On Monday 9 December 2024 at 22:06 UTC, a login endpoint flood targeted a video streaming customer in Western Europe. The attack peaked at 675.9 million requests per second and lasted 132 minutes. Traffic originated from 3883 autonomous systems in 49 countries, predominantly a headless-browser farm.
| Vector | login endpoint flood |
| Peak | 675.9 million requests per second |
| Duration | 132 min |
| Time to mitigation | 0.425 s |
| Attack traffic reaching origin | 0.014% |
| Legitimate traffic challenged | 0.29% |
Timeline
The attack was preceded by a breaking political story. Request rates on the targeted routes exceeded their hourly baseline by a factor of 114 within 39 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
- Lower challenge thresholds on authentication endpoints during high-risk events.
- Keep origin IPs out of public DNS history.
- Enable authenticated origin pulls.
Is the risk score exposed in the logs so we can build our own dashboards on it?
How do you avoid challenging uptime monitors and partners?
Good question. We will cover that in a follow-up post.
This matches what we see in iGaming around big matches.
Verified good bots and allow-listed partners bypass challenges entirely.
Carpet bombing is nasty. Good to see a clear explanation of it.
Clear and practical, thanks.
Great write-up. We saw almost the same pattern on our login endpoint last month.