On Friday 26 May 2023 at 13:46 UTC, a TLS handshake exhaustion targeted a sports betting customer in the Middle East. The attack peaked at 819.4 million requests per second and lasted 13 minutes. Traffic originated from 2178 autonomous systems in 13 countries, predominantly hijacked home routers.
| Vector | TLS handshake exhaustion |
| Peak | 819.4 million requests per second |
| Duration | 13 min |
| Time to mitigation | 0.450 s |
| Attack traffic reaching origin | 0.090% |
| Legitimate traffic challenged | 0.15% |
Timeline
The attack was preceded by a breaking political story. Request rates on the targeted routes exceeded their hourly baseline by a factor of 715 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
A brief increase in p99 latency of 217 ms during the first minute, then normal service.
Recommendations
- Review allow-listed partner ranges quarterly.
- Lower challenge thresholds on authentication endpoints during high-risk events.
- Keep origin IPs out of public DNS history.
The billing model is what got our finance team on board, honestly.
How does the proof-of-work challenge behave on older Android devices? Any numbers below Android 10?
Any plans to support per-tenant limits keyed on a JWT claim?
This matches what we see in iGaming around big matches.
How do you avoid challenging uptime monitors and partners?
Our auditors asked for exactly this kind of incident evidence under DORA.
Thanks! Yes — the risk score and its components are included in every log record.