Applied Cybernetics Group
T1498.001 — Direct Network Flood
coverage gap
- Technique
T1498.001- Tactics
- Impact
- MISP citations
- 0
- KEV CVEs mapped
- 1
- Community rules
- 0
- thrunt rules
- 0
- Upstream
- https://attack.mitre.org/techniques/T1498/001
MITRE description
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 Flood](https://attack.mitre.org/techniques/T1498/001)s 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.(Citation: USNYAG IranianBotnet March 2016)
KEV CVEs mapped to this technique
Per MITRE CTID's hand-curated KEV→ATT&CK mappings — these are the actively-exploited vulnerabilities behind this technique's KEV signal.
Detection coverage
volumetric flood is invisible at single-event granularity; edge/upstream mitigation and netflow analytics are the control class
T1498.001 is the purest volumetric technique in ATT&CK: SYN, UDP, and ICMP floods whose only signature is aggregate packets-per-second toward the target. Standard telemetry — firewall logs, netflow, Zeek conn — records individual flows, and no single flow record carries flood semantics; flagging any one of them is a guaranteed false positive, and base Sigma has no aggregation with which to count them. The community rule set reflects the same conclusion: parent T1498's only entries are a honeypot amplification-recon rule (OpenCanary NTP Monlist) and a malware-family rule (BlackByte), neither of which detects a flood in progress. The KEV mapping here (CVE-2024-45195, Apache OFBiz) reflects compromised servers being drafted as flood sources — that is caught by the exploit rules for the CVE, not by a T1498 rule on the victim side. Flood defense belongs to upstream provider scrubbing, BGP Flowspec/RTBH, and edge rate-limiting; flood detection belongs to netflow analytics with time-windowed thresholds. Neither is expressible as base Sigma, and we will not pretend otherwise.
Compensating controls
- Upstream provider DDoS scrubbing contracts
- BGP Flowspec / remotely-triggered blackhole (RTBH) runbooks
- Edge rate-limiting and SYN-cookie enforcement
- Netflow/NDR volumetric analytics with baselined thresholds
- OpenCanary NTP monlist rule where honeypots are deployed (amplification-abuse early warning)
Revisit when: thrunt adopting Sigma correlation rules with count/time-window aggregation over netflow-class logsources; nothing short of that flips this.