Update on the Beebone Botnet Takedown

On April 8, the takedown operation for the polymorphic botnet known as Beebone successfully concluded. This action redirected traffic from infected hosts to a sinkhole operated by the Shadowserver Foundation. In addition to halting additional infections and the continued morphing of the W32/Worm-AAEH worm, the sinkhole allows McAfee Labs and other partners in the takedown to better understand the scope and complexity of the Beebone operation. We now have a more accurate count of infected hosts, we have identified additional indicators of compromise, and we have greater visibility into the botnet’s geographic reach.

Obfuscation capabilities

The sinkhole has revealed multiple obfuscation techniques. One mechanism is the botnet’s polymorphic nature, which guarantees unique samples for every download request. The actors behind Beebone went the extra mile by replacing the base worm sample multiple times per day. For example, from March to July 2014, the Beebone control server served at least one new sample every day (we conclude with 93.6% confidence) with up to four variant changes per day.

The worm switched from its custom crypter to the underground “29A Loader” crypter on July 21, 2014, losing all of its server-side polymorphism capabilities. To make up for the lost variety of distributed samples, the attackers replaced an average of eight variants per day, with 35 variant replacements on the same day the packer changed.

Although the samples were functionally similar across variants, the top-level crypter was consistently modified to change its final binary code. Some of the changes are listed below.

Third-party open-source software

Some of these samples included the entire “Wizard-TemplateXP” UI library, originally located at http://en.pudn.com/downloads27/sourcecode/windows/control/detail85571_en.html. We can verify this by comparing strings from the UI library source code to the W32/Worm-AAEH binaries. (See following images.)

These samples include:

• b6e232d8ac1841fa87ebbd15bebec1ce
• c880bd52cfaf3206f95eb49b5d51f1c657b7aa82
• 15fc526edc6a5c665accfae06f8609c5cc93ac30
• 449c870a9d5012a1cb6279638291de51e551490d)

 

Change in encryption keys.

Another obfuscation technique is the use of the RC4 encryption algorithm to generate encrypted strings (prior to December 2013) and binaries (after December 2013). For any given base W32/Worm-AAEH crypter stub (which the polymorphic engine uses to mutate and generate other samples), the RC4 key is composed of the original project name concatenated with a hardcoded number treated as a string. Although the polymorphic engine randomizes the project name on each mutation, it keeps the hardcoded number intact, allowing us to identify base variants generated by the polymorphic engine. However, some samples introduce an additional round of RC4 encryption with a one-character string, starting from “0” and stopping at “9” before moving to a new obfuscation technique.

Change in fields needed for decryption
On December 12, 2013, dependence on the project name was removed entirely. After that date, samples could use any string present in the sample as the RC4 key to decrypt the final payload. The intent of this change was likely to make static detection by antimalware scanners more difficult. This approach was used until March 31, 2014. After that day, the crypter began to use position-independent code (for example, 6620235fced076d1d7ce9b1c7c58967b) to partially implement its unpacking functionality. An additional layer of obfuscation was added on April 14, 2014, when the data type of variables storing the location of encrypted data changed from an integer to a “currency” type, which is native to the Visual Basic 6 language. Although this was a simple change in the crypter source code, its effect on final binaries is immense. Instead of having the location appear directly in a binary as a 32-bit value, with a currency type it appears as the original value multiplied by 10,000. However, each sample unevenly splits the number into two separate numbers, requiring addition or subtraction (followed by a division by 10,000) to retrieve the location of the encrypted data (for example, b1121d10573440735f0db22b85a4a634). Although antimalware scanners can still detect these samples, it is more difficult.

Control server architecture
The control servers behind W32/Worm-AAEH used a MariaDB database (a MySQL alternative) along with the Webmin web-based database administration tool (an alternative for phpMyAdmin) to store and maintain data stolen from infected systems. It is likely that they remotely controlled their servers using the Secure Shell (SSH) tool.

The Webmin interface for a control server used in August 2014.

The domains for the control servers were prefixed with “ns1.” to masquerade as DNS name servers. To make the deception appear authentic, the port used for DNS queries (53) was left open even though no name resolution took place.

The attackers changed the control server names more than five times a month on average, as shown in the table below.

Sinkhole results

These actions illustrate some of the mechanisms used to obfuscate the infection. As a result, we underestimated the scale of the Beebone botnet. Overnight reports from the Shadowserver team show that the scale of the botnet is about three times greater than earlier estimates.

Although this data shows about 34,000 unique IP addresses per day, it does not mean that there are 34,000 infected computers, as some people may connect for research purposes and other systems may be turned off. We hope to see the number of unique connections to the sinkhole decline as remediation begins to take effect.

We would like to thank and recognize F-Secure, Trend Micro, and Symantec for also developing removal tools for W32/Worm-AAEH.

 

I am indebted to my colleague Sanchit Karve for his assistance with this post. Sanchit (@s_karve) and Raj (@Raj_samani) can also be found on Twitter.

The post Update on the Beebone Botnet Takedown appeared first on McAfee.