Darkleech + Bitly.com = Insightful Statistics

This post is about how hackers abuse popular web services, and how this helps security researchers obtain interesting statistics about malware attacks.

We, at Sucuri, work with infected websites every day. While we see some particular infections on one site or on multiple sites, we can’t accurately tell how many more sites out there are infected, and how many people were exposed to that malware. All we can do is estimate.

Most estimations are based on data that can’t provide the whole picture such as number of detections in our SiteCheck scanner, number of cleanup requests, number of posts about a particular problem in webmaster forums. This only helps to tell whether it’s something “major” or “minor”.

Like any other firm out there, sometimes we can make some good educated estimates. For example, we can target specific Google searches that reveal the number of sites that contain some text, or URL specific to a particular attack. Another example is if an attack uses one specific URL (or a few well known URLs), then Google Safe Browsing reports also help estimate number of infected sites. These Google-based approaches are more precise, but they don’t work for most attacks that frequently change domains and have no artifacts that can be found in search results.

If security researchers are quite lucky, they might find an attacker’s unprotected (or poorly protected) Control Panel that contains all the statistics about infected site, clicks, exploits, etc.

This post will be about a different and quite unusual way of obtaining data about activity of a server-level attack that is known for being hard to detect and track.

What is Darkleech?

Just a quick recap. Darkleech is a malware that hackers install in a form of malicious web server modules. Usually Apache, but there is evidence of similar malware on nGinx and Litespeed on compromised servers. The servers are compromised at a root level, and in most cases hackers also replace all SSH binaries with their own versions that contain backdoors. This allows the hackers access to such servers even if the server owner changes root passwords.

The rogue web server modules analyze HTTP traffic and inject malicious code into legitimate server responses.

This sort of server infection is usually hard to detect as it lurks when server admins log in, or site admins work in admin areas of their sites. Moreover, the malware is only injected to visitors that come from search engines and this happens only once a day for such eligible visitors. As a result, it’s also hard to make any estimations on the number of infected servers and number of attacked web surfers (assuming the selectivity of injections).

This malware has been public since at least the summer of 2012, and the malicious code that it injects remains quite recognizable.

This sample is from July of 2012.

.um6x1zsq { position:absolute; left:-1241px; top:-1283px}
<div class=”um6x1zsq“><ifr ame src=”hxxp://megaworlsnetscapes .info/?a=YWZmaWQ9MDUyODg=” width=”120” height=”300“>

This is from January of 2013:

<style<.t1nhuhjv { position:absolute; left:-1619px; top:-1270px}
<div class=”t1nhuhjv”><i fra me src=”httx:////” width=”534″ height=”556″>

You see the pattern? A style definition with an auto-generated random name and off the screen absolute position, followed by a

containing that very style, and an iFrame inside that

. The iFrame has normal visible dimensions but the style makes it rendered far off the screen so visitors have no chance to see it.

January 2014 Modification

Now the most interesting part that made this post possible. In January-February of 2014, Darkleech injects this code:

.jasz8u72u { position:absolute; left:-1851px; top:-1816px}

<i fr ame src=”hxxp://bitly.com/MlrZaD” width=”317″ height=”589″>

Here is the VirusTotal analysis of the .so file that does it.

Looks the same. But you’ll notice that now it uses shortened bitly.com links in the iFrames. Bitly (aka Bit.ly), is a very popular service that many sites and people use every day. The challenge is that Bitly links can efficiently disguise suspicious URLs that could otherwise trigger malware alarms.

Bitly Link Statistics

The flip side of using Bitly links is bitly.com provides public statistics for every shortened link:

All you need to do to get that information is to add “+” to a Bitly link.

For example, here is the link to the information on the Bitly.com link with ID 1hU6w3H that was also used in the attack: http://bitly.com/1hU6w3H+. Sorry, after my request, Bitly.com blocked the links, so most likely you won’t see anything there now. Don’t worry however, I saved a lot of interesting data and will share it here.

What we can see for this link is:

41 clicks — doesn’t look impressive for a serious attack, does it? But wait, it’s just one link. And the attack frequently changes them. How frequently? Bitly.com has this information too, and I’ll show it below.

Username: Grantdad

At this point, the most important part of this data is the username: grantdad. We can check his statistics too: http://bitly.com/u/grantdad (Already suspended)

bitly_grantdad

What we can see here is:

Is this all the information, is there more data?

In short, there is more data. The longer answer is Bitly.com limits number of displayed links per account to 10,000. Moreover, these 10K are not continuous. I can see links from January 25th, January 28th, and the latest February links. At this point, we can only guess how many links may have been created by this user, and when he began doing it.

On January 25th or earlier (actually, in our SiteCheck logs we found detections of these Bitly.com iFrames from Dec 16th, 2013, and up to the beginning of this February, and the Bitly API confirms that they all were created by the grantdad Bitly user. Still we have enough data to make some estimations.

One more useful feature of Bitly is their API that allowed me to download and analyze a lot of data on more than 10,000 malicious Bitly URLs that the Darkleech used during late January and beginning of February. The earliest Bitly data I have is from January 25th, and Bitly was not cooperative in providing more information about activity of the grantdad account.

Get Ready For The Stats

If you want to analyze the data yourself you can find links to the raw data in this post.

Number of created malicious bitly URLs

(Total 30.5 hours of the tracked attack activity)

This give us the following averages:

Given the attack was continuous, we can extrapolate this data to the period of the confirmed attack activity. The period of attack was (January 25th – February 5th), which gives us 110,000+ malicious Bitly.com links. If we extrapolate it even further, going back to a period beginning on Dec 16th (assuming it was as active from the very beginning), we’re looking at almost half a million malicious Bitly links!

Iframe loads

During the tracked periods (30.5 hours overall), there were 87,000+ “clicks” on the Bitly.com links. Based on our analysis, this means there were 87,000+ malicious iFrame loads.

Averages and Highlights:

Lets again extrapolate this to the whole period of January 25th – February 5th: 800,000+ iFrame loads during those 12 days, and about 3.5 million iFrame loads during the extended period dating back to December 16th.

Infected Servers and Domains

During the tracked 30.5 hours, 575 unique domain names were registered as “referrers” of the Bitly “clicks”. In our context, this means the malicious iFrames were loaded from sites on those 575 domains, including subdomains and IP addresses.

Those 575 domains are hosted on servers with 303 unique IP addresses (30+ domains didn’t resolve at the time when I checked them).

Raw data before removing direct clicks, proxies and translation services: http://pastebin.com/HYaY2yMb (iFrame loads per referring domains)

IP’s and domains infected with the Darkleech : http://pastebin.com/Gxr51Nc1(during the time for which we have Bitly data. Some of them have been cleaned up already)

Averages and highlights:

Countries

During the tracked 30.5 hours the malicious iFrames have been loaded by web surfers in 196 countries: http://pastebin.com/SZJMw3vx

Highlights:

iframes-per-country

IFrame Load Geo-Distribution

iframe-load-geo-distribution

No-IP.com URLs

Each short Bitly link points to a unique long URL on multiple subdomains of myftp.biz, myftp.org and serveftp.com. No-IP.com provides such domains as a part of their free Dynamic DNS service. As I said earlier, they all resolve to 69.64.39.166, an IP of Hosting Solutions International Inc.

While all the long URLs are unique, many of them share the same subdomains, for example:

hxxp://ivgrbj .serveftp .com/dm0rz7xwkphigpuvwr4nhd01xewty2avsax0qra9clnmdo0
hxxp://ivgrbj .serveftp .com/jsgpzpnxnwepoph3yiu5f0dlzghrxf
hxxp://ivgrbj .serveftp .com/haxveodmyzoff64mpjbq90ztsyxxay4cytte

Overall, during those 30.5 hours, Bitly registered links to 202 unique No-IP subdomains: http://pastebin.com/QP9TrPbV, with an average of 58 unique URLs per subdomain.

Attack Disruption

As you can see, the attackers choice of Bitly.com helped us dig up quite a lot of data about the attack scale. Another outcome of this choice was the ease of disruption of this attack. Once we downloaded all the interesting data, we contacted both Bitly.com and no-ip.com, within hours they blocked the offending accounts. Old links still work, but you can’t get any information about them when you add “+“, and the grantdad account page says “Forbidden”. As far as I can tell, grantdad can no longer create short links. As a result, I no longer see malicious iFrames on the known infected servers. I’m sure it’s a temporary disruption, but as our statistics show, every day of inactivity prevents about 68,000 malicious iframe loads ;-)

Update: On February 6th, I began to detect iFrames with bitly.com URL’s again.

https://bitly.com/1nWQpGj+

https://bitly.com/1ln3Osp+

But now Bitly flags them as “potentially problematic”. When you try to open them you get this warning from Bitly:

bitly-warning

While Bitly’s website doesn’t show user information for these new links, using their API I can see that they were created by the same grantdad user. Nonetheless, now Bitly does a good job identifying them as dangerous, which effectively prevents loading of the malicious content in hidden iFrames, where web surfers have even no chance to click the “continue at your own risk” link in the warning.

Unfortunately, both Bitly and No-IP ignored my requests for additional information about the activity of the malicious accounts. This information could help us better understand when Darkleech really began to use Bitly.com links, and have a more accurate picture of how active it was during all that time. I can only hope, if and Bitly or No-IP employees come across this post, they share some information in comments.

Via Sucuri.net

Tags: , ,

No comments yet.

Leave a Reply