T1499.002: Service Exhaustion Flood
Adversaries may target the different network services provided by systems to conduct a denial of service (DoS). Adversaries often target the availability of DNS and web services, however others have been targeted as well.[1] Web server software can be attacked through a variety of means, some of which apply generally while others are specific to the software being used to provide the service.
One example of this type of attack is known as a simple HTTP flood, where an adversary sends a large number of HTTP requests to a web server to overwhelm it and/or an application that runs on top of it. This flood relies on raw volume to accomplish the objective, exhausting any of the various resources required by the victim software to provide the service.[2]
Another variation, known as a SSL renegotiation attack, takes advantage of a protocol feature in SSL/TLS. The SSL/TLS protocol suite includes mechanisms for the client and server to agree on an encryption algorithm to use for subsequent secure connections. If SSL renegotiation is enabled, a request can be made for renegotiation of the crypto algorithm. In a renegotiation attack, the adversary establishes a SSL/TLS connection and then proceeds to make a series of renegotiation requests. Because the cryptographic renegotiation has a meaningful cost in computation cycles, this can cause an impact to the availability of the service when done in volume.[3]
Analyst context for executives and security teams
Service Exhaustion Flood matters because it targets availability of business-facing services such as web, DNS, and other network services by overwhelming the software or protocol resources they depend on. For leaders, the key issue is not malware execution but whether critical services can stay online, degrade gracefully, and produce enough evidence for fast incident decisions during a denial-of-service event.
Executive priority
Prioritize this as an operational resilience and incident readiness concern for public or important internal services on Windows, Linux, macOS, and IaaS. Executives should ask which services are business-critical, what traffic filtering and capacity controls exist before the endpoint, who can make rapid block/allow decisions, and whether logs and flow data are retained well enough to support outage analysis, compliance evidence, and post-incident reporting.
Technical view
ATT&CK provides no official detection text for this sub-technique, but the object is related to DET0173, Detection Strategy for Endpoint DoS via Service Exhaustion Flood, and M1037, Filter Network Traffic. SOC and IR teams should validate visibility around abnormal request volume, connection rates, protocol behavior, and endpoint/service resource exhaustion. Pay particular attention to HTTP flood patterns against web applications and excessive SSL/TLS renegotiation behavior where applicable. Detection should be tied to service baselines because high traffic alone can be legitimate during business peaks.
Likely telemetry
- Network flow records showing source/destination, ports, protocol, connection counts, and traffic volume
- Firewall, load balancer, reverse proxy, and network appliance logs for allowed, denied, and rate-limited traffic
- Web server and application access logs showing request rate, URI patterns, response codes, user agents, and client distribution
- DNS or other service-specific logs where those services are exposed
- TLS/SSL handshake or renegotiation metrics where collected
Detection direction
- Build baselines for normal request rates, connection rates, protocol mix, and resource consumption per critical service.
- Alert on sharp divergence between traffic volume and successful service outcomes, such as rising request/connection counts with increased errors, latency, or resource saturation.
- Correlate network telemetry with host/service metrics to distinguish service exhaustion from ordinary high demand or unrelated application failure.
- Tune detections for known legitimate spikes, maintenance windows, synthetic monitoring, and high-volume business events to reduce false positives.
- Validate whether encrypted traffic limits inspection; where content is not visible, rely on flow, TLS metadata, service metrics, and proxy/load balancer telemetry.
Mitigation priorities
- Start with M1037-aligned traffic filtering: enforce firewall and network appliance rules that restrict traffic to authorized or expected paths for exposed services.
- Place filtering and rate-control decisions as close to the network edge or service front door as practical so endpoints are not the first control point under flood conditions.
- Review whether web, DNS, and other critical services have documented thresholds, escalation paths, and emergency change procedures for traffic restrictions.
- Harden protocol and service configurations where relevant, including review of SSL/TLS renegotiation exposure when supported by the local service stack.
- Ensure IaaS-hosted services have monitored ingress rules and operational runbooks for surge conditions and denial-of-service triage.
Analyst notes and limits
This object is an ATT&CK Enterprise sub-technique under Endpoint Denial of Service and is scoped to the impact tactic. The supplied relationship to M1037 supports network traffic filtering as a mitigation direction. The Cisco NetFlow reference supports use of network flow evidence, while the Cloudflare and Arbor/Netscout references support HTTP flood and SSL/TLS renegotiation examples.
MITRE did not provide an official detection section for this object, and the supplied DET0173 relationship includes only the detection strategy name, not analytic logic. Local service architecture, traffic baselines, TLS configuration, and logging coverage are required to determine practical detection and response readiness. This take does not assert active exploitation, attribution, or guaranteed detection coverage.
Service Exhaustion Flood
Adversaries may target the different network services provided by systems to conduct a denial of service (DoS). Adversaries often target the availability of DNS and web services, however others have been targeted as well.[1] Web server software can be attacked through a variety of means, some of which apply generally while others are specific to the software being used to provide the service.
One example of this type of attack is known as a simple HTTP flood, where an adversary sends a large number of HTTP requests to a web server to overwhelm it and/or an application that runs on top of it. This flood relies on raw volume to accomplish the objective, exhausting any of the various resources required by the victim software to provide the service.[2]
Another variation, known as a SSL renegotiation attack, takes advantage of a protocol feature in SSL/TLS. The SSL/TLS protocol suite includes mechanisms for the client and server to agree on an encryption algorithm to use for subsequent secure connections. If SSL renegotiation is enabled, a request can be made for renegotiation of the crypto algorithm. In a renegotiation attack, the adversary establishes a SSL/TLS connection and then proceeds to make a series of renegotiation requests. Because the cryptographic renegotiation has a meaningful cost in computation cycles, this can cause an impact to the availability of the service when done in volume.[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.4 | Current bundle | 844c83a3d466… |
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 HTTPflood
Cloudflare. (n.d.). What is an HTTP flood DDoS attack?. Retrieved April 22, 2019.
Open source URL -
[3]
Arbor SSLDoS April 2012
ASERT Team, Netscout Arbor. (2012, April 24). DDoS Attacks on SSL: Something Old, Something New. Retrieved April 22, 2019.
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.002Open 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.