Last reviewed:
T1499 targets the application rather than the pipe: request floods, resource exhaustion and crash-inducing payloads that take a service down without remarkable bandwidth. Resilience is the measurable control. DCV maps Azure's DDoS protection policy and Defender recommendation alongside a broad AWS Config set covering cross-zone load balancing, multi-AZ database deployment and autoscaling health-check requirements, the checks that decide whether an exhaustion attack finds a single point of failure. A ModSecurity detection stream covers the HTTP flood shape at the edge.
Adversaries may perform Endpoint Denial of Service (DoS) attacks to degrade or block the availability of services to users. Endpoint DoS can be performed by exhausting the system resources those services are hosted on or exploiting the system to cause a persistent crash condition. Example services include websites, email services, DNS, and web-based applications. Adversaries have been observed conducting DoS attacks for political purposes and to support other malicious activities, including distraction, hacktivism, and extortion.
An Endpoint DoS denies the availability of a service without saturating the network used to provide access to the service. Adversaries can target various layers of the application stack that is hosted on the system used to provide the service. These layers include the Operating Systems (OS), server applications such as web servers, DNS servers, databases, and the (typically web-based) applications that sit on top of them. Attacking each layer requires different techniques that take advantage of bottlenecks that are unique to the respective components. A DoS attack may be generated by a single system or multiple systems spread across the internet, which is commonly referred to as a distributed DoS (DDoS).
To perform DoS attacks against endpoint resources, several aspects apply to multiple methods, including IP address spoofing and botnets.
Adversaries may use the original IP address of an attacking system, or spoof the source IP address to make the attack traffic more difficult to trace back to the attacking system or to enable reflection. This can increase the difficulty defenders have in defending against the attack by reducing or eliminating the effectiveness of filtering by the source address on network defense devices.
Botnets are commonly used to conduct DDoS attacks against networks and services. Large botnets can generate a significant amount of traffic from systems spread across the global internet. Adversaries may have the resources to build out and control their own botnet infrastructure or may rent time on an existing botnet to conduct an attack. In some of the worst cases for DDoS, so many systems are used to generate requests that each one only needs to send out a small amount of traffic to produce enough volume to exhaust the target's resources. In such circumstances, distinguishing DDoS traffic from legitimate clients becomes exceedingly difficult. Botnets have been used in some of the most high-profile DDoS attacks, such as the 2012 series of incidents that targeted major US banks.
In cases where traffic manipulation is used, there may be points in the global network (such as high traffic gateway routers) where packets can be altered and cause legitimate clients to execute code that directs network packets toward a target in high volume. This type of capability was previously used for the purposes of web censorship where client HTTP traffic was modified to include a reference to JavaScript that generated the DDoS code to overwhelm target web servers.
For attacks attempting to saturate the providing network, see Network Denial of Service.
Platforms: Windows, Linux, macOS, Containers, IaaS.
DCV maps 13 detections across 3 cloud providers to T1499. Coverage by source:
| Source | Cloud | Findings mapped | Avg confidence |
|---|---|---|---|
| AWS Config Rules | AWS | 10 | 0.57 |
| Azure Policy | Azure | 1 | 0.95 |
| GCP Chronicle | GCP | 1 | 0.85 |
| Microsoft Defender for Cloud | Azure | 1 | 0.95 |
CloudSigma has coverage metadata for 13 T1499 rules across 4 platforms. The linked platform page remains the canonical rule surface; this page will embed an example after a rule clears the public embed bar.
CloudSigma has coverage metadata for T1499, but no public example rule clears the embed bar for this page yet. Generate a fresh starting-point rule in CloudSigma from the relevant advisory or threat-research input, then validate it against your local telemetry before enabling it in production.
T1499 targets the application rather than the pipe: request floods, resource exhaustion and crash-inducing payloads that take a service down without remarkable bandwidth. Resilience is the measurable control. DCV maps Azure's DDoS protection policy and Defender recommendation alongside a broad AWS Config set covering cross-zone load balancing, multi-AZ database deployment and autoscaling health-check requirements, the checks that decide whether an exhaustion attack finds a single point of failure. A ModSecurity detection stream covers the HTTP flood shape at the edge.
DCV maps 13 cloud-native detections to T1499 across 3 cloud providers, drawn from AWS Config Rules, Azure Policy, GCP Chronicle and Microsoft Defender for Cloud.
T1499 is part of MITRE ATT&CK TA0040 Impact: How adversaries disrupt or destroy systems and data.
CloudSigma ships 4 validated Sigma rules for T1499 across AWS CloudTrail, Azure Activity, GCP Audit Logs and ModSecurity. Each rule is validated against its source SIEM dialect before publication.