AV-09 · DDoS and service exhaustion attacks

Disrupting availability is cheaper and faster than breaching systems. Extortion, distraction during another attack, retaliation, political signaling, competitive disruption — the motivations vary but the mechanism is consistent: make the service unreachable or unusable long enough to cause real harm.

The attack layer matters for the response. Bandwidth saturation at the edge requires different mitigation than a SYN flood exhausting connection tables, which is different again from a targeted request flood against an expensive API endpoint. Defenders who apply the wrong mitigation to the wrong layer slow themselves down.

Many organizations have scrubbing relationships and CDN protections, but still experience prolonged outages during attacks because recognition is slow, escalation paths aren't practiced, and runbooks assume conditions that don't match reality under pressure.

Attackers can flood edge links, exhaust firewall and load balancer connection state tables, saturate application worker pools, or target specific expensive endpoints — like a search function or authentication API — with lower bandwidth that still causes service failure.

Lower-volume attacks are particularly effective when they target asymmetric processing: a request that costs the attacker little but requires significant server-side computation. A well-crafted application-layer attack can take down a service that would survive a much larger volumetric flood.

Watch for concurrent suspicious activity during availability events. DDoS is sometimes a distraction technique while a separate intrusion attempt targets a service that defenders aren't watching closely because they're focused on the traffic flood.

Layered mitigation is the only realistic approach. Upstream scrubbing for volumetric attacks, CDN and WAF protections for application-layer requests, rate limiting and autoscaling for burst traffic, and targeted rate limits on expensive endpoints. No single control handles every attack pattern.

Clear escalation thresholds matter more than most teams realize. Define in advance: at what traffic volume do you call the ISP? At what error rate do you enable emergency rate limits? Which services get prioritized if capacity is constrained? Those decisions made under pressure during an outage are reliably worse than the same decisions made calmly beforehand.

After recovery, review what failed first — capacity, filtering logic, runbook timing, or observability — and improve instrumentation and procedures before the next event. DDoS resilience is as much about operational discipline as it is about technical controls.