T1499

Endpoint Denial of Service

Impact Last updated:

Adversaries may perform Endpoint Denial of Service (DoS) attacks to degrade or block the availability of services to users. Endpoint DoS can be performed by exhausting system resources (CPU, memory, disk, network connections) or exploiting the system to cause a persistent crash condition. Unlike network-saturating DDoS, Endpoint DoS targets the application stack layers hosted on the victim system — including OS, web servers, DNS, databases, and web applications. Attackers may use IP spoofing, botnets, or direct tools such as hping3, stress-ng, Apache Bench, and custom scripts to generate floods. Observed threat actors include Sandworm Team (disrupting Georgian government websites) and ZxShell malware (SYN flood capability). This detection covers the execution of known DoS tools, abnormal network connection volume from single processes, and resource exhaustion indicators.

What is T1499 Endpoint Denial of Service?

Endpoint Denial of Service (T1499) 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, covering the data sources and telemetry it touches: Process: Process Creation, Network Traffic: Network Connection Creation, Microsoft Defender for Endpoint. 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
Technique
T1499 Endpoint Denial of Service
Canonical reference
https://attack.mitre.org/techniques/T1499/
Microsoft Sentinel / Defender
kusto 
let KnownDoSTools = dynamic([
  "hping3", "hping", "stress-ng", "stress", "memtester",
  "ab.exe", "ab", "siege", "wrk", "wrk2", "slowloris",
  "loic", "hoic", "goldeneye", "hulk", "pyloris",
  "torsocks", "rudy", "xerxes", "torshammer",
  "mz", "ncrack", "thc-ssl-dos"
]);
let DoSCommandPatterns = dynamic([
  "--flood", "--syn", "-S --flood", "--icmp --flood",
  "stress --cpu", "stress --vm", "stress --io", "stress-ng --cpu",
  "stress-ng --vm", "stress-ng --sock", "--workers",
  ":(){ :|:", "fork bomb",
  "-c 10000", "-n 100000", "--concurrency 5000"
]);
let HighConnectionThreshold = 500;
// Detection 1: Known DoS tool execution
let DoSToolExecution =
DeviceProcessEvents
| where Timestamp > ago(1h)
| where FileName has_any (KnownDoSTools)
   or ProcessCommandLine has_any (DoSCommandPatterns)
| extend DetectionType = "KnownDoSTool"
| extend RiskIndicator = strcat(FileName, " | ", ProcessCommandLine);
// Detection 2: Abnormal outbound connection volume from a single process (potential flood)
let NetworkFlood =
DeviceNetworkEvents
| where Timestamp > ago(10m)
| where ActionType in ("ConnectionSuccess", "ConnectionRequest", "ConnectionFailed")
| summarize
    ConnectionCount = count(),
    UniqueDestIPs = dcount(RemoteIP),
    UniqueDestPorts = dcount(RemotePort),
    Protocols = make_set(Protocol),
    EarliestConn = min(Timestamp),
    LatestConn = max(Timestamp)
  by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessAccountName
| where ConnectionCount > HighConnectionThreshold
| extend DetectionType = "NetworkFlood"
| extend RiskIndicator = strcat("ConnectionCount=", ConnectionCount, " UniqueIPs=", UniqueDestIPs);
// Detection 3: Rapid fork / process spawning (potential fork bomb or process exhaustion)
let ProcessExhaustion =
DeviceProcessEvents
| where Timestamp > ago(5m)
| summarize
    ProcessCount = count(),
    UniqueExecutables = dcount(FileName),
    ParentProcesses = make_set(InitiatingProcessFileName, 5)
  by DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName
| where ProcessCount > 200 and UniqueExecutables < 3
| extend DetectionType = "ProcessSpawnExhaustion"
| extend RiskIndicator = strcat("ProcessCount=", ProcessCount, " UniqueExe=", UniqueExecutables);
// Union all detections
DoSToolExecution
| project Timestamp, DeviceName, AccountName=InitiatingProcessAccountName,
          DetectionType, FileName, ProcessCommandLine, InitiatingProcessFileName,
          InitiatingProcessCommandLine, RiskIndicator
| union (
    NetworkFlood
    | project
        Timestamp=EarliestConn, DeviceName,
        AccountName=InitiatingProcessAccountName,
        DetectionType,
        FileName=InitiatingProcessFileName,
        ProcessCommandLine=InitiatingProcessCommandLine,
        InitiatingProcessFileName="",
        InitiatingProcessCommandLine="",
        RiskIndicator
)
| union (
    ProcessExhaustion
    | project
        Timestamp=now(), DeviceName,
        AccountName=InitiatingProcessAccountName,
        DetectionType,
        FileName=InitiatingProcessFileName,
        ProcessCommandLine="",
        InitiatingProcessFileName="",
        InitiatingProcessCommandLine="",
        RiskIndicator
)
| sort by Timestamp desc

Multi-signal detection for Endpoint Denial of Service covering three distinct patterns: (1) Execution of known DoS tools such as hping3, stress-ng, ab, siege, LOIC, and GoldenEye by filename or command-line patterns including --flood, --syn, and high concurrency flags; (2) A single process generating more than 500 outbound network connections within a 10-minute window, indicating application-layer flood behavior; (3) Rapid process spawning where a single parent process creates more than 200 child processes within 5 minutes using fewer than 3 unique executables, indicative of fork bomb or process exhaustion attacks. Results are unioned into a single timeline with a DetectionType field for triage prioritization.

high severity medium confidence

Data Sources

Process: Process Creation Network Traffic: Network Connection Creation Microsoft Defender for Endpoint

Required Tables

DeviceProcessEvents DeviceNetworkEvents

False Positives

  • Performance testing teams running Apache Bench (ab), wrk, or siege against internal load balancers or staging environments during authorized load tests
  • Site reliability engineers running stress-ng or stress on Linux servers to validate autoscaling or hardware under controlled conditions
  • Security teams using hping3 for legitimate network diagnostic or firewall rule testing in authorized environments
  • High-throughput legitimate services (CDN proxies, load balancers, streaming servers) that maintain large persistent connection pools
  • Deployment automation or CI/CD pipeline jobs that spawn many short-lived processes in rapid succession during build or test phases

Sigma rule & cross-platform mapping

The detection logic for Endpoint Denial of Service (T1499) 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:

SigmaHQ rules for T1499 Sigma rules on detection.fyi

Platform-specific guides for T1499

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-04-19 Research depth: deep
References (8)

Testing Methodology

Validate this detection against 4 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 1CPU Exhaustion with stress-ng (Linux)

    Expected signal: Sysmon for Linux Event ID 1 (Process Create): Image=/usr/bin/stress-ng, CommandLine contains '--cpu 0 --cpu-load 100'. Linux audit log (execve syscall): stress-ng invocation. /proc/loadavg will show load equal to number of CPU cores during test window. System CPU utilization in monitoring tools should spike to 100%.

  2. Test 2HTTP Flood Simulation with Apache Bench (Windows/Linux)

    Expected signal: Sysmon Event ID 1: Image=ab.exe, CommandLine contains '-n 50000 -c 500'. Sysmon Event ID 3: Rapid outbound connections to 127.0.0.1:80. NetworkFlood branch will aggregate these into the 10-minute bucket. Windows Firewall log entries for loopback connections may appear if firewall logging is enabled.

  3. Test 3SYN Flood Simulation with hping3 (Linux — requires root)

    Expected signal: Sysmon for Linux Event ID 1: Image=/usr/sbin/hping3, CommandLine contains '--syn --rand-source --flood'. Linux audit log: execve syscall for hping3 with full arguments. Network statistics: netstat or ss will show spike in SYN connections on the loopback interface. /proc/net/tcp will show many half-open connections.

  4. Test 4Fork Bomb Execution — Limited Variant (Linux)

    Expected signal: Sysmon for Linux Event ID 1: 50+ Process Create events from the same parent bash PID within seconds, all spawning 'sleep' processes. ProcessSpawnExhaustion bucket will accumulate ProcessCount=50+ with UniqueExecutables=1 (sleep). Parent process command line contains the for loop.

Response Playbook

Triage

  1. Identify the detection type from the alert — KnownDoSTool, NetworkFlood, or ProcessSpawnExhaustion — as each has a different triage path. Tool execution is highest priority; network flood may be authorized load testing.
  2. For KnownDoSTool alerts: check the parent process of the DoS tool. Was it launched by a user session, a script, a cron job, or a compromised service? Interactive user sessions are more suspicious than scheduled jobs with a change ticket.
  3. Check whether there is an active change window, pentest engagement, or load test scheduled. Query your change management system for the host and time window. If a ticket exists, verify the scope and requester match the observed activity.
  4. Assess the target: is the flood aimed at an internal resource (staging server) or external production service? Internal targets during load testing hours are lower risk; external targets with no authorized test are critical.
  5. For NetworkFlood alerts: examine the destination IPs and ports. Are they all the same target (focused flood) or varied (scanning)? A single target on port 80/443 suggests HTTP flood; varied ports suggest a broader attack or scanning precursor.
  6. For ProcessSpawnExhaustion alerts: examine the spawned process name. If it is a shell (sh, bash, cmd.exe) looping on itself, treat it as a fork bomb attempt. Check uptime and CPU utilization of the host via EDR telemetry.
  7. Determine scope — is this a single host or multiple endpoints showing the same pattern? Multiple hosts within minutes indicates botnet membership or automated malware propagation rather than an isolated admin error.

Containment

  1. If active flood ongoing and impacting production: immediately isolate the endpoint from the network using EDR isolation to stop outbound attack traffic while preserving forensic evidence on disk.
  2. If process exhaustion (fork bomb) has caused system instability: initiate a graceful reboot via out-of-band management (IPMI/iLO/iDRAC) rather than relying on a potentially unresponsive OS. Capture a memory dump first if the system is still responsive.
  3. Kill the offending process tree using EDR live response. For Linux: `kill -9 <PID>` of the stress/hping parent. For Windows: `taskkill /F /T /PID <PID>` to terminate entire process tree.
  4. If the DoS tool was deployed by an attacker (malware or compromised account): treat this as a full incident. Disable the user account, revoke active sessions, and preserve logs before isolation.
  5. Apply rate-limiting at the network perimeter or host-based firewall for the specific source IP and protocol if the attack is ongoing and isolation is not yet possible.
  6. If multiple hosts are affected (botnet scenario): engage IR team for coordinated containment. Do not isolate hosts one at a time without a coordinated plan, as the attacker may shift traffic.

Evidence Collection

  1. Process creation logs — Sysmon Event ID 1 or Security Event ID 4688 (with command-line auditing enabled): captures the DoS tool invocation with full command-line arguments and parent process context.
  2. Network connection logs — Sysmon Event ID 3: captures every outbound connection including destination IP, port, and protocol to reconstruct the flood target and volume.
  3. Memory dump of the offending process (if still running): `procdump -ma <PID> c:\temp\dos_process.dmp` on Windows; `gcore <PID>` on Linux. Preserves any injected code or in-memory configuration.
  4. Running process list at time of detection: `tasklist /v` (Windows) or `ps auxf` (Linux) to capture the full process tree before containment kills it.
  5. Network statistics snapshot: `netstat -anob` (Windows) or `ss -tunp` (Linux) to count active connections and identify target endpoints.
  6. System performance metrics: `typeperf "\Processor(_Total)\% Processor Time" -sc 60` (Windows) or `sar -u 1 60` (Linux) to document resource exhaustion impact.
  7. Windows System Event Log (Event ID 7034 — service crashed, Event ID 7035 — service control, Event ID 6008 — unexpected shutdown) for evidence of service interruption caused by the DoS.
  8. File artifacts of the DoS tool: hash the binary and search threat intelligence platforms. Check creation timestamp and digital signature with `Get-AuthenticodeSignature` (Windows) or `file` + `strings` (Linux).

Escalation Criteria

  • ! Attack is targeting production systems (web servers, DNS, databases) and causing measurable service degradation or availability impact to end users.
  • ! DoS tool was deployed by malware or via a compromised account — this indicates the endpoint is part of a larger attack campaign, not isolated misuse.
  • ! Multiple endpoints showing the same DoS behavior within a short window — indicates botnet infection or lateral movement followed by coordinated attack launch.
  • ! Evidence of C2 communication prior to DoS tool execution — the attack is remotely orchestrated, not locally initiated.
  • ! DoS activity targeting critical infrastructure, financial systems, or healthcare environments where availability impact has regulatory or safety implications.
  • ! The attacking process cannot be terminated via normal means and persists after attempted kill — indicates kernel-level rootkit or a driver-based attack mechanism requiring specialized remediation.

Investigation Guide

Forensic Artifacts

  • > Windows Prefetch: C:\Windows\Prefetch\HPING3.EXE-*.pf, STRESS-NG.EXE-*.pf — confirms tool execution and timestamps even after process termination.
  • > Windows Event Log (System): Event ID 6008 (unexpected shutdown), Event ID 7034 (service terminated unexpectedly), Event ID 7035 (service control) — evidence of service impact from DoS.
  • > Linux /var/log/syslog or /var/log/messages: OOM killer events (kernel: Out of memory: Kill process) indicate successful memory exhaustion DoS.
  • > Linux /proc/<PID>/cmdline and /proc/<PID>/net/tcp or /proc/<PID>/net/tcp6: real-time network connection counts per process — useful for in-progress investigation.
  • > Network flow records (NetFlow/IPFIX): source/destination IP pairs with packet and byte counts — identifies flood targets and volume. Look in SIEM for flow data around the alert timestamp.
  • > Windows Performance Monitor logs (if enabled): CPU, memory, and network interface utilization showing resource exhaustion correlated with process activity.
  • > Linux audit log (/var/log/audit/audit.log): execve syscall records for DoS tool execution if auditd rules cover the binary paths.
  • > Downloaded DoS tool binary: hash against VirusTotal. Examine file metadata (creation time, last modified, digital signature). Check browser history or download manager logs for the retrieval source URL.
  • > Scheduled tasks and cron jobs: `schtasks /query /fo LIST /v` (Windows) or `crontab -l` and `/etc/cron.*` (Linux) — attacker may have installed persistence to relaunch the tool after reboot.

Tuning Guidance

The highest source of false positives for this detection is authorized performance and load testing. Maintain an allowlist of accounts, subnets, and time windows associated with scheduled load tests (e.g., the QA subnet during business hours on Tuesdays). Integrate with your change management system to automatically suppress alerts when a valid load test ticket is active for the host in question. For the NetworkFlood branch, calibrate the 500-connection threshold against your baseline — high-traffic servers (proxies, streaming services, web frontends) may legitimately exceed this. Consider raising the threshold to 2000 for servers and keeping 500 for workstations. For the ProcessSpawnExhaustion branch, CI/CD build agents and test runners may legitimately spawn hundreds of short-lived processes. Exclude known build agent hostnames or service account names. For the KnownDoSTool branch, security team hosts running authorized assessments should be excluded by hostname or tag. Never exclude by username alone — attacker may compromise that account. Consider adding a severity modifier: if the destination IP of a flood belongs to a known external production service (as tagged in your CMDB), escalate severity from high to critical regardless of other context.

Hunting Queries

Hunt for network flood patterns by looking at per-minute connection rates per process. Calculates a FloodScore based on volume, target diversity, and failure rates — a high connection count to a narrow set of destinations or ports is a stronger DoS indicator than distributed connections. Covers SYN flood patterns (high failure rate) and HTTP flood patterns (concentrated port 80/443).

Hunting — KQL
kql 
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where ActionType in ("ConnectionRequest", "ConnectionSuccess", "ConnectionFailed")
| summarize
    TotalConnections = count(),
    UniqueDestIPs = dcount(RemoteIP),
    UniqueDestPorts = dcount(RemotePort),
    SamePortRatio = countif(RemotePort == 80) * 100 / count(),
    SynFailRate = countif(ActionType == "ConnectionFailed") * 100 / count()
  by bin(Timestamp, 1m), DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName
| where TotalConnections > 100
| extend FloodScore = case(
    TotalConnections > 1000 and UniqueDestIPs < 5, 3,
    TotalConnections > 500 and SynFailRate > 50, 2,
    TotalConnections > 100 and UniqueDestPorts < 3, 1,
    0
  )
| where FloodScore > 0
| sort by FloodScore desc, TotalConnections desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
| bucket span=1m _time
| stats
    count as TotalConns,
    dc(DestinationIp) as UniqueDestIPs,
    dc(DestinationPort) as UniqueDestPorts,
    count(eval(DestinationPort==80)) as Port80Count
  by _time, host, Image, User
| eval SamePortRatio=round(Port80Count*100/TotalConns, 1)
| where TotalConns > 100
| eval FloodScore=case(
    TotalConns > 1000 AND UniqueDestIPs < 5, 3,
    TotalConns > 500 AND SamePortRatio > 70, 2,
    TotalConns > 100 AND UniqueDestPorts < 3, 1,
    true(), 0
  )
| where FloodScore > 0
| sort - FloodScore, - TotalConns

Hunt for DoS tools launched from scripting interpreters (cmd, bash, Python) which may indicate automated or scripted flood initiation. Also looks for high-count flags (-c/-n with 4+ digit values) that suggest volume flooding regardless of tool name. This catches tool variations and obfuscated invocations that the primary detection may miss due to renamed binaries.

Hunting — KQL
kql 
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("cmd.exe", "bash", "sh", "python.exe", "python3", "python")
| where ProcessCommandLine has_any ("hping", "stress", "ab ", "siege ", "wrk ", "curl --parallel", "wget --mirror", "ping -f", "ping -l 65500")
   or ProcessCommandLine matches regex @"-[cCnN]\s+[0-9]{4,}"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  (ParentImage="*\\cmd.exe" OR ParentImage="*\\bash" OR ParentImage="*\\sh" OR ParentImage="*\\python.exe" OR ParentImage="*\\python3")
  (CommandLine="*hping*" OR CommandLine="*stress*" OR CommandLine="*ab *" OR CommandLine="*siege *" OR CommandLine="*wrk *" OR CommandLine="*ping -f*" OR CommandLine="*ping -l 65500*")
| rex field=CommandLine "(?i)-[cCnN]\s+(?<RequestCount>[0-9]+)"
| eval HighVolume=if(tonumber(RequestCount) > 9999, 1, 0)
| table _time, host, User, Image, CommandLine, ParentImage, ParentCommandLine, RequestCount, HighVolume
| sort - _time

Hunt for application-layer flood attempts using common scripting tools with parallelism flags. Adversaries often use curl --parallel, Python asyncio/aiohttp, or Node.js cluster workers to generate high-volume HTTP floods without specialized tools. This hunt identifies legitimate-looking binaries being used at scale for flooding, covering T1499.003 (Application Exhaustion Flood) scenarios that named-tool detection misses.

Hunting — KQL
kql 
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("curl", "curl.exe", "wget", "python.exe", "python3", "node.exe", "node")
| where ProcessCommandLine has_any (
    "--parallel", "--parallel-max", "--rate",
    "asyncio", "aiohttp", "ThreadPoolExecutor",
    "cluster", "child_process", "workers"
  )
| summarize
    EventCount = count(),
    UniqueDevices = dcount(DeviceName),
    EarliestSeen = min(Timestamp),
    LatestSeen = max(Timestamp),
    SampleCommands = make_set(ProcessCommandLine, 3)
  by AccountName, FileName
| where EventCount > 5
| sort by EventCount desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  (Image="*\\curl.exe" OR Image="*\\wget" OR Image="*\\python.exe" OR Image="*\\python3" OR Image="*\\node.exe")
  (CommandLine="*--parallel*" OR CommandLine="*--rate*" OR CommandLine="*asyncio*" OR CommandLine="*aiohttp*" OR CommandLine="*ThreadPoolExecutor*" OR CommandLine="*--parallel-max*")
| stats
    count as EventCount,
    dc(host) as UniqueDevices,
    earliest(_time) as EarliestSeen,
    latest(_time) as LatestSeen,
    values(CommandLine) as SampleCommands
  by User, Image
| where EventCount > 5
| sort - EventCount

Atomic Red Team Tests

Test 1 CPU Exhaustion with stress-ng (Linux)
linux

Uses stress-ng to fully saturate all available CPU cores for 30 seconds on a Linux system. This simulates an OS Exhaustion Flood (T1499.001) that an adversary might use to degrade server performance or trigger watchdog-based service crashes. The test is self-terminating at 30 seconds and does not require cleanup.

Command

bash 
stress-ng --cpu 0 --cpu-load 100 --timeout 30s --metrics-brief

Cleanup

bash 
killall stress-ng 2>/dev/null || true

Expected Telemetry

Sysmon for Linux Event ID 1 (Process Create): Image=/usr/bin/stress-ng, CommandLine contains '--cpu 0 --cpu-load 100'. Linux audit log (execve syscall): stress-ng invocation. /proc/loadavg will show load equal to number of CPU cores during test window. System CPU utilization in monitoring tools should spike to 100%.

Expected Detection

KQL: DoSToolExecution branch fires on FileName matching 'stress-ng' pattern. SPL: Branch 1 fires on Image='*stress-ng*' with CommandLine matching '--cpu'. Both detect within seconds of process creation via Sysmon Event ID 1.

Test 2 HTTP Flood Simulation with Apache Bench (Windows/Linux)
windows

Uses Apache Bench (ab) to send 50,000 HTTP requests with concurrency of 500 against a local test target. This simulates T1499.002 (Service Exhaustion Flood) and T1499.003 (Application Exhaustion Flood) patterns. The target is localhost:80 to avoid any external impact — ensure a local web server is running or the test will complete quickly with connection errors (both scenarios generate the same telemetry).

Command

powershell 
ab -n 50000 -c 500 -r http://127.0.0.1:80/

Expected Telemetry

Sysmon Event ID 1: Image=ab.exe, CommandLine contains '-n 50000 -c 500'. Sysmon Event ID 3: Rapid outbound connections to 127.0.0.1:80. NetworkFlood branch will aggregate these into the 10-minute bucket. Windows Firewall log entries for loopback connections may appear if firewall logging is enabled.

Expected Detection

KQL: DoSToolExecution fires on FileName='ab.exe'. NetworkFlood fires after connection count exceeds 500 in the 10-minute window. SPL: Branch 1 fires on Image matching ab.exe with high -c value; Branch 2 fires on connection count threshold. Both should alert within 1-2 minutes of test start.

Test 3 SYN Flood Simulation with hping3 (Linux — requires root)
linux

Uses hping3 to generate a SYN flood against localhost port 80. The --rand-source flag randomizes the source IP to simulate IP spoofing (a common real-world DDoS technique). Count is limited to 10,000 packets to keep the test brief. This directly simulates ZxShell's documented SYN flood capability and tests T1499.002 (Service Exhaustion Flood) detection.

Command

bash 
sudo hping3 --syn --rand-source --flood -c 10000 -p 80 127.0.0.1

Cleanup

bash 
sudo killall hping3 2>/dev/null || true

Expected Telemetry

Sysmon for Linux Event ID 1: Image=/usr/sbin/hping3, CommandLine contains '--syn --rand-source --flood'. Linux audit log: execve syscall for hping3 with full arguments. Network statistics: netstat or ss will show spike in SYN connections on the loopback interface. /proc/net/tcp will show many half-open connections.

Expected Detection

KQL: DoSToolExecution fires on FileName matching 'hping3' and CommandLine matching '--flood' and '--syn'. SPL: Branch 1 fires on Image='*hping3*' CommandLine='*--flood*'. Both detect within seconds of process creation event.

Test 4 Fork Bomb Execution — Limited Variant (Linux)
linux

Executes a resource-limited fork bomb variant using bash that spawns child processes but with an enforced process count ceiling via ulimit. The standard fork bomb `:(){ :|:& };:` is intentionally NOT used as it can render a system unresponsive. This safe variant tests process spawn detection without system risk: it spawns 50 background sleep processes from a single parent, simulating the ProcessSpawnExhaustion pattern without actual system harm.

Command

bash 
bash -c 'for i in $(seq 1 50); do sleep 10 & done; echo "spawned 50 children"; wait'

Cleanup

bash 
kill $(jobs -p) 2>/dev/null || true

Expected Telemetry

Sysmon for Linux Event ID 1: 50+ Process Create events from the same parent bash PID within seconds, all spawning 'sleep' processes. ProcessSpawnExhaustion bucket will accumulate ProcessCount=50+ with UniqueExecutables=1 (sleep). Parent process command line contains the for loop.

Expected Detection

KQL: ProcessSpawnExhaustion fires when ProcessCount > 200 threshold is not met at 50 processes — adjust test to spawn 250+ processes if validating threshold detection. SPL: Branch 3 similarly requires count > 200. To validate detection at lower thresholds, adjust the for loop range: `seq 1 250`. The test as written validates telemetry collection without necessarily triggering the alert.

Related Detections

Tactic Hub

TA0040Impact

Sub-techniques (4)

Related Techniques

T1499.001OS Exhaustion FloodT1499.002Service Exhaustion FloodT1499.003Application Exhaustion FloodT1499.004Application or System ExploitationT1498Network Denial of ServiceT1489Service StopT1485Data DestructionT1496Resource HijackingT1059Command and Scripting InterpreterT1105Ingress Tool Transfer

Same Tactic: Impact

Popular Detections