DDoS

DDoS Attack Categories and How They Work

• A Distributed Denial of Service (DDoS) attack overwhelms a target system, service, or network with a flood of traffic from multiple distributed sources, rendering it unavailable to legitimate users.
• MITRE ATT&CK maps this to T1498 (Network Denial of Service) and T1499 (Endpoint Denial of Service).
• DDoS is not a breach — attackers do not gain access to data or systems.
• But the business impact can be severe: revenue loss, reputational damage, and diversion of security resources while the DDoS masks a concurrent data breach (smokescreen tactic).
• Three categories of DDoS attacks, each requiring different detection and mitigation:

Volumetric Attacks (T1498)

Designed to saturate the pipe — the network link between the target and the internet.

• UDP floods. Massive amounts of UDP traffic to random ports. The server checks each port, finds no application listening, and sends ICMP Destination Unreachable responses — consuming resources on both the inbound and outbound side.
• ICMP floods. Ping flood — overwhelming the target with ICMP Echo Request packets.
• DNS amplification. Attacker sends small DNS queries with the target’s spoofed source IP to open DNS resolvers. The resolver sends back a response 50-100x larger than the query. 1 Gbps of query traffic becomes 50-100 Gbps of attack traffic.
• NTP amplification. Same concept using monlist command on open NTP servers — amplification factor up to 556x.
• CLDAP amplification. Connectionless LDAP reflection — amplification factor 46-74x, increasingly used in 2023-2024.

Key signature: Total bandwidth utilization spikes to or near the link capacity. Measured in Gbps.

Protocol Attacks (T1498 / T1499)

Target weaknesses in Layer 3 and Layer 4 protocols, consuming connection state tables on load balancers, firewalls, and servers.

• SYN flood. Attacker sends TCP SYN packets with spoofed source IPs. The server responds SYN-ACK to each, allocates a connection slot in the backlog queue, and waits for the ACK that never comes. Backlog fills, legitimate connections are dropped.
• ACK flood. Flood of TCP ACK packets with spoofed source IPs. Forces the server to process packets through the TCP stack looking for an existing connection — stateless but resource-intensive.
• RST flood. Flood of TCP RST packets attempting to terminate existing connections.
• TCP connection flood. Instead of half-open connections (SYN flood), the attacker completes the TCP handshake and holds connections open.
• Fragmentation attacks. Sending IP fragments that the target must reassemble — high CPU cost.

Key signature: Firewall or load balancer connection table utilization spikes. Measured in packets per second (PPS) — link may not be saturated but the middlebox CPU is.

Application-Layer Attacks (T1499)

Target specific application functions with low-volume traffic that looks legitimate. Hardest to detect because each individual request appears benign.

• HTTP flood. Attacker sends seemingly valid HTTP GET or POST requests. Often targets the most expensive endpoint: search, login, file upload.
• Slowloris. Opens many connections to the target web server. Sends partial HTTP requests — sending headers one line at a time with long delays. Keeps connections open, exhausting the server’s connection pool.
• Slow POST. Sends the HTTP headers normally, then sends the POST body at extremely slow speed (e.g., 1 byte per 100 seconds). The server keeps the connection open waiting for the complete body.
• GraphQL abuse. Sending expensive nested queries — aliasing the same query dozens of times in a single request. One request can trigger hundreds of database queries.
• API abuse. Specific API endpoints (e.g., /api/recommend, /api/export) are hit at high volume. Each request validates and returns real data.

Key signature: Low bandwidth (often < 1 Gbps) but high CPU/DB load on application servers. Application logs show a flood of requests to specific endpoints from distributed IPs.

Detection Workflow — DDoS Triage

Step 1: Identify the Attack Type

When a customer or monitoring system reports an outage, determine which layer is under attack:

Step 2: Collect Critical Log Sources

SPL query — detect bandwidth spike from netflow:

index=netflow sourcetype=netflow
| timechart span=1m sum(bytes) as bps by src_ip, dst_ip
| eval mbps = bps * 8 / 1048576
| where mbps > 100
| stats avg(mbps) as AvgMbps, max(mbps) as PeakMbps by src_ip, dst_ip
| sort - PeakMbps

SPL query — detect SYN flood by filtering for incomplete handshakes:

index=firewall sourcetype=firewall_traffic
| search action=blocked AND tcp_flags="S" (SYN-only packets)
| timechart span=1m count by src_zone
| where count > 10000
| eval alert = "POSSIBLE SYN FLOOD — incomplete handshakes detected"

SPL query — detect HTTP flood to specific endpoint:

index=web sourcetype=iis_access OR sourcetype=apache_access
| search cs_uri_stem="/api/search" OR cs_uri_stem="/api/login"
| timechart span=1m count by ClientIP
| eventstats avg(count) as avg_count, stdev(count) as stdev_count
| where count > (avg_count + 5*stdev_count)
| eval severity = if(count > 1000, "CRITICAL — HTTP flood in progress", "HIGH — endpoint under unusual load")

Step 3: Determine the Attack Signature

Step 4: Mitigate by Attack Type

Step 5: Check for Smokescreen

DDoS attacks are frequently used to distract the SOC while the real attack happens elsewhere:

• Check EDR alerts during the DDoS window — are there new process executions, lateral movement, or privilege escalation attempts?
• Review authentication logs — did a wave of failed logins coincide with the DDoS?
• Check for phishing reports or email anomalies during the same period
• Review VPN connections — unexpected users or new accounts logging in during the DDoS window
• Correlation with cloud provider alerts — are API calls being made from unusual IPs?

SPL query — correlate DDoS with authentication anomalies:

index=auth sourcetype=windows_security EventCode=4625
| timechart span=5m count as FailedLogins
| append [search index=netflow sourcetype=netflow | timechart span=5m sum(bytes) as Bandwidth]
| fillnull value=0
| where FailedLogins > 100 AND Bandwidth > 500000000
| eval alert = "SMOKESCREEN — DDoS + credential attack in progress"

DDoS Response — What to Do During an Active Attack

Immediate (first 5 minutes)

• Identify the attack type — volumetric, protocol, or application layer. Check bandwidth, PPS, and application latency.
• Activate scrubbing — trigger BGP diversion to your DDoS protection provider. This takes 1-5 minutes for most providers.
• Notify stakeholders — alert the SOC lead, network operations, and the affected service owner.
• Preserve evidence — start packet capture (tcpdump, netflow, or full packet capture) at the edge. This is critical for post-incident analysis and potential legal action.
• Block attack source IPs if the attack is from a small number of IPs (rare — most DDoS uses distributed botnets or reflection).

Within 15 minutes

• Verify scrubbing is working — check that legitimate traffic is passing through and attack traffic is being dropped. Monitor bandwidth graphs.
• Apply WAF rate limiting — if it is an application-layer attack, enable rate limiting on the affected endpoints.
• Scale up — add more web servers / application instances if the attack is at the application layer.
• Check for smokescreen — review authentication logs, EDR alerts, and phishing reports for any concurrent attacks.

During recovery

• Monitor for attack changes — attackers often shift tactics when the first vector is blocked (volumetric → protocol → app layer). Stay alert.
• Communicate status — provide regular updates to stakeholders and, if public-facing, a status page.
• Collect post-attack IOCs — extract source IPs, attack patterns, and tool signatures from pcap data.

After the attack

• Post-mortem — analyze mitigation effectiveness. Was the scrubbing activated quickly enough? Were there false positives on legitimate traffic?
• Update DDoS runbook — document lessons learned. Add new detection rules for the attack pattern.
• Review smokescreen possibility — was there any data exfiltration, credential theft, or lateral movement during the DDoS window?
• Tune thresholds — adjust monitoring thresholds to catch the next attack earlier.
• Report — if a crime, file a report with law enforcement (FBI IC3 or local cybercrime unit).

Preventative Controls

Related

• API Attacks — OWASP API Top 10 — detection and response for T1190 techniques
• Wireless Attacks — detection and response for T1600 techniques
• Cloud Threats — Credential Theft, IMDS Abuse, Hijacking, Privilege Escalation — detection and response for T1525, T1552, T1613 techniques
• Snort and Suricata — detection and response for T1040 techniques

Sources

• Cloudflare DDoS Guide
• MITRE ATT&CK T1498
• CISA DDoS Quick Guide
• AWS Shield — DDoS Best Practices
• NIST SP 800-61 Rev 2 — DDoS Handling
• US-CERT — DDoS Guidance