DDoS Attack Overview

The graph below (Figure 1) represents the bot traffic handled over the course of the 12-hour attack by our detection engine, in 30 minute intervals. The attack reached a peak of 86 million requests per 30 minutes and ~55K requests per second towards the beginning of the attack.

Distribution of the Attack

The attack was distributed across ~311K IP addresses. The graph below (Figure 2) represents the distinct number of bot IP addresses during the attack.

We can see that at any given time, the attacker had access to between 120K and 140K distinct IP addresses to distribute their attack.

Attack Indicators of Compromise (IoCs)

While the attacker leveraged mostly residential IPs belonging to well-known ISPs such as Charter Communications, Time Warner Cable, and Turk Telekom, there were some commonalities between requests:

• Every bot used the same Android webview user-agent: Mozilla/5.0 (Linux; Android 9; LIO-AN00 Build/PQ3A.190705.11031332; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/91.0.4472.114 Safari/537.36
• Bots used Chinese accept-languages: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7 and zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2.
• The bots had a non-consistent and unique TLS fingerprint that is not found across the other customers we protect.
• Bots didn’t execute JavaScript on any request. However, they did support cookies.

How was the attack blocked?

Thanks to our multi-layered detection approach, the attack was blocked using different independent categories of signals. Thus, had the attacker changed part of its bot (for example, fingerprint or behavior), it would have likely been caught using other signals and approaches.

The main signals and detection approaches here were the following:

• Lack of JavaScript execution: The attacker never sent any of the JS payloads, either from our JS tag or our Device Check page.
• New/Recent sessions: The requests were coming from fresh sessions, meaning the requests weren’t given time to build up a “human-like” browsing session.
• Fingerprinting: Our engine detected inconsistent and abnormal fingerprints, such as HTTP headers and TLS fingerprints.
• Proxy detection: We were able to identify that the attacker was using proxies to make requests.
• Outlier detection at the website level: This attack triggered an approach we presented at Black Hat Asia 2023, which automatically identified the malicious part of traffic that was the DDoS attack and generated dynamic blocking patterns.

Conclusion

DDoS attacks are the bane of most businesses that operate online; they are usually highly publicized and have instant negative impacts on revenue, brand reputation, and customer experience.

DataDome’s powerful multi-layered ML detection engine looks at as many signals as possible, from fingerprints to reputation, to detect even the most sophisticated boots. Keeping up with bots evolving fingerprints, such as proxy usage, is key to fighting today’s main threats—and DataDome can handle it.

When our system detects a DDoS attack in progress, our anti-DDoS mechanisms enable protection to scale perfectly, no matter the number of requests the attacker sends. To get a better look at how DataDome stops DDoS attacks, schedule a demo today.