T1498

Network Denial of Service

Impact Last updated:

Adversaries may perform Network Denial of Service (DoS) attacks to degrade or block the availability of targeted resources to users. Network DoS can be performed by exhausting the network bandwidth services rely on. This includes direct network floods and reflection amplification attacks targeting websites, DNS, email services, and web-based applications. Attackers may use botnets, IP spoofing, and distributed systems to amplify attack volume and obscure the origin. Real-world usage includes APT28 DDoS attacks against WADA, NKAbuse malware with multi-protocol DoS capabilities, and Lucifer malware executing TCP/UDP/HTTP floods.

What is T1498 Network Denial of Service?

Network Denial of Service (T1498) 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 Network Denial of Service, covering the data sources and telemetry it touches: Process: Process Creation, Network Traffic: Network Connection Creation, Network Traffic: Network Traffic Flow, 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
T1498 Network Denial of Service
Canonical reference
https://attack.mitre.org/techniques/T1498/
Microsoft Sentinel / Defender
kusto 
let KnownDosTools = dynamic([
  "hping3", "hping", "nping", "loic", "hoic", "slowloris", "goldeneye",
  "mausezahn", "t50", "trinoo", "tfn", "tfn2k", "stacheldraht", "trin00",
  "udpflood", "synflood", "icmpflood", "rudy", "pyloris", "xerxes",
  "hulk", "thc-ssl-dos", "siege", "ab.exe", "wrk", "vegeta"
]);
let DosToolPatterns = dynamic([
  "--flood", "--faster", "-flood", "--ddos", "-ddos",
  "sendudp", "sendtcp", "synflood", "udpflood", "icmpflood",
  "--interval 0", "-i 0", "--count 999999", "-c 999999",
  "nmap --script dos", "metasploit auxiliary/dos"
]);
let HighVolumeConnThreshold = 500;
let LookbackWindow = 1h;
// Detection 1: Known DoS tool execution
let DosToolExec = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName has_any (KnownDosTools)
    or ProcessCommandLine has_any (DosToolPatterns)
    or ProcessCommandLine has_any (KnownDosTools)
| extend DetectionSource = "KnownDoSTool"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, InitiatingProcessCommandLine, DetectionSource;
// Detection 2: Anomalous outbound connection volume per process
let HighVolumeOutbound = DeviceNetworkEvents
| where Timestamp > ago(24h)
| where ActionType == "ConnectionSuccess" or ActionType == "ConnectionAttempt"
| where RemoteIPType == "Public"
| summarize
    ConnectionCount = count(),
    UniqueRemoteIPs = dcount(RemoteIP),
    UniqueRemotePorts = dcount(RemotePort),
    Protocols = make_set(Protocol),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, bin(Timestamp, LookbackWindow)
| where ConnectionCount > HighVolumeConnThreshold
    or UniqueRemoteIPs > 50
| extend DetectionSource = "HighVolumeOutboundConnections"
| project FirstSeen, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
         ConnectionCount, UniqueRemoteIPs, UniqueRemotePorts, Protocols, DetectionSource;
// Detection 3: Rapid repeated connection attempts to single target (SYN flood indicator)
let SynFloodIndicator = DeviceNetworkEvents
| where Timestamp > ago(24h)
| where ActionType == "ConnectionAttempt"
| where RemoteIPType == "Public"
| summarize
    AttemptCount = count(),
    UniqueLocalPorts = dcount(LocalPort),
    FirstAttempt = min(Timestamp),
    LastAttempt = max(Timestamp)
    by DeviceName, RemoteIP, RemotePort, InitiatingProcessFileName, bin(Timestamp, 5m)
| where AttemptCount > 200
| extend AttemptsPerSecond = AttemptCount / 300.0
| extend DetectionSource = "RapidConnectionAttempts"
| project FirstAttempt, DeviceName, RemoteIP, RemotePort, AttemptCount,
         AttemptsPerSecond, InitiatingProcessFileName, DetectionSource;
// Union all detection sources
DosToolExec
| union kind=outer (
    HighVolumeOutbound | extend RemoteIP = "", RemotePort = 0
)
| union kind=outer (
    SynFloodIndicator | extend AccountName = "", ProcessCommandLine = InitiatingProcessFileName
)
| sort by Timestamp desc

Detects Network Denial of Service (T1498) activity through three complementary detection patterns: (1) execution of known DoS/DDoS tools by process name and command-line flags, (2) anomalous outbound connection volume indicating a flood attack originating from the host, and (3) rapid repeated connection attempts to a single remote IP/port suggesting SYN flood behavior. Uses DeviceProcessEvents and DeviceNetworkEvents tables from Microsoft Defender for Endpoint. The union approach covers both tool-based and behavioral detection angles. Thresholds (500 connections per hour, 200 attempts per 5-minute window) should be tuned per environment.

high severity medium confidence

Data Sources

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

Required Tables

DeviceProcessEvents DeviceNetworkEvents

False Positives

  • Legitimate load testing tools (Apache Bench, siege, wrk, k6) used by QA or DevOps teams against internal or staging systems
  • Network scanners (Nmap, Masscan) run by authorized penetration testers or vulnerability management platforms
  • High-volume legitimate services such as CDN edge nodes, torrent clients, or P2P applications that generate many simultaneous outbound connections
  • Security research environments or honeypot systems configured to generate high connection volumes for traffic analysis
  • Monitoring or synthetic testing agents that make frequent connections to multiple endpoints for uptime checks

Sigma rule & cross-platform mapping

The detection logic for Network Denial of Service (T1498) 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 T1498 Sigma rules on detection.fyi

Platform-specific guides for T1498

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-03-15 Research depth: deep
References (4)

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 1hping3 SYN Flood Simulation (Linux)

    Expected signal: Linux audit log (auditd): execve syscall for hping3 with arguments --syn --flood. Syslog: process creation event for hping3. /proc/<PID>/net/tcp: rapid socket creation and teardown on loopback. If auditd is configured with EXECVE rules, Event type=EXECVE will capture the full command line.

  2. Test 2PowerShell UDP Flood Script (Windows)

    Expected signal: Sysmon Event ID 1: Process Create for powershell.exe with CommandLine containing UdpClient and 127.0.0.1. Sysmon Event ID 3: 1000 UDP network connection events from powershell.exe to 127.0.0.1:19999. PowerShell ScriptBlock Log Event ID 4104: full script including UdpClient instantiation and send loop.

  3. Test 3LOIC-style HTTP Flood via curl Loop (Linux/macOS)

    Expected signal: Linux audit log: 200 execve syscalls for curl in rapid succession from the same parent shell PID. Syslog: process creation events for curl children. Network: 200 TCP connection attempts to 127.0.0.1:80 in rapid succession. Process table (ps aux) will show many curl processes during execution.

  4. Test 4nping ICMP Flood (Linux)

    Expected signal: Linux audit log: execve for nping with --icmp --rate 500 arguments. If sysmon-for-linux is deployed, Sysmon Event ID 1 will capture the full command line. Network monitoring: 1000 ICMP packets at 500 packets/second burst on loopback. /proc/net/snmp ICMP InMsgs counter increments rapidly during test.

Response Playbook

Triage

  1. Determine whether the alert originated from a tool-based detection (known DoS binary) or a behavioral detection (high connection volume). Tool-based alerts are higher confidence and should be escalated faster.
  2. Identify the source host and responsible process. Check the process parent chain — was the DoS tool spawned by a user shell, a scheduled task, a service, or a remote execution mechanism like WMI/PSExec?
  3. Check the user context running the process. Is this a regular user, a service account, or SYSTEM? Verify whether this user or host would legitimately run network testing tools.
  4. Determine the target of the traffic. Are connections directed at a single external IP (targeted attack), a broad range of IPs (scanning/botnet activity), or are they destined for an internal system?
  5. Check network egress logs and firewall data to understand whether traffic actually left the network perimeter or was blocked by upstream controls.
  6. Review the timeline: when did the high-volume traffic start? Does it correlate with any change management events, user logins, or suspicious process execution preceding the flood?
  7. If the host is a cloud VM or container, check cloud provider network flow logs (Azure NSG Flow Logs, AWS VPC Flow Logs) to confirm actual traffic volume and destination — Sysmon-level data may undercount if the attacking process uses raw sockets.
  8. Correlate with threat intelligence — check the destination IP(s) against known threat actor infrastructure, victim lists (hacktivist targets), and IP reputation feeds.

Containment

  1. Immediately isolate the compromised host from the network using EDR network isolation or emergency ACL/VLAN change to stop outbound flood traffic at the source.
  2. If the host is a cloud VM, apply an emergency security group rule blocking all egress traffic except management ports, or snapshot and terminate the instance.
  3. Block the offending process hash at the EDR level across all endpoints to prevent lateral spread if the DoS tool was deployed as part of a broader malware campaign.
  4. Notify upstream ISP or cloud provider (e.g., Azure DDoS Protection, AWS Shield) if the attack is originating from your infrastructure and targeting third parties — this may be a legal and compliance obligation.
  5. If the DoS activity is inbound (your assets are the victim), engage your DDoS mitigation provider (Cloudflare Magic Transit, Akamai Prolexic, AWS Shield Advanced) and apply upstream null-routing or scrubbing for the targeted IP range.
  6. Rotate credentials for any accounts associated with the compromised host, as DoS tool deployment often accompanies broader compromise.
  7. Preserve a memory image and disk snapshot of the affected host before remediation to retain forensic evidence.

Evidence Collection

  1. Full process tree from EDR: capture parent process, grandparent process, siblings, and all child processes spawned around the time of the DoS tool execution.
  2. Sysmon Event ID 1 (Process Create): command line, image path, parent image, hashes (MD5/SHA256), user, working directory for the DoS tool process.
  3. Sysmon Event ID 3 (Network Connection): destination IPs, ports, protocols, connection timestamps, and associated process for the attack window.
  4. Sysmon Event ID 11 (File Create): any files written by the DoS tool or its installer (configuration files, payloads, persistence mechanisms).
  5. Windows Security Event ID 4688: process creation events if Sysmon is unavailable, with command line auditing enabled.
  6. Network flow data from the host (Windows netstat -ano output captured live, or network tap/firewall logs) to quantify actual traffic volume.
  7. Prefetch file for the DoS tool executable (C:\Windows\Prefetch\<TOOLNAME>.EXE-*.pf) to establish execution timestamps and loaded libraries.
  8. Memory image of the DoS process if still running — may contain C2 configuration, target lists, or decrypted payloads.
  9. Filesystem artifacts: check common drop locations (%TEMP%, %APPDATA%, C:\ProgramData, /tmp, /var/tmp) for the tool binary and any configuration or target files.
  10. Scheduled tasks, services, and startup locations to determine if persistence was established for recurring DoS execution.

Escalation Criteria

  • ! DoS tool confirmed as part of a known malware family (NKAbuse, Lucifer, Mirai variant) — escalate immediately as broader compromise is likely.
  • ! Traffic is directed at critical infrastructure targets (financial institutions, healthcare, government) — legal and regulatory notification obligations may apply.
  • ! Multiple hosts in the environment are participating in the flood — indicates botnet infection requiring enterprise-wide response.
  • ! DoS activity coincides with other attack techniques (credential dumping, lateral movement, data staging) — the flood may be a distraction for concurrent intrusion activity.
  • ! The source host is a production server, domain controller, or security appliance — the blast radius of compromise is significantly higher.
  • ! Outbound traffic volume is exhausting the organization's upstream bandwidth, impacting business operations of legitimate users.
  • ! Attribution indicators (C2 infrastructure, tool signatures, behavioral patterns) link the activity to a nation-state threat actor or known cybercrime group.

Investigation Guide

Forensic Artifacts

  • > File System: DoS tool binary in common drop paths (%TEMP%, %APPDATA%\Roaming, C:\ProgramData, /tmp, /var/tmp, /dev/shm)
  • > File System: Configuration files with target IP lists, flood parameters, C2 callback addresses (often JSON, INI, or plaintext)
  • > Registry: HKLM\SYSTEM\CurrentControlSet\Services\ — check for malicious service installation as DoS bot persistence mechanism
  • > Registry: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run — user-level autorun persistence for the DoS tool
  • > Windows Event Log: System Log Event ID 7045 (new service installed) if DoS tool installed as a service
  • > Network: Established connections in netstat output (netstat -ano) mapping PIDs to active flood connections
  • > Network: ARP cache and routing table — may reveal unusual gateway or routing changes that redirect traffic
  • > Memory: Process memory of running DoS tool may contain: embedded target lists, C2 URLs, flood protocol parameters, XOR keys for config decryption
  • > Scheduled Tasks: C:\Windows\System32\Tasks\ or C:\Windows\SysWOW64\Tasks\ — XML task definitions for recurring flood execution
  • > Linux/macOS: /etc/crontab, /var/spool/cron/, /etc/cron.d/ — persistence via cron for recurring DoS execution
  • > Linux/macOS: /proc/<PID>/net/tcp and /proc/<PID>/net/udp — active connections for a running DoS process
  • > Cloud: Azure NSG Flow Logs (Log Analytics table: AzureNetworkAnalytics_CL) showing outbound byte volumes
  • > Cloud: AWS VPC Flow Logs for EC2 instances showing connection counts and byte totals

Tuning Guidance

The primary challenge with T1498 detections is distinguishing malicious flood activity from legitimate high-volume network applications. Begin by baselining normal connection counts per process per hour for your environment — development and testing systems, CDN nodes, and media servers may legitimately exceed the default thresholds. Build process-based allowlists for known load testing and monitoring tools (Apache Bench, k6, Pingdom agents) tied to specific source hosts rather than environment-wide exclusions. For cloud environments, supplement Sysmon-based detections with Azure NSG Flow Logs or AWS VPC Flow Logs, which provide byte-level volumetrics that process connection counts cannot capture — a single TCP connection can still transfer gigabytes. Tune the connection count threshold based on 95th-percentile baseline: if your busiest legitimate process makes 150 connections per hour, set the threshold at 3-4x that value (450-600). For the SYN flood pattern (rapid attempts to one target), the false positive rate is much lower — legitimate software rarely makes >100 connection attempts to a single endpoint within 10 minutes without establishing a connection. Consider adding a filter requiring ActionType=="ConnectionAttempt" without a subsequent ConnectionSuccess to tighten the SYN flood indicator. For environments using NKAbuse or similar blockchain-C2 malware, add hunting queries for unusual outbound traffic on non-standard high ports (>1024) from processes that typically only make DNS/HTTP connections.

Hunting Queries

Hunt for hosts generating anomalous outbound network connection volumes to public IPs, grouped by process and hour. This identifies potential DoS flood activity that may not match known tool signatures but exhibits volume-based behavioral indicators. Hosts with >300 connections per hour or >30 unique destination IPs warrant investigation.

Hunting — KQL
kql 
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIPType == "Public"
| where ActionType in ("ConnectionSuccess", "ConnectionAttempt", "ConnectionFailed")
| summarize
    TotalConnections = count(),
    UniqueDestIPs = dcount(RemoteIP),
    UniqueDestPorts = dcount(RemotePort),
    ProtocolsUsed = make_set(Protocol),
    SampleDestIPs = make_set(RemoteIP, 5)
    by DeviceName, InitiatingProcessFileName, bin(Timestamp, 1h)
| where TotalConnections > 300 or UniqueDestIPs > 30
| extend ConnectionsPerMinute = TotalConnections / 60.0
| sort by TotalConnections desc
| project Timestamp, DeviceName, InitiatingProcessFileName,
         TotalConnections, ConnectionsPerMinute, UniqueDestIPs,
         UniqueDestPorts, ProtocolsUsed, SampleDestIPs
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
NOT (DestinationIp="10.*" OR DestinationIp="172.16.*" OR DestinationIp="192.168.*" OR DestinationIp="127.*")
| bin _time span=1h
| stats
    count as total_conns,
    dc(DestinationIp) as unique_dest_ips,
    dc(DestinationPort) as unique_dest_ports,
    values(DestinationPort) as dest_ports
    by host, Image, _time
| where total_conns > 300 OR unique_dest_ips > 30
| eval conns_per_min=round(total_conns/60, 1)
| sort - total_conns
| table _time, host, Image, total_conns, conns_per_min, unique_dest_ips, unique_dest_ports, dest_ports

Hunt for DoS tool execution by process name and command-line arguments across the full 7-day window. This broader time-window hunt surfaces historical tool usage that may have been missed by real-time detections, enabling timeline reconstruction and identification of initial access vectors.

Hunting — KQL
kql 
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("--flood", "--ddos", "-flood", "synflood", "udpflood",
         "icmpflood", "sendudp", "sendtcp", "--interval 0", "-i 0",
         "--count 9999", "-c 9999", "--faster", "nmap --script dos")
    or FileName has_any ("hping", "nping", "t50", "mausezahn", "trinoo", "tfn",
         "loic", "hoic", "slowloris", "goldeneye", "xerxes", "hulk")
| project Timestamp, DeviceName, AccountName, FileName, SHA256,
         ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| eval img_lower=lower(Image), cmd_lower=lower(CommandLine)
| where match(img_lower, "(hping|nping|t50|mausezahn|trinoo|tfn2k|loic|hoic|slowloris|goldeneye|xerxes|hulk|rudy|siege)")
  OR match(cmd_lower, "(--flood|--ddos|-ddos|synflood|udpflood|icmpflood|sendudp|sendtcp|--interval\s+0|-i\s+0|--faster|nmap.*dos)")
| table _time, host, User, Image, CommandLine, ParentImage, ParentCommandLine, Hashes
| sort - _time

Hunt for concentrated connection attempt bursts toward a single target IP:port combination — a strong behavioral indicator of SYN flood or UDP flood attacks. Unlike the volume-based hunt, this focuses on target concentration (many connections to one endpoint) rather than distribution (many destinations). High attempts-per-minute to a single target with varying source ports suggests port randomization commonly used in automated flood tools.

Hunting — KQL
kql 
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIPType == "Public"
| where ActionType == "ConnectionAttempt"
| summarize
    AttemptCount = count(),
    TimeSpanMinutes = datetime_diff('minute', max(Timestamp), min(Timestamp)),
    InitiatingProcesses = make_set(InitiatingProcessFileName, 3)
    by DeviceName, RemoteIP, RemotePort, bin(Timestamp, 10m)
| where AttemptCount > 100
| where TimeSpanMinutes > 0
| extend AttemptsPerMinute = AttemptCount / (TimeSpanMinutes + 1)
| where AttemptsPerMinute > 20
| sort by AttemptsPerMinute desc
| project Timestamp, DeviceName, RemoteIP, RemotePort,
         AttemptCount, AttemptsPerMinute, InitiatingProcesses
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
NOT (DestinationIp="10.*" OR DestinationIp="172.16.*" OR DestinationIp="192.168.*" OR DestinationIp="127.*")
| bin _time span=10m
| stats
    count as attempt_count,
    dc(SourcePort) as unique_src_ports,
    values(Image) as processes
    by host, DestinationIp, DestinationPort, _time
| where attempt_count > 100
| eval attempts_per_min=round(attempt_count/10, 1)
| where attempts_per_min > 20
| sort - attempt_count
| table _time, host, DestinationIp, DestinationPort, attempt_count, attempts_per_min, unique_src_ports, processes

Atomic Red Team Tests

Test 1 hping3 SYN Flood Simulation (Linux)
linux

Executes a brief SYN flood against localhost using hping3, a widely-used network tool that is frequently weaponized for DoS attacks. The attack is directed at the loopback interface to avoid causing actual network disruption. hping3 is available on most Linux distributions and is used by Lucifer malware and other DoS platforms for TCP flood capabilities. The --count limit ensures the test terminates automatically.

Command

bash 
hping3 --syn --flood --count 500 --interface lo 127.0.0.1 -p 80

Cleanup

bash 
pkill hping3 2>/dev/null; true

Expected Telemetry

Linux audit log (auditd): execve syscall for hping3 with arguments --syn --flood. Syslog: process creation event for hping3. /proc/<PID>/net/tcp: rapid socket creation and teardown on loopback. If auditd is configured with EXECVE rules, Event type=EXECVE will capture the full command line.

Expected Detection

KQL: DeviceProcessEvents with FileName=hping3 and ProcessCommandLine containing --syn and --flood. SPL: Sysmon Event ID 1 (if deployed on Linux via sysmon-for-linux) or auditd exec events matching hping3 with --flood flag. Both detections fire on the known DoS tool process name and flood argument patterns.

Test 2 PowerShell UDP Flood Script (Windows)
windows

Simulates a basic UDP flood using PowerShell's System.Net.Sockets.UdpClient class, directing traffic to localhost on a high port. This technique is used by attackers who cannot deploy binary tools but can execute PowerShell, and mirrors behavioral patterns seen in PowerShell-based DoS scripts. The loop generates 1000 UDP packets and terminates. Targeting localhost ensures no external disruption.

Command

powershell 
powershell.exe -NoProfile -Command "$udp = New-Object System.Net.Sockets.UdpClient; $bytes = [System.Text.Encoding]::ASCII.GetBytes('A' * 1024); 1..1000 | ForEach-Object { $udp.Send($bytes, $bytes.Length, '127.0.0.1', 19999) }; $udp.Close(); Write-Host 'Test complete'"

Expected Telemetry

Sysmon Event ID 1: Process Create for powershell.exe with CommandLine containing UdpClient and 127.0.0.1. Sysmon Event ID 3: 1000 UDP network connection events from powershell.exe to 127.0.0.1:19999. PowerShell ScriptBlock Log Event ID 4104: full script including UdpClient instantiation and send loop.

Expected Detection

SPL high-volume outbound branch: powershell.exe generating >200 connection events to a single target within the 5-minute window fires the RapidConnectionAttempts detection branch. KQL DeviceNetworkEvents: summarize shows >200 ConnectionAttempt events from powershell.exe to 127.0.0.1:19999 within the threshold window.

Test 3 LOIC-style HTTP Flood via curl Loop (Linux/macOS)
linux

Simulates the HTTP flood component used by LOIC (Low Orbit Ion Cannon) and similar hacktivist tools by executing rapid sequential HTTP requests using curl in a loop. Directed at localhost to avoid external impact. This pattern is recognizable by the extremely high request rate from a single source process and is used by tools like LOIC, HOIC, and custom hacktivist scripts. The loop is limited to 200 iterations.

Command

bash 
for i in $(seq 1 200); do curl -s -o /dev/null --max-time 1 http://127.0.0.1/ & done; wait

Cleanup

bash 
pkill curl 2>/dev/null; true

Expected Telemetry

Linux audit log: 200 execve syscalls for curl in rapid succession from the same parent shell PID. Syslog: process creation events for curl children. Network: 200 TCP connection attempts to 127.0.0.1:80 in rapid succession. Process table (ps aux) will show many curl processes during execution.

Expected Detection

KQL: DeviceProcessEvents showing high-frequency FileName=curl process creation from a single parent process within a short window. SPL: Sysmon Event ID 1 (sysmon-for-linux) capturing 200 curl executions. Behavioral threshold detection fires if curl generates >200 network connections in 5 minutes to a single destination.

Test 4 nping ICMP Flood (Linux)
linux

Uses nping (included with Nmap) to generate a high-rate ICMP ping flood against localhost, simulating ICMP flood DoS attacks used by malware like NKAbuse. nping provides precise control over packet rates and counts, making it a common tool for both legitimate network testing and malicious DoS. Directed at loopback to avoid external impact. The --rate flag simulates aggressive flooding.

Command

bash 
nping --icmp --rate 500 --count 1000 127.0.0.1

Expected Telemetry

Linux audit log: execve for nping with --icmp --rate 500 arguments. If sysmon-for-linux is deployed, Sysmon Event ID 1 will capture the full command line. Network monitoring: 1000 ICMP packets at 500 packets/second burst on loopback. /proc/net/snmp ICMP InMsgs counter increments rapidly during test.

Expected Detection

SPL Sysmon Event ID 1: Image matching nping and CommandLine containing --rate and --icmp triggers the known DoS tool detection branch. KQL DeviceProcessEvents: FileName=nping with ProcessCommandLine containing --rate and --icmp matches the DosToolPatterns filter. Both detections fire within seconds of execution.

Related Detections

Tactic Hub

TA0040Impact

Sub-techniques (2)

Related Techniques

T1498.001Direct Network FloodT1498.002Reflection AmplificationT1499Endpoint Denial of ServiceT1496Resource HijackingT1489Service StopT1059.004Unix ShellT1059.001PowerShellT1105Ingress Tool TransferT1543.003Windows ServiceT1053.005Scheduled TaskT1078Valid Accounts

Same Tactic: Impact

Popular Detections