DDoS attacks aim to make a service unavailable by exhausting bandwidth, connections, or application resources. Modern attacks combine volumetric L3/L4 floods (SYN, UDP, DNS amplification) with application-layer (L7) HTTP floods and protocol-abuse attacks (HTTP/2 Rapid Reset, slowloris). Volumes regularly exceed 1 Tbps; HTTP/2 Rapid Reset reached 398 million requests per second.
Effective response requires scrubbing at the edge (Azure DDoS Protection Standard, Cloudflare, Akamai), application-layer protections (WAF rate limiting, bot management), and a tested ISP / DDoS-mitigation contact path. This SOP assumes you have a DDoS protection service in front of your origin; if you don't, getting one is your number-one mitigation step.
◈ Table of Contents
01
Background
CONTEXTB1Attack Vectors & MITRE Mapping
| Vector | MITRE | Signal | Severity |
|---|---|---|---|
| Volumetric L3/L4 (UDP, SYN, ICMP floods) | T1498.001 (Direct Network Flood) | Massive pps/bps spike on edge; small packets to random ports | HIGH |
| Reflection / amplification (DNS, NTP, Memcached, CLDAP) | T1498.002 (Reflection Amplification) | Spoofed source UDP traffic from open resolvers; amplification factor > 50x | HIGH |
| HTTP/HTTPS flood (L7) | T1499.002 (Service Exhaustion Flood) | Sudden RPS spike on a few endpoints; legitimate-looking headers; rotating IPs | HIGH |
| HTTP/2 Rapid Reset (CVE-2023-44487) | T1499 | Massive stream RST_STREAM frames; CPU saturation on TLS endpoints | CRITICAL |
| Slowloris / slow POST | T1499.003 (Application Exhaustion Flood) | Many concurrent connections holding open with trickle data; connection-pool exhaustion | MEDIUM |
| Ransom DDoS (RDDoS) | T1657 (Financial Theft) | Demo flood + email demanding payment in BTC/XMR to stop | CRITICAL |
| DDoS as cover for intrusion | T1498 + parallel TTPs | Loud flood during off-hours coincident with separate quiet probing / login attempts | CRITICAL |
B2Log Sources & Defence Layers
| Source | Tool | Signal |
|---|---|---|
| Azure DDoS Protection | Azure Monitor metrics | UnderDDoSAttack, DDoSTriggerSYNPackets, DDoSTriggerUDPPackets per public IP |
| Front Door / Cloudflare / Akamai | Vendor portal + diagnostic export | Edge mitigations triggered, RPS by country/ASN, action distribution |
| Application Gateway / WAF | AzureDiagnostics | Rate-limit rule hits, custom-rule actions, blocked sources |
| App tier APM / Insights | requests / requests/sec / latency / failure rate | Endpoint-level RPS spikes, slow request trends |
| NetFlow / VPC Flow / sFlow | SIEM | L3 source IP distribution, packet sizes, port spread |
02
Identification
INVESTIGATEDDoS — Investigation Workflow
I1Confirm Attack & Classify VectorKQL
KQL — Azure DDoS Protection metrics
// Confirm UnderDDoSAttack signal on a public IP
AzureMetrics
| where TimeGenerated > ago(2h)
| where MetricName == "IfUnderDDoSAttack"
| where Average > 0
| project TimeGenerated, Resource, Average, _ResourceId
| order by TimeGenerated desc
KQL — Edge RPS & mitigation actions (Front Door)
AzureDiagnostics
| where TimeGenerated > ago(2h)
| where ResourceType == "FRONTDOORS"
| where Category == "FrontDoorAccessLog"
| summarize RPS=count() by bin(TimeGenerated, 1m), clientCountry_s, action_s
| order by TimeGenerated asc, RPS desc
KQL — App-layer endpoint RPS spike
AppRequests
| where TimeGenerated > ago(2h)
| summarize RPS=count() by bin(TimeGenerated, 1m), Url
| top 10 by RPS desc
I2Look for Parallel Intrusion (DDoS as Smokescreen)KQL
KQL — Successful logins during attack window from unusual sources
// Adversaries often pair noisy DDoS with quiet login attacks
SigninLogs
| where TimeGenerated between (datetime(ATTACK_START)..datetime(ATTACK_END))
| where ResultType == 0
| extend Country = tostring(LocationDetails.countryOrRegion)
| where Country !in ("ExpectedCountry1", "ExpectedCountry2") // adjust
| project TimeGenerated, UserPrincipalName, IPAddress, Country, AppDisplayName, ConditionalAccessStatus
| order by TimeGenerated asc
Always assume a DDoS could be cover. Open a second incident track and continue monitoring authentication, control-plane, and EDR alerts independently of the DDoS war room — they should not share the same analyst.
I3FP vs TP Decision Gate
| True-Positive Signals | False-Positive Signals |
|---|---|
| Edge RPS > baseline × 10 with mitigation actions firing | Marketing launch / viral content / planned campaign you weren't briefed on |
| Source distribution is global, low geographic concentration, many ASNs | Concentrated sources from a single ASN you serve (single misbehaving customer) |
| Origin latency & error rate degrading despite edge defences | Origin slow due to unrelated app deploy or DB issue (check change log) |
| Ransom email arriving in tandem with traffic spike | Random extortion email with no actual capacity to flood |
03
Containment / Mitigation
ABSORB ITC1Edge-Layer Mitigation — First 15 MinutesImmediate
- 1Verify edge protection is engaged: Azure DDoS Standard / Cloudflare / Akamai should be auto-mitigating. Confirm via vendor portal that scrubbing is active.
- 2Tighten WAF / Front Door rate limits: Lower per-IP and per-ASN RPS thresholds on the targeted endpoint; enable "Under Attack" mode if available.
- 3Geo / ASN block sources if pattern is clear: If 90% of traffic is from regions you don't serve, block at the edge — use temporarily, lift after attack.
- 4Increase challenge / JS-challenge for unauthenticated paths (especially login, search, expensive API endpoints).
- 5Open vendor ticket: Even with auto-mitigation, file a ticket to engage human DDoS engineers — they can apply tighter rules and tune mitigation.
C2Origin Protection
- 1Verify origin only accepts traffic from your CDN/scrubber IPs: Restrict NSG / Security Group / firewall to vendor IP ranges. If attacker bypassed edge by hitting origin directly, that is the entry point to close.
- 2Scale origin if cost-effective: Auto-scale rules or temporary upscaling can absorb L7 attacks edge can't fully filter.
- 3Tarpit / SYN cookies on origin LB: Confirm SYN-cookie protection is enabled on origin load balancers.
- 4For HTTP/2 Rapid Reset: Apply vendor patches (Nginx, IIS, Apache, Envoy, application servers); set stricter stream limits.
C3If Ransom DDoS — DO NOT PAY
Paying a DDoS ransom funds the actor and marks you for repeat attacks. Standard advice from CISA / Microsoft / NCSC: do not pay. Engage law enforcement (FBI IC3 / local equivalent), preserve the ransom email with full headers, and notify your DDoS mitigation vendor for upstream coordination.
04
Eradication / Post-Attack
CLEAN UPE1Post-Attack Cleanup & Hardening
- 1Capture full attack telemetry: peak pps/bps, vector mix, source ASN distribution, mitigation effectiveness — for after-action and vendor support.
- 2Verify no parallel intrusion succeeded: re-run authentication, control-plane, and EDR queries for the attack window. Hunt with elevated sensitivity for 48 hours.
- 3Lift temporary geo/ASN blocks gradually; keep tightened rate limits that performed well as the new baseline.
- 4Close origin-direct exposure if attacker bypassed edge — origin should be unreachable from public Internet except via your CDN/scrubber.
- 5Run a tabletop with the on-call rota covering the same vector for the next quarter — find the gaps the live attack exposed.
Eradication / After-Action Complete When
- Edge metrics returned to baseline for at least 30 minutes
- Origin only reachable via CDN/scrubber IPs
- Parallel-intrusion hunt complete; no related lateral movement
- Vendor after-action report received; tuning changes applied
- Customer comms / status page updated with resolution
05
Escalation
TIERSESC1Escalation Tiers
| Tier | Trigger | Action / Handoff Bundle |
|---|---|---|
| L1 → L2 | Confirmed traffic spike with mitigation engaged; no customer-visible impact | Target IPs, vector, peak metrics, mitigation actions taken |
| L2 → IR + Network On-Call | Customer-visible degradation or partial outage; origin saturation; protection failing | Vendor ticket #, traffic profile, recent rule changes, parallel-intrusion check status |
| IR → CISO + Comms | Sustained outage; customer SLAs breached; status page update needed; ransom received | Customer comms draft, regulator pre-engagement if relevant, exec dashboard |
| External | Beyond vendor mitigation capacity; sector-wide pattern; ransom paired with attack | ISP / DDoS-mitigation upgrade, sector ISAC notification, law enforcement (FBI IC3 / equivalent) |
Authorized security research & penetration testing only. Unauthorized use is illegal. Authored by Rudra Verma | Senior Security Architect | CyberHawk Threat Intel.