Detect Endpoint Denial of Service via Process/Service Resource Exhaustion Flood in Elastic Security
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
Elastic Detection Query
sequence by process.parent.entity_id with maxspan=5m
[process where event.type == "start"] with runs=50Detects a single parent process generating 50 or more child process-start events within a 5-minute window using Elastic's EQL sequence-with-runs construct — a direct, low-overhead expression of the fork-bomb/spawn-loop signature without any performance-counter polling.
Data Sources
Required Tables
False Positives & Tuning
- Build/test automation and package managers that legitimately spawn many short-lived child processes
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.
Response Playbook
Triage
- 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.
- Identify the parent process and account responsible for the flood — is it a known automation tool (allowlisted) or an unrecognized script/binary?
- 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.
- 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.
- If multiple hosts show the same signal simultaneously, treat as a coordinated attack rather than an isolated local issue.
Containment
- 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.
- Restart any critical service that has become unresponsive due to resource exhaustion once the offending process tree is confirmed terminated.
- If the host is unresponsive to remote administration due to exhaustion, use out-of-band management (iDRAC/iLO, hypervisor console) to intervene.
- Disable or remove the scheduled task, script, or startup entry that launched the offending process to prevent recurrence on reboot.
- 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
- Full process tree (parent/child relationships) for the offending process at time of detection
- DeviceProcessEvents / Sysmon Event ID 1 history for the responsible parent process over the prior 24 hours, including command line
- Windows Resource-Exhaustion-Detector and Application Hang event log entries with full RenderedDescription/Message text
- Scheduled task, service, or startup registry entries that reference the offending binary or script
- 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
Related Techniques
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.
DeviceProcessEvents
| where Timestamp > ago(7d)
| summarize ChildCount=count() by InitiatingProcessFileName, InitiatingProcessId, DeviceName, bin(Timestamp, 5m)
| where ChildCount >= 30
| sort by ChildCount descindex=mde sourcetype="DeviceProcessEvents" earliest=-7d
| bucket _time span=5m
| stats count AS ChildCount by InitiatingProcessFileName InitiatingProcessId DeviceName _time
| where ChildCount >= 30
| sort - ChildCountAtomic Red Team Tests
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
for /L %i in (1,1,60) do start /min cmd.exe /c "timeout 2"Cleanup
taskkill /IM cmd.exe /F /TExpected 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.
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
for i in $(seq 1 60); do (sleep 2 &) ; doneCleanup
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.