On Monday 3 June 2024 at 20:09 UTC, a memcached amplification targeted a retail banking customer in Latin America. The attack peaked at 136.7 Gbps and lasted 139 minutes. Traffic originated from 3032 autonomous systems in 98 countries, predominantly a headless-browser farm.
| Vector | memcached amplification |
| Peak | 136.7 Gbps |
| Duration | 139 min |
| Time to mitigation | 0.306 s |
| Attack traffic reaching origin | 0.016% |
| Legitimate traffic challenged | 0.08% |
Timeline
The attack was preceded by a publicly announced sales event. Edge packet filters identified the flood by source port and payload signature and dropped it at line rate across 22 points of presence.
What the customer saw
Checkout conversion was unchanged compared with the same hour of the previous week.
Recommendations
- Enable authenticated origin pulls.
- Review allow-listed partner ranges quarterly.
- Lower challenge thresholds on authentication endpoints during high-risk events.
How does the proof-of-work challenge behave on older Android devices? Any numbers below Android 10?
This matches what we see in iGaming around big matches.
Could you share the dataset behind the percentages?
Is the risk score exposed in the logs so we can build our own dashboards on it?
Thanks! Yes — the risk score and its components are included in every log record.
Could you share the dataset behind the percentages?
Solid runbook advice. The DNS-at-2am point hit home.
Interesting that most attacks are under ten minutes. Our experience is similar.
Solid runbook advice. The DNS-at-2am point hit home.