Necurs Proxy Module With DDOS Features

Written by Sofia Luis

Marketing Manager, EMEA & APAC

Necurs is a malware that is mainly known for sending large spam campaigns, most notably the Locky ransomware. However, Necurs is not only a spambot, it is a modular piece of malware that is composed of a main bot module, a userland rootkit and it can dynamically load additional modules.

Having been around for a few years, this malware has been subject to a lot of great research that has covered many of its aspects including the rootkit, the DGA, the communication protocol and the spam module. However, there has not been much public information on any modules loaded by Necurs besides the spam module.

About six months ago we noticed that besides the usual port 80 communications, a Necurs infected system was communicating with a set of IPs on a different port using, what appeared to be, a different protocol. The following image shows an example of this network traffic.

Recently, while decrypting the C2 communication of the a Necurs bot, we observed a request to load two different modules, each with a different parameter list. The following is the decrypted translation of the modules section of the C2 response:

The first one was the spam module for which Necurs is most known, and the parameters are the C2 addresses from which it can receive new spam campaigns. The second one was an unknown module and, judging by the parameter values, it was the one responsible for the communication we were seeing to port 5222.

We noticed this module in September 2016 and the compilation timestamp on the module is “Aug 23 2016”, which suggests the module started being used around then. However, it is possible that another version of the same module had been deployed before, without being noticed.

We downloaded the module and reverse engineered it to try to understand exactly what it was. At first look, it seemed to be a simple SOCKS/HTTP proxy module, but as we looked at the commands the bot would accept from the C2 we realized that there was an additional command, that would cause the bot to start making HTTP or UDP requests to an arbitrary target in an endless loop, in a way that could only be explained as a DDOS attack. This is particularly interesting considering the size of the Necurs botnets (the largest one, where this module was being loaded, has over 1 million active infections each 24 hours, we blogged about it here). A botnet this big can likely produce a very powerfull DDOS attack.

Please notice that we have not seen Necurs being used for DDOS attacks, we simply saw that it has that capability in one of the modules that it has been loading.

The rest of this post contains the results of a technical analysis of this module, detailing its C2 protocol, the SOCKS/HTTP proxy features, and the DDOS attack features.

MODULE TECHNICAL ANALISYS

Module start/initialization

Once the module is loaded by the bot, it performs the following initialization actions:

Parses the parameters and stores them in an internal list of C2 addresses;
Fills a memory structure (see botsettings struct definition below) with:
- The BotID - Generated through gathering unique system characteristics;
- The internal IP address - Obtained by checking the outbound sockets IP address when connecting to google.com;
- The external IP address - Obtained trough HTTP from ipv4.icanhazip.com or checkip.dyndns.org;
- The available bandwidth - Obtained by measuring the download speed of the Windows 7 Service Pack 1 file from microsoft;
- The (socks/http) proxy service port - The port of the service listening on a random port above 1024;
Checks if the system is behind NAT - By checking if the outbound socket IP is not a local address and that it matches the external IP;
If the system is not behind NAT, the bot starts a SOCKS/HTTP proxy service listening on a random port above 1024.

The botsettings struct can be defined as follows:

C2 communication protocol

After initialization, the bot will enter the main C2 connection loop, where it will attempt to connect to the current C2 every 10 seconds, unless instructed otherwise. If the connection to the current C2 fails, it will fetch another from the address list and try again.

The communication protocol is binary and encrypted/obfuscated using a custom algorithm. Messages to, and from, the server have a very similar structure (see struct botmsg and c2msg definitions below) and contain the following data:

Key - A 32 bit encryption key;
Encrypted header - A header structure (see struct botmsgheader and c2msgheader definitions below), encrypted with the key and containing:
- Message type - A byte that defines the type of message/command being sent;
- Payload length - The length of the payload being sent;
- Header hash - A hash of the first bytes of the message (key, msgtype, unknown and datalength);
- Data hash - A hash of the payload, used for integrity checking;
Encrypted payload - An array of data being sent, encrypted with the reverse value of the key.

There are three types of messages sent by the bot to the C2, that can be distinguished by the msgtype byte in the header:

Beacon (msgtype 0) - This is the main message that is sent by the bot every 10 seconds. It sends the botsettingsstruct described previously as a payload;
Connectivity check (msgtype 1) - This is a simple dummy message that contains no data besides the encrypted message header. It is sent in case a timeout occurs to the current C2 to make sure it is no longer available;
Proxybackconnect (msgtype 2) - This message is sent in case the bot receives the command to start a socks backconnect. This will start a connection to the C2 that will be reused for the SOCKS/HTTP proxy connection, proceeding as if it had been initiated by the proxy client.

As a response to the beacon, there are also three types of messages (or commands) sent by the C2 to the bot, that can be distinguished by the msgtype byte in the header:

Start Proxybackconnect (msgtype 1) - This command tells the bot to start a backconnect proxy session by sending a proxybackconnect message from the bot to the C2. This connection’s socket will be reused and allows the bot to be used as a proxy even behind a firewall and without establishing a direct connection to it;
Sleep (msgtype 2) - This will cause the bot to sleep for 5 minutes;
Start DDOS (msgtype 5) - This command will start a DDOS attack against the target specified in the message payload using one of two available attack modes:
- HTTPFlood: If the first bytes of the message payload are the string “http:/”, the bot will start an HTTP flood attack against the target;
- UDPFlood: If the first bytes of the message payload are not the string “http:/”, the bot will start an UDP flood attack against the target.

Proxy features

The SOCKS/HTTP proxy service and command, allows the botnet owners to use the compromised bots as proxies (HTTP, SOCKSv4 and SOCKSv5 protocols), relaying connections through them in two modes of operation (direct proxy and proxy backconnect).

In direct proxy mode, the client connects to the proxy service, which will forward the communication to the destination, as in the following image:

This is only possible if the bot is not protected behind NAT or a firewall, which is not the case in the vast majority of the botnet.

In proxy backconnect mode, the client connects to the proxy controller, that will then obtain an outbound proxy from a pool of available proxies and relay the connection through it. The following diagram illustrates the system:

There are several advantages to this operation mode. The main ones being that it works even if the infected system is behind NAT and it will allow a connection to internal network resources as if it came from the infected machine. Another common use for these kind of proxies is to have a constantly changing IP address, by constantly and automatically changing the bot serving as proxy.

Taking a brief view at how this is implemented, the following image shows part of the function that processes the C2 commands.

In case the bot receives a startproxybackconnect command (msgtype 1), the bot will send a proxybackconnect message to the C2 (msgtype 2) and then the same socket that is used in the C2 communication (globalsocket) to the startprocessincoming function that does the actual proxying work. This means that the same connection used for C2 communication will then be used to proxy the connections.

The processincomming function reads 2 bytes from the incoming connection (direct or through backconnect) and checks if the first has the value 5 (Socks v5 protocol), 4 (Socks v4 protocol) or if it is alphanumeric (HTTP Proxy). It then calls the appropriate function that does the actual proxying work for each of the supported protocols.

DDOS attack features

Possibly the most interesting, and unexpected, feature of this module is the DDOS attack mode. The module contains two very basic DDOS attack modes, that don’t have special features like origin IP address spoofing or amplification techniques. However, given the size of the Necurs botnets (more than 1M IP/24 hours in the largest botnet), even the most basic techniques should produce a very powerful attack.

Taking a brief look at how it is implemented, if the bot receives the startDDOS command (msgtype 5) the payload portion of message is parsed looking for the string “http:/”. If it is found, the HTTPflood function is called, if not, the UDPFlood function is called, as shown in the following image:

HTTP Flood attack mode

The HTTP attack works by starting 16 threads that perform an endless loop of HTTP requests. The following images show the 16 threads being queued and the section of the code that sends the HTTP request:

The HTTP request is built using the following format string:

UDP Flood attack mode

The UDP flood attack works by repeatedly sending a random payload with size between 128 and 1024 bytes. The function contains a 0.1 second sleep that may be triggered depending on the available bandwidth (calculated during bot initialization), possibly to avoid losing access to the bot during a DDOS attack. The following image shows the UDPFlood main loop:

Conclusion

Although known mainly for its spam module, Necurs is a modular malware that can be used for many different purposes. In this blog post we detailed a module that adds SOCKS/HTTP proxy and DDOS capabilities to this malware. Although we have not seen Necurs being used to perform DDOS attacks, this capability is currently deployed in the infected systems and taking into account the size of the botnet it could produce a powerful attack.

References

For more information about the Necurs Botnet, check out the following links:

Analysed module sample:

f3aeafe50880cb9dd584b3669800c017de561f8f9654440f62c51319fda0e970