On Thursday 16 June 2022 at 21:15 UTC, a TLS handshake exhaustion targeted a developer platform customer in Latin America. The attack peaked at 120.5 million requests per second and lasted 80 minutes. Traffic originated from 3045 autonomous systems in 96 countries, predominantly mobile carrier ranges.
| Vector | TLS handshake exhaustion |
| Peak | 120.5 million requests per second |
| Duration | 80 min |
| Time to mitigation | 0.153 s |
| Attack traffic reaching origin | 0.085% |
| Legitimate traffic challenged | 0.46% |
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 797 within 8 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
- Lower challenge thresholds on authentication endpoints during high-risk events.
- Review allow-listed partner ranges quarterly.
- Add a dedicated rate limit for the targeted route.
Could you share the dataset behind the percentages?
Would love a follow-up on how you handle HTTP/3 fingerprinting.
The billing model is what got our finance team on board, honestly.
Any plans to support per-tenant limits keyed on a JWT claim?
Nice to read a vendor blog that admits what went wrong.
Thanks — sharing this with our on-call team.
Machine-readable ranges are at /ips.json and via the API.
Thanks — sharing this with our on-call team.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
Is the risk score exposed in the logs so we can build our own dashboards on it?