On Thursday 26 October 2023 at 10:59 UTC, a carpet-bombing UDP flood targeted a developer platform customer in North America. The attack peaked at 96.1 Gbps and lasted 96 minutes. Traffic originated from 2913 autonomous systems in 23 countries, predominantly a Mirai-derived IoT botnet.
| Vector | carpet-bombing UDP flood |
| Peak | 96.1 Gbps |
| Duration | 96 min |
| Time to mitigation | 0.822 s |
| Attack traffic reaching origin | 0.048% |
| Legitimate traffic challenged | 0.27% |
Timeline
The attack was preceded by a ransom note demanding payment in Monero. Edge packet filters identified the flood by source port and payload signature and dropped it at line rate across 12 points of presence.
What the customer saw
No customer-visible impact. The on-call engineer was notified and acknowledged the incident from the dashboard.
Recommendations
- Add a dedicated rate limit for the targeted route.
- Review allow-listed partner ranges quarterly.
- Keep origin IPs out of public DNS history.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
Is the risk score exposed in the logs so we can build our own dashboards on it?
Solid runbook advice. The DNS-at-2am point hit home.
How does the proof-of-work challenge behave on older Android devices? Any numbers below Android 10?
Clear and practical, thanks.
The point about origin IPs leaking through certificate transparency logs is underrated.
Good question. We will cover that in a follow-up post.
How do you avoid challenging uptime monitors and partners?
Our auditors asked for exactly this kind of incident evidence under DORA.
Could you share the dataset behind the percentages?