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.
[table caption=”” width=”370″ colwidth=”150|150|150″ colalign=”left|left”]
Sample,
0d796cd23d03500879799f586136d548,“1” as first key,
14c761471b2659d5a63cfee50eca029d,“2” as first key,
14fe9b39dbe3017c2a6351b49f5a344a,“3” as first key,
a9d385ac73119c26f62f312801d46499,“4” as first key,
ebf2de1a6552b0342d57286472ff7200,“5” as first key,
1340319fc03aa4313651301814d0d635,“6” as first key,
1344557ff83e92384894f7f7f8b94fbd,“7” as first key,
158e28794b970a477c5cf01a402bf3f0,“8” as first key,
[/table]
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.
[table caption=”” width=”250″ colwidth=”100″ colalign=”left|left”]
Date Ranges for Control Server Names
01-MAR-2014 to 12-MAR-2014
12-MAR-2014 to 17-MAR-2014
17-MAR-2014 to 19-MAR-2014
19-MAR-2014 to 21-MAR-2014
21-MAR-2014 to 22-MAR-2014
25-MAR-2014 to 27-MAR-2014
27-MAR-2014 to 31-MAR-2014
31-MAR-2014 to 04-APR-2014
05-APR-2014 to 08-APR-2014
08-APR-2014 to 28-APR-2014
29-APR-2014 to 02-MAY-2014
03-MAY-2014 to 08-MAY-2014
08-MAY-2014 to 20-MAY-2014
20-MAY-2014 to 22-MAY-2014
23-MAY-2014 to 26-MAY-2014
28-MAY-2014 to 01-JUN-2014
02-JUN-2014 to 03-JUN-2014
03-JUN-2014 to 07-JUN-2014
09-JUN-2014 to 12-JUN-2014
13-JUN-2014 to 17-JUN-2014
20-JUN-2014 to 25-JUN-2014
27-JUN-2014 to 28-JUN-2014
03-JUL-2014 to 07-JUL-2014
07-JUL-2014 to 22-JUL-2014
22-JUL-2014 to 24-JUL-2014
25-JUL-2014 to 05-AUG-2014
06-AUG-2014 to 12-AUG-2014
12-AUG-2014 to 14-AUG-2014
14-AUG-2014 to 16-AUG-2014
16-AUG-2014 to 24-AUG-2014
28-AUG-2014 to 01-SEP-2014
02-SEP-2014 to 23-SEP-2014
24-SEP-2014 until Takedown
[/table]
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.
[table caption=”” width=”475″ colwidth=”85|100|50″ colalign=”left|center|center”]
Date,Unique IP Addresses,Unique Geographies
2015-04-15,”37,828″,150
2015-04-14,”37,089″,145
2015-04-13,”37,243″,150
2015-04-12,”32,200″,147
2015-04-11,”33,984″,144
2015-04-10,”34,899″,149
2015-04-09,”34,314″,150
2015-04-08,”15,454″,140
[/table]
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.
Stay Updated
Follow us to stay updated on all things McAfee and on top of the latest consumer and mobile security threats.
