On Monday 26 July 2021 at 21:30 UTC, a login endpoint flood targeted a fashion retail customer in the UK. The attack peaked at 607.2 million requests per second and lasted 32 minutes. Traffic originated from 2180 autonomous systems in 69 countries, predominantly a rented booter service.
| Vector | login endpoint flood |
| Peak | 607.2 million requests per second |
| Duration | 32 min |
| Time to mitigation | 0.572 s |
| Attack traffic reaching origin | 0.084% |
| Legitimate traffic challenged | 0.35% |
Timeline
The attack was preceded by a breaking political story. Request rates on the targeted routes exceeded their hourly baseline by a factor of 775 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
No customer-visible impact. The on-call engineer was notified and acknowledged the incident from the dashboard.
Recommendations
- Add a dedicated rate limit for the targeted route.
- Enable authenticated origin pulls.
- Review allow-listed partner ranges quarterly.
Clear and practical, thanks.
This matches what we see in iGaming around big matches.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
Thanks — sharing this with our on-call team.
Could you share the dataset behind the percentages?
Could you share the dataset behind the percentages?
The point about origin IPs leaking through certificate transparency logs is underrated.
Great write-up. We saw almost the same pattern on our login endpoint last month.