On Wednesday 5 March 2025 at 05:06 UTC, a HTTP POST flood targeted a tax authority portal customer in Iberia. The attack peaked at 806.8 million requests per second and lasted 150 minutes. Traffic originated from 994 autonomous systems in 113 countries, predominantly a rented booter service.
| Vector | HTTP POST flood |
| Peak | 806.8 million requests per second |
| Duration | 150 min |
| Time to mitigation | 0.247 s |
| Attack traffic reaching origin | 0.079% |
| Legitimate traffic challenged | 0.74% |
Timeline
The attack was preceded by a competitor’s product launch. Request rates on the targeted routes exceeded their hourly baseline by a factor of 86 within 35 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
A brief increase in p99 latency of 101 ms during the first minute, then normal service.
Recommendations
- Enable log streaming to your SIEM for faster correlation.
- Review allow-listed partner ranges quarterly.
- Lower challenge thresholds on authentication endpoints during high-risk events.
Our auditors asked for exactly this kind of incident evidence under DORA.
Great write-up. We saw almost the same pattern on our login endpoint last month.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
Verified good bots and allow-listed partners bypass challenges entirely.
Clear and practical, thanks.
We had the exact false-positive issue with CGNAT carriers. The weighting change makes sense.
How does the proof-of-work challenge behave on older Android devices? Any numbers below Android 10?
Machine-readable ranges are at /ips.json and via the API.
Clear and practical, thanks.