What To Do When You’re Under a DDoS Attack

DDoS protection gaps usually become visible when there is the least room to investigate them: during an active attack. Traffic volumes rise, services begin to degrade, and the response team has to determine whether the issue is attack volume, routing, mitigation coverage, application-layer bypass, or an exposed asset that was never protected in the first place. At that stage, every unclear ownership path or unvalidated assumption slows the response.

Red Button saw this in a live financial services incident: an organization that found itself under a DDoS attack (60 Gbps of UDP reflection traffic), despite having mitigation in place. The problem was the unprotected network segments that had never been routed through the scrubbing center. The result? A 15-minute service disruption that could have been avoided with validated coverage and routing procedures.

Key Takeaway

A successful DDoS response depends on fast coordination, validated mitigation coverage, and clear escalation paths. This post explains how to confirm an active DDoS attack, contain the impact, identify protection gaps, and strengthen your defenses in the 72 hours after the incident ends. 

First, Confirm It’s Actually a DDoS Attack

Before triggering a full incident response, rule out the alternatives. Misdiagnosing the cause of a traffic spike wastes time and pulls resources away from the real problem.

Check whether a recent configuration push or failed deployment is causing an internal infrastructure failure. Verify whether a product launch, marketing campaign, or external media event could explain the surge in legitimate traffic. Confirm with your ISP or upstream provider that there’s no broader outage affecting your region or peering points.

If none of those explain the spike, these are the indicators that you’re dealing with a DDoS attack:

• A sudden inbound traffic spike with no corresponding business trigger
• Unusual traffic profile — abnormally high SYN, UDP, or ICMP packet ratios relative to baseline
• Requests concentrated on a single endpoint, API route, or service
• Latency and error rate spikes disproportionate to the traffic volume increase
• An alert from your mitigation vendor without a matching business event

Once you’ve confirmed it’s a DDoS attack, the priority is speed and coordination. Every minute without a structured response is a minute the attack continues unchecked.

Phase 1 — During the Attack: Immediate Response Steps

Step 1 — Activate Your Incident Response Chain

Alert your SOC and NOC immediately and escalate per your runbook. If your organization has a pre-established war room protocol, activate it now. The room should include your network team, application owners, ISP contact, mitigation provider representative, and any external incident response partner already under contract.

Every person in that room needs to know their role before they sit down. Decisions about traffic routing, escalation authority, and external communications cannot be made by committee in the middle of an attack. If no runbook exists, document the response chain in real time and treat formalization as a mandatory post-incident deliverable.

The absence of pre-established escalation paths is consistently the primary driver of extended outages and not the attack volume itself. When Red Button responded to a ransom-driven DDoS attack on a Latin American bank, the initial 60 Gbps attack caused a 15-minute disruption because no escalation paths or traffic routing procedures had been defined in advance. After Red Button formalized both, a second 60 Gbps attack 24 hours later caused zero disruption. Same attacker, same volume, completely different outcome — because the response infrastructure existed this time.

Step 2 — Identify the Attack Vector(s)

Pull traffic logs from your network components, security appliances, WAF, mitigation provider dashboards, and upstream ISP. The goal is to classify the attack by layer before attempting mitigation, because the response to a volumetric L3 flood is different from the response to an L7 application-layer attack.

Layer	Attack Types	Target
L3 Volumetric	UDP floods, ICMP floods, encapsulation floods	Bandwidth saturation
L4 Protocol	SYN floods, ACK floods, fragmented packets	Network device resources, connection tables
L7 Application	HTTP GET/POST floods, large file downloads, API floods	Server resources, proxy exhaustion

Understanding the types of DDoS attacks you’re facing is what determines which mitigation controls apply. Do not assume a single vector. Multi-vector attacks that combine volumetric and application-layer techniques simultaneously are now standard practice for sophisticated threat actors. Responding to one layer while another continues unchecked will extend the outage regardless of how well the first response is executed.

Step 3 — Engage Your DDoS Mitigation Provider

Confirm that traffic is actively being routed through your scrubbing center, CDN, or ISP cleanpipe. Then verify that protection measures are actually engaged and functioning — rate-limit rules firing, bot detection active, traffic thresholds triggering as configured. Do not assume that because a system is deployed, it is working as intended.

If mitigation is active but the attack persists, the most likely explanations are a misconfiguration somewhere in the stack, an application-layer bypass that the scrubbing layer isn’t catching, or an unprotected service segment that traffic is reaching directly.

This is a well-documented failure pattern. Red Button’s simulation testing at a Central American bank found that all six simulated attacks bypassed AWS Shield Advanced due to a single misconfiguration: a Regional API Gateway had been deployed without CloudFront, which disabled Shield Advanced’s L7 protection entirely. The bank had a licensed, enterprise-grade DDoS protection product — and it wasn’t protecting the most exposed attack surface. That gap was found in a controlled DDoS test. It would have been found the same way in a live attack, with significantly higher consequences.

Step 4 — Protect All Services

While your mitigation provider is handling the primary attack traffic, conduct a parallel sweep for unprotected exposure. Identify any assets not currently routed through your mitigation layer, including internal-facing services inadvertently exposed, staging environments with public IPs, and any recently deployed infrastructure not included in the original protection scope.

If application-layer resources are exhausted and you cannot quickly route additional assets through mitigation, temporarily restrict access to non-critical endpoints. This reduces the attack surface while you work on the primary problem.

Implement an ad-hoc emergency policy to contain the attack on specific services. Geo-restricting traffic from the attacker’s origin country is a practical, immediate measure when the source geography is identifiable from your traffic logs. It won’t stop a sophisticated attacker using distributed infrastructure, but it reduces noise and buys time.

Step 5 — Document Everything in Real Time

Under attack conditions, documentation feels like a low priority. It isn’t. Timestamp every action taken, every escalation path activated, and every decision made. Capture traffic logs, firewall logs, WAF logs, and screenshots of mitigation provider dashboards at regular intervals throughout the event.

This serves multiple purposes simultaneously. It validates your emergency playbook against real conditions. It provides the raw data needed for a thorough post-mortem. It supports root cause analysis when you’re trying to establish exactly where and why the first disruption occurred. And it satisfies regulatory disclosure requirements under DORA, FFIEC, and FCA — frameworks that require documented evidence of incident response, not just a summary account of what happened.

The documentation you capture during the attack also serves as the baseline for future DDoS simulation testing, allowing you to compare controlled test conditions with what actually happened in a live event.

Phase 2 — After the Attack: What To Do Within 72 Hours

The attack is over. Services are restored. The instinct in most organizations is to exhale, write a brief incident summary, and return to normal operations. But that instinct is wrong. The 72-hour window after a DDoS attack is when organizations either fix what broke or leave it broken for the next attacker to find. Restoration is not resolution — the real work starts now.

Conduct a Full Post-Mortem

Assemble your network team, application owners, and mitigation provider for a structured post-mortem. Work through the following questions with specificity:

• Which attack vectors were detected and mitigated? Which were not, and why?
• Where did the attack first cause disruption? Was it bandwidth exhaustion, connection table overflow, application layer failure, or something else?
• Which protection layers performed as expected? Which failed, at what traffic threshold, and under what conditions?
• Did your mitigation provider meet its SLA? If not, what is the contractual recourse and what does that mean for your provider relationship?
• Were your runbook procedures followed? Were they efficient under real conditions? What gaps became apparent that didn’t exist on paper?

An Israeli bank that engaged Red Button for simulation testing discovered that its ISP-managed cleanpipe couldn’t handle low-volume, standard attacks — SYN, ACK, and UDP floods were only partially mitigated. The first application-layer simulation had to be terminated early because protection failed on scenario one of three. This wasn’t a sophisticated, high-volume attack that overwhelmed a capable system. It was a standard test scenario that exposed fundamental gaps no one knew existed. The bank’s initial DDoS Resiliency Score was 3.0. Post-remediation it reached 4.7, with a documented path to 6.5 through further architectural improvement.

Close the Gaps Before the Next Attack

Post-incident findings from Red Button engagements across financial services consistently surface the same categories of exposure. If your post-mortem identifies any of the following, treat them as urgent remediation items:

• HTTP payload size limits not enforced — unrestricted request bodies allow attackers to exhaust server resources with a small number of requests
• WAF rate-limit thresholds too permissive — permissive default configurations are a systemic problem across financial deployments; they need to be tuned against your actual traffic baseline, not left at vendor defaults
• Public assets not fully routed through CDN or scrubbing layer — unprotected segments are the most consistent entry point in post-incident findings
• Manual traffic diversion still in place — every minute of manual process between attack detection and diversion adds directly to customer-facing downtime
• Static assets not cached at the CDN layer — proper caching maintains partial service availability during origin-targeted attacks, reducing the blast radius significantly
• No external managed DNS service — DNS infrastructure is frequently unprotected and is a common attack target precisely because defenders don’t treat it as part of the DDoS attack surface

None of these gaps require procuring a new tool. Knowing how to protect against a DDoS attack at the configuration level is what separates teams that recover cleanly from those that face the same failure twice.  

Test Before the Next Attack Finds You

Closing a gap and confirming that the fix holds under real attack conditions are two different things. Configuration changes introduce new variables. Architectural changes can create unintended exposure elsewhere. The only way to confirm that remediation actually worked is to test it under controlled attack conditions before a real attacker does it for you.

Controlled simulation testing after remediation lets you validate each fix against the specific vectors that caused problems, stress-test the updated configuration at realistic traffic volumes, and confirm that your runbook changes actually improve response time. Red Button’s DDoS Resiliency Score framework quantifies current resilience against an industry benchmark, making the gap between your current posture and the required posture measurable and trackable over time. Simulation testing under this framework also satisfies DORA Article 26, ISO 27001, and SOC 2 requirements for documented resilience validation, satisfying regulatory requirements and improving actual security posture at the same time.

What You Should Have in Place Before an Attack

If you’re doing post-incident planning, proactive preparation, or looking to prevent a DDoS attack before one materializes, the checklist below is your operational baseline:

• DDoS incident response runbook with named escalation paths and defined decision authority
• Full inventory of all publicly exposed assets, their hosting environment, and their protection status
• Configured and validated security rules — WAF rate limits, blocklists, allow lists, and bot management policies tuned against real traffic
• Mitigation provider contacts reachable 24/7, with escalation contacts above the first-line support tier
• DNS protection in place — managed DNS or a dedicated DNS protection service
• Automatic traffic diversion configured and tested — not manual
• DDoS simulation test completed within the last 12 months

Use this DDoS testing checklist to assess your readiness before running a simulation. One item on that list that organizations running cloud infrastructure consistently underestimate: cloud-native DDoS protection is not automatic. When Red Button tested an accounting firm’s Azure environment, the assumptions built into the architecture proved to be the primary source of exposure — a pattern that recurs across both financial services and professional services deployments. 

Conclusion

An effective DDoS response depends on preparation that has been tested before an attack begins. During an incident, teams need to know which assets are protected, how traffic should be routed, who owns each decision, and whether mitigation controls are working as expected.

After the attack, those same areas need to be reviewed with evidence rather than assumptions. Any gap in coverage, routing, escalation, or control behavior should be remediated and tested again under controlled conditions.

If you need a confirmed answer on whether your defenses will actually hold, Red Button’s DDoS readiness testing delivers one. Prevent a DDoS attack from becoming a preventable outage — contact Red Button to schedule a simulation.

FAQs

How do you know if you’re under a DDoS attack?

Common signs include sudden traffic spikes without a business reason, increased latency, SYN or UDP flood activity, application outages, and mitigation alerts from your provider. Reviewing traffic patterns and ruling out internal failures is the first step.

What should you do first during a DDoS attack?

Immediately activate your incident response process, alert your SOC and NOC teams, and confirm that traffic is being routed through your DDoS mitigation provider or scrubbing service.

Why do DDoS protections sometimes fail?

DDoS protections often fail because of unprotected assets, routing misconfigurations, weak WAF rules, or application-layer attack paths that bypass mitigation controls.

What should organizations review after a DDoS attack?

Teams should conduct a full post-mortem, identify gaps in protection coverage, validate mitigation performance, review escalation procedures, and run simulation testing to confirm fixes before the next attack.