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 Pro
THREAT-Impact-EndpointResourceExhaustionDoS Splunk · SPL

Detect Endpoint Denial of Service via Process/Service Resource Exhaustion Flood in Splunk

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

SPL Detection Query

Splunk (SPL)
spl
(
  index=mde sourcetype="DeviceProcessEvents"
  | bucket _time span=5m
  | stats count AS ChildCount, values(FileName) AS Children by DeviceName, InitiatingProcessId, InitiatingProcessFileName, _time
  | where ChildCount >= 50
  | eval Indicator="ProcessCreationFloodFromSingleParent", RiskScore=90
  | table _time, DeviceName, InitiatingProcessFileName, InitiatingProcessId, ChildCount, Children, Indicator, RiskScore
)
| append [
    search index=wineventlog source="Microsoft-Windows-Resource-Exhaustion-Detector/Operational" (EventCode=2004 OR EventCode=2005)
    | eval Indicator="WindowsResourceExhaustionDetectorFired", RiskScore=80
    | table _time, Computer, EventCode, Message, Indicator, RiskScore
  ]
| append [
    search index=wineventlog sourcetype="WinEventLog:Application" source="Application Hang" EventCode=1002
    | bucket _time span=15m
    | stats count AS HangCount, values(Message) AS HungProcesses by Computer, _time
    | where HangCount >= 3
    | eval Indicator="MultiProcessApplicationHangCluster", RiskScore=70
    | table _time, Computer, HangCount, HungProcesses, Indicator, RiskScore
  ]
| sort - RiskScore
high severity medium confidence

SPL equivalent of the three lightweight endpoint-DoS signals: process-creation flood by parent (5-minute bucket, threshold 50), native Windows resource-exhaustion detector events, and application-hang clustering (3+ hangs in 15 minutes on one host).

Data Sources

Microsoft Defender for Endpoint (DeviceProcessEvents) via Splunk add-onWindows Event Log forwarded to Splunk (Resource-Exhaustion-Detector, Application Hang)

Required Sourcetypes

DeviceProcessEventsWinEventLog:Application

False Positives & Tuning

  • CI/CD or test automation spawning many short-lived child processes
  • Installer/update tooling spawning helper processes
  • A single buggy application hanging repeatedly due to a known local defect

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.

  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.

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

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections

Tactic Hub