On Wednesday 29 May 2024 at 15:06 UTC, a credential stuffing targeted a online payments customer in the UK. The attack peaked at 932.3 million requests per second and lasted 25 minutes. Traffic originated from 945 autonomous systems in 65 countries, predominantly a rented booter service.
| Vector | credential stuffing |
| Peak | 932.3 million requests per second |
| Duration | 25 min |
| Time to mitigation | 0.787 s |
| Attack traffic reaching origin | 0.031% |
| Legitimate traffic challenged | 0.47% |
Timeline
The attack was preceded by a hacktivist channel announcing the target. Request rates on the targeted routes exceeded their hourly baseline by a factor of 755 within 17 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.
- Review allow-listed partner ranges quarterly.
- Lower challenge thresholds on authentication endpoints during high-risk events.
Could you share the dataset behind the percentages?
Solid runbook advice. The DNS-at-2am point hit home.
Any plans to support per-tenant limits keyed on a JWT claim?
Could you share the dataset behind the percentages?
Great to hear, thanks for sharing your experience.