Detect Application Exhaustion Flood in CrowdStrike LogScale
Adversaries may target resource-intensive features of web applications to cause a denial of service (DoS), denying availability to those applications. Unlike volumetric network-layer floods, application exhaustion attacks focus on Layer 7 features that consume disproportionate server resources per request — such as search functions, complex database queries, authentication endpoints, report generation, GraphQL resolvers, XML/SOAP processing, or file conversion operations. By repeatedly invoking these expensive operations, adversaries can exhaust CPU cycles, memory, database connection pools, or thread pools with relatively low request volumes, making the attack harder to distinguish from legitimate traffic spikes and more difficult to block at the network layer without application-aware controls.
MITRE ATT&CK
- Tactic
- Impact
- Technique
- T1499 Endpoint Denial of Service
- Sub-technique
- T1499.003 Application Exhaustion Flood
- Canonical reference
- https://attack.mitre.org/techniques/T1499/003/
LogScale Detection Query
// T1499.003 — Application Exhaustion Flood Detection
// Requires HTTP activity telemetry from Falcon sensor or ingested web proxy/WAF logs
// Step 1: Filter to relevant HTTP web events with resource-intensive endpoints
#event_simpleName IN ("NetworkConnectIP4", "HttpRequest", "WebRequest")
// Filter for resource-intensive paths or slow responses
| regex(field="RequestUrl", regex="(?i)/(search|query|find|report|export|download|generate|convert|login|authenticate|auth|oauth|signin|graphql|wp-login\.php|xmlrpc\.php|wp-admin|rest/api|odata|api/)", strict=false)
// Step 2: Extract source IP and host from available fields
| eval SourceIP = coalesce(RemoteAddressIP4, SrcIP, SourceIP)
| eval TargetHost = coalesce(HttpHost, DestinationHostname, DomainName)
| eval UriPath = coalesce(RequestUrl, UrlPath, Uri)
| eval StatusCode = coalesce(HttpStatusCode, StatusCode, 0)
| eval ResponseTimeMs = coalesce(ResponseTimeMs, TimeTakenMs, 0)
// Step 3: Bucket into 5-minute windows and aggregate per source IP
| bucket(field="@timestamp", function="floor", arg=300000) as TimeWindow
| groupBy([TimeWindow, SourceIP, TargetHost], function=[
count() as RequestCount,
avg(ResponseTimeMs) as AvgResponseMs,
max(ResponseTimeMs) as MaxResponseMs,
count(UriPath, distinct=true) as UniqueEndpoints,
sum(if(StatusCode >= 500, 1, 0)) as ServerErrorCount,
sum(if(StatusCode = 429, 1, 0)) as RateLimitedCount
])
// Step 4: Apply detection thresholds matching KQL/SPL logic
| where RequestCount > 300
or (AvgResponseMs > 5000 and RequestCount > 50)
or RateLimitedCount > 10
// Step 5: Compute derived fields
| eval ErrorRate = round(ServerErrorCount / RequestCount, 2)
| eval ThreatScore = case(
RequestCount > 1000 and AvgResponseMs > 10000, "3-Critical",
RequestCount > 500 or AvgResponseMs > 8000, "2-High",
"1-Medium")
| eval IsHighRateFlood = if(RequestCount > 300, "true", "false")
| eval IsSlowExhaustion = if(AvgResponseMs > 5000, "true", "false")
// Step 6: Sort and output
| sort(ThreatScore, order=desc)
| sort(RequestCount, order=desc)
| table([TimeWindow, SourceIP, TargetHost, RequestCount, AvgResponseMs, MaxResponseMs, UniqueEndpoints, ServerErrorCount, RateLimitedCount, ErrorRate, IsHighRateFlood, IsSlowExhaustion, ThreatScore])Detects T1499.003 Application Exhaustion Flood using CrowdStrike Falcon LogScale (CQL). Targets NetworkConnectIP4, HttpRequest, and WebRequest event types containing HTTP telemetry from the Falcon sensor or ingested web proxy/WAF logs. Filters to resource-intensive URI patterns using regex, aggregates per source IP and target host in 5-minute buckets, and applies the same detection thresholds as the KQL/SPL queries: 300+ requests per window, average response time over 5 seconds with 50+ requests, or 10+ rate-limit (HTTP 429) responses. Outputs a ranked threat score for analyst triage.
Data Sources
Required Tables
False Positives & Tuning
- CrowdStrike-managed endpoints running automated software update checks or telemetry agents that periodically poll /api/ endpoints at high frequency — these typically have consistent User-Agent strings and uniform request intervals
- Legitimate high-volume API consumers (partner integrations, CI/CD pipelines, data sync jobs) operating from a small number of corporate egress IPs and targeting /export or /graphql endpoints on a schedule
- Security scanning tools (vulnerability scanners, web application fuzzers) operated by the internal security team that probe all application endpoints including authenticated routes — validate against authorized scan schedules and scanning tool hostnames
- CDN origin-pull behavior where the CDN makes large batches of requests to the origin for cache warming, appearing as a single high-volume source IP hitting /download or /generate endpoints
Other platforms for T1499.003
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 1Apache Bench Single-Source Application Endpoint Flood
Expected signal: W3CIISLog or Apache access.log: 5000 requests from 127.0.0.1 to /search endpoint within 30-60 seconds. User-Agent will show ApacheBench/2.X despite the override only applying to one header in some ab versions — check actual logs. TimeTaken values will show progressive degradation as server load increases. High RequestCount in 5-minute window from single source IP.
- Test 2Python Multi-threaded Concurrent Request Flood
Expected signal: Web access logs: 2000 requests from 127.0.0.1 to /api/search endpoint within 10-30 seconds with User-Agent 'python-requests/X.X.X'. High concurrency visible from overlapping request timestamps. If server load causes stress, HTTP 503 or 429 responses will appear in logs alongside 200s. ServerErrorCount or RateLimitedCount fields will be non-zero.
- Test 3curl Loop Targeting Authentication Endpoint with POST Bodies
Expected signal: Web access logs: 500 POST requests to /login from 127.0.0.1 with Content-Type: application/json. Average response time measurably higher than GET requests due to bcrypt cost. Application logs may show repeated authentication failure warnings. HTTP status codes will be 401 for invalid credentials or 429 if rate limiting activates.
- Test 4GraphQL Complexity Attack via Deeply Nested Query Flood
Expected signal: Web access logs: 200 POST requests to /graphql endpoint with deeply nested query payload. Response times significantly elevated (potentially >10s per request) due to N+1 resolver execution and recursive database queries. CPU utilization on application server and database server both spike. Database slow query logs will show high-volume repetitive queries triggered by the resolver chain.
References (8)
- https://attack.mitre.org/techniques/T1499/003/
- https://pages.arbornetworks.com/rs/082-KNA-087/images/13th_Worldwide_Infrastructure_Security_Report.pdf
- https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/netflow/configuration/15-mt/nf-15-mt-book/nf-detct-analy-thrts.pdf
- https://owasp.org/www-community/attacks/Denial_of_Service
- https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html
- https://learn.microsoft.com/en-us/azure/web-application-firewall/overview
- https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/w3ciislog
- https://learn.microsoft.com/en-us/iis/extensions/advanced-logging-module/advanced-logging-for-iis-real-time-logging
Unlock Pro Content
Get the full detection package for T1499.003 including response playbook, investigation guide, and atomic red team tests.