THREAT-Impact-EndpointResourceExhaustionDoS

Endpoint Denial of Service via Process/Service Resource Exhaustion Flood

Impact Last updated:

Endpoint denial-of-service attacks against a single host (T1499) do not always require network floods — an adversary with local or remote code execution can render a system or a critical service unusable purely by exhausting local resources: spawning processes faster than the OS can reap them (a 'fork bomb' or self-replicating process tree), repeatedly invoking a resource-heavy service call, or exhausting available memory/handles until the OS resource-exhaustion detector or the application itself begins failing. This detection deliberately avoids continuous performance-counter polling (CPU%, memory% telemetry), which is expensive to collect and noisy to baseline. Instead it relies on cheap, event-driven signals that are already logged by default on most endpoints: (1) process-creation event volume from a single parent process crossing a hard threshold in a short window (the signature of a fork bomb or malicious loop, e.g. cmd.exe spawning itself repeatedly or a scripted `while(1){Start-Process}` loop), (2) native OS resource-exhaustion telemetry — Windows' Microsoft-Windows-Resource-Exhaustion-Detector ETW provider (Event IDs 2004/2005 for low virtual memory/commit) and Application-Hang events (Event ID 1002), and (3) the Linux OOM-killer's own log line, which fires only when the kernel actually reclaims memory by killing a process. All three are single-event or simple-count aggregations, not continuous metric collection.

What is THREAT-Impact-EndpointResourceExhaustionDoS Endpoint Denial of Service via Process/Service Resource Exhaustion Flood?

Endpoint Denial of Service via Process/Service Resource Exhaustion Flood (THREAT-Impact-EndpointResourceExhaustionDoS) maps to the Impact tactic — the adversary is trying to manipulate, interrupt, or destroy your systems and data in MITRE ATT&CK.

This page provides production-ready detection logic for Endpoint Denial of Service via Process/Service Resource Exhaustion Flood, covering the data sources and telemetry it touches: Microsoft Defender for Endpoint (DeviceProcessEvents), Windows Event Log — Microsoft-Windows-Resource-Exhaustion-Detector/Operational, Windows Application Event Log (Application Hang, Event ID 1002). The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Impact
Microsoft Sentinel / Defender
kusto
// THREAT: Endpoint DoS via resource exhaustion (T1499.002/.003) - lightweight, event-driven signals only
let LookbackWindow = 1h;
let ForkBombThreshold = 50; // child processes from one parent within the window
// Signal 1: process-creation flood from a single parent (fork bomb / malicious spawn loop)
let ProcessFlood = DeviceProcessEvents
| where Timestamp > ago(LookbackWindow)
| summarize ChildCount=count(), Children=make_set(FileName, 20) by DeviceName, InitiatingProcessId, InitiatingProcessFileName, bin(Timestamp, 5m)
| where ChildCount >= ForkBombThreshold
| extend Indicator = "ProcessCreationFloodFromSingleParent"
| extend RiskScore = 90
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessId, ChildCount, Children, Indicator, RiskScore;
// Signal 2: Windows native resource-exhaustion detector events (event-driven, not polled)
let ResourceExhaustion = Event
| where Timestamp > ago(LookbackWindow)
| where Source == "Microsoft-Windows-Resource-Exhaustion-Detector"
| where EventID in (2004, 2005)
| extend Indicator = "WindowsResourceExhaustionDetectorFired"
| extend RiskScore = 80
| project Timestamp, Computer, EventID, RenderedDescription, Indicator, RiskScore;
// Signal 3: application hang clustering (multiple distinct processes hanging on one host in a short window)
let AppHangCluster = Event
| where Timestamp > ago(LookbackWindow)
| where Source == "Application Hang" and EventID == 1002
| summarize HangCount=count(), HungProcesses=make_set(RenderedDescription, 10) by Computer, bin(Timestamp, 15m)
| where HangCount >= 3
| extend Indicator = "MultiProcessApplicationHangCluster"
| extend RiskScore = 70
| project Timestamp, Computer, HangCount, HungProcesses, Indicator, RiskScore;
union ProcessFlood, ResourceExhaustion, AppHangCluster
| sort by RiskScore desc, Timestamp desc

Three event-driven signals for local endpoint DoS, none of which require polling performance counters. Signal 1 aggregates DeviceProcessEvents by parent process within 5-minute bins and flags a single parent spawning 50+ children — the classic fork-bomb/spawn-loop signature. Signal 2 surfaces Windows' own Resource-Exhaustion-Detector ETW events (2004 = low virtual memory, 2005 = low commit), which the OS only emits when it has already detected genuine resource pressure. Signal 3 clusters Application Hang events (Event ID 1002) across 3+ distinct processes on one host within 15 minutes, indicating system-wide unresponsiveness rather than one crashy app.

high severity medium confidence

Data Sources

Microsoft Defender for Endpoint (DeviceProcessEvents) Windows Event Log — Microsoft-Windows-Resource-Exhaustion-Detector/Operational Windows Application Event Log (Application Hang, Event ID 1002)

Required Tables

DeviceProcessEvents Event

False Positives

  • Legitimate build/test automation that intentionally spawns many short-lived processes (CI runners, parallel test harnesses) — allowlist the known automation parent process names
  • Software installers or update tools that briefly spawn many child helper processes during installation
  • A single genuinely buggy application repeatedly hanging due to a local bug rather than an attack — correlate with recent patch/deployment history before escalating
  • Memory-constrained VMs or containers with tight resource limits that naturally trigger resource-exhaustion events under normal peak load

Sigma rule & cross-platform mapping

The detection logic for Endpoint Denial of Service via Process/Service Resource Exhaustion Flood (THREAT-Impact-EndpointResourceExhaustionDoS) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 2 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 1Simulate Process-Creation Flood (Windows)

    Expected signal: DeviceProcessEvents shows 50+ cmd.exe child processes from the same InitiatingProcessId within a 5-minute window.

  2. Test 2Simulate Process-Creation Flood (Linux)

    Expected signal: Process creation events show a single parent shell spawning 50+ short-lived child processes within a 5-minute window; on repeated/uncontrolled runs, kernel oom-killer log lines may appear.


Response Playbook

Triage

  1. Determine which signal fired: a process-creation flood points to an active spawn-loop/fork-bomb still potentially running on the host; a resource-exhaustion or app-hang signal indicates the system may already be degraded or unresponsive.
  2. Identify the parent process and account responsible for the flood — is it a known automation tool (allowlisted) or an unrecognized script/binary?
  3. Check whether the affected host is a shared or critical system (domain controller, database server, jump host) where a DoS has outsized business impact versus a single user workstation.
  4. Correlate with recent logon activity, remote execution (PsExec/WinRM/SSH), or scheduled task creation on the host to identify how the responsible process was launched.
  5. If multiple hosts show the same signal simultaneously, treat as a coordinated attack rather than an isolated local issue.

Containment

  1. If a fork bomb/spawn loop is still active, kill the parent process tree immediately (taskkill /T /F on Windows, pkill -P on Linux) or isolate the host via EDR if the process cannot be safely terminated remotely.
  2. Restart any critical service that has become unresponsive due to resource exhaustion once the offending process tree is confirmed terminated.
  3. If the host is unresponsive to remote administration due to exhaustion, use out-of-band management (iDRAC/iLO, hypervisor console) to intervene.
  4. Disable or remove the scheduled task, script, or startup entry that launched the offending process to prevent recurrence on reboot.
  5. For a coordinated multi-host event, isolate affected hosts from the network segment to prevent the resource-exhaustion trigger from propagating (e.g., a malicious logon script pushed via GPO).

Evidence Collection

  1. Full process tree (parent/child relationships) for the offending process at time of detection
  2. DeviceProcessEvents / Sysmon Event ID 1 history for the responsible parent process over the prior 24 hours, including command line
  3. Windows Resource-Exhaustion-Detector and Application Hang event log entries with full RenderedDescription/Message text
  4. Scheduled task, service, or startup registry entries that reference the offending binary or script
  5. Any logon session or remote-execution artifact (PsExec, WinRM, SSH) that preceded the process launch

Escalation Criteria

  • ! A critical production system (domain controller, database, hypervisor host) is affected
  • ! The process-creation flood is still active and has not been contained after initial kill attempts (may indicate a self-restarting/watchdog spawn loop)
  • ! Multiple hosts show the flood or exhaustion signal within the same short window, indicating a coordinated or worm-propagated trigger
  • ! The offending binary or script is unrecognized and not present in any change record or deployment log

Investigation Guide

Forensic Artifacts

  • > Sysmon Event ID 1 (Process Create) chain showing parent-to-child fan-out
  • > Windows Event Log: Microsoft-Windows-Resource-Exhaustion-Detector/Operational (Event IDs 2004, 2005)
  • > Windows Application Event Log: Application Hang (Event ID 1002), Application Error (Event ID 1000)
  • > Linux: /var/log/syslog or journalctl entries containing 'Out of memory: Killed process' (oom-killer invocation)
  • > Scheduled Task XML / cron entry / systemd timer unit referencing the offending script or binary

Tuning Guidance

The ForkBombThreshold (default 50 children/5min) should be tuned against your own baseline — build/test infrastructure and package managers can legitimately spawn dozens of short-lived processes. Establish a per-host or per-role baseline (build agents vs. workstations vs. servers) and set separate thresholds rather than one global value. For the resource-exhaustion and app-hang signals, these are rare enough in a healthy fleet that any occurrence on a production server warrants investigation; workstations may see occasional legitimate app hangs and should be scoped separately from server-tier alerting.


Hunting Queries

Hunt for lower-threshold process fan-out (30+ children in 5 minutes) over a wider 7-day window to catch slower or throttled spawn-loop attempts that stay just under the primary detection threshold.

Hunting — KQL
kql
DeviceProcessEvents
| where Timestamp > ago(7d)
| summarize ChildCount=count() by InitiatingProcessFileName, InitiatingProcessId, DeviceName, bin(Timestamp, 5m)
| where ChildCount >= 30
| sort by ChildCount desc
Hunting — SPL
spl
index=mde sourcetype="DeviceProcessEvents" earliest=-7d
| bucket _time span=5m
| stats count AS ChildCount by InitiatingProcessFileName InitiatingProcessId DeviceName _time
| where ChildCount >= 30
| sort - ChildCount

Atomic Red Team Tests

Test 1 Simulate Process-Creation Flood (Windows)
windows

Spawns a rapid succession of short-lived child processes from a single parent to simulate a fork-bomb/spawn-loop pattern. Run only in an isolated lab VM — this can genuinely degrade the host.

Command

powershell
for /L %i in (1,1,60) do start /min cmd.exe /c "timeout 2"

Cleanup

powershell
taskkill /IM cmd.exe /F /T

Expected Telemetry

DeviceProcessEvents shows 50+ cmd.exe child processes from the same InitiatingProcessId within a 5-minute window.

Expected Detection

Alert fires on ProcessCreationFloodFromSingleParent indicator with RiskScore=90.

Test 2 Simulate Process-Creation Flood (Linux)
linux

Bash fork-bomb pattern that rapidly spawns background subshells, simulating local resource exhaustion via process flooding. Run only in an isolated, resource-limited lab container/VM.

Command

bash
for i in $(seq 1 60); do (sleep 2 &) ; done

Cleanup

bash
pkill -f 'sleep 2'

Expected Telemetry

Process creation events show a single parent shell spawning 50+ short-lived child processes within a 5-minute window; on repeated/uncontrolled runs, kernel oom-killer log lines may appear.

Expected Detection

Alert fires on ProcessCreationFloodFromSingleParent indicator; if memory pressure results, also correlates with OOM-killer log signal.

Related Detections

Tactic Hub