T1499.003 Google Chronicle · YARA-L

Detect Application Exhaustion Flood in Google Chronicle

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/

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral
rule t1499_003_application_exhaustion_flood {
  meta:
    author = "df00tech"
    description = "Detects T1499.003 Application Exhaustion Flood — identifies single source IPs sending high-volume requests to resource-intensive web endpoints or triggering slow server responses indicative of CPU, thread pool, or database connection exhaustion."
    mitre_attack_tactic = "Impact"
    mitre_attack_technique = "T1499.003"
    severity = "HIGH"
    priority = "HIGH"

  events:
    $e.metadata.event_type = "NETWORK_HTTP"
    $e.metadata.product_name != ""
    (
      re.regex($e.target.url, `(?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/)`)
      or $e.network.http.response_code = 429
    )
    $e.principal.ip = $src_ip
    $e.target.hostname = $target_host

  match:
    $src_ip, $target_host over 5m

  outcome:
    $request_count = count($e.metadata.id)
    $rate_limited_count = sum(
      if($e.network.http.response_code = 429, 1, 0)
    )
    $server_error_count = sum(
      if($e.network.http.response_code >= 500, 1, 0)
    )
    $unique_endpoints = count_distinct($e.target.url)
    $max_response_bytes = max($e.network.http.response_body_bytes)
    $error_rate = math.round(
      ($server_error_count / $request_count) * 100
    ) / 100
    $threat_score = if(
      $request_count > 1000 and $rate_limited_count > 20, 3,
      if($request_count > 500 or $rate_limited_count > 10, 2, 1)
    )
    $is_high_rate_flood = if($request_count > 300, "true", "false")
    $is_rate_limit_triggered = if($rate_limited_count > 10, "true", "false")

  condition:
    #e > 300
    or ($rate_limited_count > 10)
    or ($server_error_count > 50 and #e > 50)
}
high severity medium confidence

Detects T1499.003 Application Exhaustion Flood using Google Chronicle YARA-L 2.0 over UDM NETWORK_HTTP events. Matches HTTP requests to resource-intensive URI patterns (search, GraphQL, auth, export, XML-RPC) or HTTP 429 rate-limit responses from a single source IP to a target host within a 5-minute window. Computes request count, rate-limited count, server error count, unique endpoints, and a threat score. Fires when a single IP exceeds 300 requests, triggers more than 10 rate-limit responses, or generates over 50 server errors in the window — all strong indicators of application-layer exhaustion attacks.

Data Sources

Chronicle UDM NETWORK_HTTP events (ingested from web proxy, WAF, or load balancer logs)Google Cloud Load Balancer logs parsed to UDMPalo Alto Networks / Zscaler proxy logs mapped to UDMIIS / Apache / Nginx logs parsed via Chronicle ingestion parsers

Required Tables

UDM events (NETWORK_HTTP type)

False Positives & Tuning

  • High-traffic legitimate services (news aggregators, API consumers, CDN origin pulls) that make large volumes of structured requests to /api/ or /search endpoints from a single egress IP — validate against known partner IP allowlists
  • Internal automated systems performing health monitoring, synthetic transactions, or chaos engineering tests that target auth or search endpoints at defined rates
  • Mobile application backends aggregating user requests behind a NAT gateway — all traffic appears to originate from one or a small set of IPs, making per-IP volume thresholds less reliable; supplement with per-session or per-user-agent analysis
Download portable Sigma rule (.yml)

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.

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

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

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

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

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

Related Detections