Detecting and Mitigating Endpoint Denial of Service (T1499)

Not every outage is a flood. T1499, Endpoint Denial of Service, degrades or blocks the availability of services by exhausting the resources of the system that hosts them, or by exploiting it to cause a persistent crash. MITRE files it under impact, for Windows, Linux, macOS, containers and IaaS.

How attackers use it

Example services include websites, email, DNS and web based applications. Adversaries have used these attacks for political purposes and to support other malicious activity, including distraction, hacktivism and extortion.

The key difference from network DoS (T1498) is that the service is denied without saturating the network used to reach it. Attackers can target different layers of the stack: the operating system, server applications such as web servers, DNS servers and databases, and the web applications on top of them. Each layer has its own bottlenecks, so each needs different techniques.

As with network attacks, the traffic can come from one system or many. Source spoofing can hide the origin or enable reflection, which weakens source based filtering. Botnets, built or rented, let many low volume senders overwhelm a target while looking like ordinary clients.

MITRE also describes a variation in which adversaries manipulate traffic at network choke points so that users' clients run code that floods a target. It notes that this was previously used for web censorship.

MITRE's examples include malware with a built in DoS module, a state linked group that temporarily disrupted Georgian websites in 2019 after compromising a hosting provider, and a remote access tool with a SYN flood feature.

How to detect it

MITRE's detection strategy covers five environments.

• Windows: user or script launched processes that rapidly consume CPU or memory, or send malformed service requests, causing exhaustion or crashes.
• Linux: a script or binary that repeatedly causes kernel panics, out of memory kills, or restarts of services such as web, HTTP or SSH servers.
• macOS: a process or malformed application package that repeatedly crashes apps and slows the system.
• Cloud: an instance that becomes degraded or unhealthy from abnormal process load or memory exhaustion.
• Containers: orchestrator logs showing crash looping pods, repeated resource exhaustion, or binaries with infinite loops hitting systemd or cgroup limits.

MITRE does not name log sources. The analytics point to kernel and system logs, service manager logs, container orchestrator logs, CPU and memory metrics, and cgroup limit events.

Alerts that matter most:

1. Repeated restarts of the same service in a short window.
2. Out of memory events on a production host.
3. A single client or small set of clients accounting for a large share of requests.
4. Request latency rising while network bandwidth stays normal, which points to the host and not the link.

That last one separates T1499 from T1498.

Click through it at your own pace, or open it full screen.

How to reduce the risk

MITRE lists filtering network traffic. Use CDN or DoS mitigation providers to filter traffic upstream of services. Filter boundary traffic by blocking source addresses sending the attack, blocking ports being targeted, or blocking protocols being used. To defend against SYN floods, enable SYN cookies.

Beyond that, harden the layers MITRE says are attacked:

1. Set request size, timeout and rate limits in web servers and application code.
2. Set memory and CPU limits and restart policies on services and containers.
3. Test how your application behaves with a very large or malformed request, in a staging environment you own.
4. Add health checks and autoscaling where it fits.
5. Keep software patched, since crashes can come from known flaws.

Check your own environment

On a Linux host, these read-only commands show recent signs of resource trouble.

# Out of memory kills in the kernel log
dmesg | grep -i "out of memory"

# Recent service failures under systemd
systemctl --failed

Then review your web server rate limits, and confirm CPU and memory alerts exist for each production service.

Quick check

Sources

• MITRE ATT&CK T1499: Endpoint Denial of Service