Detect Service Exhaustion Flood in Elastic Security
Adversaries may target the different network services provided by systems to conduct a denial of service (DoS). Adversaries often target the availability of DNS and web services through service exhaustion floods. A simple HTTP flood sends a large number of HTTP requests to a web server to overwhelm it and/or an application running on top of it, exhausting various resources required to provide the service. A SSL renegotiation attack takes advantage of a protocol feature in SSL/TLS where the adversary establishes a connection and then proceeds to make a series of renegotiation requests, exploiting the meaningful computational cost of cryptographic renegotiation to degrade or deny service when performed at volume. Both attack types target service availability without requiring exploitation of a software vulnerability.
MITRE ATT&CK
- Tactic
- Impact
- Technique
- T1499 Endpoint Denial of Service
- Sub-technique
- T1499.002 Service Exhaustion Flood
- Canonical reference
- https://attack.mitre.org/techniques/T1499/002/
Elastic Detection Query
// Branch 1: HTTP access log flood detection — high volume from single source
// Run as a threshold rule over 5-minute windows
sequence by source.ip with maxspan=5m
[network where event.dataset == "apache.access" or event.dataset == "nginx.access" or event.dataset == "iis.access"
| keep source.ip, url.path, http.response.status_code, http.response.bytes, user_agent.original, destination.domain]
// NOTE: For threshold-based detection, use the following aggregation query via Elasticsearch API:
// POST /_eql/search with threshold rules, or use the SIEM rule type 'threshold'
// Equivalent aggregation logic:
from logs-*
| where event.dataset in ("apache.access", "nginx.access", "iis.access", "aws.elb_logs")
| where @timestamp > now() - 5m
| stats
total_requests = count(),
unique_uris = count_distinct(url.path),
status_5xx = count(http.response.status_code >= 500),
status_429 = count(http.response.status_code == 429),
distinct_user_agents = count_distinct(user_agent.original),
total_bytes = sum(http.response.bytes)
by source.ip, destination.domain, bucket(@timestamp, "5 minutes")
| where total_requests > 500 or status_5xx > 100
| eval requests_per_second = round(total_requests / 300, 2)
| eval flood_type = case(
unique_uris == 1 and total_requests > 500, "Single-Resource HTTP Flood",
distinct_user_agents == 1 and total_requests > 1000, "Simple HTTP Flood",
status_5xx > 100, "Service Degradation via HTTP Flood",
"HTTP Request Flood"
)
| eval severity = case(
total_requests > 2000 or status_5xx > 500, "critical",
total_requests > 1000 or status_5xx > 200, "high",
"medium"
)
| sort total_requests descDetects T1499.002 Service Exhaustion Flood by identifying HTTP flood patterns from web access logs. Aggregates requests per source IP over 5-minute windows and flags sources exceeding volume thresholds (>500 requests/window) or causing elevated error rates (>100 5xx responses). Covers single-resource floods, simple floods, and service degradation patterns across Apache, Nginx, IIS, and AWS ELB log sources. Complements network-layer detection with application-layer telemetry.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate high-traffic web applications or content delivery events such as a viral post or marketing campaign driving thousands of real users to a single URL in a short window — correlate with marketing calendar and CDN traffic baseline.
- Automated legitimate traffic sources such as web crawlers (Googlebot, Bingbot), uptime monitoring probes (Pingdom, DataDog Synthetics), or CI/CD pipeline health checks that issue many requests from a single IP against a single endpoint.
- Load testing and performance benchmarking tools (Apache JMeter, Locust, k6, Gatling) executed against production or staging environments by internal teams — validate against change management tickets and notify-on-test procedures.
- SSL/TLS certificate validation services and OCSP stapling responders that establish many short-lived connections, potentially triggering SSL renegotiation thresholds.
- Misconfigured API clients or SDK bugs causing retry storms — a single application server sending thousands of identical requests due to an infinite retry loop without backoff.
Other platforms for T1499.002
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1HTTP Flood via Apache Bench (ab)
Expected signal: IIS/Apache access logs: 5000 GET requests from 127.0.0.1 to / within ~30-60 seconds, generating ~83-166 req/sec. Linux syslog: ab process creation if auditd enabled. Web server error logs: likely 500/503 responses if no service is running on port 80. Network flow data: single-flow burst pattern from source 127.0.0.1 to destination 127.0.0.1:80.
- Test 2HTTP Flood via Python requests (cross-platform)
Expected signal: IIS W3C logs: 5000 GET requests from source IP 127.0.0.1 with Python requests User-Agent string within ~10-30 seconds. Windows Security Event 4688 (process create) for python3.exe with command line visible if command line auditing enabled. Sysmon Event 1: python3.exe process creation. Sysmon Event 3: multiple concurrent TCP connections from python3.exe to 127.0.0.1:80.
- Test 3SSL Renegotiation Exhaustion via openssl s_client
Expected signal: Linux syslog/auditd: 20 concurrent openssl s_client process creations. TLS server logs (nginx ssl_error.log or Apache ssl_error.log): TLS renegotiation events or errors. Windows equivalent via Schannel: EventID 36874 or 36888 in System Event Log when server rejects or fails renegotiation. Network packet capture: multiple TLS ClientHello and Handshake records on port 443 followed by TLS Handshake (type 22) renegotiation records within existing sessions.
- Test 4Single-Resource HTTP Flood targeting application endpoint
Expected signal: IIS/Apache access logs: 2000 GET requests to /search from 127.0.0.1 with distinct query strings, all within 2-3 minute window. Sysmon Event 1 (if enabled): multiple curl process creation events. Sysmon Event 3: TCP connections from curl to 127.0.0.1:80. Web server logs: potential 404 or 500 responses if /search endpoint does not exist.
References (9)
- https://attack.mitre.org/techniques/T1499/002/
- https://www.cloudflare.com/learning/ddos/http-flood-ddos-attack/
- https://www.netscout.com/blog/asert/ddos-attacks-ssl-something-old-something-new
- https://pages.arbornetworks.com/rs/082-KNA-087/images/13th_Worldwide_Infrastructure_Security_Report.pdf
- https://learn.microsoft.com/en-us/iis/extensions/dynamic-ip-restrictions/using-dynamic-ip-restrictions
- https://learn.microsoft.com/en-us/windows/win32/secauthn/tls-renegotiation
- https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/ag-overview
- https://docs.splunk.com/Documentation/SplunkCloud/latest/SearchReference/CommonStatsFunctions
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1499.002/T1499.002.md
Unlock Pro Content
Get the full detection package for T1499.002 including response playbook, investigation guide, and atomic red team tests.