Network Denial of Service
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/
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.
Data Sources
Required Tables
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:
Platform-specific guides for T1498
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.
- 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.
- 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.
- 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.
- 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.
Unlock Pro Content
Get the full detection package for T1498 including response playbook, investigation guide, and atomic red team tests.