DDoS Tabletop Exercise: Peak-Season Outage and Extortion

Distributed denial-of-service (DDoS) attacks are an availability problem, a customer-communication problem and sometimes a distraction from something quieter. Most organisations rely on a CDN, a cloud provider or a scrubbing service for protection, and assume that is enough. A tabletop tests the parts that contracts and dashboards don't cover: escalation to providers, configuration decisions under pressure, status-page communication and business trade-offs while revenue is lost.

This scenario is a good foundational exercise for IT operations, SRE, communications and business leadership. It needs little forensic depth and works well as a first exercise for teams whose main risk is availability.

Scenario at a glance

Exercise objectives

1. Confirm the process and contacts for escalating to the ISP, CDN and DDoS mitigation provider, including out-of-hours paths.
2. Identify who can authorise emergency configuration changes (rate limits, geo-blocking, "under attack" modes) and their business impact.
3. Validate customer and internal communications during an outage: status page, social media, support scripts and approvals.
4. Decide how to handle an extortion demand, including law-enforcement engagement.
5. Ensure security monitoring continues during the outage to detect any parallel intrusion.

Starting situation

Read this aloud to players:

It is the Friday of your biggest sales weekend of the year, 11:00. Marketing has launched a campaign and traffic is already well above normal. Your website and public API sit behind a CDN with DDoS protection; your API also serves a mobile app and several partner integrations.

Your operations team is on normal staffing; extra support staff have been scheduled for the weekend.

Injects timeline

Module 1 — Is it an attack? (T+00:00 to T+00:40)

Inject 1. At 11:00, dashboards show checkout latency rising from under a second to many seconds and API error rates climbing. Traffic is high, but marketing expected that.

Inject 2. The network engineer sees a large volumetric UDP flood hitting one of your origin IP addresses directly, not via the CDN. The upstream link is saturated.

Inject 3. The CDN dashboard shows a large HTTP request flood from many IP addresses, concentrated on search and login endpoints, with request patterns that look almost like real browsers.

Discussion questions:

• How do you distinguish a successful campaign from an attack? Who makes that call?
• Why is an origin IP reachable directly? Who can contact the ISP or hosting provider for upstream filtering, and how, on a Friday?
• Does your DDoS provider contract include emergency support? Who is authorised to open a priority case?
• Which application-layer mitigations are available (rate limiting, bot management, challenge pages), and who can enable them?

Module 2 — Customers and extortion (T+01:10 to T+03:00)

Inject 4. Customers post screenshots of error pages on social media; some claim the company has been hacked. The support queue grows faster than agents can handle.

Inject 5. The security mailbox receives an email: the sender claims responsibility and threatens to continue and escalate attacks all weekend unless a cryptocurrency payment is made within 24 hours.

Inject 6. The provider proposes strict geo-blocking and challenge pages for all traffic. The product owner warns this will break a key partner's server-to-server integration and block legitimate customers in some countries.

Discussion questions:

• Who updates the status page and social channels? Is there a pre-approved message? How often do you update?
• What do support agents tell customers? Is there a script?
• Is the extortion email credible? How would you assess it? Who handles contact with law enforcement?
• Who owns the decision to accept blocking legitimate traffic to restore service for most customers? How is the partner informed?

Module 3 — The quiet problem and recovery (T+04:30 to T+24:00)

Inject 7. In the middle of the incident, the security analyst notices successful logins to the e-commerce admin back office from an unfamiliar IP address, using a staff account.

Inject 8. By Saturday morning the attack has subsided. The COO asks for an estimate of lost revenue and a list of what must change before next year's peak.

Discussion questions:

• Is the DDoS a distraction? Who investigates the admin logins while operations fights the outage?
• How do you balance resources between availability and investigating a possible intrusion?
• How do you estimate the impact credibly, and who needs it (finance, insurer, board)?
• What changes: origin protection, provider contracts, runbooks, capacity, communication templates?

Discussion questions

• Escalation: Are ISP and DDoS-provider emergency contacts documented, tested and reachable out of hours?
• Architecture: Which endpoints are not protected, and why?
• Authority: Who can make changes that knowingly block legitimate customers?
• Communications: Is the status page hosted independently of the infrastructure under attack?
• Security: Does someone own security monitoring when everyone is focused on availability?

Curveballs / optional injects

• The status page is hosted on the same infrastructure and is also down.
• The DDoS provider's support line has a long queue; your account manager is on holiday.
• A competitor's site is also down; media speculate about a coordinated campaign.

Facilitator notes

Expected decisions. A mature team identifies the attack quickly, escalates to upstream and mitigation providers early, protects or re-hides the origin, applies targeted application-layer controls, makes an explicit business decision about blocking legitimate traffic, communicates regularly, handles the extortion note through a structured process with law-enforcement contact, and keeps a separate eye on security telemetry.

Common pitfalls.

• Treating the slowdown as campaign load for too long.
• Discovering during the incident that the origin is directly reachable.
• Only one person knows how to change CDN rules.
• Silence on public channels while engineers work, letting speculation fill the gap.
• Everyone working the outage; nobody investigating the admin logins.

Adapting the audience. For executives, focus on injects 4 to 6 and 8. For engineers, deepen Module 1 with specific mitigation steps, provider interfaces and the order of operations for re-hiding an exposed origin.

Evaluating the exercise

Related

• Ransomware tabletop scenario
• Facilitating a tabletop exercise
• Writing the after-action report
• Glossary: out-of-band communications, recovery time objective