An endpoint denial of service takes a service down while the network link stays healthy, so bandwidth graphs look normal and the first signal is a crashing process, a full connection table or a wall of 503 errors. MITRE ATT&CK T1499 Endpoint Denial of Service is an Impact (TA0040) technique in which an adversary exhausts the resources of the system hosting a service, or exploits it into a persistent crash, without saturating the network. ATT&CK v20 lists it for Windows, Linux, macOS, Containers and IaaS, with four sub-techniques covering the operating system, network services, application features and exploitable flaws. This guide is the ATT&CK technique view: recorded procedures, the five v20 detection strategies, M1037 and the host and application controls that matter for each layer. It is for SOC analysts, SREs and application owners. For application design patterns such as bounding work per request, see the Denial of Service at Application Layer Guide.
Key takeaways
- Each layer has its own bottleneck. ATT&CK separates OS limits (TCP state tables), service capacity (web and DNS servers, TLS handshakes), expensive application features, and exploitable crashes. Controls and telemetry differ for each.
- Crash loops are the T1499.004 signature. ATT&CK notes automatic restarts can be re-exploited into a persistent denial of service, so a service that restarts repeatedly is an incident, not a reliability blip.
- Upstream filtering still helps. M1037 recommends CDN or DoS mitigation providers and blocking at the boundary; most endpoint floods arrive over the network even if they do not fill it.
- Host and application limits do the rest. SYN cookies, connection and request limits, timeouts, and per-identity quotas stop small floods from becoming outages.
- Autoscaling turns availability attacks into cost attacks. Cap scaling and alert on it, especially for APIs and AI workloads paid per request.
The four sub-techniques
| Sub-technique | What ATT&CK v20 describes | Primary controls |
|---|---|---|
| T1499.001 OS Exhaustion Flood | Exhausts limits the OS imposes, such as SYN floods that never complete the handshake and ACK floods that force state table lookups for connections that do not exist. Platforms: Linux, macOS, Windows | SYN cookies, backlog sizing, upstream and firewall SYN protection, load balancers that terminate TCP |
| T1499.002 Service Exhaustion Flood | Targets network services, often DNS and web: simple HTTP floods by volume, and TLS renegotiation attacks that make the server repeat costly cryptographic work | Disable client-initiated renegotiation, connection and request rate limits, CDN and WAF in front of web services |
| T1499.003 Application Exhaustion Flood | Repeated requests to resource-intensive application features until the application or server is exhausted | Per-identity quotas, pagination and query limits, caching, timeouts, cost-aware rate limits |
| T1499.004 Application or System Exploitation | Exploits a software flaw to crash an application or system; restarts can be re-exploited, and crashes may cascade into data destruction, firmware corruption or service stop | Patching, input validation, crash-loop alerting, exploit mitigations |
When bandwidth itself is the target, ATT&CK uses Network Denial of Service, T1498. The mobile and AI equivalents are Mobile T1642 Endpoint Denial of Service and AML.T0029 Denial of AI Service.
How adversaries use it
- Sandworm Team (G0034), Georgia, 2019: ATT&CK records that Sandworm Team temporarily disrupted service to Georgian government, non-government and private sector websites after compromising a Georgian web hosting provider. The UK government attributed the 28 October 2019 attacks to the GRU and said they also interrupted the service of several national broadcasters. Disruption came from inside the hosting layer, not from a flood at the edge. See the Sandworm Threat Actor Profile.
- Industroyer (S0604), T1499.004: ATT&CK records a custom DoS tool that exploits CVE-2015-5374 against hardcoded IP addresses of Siemens SIPROTEC protection relays. A crafted packet that disables a protection device is endpoint DoS with physical consequences. See the ATT&CK for ICS Impact Tactic Guide.
- ZxShell (S0412): ATT&CK records a feature to perform a SYN flood attack on a host, an OS exhaustion capability built into a remote access tool.
- OnionDuke (S0052): ATT&CK records a denial of service module.
The pattern across these cases: endpoint DoS capability often ships inside general-purpose malware or follows a broader compromise. A host that suddenly floods another, or a hosting platform that disrupts its own customers, points to an intrusion as much as to an availability event.
What to detect and where
ATT&CK v20 maps five detection strategies: DET0208 for the parent technique and DET0356, DET0173, DET0415 and DET0304 for the four sub-techniques in order. The table groups their key signals.
| Layer | Detection strategy | Signals named by MITRE |
|---|---|---|
| OS (T1499.001) | DET0356 | Windows Microsoft-Windows-TCPIP connection queue overflow or state allocation failures; Linux "possible SYN flood" and backlog exceeded messages; macOS accept queue overflow; firewall logs of SYN or ACK spikes without completed handshakes |
| Service (T1499.002) | DET0173 | Spikes in request volume and thread pool exhaustion in web logs; sustained CPU or memory in w3wp.exe, nginx or Apache; repeated HTTP 408, 500 and 503 errors; rapid TLS handshakes; VPC Flow Logs showing one source sending unusual volume |
| Application (T1499.003) | DET0415 | High-frequency errors or hangs in resource-intensive components; worker exhaustion in PHP, MySQL or mail servers; elevated 5xx rates at the gateway; autoscaling, CPU and memory alarms; bursts of function invocations |
| Exploitation (T1499.004) | DET0304 | Windows Application 1000 (application crash) and System 7031 and 7034 (service terminated unexpectedly); Linux segfaults in audit and journal logs; macOS crash logs; repeated instance termination with malformed payloads in flow logs before the failure |
| All layers | DET0208 | Windows bugcheck (event 1001) and service crashes; Linux OOM killer and kernel panic entries and repeated systemd unit failures; AWS StatusCheckFailed; Kubernetes CrashLoopBackOff, OOMKilled and restart counts above threshold |
Detections to build first
- Crash loop on an exposed service: more than a set number of unexpected terminations (7031, 7034, segfault, CrashLoopBackOff) in a window, joined with the requests received just before each crash.
- Error-rate and latency SLO burn: 5xx and timeout rates against the service's baseline, broken down by client, token and endpoint so analysts can see who is causing load.
- SYN backlog pressure: kernel SYN flood messages and TCP queue overflow events forwarded from internet-facing hosts.
- Expensive endpoint concentration: a small number of clients or API keys responsible for most calls to search, export, report or inference endpoints.
- Outbound flood from your hosts: a workload sending high request rates to another service, which MITRE's IaaS analytics also cover; treat it as possible compromise.
Tuning notes
- Releases cause crash loops too. Join crash alerts to deployment events and suppress for the rollout window only.
- Legitimate spikes happen. Marketing campaigns and batch jobs look like floods. Publish an events calendar to the SOC and baseline per hour of week.
- Kernel warnings can be self-inflicted. The Linux kernel documentation notes that SYN flood warnings without an actual flood point to legitimate overload or misconfiguration, and should be resolved by tuning backlog settings.
Mitigations
ATT&CK v20 lists one mitigation for T1499 and all four sub-techniques: M1037 Filter Network Traffic, using CDN or DoS mitigation providers to filter upstream, and blocking source addresses, targeted ports or protocols at the boundary. See M1037 Filter Network Traffic. The table adds NHI Mgmt Group recommendations per layer.
| Layer | Control | Specifics |
|---|---|---|
| OS | SYN cookies and backlog sizing | Linux net.ipv4.tcp_syncookies (kernel default 1, cookies sent when a socket's SYN backlog overflows); size tcp_max_syn_backlog and net.core.somaxconn for expected load; terminate TCP at load balancers in front of hosts |
| Service | Connection and TLS limits | Disable client-initiated TLS renegotiation (TLS 1.3 removes renegotiation); set header, body and idle timeouts; limit connections and requests per client at the proxy. See the Rate Limiting and API Abuse Guide |
| Application | Bound the work per request | Pagination caps, query cost limits, timeouts, caching of expensive results, per-identity quotas; avoid backtracking regular expressions on user input. See the Regular Expression Denial of Service (ReDoS) Guide |
| Exploitation | Patch and contain | Prioritise remotely triggerable crash flaws in exposed services; restart back-off so crash loops do not amplify load; exploit mitigations. See the Exploit Mitigations Guide |
| Containers and cloud | Resource limits and scaling caps | CPU and memory requests and limits per pod so one workload cannot starve a node; maximum instance counts and budget alerts on autoscaling groups and serverless concurrency |
Where identity fits
Application exhaustion floods increasingly come through authenticated paths: API keys, OAuth clients, service accounts and AI agents calling expensive endpoints. Per-identity rate limits and quotas let you throttle the one key causing harm without blocking every user, and give attribution when a partner integration or agent loops. Issue a distinct credential per integration and per agent so limits can be applied precisely. See AI Agent Rate Limits and the Denial-of-Wallet and AI Agent Cost Runaway Guide.
How to implement
- Profile each exposed service: its OS, server software, most expensive endpoints, current limits and the failure mode under load.
- Collect the telemetry: crash and service events, kernel network warnings, web and gateway logs with client and token identifiers, container restart and OOM events, cloud status checks.
- Set limits in monitor mode: configure rate limits and quotas to log rather than block, review two weeks of hits against real usage, then enforce. Roll back by returning a limit to log-only.
- Harden per layer: SYN protection and backlog tuning, TLS renegotiation off, timeouts, resource limits and scaling caps, patching of crash flaws.
- Alert: enable the five detections with clear owners, and link the runbook for upstream filtering.
- Test: load-test against staging or an agreed production window with approved tools, including expensive endpoints and slow clients; confirm limits trigger, alerts fire and the service recovers.
Choosing controls by size
| Organisation | Priority |
|---|---|
| Small | Managed hosting or CDN with built-in protection, default rate limits on login and search, crash alerts from the provider |
| Mid-size | Add per-identity API quotas, crash-loop detection, container resource limits, scaling caps with budget alerts, annual load test |
| Large | Add per-endpoint cost models, SLO-based alerting by client and token, regular game days, automated upstream filter activation |
Detection and measurement
- Exposed services with limits: percentage of internet-facing services with enforced connection, request and quota limits.
- Crash-loop dwell time: time from the third unexpected restart to analyst acknowledgement.
- Patch latency for crash flaws: median days to patch remotely triggerable denial of service vulnerabilities in exposed services.
- Attributable load: percentage of API traffic carrying a per-client identity that rate limits can act on.
- Load-test pass rate: services that stayed within SLO under the agreed test profile.
Common failure patterns
- Restart forever: orchestrators restart a crashing service without alerting, so an exploited crash becomes a silent, persistent outage.
- Global limits only: one shared limit for all clients means a single abusive key causes everyone to be throttled.
- Unlimited autoscaling: the service stays up while the bill grows without limit.
- Watching bandwidth only: endpoint DoS rarely moves link utilisation; without application and host signals it is invisible until users complain.
- Treating crash floods as bugs: repeated crashes from crafted input are an exploitation attempt and need security triage, not just a bug ticket.
Framework mapping
| Framework | References |
|---|---|
| ATT&CK | T1499, T1499.001, T1499.002, T1499.003, T1499.004 (Impact, TA0040); related T1498, T1489, T1485, T1495 |
| ATT&CK detection strategies | DET0208, DET0356, DET0173, DET0415, DET0304 |
| ATT&CK mitigations | M1037 Filter Network Traffic |
| NIST SP 800-53 Rev. 5 | SC-5 Denial-of-service Protection; SC-7 Boundary Protection; SI-4 System Monitoring; CP-10 System Recovery and Reconstitution |
| NIST CSF 2.0 | PR.IR-04 adequate resource capacity; PR.IR-03 resilience mechanisms; DE.CM-09 monitoring of computing hardware and software |
| MITRE D3FEND | D3-NTF Network Traffic Filtering; D3-ISVA Inbound Session Volume Analysis |
Practitioner checklist
- Every internet-facing service is behind upstream filtering or a CDN.
- SYN cookies are on and backlog settings are sized on internet-facing Linux hosts.
- Client-initiated TLS renegotiation is disabled; timeouts are set at the proxy.
- Expensive endpoints have per-identity quotas, pagination caps and timeouts.
- Each integration and AI agent has its own credential so limits can target it.
- Crash loops on exposed services alert the SOC, joined with preceding requests.
- Containers have resource limits; autoscaling and serverless concurrency have caps and budget alerts.
- Remotely triggerable crash flaws in exposed services have a patch target in days.
- Load tests including expensive endpoints run at least annually.
Standards and references
- MITRE ATT&CK: T1499 Endpoint Denial of Service
- MITRE ATT&CK: T1499.001 OS Exhaustion Flood
- MITRE ATT&CK: T1499.004 Application or System Exploitation
- MITRE ATT&CK: M1037 Filter Network Traffic
- Linux kernel documentation: IP Sysctl
- UK Government: UK condemns Russia's GRU over Georgia cyber-attacks
- NCSC: Denial of Service (DoS) guidance
Related NHI Mgmt Group resources: Denial of Service at Application Layer Guide, DDoS Protection Guide, DDoS Response Playbook, ATT&CK Impact Tactic Guide.