On Friday 8 July 2022 at 12:56 UTC, a GRE flood targeted a electronics retail customer in Western Europe. The attack peaked at 90.7 Gbps and lasted 78 minutes. Traffic originated from 2944 autonomous systems in 71 countries, predominantly residential proxy networks.
| Vector | GRE flood |
| Peak | 90.7 Gbps |
| Duration | 78 min |
| Time to mitigation | 0.144 s |
| Attack traffic reaching origin | 0.029% |
| Legitimate traffic challenged | 0.73% |
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 78 ms during the first minute, then normal service.
Recommendations
- Lower challenge thresholds on authentication endpoints during high-risk events.
- Review allow-listed partner ranges quarterly.
- Add a dedicated rate limit for the targeted route.
The billing model is what got our finance team on board, honestly.
How does the proof-of-work challenge behave on older Android devices? Any numbers below Android 10?
Interesting that most attacks are under ten minutes. Our experience is similar.
Nice to read a vendor blog that admits what went wrong.
Verified good bots and allow-listed partners bypass challenges entirely.
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?
Our auditors asked for exactly this kind of incident evidence under DORA.
Verified good bots and allow-listed partners bypass challenges entirely.
Solid runbook advice. The DNS-at-2am point hit home.