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 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).

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 IBM QRadar · QRadar

Detect Application Exhaustion Flood in IBM QRadar

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/

QRadar Detection Query

IBM QRadar (QRadar)

sql

SELECT
    sourceip AS SourceIP,
    "URL Host" AS Host,
    DATEFORMAT(devicetime, 'yyyy-MM-dd HH:mm') AS TimeWindow,
    COUNT(*) AS RequestCount,
    AVG(LONG("Response Time")) AS AvgResponseMs,
    MAX(LONG("Response Time")) AS MaxResponseMs,
    COUNT(DISTINCT "URL Path") AS UniqueEndpoints,
    SUM(CASE WHEN LONG("HTTP Status Code") >= 500 THEN 1 ELSE 0 END) AS ServerErrorCount,
    SUM(CASE WHEN LONG("HTTP Status Code") = 429 THEN 1 ELSE 0 END) AS RateLimitedCount,
    ROUND(SUM(CASE WHEN LONG("HTTP Status Code") >= 500 THEN 1 ELSE 0 END) * 1.0 / COUNT(*), 2) AS ErrorRate,
    CASE
        WHEN COUNT(*) > 1000 AND AVG(LONG("Response Time")) > 10000 THEN 3
        WHEN COUNT(*) > 500 OR AVG(LONG("Response Time")) > 8000 THEN 2
        ELSE 1
    END AS ThreatScore
FROM events
WHERE
    LOGSOURCETYPEID IN (
        10,    -- IBM Security Web Gateway
        18,    -- Microsoft IIS
        260,   -- Apache HTTP Server
        261,   -- nginx
        95     -- F5 BIG-IP LTM
    )
    AND devicetime > (CURRENT_TIMESTAMP - 3600000)
    AND (
        LOWER("URL Path") LIKE '%/search%'
        OR LOWER("URL Path") LIKE '%/query%'
        OR LOWER("URL Path") LIKE '%/find%'
        OR LOWER("URL Path") LIKE '%/report%'
        OR LOWER("URL Path") LIKE '%/export%'
        OR LOWER("URL Path") LIKE '%/download%'
        OR LOWER("URL Path") LIKE '%/generate%'
        OR LOWER("URL Path") LIKE '%/convert%'
        OR LOWER("URL Path") LIKE '%/login%'
        OR LOWER("URL Path") LIKE '%/authenticate%'
        OR LOWER("URL Path") LIKE '%/auth%'
        OR LOWER("URL Path") LIKE '%/oauth%'
        OR LOWER("URL Path") LIKE '%/signin%'
        OR LOWER("URL Path") LIKE '%/graphql%'
        OR LOWER("URL Path") LIKE '%/wp-login.php%'
        OR LOWER("URL Path") LIKE '%/xmlrpc.php%'
        OR LOWER("URL Path") LIKE '%/wp-admin%'
        OR LOWER("URL Path") LIKE '%/rest/api%'
        OR LOWER("URL Path") LIKE '%/odata%'
        OR LOWER("URL Path") LIKE '%/api/%'
        OR LONG("Response Time") > 5000
    )
GROUP BY
    sourceip,
    "URL Host",
    TRUNC(devicetime, 300000)
HAVING
    COUNT(*) > 300
    OR (AVG(LONG("Response Time")) > 5000 AND COUNT(*) > 50)
    OR SUM(CASE WHEN LONG("HTTP Status Code") = 429 THEN 1 ELSE 0 END) > 10
ORDER BY ThreatScore DESC, RequestCount DESC
LAST 60 MINUTES

high severity medium confidence

Detects T1499.003 Application Exhaustion Flood in IBM QRadar by querying web access log events from IIS, Apache, nginx, and load balancer log sources. Aggregates requests per source IP per 5-minute window, targeting resource-intensive URI patterns (search, GraphQL, auth, export, XML-RPC). Flags IPs exceeding 300 requests per window, generating slow responses (avg >5s with 50+ requests), or receiving repeated HTTP 429 rate-limit responses. Computes a ThreatScore of 1–3 based on combined volume and response time thresholds.

Data Sources

IBM Security Web Gateway (LOGSOURCETYPEID 10)Microsoft IIS Web Server logs (LOGSOURCETYPEID 18)Apache HTTP Server logs (LOGSOURCETYPEID 260)Nginx access logs (LOGSOURCETYPEID 261)F5 BIG-IP LTM logs (LOGSOURCETYPEID 95)WAF/CDN access logs forwarded to QRadar

Required Tables

events

False Positives & Tuning

Synthetic monitoring tools (Pingdom, Datadog Synthetics, New Relic) that perform continuous health checks against /api/ or /auth endpoints from a fixed set of source IPs — exclude known monitoring IP ranges
Batch ETL jobs that bulk-export data through /export or /download endpoints during scheduled maintenance windows; review timing against maintenance schedules
Penetration testing or red team exercises targeting the web tier — coordinate with security teams on authorized test windows and expected source IPs
API gateway retry storms caused by misconfigured downstream services sending repeated requests to /rest/api or /graphql when upstream services are degraded

Download portable Sigma rule (.yml)

Other platforms for T1499.003

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) 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 IBM QRadar

MITRE ATT&CK

QRadar 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

QRadar 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