On Monday 10 January 2022 at 04:44 UTC, a ACK flood targeted a gaming community customer in the Middle East. The attack peaked at 310.8 Gbps and lasted 58 minutes. Traffic originated from 1713 autonomous systems in 40 countries, predominantly misconfigured open reflectors.
| Vector | ACK flood |
| Peak | 310.8 Gbps |
| Duration | 58 min |
| Time to mitigation | 0.191 s |
| Attack traffic reaching origin | 0.012% |
| Legitimate traffic challenged | 0.63% |
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 35 points of presence.
What the customer saw
A brief increase in p99 latency of 21 ms during the first minute, then normal service.
Recommendations
- Enable log streaming to your SIEM for faster correlation.
- Enable authenticated origin pulls.
- Review allow-listed partner ranges quarterly.
Great write-up. We saw almost the same pattern on our login endpoint last month.
Great to hear, thanks for sharing your experience.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
Great write-up. We saw almost the same pattern on our login endpoint last month.
The billing model is what got our finance team on board, honestly.
Thanks! Yes — the risk score and its components are included in every log record.
Thanks — sharing this with our on-call team.
The point about origin IPs leaking through certificate transparency logs is underrated.
How does the proof-of-work challenge behave on older Android devices? Any numbers below Android 10?
Great to hear, thanks for sharing your experience.