On Saturday 4 May 2024 at 18:06 UTC, a WebSocket connection flood targeted a news publisher customer in North America. The attack peaked at 589.3 million requests per second and lasted 95 minutes. Traffic originated from 2573 autonomous systems in 74 countries, predominantly a Mirai-derived IoT botnet.
| Vector | WebSocket connection flood |
| Peak | 589.3 million requests per second |
| Duration | 95 min |
| Time to mitigation | 0.817 s |
| Attack traffic reaching origin | 0.065% |
| Legitimate traffic challenged | 0.57% |
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 500 within 13 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
- Review allow-listed partner ranges quarterly.
- Enable authenticated origin pulls.
- Lower challenge thresholds on authentication endpoints during high-risk events.
Great write-up. We saw almost the same pattern on our login endpoint last month.
How do you avoid challenging uptime monitors and partners?
The billing model is what got our finance team on board, honestly.
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.
Is the risk score exposed in the logs so we can build our own dashboards on it?
Machine-readable ranges are at /ips.json and via the API.