On Thursday 9 February 2023 at 18:08 UTC, a HTTP POST flood targeted a retail banking customer in Central Europe. The attack peaked at 432.6 million requests per second and lasted 105 minutes. Traffic originated from 558 autonomous systems in 26 countries, predominantly residential proxy networks.
| Vector | HTTP POST flood |
| Peak | 432.6 million requests per second |
| Duration | 105 min |
| Time to mitigation | 0.670 s |
| Attack traffic reaching origin | 0.045% |
| Legitimate traffic challenged | 0.21% |
Timeline
The attack was preceded by a breaking political story. Request rates on the targeted routes exceeded their hourly baseline by a factor of 355 within 11 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
- Add a dedicated rate limit for the targeted route.
- Enable authenticated origin pulls.
- Enable log streaming to your SIEM for faster correlation.
Is the risk score exposed in the logs so we can build our own dashboards on it?
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.
Do you publish the edge IP ranges in a machine-readable format?
Nice to read a vendor blog that admits what went wrong.
Our auditors asked for exactly this kind of incident evidence under DORA.
Any plans to support per-tenant limits keyed on a JWT claim?
Would love a follow-up on how you handle HTTP/3 fingerprinting.