Black Friday DDoS With a Ransom Demand
An online retailer's primary site is hit at 13:05 on Black Friday. Inbound traffic jumps from 6 Gbps to 48 Gbps; 70% is SYN flood from 18,000 source IPs, and 8 Gbps is HTTP POST flood hitting /cart/checkout with valid-looking cookies. The scrubbing center is already inline but in monitor mode. The WAF is blocking SQLi but rate limits are set to 500 requests per five minutes per IP. Legitimate traffic is 14 Gbps, and checkout latency has risen from 180 ms to 4.2 s. A ransom note demands 20 BTC in 48 hours. The business says blocking entire countries is unacceptable because 38% of customers are international. The on-call network engineer wants to enable "I'm Under Attack" mode immediately.
1. What should the team do in the first 15 minutes, and how should it sequence mitigation without blocking legitimate international customers?
Read the worked answer
First, move the scrubbing center from monitor to active mitigation and confirm that traffic is actually diverted through it. Enable SYN cookies or SYN authentication at the edge for the flood, and apply a challenge to the HTTP POST flood rather than a blanket block. Raise WAF rate limits only after adding a JavaScript or CAPTCHA challenge for suspicious sessions; the current 500-per-five-minutes rule is both too loose for checkout abuse and potentially too blunt for shared corporate NATs.
Do not block entire countries. Use ASN and IP reputation, but keep allowlists for payment providers, major carriers, and known corporate customers. Enable "I'm Under Attack" mode carefully: it may challenge checkout flows and break API clients, so apply it to browsable paths first and exempt payment callbacks and mobile APIs. Scale origin capacity and cache static assets. Preserve edge logs and packet captures before and after each change.
Sequence matters: activate scrubbing, then SYN defense, then HTTP challenge, then rate-limit tuning. Measure checkout success rate and latency after each step, and roll back any step that drops legitimate conversions.
2. How can the team distinguish attack traffic from a legitimate flash sale, and what metrics should guide tuning?
Read the worked answer
Baseline normal Black Friday behavior: checkout conversion rate, session length, page depth, user-agent mix, TLS fingerprint diversity, and geographic distribution. Attack traffic often shows high request volume with low session depth, repeated cookies, uniform user agents, and many requests to /cart/checkout without preceding product views. A flash sale produces high traffic but real browsing sequences, varied referrers, and normal payment-provider callbacks.
Use canary transactions and synthetic checkout probes to test whether real users can complete a purchase. Track legitimate latency, origin error rate, challenge pass rate, and cart abandonment. If challenge pass rates collapse for a major carrier, the rule is too broad. If origin CPU stays saturated despite scrubbing, the challenge is not filtering enough.
do not optimize solely for dropped packets. The business metric is completed orders. Compare revenue per minute and checkout success before and after each rule. Keep a small allowlist of monitored customer accounts and payment endpoints to detect collateral damage quickly.
3. Should the company pay the ransom, and what post-incident actions are required?
Read the worked answer
Do not pay. Payment does not guarantee stopping the attack, may violate sanctions or insurer requirements, and funds further attacks. The technical controls are already available: scrubbing, SYN defense, HTTP challenges, and rate limiting. Paying also rewards the extortion and may increase future targeting.
Preserve evidence: edge logs, scrubbing-center reports, packet captures, ransom note headers, cryptocurrency addresses, and the timeline of traffic changes. Notify the ISP and scrubbing provider, and consider law enforcement and cyber insurance contacts. Check whether the HTTP flood indicates a broader intrusion or only volumetric pressure; valid-looking cookies can be forged, but they can also indicate session replay or a botnet with real sessions.
After the attack, review capacity headroom, WAF rate limits, runbooks, and the decision to leave scrubbing in monitor mode during peak season. Add automated scrubbing activation thresholds, test "I'm Under Attack" mode against checkout and mobile APIs, and document a communication plan that does not rely on country blocks.