DDoS Attack Fired 2.45 Billion Requests From 1.2 Million IPs

A botnet that hardly looked like a botnet quietly fired off 2.45 billion malicious requests at a single user-generated content site over five hours in mid-April, and almost nothing about it tripped a traditional alarm. No single source IP misbehaved. No single network carried more than three percent of the load. Each of the 1.2 million IPs in the swarm averaged one request every nine seconds, slow enough to look like a human refreshing a page on a flaky train Wi-Fi.

That is the story DataDome’s Galileo threat research team disclosed after blocking the campaign in real time. It is also a quiet warning to every security team still leaning on per-IP rate limits as a primary control. The defense those limits were built for has been engineered around.

What Actually Happened in Those Five Hours

The campaign hit a peak of 205,344 requests per second and held a sustained average near 136,000 RPS. Aggregate volume was the same scale you would expect from a flash sale at a global retailer. Distribution was not.

The 1.2 million IPs were spread across 16,402 autonomous systems. For comparison, even aggressive scraping operations rarely involve more than a few hundred ASNs. Researchers at DataDome called the spread “strikingly flat,” with the top contributing network responsible for just three percent of total traffic.

• 2.45 billion total malicious requests in five hours
• 1,200,000 unique source IP addresses
• 16,402 autonomous systems carrying traffic
• ~1 request every 9 seconds per IP, on average
• 3 percent ceiling on any single ASN’s contribution

That last number is the structural detail that mattered most. Block any one network and you barely dent the campaign. Block ten and you still have 97 percent of the attack arriving on schedule.

Why Rate Limiting Quietly Failed

Per-IP rate limiting works when one machine sends a thousand requests per minute. It does nothing when a million machines each send one request every nine seconds and the totals roll up only at the application server. The math is what makes the technique work: the threshold any reasonable security team sets for a single IP is several orders of magnitude higher than what any given bot actually sent.

The attackers also paced the assault in waves. Tactical pauses let aggregate counters reset. During each lull the operators rotated IPs, swapped user agents, and refreshed payloads before the next surge. HAProxy’s guidance on layered DDoS protection calls out exactly this gap: static thresholds catch crude floods and miss adaptive cadence.

“The adaptive nature of the attack points to a managed operation,” said Jerome Segura, VP of Threat Research at DataDome. Either a human operator or a tightly tuned orchestration layer was watching for detection signals and adjusting in real time.

The Camouflage Was the Cleverest Part

Sophisticated DDoS crews stopped using only seedy hosting providers years ago. This one mixed them with the most reputable cloud names on the internet.

Traffic came through Cloudflare, AWS, and Google Cloud alongside privacy-oriented networks like 1337 Services GmbH and the Church of Cyberology. The mainstream providers did the heavy lifting on legitimacy. Their IP ranges show up in millions of legitimate sessions every day, so blocklists cannot touch them without breaking the open web. The fringe networks added the noise that confused reputation scoring.

The Fingerprint That Gave Them Away

The operators forged headers, cookies, and URL parameters competently. They tripped on the harder problem: maintaining a consistent browser identity across a session.

DataDome’s detectors saw inconsistent TLS handshakes and what researchers described as “unstable” client-side identification signals. A real Chrome session does not silently switch its JA3 fingerprint mid-flow. An automated tool that recycles user agents without recycling the underlying TLS stack does. That mismatch was the lever.

What Worked Instead of Rate Limits

Galileo combined three signal layers: server-side fingerprinting to catch network-level inconsistencies, behavioral analysis on session sequences, and threat intelligence flagging IPs with negative reputations elsewhere in DataDome’s network. None of those signals was decisive alone. Together, they pulled the bots out of the noise without blocking a single legitimate user.

The Bigger Picture: 2026’s New DDoS Baseline

The DataDome campaign is not the loudest attack of the year. That title sits with a 31.4 Tbps burst Cloudflare blocked in November and detailed in its inaugural 2026 Threat Report. The two attacks represent the two ends of the modern DDoS spectrum, and defenders have to cover both.

The Cloudflare numbers are useful context. In Q1 2025 alone the company blocked 20.5 million DDoS attacks, roughly 96 percent of its total for all of 2024. Hyper-volumetric attacks above 1 Tbps or 1 Bpps grew 65-fold year over year in Q2. The Aisuru botnet, a swarm of compromised Android TVs and home routers estimated at one to four million devices, drove most of the record-breakers.

35 seconds, or even 10 minutes, is not a sufficient time for manual mitigation. By the time a security analyst receives the alert and analyzes the attack, it’s already over.

That line, from Cloudflare’s own analysis of the 31.4 Tbps incident, is the operational reality every SOC manager has to plan around now. The DataDome attack ran for five hours, not 35 seconds, but the same principle applies in reverse. A human team watching dashboards would not have noticed any single IP doing anything wrong.

What “Low and Slow” Looks Like as a Strategy

The phrase used to describe a different kind of attack: a single attacker holding TCP sockets open to exhaust a server’s connection table, Slowloris-style. The 2026 version is structurally different. It is high-aggregate, low-per-source, and built specifically to look indistinguishable from a popular site having a busy afternoon.

The Three Tactical Layers

1. Distribute the source pool across enough IPs that no rate limit is meaningful. 1.2 million is the new ceiling, not the floor.
2. Pulse the cadence so aggregate counters reset between waves and the operation can probe defenses without committing.
3. Mix infrastructure so the traffic blends into the cloud egress that legitimate apps already produce in volume.

None of those layers is exotic on its own. Combining all three with the operational discipline to run them for five hours straight is what separates this campaign from the script-kiddie work that fills most threat reports.

Where Defenders Are Pivoting

Behavioral baselines are the obvious answer, and most enterprise security vendors have been building toward them for two years. The harder question is what “behavior” means when a bot fires one request every nine seconds. The signal cannot be volume. It has to be consistency: does this client’s TLS stack match its declared browser, do the session sequences match what a human would do on this site, does the IP show up in adjacent threat data.

“Static rate limiting fails against dynamically tuned volumes,” the Galileo team wrote in its disclosure. The line reads like a slogan but it is also a procurement brief. Security teams whose primary DDoS control is still a number on a dashboard have a gap to close.

Who Should Be Worried

User-generated content platforms are the obvious target class. The April victim fits that profile directly. Forums, marketplaces, dating apps, comment sections, and any site where the business model depends on letting strangers post share the same exposure: high tolerance for spiky traffic, low tolerance for friction on legitimate users, and an attack surface that cannot be locked down without killing the product.

API-heavy fintech and AI inference platforms are the next tier. Both run on per-request economics. An attack that looks like 2.45 billion requests of cheap compute can move a meaningful number on a monthly cloud bill even when it never quite breaks anything.

The pattern that matters across all of them is that the attacker’s goal is not always to take the site offline. Sometimes it is to inflate cost. Sometimes it is to scrape behind a smokescreen. Sometimes it is to test which defenses fire so the next campaign can route around them. India’s SEBI naming Anthropic’s Claude Mythos in a recent regulatory circular reflects the same broader concern about adaptive, AI-assisted attack tooling that regulators globally are starting to flag.

What Comes After the Forged Headers

The Galileo team’s read on the adversary is worth quoting in full: capable of managing a globally dispersed botnet, operationally disciplined, but only moderately sophisticated on the evasion side. They forged headers and cookies but did not deploy true browser automation or JavaScript execution. That gap is the next step.

Real headless-browser-driven DDoS, where each bot runs Chromium and produces a coherent session, is computationally expensive. It is also already in use against some financial-services targets. As compute costs fall and AI-assisted orchestration tools mature, the floor for an evasive 1.2 million IP campaign drops too.

Defenders who built their stacks around 2022 assumptions are running on borrowed time.

Frequently Asked Questions

How do I know if my site was hit by a low-and-slow distributed attack like this?

Check aggregate request rates against a stable baseline rather than per-IP counters. Look for a sustained five to ten-fold increase in total RPS without any single IP exceeding normal thresholds. Cross-reference with TLS fingerprint diversity: a sudden spike in unique JA3 fingerprints from cloud-provider IP ranges is a strong indicator. Most WAFs surface this in their analytics dashboard under “unique client signatures.”

Can Cloudflare or AWS block this kind of attack on its own?

Not reliably without additional configuration. Both providers offer behavioral bot management products (Cloudflare Bot Management, AWS Shield Advanced with WAF Bot Control) that handle this profile, but the default DDoS protection on either platform leans heavily on volumetric thresholds and IP reputation. If you have not enabled the bot-management add-on, your defaults assume a louder attacker than this one.

Is rate limiting now useless for DDoS defense?

No, but it is no longer sufficient on its own. Per-IP rate limits still catch crude attacks and cap individual abusive clients, which is worth keeping. The change is that they cannot be your primary control. Pair them with session-level behavioral analysis, TLS and HTTP/2 fingerprinting, and aggregated thresholds that sum activity by ASN, geography, or request pattern rather than only by IP.

What should a small site do if it cannot afford enterprise bot management?

Three steps that cost little. Turn on the highest available security mode in your existing CDN (Cloudflare’s “I’m Under Attack” mode, Fastly’s challenge pages). Add JavaScript and TLS challenges to high-cost endpoints like search, login, and any AI-inference routes. Cache aggressively on cacheable paths so even a sustained 100,000 RPS hits your cache and not your origin. The free tier of most CDNs handles this if you configure it.

How long until attackers add real headless-browser automation to this technique?

It is already happening at the high end. Financial-services teams have been reporting headless-Chromium-driven credential stuffing for over a year, and the same tooling extends naturally to DDoS. The economic gate is compute cost per bot session, which dropped roughly 40 percent in 2025 as cheaper GPU and CPU spot capacity came online. Plan for a credible large-scale campaign with full browser fidelity inside the next 12 months.

The 2.45 billion-request operation will not be the last campaign that hides inside the noise of legitimate traffic. It is closer to a template than an outlier. Security teams that read the disclosure as a vendor blog post and move on are misreading the signal. The teams that read it as a procurement brief, and start auditing where their stack still trusts a per-IP counter as the floor, are the ones who will recognize the next one in time to do anything about it.

Disclaimer: This article describes a publicly disclosed DDoS campaign and general defensive principles for awareness only. It does not constitute formal incident-response guidance for any specific environment. Security teams should validate any control changes in a staging environment before production rollout and consult their internal threat-intelligence and network-engineering leads for architecture-specific decisions. Vendor product capabilities cited reflect publicly available information as of May 2026 and may change without notice.