On Monday 24 November 2025 at 19:47 UTC, a TLS handshake exhaustion targeted a news publisher customer in Southeast Asia. The attack peaked at 944.8 million requests per second and lasted 168 minutes. Traffic originated from 1890 autonomous systems in 91 countries, predominantly mobile carrier ranges.
| Vector | TLS handshake exhaustion |
| Peak | 944.8 million requests per second |
| Duration | 168 min |
| Time to mitigation | 0.327 s |
| Attack traffic reaching origin | 0.026% |
| Legitimate traffic challenged | 0.37% |
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 753 within 23 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
- Lower challenge thresholds on authentication endpoints during high-risk events.
- Add a dedicated rate limit for the targeted route.
- Review allow-listed partner ranges quarterly.
Great write-up. We saw almost the same pattern on our login endpoint last month.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
Nice to read a vendor blog that admits what went wrong.
Good question. We will cover that in a follow-up post.
How do you avoid challenging uptime monitors and partners?