Akamai Diversity
Home > Web Security > A Two Week Overview of the Latest Massive Scale RFI Scanning

A Two Week Overview of the Latest Massive Scale RFI Scanning

In the past several weeks, Akamai was in a unique position to witness a massively orchestrated attack, designed to map Internet facing web servers that are susceptible to certain specific vulnerabilities.
While various sources on the blogosphere speculated about the scale and nature of these attacks seen on their own infrastructure, Akamai's big data intelligence platform demonstrated the true massive scale and reach of this internet-wide orchestrated attack.

In order to thoroughly analyze this attack and bring you our conclusions and impressions, we extracted attack data on the last 2 weeks (January 5th - January 19th, 2014) from Akamai's security big data platform (Cloud Security Intelligence).

Here are our findings:

Detailed Findings:

During our analysis period, Akamai has seen a total of 2,071,089 Remote File Inclusion attack attempts, targeting mostly PHP applications. The following chart depicts the distribution of attacks per hour:

Blog3.001.png
Our data shows that at its peak during the past 2 weeks, 80,000 attacks were launched per hour. It is also quite obvious that attack volume has subsided gradually, and perhaps the attack is about to end.

Another supporting evidence that this attack might be reaching its end these days, is the slow and steady decrease in the number of attacking sources (IP addresses) seen every hour: 

Blog3.002.png
In total, Akamai has seen 237 unique attackers during the 2-week period, with the majority of attacks originating in the United States (see chart below).

Blog3.003.png

In addition to the above, we saw that the most "active" attacker performed attacks against 86 different web sites, and sent a total of 73,515 attacks. The average number of attacked sites per attacker was 10 sites/attacker, while the average attacks per attacker stood on 8738 attacks/attacker.

When inspecting closely the top attack source IPs, we discovered that most of them were running on a web server, and seemed to belong to web hosting providers running the cPanel management application. Using web servers for launching massive scale attacks on the web is definitely becoming the de-facto approach for hackers who are looking for high bandwidth.

Depending on the attacker and target application, the attack itself seemed to look for 2,000 - 2,500 different known Remote File Inclusion attacks, mostly in PHP applications. Our data also shows that when the web server failed to respond according to the scanner's expected behavior (e.g. HTTP authentication was required, or an HTTP 5XX error was raised), scanning activity stopped after only a few attempts.

Let's move on to look at the target sites - during the 2-week period, a total of 1,803 web sites were attacked, and the chart below, which shows the number of target sites attacked per day, clearly demonstrates again, that the attack is subsiding:

Blog3.004.png
While we can't expose the names and industry sectors of the target sites, it's clear from the top-level domains of the sites, that attackers were not only interested in .com web sites, but also targeted government and military web properties.

Blog3.005.png
Of the 2,071,089 attacks registered during our sample period, more than 99% of HTTP requests were extremely basic and were stripped down of almost all HTTP headers except the mandatory 'Host' header - this leads us to believe that a very rudimentary script performed the attacks, since sophisticated scanners usually perform more deep crawling and usually support cookie-setting, session token refresh and will submit more headers in order to mimic browser web interaction.

The attacks sent by the script used the following HTTP request format - 

GET /page.php?param=http://www.google.com/humans.txt HTTP/1.0
Host: www.target.site


Where '/page.php' represents one of the 2,000 - 2,500 unique attack paths and 'param' represents the name of the injected parameter. As noted in earlier blog posts, the injected resource location always points to a known file on Google.com - this might be an attempt to bypass web application firewalls and anti-malware protections.

Our data shows that each scanning instance did not concurrently scan multiple target hosts but rather focused on a single target and then went on to the next. This behavior might be driven by the attack orchestrator's desire to "stay under the radar" and to avoid drawing the attention of the legitimate owner of each web server used for running the attacks. It may also hint on the unsophisticated nature of the script itself.

In addition, based on the fact that the same target hosts were scanned multiple times by different attack sources, at different times, we conclude that different scanning instances (i.e the bots in the botnet) were not well synchronized, or even not synchronized at all.

Looking at a sample of the top-attacking sources, we did not find any other kind of activity such as reconnaissance gathering or site crawling/indexing from these sources in the past month. We therefore conclude that the scanning activity was performed by dedicated machines that were operated for the sole purpose of massively scanning for PHP Remote File Inclusion vulnerabilities

The vulnerabilities being searched for included both known issues that were recently published as well as issues that were reported many years ago - for example, the 'In-Link ADODB Remote File Inclusion' (http://www.exploit-db.com/exploits/2295/), which was published back in 2006. This, in conjunction with the tremendous scale of the attack, clearly points that this was a crude brute-force attempt to massively harvest any kind of server for the purpose of building a bot network by breaking into as many machines as possible, in a short period of time.

Time will tell when and how the detected vulnerabilities will be exploited. We believe Akamai's Kona Site defender, alongside our big data intelligence platform, which holds Internet-wide visibility, will continue to be in the unique position to detect and help mitigate such attacks better than any on-premise, local protection mechanism.


Leave a comment