On Sunday 14 January 2024 at 04:36 UTC, a HTTP/2 rapid reset targeted a online payments customer in North America. The attack peaked at 52.6 million requests per second and lasted 155 minutes. Traffic originated from 253 autonomous systems in 94 countries, predominantly a rented booter service.
| Vector | HTTP/2 rapid reset |
| Peak | 52.6 million requests per second |
| Duration | 155 min |
| Time to mitigation | 0.483 s |
| Attack traffic reaching origin | 0.039% |
| Legitimate traffic challenged | 0.51% |
Timeline
The attack was preceded by an extortion email received two days earlier. Request rates on the targeted routes exceeded their hourly baseline by a factor of 252 within 33 seconds. The risk score of participating clients crossed the challenge threshold automatically and proof-of-work difficulty rose with origin load.
What the customer saw
The customer’s status page stayed green throughout; they learned about the attack from our notification.
Recommendations
- Review allow-listed partner ranges quarterly.
- Keep origin IPs out of public DNS history.
- Lower challenge thresholds on authentication endpoints during high-risk events.
The billing model is what got our finance team on board, honestly.
Great write-up. We saw almost the same pattern on our login endpoint last month.
Do you publish the edge IP ranges in a machine-readable format?
Any plans to support per-tenant limits keyed on a JWT claim?
Verified good bots and allow-listed partners bypass challenges entirely.
How do you avoid challenging uptime monitors and partners?
Thanks! Yes — the risk score and its components are included in every log record.