You are here:Home›Security›Darkleech + Bitly.com = Insightful Statistics
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.
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:
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+. 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.
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.
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 126.96.36.199 (Hosting Solutions International Inc.)
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.
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!
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 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).
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
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 188.8.131.52, an IP of Hosting Solutions International Inc.
While all the long URLs are unique, many of them share the same subdomains, for example:
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.
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.
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.