On Wednesday 23 March 2022 at 06:27 UTC, a HTTP POST flood targeted a retail banking customer in the Nordics. The attack peaked at 530.4 million requests per second and lasted 93 minutes. Traffic originated from 3142 autonomous systems in 32 countries, predominantly misconfigured open reflectors.
| Vector | HTTP POST flood |
| Peak | 530.4 million requests per second |
| Duration | 93 min |
| Time to mitigation | 0.833 s |
| Attack traffic reaching origin | 0.035% |
| Legitimate traffic challenged | 0.44% |
Timeline
The attack was preceded by a publicly announced sales event. Request rates on the targeted routes exceeded their hourly baseline by a factor of 724 within 26 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
No customer-visible impact. The on-call engineer was notified and acknowledged the incident from the dashboard.
Recommendations
- Enable log streaming to your SIEM for faster correlation.
- Enable authenticated origin pulls.
- Lower challenge thresholds on authentication endpoints during high-risk events.
The billing model is what got our finance team on board, honestly.
This matches what we see in iGaming around big matches.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
Is the risk score exposed in the logs so we can build our own dashboards on it?
Great to hear, thanks for sharing your experience.
Interesting that most attacks are under ten minutes. Our experience is similar.
Machine-readable ranges are at /ips.json and via the API.
Carpet bombing is nasty. Good to see a clear explanation of it.
Verified good bots and allow-listed partners bypass challenges entirely.
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.
Could you share the dataset behind the percentages?