The Kelihos botnet is rising from the ashes. Although it was taken down by the combined initiatives of Microsoft and Kaspersky Labs in 2011, and again by the Kaspersky Labs and several security firms in 2012, recent research shows that it has emerged again.

The Kelihos botnet is used for information stealing (such as passwords and virtual currency) in addition to serving as a spam bot.  It was pointed out by Kaspersky labs following the second reemergence of Kelihos in 2012 that the botnet is most likely relying on a pay per install (PPI) service. In a PPI scheme, the bot operators (or clients wanting to deploy a malware on a large scale) buy or rent the botnet infrastructure (infected hosts) to build their network and launch their operation. We observed that most of the compromised hosts serving the botnet are located in Asia and lots of them are running Windows XP (and later versions) with open ports 49152 to 49157, which might indicate that hosts in Asia are a cheaper commodity to buy (or rent) compared to other countries.

George Washington University, which uses Umbrella by OpenDNS for malware protection across its entire campus, reached out to us with intelligence related to Kelihos.  Here’s a look at the research we conducted on the case. 

The cybercriminals behind the new Kelihos botnet have decided to use a vast panoply of evasion techniques both within its malware and network components. This is making the botnet more resilient to host-based detection and sinkholing/blacklisting. Kelihos uses a new malware sample that operates in “slow motion” by making sleep calls with long timeouts in an attempt to evade automated analysis. A detailed investigation of the malware sample is available here.

From the network perspective, there are a few hundred different domains serving as command-and-control or malware distribution domains for the botnet, with which the malware component of an infected client machine attempts to communicate.
The majority of these domains are registered under the .ru (Russia) and .ms (Montserrat) ccTLDs with a few under .eu (European Union), .in (India) and .com.
Almost all of these domains were registered in the past 6 months. 74 domains were all registered in bulk on January 13th, 2013.
The figure below shows the number of domains registered on each date since early 2012.

 kelihos-domains-registration-dates5

These domains show a strong case of fast flux behavior used on multiple layers.
First, we observe that every domain (let’s take for example girwysca[.]ru) resolves to a single IP with a Time To Live (TTL) of 0 seconds (shown in the dig excerpt below). This means the A record of the domain is never cached, and the recursive DNS resolver that the infected client uses will always query the authoritative name server of girwysca[.]ru for a new IP address.

;; QUESTION SECTION:
;girwysca[.]ru. IN A

;; ANSWER SECTION:
girwysca[.]ru. 0 IN A 46.211.53.6

As mentioned, due to the fast flux nature of these domains the IPs were constantly changing. Collectively, we saw that the Kelihos domain names we studied resolved to a pool of 31,414 different IPs (and still growing) spread across 1920 ASNs and 143 countries. Most hosts are located in Asia (India, Ukraine, Russia, China and Pakistan).

 

 

As an example of this fast fluxing of IPs, we use our in-house passive DNS database to show the evolution of unique IPs that the domain girwysca[.]ru has resolved to over time. The data is sampled from one resolver in our London datacenter. Notice that the domain girwysca[.]ru was registered on December 7th, 2012, and it started resolving to IPs according to our data just 4 days after its registration.

kelihos-domain-uniq-ips-time

Second, the Kelihos domains that we analyzed show an inconsistency in the setup of their name servers. This inconsistency could be used to the cybercriminals’ advantage, as two layers of name servers can serve as evasion and redundancy techniques for the botnet. As an example, let’s again take the domain girwysca[.]ru. We show the main part of the output of a dig +trace A girwysca[.]ru below.

girwysca[.]ru. 345600 IN NS ns4[.]newrect[.]com.
girwysca[.]ru. 345600 IN NS ns2[.]newrect[.]com.
girwysca[.]ru. 345600 IN NS ns3[.]newrect[.]com.
girwysca[.]ru. 345600 IN NS ns5[.]newrect[.]com.
girwysca[.]ru. 345600 IN NS ns1[.]newrect[.]com.
girwysca[.]ru. 345600 IN NS ns6[.]newrect[.]com.
;; Received 148 bytes from 193.232.142.17#53(e.dns.ripn.net) in 169 ms

girwysca[.]ru. 0 IN A 113.255.226.230
;; Received 56 bytes from 94.154.224.58#53(ns2[.]newrect[.]com) in 363 ms

The name server replying with the IP of girwysca[.]ru is ns2[.]newrect[.]com, which is one of the name servers listed at the parent name server e.dns.ripn.net (one of the authoritative name servers for .ru). The NS record for ns2[.]newrect[.]com has a TTL of 345600 seconds (4 days) which is a reasonable duration for a stable name server. So far, so good.

Now, if we issue a dig +trace NS girwysca[.]ru to query explicitly for the name servers of girwysca[.]ru, we get the reply displayed below (an excerpt):

girwysca[.]ru. 345600 IN NS ns1[.]newrect[.]com.
girwysca[.]ru. 345600 IN NS ns6[.]newrect[.]com.
girwysca[.]ru. 345600 IN NS ns5[.]newrect[.]com.
girwysca[.]ru. 345600 IN NS ns2[.]newrect[.]com.
girwysca[.]ru. 345600 IN NS ns3[.]newrect[.]com.
girwysca[.]ru. 345600 IN NS ns4[.]newrect[.]com.
;; Received 148 bytes from 194.85.252.62#53(b.dns.ripn.net) in 219 ms

girwysca[.]ru. 0 IN NS ns1[.]girwysca[.]ru.
girwysca[.]ru. 0 IN NS ns2[.]girwysca[.]ru.
girwysca[.]ru. 0 IN NS ns3[.]girwysca[.]ru.
girwysca[.]ru. 0 IN NS ns4[.]girwysca[.]ru.
girwysca[.]ru. 0 IN NS ns5[.]girwysca[.]ru.
girwysca[.]ru. 0 IN NS ns6[.]girwysca[.]ru.
;; Received 280 bytes from 114.41.164.228#53(ns5[.]newrect[.]com) in 173 ms

The name server replies with a different set of name servers than those reported by the parent name servers.
In other words, we saw earlier that there are 6 name servers of girwysca[.]ru that are referred to us by the parent name server b.dns.ripn.net, which are ns1-6[.]newrect[.]com. We will call these “reported-by-parent” name servers.
When these name servers are queried directly for the name servers of girwysca[.]ru, they reply with a different set of name servers ns1-6[.]girwysca[.]ru with a TTL of 0 seconds. we will call these “infringing” name servers.
Normally, we would have expected to see the same set of ns1-6[.]newrect[.]com in the reply from ns5[.]newrect[.]com.
Clearly, this is not conforming to the DNS standard as we can also confirm it by checking the domain on http://www.intodns.com/girwysca.ru

inconsistent_ns_kelihos_domains3 

This could be a misconfiguration, but it is rather suspicious, as we further find out when we query for the IPs that the infringing name servers ns1-6[.]girwysca[.]ru resolve to. In the sample answers we show below, we see that ns1-6[.]girwysca[.]ru also have a TTL of 0 seconds and we observe that they also have a constantly changing and growing set of IPs. This is a case of fluxing of name servers/IPs also known as double flux in addition to the fluxing of domains/IPs discussed earlier. (refer to my presentation about fast flux in our video SF Data Mining Meetup @OpenDNS [minute 31:25] available at http://youtu.be/AeITUpKD944)

;; QUESTION SECTION:
;ns1[.]girwysca[.]ru. IN A

;; ANSWER SECTION:
ns1[.]girwysca[.]ru. 0 IN A 115.43.11.253

;; QUESTION SECTION:
;ns6[.]girwysca[.]ru. IN A

;; ANSWER SECTION:
ns6[.]girwysca[.]ru. 0 IN A 84.228.126.71

Furthermore, a substantial part of the domains of the fluxing name servers were themselves registered within the past 6 months. The main 2LD domains of the name servers are shown below with their registration dates.

boomsco[.]com, 2013-1-13
larstor[.]com, 2012-12-22
zempakiv[.]ru, 2012-12-07
newrect[.]com, 2012-8-1

From the client hosts perspective, we observe sudden spikes in the DNS traffic to the Kelihos domains, as it is shown below for gyvolnac[.]ru on the screenshot of our Sgraph investigative platform interface (we will soon be sharing Sgraph with the security community to use it). Analyzing changes in traffic patterns is one of the techniques we use in our labs to detect new malicious domains.

kelihos-sgraph-snapshot3 

This third emergence of Kelihos after recent takedowns highlights the difficulty of eliminating the botnet threat altogether. Umbrella Security Labs is a big advocate of tighter collaboration within the security community and the legal system to fight botnets. We also encourage our customers and Internet users in general to be aware of current online threats and make sure they take all precautions in protecting their sensitive data and assets by adopting the right technology and online behavior. 

We’re presenting a webcast on Feb. 20 on how Big Data is transforming Internet security. If you’d like to learn more about the methods we use for threat discovery, please join us

This post is categorized in: