Previously, we discussed how we regularly monitor our DNS traffic for malicious fast flux domains. One notable family of fast flux domains that we see every day are the “Kelihos” domains: A steady stream of DGA-like .ru domains (occasionally .com or .us), freshly registered, resolving to a single IP with a TTL of zero, and whose name servers are also fluxing with a TTL of zero. These domains have been covered numerous times recently [3] and been the subject of multiple takedowns [5], but despite this publicity and efforts, their malicious usage has not abated.
We observe that these domains are used for at least three purposes: as redirectors for Blackhole and Red kit exploit kits, as malware dropping domains for diverse trojan specimens (mainly the Kelihos trojan), and as CnC, appearing in the network traffic of trojan samples already installed on infected machines.
In this blog post, we’ll take a look at a few such domains from our perspective, show how they serve multiple purposes, and describe a few live cases of their malicious usage. Notice that all domains mentioned in bold in the tables are live at the time of this writing.
Domains’ activity in trojans’ traffic:
In the table below, we show a sample of recent .ru domains that were reported in the network communications of known trojans. We detect these domains in our DNS traffic either a few days before or on the same day that a related malware analysis report is published. Notice, the last two domains registered on July 11th stayed dormant for about 10 days, then started being DNS-active and were reported in samples’ reports. As of this moment, they are no longer resolving.
Domains’ usage as trojan downloaders:
We now show a sample of domains used as Kelihos payload downloaders via exploit kit infections. At the time of this writing, these domains are live, as are the payload URLs.
Domains’ usage in Iframe injections:
In the following table, we inspect another sample of “Kelihos” domains. These domains are used as Exploit redirectors in hidden iframe injection attacks against the listed web pages. At the time of this writing, many of these web pages are still compromised (several may have been cleaned or no longer resolve, or their Exploit landing domains may have stopped resolving). This list is just a small set for illustration purposes as we counted tens of such infected “innocent” sites still live (a number expected to reach the hundreds), with more systematically infected every day. The last domain of the table has been suspended, but we are showing it as we will discuss it in a following example.
Commonly, multiple pages of a website are infected simultaneously – and some webpages have the same iframe injection block replicated several times across the page (likely to maximize the chance that the malicious javascript is executed when the page loads). These blocks point to one specific exploit landing domain, although they could also point to several different domains. Moreover, on the same compromised page, the redirection url changes from one visit to another.
Let’s take the example of hxxp://cimplerd.com/essie/. On this page’s source code, we observe some legitimate javascript loading code at the top, followed by a large number of white spaces that the attacker most likely injected as a “simplistic” obfuscation ploy – so that if a human tries to hastily inspect the source code, the malicious code following the white spaces does not show in the screen window.
Following the white spaces, there are two iframe injection blocks that redirect to hxxp://abmisgaz.ru/count2.php and hxxp://ycsycxyd.ru/count29.php. These iframe injection blocks also feature the CookieBomb attack that we will discuss in the next section. The second block injection attempt failed though, as it appears truncated in the webpage screenshot. Notice also how the injected javascript blocks are not obfuscated.
Cookie bomb/iframe injection attack example:
By checking the compromised pages, we observed that most of the iframe injection attacks are actually “CookieBomb” javascript attacks. The “CookieBomb” attack is a recent twist on the hidden iframe injection, where the ensuing redirection or infection is made conditional upon the possession of a cookie. MalwareMustDie first described it in a fantastic article, also providing a PoC [8][9].
Briefly, the idea is that if you enabled cookies in your browser and you visit a compromised site, the injected javascript will check if you hold a certain cookie – and will create one for you if you don’t. Subsequently, the .php code on the landing page will check for the cookie, and depending on what the attacker set the php up to do, it could further redirect you to another site, or drop the malware right onto your machine, etc. In the image below, we can see an example of a CookieBomb code block:
We also observed that some webpages were infected multiple times with this attack; for example, hxxp://www.scouts108.org.mx/index.php had 9 injected exploit redirection/CookieBomb code blocks (with 9 redirection URLs) scattered across the page. These blocks pointed to 3 distinct exploit redirection URLs overall. The URLs at the time of analysis were:
hxxp://ycsycxyd.ru/count29.php
hxxp://ycsycxyd.ru/count29.php
hxxp://jibnikek.ru/count29.php
hxxp://zofbeqve.ru/count2.php
hxxp://jibnikek.ru/count29.php
hxxp://ycsycxyd.ru/count29.php
hxxp://ycsycxyd.ru/count29.php
hxxp://ycsycxyd.ru/count29.php
hxxp://jibnikek.ru/count29.php
This could likely be the result of an automated script maliciously loaded on the hosting server that attempts to infect, in bulk, as many websites (and webpages) as possible that are hosted on the same server. However, this mass infection of web pages can be counterproductive for the bad guys (and good for us) as the injected javascript often fails to properly load and does not lead to the final drive-by malware download.
We also noticed that compromised websites are multi-national, observing websites from Mexico, Peru, Russia, Poland, Turkey, India, and Thailand, etc. This could indicate that the bad guys target their “iframe injection” infections against sites in bulk, regardless of their origin, where these sites could have vulnerabilities in their web server setup, or whose administrative FTP credentials were leaked or purchased, etc. The end goal here is to infect as many user machines as possible and harvest the most accounts and personal data. Obviously, the attacks could also be targeted against a specific population or a business group.
Dual purpose domains:
We also observed that a lot of “Kelihos” domains are recycled for multiple uses: exploit redirectors and trojan droppers among them. Let’s take the example of powerwik.ru. At the time of this writing, this domain has been used as exploit redirector: hxxp://powerwik.ru/count3.php injected for example in this site http://www.bth-avocats.com/, and as a kelihos payload downloader with the following URLs: hxxp://powerwik.ru/userid2.exe, and hxxp://powerwik.ru/rasta01.exe. Below are the virustotal analysis reports of these two payloads:
The geography of the infections:
We will now discuss an interesting observation related to the geography of the client IPs querying Kelihos domains as we see it from our DNS traffic. Let’s take the example of afau.gajkukuc.ru: this domain shows a surge in DNS traffic between 10pm and 12am UTC on the night of July 24th.
We checked the client IPs that looked up this domain, and display their country distribution in the map below. Notice the high concentration of clients in Turkey (next are the US, Canada and Mexico). We speculate that either users in Turkey were targeted by a spam campaign leading to afau.gajkukuc.ru (as an Exploit redirector or payload downloader), or that several Turkish speaking websites were compromised with iframe injections also leading to afau.gajkukuc.ru.
[load-javascript slug=”kelihos-clients-ips-map”]
We observe this behavior with other domains, for example: ca595.ximxamli.ru. This domain shows a spike of DNS queries between 6 and 8am UTC on July 24th from client IPs highly concentrated in Vietnam and Turkey.
Multi-layer evasion:
To summarize, we observe that the attackers use randomness at several levels to evade detection and blocklisting:
1. The redirection URL changes between consecutive visits to the same compromised page.
2. The domain names (2LD) are randomly generated, as are the subdomain names (3LD).
3. The domains resolve to a single IP with a TTL=0, this in itself tries to simulate a random DNS resolution. We monitor the total number of unique IPs, and can confirm this number is continuously growing.
4. The “Kelihos” domains are wildcard domains. If you try to resolve a hostname formed by prepending a random string to the domain name, you will get a successful resolution. This seems like an artifact that serves the random generation of subdomains. We presume that the automated script installed on an infected server uses this artifact to generate new random Exploit landing urls, (i.e. the targets of the iframe injection blocks) or payload downloading URLs.
