Response playbooks, investigation guides, and Atomic Red Team tests are Pro-only. Upgrade to unlock the full detection package for THREAT-Impact-EndpointResourceExhaustionDoS.
Upgrade to ProDetect Endpoint Denial of Service via Process/Service Resource Exhaustion Flood in Microsoft Sentinel
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.
MITRE ATT&CK
- Tactic
- Impact
KQL Detection Query
// 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 descThree 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.
Data Sources
Required Tables
False Positives & Tuning
- 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
Other platforms for THREAT-Impact-EndpointResourceExhaustionDoS
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.
- Test 1Simulate Process-Creation Flood (Windows)
Expected signal: DeviceProcessEvents shows 50+ cmd.exe child processes from the same InitiatingProcessId within a 5-minute window.
- 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.
Unlock playbooks & atomic tests with Pro
Get the full detection package for THREAT-Impact-EndpointResourceExhaustionDoS — response playbook and atomic red team tests, plus investigation guidance and hunting queries.
df00tech Pro — £29/user/month