On Saturday 14 December 2024 at 08:15 UTC, a ACK flood targeted a retail banking customer in Central Europe. The attack peaked at 180.3 Gbps and lasted 105 minutes. Traffic originated from 3020 autonomous systems in 90 countries, predominantly compromised cloud VMs.
| Vector | ACK flood |
| Peak | 180.3 Gbps |
| Duration | 105 min |
| Time to mitigation | 0.587 s |
| Attack traffic reaching origin | 0.052% |
| Legitimate traffic challenged | 0.65% |
Timeline
The attack was preceded by a breaking political story. Edge packet filters identified the flood by source port and payload signature and dropped it at line rate across 17 points of presence.
What the customer saw
The customer’s status page stayed green throughout; they learned about the attack from our notification.
Recommendations
- Enable log streaming to your SIEM for faster correlation.
- Keep origin IPs out of public DNS history.
- Lower challenge thresholds on authentication endpoints during high-risk events.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
The billing model is what got our finance team on board, honestly.
How do you avoid challenging uptime monitors and partners?
Clear and practical, thanks.
Good question. We will cover that in a follow-up post.
How do you avoid challenging uptime monitors and partners?
Do you publish the edge IP ranges in a machine-readable format?
This matches what we see in iGaming around big matches.
Great write-up. We saw almost the same pattern on our login endpoint last month.