T1498.001: Direct Network Flood
Adversaries may attempt to cause a denial of service (DoS) by directly sending a high-volume of network traffic to a target. This DoS attack may also reduce the availability and functionality of the targeted system(s) and network. Direct Network Floods are when one or more systems are used to send a high-volume of network packets towards the targeted service's network. Almost any network protocol may be used for flooding. Stateless protocols such as UDP or ICMP are commonly used but stateful protocols such as TCP can be used as well.
Botnets are commonly used to conduct network flooding attacks against networks and services. Large botnets can generate a significant amount of traffic from systems spread across the global Internet. Adversaries may have the resources to build out and control their own botnet infrastructure or may rent time on an existing botnet to conduct an attack. In some of the worst cases for distributed DoS (DDoS), so many systems are used to generate the flood that each one only needs to send out a small amount of traffic to produce enough volume to saturate the target network. In such circumstances, distinguishing DDoS traffic from legitimate clients becomes exceedingly difficult. Botnets have been used in some of the most high-profile DDoS flooding attacks, such as the 2012 series of incidents that targeted major US banks.[1]
Analyst context for executives and security teams
Direct Network Flood is a denial-of-service behavior where adversaries send high volumes of traffic directly at a target service or network, potentially reducing availability for websites, email, DNS, web applications, or other exposed services. For business leaders, the key issue is not malware cleanup but service resilience: whether critical internet-facing systems can keep operating, whether teams can separate legitimate client demand from flood traffic, and whether escalation paths to network, cloud, and response teams are already rehearsed.
Executive priority
Prioritize this as an operational resilience and incident decision-making risk for public-facing services on Windows, Linux, macOS, and IaaS environments. Leadership should ask which business services would be most affected by bandwidth exhaustion, what evidence would prove a network flood is occurring, who can authorize traffic filtering during an outage, and whether compliance or customer commitments require documented availability controls and response procedures. Budget and control decisions should focus on visibility, filtering capability, and tested response coordination rather than assuming endpoint controls alone will address the issue.
Technical view
ATT&CK maps this sub-technique to the Impact tactic under Network Denial of Service. The supplied object has no official ATT&CK detection text, but a related detection strategy, DET0343, is identified for Direct Network Flood detection across IaaS, Linux, Windows, and macOS, and an external reference points to NetFlow-based network threat analysis. SOC and IR teams should validate that they can observe traffic volume, protocol mix, source distribution, destination service saturation, and changes in availability for exposed services. Because ATT&CK notes that almost any protocol may be used, including UDP, ICMP, and TCP, detection should not be limited to a single protocol or endpoint signal.
Likely telemetry
- Network flow records such as NetFlow or equivalent summaries
- Firewall, router, load balancer, and network appliance logs
- Cloud or IaaS network traffic metrics for exposed services
- IDS/IPS or network security monitoring alerts related to traffic spikes or protocol floods
- Service availability, latency, error-rate, and saturation metrics for public-facing applications
Detection direction
- Validate DET0343-relevant coverage in the local environment rather than assuming ATT&CK provides a complete detection recipe; the official detection field is not provided.
- Baseline normal inbound traffic volumes by service, protocol, geography/source distribution where available, and time of day so flood conditions can be distinguished from legitimate demand surges.
- Tune detections for high-volume UDP, ICMP, and TCP patterns, but account for the ATT&CK note that almost any network protocol may be used.
- Correlate network volume anomalies with service availability degradation to reduce false positives from expected business events, releases, backups, or marketing-driven traffic spikes.
- Assess blind spots where traffic is handled before enterprise logging points, such as upstream providers, cloud edge services, or network appliances that do not export usable flow data.
Mitigation priorities
- Implement and periodically review network traffic filtering controls consistent with M1037, including ingress filtering and firewall rules for public-facing services.
- Define which services should accept traffic only from authorized sources where business requirements allow, especially administrative or restricted interfaces.
- Prepare response playbooks for rapid filtering decisions across network, cloud/IaaS, SOC, and incident response teams.
- Maintain visibility into inbound traffic before and at critical service boundaries so responders can identify saturation points.
- Test availability monitoring and escalation paths for websites, email, DNS, and web-based applications that align with the parent Network Denial of Service technique context.
Analyst notes and limits
The materiality of this behavior depends heavily on which services are internet-facing, how traffic reaches them, and whether the organization can coordinate filtering at the right layer quickly. Botnets are described by ATT&CK as common infrastructure for these floods, and in large distributed floods each source may generate only a small amount of traffic, making simple per-source blocking less reliable. Defensive validation should therefore emphasize aggregate network behavior, service impact, and response authorization paths.
The official ATT&CK detection field for this object is not provided. This take is limited to the supplied ATT&CK description, platforms, tactic, external references, and relationships, including DET0343 and M1037. It does not assert active exploitation, attribution, customer exposure, or guaranteed detection coverage. Local architecture, provider telemetry, and service criticality are required to determine actual risk and control sufficiency.
Direct Network Flood
Adversaries may attempt to cause a denial of service (DoS) by directly sending a high-volume of network traffic to a target. This DoS attack may also reduce the availability and functionality of the targeted system(s) and network. Direct Network Floods are when one or more systems are used to send a high-volume of network packets towards the targeted service's network. Almost any network protocol may be used for flooding. Stateless protocols such as UDP or ICMP are commonly used but stateful protocols such as TCP can be used as well.
Botnets are commonly used to conduct network flooding attacks against networks and services. Large botnets can generate a significant amount of traffic from systems spread across the global Internet. Adversaries may have the resources to build out and control their own botnet infrastructure or may rent time on an existing botnet to conduct an attack. In some of the worst cases for distributed DoS (DDoS), so many systems are used to generate the flood that each one only needs to send out a small amount of traffic to produce enough volume to saturate the target network. In such circumstances, distinguishing DDoS traffic from legitimate clients becomes exceedingly difficult. Botnets have been used in some of the most high-profile DDoS flooding attacks, such as the 2012 series of incidents that targeted major US banks.[1]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1498 | Network Denial of Service | This object subtechnique of Network Denial of Service. |
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.4 | Current bundle | e970972a6488… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
USNYAG IranianBotnet March 2016
Preet Bharara, US Attorney. (2016, March 24). Retrieved April 23, 2019.
Open source URL -
[2]
Cisco DoSdetectNetflow
Cisco. (n.d.). Detecting and Analyzing Network Threats With NetFlow. Retrieved April 25, 2019.
Open source URL -
[3]
mitre-attack T1498.001Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.