On Saturday 20 April 2024 at 17:08 UTC, a memcached amplification targeted a ticketing customer in the Middle East. The attack peaked at 121.3 Gbps and lasted 167 minutes. Traffic originated from 2342 autonomous systems in 65 countries, predominantly a Mirai-derived IoT botnet.
| Vector | memcached amplification |
| Peak | 121.3 Gbps |
| Duration | 167 min |
| Time to mitigation | 0.883 s |
| Attack traffic reaching origin | 0.014% |
| Legitimate traffic challenged | 0.64% |
Timeline
The attack was preceded by a ransom note demanding payment in Monero. Edge packet filters identified the flood by source port and payload signature and dropped it at line rate across 39 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.
- Enable log streaming to your SIEM for faster correlation.
- Lower challenge thresholds on authentication endpoints during high-risk events.
The billing model is what got our finance team on board, honestly.
Any plans to support per-tenant limits keyed on a JWT claim?
Machine-readable ranges are at /ips.json and via the API.
Great write-up. We saw almost the same pattern on our login endpoint last month.
Verified good bots and allow-listed partners bypass challenges entirely.
We had the exact false-positive issue with CGNAT carriers. The weighting change makes sense.
Good question. We will cover that in a follow-up post.
Nice to read a vendor blog that admits what went wrong.
Nice to read a vendor blog that admits what went wrong.
Verified good bots and allow-listed partners bypass challenges entirely.
The billing model is what got our finance team on board, honestly.