T1499.001: OS Exhaustion Flood
Adversaries may launch a denial of service (DoS) attack targeting an endpoint's operating system (OS). A system's OS is responsible for managing the finite resources as well as preventing the entire system from being overwhelmed by excessive demands on its capacity. These attacks do not need to exhaust the actual resources on a system; the attacks may simply exhaust the limits and available resources that an OS self-imposes.
Different ways to achieve this exist, including TCP state-exhaustion attacks such as SYN floods and ACK floods.[1] With SYN floods, excessive amounts of SYN packets are sent, but the 3-way TCP handshake is never completed. Because each OS has a maximum number of concurrent TCP connections that it will allow, this can quickly exhaust the ability of the system to receive new requests for TCP connections, thus preventing access to any TCP service provided by the server.[2]
ACK floods leverage the stateful nature of the TCP protocol. A flood of ACK packets are sent to the target. This forces the OS to search its state table for a related TCP connection that has already been established. Because the ACK packets are for connections that do not exist, the OS will have to search the entire state table to confirm that no match exists. When it is necessary to do this for a large flood of packets, the computational requirements can cause the server to become sluggish and/or unresponsive, due to the work it must do to eliminate the rogue ACK packets. This greatly reduces the resources available for providing the targeted service.[3]
Analyst context for executives and security teams
OS Exhaustion Flood is an availability risk: an adversary can overwhelm operating-system networking limits on Linux, macOS, or Windows endpoints so legitimate users cannot reach hosted services. For leaders, the practical issue is not only bandwidth capacity; it is whether critical services have upstream filtering, traffic visibility, and incident runbooks that can distinguish OS-level TCP exhaustion from application failure or ordinary load.
Executive priority
Prioritize this where business-critical websites, email, DNS, or web applications depend on reachable endpoints. The key decision is whether resilience funding is going to the controls that actually decide outcome: ingress traffic filtering, network-layer visibility, and tested response paths with service owners and network teams. This technique also matters for compliance and audit evidence because organizations may need to show they can monitor and respond to availability-impacting events, even though ATT&CK provides no specific detection logic for this object.
Technical view
ATT&CK places this sub-technique under Endpoint Denial of Service in the impact tactic and lists Linux, macOS, and Windows platforms. The supplied description focuses on TCP state exhaustion patterns such as SYN and ACK floods, where the endpoint OS spends finite connection/state resources handling traffic rather than serving legitimate requests. SOC and IR teams should validate detection around the related DET0356 detection strategy and confirm that network telemetry can expose abnormal TCP connection attempts, incomplete handshakes, ACK-heavy traffic without matching state, and concurrent service unavailability. Because official detection text is not provided, local baselining and service-specific thresholds are required.
Likely telemetry
- Network flow records such as NetFlow or equivalent traffic summaries
- Packet metadata or packet captures during suspected availability events
- Firewall, router, load balancer, and ingress filtering logs
- Endpoint OS network stack counters and TCP connection/state table indicators
- Service health, latency, error-rate, and availability monitoring for exposed TCP services
Detection direction
- Validate that monitoring distinguishes traffic floods from application-layer faults, resource bugs, or legitimate traffic spikes.
- Baseline normal SYN, ACK, connection-attempt, and incomplete-handshake patterns for critical exposed services.
- Correlate network-layer anomalies with endpoint OS responsiveness and service availability rather than relying on a single alert source.
- Tune for false positives from load tests, failover events, scanning, monitoring systems, and sudden legitimate demand.
- Use the related DET0356 strategy as the ATT&CK-linked detection reference, but require local implementation detail because the object itself has no official detection text.
Mitigation priorities
- Apply M1037 Filter Network Traffic as the primary ATT&CK-supported mitigation: restrict ingress traffic to what exposed services actually require.
- For public-facing services, place filtering and rate-control decisions as far upstream as practical so the endpoint OS is not the first enforcement point.
- Maintain firewall and network appliance rules that allow only expected protocols and sources where business requirements permit.
- Test incident response procedures for availability events, including escalation between SOC, network operations, infrastructure owners, and service owners.
- Review critical service architecture for dependency on single endpoints whose OS limits can become a business continuity bottleneck.
Analyst notes and limits
This take is based on ATT&CK T1499.001, its parent relationship to Endpoint Denial of Service, the M1037 mitigation relationship, the DET0356 detection-strategy relationship, and the supplied external references discussing DoS visibility and TCP flood behavior. The business value is in validating whether network-layer evidence and filtering controls exist before an availability incident forces ad hoc triage.
ATT&CK provides no official detection text and no procedure examples in the supplied object. This assessment does not prove exposure, exploitation, attribution, or existing detection coverage. Applicability depends on the organization’s actual externally reachable services, network architecture, OS configuration, and telemetry retention.
OS Exhaustion Flood
Adversaries may launch a denial of service (DoS) attack targeting an endpoint's operating system (OS). A system's OS is responsible for managing the finite resources as well as preventing the entire system from being overwhelmed by excessive demands on its capacity. These attacks do not need to exhaust the actual resources on a system; the attacks may simply exhaust the limits and available resources that an OS self-imposes.
Different ways to achieve this exist, including TCP state-exhaustion attacks such as SYN floods and ACK floods.[1] With SYN floods, excessive amounts of SYN packets are sent, but the 3-way TCP handshake is never completed. Because each OS has a maximum number of concurrent TCP connections that it will allow, this can quickly exhaust the ability of the system to receive new requests for TCP connections, thus preventing access to any TCP service provided by the server.[2]
ACK floods leverage the stateful nature of the TCP protocol. A flood of ACK packets are sent to the target. This forces the OS to search its state table for a related TCP connection that has already been established. Because the ACK packets are for connections that do not exist, the OS will have to search the entire state table to confirm that no match exists. When it is necessary to do this for a large flood of packets, the computational requirements can cause the server to become sluggish and/or unresponsive, due to the work it must do to eliminate the rogue ACK packets. This greatly reduces the resources available for providing the targeted service.[3]
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 | T1499 | Endpoint Denial of Service | This object subtechnique of Endpoint 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.2 | Current bundle | 26735df4772f… |
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]
Arbor AnnualDoSreport Jan 2018
Philippe Alcoy, Steinthor Bjarnason, Paul Bowen, C.F. Chui, Kirill Kasavchnko, and Gary Sockrider of Netscout Arbor. (2018, January). Insight into the Global Threat Landscape - Netscout Arbor's 13th Annual Worldwide Infrastructure Security Report. Retrieved April 22, 2019.
Open source URL -
[2]
Cloudflare SynFlood
Cloudflare. (n.d.). What is a SYN flood attack?. Retrieved April 22, 2019.
Open source URL -
[3]
Corero SYN-ACKflood
Corero. (n.d.). What is a SYN-ACK Flood Attack?. Retrieved November 17, 2024.
Open source URL -
[4]
Cisco DoSdetectNetflow
Cisco. (n.d.). Detecting and Analyzing Network Threats With NetFlow. Retrieved April 25, 2019.
Open source URL -
[5]
mitre-attack T1499.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.