T1499.003 — Application Exhaustion Flood

Tactic: Impact · Platforms: Windows, IaaS, Linux, macOS

Adversaries may target resource intensive features of applications to cause a denial of service (DoS), denying availability to those applications. For example, specific features in web applications may be highly resource intensive. Repeated requests to those features may be able to exhaust system…

Sub-technique of Endpoint Denial of Service (T1499).

Sigma detection rules (4)

T1499.003 Endpoint Denial of Service: Application Exhaustion Flood

title: "T1499.003 Endpoint Denial of Service: Application Exhaustion Flood"
id: e314ff9b-4ccb-4e5e-886f-b33fe0fb9358
description: 'Detects Windows Application-log crash (EventID 1000) and hang (EventID 1002) events, the actual identifiers logged when an application exhausts resources under an exhaustion-flood attack; a single event indicates one crash/hang and not necessarily a DoS, so pair with a frequency/correlation rule grouped by the faulting application within a short window to confirm sustained exhaustion versus an isolated fault. (Data Component: Application Log Content; baseline tier: windows-eventid.) Tune using: CPUThreshold, MemoryConsumptionWindow, AppCrashFrequency.'
references:
  - https://attack.mitre.org/techniques/T1499/003
author: Shahrukh Khan
date: 2026-02-06
license: MIT
tags:
  - attack.impact
  - attack.t1499.003

logsource:
  product: windows
  service: application

detection:
  selection:
    EventID:
      - '1000'
      - '1002'

  filter_system_account:
    User|contains:
      - 'SYSTEM'
      - 'LOCAL SERVICE'
      - 'NETWORK SERVICE'

  condition: selection and not filter_system_account

falsepositives:
  - System and service accounts (SYSTEM, LOCAL SERVICE, NETWORK SERVICE) performing the same action are excluded via filter_system_account; tune further with process/path allowlists if noise remains.
  - Isolated application crashes/hangs unrelated to a resource-exhaustion attack; use frequency tuning (AppCrashFrequency) to reduce noise.

level: medium

T1499.003 Endpoint Denial of Service: Application Exhaustion Flood

title: "T1499.003 Endpoint Denial of Service: Application Exhaustion Flood"
id: c7d49256-b845-4042-8039-1e66ace5d73c
description: 'Application Exhaustion Flood Detection (T1499.003), retargeted from hping3 (a raw network-flood tool that maps to T1498, not this technique) and from a bash brace-expansion regex (e.g. {1..100}) that the invoking shell always resolves before exec, so the literal pattern can never appear in a captured EXECVE argument. This rule instead flags execution of HTTP/application-layer load-generation tools capable of exhausting a specific resource-intensive endpoint; auditd cannot itself measure request rate or server-side resource exhaustion, so a single EXECVE event is a seed indicator, not proof of a flood. Tune using: SyslogErrorRate, PortRequestSpikeThreshold, ProcessSpawnRate.'
references:
  - https://attack.mitre.org/techniques/T1499/003
author: Shahrukh Khan
date: 2026-02-16
license: MIT
tags:
  - attack.impact
  - attack.t1499.003

logsource:
  category: process_creation
  product: linux

detection:
  selection:
    type: EXECVE
    a0|endswith:
      - '/ab'
      - '/siege'
      - '/wrk'
      - '/hey'
      - '/slowhttptest'
      - '/hulk.py'
      - '/goldeneye.py'

  condition: selection

falsepositives:
  - Legitimate load/performance testing (ab, siege, wrk, hey) run by developers or QA against internal endpoints; confirming an actual exhaustion flood requires request-rate/server-error-rate correlation (SyslogErrorRate, ProcessSpawnRate) beyond a single EXECVE event.

level: medium

T1499.003 Endpoint Denial of Service: Application Exhaustion Flood

title: "T1499.003 Endpoint Denial of Service: Application Exhaustion Flood"
id: eb4b7e3e-842d-4951-9b18-9ce43a66bbe6
description: 'Application Exhaustion Flood Detection Across Platforms. (Retargeted to the process_creation macOS unified-log telemetry that actually captures this techniques behavior; see logsource below.) Tune using: SpinReportCount, HeavyAppReopenRate.'
references:
  - https://attack.mitre.org/techniques/T1499/003
author: Shahrukh Khan
date: 2026-06-13
license: MIT
tags:
  - attack.impact
  - attack.t1499.003

logsource:
  category: process_creation
  product: macos

detection:
  selection:
    Image|endswith: '/open'
  selection_repeat:
    CommandLine|contains: '.app'
  condition: selection and selection_repeat

falsepositives:
  - Users legitimately reopen applications many times during normal troubleshooting, so this rule only becomes meaningful when the same application is relaunched at an abnormally high rate in a short window, which requires frequency analysis beyond a single process_creation event.

level: medium

T1499.003 Endpoint Denial of Service: Application Exhaustion Flood

title: "T1499.003 Endpoint Denial of Service: Application Exhaustion Flood"
id: ae4f52c8-1e4d-4fcb-ad4b-aa740766ea39
description: 'Application Exhaustion Flood Detection Across Platforms. (Retargeted to the application AWS telemetry that actually captures this techniques behavior; see logsource below.) Tune using: HTTP5xxRateThreshold, FunctionInvocationRate, AutoscaleEventCount.'
references:
  - https://attack.mitre.org/techniques/T1499/003
author: Shahrukh Khan
date: 2026-01-01
license: MIT
tags:
  - attack.impact
  - attack.t1499.003

logsource:
  category: application
  product: aws
  service: cloudwatch

detection:
  selection:
    MetricName:
      - 'HTTPCode_Target_5XX_Count'
      - 'Throttles'
    Value|gte: 100

  condition: selection

falsepositives:
  - Application-level bugs, dependency outages, and legitimate traffic surges during marketing events produce the same metric pattern, so CloudWatch alarms alone cannot confirm deliberate application exhaustion without traffic-source correlation, which lowers confidence.

level: medium

Related sub-techniques

Explore