Massive 2.45 billion request DDoS attack used 1.2 million IPs to evade rate limits

A massive application-layer DDoS attack sent more than 2.45 billion malicious requests to a large user-generated content platform in just five hours. DataDome said the campaign peaked at 205,344 requests per second and sustained an average of about 136,000 requests per second.

The attack stood out because it did not rely on a few noisy sources. Instead, it spread traffic across more than 1.2 million unique IP addresses and 16,402 autonomous systems, which helped the attackers stay below normal per-IP rate limits.

Each source averaged roughly one request every nine seconds. That made individual IPs look harmless on their own, while the combined botnet still created enormous pressure on the target.

Why the attack bypassed normal rate limits

Traditional rate limiting often focuses on how many requests come from one IP address in a set period. That works against simple floods, scrapers, and abusive clients that send too many requests from the same source.

This attack used a different strategy. The botnet spread requests across so many IP addresses that no single source had to send much traffic.

DataDome said this exposed a structural weakness in static rate-limit rules. A request pattern can look normal at the source level while still becoming destructive at the platform level.

At a glance

Detail	What DataDome observed
Target	A large user-generated content platform
Attack window	Five hours in mid-April 2026
Total malicious requests	More than 2.45 billion
Unique IP addresses	More than 1.2 million
Autonomous systems	16,402 ASNs
Peak traffic	205,344 requests per second
Average traffic	About 136,000 requests per second
Per-source rate	Roughly one request every nine seconds

The botnet used a flat traffic pattern

The botnet’s distribution made simple blocking less effective. DataDome said the top contributing autonomous system accounted for only about 3% of the total attack traffic.

That flat structure means defenders could not stop the campaign by blocking one provider, one region, or one network. The attackers mixed traffic through privacy-focused infrastructure and legitimate cloud providers.

This helped the malicious requests blend into normal internet traffic. It also made broad blocking risky because defenders could accidentally affect real users and business traffic.

The campaign used wave-like pressure

DataDome observed a wave pattern rather than one constant flood. The attack intensity rose and fell over time, which suggests the operators or orchestration system adjusted traffic during the campaign.

Those pauses gave some aggregate counters time to reset. The attackers then returned with changed IPs, user agents, headers, cookies, and URL parameters.

This made the campaign more adaptive than a basic HTTP flood. It also forced defenders to evaluate behavior across sessions and time, not only request volume at one moment.

What made the attack detectable

The campaign was large and well distributed, but it was not perfect. DataDome said the attackers forged headers, cookies, and URL parameters, but they did not maintain consistent browser behavior across sessions.

Real users tend to keep stable browser and session signals. Automated traffic often shifts those signals in unnatural ways, especially when operators rotate tools, identities, and network paths.

DataDome said its Galileo threat research team used server-side fingerprinting, behavioral analysis, and threat intelligence to identify and block the attack in real time.

Why application-layer DDoS is hard to stop

Application-layer DDoS attacks target the web application itself, not only the network pipe. They can send requests that look closer to normal user activity than raw network floods.

Cloudflare explains that application-layer attacks can be efficient because they force the target to spend more resources processing requests than the attacker spends sending them.

This is why the 2.45 billion request campaign matters. The attackers did not need every IP to send huge volumes. They used scale, timing, and distribution to create pressure while avoiding simple thresholds.

Defender checklist

• Do not rely only on per-IP rate limits for DDoS protection.
• Track request behavior across sessions, user agents, fingerprints, and time windows.
• Build baselines for normal traffic before an attack begins.
• Monitor ASN, hosting provider, and cloud provider distribution during traffic spikes.
• Use bot detection signals in addition to network and volume controls.
• Watch for unstable client identities inside the same session.
• Prepare an incident response plan for application-layer DDoS attacks.
• Coordinate early with CDN, hosting, DNS, and DDoS mitigation providers.

Why businesses should care

Large user-generated content platforms depend on availability. If the service becomes slow or unreachable, users leave, moderation queues pile up, and revenue can drop quickly.

Attackers may also use a DDoS attack as cover. While defenders focus on traffic pressure, another part of the operation may attempt account abuse, scraping, fraud, or intrusion activity.

CISA advises organizations to prepare for DDoS incidents before they happen, including response planning, coordination with service providers, and documented mitigation steps.

FAQ