What happened
A massive DDoS campaign recently hit a large-scale user-generated content platform with over 2.45 billion malicious requests in just five hours. But this wasn't your typical brute-force flood. The attackers distributed traffic across 1.2 million unique IP addresses spanning 16,402 autonomous systems, keeping each individual IP's request rate so low that it looked completely legitimate in isolation.
Each source averaged just one request every nine seconds. No single IP looked malicious. No single network stood out. The top contributing ASN accounted for only three percent of total attack traffic. Traditional rate limiting didn't stand a chance.
How the attack worked
The campaign peaked at 205,344 requests per second while maintaining a sustained average of around 136,000 RPS. But the sophistication wasn't in the volume. It was in the structure.
The attackers used deliberate wave patterns instead of a constant flood. Between waves they rotated IPs, swapped user agents, and returned with modified payloads. These tactical pauses allowed aggregate rate-limit counters to reset, effectively making each new wave look like fresh, legitimate traffic.
They also deliberately mixed traffic sources across privacy-oriented infrastructure like 1337 Services GmbH and the Church of Cyberology alongside major cloud providers like AWS, Cloudflare, and Google. By routing through these providers, malicious requests blended seamlessly into the massive volumes of legitimate cloud egress traffic that defenders are used to seeing.
Why traditional defenses failed
This attack exposed a fundamental flaw in how most applications handle rate limiting. Standard approaches evaluate requests in isolation, checking whether a single IP or session has exceeded a threshold within a time window. When each of 1.2 million IPs is sending one request every nine seconds, none of them individually trigger anything.
Blocking by ASN was equally useless. With traffic spread across over 16,000 autonomous systems and no single ASN contributing more than three percent, blocking any individual network would barely dent the attack.
Even header and cookie inspection had limited value. The attackers forged headers, cookies, and URL parameters, though their client-side browser identification signals shifted constantly within sessions, which became one of the detection vectors that ultimately helped identify the attack.
What actually worked
The attack was ultimately detected and blocked in real-time using layered behavioral detection rather than static thresholds. The successful mitigation combined server-side fingerprinting to catch network-layer inconsistencies, behavioral analysis to identify anomalous session sequences, and threat intelligence to flag IPs with negative reputations.
In other words, instead of asking "is this single request suspicious?" the detection systems asked "does the pattern of behavior across time and sources make sense?"
What this means for developers
If your application relies solely on per-IP rate limiting as a defense against abuse, this attack is a case study in why that's not enough. Here's what to consider:
Rate limiting is necessary but not sufficient. You still need it to handle simple abuse, but it can't be your only layer. Sophisticated attackers will distribute traffic to stay under your thresholds.
Think in patterns, not individual requests. Monitor for anomalous aggregate behavior across your entire traffic, not just per-IP metrics. A sudden increase in unique IPs all hitting the same endpoints with similar timing patterns is a signal even if each IP looks clean.
Validate client-side signals. The attackers in this campaign couldn't maintain consistent browser identification signals within sessions. Checking for consistency in things like TLS fingerprints, JavaScript execution behavior, and session continuity can catch automated tooling that forges surface-level headers.
Don't trust traffic just because it comes from a major cloud provider. A request originating from AWS or Google Cloud isn't inherently legitimate. Attackers routinely route through major providers specifically because defenders tend to whitelist that traffic.
Layer your defenses. Combine rate limiting with behavioral analysis, IP reputation checks, fingerprinting, and challenge mechanisms. No single layer will catch everything, but a layered approach forces attackers to solve multiple problems simultaneously.
The bigger picture
DDoS attacks are evolving from blunt instruments into precision operations. This campaign demonstrates that attackers are now capable of managing globally distributed botnets with the operational discipline to keep individual node behavior below detection thresholds while maintaining devastating aggregate pressure.
The takeaway for developers and engineering teams is clear: static, threshold-based defenses are no longer enough on their own. Detection needs to operate on behavioral baselines across time and sources rather than evaluating requests in isolation.
The good news is that the attackers in this case, despite their impressive infrastructure, were only moderately sophisticated in their evasion techniques. They couldn't fake consistent browser behavior or execute JavaScript challenges. That gap is where defenders still have an advantage, but only if they're actually checking for it.
What rate limiting or DDoS mitigation strategies are you using in your applications? Curious to hear how other teams are thinking about this, especially smaller teams that can't afford enterprise-grade DDoS protection.
Source: DataDome / Cybersecurity News
Top comments (0)