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 mentioned file will install the WinPcap library, which is being used by the malware to sniff the network traffic on the victims computer:

Origin process (executing process)

Affected file

C:\WINDOWS\Temp\_ex-68.exe

C:\WINDOWS\system32\Packet.dll

C:\WINDOWS\Temp\_ex-68.exe

C:\WINDOWS\system32\wpcap.dll

C:\WINDOWS\Temp\_ex-68.exe

C:\WINDOWS\system32\drivers\npf.sys

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:

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:

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:

GET /jucheck.exe HTTP/1.0
Host: etrodhy.eu

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”.

It is common that cybercriminals are hosting their stuff in rogue networks (renting out so-called Bulletproof hosted servers). Many of you may remember the year 2008, when a well known Bulletproof hoster named McColo was knocked offline. We can say that this nearly was a historical moment in the history of the world wide web, where the Internet community clearly showed that they didn’t want to tolerate Cybercrime any longer. The McColo takedown was the beginning of a series of takedowns initiated by security researchers, law enforcement agencies and volunteers; In 2010, the well known Russian based Bulletproof hoster Troyak was cut off from the Internet, followed by the takedown of Group Vertical.

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.