Akamai Diversity
Home > Web Security > Cloudification of Web DDoS Attacks

Cloudification of Web DDoS Attacks

Recent studies and reports show a dramatic increase in the prevalence of denial of service attacks in general, and application layer attacks in particular. As a result of this increase, DoS protection and mitigation solutions have evolved both on the technological side as well as in their ability to scale and protect against larger and more distributed attacks (DDoS).
It goes without saying that the technological evolution did not skip the hackers, who developed new techniques and tools to generate significantly larger attack volumes and maximize their available resources. In this post we will analyze unique data that was collected from Akamai's big data platform, showing an up-and-coming approach to application-layer denial of service attacks, in which attackers share a single attack tool, similar to a cloud-based service, while abusing internet proxy-infrastructures to hide their true identities and remain undetected.

Technical overview

The subject of analysis in this post is the notorious Web based DoS tool "WebHive LOIC". This tool is a single-page web application that once uploaded to a hosting web server can be used by anyone with a browser to conduct HTTP flood attacks. Upon visiting the WebHive LOIC application's URL, the user is requested to enter a target site and perform a few simple configurations. Once the user clicks on the "Start Attack" button, JavaScript code that runs in the user's browser starts flooding the target web application with simple HTTP requests. Each request carries a randomized payload in order to avoid being answered by intermediary devices such as caching proxies or naïve DoS protection solutions.

Or Katz 4-15 - 1.jpg
A sample WebHive Loic Interface

The easiness and simplicity of WebHIVE LOIC attacks practically commoditized denial of service attacks - any given internet-connected device with an embedded browser can now take part in a denial of service attack campaign, without the need to download any dedicated software.

Attack Analysis

As part of Akamai's continuous effort to secure our customers' digital properties, we regularly monitor the usage patterns of WebHive LOIC across Akamai's customer base. Let's take a look at the traffic statistics of a large Akamai customer that was recently heavily targeted by WebHive LOIC based attacks.

Attack Volume:

Looking at a one-month period, we see an on-going effort of overloading the application with HTTP traffic:

Or Katz 4-15 -2.jpg
Attack Sources:

By looking at the 'Referer' header of each attack request, we can pinpoint the source WebHive LOIC applications that were used in order to perform these denial of service attacks - this data revealed as many as 51(!) different WebHive LOIC sources, such as those listed below:

  • http://www.tgi.co.id/loic.php
  • http://newbie005.w.pw/
  • http://gdr.zat.su/index.html?8401

When looking at the URLs of the 51 WebHive LOIC applications, we observed the following distribution by top-level domain:

Or Katz 4-15 -3.jpg
Who is Behind This?

Since WebHive LOIC attacks originate from the attacker's browser, the attacker's IP address is exposed. Over the period of one-month, DoS attacks targeting a single Akamai customer, originated from 234 different IP addresses. Further analysis into the source IP GEO location data shows that most of the attacks were initiated from the US, Indonesia and Iceland.

Or Katz 4-15 -4.jpg
Figure 1 - Attackers Source Distribution by Country

234 source IP addresses is a surprisingly low number when considering the duration of the collected data (one month), further analysis into the data revealed that out of the 234 IPs, 136 were web proxies - this explains the low number of source IPs - attackers are using web proxies to hide their true identity. In order to understand the nature of these web proxies, we analyzed the domain (WHOIS) information as well as certain HTTP headers and discovered that 77% of all WebHive LOIC attack traffic came from behind Opera Mini proxy servers.

Opera mini is a cloud-based browser, which redirects the traffic from the mobile browser through one of Opera's proxy servers. Previous research on how to abuse such services was already published and our findings show that hackers are in fact using these techniques.

From the data we can also detect minor activity of attackers that use similar methodology by abusing the Nokia Xpress cloud browser service.

The exploitation of web proxies by attackers creates a challenge to security operations teams:

  • Should organizations block traffic coming from HTTP proxies, based on evidence of a Denial of Service activity?
  • Should organizations take a risk of blocking traffic arriving from proxy servers and by doing so perhaps block legitimate users coming from the same proxies?
  • What if these proxies belong to a network of load balancing proxies? Should the entire proxy network be blocked? 

Who is hiding behind the curtain?

In order to gain better insight into the identity and origin of the attackers that were exploiting Opera Mini proxy servers, we analyzed certain HTTP attributes, one of which is the attackers' source IP address, which appears in the 'X-Forwarded-For' HTTP header. This revealed a substantial discrepancy in the source country distribution - in the new data we saw that the dominant source country of attack is actually Indonesia. While hackers who control the Proxy server can spoof this header - this was not the case here, since Opera's proxy server, which we consider to be trustworthy, inserted this header into the traffic.

Or Katz 4-15 - 5.jpg
Figure 2 - True Attackers Source Distribution by Country

Based on this new evidence, we can get a sense of the level of sophistication being applied in such attacks - attackers are exploiting cloud-based browsing platforms to mask their origin and take advantage of the distribution and high-scale of the platform for carrying out large-scale attacks. Moreover, the fact that most attacks originated from the same geographical location imply that the attacker behind this activity is a single individual or a small group of individuals sharing a similar agenda.

From Security Intelligence to Actionable Defense

Based on the data in this analysis, the following countermeasures should to be considered:

  1. Analyze HTTP 'X-Forwared-For' header (from trusted sources) - extract the source IP from X-Forward-For headers in order to block attackers' source IP addresses
  2. Protect your applications - 
a. Add appropriate WAF rules that will detect and block relevant Web-based DoS tools
b. Add appropriate WAF rules that will block HTTP requests originating from known web-based DoS applications (based on the 'Referer' header)
c. Apply rate control protection to avoid flood attacks on your application
3. If your organization owns proxy servers or open proxy infrastructure - you should protect it from being exploited to route malicious attack traffic

Ory Segal, Director of Threat Research, also contributed to this blog post

1 Comment

I am not aware of DDoS attacks, I have knowledge of proxies, spoofing and spamming and Dedicated Proxies attack. My college gives me topics of DDoS attacks and searching a lot on net but finally, i found something which helps me a lot for working on my project. keep updating and keep sharing.

Leave a comment