On Saturday 22 May 2021 at 10:43 UTC, a TLS handshake exhaustion targeted a online payments customer in North America. The attack peaked at 111.3 million requests per second and lasted 30 minutes. Traffic originated from 1006 autonomous systems in 111 countries, predominantly a Mirai-derived IoT botnet.
| Vector | TLS handshake exhaustion |
| Peak | 111.3 million requests per second |
| Duration | 30 min |
| Time to mitigation | 0.807 s |
| Attack traffic reaching origin | 0.070% |
| Legitimate traffic challenged | 0.01% |
Timeline
The attack was preceded by a publicly announced sales event. Request rates on the targeted routes exceeded their hourly baseline by a factor of 139 within 9 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
The customer’s status page stayed green throughout; they learned about the attack from our notification.
Recommendations
- Add a dedicated rate limit for the targeted route.
- Lower challenge thresholds on authentication endpoints during high-risk events.
- Keep origin IPs out of public DNS history.
Thanks — sharing this with our on-call team.
Good question. We will cover that in a follow-up post.
The billing model is what got our finance team on board, honestly.
Any plans to support per-tenant limits keyed on a JWT claim?
How do you avoid challenging uptime monitors and partners?
Interesting that most attacks are under ten minutes. Our experience is similar.
Great to hear, thanks for sharing your experience.
The billing model is what got our finance team on board, honestly.
How do you avoid challenging uptime monitors and partners?