Salt Customer Attack Case Study: Blocking a Low-rate-per-bot HTTP DDoS Attack

What is an HTTP DDoS Attack?

An HTTP DDoS attack is a malicious attempt to overwhelm the resources of a web service, or an in-line network intermediary device, to prevent it from serving legitimate requests from legitimate users. Bad actors launch these attacks leveraging a large group of devices, called a botnet, so they can send a high rate of requests and thereby create a debilitating load on them.

The amplitude of an attack is measured by the total request rate received by the victim web service. This rate is a result of the size of the botnet and the malicious request rate from each one of its bots.

Each malicious request may look legitimate, or at least might not match a typical web application attack. Differentiating the malicious requests from legitimate ones to detect an HTTP DDoS attack can usually be done by:

• Rate limiting the number of requests from each source client.
• Fingerprinting source clients to differentiate malicious from legitimate ones.
• Using pre-defined signatures included in some WAFs.

Detection and Mitigation for APIs

Fingerprinting source clients to differentiate malicious from legitimate traffic can be done using web challenges, triggered by the attacked web service itself or a WAF. Incriminated clients can then be blocked. These web challenges can include:

• JavaScript Challenge — Presenting a JS script to a web client. A browser of a legitimate user can render it and return its output easily, while a client that doesn’t have a JavaScript rendering capability is incriminated.
• 302 Redirect Challenge — The web service or the WAF redirects the web client to another page. A browser of a legitimate user is redirected and renews its requests successfully, while a client without a full HTTP stack implemented keeps sending the original request over and over and, as a result, is incriminated.
• Cookie Challenge — The web service or the WAF sends a cookie to the web service as part of a response. A browser of a legitimate user returns it in its next request while a client which doesn’t have a full HTTP stack implemented does not and, as a result, is incriminated.
• CAPTCHA — The web service or the WAF asks the user to insert specific info. Only humans can understand its format — programs cannot — so a legitimate user can continue browsing while automated tools are eliminated.

These challenges can stop basic malicious automated tools that lack a JavaScript rendering capability and a full HTTP stack implementation. However, web challenges cannot defend against advanced automated tools that include those capabilities.

In addition, web challenges cannot be used to protect application programming interfaces (APIs) — the ubiquitous interface for machine-to-machine communications. APIs serve dedicated clients which typically lack JavaScript rendering as well as a full HTTP stack implementation. In this case, web challenges will also block legitimate clients. This shortcoming leaves request rate-limiting and pre-defined signatures as the only mitigation methods available for protection.

The Low-rate-per-bot Attack Approach

The problem is bad actors have figured out that traditional tooling can recognize these automated, high-rate attacks, and they’ve adjusted their method of attack. To avoid detection by traditional security tools, bad actors slow down their rate of attack, staying below the rate-limiting thresholds. But if they reduce the speed of attacks, how can they still compromise the web service? The answer is simple math. They reduce the request-sending rate of any given single bot, to keep them undetected, but they add more and more bots. As a result, the total request rate into the web service remains high — high enough to compromise service availability.

Customer Case Study — Blocking an In-the-Wild Attack

So what’s a company to do? How can you protect yourself from these increasingly sophisticated API attacks? You need technology that can stitch together the traffic patterns of seemingly disconnected “users” to spot this kind of attack. Today’s WAFs, while more intelligent than their peers of 20 years ago, still see transactions and “users” in isolation and cannot see such patterns in aggregate and over time.

To thwart this kind of attack, you need perspective — or context — across a longer timeframe and across 100s of “users” and API interactions. That’s what the Salt platform does.

WAFs can track the number of requests from a client in timeframes of seconds and minutes, whereas the Salt Security API Protection Platform tracks client requests over much longer and more diverse timeframes and durations. With its cloud-scale big data platform and artificial intelligence (AI) and machine learning (ML) algorithms, Salt can easily identify requests that differ from legitimate requests. This dynamic anomaly detection empowers users to quickly spot malicious low-rate requests with a very low rate of false positives.

A few weeks ago, a Salt Security customer notified our SOC Group that one of the company’s web services was being exhausted by an unknown threat. At the same time, the Salt platform detected high inbound traffic. Using the Salt platform, our analysts detected an HTTP DDoS attack against an authentication (aka login) endpoint launched by a botnet that included thousands of bots. Because each individual bot would send only one request a minute, the cloud WAF deemed the traffic legitimate and let it pass through. As a consequence of the cumulative load, however, legitimate users could not authenticate to the web service. The Salt API discovery algorithms also immediately detected the following anomaly — that the malicious requests missed required payload fields. The web service responded to those invalid requests with 400 Bad Request response code, and the Salt platform detected it as an abnormal response code from this API endpoint, which helped further differentiate the bot traffic from legitimate authentication attempts.

Our analysts reported these findings back to the customer’s security engineers, and they activated an already defined integration between Salt and the cloud WAF to block the source IPs of the entire botnet. With this automated blocking in place, the load on the web service dropped significantly, and legitimate users were able to authenticate once again.

Automated or Manual Blocking — the Customer’s Choice

Salt customers have the choice to enable automated or manual blocking when the Salt platform detects an attack. Customers tend to start with manual blocking, giving them the chance to investigate the identified attack before taking action. This on-demand option is slower but avoids blocking a legitimate user in the case of a false positive.

Upon seeing the same attack repeated, many customers often then choose to set the Salt integration with their inline device into auto-blocking mode. This approach effectively turns the Salt out-of-band deployment (which avoids any application impact) into an inline protective device, immediately stopping the attack traffic. Having this flexibility means the Salt platform supports a range of customer approaches and adjusts with them as they move through their API security maturity model.

In Conclusion

WAFs provide helpful protections against a lot of traditional attacks that are still prevalent. However, because of their proxy architecture, they cannot correlate activity across users and across time to detect today’s sophisticated API attacks. Relying on WAFs alone for API protection is insufficient and leaves companies vulnerable. We here at Salt do not claim that our platform is a DDoS protection solution. However, by leveraging our anomaly detection capabilities, we can catch attacks your WAF will miss. And we can integrate with your WAF to provide the inline blocking needed to protect your services.

To learn about the Salt award-winning API security platform and how it can help you discover and secure both in-house developed and third-party APIs in your environment, contact us or sign up for a personalized demo.