On Thursday 8 April 2021 at 02:13 UTC, a credential stuffing targeted a developer platform customer in Iberia. The attack peaked at 623.2 million requests per second and lasted 74 minutes. Traffic originated from 842 autonomous systems in 47 countries, predominantly misconfigured open reflectors.
| Vector | credential stuffing |
| Peak | 623.2 million requests per second |
| Duration | 74 min |
| Time to mitigation | 0.391 s |
| Attack traffic reaching origin | 0.075% |
| Legitimate traffic challenged | 0.29% |
Timeline
The attack was preceded by a ransom note demanding payment in Monero. Request rates on the targeted routes exceeded their hourly baseline by a factor of 656 within 30 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.
- Keep origin IPs out of public DNS history.
- Enable authenticated origin pulls.
How do you avoid challenging uptime monitors and partners?
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
Do you publish the edge IP ranges in a machine-readable format?
Solid runbook advice. The DNS-at-2am point hit home.
Machine-readable ranges are at /ips.json and via the API.
This matches what we see in iGaming around big matches.
How does the proof-of-work challenge behave on older Android devices? Any numbers below Android 10?
Great write-up. We saw almost the same pattern on our login endpoint last month.
Clear and practical, thanks.
Thanks — sharing this with our on-call team.