Detect Service Exhaustion Flood in CrowdStrike LogScale
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/
LogScale Detection Query
// Branch 1: HTTP flood detection via CrowdStrike network connection telemetry
// Detects high-volume outbound/inbound HTTP connections from a single endpoint
// indicating potential HTTP flood activity from a compromised host
#event_simpleName = "NetworkConnectIP4" OR #event_simpleName = "NetworkConnectIP6"
| RemotePort = 80 OR RemotePort = 443 OR RemotePort = 8080 OR RemotePort = 8443
| groupBy(
[ComputerName, LocalAddressIP4, RemoteAddressIP4, RemotePort],
function=[
count(aid, as=TotalConnections),
count(distinct(RemoteAddressIP4), as=UniqueTargets),
min(@timestamp, as=FirstSeen),
max(@timestamp, as=LastSeen)
],
limit=max
)
| TotalConnections > 500
| eval RequestsPerSecond = round(TotalConnections / 300, 2)
| eval FloodType = if(UniqueTargets == 1, "Single-Target HTTP Flood", "Multi-Target HTTP Flood")
| eval Severity = if(TotalConnections > 5000, "Critical",
if(TotalConnections > 2000, "High", "Medium"))
| eval MITRETechnique = "T1499.002"
| eval DetectionSource = "CrowdStrike_NetworkConnect"
| table([
ComputerName, LocalAddressIP4, RemoteAddressIP4, RemotePort,
TotalConnections, RequestsPerSecond, UniqueTargets,
FloodType, Severity, MITRETechnique, DetectionSource,
FirstSeen, LastSeen
])
| sort(TotalConnections, order=desc)
// Branch 2: DNS flood detection via CrowdStrike DNS telemetry
// Detects high-volume DNS query bursts that may indicate DNS amplification/exhaustion
#event_simpleName = "DnsRequest"
| groupBy(
[ComputerName, LocalAddressIP4],
function=[
count(aid, as=TotalDNSQueries),
count(distinct(DomainName), as=UniqueDomains),
count(distinct(RequestType), as=UniqueQueryTypes),
values(DomainName, as=SampledDomains, limit=5)
],
limit=max
)
| TotalDNSQueries > 1000
| eval QueriesPerSecond = round(TotalDNSQueries / 300, 2)
| eval FloodIndicator = if(
UniqueDomains < 5 and TotalDNSQueries > 1000,
"DNS Amplification/Flood Suspected",
if(
UniqueQueryTypes == 1 and TotalDNSQueries > 2000,
"Single-Type DNS Flood",
"High-Volume DNS Activity"
)
)
| eval Severity = if(TotalDNSQueries > 10000, "Critical",
if(TotalDNSQueries > 5000, "High", "Medium"))
| eval MITRETechnique = "T1499.002"
| eval DetectionSource = "CrowdStrike_DNSRequest"
| table([
ComputerName, LocalAddressIP4, TotalDNSQueries, UniqueDomains,
QueriesPerSecond, UniqueQueryTypes, SampledDomains,
FloodIndicator, Severity, MITRETechnique, DetectionSource
])
| sort(TotalDNSQueries, order=desc)
// Branch 3: Process-initiated flood detection
// Detects known flood/stress-test tools by process name or command line
#event_simpleName = "ProcessRollup2"
| ImageFileName = /(?i)(hping|hping3|wrk|ab\.exe|siege|slowloris|loic|hoic|goldeneye|torshammer|hulk|pyloris|thcssl|mdk3|xerxes|ufosyn|sockstress|t50\.exe|flood\.py|dosflood)/
OR CommandLine = /(?i)(--flood|--syn-flood|ssl.renegotiation|renegotiation.attack|-flood|-dos|-stress|--slowloris)/
| groupBy(
[ComputerName, UserName, ImageFileName, CommandLine],
function=[
count(aid, as=ExecutionCount),
values(ParentImageFileName, as=ParentProcess),
min(@timestamp, as=FirstSeen),
max(@timestamp, as=LastSeen)
]
)
| eval FloodType = "Known_Flood_Tool_Execution"
| eval Severity = "Critical"
| eval MITRETechnique = "T1499.002"
| eval DetectionSource = "CrowdStrike_ProcessRollup2"
| table([
ComputerName, UserName, ImageFileName, CommandLine, ParentProcess,
ExecutionCount, FloodType, Severity, MITRETechnique, DetectionSource,
FirstSeen, LastSeen
])Three-branch CrowdStrike LogScale CQL detection for T1499.002 Service Exhaustion Flood. Branch 1 aggregates NetworkConnectIP4/IPv6 events to identify endpoints making >500 HTTP/HTTPS connections in a 5-minute window to detect compromised hosts participating in or launching floods. Branch 2 monitors DnsRequest events for DNS amplification patterns: >1000 queries with low domain diversity suggesting a flood or amplification attack. Branch 3 performs high-confidence binary/commandline matching against known flood tools (hping, LOIC, HOIC, Slowloris, GoldenEye) and stress-testing flags, triggering at Critical severity on any match.
Data Sources
Required Tables
False Positives & Tuning
- Penetration testing engagements where authorized red team operators run tools like hping3, wrk, or ab (Apache Benchmark) against in-scope targets — validate against active engagement windows and authorized IP lists before escalating Branch 3 matches.
- Developer workstations running local load tests against development environments using tools like k6, JMeter, or wrk that are bundled under innocuous process names or executed via script wrappers, potentially matching command-line patterns.
- Network monitoring appliances or endpoint agents that establish many simultaneous connections to cloud telemetry endpoints for health reporting or event streaming, triggering Branch 1 volume thresholds without malicious intent.
- High-frequency DNS resolvers or DNS prefetching mechanisms on busy workstations or browser-based kiosks that pre-resolve large numbers of domains from a browsed page, triggering Branch 2 DNS volume thresholds.
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.