How T1499 endpoint denial of service shows up in your SOC
When a host or service is slow or unavailable, the first question for the SOC is whether the cause is an adversary exhausting the endpoint or an ordinary fault. T1499 Endpoint denial of service covers the case where an adversary tries to degrade or stop a system's availability by consuming its resources directly: CPU, memory, disk, application capacity or connection slots. Unlike network-volume attacks that saturate a link, this technique targets the endpoint itself, so the evidence usually sits on the host, in its application logs and in the traffic reaching it. The technique sits under the Impact tactic, which ATT&CK defines as adversary activity that tries to manipulate, interrupt or destroy systems and data (TA0040). It has four sub-techniques, each describing a different resource or service being exhausted, and it appears in intrusions alongside other Impact activity such as resource hijacking or service stop, often as a distraction or as pressure on a service the adversary wants to disrupt.
Detection mappings in this section target Enterprise ATT&CK version 20.0. ATT&CK IDs, sub-technique structure and detection strategy identifiers can change between releases, and MITRE can rename, deprecate or revoke techniques, so your detection content should record the version it was written against. Confirm the current technique and sub-technique list in the MITRE ATT&CK tactic page for Impact before you map rules to coverage reports. Practically, the decision for the SOC is triage: for a slow or failing endpoint, check whether process creation, application log content and network traffic flow show a single source or process consuming a disproportionate share of a resource, or a sustained flood of requests against one service. Agree in advance which of your hosts and services are expected to show load spikes, such as batch jobs or backup windows, so that legitimate peaks do not hide a genuine denial of service.
The response decision follows from that triage. If the evidence points to an endpoint being exhausted on purpose, the SOC needs to decide whether to isolate the host, throttle or block the source at the network boundary, or fail the service over to a standby, and each choice has an availability cost that the service owner should approve. Record these decisions with the owners of the affected platform before an incident, because the people who can accept a failover or a temporary block are rarely the people on the first alert. Ask your platform team which resource limits, rate limits and connection caps are already configured on the endpoints in scope, since these determine whether an exhaustion attempt is visible in logs before it becomes an outage.
Which telemetry reveals endpoint denial of service
This table maps the three telemetry sources most useful for T1499 to the signal each one shows, the open-source collector that gathers it, and what the team must confirm on each host family. Read each row as a question to answer for your own estate before writing detection logic. The main takeaway is that no single source covers every platform, so coverage gaps should be documented before a detection is trusted.
| Telemetry source | Signal to look for | Open-source collector | Confirm on Windows, Linux, macOS and containers |
|---|---|---|---|
| Process Creation (DC0032) | Abnormal process counts, or a small set of resource-heavy processes spawning or consuming unusual CPU and memory for the host's baseline | Wazuh agent, Velociraptor for on-demand collection | Process creation events are enabled and forwarded on Windows, audit or process accounting is active on Linux and macOS, and container runtime process visibility is available to the agent |
| Application Log Content (DC0038) | Repeated service errors, timeouts, queue backlogs or health check failures that rise sharply in a short window | Wazuh log collection, Velociraptor artifacts for application logs | Each service writes logs to a location the agent can read, and log rotation does not drop lines during a spike |
| Network Traffic Flow (flow records) | Sudden connection floods, many half-open or short-lived sessions to one endpoint, or a sharp change in packets per second | Zeek connection logs, Suricata flow records | Sensors see traffic to the protected endpoints on each segment, and container east-west traffic is captured or flow-exported |
| Host status and resource metrics | Sustained CPU, memory, file descriptor or connection table exhaustion on a single endpoint | Wazuh agent system inventory and performance checks | Metrics are collected for each host family, and container limits and node-level metrics are both visible |
| Container runtime events | Restart loops, rapid pod or container churn, or a single container consuming its resource limit | Wazuh agent with container runtime integration, Velociraptor | Runtime event streams are enabled, and orchestrator events are retained long enough to correlate with network and process data |
| Process termination and service state | Services or agents stopping or restarting while load is high, which can indicate the endpoint is being starved | Wazuh agent service monitoring | Service state is monitored on Windows services and Linux and macOS daemons, with alerts tied to the same time window as the load signal |
Detection logic for T1499 that engineers can tune
The four ideas below cover the symptoms T1499 Endpoint Denial of Service leaves on a host: resource exhaustion, service instability, inbound connection surges and container limits. Each one starts from a baseline for the specific workload, so thresholds reflect normal peaks rather than generic values. Every card lists the false positive sources engineers should exclude before alerting.
Sustained resource saturation on endpoints
Alert when CPU, memory, disk I/O or process count stays near capacity for longer than the workload's normal peak window, and when a single process accounts for most of the load. Pair the host metric with Process Creation telemetry to identify which process or parent started the spike. Baseline each host group separately, since a database server and a build agent have very different normal ranges. Exclude nightly backups, batch jobs, patch installs, load tests and scheduled reindexing by matching their known schedules or change tickets.
Burst of service restarts and errors
Correlate repeated service restarts, crash loops and spikes in application error logs within a short window on the same host. A single restart is rarely meaningful, but several within minutes, combined with timeouts or queue overflow messages in Application Log Content, suggests the service is being overwhelmed. Tune the window and count against the service's historical restart rate. Expect false positives from deployments, configuration reloads and rolling restarts, so suppress alerts that match a logged change event.
Abnormal inbound connection rates
Measure new inbound connections per second to each exposed host from Network Traffic Flow records, and alert when a source or group of sources exceeds a per-host baseline by a wide margin. Track half-open or unanswered connections separately, because they point to flood patterns. Thresholds depend on the service and the client population, so set them from at least several weeks of traffic. Watch for load balancer health checks, CDN origins, marketing campaigns, and legitimate traffic from autoscaling clients.
Container resource exhaustion
Monitor container CPU throttling, memory limit hits and OOM kill events against the limits set in each pod or container spec. Repeated throttling or OOM kills on the same workload, especially when request rates rise at the same time, indicate exhaustion that may stem from T1499 or from a poorly sized workload. Confirm which signals your container runtime and orchestrator expose before writing rules. Exclude scheduled jobs, autoscaling events and node drains, which create similar patterns.
How to validate that T1499 detections fire
This sequence proves, in a private cyber range, that each T1499 detection fires on the expected telemetry, within a measured latency, and that the results are recorded against the ATT&CK version the rules target. It turns a rule set that looks correct on paper into evidence a security team can defend.
Define emulation scope and approvals
The detection owner, the platform owner and the range administrator agree in writing which T1499 sub-techniques and platforms are in scope, which test hosts and network segments may be used, and who can halt the exercise. Record the ATT&CK version the detection mappings target so every later result refers to the same technique definitions. Confirm the change window with operations staff and make sure no production systems or shared monitoring paths are reachable from the range. The step is done when the signed scope sheet lists each sub-technique, each test host and the stop conditions.
Baseline telemetry on test hosts
Before any emulation, the detection engineer confirms that Process Creation, Application Log Content and Network Traffic Flow records are arriving from every test host into the SIEM, such as Wazuh or Security Onion. Check that timestamps are synchronized, that agents are reporting the expected fields and that the rule set loads without errors. Capture a quiet baseline for the same window so that normal load on the hosts is understood before pressure is added. The step closes when the baseline shows complete, time-aligned records from each host and the rule set reports no load errors.
Run a controlled resource-pressure emulation
The red team or range operator runs a bounded resource-pressure emulation against the approved test hosts, covering only the sub-techniques in the signed scope. The operator follows the agreed profile, keeps a timestamped log of each start and stop, and watches host health so the exercise can be halted under the stop conditions. The emulation should be repeated across the Windows, Linux, macOS and container targets in scope, because the telemetry differs by platform. The step is done when the operator log, the host health record and the range timeline all agree on when each action began and ended.
Confirm each rule fires with expected fields
The detection engineer checks, rule by rule, that the expected alert was raised for each emulated action and that the event contains the fields the analytic depends on, such as process name, parent process, command context, source address or service identifier. Mark any rule that stays silent, fires on the wrong host, or fires without the fields it needs. Treat a missing field as a defect in the log pipeline or parser, not only in the rule. The step closes when every in-scope rule has a recorded pass, fail or partial result with the evidence attached.
Measure detection latency for each alert
For every alert that fired, the team calculates the time between the first emulated action in the operator log and the alert timestamp in the SIEM, separating ingestion delay from rule evaluation delay where the platform allows. Record latency per platform and per sub-technique, because a rule that is fast on Linux may be slow on a container host. Ask the platform owner to confirm the expected ingestion and scheduling intervals for the SIEM in use before setting any acceptance threshold. The step is done when a latency table exists for each rule and each target, with the threshold the business has agreed to accept.
Test response and host recovery
The incident responder works from the generated alerts through the documented runbook, including triage, containment of the test host and restoration of normal service. The team checks that the mitigations in scope, such as filtering network traffic at the boundary the range provides, behaved as documented, and notes any step that depended on a person who was not available. Confirm that the test host returns to its baseline state before the next run. The step closes when the responder's notes, the restored host health record and the list of runbook gaps are filed with the exercise.
Record results against the ATT&CK version
The team writes a results register that lists each detection strategy and analytic, the ATT&CK version it targets, the pass, fail or partial outcome, the observed fields, the measured latency and the owner of any fix. Because MITRE can rename, deprecate or revoke techniques between releases, the register must name the exact ATT&CK version used, and the detection owner should check the MITRE updates notes before the next review. The step is done when the register is approved by the detection owner and the CISO's delegate, and each failed item has a tracked remediation and a retest date.
Preventive controls that limit endpoint denial of service
Preventive controls reduce how much endpoint availability an adversary can take away and how quickly services recover. The cards below cover network filtering, segmentation and backup, with the limits of each. Filtering is the primary mitigation for T1499 and the others support availability around it.
Filter network traffic (M1037)
ATT&CK maps Filter Network Traffic (M1037) to T1499 because many endpoint denial of service attempts arrive as floods of connections or requests that a filter can meter or drop before they exhaust a service. Review where filtering sits: host firewalls, cloud network security groups, load balancer rate limits and web application firewalls each see different traffic. Confirm which rules apply to each exposed service, how connection and request limits are set, and whether the team can change them during an incident without a change window. Filtering cannot stop an attack that uses legitimate-looking requests against expensive application functions, so pair it with application-level limits.
Limit what filtering cannot see
Filtering works on packets and headers, so it misses application-layer work such as expensive queries, large uploads or repeated authenticated calls. Ask which endpoints can be expensive for a single client, and confirm that request size caps, timeouts, per-account quotas and concurrency limits exist for them. Check whether these limits are enforced at the service and not only documented in a runbook. Without them, a low volume of valid requests can still degrade an endpoint while network telemetry looks normal.
Segment services to contain impact
Network Segmentation (M1030) supports availability by keeping a flood against one service from consuming shared links, firewalls or hosts used by others. Confirm which services share a subnet, load balancer pool, database or egress path, and whether a noisy service can be isolated without taking down unrelated ones. Segmentation does not stop an attacker who can reach the target from inside the same segment, and it adds routing and policy work that must be tested. Review the boundary rules at each segment edge alongside the filter rules.
Recover with tested backups
Data Backup (M1053) does not prevent an endpoint from being overloaded, but it shortens recovery when an attack causes data corruption, failed nodes or emergency rebuilds. Confirm that backups cover the configuration, the data stores and the infrastructure definitions that the affected services need, and that restores have been timed in a test. Check that backups are stored separately from the systems they protect so a denial of service event cannot remove them along with the service. Backups are not a defense against the traffic itself.
Measure filter coverage
A filter is only preventive if it is applied to the paths an attacker can reach. Build an inventory of internet-facing and partner-facing endpoints, then check each against the filtering layer that covers it. Record gaps such as direct origin access that bypasses a CDN or load balancer, or services exposed through a management interface. Tie each gap to an owner and a retest date, and rerun the check after ATT&CK version changes or infrastructure moves, since mappings can change between releases.
Triage and response when a T1499 alert fires
The first decision on a T1499 alert is whether the pressure on the endpoint is hostile or simply legitimate demand that the service was not sized for. Start by confirming which endpoint and which service are affected, then compare the alert against the service's normal request profile for the same hours and days. Check whether the traffic arrives from a narrow set of sources, repeats the same request path, or spikes without a matching change in marketing activity, batch schedules, or customer behavior. Ask the service owner whether a release, a partner integration, or a scheduled job went live at the time of the spike, because an internal cause can look identical to an attack in the first few minutes.
Next, correlate the endpoint signals with network flow records and application logs. Flow data should show whether the volume is concentrated on the affected port and whether connection counts, not just bandwidth, are climbing. Application logs should show whether requests are completing, timing out, or failing with resource exhaustion errors, and whether error rates track the traffic rate. Process creation telemetry on the host helps confirm whether the service is being restarted or whether a new process is consuming CPU, memory, or file handles. Record the time window and the fields you used so the analysis can be repeated. Where your detection relies on a single data source, treat the alert as unconfirmed until a second source agrees.
If the evidence points to hostile traffic, choose the least disruptive containment that keeps the service usable. Options usually include upstream rate limiting or filtering at the network edge, temporarily isolating the host from the segment it shares with other workloads, or moving the service behind an existing traffic control. Before changing anything, preserve the relevant flow records, application logs, and a memory or process snapshot if your procedures call for it, and note every change with its time. Notify service owners and the incident coordinator before containment, and agree on a rollback condition. Afterward, document what the alert threshold missed or over-reported, and feed those lessons into tuning and the next cyber range rehearsal. Confirm with your own change and evidence procedures and with your legal team what must be retained.
Rehearsing T1499 detection in a private cyber range
Build a small range of Windows and Linux endpoints enrolled in the same log pipeline as production, with the Wazuh agent or equivalent collector, Sysmon or the Linux audit subsystem feeding process creation events, and a Security Onion or Zeek sensor on the segment. The blue team receives injects that drive sustained process-level resource pressure on one host at a time, with no advance notice of which host or which sub-technique is in play. Good detection means the alert fires within the window agreed in the exercise plan, names the correct host and the responsible process, and the triage notes separate the resource symptom from the process that caused it. Good response means a containment decision recorded with a reason, the affected service restored from a documented procedure, and an after-action review that compares the alert timeline with the inject log.
- Topology: two or three Windows hosts and two or three Linux hosts on one range segment, each with a documented owner and baseline resource profile.
- Injects: staged load injects on one host at a time, with varied duration, so the team must confirm which host is affected.
- Detection quality: alert timing against the inject log, correct host attribution, and triage notes that name the process and the evidence used.
- Response quality: containment decision, service restoration, and a record of who approved each step.
- Review: replay the telemetry in the Wazuh or Security Onion console to confirm the rule matched the intended behavior, and log any false positives.
Check that every host has a known-good baseline before the exercise starts, so alerts can be scored against it.
Deploy a container cluster in the range that mirrors the production orchestration model, with namespaces for two or three workloads, resource requests and limits set as they are in production, and container runtime and orchestrator audit logs forwarded to the central platform. The injects target one workload at a time, so the blue team must separate a noisy neighbor from a deliberate exhaustion pattern. Good detection means the team identifies the affected namespace and pod, not only the node, and documents whether limits were enforced as designed. Good response means the team decides whether to cordon a node, scale a deployment or apply a limit change, and records the change in the cluster audit trail.
- Topology: one control plane and two or three worker nodes, with two or three workloads in separate namespaces and documented resource limits.
- Injects: resource pressure applied inside one workload, followed by a second inject that targets the node itself.
- Detection quality: the alert identifies the namespace and workload, and the team can explain why limits did or did not contain the impact.
- Response quality: a containment step that is reversible, a record of the change in the audit log, and confirmation that other workloads stayed healthy.
- Review: compare the container runtime events with the orchestrator events to confirm the timeline and the attribution.
Confirm with your platform team which orchestrator version and audit policy the range will use, because log fields vary between releases and detection content must match the version under test.
Place a representative network-facing service behind a load balancer or reverse proxy in the range, with its access logs and flow records forwarded to the sensor stack. The injects send high-rate request or connection patterns from a small set of sources, then vary the source set so the team must decide whether the traffic is one client or many. Good detection means the alert fires on the traffic pattern at the service boundary, the team attributes it to specific source addresses or ranges, and the triage notes state whether the service, the proxy or the network path was the bottleneck. Good response means the team applies a filtering decision at the right layer, restores the service to its documented availability target, and records what was blocked and why.
- Topology: one service instance with a proxy in front, a second instance for failover, and a sensor on the path that sees both the client and service sides.
- Injects: a single-source pattern first, followed by a distributed pattern, so the team must change its filtering decision.
- Detection quality: alert timing against the inject log, correct source attribution, and a clear statement of which layer was affected.
- Response quality: a filtering change applied and then reviewed, a rollback plan, and evidence that legitimate traffic was preserved.
- Review: test that the Filter Network Traffic mitigation is enforced at the intended control point and that its logs reach the sensor.
Confirm the expected request-rate thresholds and blocking policy with the service owner before the exercise, so the team is not scored on a limit nobody agreed to.
Practitioner questions about detecting T1499
How do I separate T1499 endpoint denial of service from T1498 network denial of service?
Separate them by where the exhaustion happens. T1498 (network denial of service) saturates bandwidth or network capacity before traffic reaches the host, so its signals sit in network traffic flow and connection volume. T1499 targets the endpoint itself, so its signals appear in process creation, application logs and host resource behavior, such as a service that keeps spawning processes or exhausting connections while network volume stays modest. In practice, correlate both views on the same asset and time window. A spike in inbound flows with no matching host-side load points to T1498, while host-side exhaustion with ordinary network volume points to T1499. Confirm the telemetry available for each asset class in your own environment before you commit to a mapping.
How do I tune T1499 detections for autoscaling and batch windows?
Start from a baseline of normal load per workload, then alert on deviation from that baseline rather than on absolute thresholds. Autoscaling groups and nightly batch jobs produce sharp, expected spikes, so suppressions should be tied to known identifiers, such as the scheduler's job name, the autoscaling group or the change window, not to broad time-of-day exclusions that an attacker could also use. Review every suppression on a schedule and record who approved it. Test each tuned rule against a recorded batch run and a recorded scale-out event before promoting it to production. Expect the first tuning cycle to take longer than the rule itself, and plan analyst time for it.
How do I map detection rules to MITRE ATT&CK version 20.0?
Map each rule to a detection strategy and its data components for the exact ATT&CK version you target, and record that version in the rule metadata. The Enterprise ATT&CK 20.0 release is available as a STIX 2.1 bundle in the attack-stix-data repository, and that bundle is the most reliable place to check which data components a technique references. Since ATT&CK v18, detections on technique pages are expressed as detection strategies with DET IDs and analytics, and data sources have been deprecated in favor of data components, so older mappings built on data sources need to be rewritten. Re-validate mappings after each release, because techniques can be renamed, deprecated or revoked.
How do I cover T1499 on containers without losing host context?
Collect container runtime events and host-level process data together, because a container process creation event alone may not show the resource pressure it causes. Label each event with the container ID, image name, pod or namespace where your platform provides them, so a rule can aggregate by workload. Watch for repeated process spawning, connection bursts from a single container and restart loops that signal resource exhaustion. Confirm which container runtime, logging driver and orchestrator telemetry your platform exposes, since coverage differs by stack, and test that metadata survives the log pipeline before relying on it.
How do I measure T1499 detection coverage over time?
Track coverage as a set of measurable items: which assets send the required telemetry, which rules are enabled and mapped to the target ATT&CK version, and which rules have been validated in a cyber range within the last review cycle. Report these as trends rather than a single score. Keep a register of validation results, including the replay date, the rule version and the outcome, so you can show whether a tuning change lost detection. Review the register after each ATT&CK release and after each significant change to workloads or logging. Ask your team to define the review cadence in writing so it is auditable.
Which mitigations should I rely on for T1499 besides detection?
The ATT&CK mitigation most directly tied to this technique in its family is Filter Network Traffic (M1037), which applies to the network-facing parts of the exposure. Pair it with capacity controls and rate limiting at the application and host layers, and with Network Segmentation (M1030), which limits how many systems an overload can reach. Mitigations reduce the chance and impact of an attack, but they do not replace detection, so keep both. Check each mitigation against your own architecture and confirm with your network and platform teams which controls are already in place.
How should I rehearse T1499 detection and response in a cyber range?
Rehearse in a private range that mirrors your production logging and network paths, so that a detection that works in the range also works in production. Define a scenario with a clear start, a set of expected signals and a response runbook, then run it against the rule versions you plan to deploy. Record what fired, what was missed, how long the analysts took to triage and which runbook steps were unclear. Use the results to update rules and runbooks, and repeat the exercise after each major change. DeployOpen can plan and run this as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing first.
How DeployOpen builds T1499 detections and range exercises
DeployOpen starts every T1499 engagement with a written scope that names the systems, operating systems, container platforms and network segments in play, the telemetry sources the client already collects, and the ATT&CK version the detections will target. For this technique that means agreeing which endpoints and workloads are in scope for Process Creation and Application Log Content collection, which network sensors can see Network Traffic Flow for the affected segments, and who on the client side owns alert triage and change approval. The scope also records the ATT&CK version used for mapping, because technique and sub-technique structure can change between releases and the detection logic needs a fixed reference. Deliverables, the number of rules, the range exercises and the evidence pack are listed in the same document before work begins, so the client can judge the effort against its own environment.
Implementation happens inside the client's own infrastructure, using open-source components such as Wazuh for host telemetry, Zeek or Suricata for network metadata and Sigma rules converted to the client's SIEM. DeployOpen tunes thresholds for the client's normal traffic patterns, such as load balancer health checks, backup jobs and CI pipelines that can look like flood or resource exhaustion, and documents each exclusion with a reason and an owner. Filtering recommendations for the ATT&CK mitigation Filter Network Traffic are written against the client's actual edge, cloud and host firewalls, and the client's network team confirms which controls can be changed and who approves them. Any capability the client's chosen platform lacks, such as per-host connection rate limiting, is recorded as a gap to confirm with the vendor rather than assumed.
Before the detections go live, DeployOpen runs purple team exercises in a private cyber range that mirrors the client's operating systems and sensor placement. The exercises replay controlled load scenarios, the expected alerts are compared with what the SIEM actually raised, and the results go into a findings log with the gaps and owners. DeployOpen documents the detection logic, configuration, test results and residual risk as evidence that the client's teams can hand to internal audit or an independent assessor. DeployOpen prepares these systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Those decisions remain with the client's auditor or certification body.
