A network flood is won or lost upstream of your firewall, and most of the defender's work happens before the attack: capacity, provider contracts and a rehearsed switch to scrubbing. MITRE ATT&CK T1498 Network Denial of Service is an Impact (TA0040) technique in which an adversary exhausts the network bandwidth that services rely on, so that websites, email, DNS or web applications become unreachable. ATT&CK v20 lists it for Windows, IaaS, Linux, macOS and Containers, with two sub-techniques: T1498.001 Direct Network Flood and T1498.002 Reflection Amplification. This guide is the ATT&CK technique view: the recorded procedures, the v20 detection strategies (which look as much at your own hosts sending floods as at floods arriving), M1037 Filter Network Traffic, and how to test readiness. It is for SOC, network and cloud teams. For upstream architecture and provider choice, see the DDoS Protection Guide; for the live incident, see the DDoS Response Playbook.
Key takeaways
- Volume beats on-premises filtering. ATT&CK's own example is 10 Gbps of traffic sent to a server on a 1 Gbps link; once the pipe is full, filtering behind it cannot help. M1037 says the traffic must be intercepted upstream by the ISP or a third party.
- Two sub-techniques, different controls. Direct floods come from botnets; reflection amplification abuses third-party servers that answer spoofed requests, such as DNS, NTP and memcached.
- Your estate can be the weapon. MITRE's v20 analytics mostly detect hosts and cloud instances generating floods or spoofed reflector traffic. Compromised servers, containers and exposed AI tools are recruited into botnets.
- Exposed reflectors are your problem too. Open resolvers, NTP monitoring and UDP memcached on your network amplify attacks against others; close them.
- Floods often cover something else. ATT&CK notes DoS is used for distraction, hacktivism and extortion; keep watching the rest of the estate during an attack.
The two sub-techniques
| Sub-technique | How it works (ATT&CK v20) | Where to defend |
|---|---|---|
| T1498.001 Direct Network Flood | One or more systems send high volumes of packets straight at the target network. Almost any protocol can be used; stateless UDP and ICMP are common, TCP also. Botnets let each source send little while the total saturates the target | Upstream scrubbing, provider blackholing or Flowspec, anycast and CDN for public services |
| T1498.002 Reflection Amplification | Packets with the victim's spoofed source address are sent to reflectors, which reply to the victim. Protocols with larger responses than requests amplify volume; ATT&CK names DNS and NTP, and notes memcached amplification of up to 51,200 times the request | Upstream filtering of the reflected protocols, closing reflectors in your own estate, anti-spoofing at network edges |
T1498 is about the network path. When the target is the host or application itself, through SYN floods, HTTP floods or crash-inducing exploits, ATT&CK uses T1499 Endpoint Denial of Service. CISA's DDoS guidance uses the related categories of volumetric, protocol and application attacks.
How adversaries use it
- APT28 (G0007): ATT&CK records that in 2016 APT28 conducted a distributed denial of service attack against the World Anti-Doping Agency, citing the US Department of Justice indictment. A state actor using DDoS alongside intrusion and leaks shows why floods should trigger heightened monitoring elsewhere.
- NKAbuse (S1107): ATT&CK records multiple network denial of service capabilities across several protocols after installation.
- Lucifer (S0532): ATT&CK records TCP, UDP and HTTP denial of service capability in malware that also mines cryptocurrency, a reminder that a host can be both a miner and a flood source.
- Botnet recruitment of servers: in the Langflow CVE-2025-3248 exploitation, attackers exploited exposed, unpatched AI workflow servers, dumped environment variables holding credentials, and installed the Flodrix DDoS botnet. The defender's first T1498 exposure is often not being flooded but having infrastructure that floods others.
Botnet acquisition is tracked separately under Resource Development (T1583.005 and T1584.005 Botnet). See T1584 Compromise Infrastructure, the Botnets Guide and, for hacktivist DDoS campaigns, the NoName057 DDoS Hacktivist Group Profile Guide.
What to detect and where
ATT&CK v20 maps DET0518 to the parent technique, DET0343 to Direct Network Flood and DET0408 to Reflection Amplification. Read together, they are mostly source-side analytics: they find a host in your estate producing attack traffic.
| Platform | Analytics | Data sources named by MITRE | What to alert on |
|---|---|---|---|
| Windows | AN1434, AN0969, AN1140 | Sysmon 1 and Security 4688 process creation; Sysmon 3 network connection and 22 DNS query; performance counters | A process or script generating large outbound traffic to one destination or to amplification ports; outbound throughput spikes without matching inbound traffic |
| Linux | AN1435, AN0970, AN1141 | auditd execve, connect and sendto; network flow records; sar network statistics | Packet generation tools run outside approved testing; burst sendto patterns; outbound UDP floods to reflector ports; high-volume flows with incomplete TCP sessions |
| macOS | AN0971, AN1142 | Unified log process and network events | Sudden bursts of outbound packets from one process with no user context |
| IaaS | AN0972, AN1143 | VPC Flow Logs; CloudWatch NetworkOut; CloudTrail egress rule creation | Instance egress far above baseline to a single destination; large outbound UDP to many public IPs on ports 53, 123 or 11211; new egress rules allowing those ports |
Target-side signals
MITRE's analytics say little about receiving a flood, because the evidence lives with providers and network devices. For the target side, collect: interface utilisation and drops on edge routers, NetFlow or IPFIX at the edge, provider or CDN attack alerts, cloud DDoS service metrics, DNS query rates, and external synthetic availability checks. Alert when utilisation on an internet link stays above an agreed level, or when a single protocol (for example UDP from source port 123 or 11211) dominates inbound traffic.
Detections to build first
- Egress anomaly per workload: outbound bytes or packets per instance or container far above its baseline, especially to one destination.
- Reflector-port egress: any workload sending high-rate UDP to external ports 53, 123, 1900 or 11211 that is not a resolver or time server by design.
- Packet tool execution: packet crafting or stress tools run on servers outside an approved test window.
- Exposed reflector inventory: external scan results showing your own open resolvers, NTP or memcached on UDP, tracked as findings.
- Link saturation with protocol skew: edge utilisation alerts that include the top protocol and source port, so the on-call engineer can request the right upstream filter.
Mitigations
ATT&CK v20 lists one mitigation for T1498 and both sub-techniques: M1037 Filter Network Traffic. When flood volume exceeds the capacity of the targeted connection, the traffic must be intercepted upstream, by the hosting ISP or a third party such as a CDN or DoS mitigation provider, to separate attack traffic from legitimate traffic. See M1037 Filter Network Traffic.
| Control | Source | What it means in practice |
|---|---|---|
| Upstream filtering and scrubbing | ATT&CK M1037 | Contracted ISP or provider mitigation, with documented activation steps and contacts |
| Remote triggered blackhole and Flowspec | NHI Mgmt Group recommendation | Agree with transit providers how to drop or rate-limit traffic to a prefix or protocol. See the RTBH and BGP Flowspec DDoS Mitigation Guide |
| Anycast, CDN and cloud DDoS services | NHI Mgmt Group recommendation | Front public web and DNS with distributed capacity; hide origin addresses and allow origin traffic only from the CDN. See the CDN Security Guide |
| Anti-spoofing at your edge | IETF BCP 38 (RFC 2827) | Drop outbound packets whose source address is not in your own prefixes, so your network cannot launch spoofed reflection attacks |
| Close reflectors you own | NHI Mgmt Group recommendation | Restrict recursive DNS to internal clients, disable NTP monitoring queries, keep memcached off UDP and off the internet. See the Memcached Security and NTP Security Guide |
| Egress controls for workloads | NHI Mgmt Group recommendation | Default-deny egress for servers and containers that do not need arbitrary internet access. See Cloud Egress Filtering |
The NCSC's denial of service guidance organises preparation into five steps: understand your service, upstream defences, scaling, response plan, and testing and monitoring. That sequence is a sound order of work for the controls above.
Where identity fits
Two identity questions matter for T1498. First, the accounts that can change DDoS protection: CDN and DNS provider API tokens, cloud roles able to alter protection or firewall policy, and router credentials used for Flowspec. An attacker who disables protection with a stolen token makes the flood far cheaper. Scope and monitor these tokens; see the Cloudflare API tokens security guide as a worked example. Second, the credentials on hosts that become bots: the Flodrix case shows exploited servers giving up environment-variable secrets at the same time as joining a botnet, so a source-side T1498 detection should trigger credential rotation for that host.
How to implement
- Map critical services to links: for each service, the internet links, DNS providers and upstream providers it depends on, and their capacity.
- Agree upstream mitigation: contracts, activation steps, contacts and expected time to mitigate, for each provider.
- Turn on telemetry: edge flow records, VPC Flow Logs, CDN and cloud DDoS metrics, and egress baselines per workload.
- Remove what you contribute: anti-spoofing filters, closed reflectors, workload egress rules. Roll out in rings and roll back by restoring the previous ACL.
- Write and rehearse the switch: the steps to move traffic to scrubbing or to request RTBH, with named owners. See the DDoS Readiness Checklist.
- Test: use a provider-approved DDoS test service against an agreed target, with the provider and ISP informed in advance; never run unannounced floods against shared infrastructure.
Choosing controls by size
| Organisation | Priority |
|---|---|
| Small | Host public sites and DNS on providers with built-in DDoS protection; know who to call; make sure no device on your network is an open reflector |
| Mid-size | Add CDN in front of origins with origin locked to the CDN, workload egress baselines, a written activation runbook, annual test |
| Large or own address space | Add BCP 38 filtering, RTBH and Flowspec agreements, always-on or on-demand scrubbing, cross-provider DNS, source-side analytics for every cloud account |
Detection and measurement
- Time to mitigate: from attack start to upstream filtering in place, measured in tests and real events.
- Protected coverage: percentage of internet-facing services behind upstream protection.
- Owned reflectors: number of open resolvers, NTP or UDP memcached services found by external scanning. Target zero.
- Source-side alerts closed: egress anomaly alerts investigated within the agreed time, with credential rotation where a host was compromised.
- Runbook freshness: date of last successful activation test per provider.
Common failure patterns
- Origin exposed behind the CDN: attackers flood the origin address directly, bypassing the protection.
- Protection contracted but never activated in a test: the first activation happens during the attack, with the wrong contacts.
- Single DNS provider: a flood against DNS takes down every service that depends on it. See the DNS Security Guide.
- Ignoring outbound floods: a cloud instance sending gigabits to one address is treated as a billing issue rather than a compromise.
- All eyes on the flood: the SOC stops monitoring the rest of the estate while the attack runs.
Framework mapping
| Framework | References |
|---|---|
| ATT&CK | T1498, T1498.001, T1498.002 (Impact, TA0040); related T1499, T1583.005, T1584.005 |
| ATT&CK detection strategies | DET0518, DET0343, DET0408 |
| ATT&CK mitigations | M1037 Filter Network Traffic |
| NIST SP 800-53 Rev. 5 | SC-5 Denial-of-service Protection; SC-7 Boundary Protection; SI-4 System Monitoring |
| NIST CSF 2.0 | PR.IR-04 adequate resource capacity; PR.IR-03 resilience mechanisms; DE.CM-01 network monitoring |
| MITRE D3FEND | D3-NTF Network Traffic Filtering; D3-ISVA Inbound Session Volume Analysis |
| Mobile and AI mirrors | Mobile T1464 Network Denial of Service; AML.T0029 Denial of AI Service |
Practitioner checklist
- Every internet-facing service has a named upstream protection path and a tested activation runbook.
- Origins behind a CDN accept traffic only from the CDN.
- DNS for critical domains does not depend on a single provider without DDoS protection.
- Edge filters drop outbound packets with source addresses outside your prefixes.
- No open resolvers, NTP monitoring responders or UDP memcached are reachable from the internet.
- Workload egress is baselined and alerts on floods to single destinations or reflector ports.
- A source-side alert triggers host investigation and credential rotation.
- Tokens and roles that can change DDoS protection are scoped, monitored and held by few identities.
Standards and references
- MITRE ATT&CK: T1498 Network Denial of Service
- MITRE ATT&CK: T1498.001 Direct Network Flood
- MITRE ATT&CK: T1498.002 Reflection Amplification
- MITRE ATT&CK: M1037 Filter Network Traffic
- IETF: RFC 2827 (BCP 38) Network Ingress Filtering
- NCSC: Denial of Service (DoS) guidance
- CISA: Understanding and Responding to Distributed Denial-of-Service Attacks
Related NHI Mgmt Group resources: DDoS Protection Guide, DDoS Response Playbook, 5G Security Guide, ATT&CK Impact Tactic Guide.