On Monday 30 January 2023 at 08:36 UTC, a HTTP/2 rapid reset targeted a fashion retail customer in Latin America. The attack peaked at 397.6 million requests per second and lasted 155 minutes. Traffic originated from 1984 autonomous systems in 99 countries, predominantly a rented booter service.
| Vector | HTTP/2 rapid reset |
| Peak | 397.6 million requests per second |
| Duration | 155 min |
| Time to mitigation | 0.708 s |
| Attack traffic reaching origin | 0.045% |
| Legitimate traffic challenged | 0.33% |
Timeline
The attack was preceded by a ransom note demanding payment in Monero. Request rates on the targeted routes exceeded their hourly baseline by a factor of 54 within 13 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
- Keep origin IPs out of public DNS history.
- Enable log streaming to your SIEM for faster correlation.
- Lower challenge thresholds on authentication endpoints during high-risk events.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
Nice to read a vendor blog that admits what went wrong.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
Any plans to support per-tenant limits keyed on a JWT claim?
Thanks! Yes — the risk score and its components are included in every log record.
The point about origin IPs leaking through certificate transparency logs is underrated.
Verified good bots and allow-listed partners bypass challenges entirely.
Clear and practical, thanks.
Solid runbook advice. The DNS-at-2am point hit home.
Good question. We will cover that in a follow-up post.
Would love a follow-up on how you handle HTTP/3 fingerprinting.