Detect Service Exhaustion Flood in Splunk
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/
SPL Detection Query
| multisearch
[ search index=web sourcetype=iis
| eval _src_ip=c_ip, _target=cs_host, _uri=cs_uri_stem,
_status=sc_status, _ua=cs_user_agent, _bytes=sc_bytes,
_detection_source="IIS_Log" ]
[ search index=web sourcetype="access_combined" OR sourcetype="access_log"
| eval _src_ip=clientip, _target=host, _uri=uri,
_status=status, _ua=useragent, _bytes=bytes,
_detection_source="Apache_Access_Log" ]
| bin _time span=5m
| stats
count as TotalRequests,
dc(_uri) as UniqueURIs,
count(eval(_status>=500)) as Status5xx,
count(eval(_status==429)) as Status429,
dc(_ua) as DistinctUserAgents,
sum(_bytes) as TotalBytesSent,
values(_detection_source) as DetectionSource
by _time, _src_ip, _target
| where TotalRequests > 500 OR Status5xx > 100
| eval RequestsPerSecond=round(TotalRequests / 300, 2)
| eval FloodType=case(
UniqueURIs==1 AND TotalRequests>500, "Single-Resource HTTP Flood",
DistinctUserAgents==1 AND TotalRequests>1000, "Simple HTTP Flood",
Status5xx>100, "Service Degradation via HTTP Flood",
true(), "HTTP Request Flood"
)
| eval Severity=case(
TotalRequests > 2000 OR Status5xx > 500, "High",
TotalRequests > 1000 OR Status5xx > 200, "Medium",
true(), "Low"
)
| table _time, _src_ip, _target, TotalRequests, RequestsPerSecond, UniqueURIs,
Status5xx, Status429, DistinctUserAgents, FloodType, Severity, DetectionSource
| sort - TotalRequests
| appendcols
[ search index=network sourcetype="pan:traffic" OR sourcetype="cisco:asa" OR sourcetype="fortinet"
(severity=high OR severity=critical)
("flood" OR "dos" OR "denial" OR "renegotiation" OR "connection-limit" OR "http-flood" OR "ssl-renegotiation")
| bin _time span=5m
| stats count as AlertCount, dc(dest_port) as UniquePorts, dc(dest_ip) as AffectedTargets
by _time, src_ip, dest_ip, signature, sourcetype
| where AlertCount > 5
| eval FloodType=mvappend("Network_Alert: " . signature)
| eval Severity="High"
| rename src_ip as _src_ip, dest_ip as _target, sourcetype as DetectionSource
| eval TotalRequests=AlertCount, RequestsPerSecond=0, UniqueURIs=UniquePorts,
Status5xx=AlertCount, Status429=0, DistinctUserAgents=0
| table _time, _src_ip, _target, TotalRequests, RequestsPerSecond, UniqueURIs,
Status5xx, Status429, DistinctUserAgents, FloodType, Severity, DetectionSource ]Detects Service Exhaustion Flood attacks (T1499.002) using two SPL branches combined with multisearch: (1) Web server access logs (IIS sourcetype=iis and Apache sourcetype=access_combined/access_log) aggregated in 5-minute windows to detect high request volume (>500 req/5min) from single source IPs, 5xx error rate spikes (>100), and single-resource flood patterns. A suspicion classification labels Single-Resource HTTP Flood, Simple HTTP Flood, and Service Degradation scenarios. (2) Network security device logs (Palo Alto pan:traffic, Cisco ASA, Fortinet) filtered for high-severity flood, DoS, SSL renegotiation, and connection-limit alert signatures. Both branches project a unified schema for consistent analyst review.
Data Sources
Required Sourcetypes
False Positives & Tuning
- Legitimate high-traffic events such as product launches, viral marketing campaigns, or news coverage driving genuine traffic spikes from many distributed users
- Web scraping bots, SEO crawlers, and content aggregators that rapidly enumerate site content and generate high request volumes from single IP ranges
- Load testing tools (Apache Bench, k6, Locust, JMeter, Gatling) used by development and QA teams against production or staging environments without prior notification
- CDN edge nodes, reverse proxies, or shared NAT gateways that aggregate traffic from many legitimate users behind a single source IP, inflating per-IP counts
- Automated monitoring and synthetic transaction tools that poll endpoints at high frequency
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.