On Sunday 15 August 2021 at 19:16 UTC, a ACK flood targeted a B2B SaaS customer in Western Europe. The attack peaked at 388.9 Gbps and lasted 125 minutes. Traffic originated from 2136 autonomous systems in 73 countries, predominantly a rented booter service.
| Vector | ACK flood |
| Peak | 388.9 Gbps |
| Duration | 125 min |
| Time to mitigation | 0.936 s |
| Attack traffic reaching origin | 0.012% |
| Legitimate traffic challenged | 0.19% |
Timeline
The attack was preceded by a hacktivist channel announcing the target. Edge packet filters identified the flood by source port and payload signature and dropped it at line rate across 27 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.
- Lower challenge thresholds on authentication endpoints during high-risk events.
- Keep origin IPs out of public DNS history.
We had the exact false-positive issue with CGNAT carriers. The weighting change makes sense.
Great write-up. We saw almost the same pattern on our login endpoint last month.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
Do you publish the edge IP ranges in a machine-readable format?
Our auditors asked for exactly this kind of incident evidence under DORA.
Thanks! Yes — the risk score and its components are included in every log record.
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.
Our auditors asked for exactly this kind of incident evidence under DORA.
Clear and practical, thanks.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.