# 🌊 DDoS Attack — Starter Kit

> Complete starter bundle for ddos attack incident response.

**Generated:** 2026-04-18

---

## Part 1: IR Cheatsheet

### Triage
- **DDoS Characterization** (P1, ~30m)
  1. Determine attack layer from traffic telemetry: L3/L4 (SYN flood, UDP flood, ICMP flood) shows high pps and bps with repetitive small packets; L7 shows HTTP/HTTPS request spikes with plausible-looking requests but abnormal sources or patterns.
  2. Identify the specific vector: SYN flood, UDP amplification (DNS, NTP, Memcached, SSDP, CLDAP), TCP reflection (RST, ACK), HTTP flood, Slowloris, application-layer cache-buster, search-expensive query flood.
  3. Measure magnitude: peak pps, peak bps, peak RPS for L7; compare to baseline and to provider-side capacity to determine if upstream scrubbing is required.

### Containment
- **DDoS Mitigation** (P1, ~240m)
  1. Route traffic through upstream scrubbing (BGP redirection, DNS redirection to scrubbing provider anycast, on-demand cloud WAF activation) for volumetric attacks.
  2. Apply rate limiting at edge: per-IP, per-subnet, per-session rate limits on affected endpoints; aggressive but not blocking legitimate users unless necessary.
  3. For clear source concentrations, apply geo-blocking or ASN-blocking at the edge; revert once attack subsides to restore legitimate traffic.

### Post-Incident Review
- **DDoS Resilience** (P2, ~180m)
  1. Evaluate mitigation latency: time from attack start to detection, time to scrubbing activation, time to full mitigation. Compare to SLAs and target goals.
  2. Evaluate capacity: at peak, what percentage of attack traffic was mitigated upstream, at the CDN, at the WAF, at origin? Identify the layer closest to origin that became saturated.
  3. Evaluate architectural resilience: are origins behind scrubbing protected by IP allowlisting? Are DNS TTLs short enough for rapid redirection? Is there geo-redundant failover?

## Part 2: Key Artifacts

### NetFlow / sFlow / IPFIX Records
**Location:** `NetFlow collector (e.g., nfdump files, SiLK repository, or SIEM ingestion)`
**Value:** Flow data provides long-term network visibility where full PCAP retention is not feasible due to storage costs. Flow records reveal C2 beaconing patterns through periodic connections of consistent size and interval to the same destination. Large outbound byte counts to unusual destinations indicate data exfiltration. Lateral movement appears as new internal-to-internal flows on management ports (RDP 3389, SMB 445, SSH 22) that did not exist before the compromise window.

### Firewall Logs (Allow/Deny)
**Location:** `Firewall management console or syslog server (vendor-specific: Palo Alto, Fortinet, pfSense, iptables)`
**Value:** Firewall deny logs reveal attacker reconnaissance -- repeated blocked connections to internal IPs on sequential ports indicate port scanning. Allowed connections to known-malicious IPs that were later added to threat feeds retroactively identify early compromise indicators. Outbound allow logs to unusual destination countries or non-standard ports (e.g., TCP 4444, 8888) expose C2 and exfiltration channels. Rule-name correlation shows which firewall policies the attacker exploited.

### Load Balancer Access Logs
**Location:** `Load balancer logs (F5 BIG-IP, AWS ALB/NLB, Azure Application Gateway, HAProxy, Nginx)`
**Value:** Load balancer logs capture the true client IP address before it reaches backend servers, which is critical when backend application logs only show the load balancer IP. Request distribution patterns reveal which backend servers handled attacker traffic. Health check failures may indicate backend server compromise or denial of service. TLS negotiation details expose outdated cipher usage. Connection rate and error patterns help reconstruct the timeline of web application attacks.

### Web Application Firewall (WAF) Logs
**Location:** `WAF console or logs (AWS WAF, Azure WAF, Cloudflare, Akamai, Imperva, F5 ASM, ModSecurity)`
**Value:** WAF logs capture the actual attack payloads used in web application exploitation attempts, including SQL injection queries, XSS payloads, command injection strings, and path traversal sequences. Blocked request logs reveal attack techniques the adversary attempted unsuccessfully. JA3/JA3S TLS fingerprints in WAF logs identify specific attacker tools and C2 frameworks. Bot classification distinguishes automated scanning from targeted manual exploitation. Rate limiting and GeoIP logs provide additional attacker profiling data.

## Part 3: Key Queries

### DDoS Characterization
```
index=netflow earliest=-1h | stats sum(bytes) as bytes sum(packets) as packets by src_ip, dst_port | sort -packets | head 100
```

```
index=proxy sourcetype=nginx earliest=-1h | stats count dc(uri_path) as distinct_paths by src_ip | where count > 1000 and distinct_paths < 5
```

### DDoS Mitigation
```
What is the upstream scrubbing provider currently mitigating (pps, bps, RPS), and what is bypassing mitigation?
```

```
What WAF rules are currently active for the DDoS event, and what is their block rate?
```

### DDoS Resilience
```
Do our DNS TTLs allow rapid redirection to scrubbing, or did they delay our response?
```

```
Is our origin protected from direct attack if scrubbing is bypassed?
```

---
*Generated by DFIR Assist*