DDoS Attack Overview

The graph below (Figure 1) represents the bot traffic detected over time by our detection engine. As noted earlier, it does not take into account the requests handled by our anti-DDoS mechanism.

Figure 1: Number of bot requests handled by the DataDome bot detection engine over time during the attack. 

Indeed, as the volume of incoming traffic reached peaks of 2.459M requests/second (Figure 2), our detection engine activated its anti-DDoS mechanisms.

Figure 2: Time series representing the volume of requests originating from the attacker during the most intense part of the attack. At peak, the customers received more than 2.459M requests/second.

The graph below (Figure 3) represents the volume of requests handled by DataDome’s anti-DDoS mechanism. We observed that this mechanism quickly acted a few seconds after the beginning of the attack. This is the component that handled most of the DDoS requests (>505M requests).

Figure 3: Time series representing the volume of requests handled by our anti-DDoS mechanism during the attack.

Distribution of the Attack

The attack was distributed across 43,740 IP addresses. The graph below (Figure 4) represents the distinct number of bot IP addresses during the attack.

Figure 4: Number of distinct bot IP addresses used over time. When the attack started, we observed spikes of 12K distinct IP addresses used per minute. 

If we have a closer look at the IP addresses used by the attack, we observe that the attack was coming from several autonomous systems (Figure 5), including well known American ISPs such as Comcast, AT&T, and Verizon (UUNET).

Figure 5: Volume of requests per top autonomous system (AS) involved in the attack.

Attack Indicators of Compromise (IoCs)

The attacker used different user-agents, all of which were relatively up-to-date:

• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36 Edg/97.0.1072.91
• Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0
• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 OPR/106.0.0.0
• Mozilla/5.0 (X11; CrOS x86_64 14989.11.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36

Some user-agents—like Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36—were malformed (here the quote was contained in the user-agent). This occurred either because the attacker used a database of user-agents that contained bogus values or wasn’t properly escaping the strings in their code.

The attacker used different combinations of accept-languages, but the majority of them included US English language as this is the language of the website.

The attacker used different TLS fingerprints; however, the most common JA3 fingerprint was 0cce74b0d9b7f8528fb2181588d23793. If we analyze traffic with this JA3 fingerprint on our customer base, we observe that it is also linked to the following user-agents:

• node-fetch/1.0 (+https://github.com/bitinn/node-fetch)
• axios/0.17.1

Thus, we can safely conclude that the attacker used a NodeJS-based HTTP(s) client to conduct the attack. Because of that, the attacker didn’t execute any JS payloads.

How was the attack blocked?

Thanks to our multi-layered approach, the attack was blocked using different independent categories of signals. Thus, had the attacker changed part of a bot—such as fingerprint, behavior, etc.—it would have likely been caught using other signals and approaches.

The main signals and detection approaches used here were the following:

• Fingerprinting inconsistencies: The requests exhibited different inconsistencies in their fingerprints, both at the HTTP level and the TLS level. For example, some of the requests with outdated user-agents—like Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.54—were sending recent client-hints HTTP headers. The different TLS fingerprints used by the attacker were also linked to known HTTP clients.
• Behavioral detection: Our behavioral engine noticed a shift in the traffic distribution, in particular an abnormal increase of traffic without JS executed on login APIs. Each IP address also had an abnormal distribution of user-agents, and they all started to use too many distinct fingerprints compared to what we usually observe on this website.
• Contextual and reputational signals: Our ML models were also able to leverage the fact that most of the attacker’s requests came from IP addresses flagged as proxies, using outdated/non-standard user agents, from sessions that were brand new.

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 ML detection engine uses multiple layers of protection, looking at a variety of signals from fingerprints to behaviors to reputation. This approach helps us detect even the most sophisticated bots—an approach strengthened by our invisible Device Check challenge and integrated CAPTCHA.

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 layer 7 DDoS attacks, schedule a demo today.