End of the Line for the Bredolab Botnet?

On 25 October 2010, the Dutch police force’s Cybercrime Department announced the shutdown of 143 Bredolab botnet control servers. The next day at Armenia’s Yerevan international airport, one of those formerly responsible for running the botnet was arrested. While it is certainly possible that this marked the end of Bredolab, the technologies behind it remain and can, unfortunately, still be used to create new botnets.

A brief history of Bredolab

Malicious programs from the Backdoor.Win32.Bredolab family were first detected by IT security labs as long ago as mid-2008. Bredolab’s key purpose is to download other malicious programs onto victim computers. The download management system, which includes a loader (Backdoor.Win32.Bredolab) and an administration panel, was offered for sale on hacker forums. It is this software that shaped the foundation of the Bredolab botnet that appeared in mid-2009, and was, according to the Dutch police, comprised of approximately 30 million computers located in countries all over the world.

One of the botnet’s most distinguishing features was its method of operation: legitimate websites that had been hacked were used to spread the botnet’s payload. Visitors to these websites were redirected to malicious resources which resulted in their computers being infected with Backdoor.Win32.Bredolab — everything operated automatically.

Hacked sites

When the botnet was first created, it operated by hiding an iframe tag on hacked websites that linked to a malicious resource. In late 2009, this iframe tag was replaced with obfuscated JavaScript code known as the Trojan-Downloader.JS.Pegel script downloader. When the code executed, the browser decrypted the tag script and placed it on an HTML page with a link to a malicious resource. Pegel was designed to download exploits onto victim computers; and in turn, these exploits downloaded Bredolab. The cybercriminals reverted to their former method of hidden iframe tags again in the summer of 2010.

It is worth noting that the scheme used to spread Bredolab is similar to that used by the creators of the Gumblar botnet, while the obfuscation methods used with Pegel were reminiscent of the Gumblar script downloader’s functions.

The threat was essentially global: web resources containing malicious code were found in countries all over the world.

Distribution of web resources infected by Trojan-Downloader.JS.Pegel by country:
January-October 2010

Users in many countries faced the risk of their computers becoming infected with Bredolab.

Distribution of victim computers infected by Trojan-Downloader.JS.Pegel by country:
January-October 2010

Internet forums were dotted with messages about obfuscated JavaScript code planted on legitimate websites; the code was redirecting users to web resources controlled by cybercriminals.

An example of a forum message

At the start of 2010, there were lots of forum messages similar to the example given here. At the time, one of the main distinguishing features of Pegel were the /*GNU GPL*/, /*LGPL*/, /*CODE1*/ or /*Exception*/ comments placed at the start of the malicious JavaScript code. The infected page’s code looked something like this:

An example of a legitimate web page that has been infected

Later, the comments disappeared from the code script and the obfuscation became increasingly complex:

An example of an infected website in which the JavaScript code is more deeply obfuscated

The appearance of the links leading to the malicious resources used by Pegel during the early months of its existence deserves special mention. The domain portion and the route to the malicious script in these links were composed of known domain names, one after the other, for example:

hxxp://twitpic-com.fastclick.com.shinobi-jp.bestb***site.ru:8080/google.com/google.com/novoteka.ru/vagos.es/radikal.ru/
hxxp://google-com-sa.scribd.com.google-hr. bestb***site.ru:8080/bu520.com/bu520.com/google.com/56.com/ups.com/
hxxp://staples-com.toysrus.com.ngoisao-net. cars***net.ru:8080/google.com/google.com/livedoor.biz/atwiki.jp/torrents.ru/

Second level domains were made up of a series of two or three English words that are usually not used together. The creation of these malicious links that resembled the URLs of popular web resources was one of the most favored methods of social engineering among cybercriminals as such a technique minimizes user suspicion.

Later, the domain section of the links was also composed of second level domains:

hxxp://help***ecare.at:8080/vkontakte-ru/google.com/chinahr.com.php
hxxp://jui***ile.ru:8080/sify-com/google.com/last.fm.php
hxxp://pass***tblues.ru:8080/google.com/kijiji.ca/pornhub.com.php
hxxp://best***kstar.info:8080/google.com/travian.com/youjizz.com.php

Later still, the long paths disappeared from the links, and the path was changed to index.php.

Fast-flux networks

Domains containing malicious links were registered in several domain zones, including: ru, info, at, and com. Each domain was on five IP addresses and, in turn, each IP address was linked to numerous malicious domains.

The connections between IP addresses and malicious domains

The number of IP addresses fluctuated between twenty and forty. Over time, some addresses dropped off and new ones appeared. Periodically, IP addresses connected to certain domains would change.

A records at different points in time

It transpired that all of the IP addresses used belonged to a dedicated server, or virtual dedicated servers, of a variety of hosting providers. Moreover, further analysis has shown that Port 80 on many such servers communicates with popular websites that have no links to any criminal activity. A detailed picture of the situation leads one to believe that the servers hosting malicious domains were potentially hacked. Cybercriminals used some of the registered domains for DNS services on these very same hacked servers. Furthermore, the NS-records — like the A records — changed periodically.

NS records at various points in time

The details described above fit the profile of fast-flux networks, or more specifically, double-flux networks, where the address of DNS servers also changes.

There is another interesting fact: in the overwhelming majority of cases, all malicious links pointed to Port 8080, while the HTTP headers contained ‘nginx’ as the server’s response in the Server field. Nginx is a very commonly used HTTP server that is often employed as a reverse proxy. Users who follow the malicious link were routed to proxy servers that then redirected the request to the botnet’s actual control center.

A fast-flux network consisting of proxy servers helps to conceal the botnet’s command center from IT security professionals. All of the requests to download malicious code sourced from the malicious JavaScript and exploits, as well as Bredolab requests sent to the command center, passed through the fast-flux network’s proxy servers.

Most domains on the fast-flux network were registered by the cybercriminals themselves. However, in the early summer of 2010, some domains appeared that were actually third-level subdomains:

kollinsoy.skyef***on.com
aospfpgy.dogpl***tation.com
oployau.fancou***logger.com
hosotpoyu.credi***brary.com

While the third-level domains pointed to Bredolab’s fast-flux network proxy servers, the second-level domains from these links were planted on legitimate sites. The IP addresses of the third-level and second-level domains were different from one another. Somehow, probably by hacking user account details or another similar method, the cybercriminals were able to control the DNS settings of these websites.

Infection of victim computers

After Pegel or iframe assisted in redirecting the user’s browser to a malicious site, JavaScript code was downloaded:

…that looked like this after deobfuscation:

After executing, the JavaScript code planted the following HTML-code on the page:

Yet another JavaScript code was downloaded from the link.

…and following deobfuscation, its fragment looked like this:

This code redirected user requests in the browser to exploits.

These exploits took advantage of the following vulnerabilities in certain Adobe Acrobat functions, including: util.printf (CVE-2008-2992), Collab.collectEmailInfo (CVE-2008-0655), Collab.getIcon (CVE-2009-0927), and media.newPlayer (CVE-2009-4324); whilst in the virtual Java machine they took advantage of (CVE-2010-0886) and the MDAC RDS.Dataspace ActiveX component (CVE-2006-0003).

A fragment of deobfuscated JavaScript code in a PDF exploit

The Java exploit is downloaded in two stages: the first download is the Applet1.html page, which contained an tag named as a jar file. The exploits are downloaded next.

The Applet1.html page that downloads a java exploit

Once this process has taken place, the exploits are downloaded onto the victim computer and proceed to launch the malicious Backdoor.Win32.Bredolab, which then downloads and launches other malicious programs.

The stages of infection of a victim computer

The botnet in action

Once it has launched on a victim computer, and in order to download more malicious programs, the bot will send a request like the one below to its command center:

http://ba***il.ru:8080/new/controller.php?action=bot&entity_list=&first=1&rnd=981633&id=1&guid=3676040431.

In the body of the reply from the botnet’s command center, we can see encrypted executables, usually in the form of three or four files, which follow one after the other.

A command center reply containing encrypted malware

The header of the reply contains the Entity-Info field, which is composed of a list of elements separated by a semicolon. Each element describes one of the executables found in the body of the reply. The element is separated from a numeric field by a colon — for example; the field immediately following each element contains the size of the respective executable file. In this way, it is possible to identify where one file ends and the next begins.

The reply header’s Magic-Number field contains the key to deciphering the body of the reply. It is composed of numbers separated by the ‘|’ symbol. The first number is the length of the key, and the second denotes the deciphering algorithm. The number 1 being a typical XOR; the rest of the field is the deciphering key. Note that the malicious JavaScript code, the exploits, Bredolab, and the other malicious programs that were installed by Bredolab on the victim computer were all downloaded from the same domains on the Bredolab botnet’s fast- flux network.

Bredolab downloaded a fairly wide variety of malicious programs to victim computers:

Trojan-Spy.Win32.Zbot,
Trojan-Spy.Win32.SpyEyes,
Trojan-Spy.Win32.BZub,
Backdoor.Win32.HareBot,
Backdoor.Win32.Blakken,
Backdoor.Win32.Shiz,
Trojan-Dropper.Win32.TDSS,
Trojan-Ransom.Win32.PinkBlocker,
Trojan.Win32.Jorik.Oficla.

This list is far from complete.

Some of these malicious programs are transmitted in replies to the command center using parameters that denote a partner’s identification number. For example, Backdoor.Win32.Shiz, when downloaded by Bredolab, transmits the parameter seller=15, which means that it was installed on the system via Bredolab. The transmission of these ID numbers to the command center usually means that the malicious program is being spread via partners. This, in addition to the variety of software downloaded by Bredolab, points to the way in which the owners of the Bredolab botnet were making money from their creation: they were generating revenue from downloads. In other words, they sold the software to other cybercriminals in the form of downloads.

Of all of the downloaded software, Trojan-PSW.Win32.Agent.qgg deserves special mention. Once it is installed on a victim machine, this Trojan attempts to find the passwords for FTP accounts saved on the following clients:

When it finds any passwords, the Trojan sends them to the cybercriminals’ server.

Trojan-PSW.Win32.Agent.qgg is interesting because the server to which the Trojan sends its stolen passwords belonged to the owner of the Bredolab botnet. The stolen FTP account passwords helped the cybercriminals to infect legitimate sites with malicious code. This vicious cycle turned out to be very effective indeed.

The malicious cycle

After close examination, it became clear how the botnet was created.

1. When visiting a site infected by Pegel or iframe, users’ browsers download a page containing malicious JavaScript code.
2. This code initiates the download of Bredolab onto the victim computer. In turn, Bredolab downloads other malicious programs, including a Trojan that steals passwords to FTP accounts. All of these operations take place via reverse-proxy servers which conceal the botnet’s actual command center.
3. After some time, the website for which the account details were stolen also becomes infected. Using stolen usernames and passwords for FTP accounts, some, though not all of the website’s contents are downloaded from the server. Only those files that start with index*, default* and main* are targeted, as well as all of the files with the *.js extension. These files are then uploaded back onto the website having been injected with malicious code. Remarkably, the download and subsequent upload operations take place via numerous IP addresses. Each file can be downloaded from one IP address, and then uploaded from another.
4. After another user visits the infected site, the process described above begins all over again.

Clearly, the computers that ended up participating in the infection of the website are proxy servers. The cybercriminals employed two groups of proxy servers: one for infecting victim computers, and a second for infecting websites. These two server groups do not appear to interact in any way.

A fragment of the FTP log illustrating the website infection process

How the Bredolab botnet was created

This method of proliferation was employed by the cybercriminals throughout Bredolab’s entire existence.

Traffic

The botnet’s self-sustaining capability as described above is no doubt effective, if only for the way that it automated the process of infecting ever more computers. However, it does have one flaw. The scheme starts to work the moment the user is redirected from the infected legitimate resource to a malicious domain on the fast-flux network. Furthermore, the number of victim computers infected by Bredolab that have administrative access to some kind of website is limited. This in turn reduces the number of web resources that cybercriminals can infect using stolen FTP account credentials. Malware was removed from sites with high hit-rates relatively quickly. The larger the number of visitors a site had, the higher the probability a user would notice something suspicious and file a report with the website’s administrators. So, although the self-sustaining capability is effective as mentioned previously, the actual number of infected machines resulting from this approach turned out to be too low for the cybercriminals’ purposes.

In order to boost the effectiveness of their attacks, the cybercriminals needed to increase traffic, that is to say, the number of visitors redirected to malicious fast-flux network domains, so they tried a variety of methods to accomplish this goal.

Starting in December 2009, many legitimate websites, including some very popular ones, were infected with obfuscated JavaScript code in order to redirect users to malicious resources. Had an Internet user opened the page in their browser, the code view may well have looked like this example:

An example of code from an infected website

After the browser deciphered the code, the page was seeded with a code containing Trojan-Downloader.JS.Pegel, which then redirected the user to a malicious resource.

Users may well have received a link to malicious content labeled “with home delivery” in a spam email. In June 2010, the Trojan-Downloader.JS.Pegel.g variant ranked first among the most prevalent malicious attachments in email traffic.

The most widespread malicious files delivered by email in June 2010.

Some malicious spam attacks were relatively sophisticated. In June 2010, there was also a wave of spam purporting to be messages from popular websites such as Twitter, YouTube, Amazon, Facebook, Skype and others. These emails contained either HTML attachments infected with Pegel, or links to infected websites.

An example of a spam email with links to a malicious website

If a user clicked on the link, the infected site would load an HTML page with the following code into the browser:

PLEASE WAITING 4 SECOND…

After a few seconds, the meta-refresh tag would redirect the user to the Canadian Pharmacy website, which sells Viagra and other medication.

The Canadian Pharmacy website

Meanwhile, the link containing the iframe tag would redirect users to one of the proxy servers in the fast-flux network in order to infect the computer with Bredolab.

In August 2010, another source of traffic was also identified. The Asprox spambot, which is capable of injecting SQL into websites written in ASP, started to infect legitimate websites by injecting an iframe with a link to the ****n.ru/tds/go.php?sid=1 path .

GET /page.asp?id=425;
declare%20@s%20varchar(4000);set%20@s=cast(0x6445634c417245204054207661526368615228
323535292c406320…5205461424c655f435552736f7220%20as%20varchar(4000));exec(@s);-

An example of an SQL injection used by the Asprox bot

After a user had visited the infected site, their browser would close the link containing the iframe tag. This link was injected with a TDS (traffic distribution system), which then redirected the browser to malicious domains that belonged to the owners of Bredolab’s fast-flux network in order to infect the user’s computer with Bredolab. Approximately 10 thousand users per day were redirected in this way.

Finally, in September 2010 the latest method used to redirect users to Bredolab’s fast-flux network domains was discovered. Legitimate websites were hacked using the OpenX banner generator. A vulnerability was used in the Open Flash Chart 2 component, allowing cybercriminals to download files of their choice to the server. As a result, popular websites such as thepiratebay.org, tucows.com, afterdawn.com, esarcasm.com, and tutu.ru had banner ads replaced. The banner ads were flash files containing ActionScript code that redirected users to malicious resources. At the same time, a DDoS attack was launched against the official OpenX project site, leaving users unable to download engine updates to patch the vulnerability for several days.

A fragment of a malicious SWF file

A fragment of ActionScript code planted in an HTTP page tag script with a link to a malicious site

After a strong upsurge in June related to the spread of spam with links to the botnet’s malicious resources, Pegel activity diminished. Nevertheless, the threat could have remained very real — if the Bredolab botnet had not been shut down.

Conclusion

The owners of the Bredolab botnet created and controlled a network of over 30 million zombie computers that functioned over a long period of time. In order to keep the botnet up and running, the cybercriminals skillfully and effectively concealed the botnet’s command center using fast-flux network techniques. This scheme not only provided reliable sustainability for the botnet’s command center, it also simplified management of malicious content: instead of having to manage malicious sites on multiple nodes, all the cybercriminals had to do was place one such site on the command and control centre and set up redirectors.

Due to its complexity, the Bredolab botnet was most likely controlled by more than one person. However, at this point only one cybercriminal has been arrested in connection with this botnet. It is possible that the other participants in this criminal group are still engaging in these activities, since the scheme that they came up with and put into operation is rather effective. The technologies used to create and maintain the botnet’s performance — obfuscated JavaScript code that downloads exploits, the repetitive cycle of building up zombie networks, and the creation of network infrastructure using fast-flux, among other things — is a worthy addition to the cybercriminals’ arsenals.

One of the key features of the Bredolab botnet is the closely repeating cycle it used to build up its zombie networks, in which infected computers subsequently infected websites, which in turn infected new victim computers. Furthermore, the search for new ways to redirect users to malicious domains was ongoing. The main source of threat in this instance was the infected websites that, when visited, would download malicious programs. Information from the infected user computers could then be used to infect new websites.

In order to protect yourself against this type of threat, you should follow the security recommendations below regarding computers and websites:

Protecting your computer

• Promptly install updates and patches for your operating system and third-party applications, as most exploits and worms take advantages of software vulnerabilities for which patches are already available.
• Of course, you must also install a proprietary antivirus program and keep your antivirus database up to date. Antivirus programs are not a panacea, but they can significantly minimize the risk of computer infection.
• Always avoid clicking on links in spam emails, instant messaging apps and in messages from people you are not familiar with on social networks. No further explanation needed.

Protecting websites

• Vulnerabilities in website coding can be used to infect a website. In order to minimize the chances that cybercriminals will take advantage of a vulnerability, monitor the software updates released and promptly update your website’s software.
• Keep in mind that some services provide malware code scanning and scanning for unauthorized content changes.
• For security purposes, it is best to switch off any autosave functionality for FTP passwords and FTP clients. Remember, many programs that steal FTP account passwords, particularly Bredolab’s Trojan-PSW.Win32.Agent.qgg, search for passwords that have been saved on an infected computer.
• It may be useful to make a backup copy of your website from time to time, including any databases and files that may contain important data, so that your data is safe in the event of infection.
• If your site becomes infected despite your best efforts to protect it, simply deleting malicious code from the site may not be sufficient. For example, if your FTP password is stolen, the site may be re-infected at a later date. Take the following steps to resolve the issue fully:
  1. Check for any updates for the website’s software and download them, this will help to prevent infection taking place through vulnerabilities.
  2. Use a proprietary antivirus product with the most up-to-date antivirus databases, and do a full scan of your computers that have access to the FTP website.
  3. Change the password to your FTP account regularly.
  4. Remove malicious code from the site.

By following the above recommendations, you can help to minimize the risk of your computer resources becoming part of a botnet. Don’t forget — it’s always much easier to prevent an infection than it is to deal with the consequences of an infection.