On Tuesday 30 January 2024 at 11:48 UTC, a UDP reflection (DNS) targeted a online payments customer in the Nordics. The attack peaked at 212.2 Gbps and lasted 131 minutes. Traffic originated from 2515 autonomous systems in 22 countries, predominantly residential proxy networks.
| Vector | UDP reflection (DNS) |
| Peak | 212.2 Gbps |
| Duration | 131 min |
| Time to mitigation | 0.050 s |
| Attack traffic reaching origin | 0.062% |
| Legitimate traffic challenged | 0.57% |
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 15 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
- Lower challenge thresholds on authentication endpoints during high-risk events.
- Enable log streaming to your SIEM for faster correlation.
- Enable authenticated origin pulls.
Carpet bombing is nasty. Good to see a clear explanation of it.
Thanks! Yes — the risk score and its components are included in every log record.
Could you share the dataset behind the percentages?
Machine-readable ranges are at /ips.json and via the API.
Nice to read a vendor blog that admits what went wrong.
The point about origin IPs leaking through certificate transparency logs is underrated.
Interesting that most attacks are under ten minutes. Our experience is similar.
Machine-readable ranges are at /ips.json and via the API.
This matches what we see in iGaming around big matches.
Do you publish the edge IP ranges in a machine-readable format?
Good question. We will cover that in a follow-up post.
Thanks — sharing this with our on-call team.
How do you avoid challenging uptime monitors and partners?
Verified good bots and allow-listed partners bypass challenges entirely.