Endpoint Telemetry Is the Evidence Layer Behind Every MITRE ATT&CK Technique

Every technique cataloged in the MITRE ATT&CK enterprise matrix produces observable signals at the endpoint. That is not a coincidence or a design aspiration — it is a structural fact about how operating systems work. Understanding why that relationship exists, and how to exploit it operationally, is one of the clearest separators between security programs that detect intrusions early and those that discover them months later.

The MITRE ATT&CK framework, maintained by the nonprofit MITRE Corporation and updated continuously since its public release in 2015, now catalogs 216 techniques and 475 sub-techniques across 14 tactics in the Enterprise matrix as of ATT&CK v18 (released October 2025). Each one of those entries was derived from observed, real-world adversary behavior — not theoretical attack paths. And because real adversaries operate on real operating systems, every one of those techniques generates some form of artifact in endpoint telemetry. That is the connection that makes telemetry not just useful but foundational to a detection program built around ATT&CK.

What Endpoint Telemetry Actually Is

Endpoint telemetry is the continuous stream of behavioral and state-change data produced by operating systems, security agents, and instrumented applications running on individual hosts. It is distinct from network telemetry (which captures packet flows and connections) and log-based telemetry (which captures discrete application events). What makes endpoint telemetry unique is its granularity: it captures what happened inside a process, not just that the process communicated somewhere.

At the operating system level, telemetry sources include process creation events with full command-line arguments, file system operations (reads, writes, renames, deletions), registry modifications on Windows systems, network connections initiated by specific processes, inter-process communication such as named pipe usage and shared memory access, driver and kernel module loads, and authentication events. Modern endpoint detection and response (EDR) platforms go further, adding parent-child process relationship tracking, memory region permissions monitoring, API call tracing, and in-memory code scanning.

On Windows systems, Event Tracing for Windows (ETW) is the underlying kernel mechanism that many of these data streams flow through. Microsoft's own Sysmon — a free system monitor from the Sysinternals suite — exposes a curated set of these ETW channels as structured XML events that feed into SIEM platforms. Sysmon Event ID 1 captures process creation with hash and command-line. Event ID 3 captures network connections. Event ID 10 captures process access — a critical source for detecting credential dumping. Event ID 25, added in Sysmon v13, captures process tampering, which helps detect hollowing and doppelganging techniques that ATT&CK tracks under T1055. As of late 2025, Microsoft has announced that Sysmon functionality will become a native optional feature in Windows 11 and Windows Server 2025, deliverable via Windows Update — removing the manual per-endpoint deployment burden that has historically limited consistent Sysmon coverage across enterprise fleets.

On Linux and macOS, analogous instrumentation exists through auditd, eBPF-based sensors, and the Endpoint Security Framework introduced in macOS 10.15 Catalina. eBPF (Extended Berkeley Packet Filter) has become particularly significant because it allows security vendors to attach monitoring programs directly to kernel functions without requiring loadable kernel modules — meaning an attacker who avoids creating new kernel modules cannot blind an eBPF-based sensor simply by subverting the module loader.

ATT&CK as a Signal Catalog, Not Just a Technique List

A common misreading of the ATT&CK framework treats it as a threat intelligence reference — a list of things attackers do. That reading is accurate but incomplete. Each technique entry in ATT&CK includes detection guidance that identifies what telemetry sources, data components, and specific data elements defenders should monitor to identify the technique in action. MITRE structured this through a parallel taxonomy called ATT&CK Data Sources, which was formalized and restructured in ATT&CK v10 in October 2021. In the landmark ATT&CK v18 release of October 2025, MITRE went significantly further: traditional Data Sources were deprecated entirely and replaced by two new structured objects — Detection Strategies and Analytics — that transform the framework from a static catalog into a behavior-driven detection model. Detection Strategies define high-level approaches to detecting specific adversary techniques. Analytics provide platform-specific, actionable detection logic with explicit links to log sources and telemetry data components. This means that as of v18, every technique in the Enterprise matrix maps not just to "what log source to collect" but to structured detection logic that specifies exactly how to operationalize that telemetry against adversary behavior.

Prior to v18, the ATT&CK Data Sources taxonomy identified over 30 distinct data source types, each with specific data components. The Process data source included components for Process Creation, Process Termination, Process Access, Process Metadata, and OS API Execution. The File data source included File Creation, File Modification, File Deletion, File Access, and File Metadata. Network Traffic included Network Connection Creation, Network Traffic Content, and Network Traffic Flow. Each technique was mapped to the data source components that produce detectable signals. The v18 overhaul preserves this granularity but links it explicitly to detection logic rather than leaving the implementation gap between "what to collect" and "how to detect" to the organization to bridge independently.

The MITRE ATT&CK Design and Philosophy document (v1.0) states that the framework is not intended to enumerate every possible attacker action. Its purpose is to give defenders an empirically grounded foundation for prioritizing detection and response investments against documented, real-world adversary behavior. — MITRE Corporation, ATT&CK Design and Philosophy, v1.0

This means that when a defender looks up T1059.001 (PowerShell under the Command and Scripting Interpreter technique), they do not just learn that attackers use PowerShell — they find that detection requires monitoring Process Creation events for PowerShell invocations with suspicious arguments, Command execution data from Script Block Logging (Windows Event ID 4104), and Module Load events for suspicious PowerShell module imports. That is a direct prescription for what telemetry sources to configure and ingest. The framework is doing double duty as both a threat catalog and a sensor requirements document.

How Telemetry Maps to Each ATT&CK Tactic

Walking through the 14 ATT&CK Enterprise tactics illustrates how endpoint telemetry provides a signal for each stage of adversary activity. This is not an abstract claim — it holds up under technical scrutiny at each tactic level.

Reconnaissance and Resource Development

These two pre-intrusion tactics (TA0043 and TA0042) are the hardest to detect from endpoint telemetry alone because they occur before the adversary touches the victim's infrastructure. However, certain sub-techniques do produce endpoint artifacts. T1598 (Phishing for Information) may leave browser process telemetry showing credential submission to lookalike sites. T1588.002 (Obtain Capabilities: Tool) is entirely external, but the subsequent staging of those tools generates File Creation events on victim endpoints at the moment of delivery.

Initial Access

T1566 (Phishing) is the leading initial access technique across threat intelligence reporting. On the endpoint, the signal appears in Process Creation telemetry: a document viewer or browser spawning an unexpected child process is the classic indicator. Microsoft Office spawning cmd.exe or wscript.exe is a pattern that has been exploited so reliably that it appears in detection rules across virtually every EDR platform. File Creation events show the initial payload drop. Registry modification events may show persistence being established in the same execution chain within seconds of the phishing document opening.

Execution

The Execution tactic (TA0002) is where endpoint telemetry becomes densest. T1059 sub-techniques covering PowerShell, Windows Command Shell, Python, JavaScript, and others all produce Process Creation events. T1047 (Windows Management Instrumentation) produces WMI activity in ETW that Sysmon Event ID 19, 20, and 21 are specifically designed to capture. T1053 (Scheduled Task/Job) produces registry writes and file writes to the %SystemRoot%\System32\Tasks directory. T1106 (Native API) execution produces OS API execution telemetry. The breadth of coverage is extensive, but it requires that the telemetry infrastructure is collecting at the right level of granularity — command-line argument logging must be enabled, and Script Block Logging for PowerShell must be configured.

Persistence and Privilege Escalation

T1547 (Boot or Logon Autostart Execution) produces registry modification events in the Run keys and registry writes to HKLM and HKCU. T1543 (Create or Modify System Process) produces service creation events visible through Windows Event ID 7045 and ETW. T1548 (Abuse Elevation Control Mechanism) — covering UAC bypass sub-techniques — produces process creation events with anomalous integrity levels relative to parent process integrity. The parent-child relationship in process creation telemetry is particularly revealing here: a medium-integrity parent spawning a high-integrity child without a visible UAC prompt is a strong indicator of privilege escalation.

Defense Evasion

Defense Evasion (TA0005) is the tactic with the largest number of techniques in ATT&CK, reflecting how much adversary effort goes into avoiding detection. Many sub-techniques here specifically target telemetry itself. T1562.001 (Impair Defenses: Disable or Modify Tools) produces process termination events as agents are killed, and registry modification events as security software configuration is altered. T1070.001 (Indicator Removal: Clear Windows Event Logs) produces Security Event ID 1102 (audit log cleared) and System Event ID 104. T1036 (Masquerading) is detected through process metadata telemetry: a process named svchost.exe running from a user's temp directory rather than System32 shows up as an anomaly in file path metadata associated with the process creation event.

Credential Access

T1003 (OS Credential Dumping) is one of the most telemetry-rich technique groups in ATT&CK. LSASS access — the primary signal for T1003.001 — is captured through Sysmon Event ID 10 (Process Access), which logs whenever one process opens a handle to another with specific access rights. A process requesting PROCESS_VM_READ access to lsass.exe is a high-fidelity signal regardless of what tool is used, which is precisely why this detection is considered living-off-the-land resistant. T1558 (Steal or Forge Kerberos Tickets) produces Windows Security Event ID 4769 (Kerberos Service Ticket request) anomalies that are detectable when volume and encryption type baselines are established — RC4-encrypted tickets in an environment configured for AES encryption is a classic Kerberoasting signal.

Lateral Movement, Collection, and Exfiltration

T1021 (Remote Services) lateral movement techniques produce Network Connection Creation events on both source and destination endpoints. SMB-based movement produces file access and process creation telemetry on the destination host. T1074 (Data Staged) produces file creation and file modification events as data is aggregated before exfiltration. T1048 (Exfiltration Over Alternative Protocol) produces network connection events to unusual destinations over unusual ports, correlatable back to specific processes through endpoint telemetry in a way that pure network monitoring cannot achieve.

The Coverage Problem: Why Many Orgs Are Flying Blind

MITRE itself has done significant work to measure the gap between available ATT&CK detection capability and what organizations actually have deployed. The ATT&CK Evaluations program — which tests EDR products against real adversary behavior simulations — consistently reveals both the strength of commercial telemetry tools and the importance of proper configuration. The 2024 ATT&CK Evaluations round (Enterprise 2024) was the most rigorous to date, introducing false positive testing for the first time and expanding platform coverage across Windows, Linux, and macOS. Emulated adversaries included ransomware-as-a-service behaviors modeled on CLOP and LockBit, and DPRK-attributed macOS attack chains. Results showed meaningful variance in technique-level detection and prevention rates across participating vendors, with configuration methodology and out-of-box tuning proving as consequential as platform selection.

CardinalOps' Fifth Annual Report on the State of SIEM Detection Risk, published in June 2025 and the largest such study ever conducted — drawing from 2.5 million total log sources, over 23,000 distinct log sources, and more than 13,000 unique detection rules across Splunk, Microsoft Sentinel, IBM QRadar, CrowdStrike Logscale, and Google SecOps — found that enterprise SIEMs have detection logic for only 21 percent of ATT&CK techniques used by adversaries, missing 79 percent. The gap was not a data availability problem: those SIEMs were already ingesting sufficient telemetry to potentially cover more than 90 percent of ATT&CK techniques. Approximately 13 percent of existing detection rules were found to be non-functional, unable to fire due to misconfigured data sources or missing log fields.

CardinalOps CEO Michael Mumcuoglu, commenting on the report's central finding, noted that enterprises have spent years accumulating telemetry but still lack the detection engineering to act on it. He argued that without automation, AI-assisted rule maintenance, and continuous detection health assessment, organizations will remain exposed even after deploying modern SIEM platforms. — Michael Mumcuoglu, CEO and Co-Founder, CardinalOps, Fifth Annual State of SIEM Detection Risk Report, June 2025

The coverage gap compounds because many organizations prioritize endpoint telemetry from workstations but underinstrument servers — precisely the systems adversaries target during lateral movement and privilege escalation. Domain controllers are the crown jewels of an Active Directory environment, yet they are often the least monitored endpoints from a behavioral telemetry perspective. T1207 (Rogue Domain Controller / DCShadow), for example, requires monitoring for Directory Service Changes events (Windows Security Event ID 4742 and 5137) on domain controllers specifically. If those events are not being forwarded to the SIEM, the technique is effectively invisible.

EDR, SIEM, and the Telemetry Pipeline

The operational architecture for consuming endpoint telemetry in an ATT&CK-aligned security program involves two distinct systems with different functions. The EDR platform is the collection and initial analysis layer: it ingests raw endpoint telemetry at high volume, correlates events across the process tree, and applies real-time behavioral detections. The SIEM is the correlation and investigation layer: it aggregates telemetry from EDR alongside identity, network, and cloud sources and applies detection logic that spans data sources and time windows beyond what an individual EDR sensor can see.

Neither replaces the other. An EDR platform that detects a credential dumping attempt generates an alert. But determining whether that alert is part of a broader campaign — correlated with anomalous authentication events from the identity provider, lateral movement indicators from network telemetry, and cloud API access anomalies — requires the SIEM to join data across sources. ATT&CK technique coverage is most complete when endpoint telemetry flows from EDR into SIEM in a structured format that preserves process relationship context.

The Sigma rule format, an open-source generic signature language for SIEM systems maintained on GitHub by the SigmaHQ organization, has become a practical standard for expressing ATT&CK-mapped detection logic in a vendor-neutral way. A Sigma rule for T1059.001 PowerShell execution encodes detection logic that can be compiled to query syntax for Splunk, Microsoft Sentinel, Elastic Security, or Chronicle, among others. The SigmaHQ repository currently contains over 3,000 rules, a substantial portion of which are explicitly tagged with ATT&CK technique IDs, making it a practical resource for organizations building ATT&CK-aligned detection coverage.

# Sigma rule excerpt: PowerShell suspicious parent process (T1059.001)
title: Suspicious PowerShell Parent Process
id: 6a5b8b42-ba95-4e2e-a3d9-7db57c2ea98a
status: test
description: Detects PowerShell spawned from suspicious parent processes
references:
    - https://attack.mitre.org/techniques/T1059/001/
tags:
    - attack.execution
    - attack.t1059.001
detection:
    selection:
        EventID: 1
        Image|endswith: '\powershell.exe'
        ParentImage|endswith:
            - '\winword.exe'
            - '\excel.exe'
            - '\outlook.exe'
            - '\mshta.exe'
    condition: selection
falsepositives:
    - Legitimate admin scripting triggered from Office macros
level: high

The practical implementation challenge is data volume. A single active endpoint generating process creation, network connection, file operation, and registry modification telemetry can produce millions of events per day. At enterprise scale, this creates significant ingestion cost and query performance pressure on the SIEM. The trend in the industry has been toward tiered telemetry architectures where EDR handles high-volume raw telemetry with local detections, and only enriched, higher-fidelity events flow into the SIEM for cross-source correlation. Microsoft Sentinel's connector for Microsoft Defender for Endpoint, for example, allows organizations to configure which event types flow upstream — avoiding the cost of forwarding all raw process creation events while preserving the enriched alert context.

Closing the Coverage Gap: Solutions That Go Beyond the Basics

Recommending that organizations "deploy EDR" and "enable Script Block Logging" is accurate but operationally insufficient. The CardinalOps finding — that enterprise SIEMs already ingest telemetry sufficient to cover more than 90 percent of ATT&CK techniques, yet cover only 21 percent in practice — is a diagnosis of an engineering and process failure, not an infrastructure one. The solutions that actually close the gap are harder and more specific than the generic advice that dominates most coverage of this problem.

Detection-as-Code with Continuous Validation Pipelines

The 13 percent non-functional rule finding from CardinalOps points to a maintenance failure that manual processes cannot fix at scale. Detection logic that was valid at deployment becomes broken when log source schemas change, when data normalization pipelines are updated, or when source systems shift versions. The solution is to treat detection rules as code — managed in version-controlled repositories (Git), validated against test data in CI/CD pipelines before deployment, and continuously tested in production through synthetic telemetry injection. Atomic Red Team, the open-source test framework maintained by Red Canary and mapped explicitly to ATT&CK techniques, provides a library of portable test procedures that simulate technique-specific telemetry without requiring an active adversary. Running Atomic Red Team tests against production telemetry pipelines on a scheduled basis produces a live measurement of which ATT&CK techniques your current rules actually detect — not which ones you have rules for on paper. That distinction is what the 13 percent non-functional rate reflects: rules that exist but cannot fire. A detection engineering program without synthetic test coverage cannot distinguish between the two states.

Telemetry Normalization at the Pipeline Layer, Not the Query Layer

Organizations running heterogeneous endpoint environments — Windows EDR alongside Linux eBPF sensors alongside macOS Endpoint Security Framework events — face a common problem: the same ATT&CK technique generates structurally different telemetry across platforms. When normalization is deferred to query time, each detection rule must implement platform-specific field mappings manually, multiplying rule maintenance burden and creating platform-specific blind spots. The OCSF (Open Cybersecurity Schema Framework), an industry initiative driven by AWS and a consortium of security vendors and now an open standard, provides a vendor-neutral event schema designed to normalize endpoint, network, and identity telemetry into a common field structure before it reaches the SIEM query layer. Deploying OCSF normalization at the data pipeline layer — rather than building per-platform logic into individual Sigma rules — means a single ATT&CK-aligned detection can fire against Windows, Linux, and macOS process creation events without per-platform variants. The operational difference is the distinction between detection engineering that scales and detection engineering that collapses under the weight of its own platform exceptions.

ATT&CK Coverage Gap Analysis as a Prioritization Instrument

Most organizations that do perform ATT&CK coverage gap analysis produce a spreadsheet: technique X has coverage, technique Y does not. That analysis is a starting point, not a prioritization framework. Coverage gaps vary enormously in operational consequence depending on which adversary groups target your sector, which techniques appear in your threat intelligence, and which techniques appear in multi-stage kill chains where a single gap voids coverage upstream and downstream. A more defensible prioritization approach combines ATT&CK coverage gap data with threat intelligence profile weighting. The MITRE ATT&CK Navigator, the free web-based layer customization tool, supports this directly: organizations can load threat actor profiles from MITRE ATT&CK (such as APT29, APT41, or Lazarus Group profiles), overlay them against their current detection coverage layer, and identify the specific techniques used by adversaries relevant to their sector that they are not currently detecting. The resulting gap list is materially shorter and operationally more relevant than a list of every undetected ATT&CK technique. Prioritizing closure of those gaps — rather than chasing overall coverage percentage — is what differentiates a detection program designed around real adversary behavior from one designed around a scorecard.

Detection Resilience Engineering Against Active Evasion

Writing a detection rule for T1003.001 (LSASS credential dumping) that fires on Sysmon Event ID 10 when a process requests PROCESS_VM_READ access to lsass.exe is table stakes detection. The adversary who studies your defensive tooling — and sophisticated actors do — will route around it using indirect syscalls that bypass user-mode hooks, using kernel-mode drivers that operate below the Sysmon layer, or using legitimate utilities like Task Manager or Windows Error Reporting that have historically been allowlisted. Detection resilience means designing rules with explicit analysis of which evasion paths are available for the technique, and adding secondary detections for those paths. For LSASS dumping specifically: monitoring for anomalous handle requests in kernel telemetry via EDR drivers, detecting the use of MiniDumpWriteDump via API call tracing, flagging lsass.exe memory access from processes with anomalous parent-child relationships, and monitoring for the downstream artifact — the dump file itself appearing in unexpected filesystem locations — provides overlapping coverage that requires the adversary to defeat multiple independent detection paths simultaneously. Single-path detection logic fails against a single evasion technique. Layered detection logic forces adversaries to achieve a much harder simultaneous bypass condition.

Telemetry Architecture for Cross-Tactic Kill Chain Detection

Many organizations build detection logic at the technique level — a rule for T1059.001, a rule for T1003.001, a rule for T1021.002. These rules catch individual technique instances. What they do not catch is a sequence of individually non-alerting behaviors that, in aggregate, constitute a complete intrusion. An adversary who uses a legitimate administrative tool for remote execution, accesses a non-sensitive file share for discovery, and requests Kerberos tickets for services that are technically within their access scope may not trip any individual technique rule — while executing a textbook lateral movement campaign. Cross-tactic kill chain detection requires that endpoint telemetry be stored in a queryable format with consistent entity identifiers — process GUIDs, account SIDs, host identifiers — that allow analysts to reconstruct the complete sequence of events across a dwell period. Platforms like Microsoft Sentinel's UEBA (User and Entity Behavior Analytics) engine, Elastic Security's correlation rules with sequence matching, and Splunk's Transaction command all provide primitives for this. But they require that telemetry from EDR, identity, and network sources share common entity identifiers that survive normalization — a pipeline design decision that is far upstream of rule writing. Organizations that design their telemetry pipelines for single-event detection will find that their SIEM cannot answer the question: "What did this account do across all endpoints between Day 0 and Day 30?" That question is the one that matters during incident response.

Instrumenting the Detection Infrastructure Itself

T1562.001 (Impair Defenses: Disable or Modify Tools) is reliably present in sophisticated intrusion campaigns because defenders rarely monitor the health of their own monitoring. An adversary who kills the EDR agent on a target host before executing credential dumping has, in effect, performed a targeted telemetry blackout. The standard recommendation to "monitor for agent heartbeat" misses a more operationally robust approach: treating telemetry volume itself as a behavioral baseline. Every instrumented endpoint in an enterprise produces a statistically predictable volume of process creation, network, and registry events over any given time window. An endpoint that drops from 10,000 events per hour to zero — without a corresponding system shutdown event — is not silent because nothing happened. It is silent because something was done to make it silent. SIEM-level alerting on per-endpoint telemetry volume anomalies, combined with tamper-protection enforcement on EDR agents and Group Policy auditing for Script Block Logging configuration changes, turns the detection infrastructure into a monitored surface rather than a trusted assumption. The organizations that discovered Salt Typhoon's presence in carrier networks did so partly because anomalous telemetry behavior on specific infrastructure pointed to collection impairment before any technique-specific alert fired.

What ATT&CK v18 Changes for Telemetry-Driven Detection

The October 2025 release of ATT&CK v18 introduced the most significant structural change to the framework's detection guidance since its public launch. Traditional "Detections" sections — which paired techniques with one or two sentences pointing to a data source — have been fully deprecated and replaced by two new structured objects: Detection Strategies and Analytics. This is not cosmetic. It fundamentally changes how the relationship between endpoint telemetry and ATT&CK technique detection is expressed.

Detection Strategies define the high-level behavioral approach to detecting a technique. They describe what an adversary's activity looks like in terms of observable system behavior, independent of any specific SIEM or EDR platform. Analytics sit below Detection Strategies and provide platform-specific, actionable detection logic — explicitly referencing log sources, data components, and the telemetry channels that produce the signals the analytic operates on. Critically, v18 added over 1,700 analytics across the Enterprise matrix, each structured with direct links to the telemetry components that feed them. For defenders, this means the framework now closes a gap it previously left open: you no longer have to infer the path from "collect this log source" to "here is how to write a detection." ATT&CK v18 makes that path explicit.

The v18 release also expanded the Enterprise matrix's platform scope to include ESXi, reflecting the documented rise in adversary targeting of VMware hypervisor infrastructure in ransomware and persistent access campaigns. This matters for endpoint telemetry architects because ESXi hosts present a fundamentally different instrumentation challenge than Windows or Linux workloads. The hypervisor layer sits below the guest operating systems, meaning EDR agents deployed inside virtual machines do not see host-level activity. Defending ESXi environments requires hypervisor-native telemetry through ESXi audit logs, vSphere events, and where available, agentless behavioral monitoring — a capability gap that v18 now explicitly documents through its new ESXi-specific technique entries.

Detection Strategies also connect behaviors across tactics in a way the older single-sentence detection notes could not. An adversary who uses Execution techniques (TA0002) to run a scheduled task is often simultaneously establishing Persistence (TA0003) through the same action. v18 Detection Strategies reflect this, enabling defenders to trace detection logic across tactical boundaries — which is how adversary behavior in real intrusions actually works. The implication for telemetry architecture is that cross-tactic detection requires telemetry that preserves temporal and causal context across the event stream, not just high-volume event collection.

How to Map Endpoint Telemetry to ATT&CK: A Prioritized Starting Sequence

The coverage gap documented by CardinalOps is an engineering and process failure, not an infrastructure one. The organizations that close it fastest work from a specific, sequenced collection roadmap rather than deploying broadly and hoping for coverage. Here is a defensible starting sequence for aligning endpoint telemetry collection with ATT&CK v18 detection requirements.

1. Enable process creation telemetry with full command-line arguments. Configure Windows Audit Process Creation alongside Sysmon Event ID 1. This single data source covers more ATT&CK techniques than any other — execution, persistence, privilege escalation, and defense evasion all produce process creation events. Command-line argument auditing is the non-negotiable component: without it, you see that a process ran, not what it did.
2. Enable PowerShell Script Block Logging (Event ID 4104). Configure this via Group Policy: Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell. Without it, T1059.001 detection is incomplete — you see powershell.exe executing but cannot examine what script it ran. This is one of the highest-frequency gaps in enterprise environments.
3. Deploy process access telemetry via Sysmon Event ID 10. This event fires when one process opens a handle to another with specific access rights. A process requesting PROCESS_VM_READ access to lsass.exe is the primary detection signal for credential dumping under T1003.001 — and it fires regardless of which tool is used, making it living-off-the-land resistant.
4. Instrument domain controllers with authentication and directory service telemetry. Windows Security Event ID 4769 (Kerberos Service Ticket requests) is required for detecting Kerberoasting under T1558.003. Directory Service Change events (Event IDs 4742 and 5137) are required for DCShadow detection under T1207. These events must be collected from domain controllers specifically — workstation telemetry will not substitute.
5. Map your current collection to ATT&CK v18 Analytics. Use the ATT&CK Data Sources page and the v18 Analytics library to identify which data components each high-priority technique requires. Each analytic specifies the exact log sources and telemetry fields that must be operational — use this as a gap checklist, not just a reference document.
6. Run ATT&CK coverage gap analysis in Navigator with threat actor overlays. Load the threat actor profiles for adversary groups relevant to your sector into MITRE ATT&CK Navigator. Overlay your current detection coverage layer against those profiles. The intersection of "techniques this actor uses" and "techniques you do not currently detect" is your prioritized closure list — shorter and operationally sharper than a generic ATT&CK coverage percentage.
7. Validate detection rules with synthetic telemetry using Atomic Red Team. Run Atomic Red Team tests against your production telemetry pipeline on a scheduled basis. This produces a live measurement of which ATT&CK techniques your detection rules actually detect — not which ones you have rules for on paper. The CardinalOps finding that 13% of SIEM rules are non-functional reflects exactly the gap this step closes.

Threat Hunting as Telemetry Interrogation

Automated detection logic — whether EDR behavioral rules or SIEM correlation rules — operates on known patterns. Threat hunting is the practice of proactively interrogating endpoint telemetry to find evidence of adversary activity that automated detections missed. ATT&CK provides the hypothesis framework: a hunter starts with a technique, identifies the telemetry sources it produces, and queries that telemetry for anomalies that fall below automated alert thresholds. For a structured look at how adversaries sequence these techniques end to end, see attacker playbooks — the same TTP chains that give hunters their starting hypotheses.

The PEAK Threat Hunting Framework, published by Splunk's security research team in 2023, formalizes this process into three hunt types: Hypothesis-Driven (starting from ATT&CK technique hypotheses), Baseline (establishing normal behavior profiles to surface anomalies), and Intel-Driven (starting from threat intelligence about specific adversary TTPs). In all three types, endpoint telemetry is the raw material being interrogated. The hypothesis for a Kerberoasting hunt (T1558.003) might be: "Are there endpoints on which service ticket requests for high-privilege accounts are being made by processes that do not normally request Kerberos tickets?" That question can only be answered if Kerberos ticket request telemetry — Windows Security Event ID 4769 — is being collected at high fidelity from domain controllers and is accessible to the hunter through a queryable platform.

The PEAK Threat Hunting Framework characterizes effective hunting as fundamentally a telemetry discipline. Hunters who understand exactly which signals each adversary technique generates — and who can construct precise queries against that telemetry — are positioned to find attackers before objectives are reached. — PEAK Threat Hunting Framework, Splunk Security Research, 2023

The practical discipline of threat hunting against ATT&CK techniques has also produced a significant body of publicly available hunting queries. The Elastic Detection Rules repository on GitHub, the Microsoft Sentinel community repository, and the Splunk Security Essentials app all contain ATT&CK-mapped hunting queries that analysts can use as starting points. Organizations at earlier stages of telemetry maturity can use these resources to understand what their current telemetry can and cannot answer — and to build a roadmap for closing coverage gaps.

How Adversaries Evade the Telemetry That Should Catch Them

ATT&CK coverage on paper does not mean an adversary will be caught. The framework describes what techniques produce detectable signals — but adversaries are aware of detection infrastructure and actively adapt to avoid tripping it. Understanding these adaptations is what separates detection programs that catch real intrusions from programs that perform well only in ATT&CK Evaluations scenarios.

Endpoint Telemetry in Cloud Workloads and Containers

The article so far has addressed telemetry in the context of traditional Windows, Linux, and macOS endpoints. But a growing share of enterprise infrastructure runs in cloud-native environments — ephemeral virtual machines, containerized workloads, and serverless functions — that behave differently from persistent endpoints in ways that create specific telemetry challenges against the ATT&CK matrix.

Cloud virtual machines running on AWS EC2, Azure Virtual Machines, or Google Compute Engine are, in principle, instrumentable with the same EDR agents and Sysmon-equivalent tooling as on-premises hosts. The challenge is operational: auto-scaling groups spin up and tear down instances without manual intervention, which means agent installation must be baked into machine images and telemetry pipelines must account for hosts that exist for minutes rather than months. ATT&CK techniques such as T1078 (Valid Accounts) are particularly common in cloud environments, but the signals they produce — authentication events from cloud identity providers like AWS IAM or Azure Entra ID — are not endpoint telemetry at all. They require cloud-native log sources (AWS CloudTrail, Azure Audit Logs) as a separate telemetry stream alongside endpoint agents on the instances themselves.

Containers present a more fundamental instrumentation challenge. A container shares the host kernel but does not expose the same event surfaces as a full operating system. A traditional EDR agent cannot be deployed inside a container image without significant overhead, and many container deployments are explicitly designed to be read-only and minimal. eBPF has emerged as the primary solution: eBPF-based sensors attached at the host kernel level observe all container activity — process creation, syscalls, network connections — without requiring an agent inside each container. MITRE has published ATT&CK for Containers coverage that maps techniques such as T1610 (Deploy Container) and T1611 (Escape to Host) to the specific telemetry sources relevant to containerized environments, including container orchestration audit logs from Kubernetes and host-level eBPF observations.

The telemetry retention question also becomes acute in ephemeral environments. On a persistent workstation, EDR platforms typically buffer telemetry locally and forward to the SIEM continuously. On a container that lives for forty seconds, buffered-but-not-forwarded telemetry is permanently lost when the container exits. This forces organizations to design telemetry architectures where streaming export is a first-class requirement — not an afterthought — and to explicitly map ATT&CK technique detection requirements to the telemetry sources available in their specific hosting model before gaps appear during an incident.

Key Takeaways

1. ATT&CK is also a sensor requirements document — and now a detection engineering document. Every technique entry includes data source mappings prescribing what telemetry must be operational to detect that technique. The ATT&CK v18 release (October 2025) went further, replacing vague detection notes with structured Detection Strategies and over 1,700 Analytics that explicitly link telemetry components to actionable detection logic. Using ATT&CK only as a threat catalog now leaves two of its most operationally useful dimensions unused.
2. Telemetry configuration matters as much as telemetry collection. PowerShell Script Block Logging, process command-line argument auditing, and Sysmon Event ID coverage for process access and process tampering are commonly unconfigured in enterprise deployments, creating blind spots for some of the highest-frequency ATT&CK techniques.
3. Server telemetry is not optional. Domain controllers, file servers, and database hosts are where post-compromise activity concentrates. ATT&CK coverage gaps on these systems represent the most operationally consequential instrumentation failures in most enterprise security programs.
4. The SIEM alone cannot do it. EDR and SIEM serve different functions in the telemetry pipeline. EDR provides real-time behavioral analysis on the host. SIEM provides cross-source correlation across extended time windows. Both are required for coverage of the full ATT&CK matrix.
5. Threat hunting closes the gap that automation cannot. Behavioral detections catch known patterns. Hunting interrogates telemetry for patterns not yet encoded in rules. ATT&CK technique hypotheses give hunters a structured starting point grounded in real adversary behavior rather than intuition alone.
6. Retention and infrastructure model are telemetry decisions, not storage decisions. Detecting adversary dwell time of weeks or months requires telemetry retained long enough to contain the initial intrusion. Cloud and containerized workloads require architecture-specific instrumentation — eBPF at the host kernel for containers, cloud API audit logs alongside endpoint agents for cloud VMs — because the telemetry surfaces differ fundamentally from traditional endpoints. ATT&CK coverage in hybrid environments is only as complete as the narrowest instrumented tier.
7. ATT&CK coverage percentages measure detection logic, not adversary detectability. Sophisticated adversaries adapt to known defensive tooling — using indirect syscalls to bypass Sysmon hooks, LOLBins to avoid hash-based detections, and targeting the telemetry infrastructure itself through T1562.001. A detection engineering program that treats ATT&CK coverage as the goal rather than a measurement instrument will be outpaced by adversaries who study the same framework. The coverage percentage is useful for identifying gaps; closing those gaps requires detection logic designed to be resilient to active evasion, not just technique presence.

The relationship between endpoint telemetry and MITRE ATT&CK is not incidental. It reflects a fundamental property of the operating environment: adversaries must interact with the operating system to accomplish their objectives, and those interactions produce observable artifacts. The framework's value to defenders is precisely that it translates observed adversary behavior into a structured map of detectable signals. Organizations that build their telemetry infrastructure around that map — rather than treating telemetry collection as a generic compliance requirement — are the ones positioned to find intrusions in hours rather than months.