Which SIEM platforms have a T1499.003 detection rule?

df00tech provides T1499.003 (Application Exhaustion Flood) detection queries for 7 SIEM platforms: Microsoft Sentinel / Defender, Splunk, Elastic Security (EQL), IBM QRadar (AQL), Sumo Logic CSE, Google Chronicle / SecOps, CrowdStrike LogScale (CQL).

What severity and confidence is the T1499.003 detection?

The T1499.003 detection is rated high severity with medium confidence.

What are common false positives for T1499.003?

Common false positives for T1499.003 include: Legitimate high-traffic events such as product launches, marketing campaigns, or viral content causing genuine user spikes to search or landing pages; Authorized security scanning tools (Qualys, Tenable Nessus, OWASP ZAP) running web application vulnerability assessments that hammer form and API endpoints; Load testing tools (Apache JMeter, Gatling, Locust, k6) executing authorized performance tests against production or staging environments.

T1499.003 Microsoft Sentinel · KQL

Detect Application Exhaustion Flood in Microsoft Sentinel

Q: What data sources are required to detect Application Exhaustion Flood (T1499.003)?

Detecting Application Exhaustion Flood requires the following data sources: Network Traffic: Network Traffic Flow, Application Log: Application Log Content, IIS Web Server Logs — W3CIISLog (Microsoft Sentinel).

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/

KQL Detection Query

Microsoft Sentinel (KQL)

kusto

let TimeWindow = 5m;
let SingleIPThreshold = 300;
let AvgResponseThreshold = 5000;
let ResourceIntensiveEndpoints = dynamic([
    "/search", "/query", "/find", "/api/search", "/api/query",
    "/report", "/export", "/download", "/generate", "/convert",
    "/login", "/authenticate", "/auth", "/oauth", "/signin",
    "/graphql", "/api/graphql", "/api/v",
    "/wp-login.php", "/xmlrpc.php", "/wp-admin",
    "/rest/api", "/odata"
]);
W3CIISLog
| where TimeGenerated > ago(1h)
| where csUriStem has_any (ResourceIntensiveEndpoints) or TimeTaken > 5000
| summarize
    RequestCount = count(),
    AvgTimeTaken = avg(TimeTaken),
    MaxTimeTaken = max(TimeTaken),
    P95TimeTaken = percentile(TimeTaken, 95),
    UniqueEndpoints = dcount(csUriStem),
    StatusCodes = make_set(scStatus),
    Endpoints = make_set(csUriStem, 10),
    ServerErrorCount = countif(scStatus >= 500),
    RateLimitedCount = countif(scStatus == 429)
    by bin(TimeGenerated, TimeWindow), cIP, csHost
| where RequestCount > SingleIPThreshold
    or (AvgTimeTaken > AvgResponseThreshold and RequestCount > 50)
    or RateLimitedCount > 10
| extend IsHighRateFlood = RequestCount > SingleIPThreshold
| extend IsSlowExhaustion = AvgTimeTaken > AvgResponseThreshold
| extend ErrorRate = round(1.0 * ServerErrorCount / RequestCount, 2)
| extend ThreatScore = case(
    RequestCount > 1000 and AvgTimeTaken > 10000, 3,
    RequestCount > 500 or AvgTimeTaken > 8000, 2,
    1)
| project TimeGenerated, SourceIP = cIP, Host = csHost, RequestCount,
    AvgResponseMs = AvgTimeTaken, MaxResponseMs = MaxTimeTaken, P95ResponseMs = P95TimeTaken,
    UniqueEndpoints, StatusCodes, Endpoints, ServerErrorCount, RateLimitedCount,
    ErrorRate, IsHighRateFlood, IsSlowExhaustion, ThreatScore
| sort by ThreatScore desc, RequestCount desc

high severity medium confidence

Detects application exhaustion flood attacks by monitoring IIS web server logs (W3CIISLog) for high-rate requests from single source IPs to resource-intensive endpoints, or sustained response time degradation indicating server resource exhaustion. Implements dual detection paths: rate-based (requests exceeding threshold per 5-minute window) and response-time-based (average response degradation indicating CPU/thread pool stress). TimeTaken field in W3CIISLog is in milliseconds; thresholds set at 5000ms (5s average) and 300 requests per window by default. Adjust thresholds via the let variables at the top of the query to match your environment's baseline.

Data Sources

Network Traffic: Network Traffic FlowApplication Log: Application Log ContentIIS Web Server Logs — W3CIISLog (Microsoft Sentinel)

Required Tables

W3CIISLog

False Positives & Tuning

Legitimate high-traffic events such as product launches, marketing campaigns, or viral content causing genuine user spikes to search or landing pages
Authorized security scanning tools (Qualys, Tenable Nessus, OWASP ZAP) running web application vulnerability assessments that hammer form and API endpoints
Load testing tools (Apache JMeter, Gatling, Locust, k6) executing authorized performance tests against production or staging environments
Legitimate API clients or integration partners with high-frequency polling or batch processing workloads making hundreds of requests per minute
Search engine crawlers (Googlebot, Bingbot, Slurp) aggressively indexing resource-intensive dynamic pages or paginated search results

Download portable Sigma rule (.yml)

Other platforms for T1499.003

Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

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.

Last updated: 2026-04-19 Research depth: deep

References (8)

Response Playbook

1. Examine the full command line and decode any Base64 content...
2. Identify the parent process chain and user context...
3. Check for concurrent network connections from the process...

Investigation Guide

Related techniques: T1027, T1105, T1562.001...
Forensic artifacts: PSReadLine history, Prefetch, ScriptBlock logs...

Atomic Red Team Tests

Test 1: Encoded command execution...
Test 2: Download cradle via Net.WebClient...

Unlock Pro Content

Get the full detection package for T1499.003 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Detect Application Exhaustion Flood in Microsoft Sentinel

MITRE ATT&CK

KQL Detection Query

Data Sources

Required Tables

False Positives & Tuning

Other platforms for T1499.003

Testing Methodology

Response Playbook

Investigation Guide

Atomic Red Team Tests

Unlock Pro Content

Related Detections

Parent Technique

Related Sub-techniques

Related Techniques

Same Tactic: Impact

Popular Detections

MITRE ATT&CK

KQL Detection Query

Data Sources

Required Tables

False Positives & Tuning

Other platforms for T1499.003

Testing Methodology

Unlock Pro Content

Related Detections

Parent Technique

Related Sub-techniques

Related Techniques

Same Tactic: Impact

Popular Detections

Get new detections in your inbox