Darkshell DDOS Botnet Evolves With Variants

Darkshell is a distributed denial of service (DDoS) botnet targeting Chinese websites. It was found in 2011 and was first analyzed by Arbor Networks. McAfee Labs recently analyzed a few new samples that turned out to be variants of Darkshell, and we found extensive variations in network traffic and control commands.

The Darkshell bot follows a fairly standard installation process by copying itself into the System32 directory with a name that appears to be legitimate, for example, C:\WINDOWS\system32\WinHe803.exe. It then sends the system information of the infected machine to its control server in encrypted format. Once the control server receives the information, it responds with the victim’s address and the type of DDoS attack to perform.

Here are a few of the MD5 hashes we analyzed:

• aff00fac695971c1aea37ce51f4d6228
• beec4de4740da867ed44c666d283c4f2
• b3e28fc05514abbaea1e12b676bef2a8
• bc47ff49ba8ea1bc0c028edd7262c0ac
• bcb210972648719e7d53223fbb7210ab
• beec4de4740da867ed44c666d283c4f2
• bf56f97511c4c4bc23d92c17d5e976fe
• c008c851bef86764943f7a4a2a16d7c6
• c74890f5a5400e70ff40da0493a933d7

The binaries we analyzed were compiled in a way that it makes them hard to reverse engineer (and ease our analysis). Each binary contained a lot of junk code and made multiple calls between the junk codes to complete a single task. We also found that the binaries used antidebugging and antidisassembly techniques to evade disassembly and reversing. The code was written in C++.

Let’s dig into some detailed analysis of the new variant of Darkshell. The binary executed fake code along with a debugger detection check, and exited the process while debugging. The binary accessed heap flags from the Process Environment Block (PEB) structure to detect our debugger. (Heap flags are set to “0×50000062” when a process is being debugged.) The following figure shows the actual code from the botnet binary:

If the flags are set to 0×50000062, the bot will detect the debugger and will exit the process. Once we bypassed this defense, the botnet started its decryption routine with the help of the hard-coded XOR key shown below:

First, the binary decrypted 1917 (hex) bytes of the code with the preceding XOR key, starting at the address 0×00401000. Next, it decrypted all the strings using the same XOR key. Following that, the bot built its import address table using the “LoadLibrary()” and “GetProcAddress()” functions. We found it interesting that the bot did not call LoadLibrary() and GetProcAddress() in the usual way. In this sample, it first pushed the address of the LoadLibrary() function on the stack and then returned to it, as shown in the next image:

After the LoadLibrary() function, the sample returned to a piece of code that the OllyDbg 1.1 debugger failed to recognize.

This maneuver means the binary uses an antidisassembly technique. To get around this obstacle, we tried OllyDbg 2.0, which successfully assembled the code as follows:

The malware used a similar move with the GetProcAddress() function, pushing the address on the stack and returning to it. This way the bot built its import address table and jumped to original entry point, as we can see in the next image:

By looking at the preceding code, we can easily say that this is a generic Microsoft Visual C++ executable entry point. Finally, we dumped the process and fixed the import table to unpack it in the original format. Here are the strings from the unpacked binary:

Now we have our unpacked binary. Rather than dive into the reverse engineering, we will focus on network control activity. The bot sends a TCP packet of 228 bytes in encrypted format to its control server. Here is the packet capture:

We identified the routine in use—a fairly simple XOR and substitution—with the help of the hard-coded value “7DB” in following snippet:

The XOR key is generated and data is encrypted in the “encryption_routine” function seen above.

The preceding encryption algorithm can be translated as follows:
Encrypted Byte = (Original Byte ^ XOR Key) + XOR Key
And hence the decryption algorithm is:
Original Byte = (Encrypted Byte – XOR Key) ^ XOR Key

Applying this decryption algorithm on the encrypted packet results in the following:

Here’s an analysis of the Darkshell control structure of 228 bytes:

struct {

char Processor[127]; // Processor information
char Memory[31]; // Memory information
char OS[31]; // Operating System information
char Version[31]; // Bot version information

};

As we see above, the bot sends processor, memory, and operating system information along with its version, “VIP0410” in this sample. Once the control server receives this information, it replies with 124 bytes of data that contain the victim’s address and method for launching the DDOS attack. The response packet is not encrypted, as we see below:

The first 4 bytes describe the type of attack. In the preceding case the value “0×00000400” launches an HTTP GET request with a small-header DDOS attack on the victim, using port number 80. The port value is specified at offset “0x009E,” which is 50 (or 80 in decimal).

The response attack structure of the 124 bytes:

struct {

DWORD dwCode; // attack method
char Target[99]; // URL of target, NULL-terminated/extended
DWORD Port // Port to attack
DWORD ThreadCount // number of threads to create
DWORD dwMilliseconds // Sleep (in milliseconds)
DWORD socketCounter1 // Counter to create sockets
DWORD socketCounter2 // Counter to create sockets

};

Once the bot receives the response, it parses the attack method and creates multiple threads with attack methods on the infected machine, according to the thread count. The bot supports multiple attack methods, including SYN flood, UDP flood, ICMP flood, SuperSYN flood, GET requests flood, etc. The bot can also download and execute malicious binaries from the control servers.

An HTTP GET requests attack with a small header looks like this:

Here are a few of the control domains we identified:

• hh6002.sxzyong.com
• 9527idc.vicp.net
• hwtt.3322.org
• 805.sxzyong.com
• 801.sxzyong.com
• sdqd666.3322.org
• 802.sxzyong.com
• 806.sxzyong.com

Further investigation revealed that the Darkshell botnet source code is available online. We found thewww.darkshellnew.com domain, which calls itself the official Darkshell website. It hosts various versions of Darkshell botnet builder that can be downloaded free with source code. Here is a screenshot of the homepage (when converted from Chinese to English):

Here are the different versions of Darkshell botnet builders available to download:

Our research shows that variants of the Darkshell botnet are still evolving, with features such as antidebugging and antidisassembly techniques to make reverse engineering more time consuming. The botnet can launch DDOS attacks using different methods and can flood websites. Further, the presence of free Darkshell builders with source code on the Internet opens up the evolution of other variants with other mechanisms.

I would like to thank my colleague Amit Malik for contributing to this botnet research.

A unique ‘fileless’ bot attacks news site visitors

In early March, we received a report from an independent researcher on mass infections of computers on a corporate network after users had visited a number of well-known Russian online information resources. The symptoms were the same in each case: the computer sent several network requests to third-party resources, after which, in some cases, several encrypted files appeared on the hard drive.

The infection mechanism used by this malware proved to be very difficult to identify. The websites used to spread the infection are hosted on different platforms and have different architectures. None of our attempts to reproduce the infections were successful. A quick analysis of KSN statistics that might help to identify the connection between compromised resources and the malicious code being distributed did not yield any results, either. However, we did manage to find something that the news sites had in common.

Infection sources

For purposes of analysis, we selected two information resources which we knew had been used to distribute the malware— http://www.ria.ru/ (a major Russian news agency) and http://www.gazeta.ru/ (a popular online newspaper). Regularly saving the contents of these resources did not identify any third-party JS scripts occasionally showing up, iframe tags, 302 errors or any other formal attributes indicating that the resources have been compromised. The only thing they had in common was that they both used AdFox advertisement management system codes, through which teaser exchange was arranged.

 

The code on the main page of RIA.ru that is used to download additional content from AdFox.ru

We discovered that the malware is loaded via the teasers on AdFox.ru.

Here is how the infection was carried out. A JS script for one of the teasers loaded on the site included an iframe that redirected the user to a malicious site in the .EU domain containing a Java exploit.

 

The contents of an infected and a clean JS script

Analysis of the exploit’s JAR file demonstrated that it exploits a Java vulnerability (CVE-2011-3544). Cybercriminals have been exploiting this vulnerability since November in attacks targeting both MacOS and Windows users. Exploits for this vulnerability are currently among the most effective and are included in popular exploit packs.

However, the exploit used in this case was unique and had not been included in any exploit packs: the cybercriminals used their own payload in the attack.

 

Part of the JAR file’s payload

‘Fileless’ malware

As a rule, the operation of such an exploit involves saving a malicious file, usually a dropper or downloader, on the hard drive. However, in this case we were in for a surprise: no new files appeared on the hard drive.

After seizing all necessary privileges on the victim computer, the exploit does not install malware on the hard drive using Java. Instead, it uses its payload to inject an encrypted dll from the web directly into the memory of the javaw.exe process. The address from which the library is to be downloaded is encrypted in the iframe that was included in the JS script downloaded from AdFox.ru:

<applet code="Applet.class" archive="/0GLMFss"><param name="cookie" value="j::eHff8dCis:ys4iNfnUWP7yy"></applet>

 

A new malicious RWE section in the JAVAW.exe process

After successfully injecting and launching the malicious code (dll), Java begins to send requests to third-party resources, which look like Google search requests: “search?hl=us&source=hp&q=%s&aq=f&aqi=&aql=&oq=”…

These requests include data on the browsing history taken from the user’s browser, as well as a range of additional technical information about the infected system.

In other words, what we are dealing with here is a very rare kind of malware – the so-called ‘fileless’ malicious programs that do not exist as files on the hard drive but operate only in the infected computer’s RAM. The best known examples of such threats are the CodeRed and Slammer worms, which caused mass outbreaks at the beginning of the last decade.

This kind of malware only remains operational until the operating system is restarted, but in this case this is not a critical issue for the Trojan’s authors.

One reason for this is that the ‘fileless’ malware operates as a bot: after sending a series of requests to the command server and receiving replies, the exploit uses several different methods to disable UAC (User Account Control). After this the bot can install the Lurk Trojan on the infected machine. It is worth noting that the decision as to whether to install Lurk on the system is made on the cybercriminals’ server.

The second reason is that the chances of the user returning to the infected website after rebooting the system are high. This would result in re-infection, with the bot returning to the victim computer’s RAM.

Because no file is written to the hard drive, it becomes much harder to detect the problem using antivirus software. If the exploit is not detected, the bot can be successfully loaded into RAM, becoming virtually invisible.

Lurk

The Trojan-Spy.Win32.Lurk malware can be installed either using commands “regsrv32” and “netsh add helper dll” or via the ShellIconOverlayIdentifiers branch of the system registry. Lurk installs its additional modules as encrypted dll files.

 

Part of the Lurk code responsible for downloading additional modules

The analysis of the additional modules used by Lurk has provided an insight into the malicious program’s functionality: it steals users’ sensitive data to gain access to online banking services at several large Russian banks. Kaspersky Lab first detected this malware in July 2011. Based on our analysis of the protocol used by Lurk to communicate to the command servers, we determined that over a period of several months, these servers processed requests from up to 300,000 infected machines.

Reasons behind the incident

After sorting out the technical side of the problem, we notified the Adfox administration of the incident. They promptly took action, resulting in the detection and removal of the malware from the infected banner.

In the course of the investigation it was determined that the cybercriminals had used the account of an Adfox customer to change the code of news headline banners by adding an iframe redirecting users to the malicious site.

After modifying code in one of the banners, they were able to attack not only users on one news site, but also visitors to other resources carrying this banner. As a result, there could be tens of thousands of users who were attacked. At the same time, banners of other AdFox clients did not contain the malicious code.

Conclusion

This is a unique attack, because the cybercriminals used their own PE file downloader (payload) that can work without creating malicious files in the infected system, operating entirely inside a trusted Java process.

Using a teaser network is one of the most effective methods that attackers can used to install malicious code, since it results in a large number of popular resources linking to the code.

This attack targeted Russian users. However, we cannot rule out that the same exploit and the same fileless bot will be used against people in other parts of the world: they can be distributed via similar banner or teaser networks in other countries. It is likely that other malware, not just Trojan-Spy.Win32.Lurk will be used in the process.

As regards protection against this threat, we strongly suggest that all users install a patch that closes the CVE-2011-3544 vulnerability in Java. This is currently the only reliable way to prevent an infection. As we mentioned above, exploits for CVE-2011-3544 are the most effective there are and can be used to install a variety of malicious programs.

In addition, a security solution that includes web antivirus features should be used at all times. We also recommend that Kaspersky Lab users enable the Geo Filter feature, which provides manual control of the browser’s access to resources in different geographical domains, and block connections to sites in the .eu zone unless accessing them is essential. We have been detecting numerous malicious resources in this domain, including those described above, as well as servers used to distribute the Hlux Trojan, which we discussed in a recent post.

 

PS. Our heartfelt thanks go to the independent researcher, who wishes to remain anonymous, for invaluable help in preparing this publication.