On Tuesday 28 May 2024 at 12:27 UTC, a HTTP/2 rapid reset targeted a municipal services customer in Iberia. The attack peaked at 807.0 million requests per second and lasted 110 minutes. Traffic originated from 2278 autonomous systems in 68 countries, predominantly compromised cloud VMs.
| Vector | HTTP/2 rapid reset |
| Peak | 807.0 million requests per second |
| Duration | 110 min |
| Time to mitigation | 0.451 s |
| Attack traffic reaching origin | 0.039% |
| Legitimate traffic challenged | 0.41% |
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 637 within 20 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
Checkout conversion was unchanged compared with the same hour of the previous week.
Recommendations
- Enable log streaming to your SIEM for faster correlation.
- Add a dedicated rate limit for the targeted route.
- Enable authenticated origin pulls.
Clear and practical, thanks.
Great write-up. We saw almost the same pattern on our login endpoint last month.
Thanks! Yes — the risk score and its components are included in every log record.
Our auditors asked for exactly this kind of incident evidence under DORA.
Do you publish the edge IP ranges in a machine-readable format?
Verified good bots and allow-listed partners bypass challenges entirely.
Could you share the dataset behind the percentages?
Could you share the dataset behind the percentages?
The billing model is what got our finance team on board, honestly.