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:
