Hackers Launch Sophisticated DDoS Attacks Using Serverless Computing

The growing popularity of serverless computing has not gone unnoticed by hackers, who have begun using such infrastructures for launching DDoS attacks.

Radware recently stopped a large-scale web DDoS attack, which was launched using serverless service workers. It’s another example of the growing sophistication and audacity of attackers. This attack also demonstrates the potential for attackers in utilizing serverless computing to launch large-scale DDoS attacks, and the risks they pose.

A Prolonged, Large-Scale Attack

On Friday, April 21^st, Radware detected a large-scale volumetric HTTPS GET flood directed at one of our Cloud Application Protection customers. The customer is an international communications service provider, and the attack targeted their user management portal.

It was a prolonged attack, lasting from Friday, April 21^st until Sunday, April 23^rd. Attackers frequently launch attacks on weekends, trying to take advantage of smaller staff numbers and less attention. However, this customer was protected by Radware’s Cloud Application Protection, so Radware’s Emergency Response Team (ERT) was on standby and provided immediate 24/7 assistance.  

Over the course of 3 days, the customer was hit with four major waves of attacks, some of them lasting several hours and each peaking at over 110K requests per second (RPS) and reaching as high as 140K RPS:

• 1^st Wave: April 21, peaking at 120K RPS
• 2^nd Wave: April 22 (noon), peaking at 110K RPS
• 3^rd Wave: April 22 (afternoon), peaking at 140K RPS
• 4^th Wave: April 22-23 (midnight), peaking at 130K RPS

Figure 1: The first attack wave from April 21, which peaked at over 122K requests per second (RPS)

Figure 2: The attack waves from April 22 and April 23, which peaked at over 140K requests per second (RPS)

While DDoS attacks are commonly measured in the amount of throughput (typically Megabits/Gigabits/Terabits per second), another important measure – particularly for application layer attacks – is the number of requests per second (RPS). Although Radware has seen (and mitigated) attacks several times larger than this one, attacks peaking at 140K RPS (and over a sustained time period) are still very sizable attacks that can easily overwhelm most application servers.

Serverless Workers Serving DDoS Attacks

Another unique characteristic of this attack is that it didn’t originate from a botnet, but by serverless scripts running from a public infrastructure. In this case, the serverless scripts were based on Cloudflare Workers.

Radware observed large numbers of requests originating from IP ranges and subnets associated with Cloudflare Workers. In this case, they originated from Cloudflare ASN (AS13335). The requests were highly distributed within those subnets, so it was impossible to identify specific IPs from which the attack originated.  

Additionally, the requests originated from multiple geographies, including the US, Australia and Ukraine, which made any type of geo-based blocking impossible.

The HTTPS GET Flood also used randomized URL parameters, so no two requests were identical. Also, the dynamic structure of the request meant it would not be cached by the customer’s CDN, but go directly to the web application’s origin server.

These parameters created multiple challenges that traditional DDoS mitigation methods couldn’t address.

Traditional Mitigation Methods Wouldn’t Have Been Sufficient

Apart from the novelty of using serverless scripts to generate the attack, the attack attributes made it particularly difficult to characterize. As a result, traditional DDoS mitigation approaches and tools would have been useless in this case.

• Access Control Lists (ACLs) are useful when the attack is coming from a single source or a small number of known sources/IPs. In this case, however, the requests were widely distributed across large numbers of IPs, and across multiple IP ranges, of a large internet infrastructure. So, blocking those sources using fixed access control lists would not be possible due to the large number of sources. And because the traffic was coming through a large, well-known public infrastructure, blocking those IP addresses could have resulted in the blocking of legitimate traffic coming through those IPs or blocking legitimate services by using the Cloudflare Workers platform.
• Geo-blocking would be problematic because the traffic originated from multiple countries (including the United States), so any type of geo-blocking would have been ineffective because it would have blocked out large portions of the world. And as a globally-distributed service provider, it wouldn’t work for the customer because it would block out large numbers of legitimate customers.
• Rate limits are popular with some DDoS mitigation services as a means of limiting the number of requests — good or bad — reaching the application. A significant downside of this approach is that it does not distinguish between good and bad connections. This means that legitimate transactions are also blocked, leading to high rates of false positives. In a massive attack like this one, where malicious requests vastly outnumbered the number of legitimate connects, rate limiting would have prevented legitimate traffic from reaching the application. As a result, the attackers would have achieved their objective.
• Fixed signatures/rules wouldn’t have stopped this attack because of the complex structure of the custom GET requests and the dynamic, randomized parameters that were used. So, pre-existing, static signatures would not have been enough to either identify the attack patterns or distinguish between malicious and legitimate traffic.

This is exactly where Radware’s automated web DDoS mitigation technologies came into play and mitigated this attack.

Automation and Expertise Make the Difference

Radware successfully mitigated the attack using a combination of its automated DDoS protection algorithms with the expertise of Radware’s Emergency Response Team (ERT) .

Once the traffic reached Radware’s network, the high volumes of requests were identified and characterized as malicious traffic and blocked, but the legitimate user traffic continued to the application, and with no interruptions.

Radware’s ERT experts then drilled down into the characteristics of the attack and the attributes of attack packets to identify common traits. Once that was done, custom signatures were put in place, which dropped all attack packets as they came into the Radware network, finally ending the attack.

Summary

To mitigate automated offensive cybersecurity activity, organizations must deploy defensive automation capabilities.

Radware provides protection against Web DDoS Tsunami attacks using behavioral-based detection and real-time signature creation, which adapts defense signatures to the specific parameters of the attack. This allows for creating attack signatures that are IP agnostic (i.e., they don’t rely on the origin of the attack traffic) and rapid adaption to changing attack patterns.

Radware’s automated Web DDoS protections are greatly augmented and enhanced by the expertise of Radware’s Emergency Response Team (ERT), one of the industry’s largest and most experienced security teams. Radware’s ERT staff work daily on DDoS and application attacks; they have tremendous experience dealing with sophisticated and unknown attacks.

Both were showcased over the course of this incident, as Radware successfully protected its customer against a massive, prolonged and complex DDoS attack.

For more information about how Radware can protect your organization from cyber-attacks, reach out to our cybersecurity professionals here. They would love to hear from you.