On Sunday 8 December 2024 at 15:29 UTC, a WebSocket connection flood targeted a municipal services customer in the Nordics. The attack peaked at 60.1 million requests per second and lasted 30 minutes. Traffic originated from 863 autonomous systems in 87 countries, predominantly mobile carrier ranges.
| Vector | WebSocket connection flood |
| Peak | 60.1 million requests per second |
| Duration | 30 min |
| Time to mitigation | 0.521 s |
| Attack traffic reaching origin | 0.085% |
| Legitimate traffic challenged | 0.38% |
Timeline
The attack was preceded by a competitor’s product launch. Request rates on the targeted routes exceeded their hourly baseline by a factor of 860 within 12 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
- Lower challenge thresholds on authentication endpoints during high-risk events.
- Enable log streaming to your SIEM for faster correlation.
- Keep origin IPs out of public DNS history.
Clear and practical, thanks.
Great write-up. We saw almost the same pattern on our login endpoint last month.
The point about origin IPs leaking through certificate transparency logs is underrated.
Machine-readable ranges are at /ips.json and via the API.
This matches what we see in iGaming around big matches.
Good question. We will cover that in a follow-up post.
Clear and practical, thanks.
Great to hear, thanks for sharing your experience.