Detecting T1498 Network denial of service

How T1498 network denial of service shows up in your traffic

T1498 Network denial of service is a technique under the ATT&CK Impact tactic (TA0040), in which an adversary tries to make a network service unavailable by overwhelming it with traffic at the network level. For a SOC lead, it usually first appears as availability alerts, saturated uplinks or slow applications, and a legitimate campaign, software release or batch job can produce the same symptoms. The hard part is not seeing the traffic but deciding whether its volume, source spread and protocol mix point to an attack. Use Enterprise ATT&CK version 20.0 as the reference when you map detections, and confirm the technique and sub-technique names in that version before you write rules.

ATT&CK splits the technique into two sub-techniques. In the first, the attacker sends large volumes of traffic straight at the target, so the signal is raw volume and connection rates, from one source or many. In the second, the attacker abuses third-party services that reply to forged requests, so the victim receives responses it never asked for, amplified and arriving from well-known servers. The two look different in your data: the first shows up as inbound floods at your edge, while the second shows up as unsolicited inbound responses to services you may not even run. Ask your upstream provider which of these their filtering can observe, and get the answer in writing.

In intrusions, T1498 is usually a pressure tactic. It is aimed at a public service on its own, sometimes alongside extortion demands, or used as cover while another intrusion runs. When the alert fires, ask three questions: is the traffic inbound to services you publish, is the source mix unusual for that service, and does the timing match a known business event. Decide in advance who may call your upstream provider for traffic scrubbing and confirm the thresholds and filtering options in your contract before an incident. The ATT&CK mitigation Filter Network Traffic is where this upstream and edge filtering work sits.

Which telemetry reveals network denial of service

This table maps each telemetry source to the T1498 signal it produces, the open-source collector that captures it, and what it cannot see. Read it as a set: flow records show volume, connection records show state, process records show the host side, and content records show protocol-level abuse.

Telemetry source	Signal for T1498	Open-source collector	Blind spots
Network Traffic Flow	Sudden spikes in packets or bytes per second toward one destination, many sources converging on one service, or asymmetric flows with little return traffic	Zeek conn logs, Suricata flow records, Security Onion sensors	Encrypted payloads are invisible, and spoofed or distributed sources can hide the true volume at a single sensor
Network Connection Creation	Surges in new connection attempts, half-open sessions, or repeated resets against a listening port on a host	Wazuh agent network telemetry, Zeek connection state fields, host firewall logs	Connections that are completed quickly look normal, and agents only report on hosts where they are deployed
Process Creation	Unexpected load-generation tools or scripts launched on a host that is then the source of outbound floods, or service processes restarting under pressure	Wazuh agent process events, Velociraptor hunts, Sysmon-style endpoint logs where deployed	Only shows the source host, not the target, and attackers often use legitimate binaries that look benign in isolation
Network Traffic Content	Protocol-level anomalies such as malformed requests, oversized headers, repeated identical payloads, or application-layer request floods	Suricata rules and protocol parsers, Zeek protocol analyzers, Security Onion alerts	Requires visibility into unencrypted traffic or TLS termination points, and rule tuning is needed to avoid false positives
Application Log Content	Request rate spikes, error bursts, timeouts and throttling events in web, API or DNS service logs	Wazuh log collection, Zeek HTTP and DNS logs, service-native logs forwarded to a SIEM	Logs show the effect on the service, not the traffic cause, and overloaded services may drop their own logging
Host and interface counters	Interface saturation, dropped packets, CPU and memory pressure on the target during the event window	Wazuh system inventory and agent metrics, Velociraptor artifacts for host state	Counters are sampled and may not capture short bursts, and upstream congestion can hide host-level symptoms
Upstream and perimeter devices	Rate limit triggers, filter drops and blocklist hits recorded at routers, load balancers or firewalls	Firewall and load balancer logs forwarded to Wazuh or Security Onion	Only covers the segments and devices that are logging, and provider-managed edge filters may not expose logs to the client

Detection logic for T1498 that tolerates normal peaks

T1498 is hard to detect because legitimate traffic can look identical to flooding at the packet level. The cards below describe signals that separate abnormal load from expected peaks, and the context that should be checked before anyone is paged. Each signal only works once it is compared against a baseline set for the specific environment.

Volume and rate baselines per destination

Set a per-destination baseline for inbound connections, packets and bytes, broken down by hour and day of week, so that a normal Monday morning is not compared with a quiet Sunday night. Alert on sustained deviation above that baseline rather than on a single spike. The threshold is a parameter to tune against each environment's own history, not a fixed number. Confirm the look-back window with the owners of each service before setting it.

Connection-state anomalies

Watch the proportion of half-open, reset and incomplete connections against the normal share for each service. A flood often shows a sharp rise in connections that never complete the handshake, while legitimate peaks usually keep completion rates steady. Flow records from Zeek or Suricata can supply these states. Compare the ratio over time rather than the raw count, because raw counts rise with traffic.

Source concentration and distribution

Measure how many distinct source addresses, autonomous systems and countries account for the traffic to a destination. A distributed attack spreads load across many sources, while a campaign from one provider concentrates it. Both can look like a surge, so record the normal source mix for each service. A sudden shift in the top sources is a prompt for review, not proof of an attack.

Correlation with service health

Only treat a traffic anomaly as a probable denial of service when it coincides with degraded service signals, such as rising latency, error rates, queue depth or failed health checks. Forward load balancer and application logs into the same case as the flow data. Traffic that rises without any service impact is usually a capacity or demand event and should be recorded but routed differently.

Known peaks and false positive sources

Maintain a calendar of expected load events, including backup windows, batch jobs, marketing launches and planned migrations. Add CDN failover as a known cause, because a provider switch can move traffic onto a different path and change the source mix without any attack. Suppress alerts only for named, time-bound events with an owner, and review each suppression after the event so it does not become a permanent blind spot.

How to validate that T1498 detections fire

This sequence proves that each T1498 detection raises the right alert under controlled conditions, measures how quickly and how accurately it does so, and records the results against the ATT&CK version under test. It turns a rule that looks correct on paper into evidence a CISO or auditor can review.

Define the emulation scenario and scope
The detection engineer and the range owner agree in writing on which T1498 behaviors are emulated, including the network-level flood pattern and the reflection-style pattern that map to the two sub-techniques. They also set the target systems, the attacker-side host in the range, and the stop conditions. The step closes when the scenario card names every behavior, its target, and its expected alert, and the range owner has signed off that the traffic stays inside the isolated segment.
Set the baseline traffic profile
Before any emulated traffic starts, the team runs normal application and service traffic against the same targets at a steady level for a fixed observation window agreed in the scenario card. This baseline is what the rules must tolerate, so it should reflect real service mix, client counts and peak patterns from production. The step closes when the baseline is recorded in Security Onion or Zeek logs and the team can show what normal flow counts, connection rates and protocol mix look like for each target.
Map expected telemetry to each data component
For each detection, the analyst lists the telemetry expected from Network Traffic Flow, Network Connection Creation and Process Creation where a host process is involved, and the field names that should appear in Zeek, Suricata or Wazuh events. Each expectation is written before the run so that a missing event is treated as a finding, not a surprise. The step closes when every detection has a table of expected data components, sources and fields, reviewed by a second engineer.
Run the emulation with baseline traffic in parallel
The emulation runs while the baseline continues, so the rules are tested against mixed traffic rather than a quiet network. The operator logs each action with a start and end timestamp in a run log that stays outside the SIEM, so timing can be compared later. The step closes when the run log, the baseline log and the emulation timeline all cover the same window and the operator confirms the scenario ran as written.
Check alerts, telemetry and time to alert
The analyst compares the run log against the events and alerts that appear in the SIEM and records the time from the first emulated packet to the first alert. The team also checks whether the expected telemetry arrived at all, because a rule can fail silently when a sensor drops traffic or a log source stops forwarding. The step closes when each detection has a timing value, a yes or no for telemetry completeness, and a list of any expected events that did not appear.
Measure alert fidelity and false positives under normal load
The analyst reviews every alert raised during the run and classifies it as a true detection, a duplicate, or a false positive, then counts false positives raised during the baseline-only window. Fidelity is judged on whether the alert names the affected host and behavior clearly enough for triage. The step closes when each rule has a fidelity assessment and a false positive count for the baseline window, and the team has agreed which thresholds need tuning before the next run.
Tag results to the ATT&CK version tested
Each result record carries the ATT&CK version the rule was mapped to, for example the Enterprise ATT&CK version named in the detection repository at the time of testing, along with the technique and sub-technique IDs, the detection strategy identifier, and the rule version. Because releases can rename, deprecate or revoke techniques, the record also notes the date of the test. The step closes when every result is stored with these tags and a reviewer can reproduce the mapping from the record alone.
Feed gaps back into the detection backlog
Each gap, whether a late alert, a missing data component, a noisy rule or a mapping that no longer matches the current ATT&CK version, becomes a tracked item with an owner and a retest condition. The next run uses the same scenario card so results can be compared. The step closes when the backlog lists every open gap with its owner, and the retest is scheduled against the same scenario so the before and after results can be set side by side.

Mitigations that limit the impact of network denial of service

ATT&CK maps T1498 Network denial of service to Filter Network Traffic (M1037) and Network Segmentation (M1030), but those mappings only help if traffic filtering and segmentation are in place before a flood arrives. The cards below cover the controls that sit in front of your hosts, the provider and ISP commitments you need to confirm, and the internal checks that keep a flood from spreading.

Filter network traffic at the edge

ATT&CK maps M1037, Filter Network Traffic, to this technique, so the first control to verify is what your edge actually drops. Confirm which protocols, source ranges and malformed packet types are blocked at the perimeter firewall, load balancer or web application firewall, and whether those rules are version controlled and tested after each change. A rule that exists only in a console export is hard to audit. Ask who owns rule changes during an active flood and how quickly they can be made.

Segment services to contain impact

Network Segmentation (M1030) limits how far a flood against one service can reach. Check whether public-facing workloads, internal APIs, databases and management interfaces sit in separate zones with explicit rules between them. Confirm that a saturated application tier cannot starve the management network, and that shared resources such as DNS, NAT gateways and authentication services are either redundant or isolated. Document which segments depend on which, because a flat design turns one target into an outage for everything.

Confirm upstream scrubbing with the ISP

Traffic volume that reaches your circuit can exceed what your own devices can filter, so upstream capacity and any ISP-level scrubbing matter. Ask your ISP or transit provider what volumetric filtering they perform, how traffic is diverted during an event, who authorizes the diversion, and what the expected behavior is for legitimate traffic during mitigation. Get these answers in writing and test the escalation path with a contact who can act outside business hours. Do not assume a generic upstream service covers your specific protocols.

Confirm cloud provider protections

If the workload runs on IaaS, the provider's network protections and your own configuration share the work. Confirm which denial-of-service protections the provider applies by default, which ones require paid tiers or explicit enablement, and what they do not cover, such as application-layer request floods. Check how autoscaling, load balancer limits and rate-limit settings are configured, and whether alerts fire on sustained traffic growth. Ask the provider for its documented escalation process and the evidence it can export after an event.

Keep detection visible during a flood

Filtering only helps if you can still see what is happening. Verify that flow telemetry and network traffic flow records continue to reach your sensors when link utilization is high, and that sensor or collector drops are monitored. Confirm that Zeek, Suricata or flow exporters on each edge segment are sized for peak volume, or that sampling is documented. Without this visibility, you cannot tell a volumetric flood from legitimate demand spikes or confirm that filters are working.

Rehearse the failover decision

Mitigation decisions, such as diverting traffic to a scrubbing path or switching to a degraded service mode, need named owners and tested runbooks. Verify that the runbook states who can approve a traffic diversion, what legitimate traffic may be blocked, and how service is restored afterward. Rehearse this in a private cyber range so that network, security and provider contacts practice the handoffs before a real event. Record the time each step takes in your own environment, because no general timing figure should be assumed.

What to do in the first hour after a T1498 alert

The first decision after a T1498 alert is whether the traffic is hurting a service at all. Before anyone changes a firewall rule or calls a provider, confirm the alert against service health: check request latency, error rates, connection queue depth and health-check failures for the affected application, and compare them with the same window on the load balancer and the upstream edge. A volumetric spike with no change in user-facing error rates is a very different event from a spike that is saturating connection tables. Record the exact time window and the destination addresses and ports named in the alert so every later step works from the same facts. Next, separate a legitimate surge from attack traffic. Check whether a marketing campaign, a product launch, a batch job, a partner integration or a retry storm from a broken client could explain the volume. Look at the source distribution: a few hundred sources hitting one login or search endpoint at a steady rate looks different from many sources spread across all endpoints, and both look different from traffic that is mostly malformed or has an unusual protocol mix. Map every affected destination and its upstream dependencies, such as DNS, identity providers, payment gateways and shared databases, because a flood aimed at one public address often degrades a dependency that the service cannot see. Within the first hour, bring in the people who control the paths. Notify the network team that owns the perimeter, the hosting or cloud provider that carries the traffic, and any upstream DDoS mitigation service you have contracted. Confirm in advance which of them can act on your behalf, through what channel and with what evidence they need, and do not assume a response time that the contract does not state. Decide on traffic filtering with a named owner: rate limits, geographic or source blocks, challenge pages or scrubbing diversion each carry a different risk of blocking real customers. Preserve evidence before you change anything. Export flow records, load balancer and web server logs, firewall counters and packet captures for the window, hash them, and record who collected them and when, so that the post-incident review can rely on them. Finish the hour with a short written timeline and a post-incident review scheduled, using the controls named in the ATT&CK mitigation Filter Network Traffic (M1037) as the baseline for what worked and what needs changing.

Rehearsing T1498 detection and response in a private cyber range

The range should mirror the production path that carries the service under test, but on isolated address space that cannot reach live systems. Place the victim services behind a segmented boundary so that the traffic generator, the edge controls and the protected service each sit in their own zone. Monitoring sensors should observe traffic at the points an analyst would actually query, not only at the victim host, because volumetric events are usually first visible at the edge. Illustrative example: a web tier, an application tier and a DNS resolver, each in its own segment, with sensors on the upstream link and on each segment boundary.

Segmented victims: Keep the web service, a DNS resolver and an API tier in separate segments so that impact can be scored per service.
Edge sensors: Place a network-layer sensor, such as Zeek or Suricata, on the upstream link and on each segment boundary to capture flow records.
Host telemetry: Forward host logs and process events from the victims to the SIEM so that resource exhaustion can be correlated with traffic.
Traffic source control: Run the load generator in a dedicated segment with a documented allow list, and record every change to its configuration.
Time synchronization: Confirm all sensors and hosts share one time source so that flow, log and alert timestamps line up.

Confirm with your own platform team which Wazuh, Security Onion and Suricata versions your range will run, and check the vendor documentation for supported sensor placements.

Questions SOC leads and detection engineers ask about T1498

How do you tell T1498 network denial of service apart from T1499 endpoint denial of service?

The split is about where the impact lands. T1498 describes floods of traffic that exhaust network bandwidth or upstream capacity before it reaches the target host, while T1499 describes exhaustion of an endpoint or service itself, such as its processes, connections or application resources. In practice both can appear in the same incident, so start from the network telemetry, Network Traffic Flow and Network Connection Creation, to see whether volume saturates the path, then check host-side Process Creation and Application Log Content to see whether the service is the thing failing. Record which signal you matched so the case maps cleanly to the ATT&CK version you target.

Why is it hard to attribute a T1498 sub-technique to a specific incident?

Sub-technique attribution depends on the protocol and the vantage point, and flow records often lose the detail needed to distinguish one flood pattern from another. Flow data summarizes packets, so a volumetric event and a protocol-level event can look similar at the border. Attribution improves when you combine flow records with packet or content capture for a short window, upstream provider reports and edge device logs. Where those sources are missing, document the uncertainty instead of assigning a sub-technique you cannot support.

How do you tune flow thresholds for T1498 without blinding the SOC?

Set thresholds from a measured baseline of your own traffic, not from a vendor default. Build baselines per site, per service and per time window, because a month-end batch job or a product launch will look like a flood to a static rule. Tune in stages: alert first in a test queue, review false positives with the owners of the busy services, then promote rules to paging only after the noise is understood. Keep a change log for every threshold so that a later review can see why a rule was relaxed. Test each change in the cyber range before production.

Which data gaps matter most when detecting network denial of service?

The most damaging gaps are missing flow data at the internet edge, missing visibility into cloud or hosting provider networks, and clock drift between sources that breaks correlation. Confirm that flow exporters cover every ingress path, including VPN, load balancers and direct connections, and that retention is long enough to baseline seasonal traffic. Check whether you can see drops at upstream filters, because a mitigation that drops traffic before it reaches you will look like a quiet network. Each gap should be written down with an owner and a date for closure.

How should you retest T1498 detections after an ATT&CK version change?

Map each detection to the ATT&CK version it targets, and re-check that mapping whenever MITRE publishes a release. ATT&CK v18 replaced detections in technique pages with detection strategies and analytics and updated data components, and later releases can rename, deprecate or revoke techniques. After each release, compare your rule metadata against the updated technique and sub-technique pages, re-run the replay tests in your cyber range, and record which rules changed. Where you use the STIX bundles, diff the technique objects for T1498 and its sub-techniques rather than relying on memory.

What should you confirm with upstream providers about T1498 coverage?

Confirm what they detect, what they filter and what they will tell you during an event. Ask whether they offer volumetric flood mitigation, how traffic is diverted, how long it takes to enable it, and whether they can provide flow or drop logs for the affected window. Get written answers on log retention, the format of exported data and the contact path for an active incident. Also confirm which of your traffic they can see and which they cannot, since that determines what your own sensors must cover. Treat these answers as assumptions to verify in a test, not as guarantees.

Can a team run T1498 detection exercises without outside help?

A team with network engineers, a SOC analyst and access to flow telemetry can run basic exercises in-house, but the work is more than writing a rule. The effort lies in building a safe private test environment, generating controlled traffic that is representative of your services, documenting results and feeding findings back into tuning. Teams often engage an implementation partner for the cyber range build and for structured exercises, while keeping ownership of the rules and runbooks. DeployOpen plans and runs these exercises under a written scope, and a quote follows from that scope.

What does a T1498 cyber range exercise need to prove?

An exercise should prove that a defined, controlled traffic pattern produces the expected alert, reaches the right queue, and triggers the runbook steps within the time your team has set. Define the success criteria before the run, including which telemetry should fire, which dashboard should show the spike and which mitigation step should be taken. Include a rollback step and a stop condition so the test does not disrupt production. Capture the timeline, the false positives and the gaps, then decide which findings change the rules, the data sources or the runbook.

How DeployOpen builds T1498 detections and range scenarios

DeployOpen plans, implements and documents T1498 Network denial of service detections inside the client's own infrastructure, using open-source tooling. The work starts with a written scope, moves through a private cyber range rehearsal, and ends with handover material and optional ongoing support.

How we scope

Agree in writing which network segments, cloud accounts and sensors fall under T1498 detection coverage.
Confirm which sub-techniques, network flow sources and log feeds the client can actually provide.
Record the ATT&CK version the detection mappings target, so later releases can be reviewed against it.

How we build

Map Network Traffic Flow and Network Connection Creation telemetry to detection logic described in plain language for each platform in scope.
Configure Wazuh, Zeek, Suricata or Security Onion collection only where the client's environment supports it.
Document the Filter Network Traffic mitigation settings and test each rule against baseline traffic before sign-off.

How we hand over

Deliver a fixed-scope report covering detection logic, data sources, known gaps and validation results.
Provide a cyber range scenario that replays benign and hostile traffic patterns so the client's team can rehearse response.
Walk the client's security engineers through the runbook, escalation path and rule tuning steps before close.

How we support

Offer ongoing support as a retainer for rule tuning, upgrades and periodic re-testing against new ATT&CK releases.
Review detections when the client changes network architecture, cloud providers or traffic profiles.
Confirm retainer scope, response expectations and review cadence in writing before support begins.

T1498 Network denial of service