Windows Event ID Mapping to MITRE ATT&CK Techniques: A Detection Reference

Overview

A good windows event id MITRE ATT&CK reference is not a static table. It is a working detection document that helps answer four recurring questions:

• Which Windows events support visibility for a specific ATT&CK technique?
• Which events are only supporting context rather than direct evidence?
• Which techniques require telemetry beyond the default Security log?
• Which mappings should be reviewed after tuning, onboarding, or lab validation?

This is where many teams get stuck. They know Event ID 4688 is useful for process creation, 4624 matters for logons, and 7045 can surface service installation. But useful detection work usually depends on combinations of events, host context, and enriched data such as command lines, parent processes, script block logging, Sysmon telemetry, PowerShell logs, EDR process trees, or identity sign-in records.

That means a mapping reference should be treated as a layered model:

1. Technique: the ATT&CK behavior you want to monitor.
2. Primary evidence: the event or telemetry source most directly tied to the activity.
3. Supporting evidence: related events that improve confidence, scoping, or triage.
4. Gaps: places where the Event ID alone is too weak, absent, or noisy.
5. Validation path: a safe lab test or telemetry review process used to confirm the mapping still works.

For example, credential access, persistence, and lateral movement often require multiple data sources. A single event may suggest suspicious behavior, but it rarely explains technique, intent, and impact by itself. That is why the best detection data source mapping work starts with ATT&CK technique goals and then traces backward into the logs that can support those goals.

As a practical rule, split your mapping into three telemetry groups:

• Windows Security log: authentication, account changes, process creation if enabled, object access in some scenarios.
• Windows operational and application logs: PowerShell, Task Scheduler, WMI, Defender, Sysmon, and service-related providers.
• Endpoint and SIEM enrichment: EDR/XDR data, asset role, user context, baseline behavior, and correlation logic.

If you keep those groups separate in your documentation, it becomes easier to explain why some ATT&CK techniques are easy to map and others remain weak until additional logging is enabled.

What to track

The most useful mitre attack windows logs references track categories of activity rather than isolated IDs. Below is a practical structure you can revisit during monthly or quarterly telemetry reviews.

1. Logon and identity activity

These events help with initial access follow-on analysis, valid account use, remote access review, and lateral movement investigations.

• 4624 — successful logon. Useful for logon type, source context, and account usage patterns.
• 4625 — failed logon. Useful for brute-force patterns, password spray indicators, and noisy service failures that need tuning.
• 4634 and 4647 — logoff events. Helpful for session timing and user activity windows.
• 4648 — explicit credentials used to attempt logon. Valuable in lateral movement detection and suspicious run-as style activity.
• 4672 — special privileges assigned to new logon. High-value context for administrator and privileged account review.
• 4768, 4769, 4771, 4776 — Kerberos and credential validation events. Often central to account abuse and authentication anomaly analysis.

These events can support ATT&CK techniques related to valid accounts, remote services, account discovery, and lateral movement. On their own, though, they usually describe access patterns, not the exact post-authentication behavior. That is why pairing them with host-level process and service telemetry matters.

2. Process execution and command activity

Process telemetry is one of the most broadly useful areas in any windows telemetry reference.

• 4688 — new process creation, when configured with command-line visibility.
• 4689 — process termination, useful but generally secondary.
• Sysmon 1 — process creation with richer fields in many environments.
• PowerShell 4103 and 4104 — module logging and script block logging for script-based behaviors.

These logs support ATT&CK techniques involving command and scripting interpreters, LOLBins, encoded commands, execution chains, suspicious parent-child relationships, and many forms of defense evasion. If your team regularly validates PowerShell or command shell detections, see Encoded Command Detection in PowerShell and CMD: Logs, Rules, and Safe Test Cases.

Tracking notes for this category should include:

• Whether command-line logging is enabled and retained
• Whether parent process visibility is available
• Whether script content is captured in a controlled and privacy-aware way
• Which binaries are expected to be common in your environment

3. Service and scheduled task persistence

Persistence and execution often leave useful traces in service and task-related logs.

• 4697 — service installed in the system audit stream where available
• 7045 — a service was installed on the system
• 4698, 4699, 4700, 4701, 4702 — scheduled task creation, deletion, enablement, disablement, and update
• Task Scheduler operational logs — often useful for execution history and troubleshooting

These can map to ATT&CK techniques for scheduled task or job abuse and service-based persistence or execution. If your team is building a soc validation lab around recurring persistence checks, review Scheduled Task Persistence Detection: Safe Payloads, Event Logs, and Response Playbooks.

4. Account and group changes

Privilege escalation and persistence sometimes show up first as account administration changes rather than process indicators.

• 4720 — user account created
• 4722, 4725, 4726 — account enabled, disabled, deleted
• 4728, 4732, 4756 — member added to privileged groups
• 4738 — user account changed

These are useful for tracking ATT&CK techniques involving account manipulation, valid account persistence, and privilege changes. Their value increases substantially when you enrich them with actor identity, host role, ticketing context, and change management records.

5. Registry, WMI, and system configuration changes

Many ATT&CK techniques depend on configuration abuse. Default Windows event coverage can be limited here, so your reference should clearly note where Sysmon, operational logs, or EDR fills the gap.

• Sysmon 12, 13, 14 — registry object create, value set, and rename events where deployed
• WMI-Activity operational logs — useful for WMI execution and persistence visibility
• Relevant Security auditing — available in narrower object access scenarios, but often not broad enough alone

For recurring review, keep separate notes for registry persistence, WMI execution, and event consumer style activity. Related guides include WMI Detection Lab: Safe Execution Scenarios, Event Sources, and Analytics and Safe Registry Persistence Tests: Telemetry, Detection Logic, and Hardening Steps.

6. Network, remote execution, and lateral movement context

Windows Event IDs can help here, but they often need to be correlated with endpoint or network telemetry.

• 4624 logon types — especially remote interactive, network, and service logons
• 4648 — explicit credentials use
• 5140 and related file share access events — useful in some lateral movement and staging scenarios
• 7045 or remote service creation patterns — possible evidence of remote execution
• WMI and PowerShell operational logs — useful supporting context for remote administration behaviors

When documenting these mappings, note that many events show administration as well as abuse. That makes baseline tracking essential. A spike in a remote admin event on a domain controller means something different than the same event on an IT jump host.

Cadence and checkpoints

A reference like this only stays accurate if it is reviewed on a schedule. For most teams, a monthly quick review and a quarterly deeper review is enough.

Monthly checkpoints

• Verify that key Event IDs are still being ingested into the SIEM or data lake
• Check field completeness for high-value logs such as 4688, 4624, 7045, PowerShell, and Sysmon process creation
• Review recent detection rules mapped to ATT&CK and confirm the expected event source still exists
• Compare recent benign lab activity to production detections and note silent failures or noisy rules
• Document any systems where logging was disabled, changed, filtered, or redirected

Quarterly checkpoints

• Revisit your ATT&CK-to-event matrix and score each technique as strong, partial, weak, or unvalidated
• Retest one or two safe emulation scenarios for each major coverage area: execution, persistence, credential access, and lateral movement
• Review false positives by event source rather than by rule name only
• Update analyst runbooks with event-specific triage guidance
• Confirm that parsing, normalization, and enrichment still preserve critical fields

This is also a good time to validate event sources with targeted labs. If you are testing LOLBins, service creation, or process ancestry, pair this article with Safe LOLBin Payloads by Binary: Defender Testing Matrix for Certutil, Mshta, Regsvr32, and More and Rundll32 Detection Engineering: Benign Test Cases and Telemetry Baselines.

What your checklist should capture

A simple spreadsheet or internal wiki page is usually enough. For each ATT&CK technique or sub-technique, track:

• Technique name and ATT&CK ID
• Primary Windows Event IDs
• Secondary telemetry sources
• Required fields
• Known blind spots
• Detection rules tied to the telemetry
• Safe validation scenario
• Last reviewed date
• Owner

That last-reviewed field is what turns a static article into a living event id mapping threat detection reference.

How to interpret changes

Changes in your event mapping usually point to one of four realities: logging drift, environmental change, content maturity, or detection gaps.

1. More events do not always mean better coverage

If volume rises sharply for a mapped Event ID, that may mean a new audit policy, a parser change, or normal business growth. It does not automatically mean better detection. Ask whether the increase improves useful signal or simply adds noise that makes triage slower.

2. Missing events often reveal pipeline problems before they reveal attacker stealth

When a once-reliable event source goes quiet, first check collection, forwarding, filtering, and normalization. Many teams initially interpret a drop in events as a behavior change when the real problem is telemetry loss.

3. Strong mappings usually rely on combinations

An ATT&CK technique marked as covered because one Event ID exists in the environment is often over-scored. Better scoring asks whether the technique can be detected with enough precision to support analyst action. For instance:

• Weak: one broad event with little context
• Partial: primary event plus some host or user context
• Strong: direct telemetry, key fields, enrichment, and a validated rule or hunting pattern

That framework helps with false positive reduction detection engineering because it shifts the conversation from event presence to analytical usefulness.

4. ATT&CK coverage should be interpreted by asset role

The same Windows Event ID has very different meaning depending on where it appears. Service creation on a developer workstation, a print server, and a domain controller should not be triaged the same way. Your mapping should include role-aware notes for:

• User endpoints
• Servers
• Identity infrastructure
• Jump hosts and admin workstations
• Golden images and ephemeral systems

Role-aware mapping is often the missing layer between a technically correct event correlation and a useful detection.

5. Safe validation should influence tuning

When your purple team lab or safe payload test produces expected events but no alert, the issue may be logic, thresholds, suppression, or missing enrichment. When it produces too many alerts, the issue may be baseline assumptions or insufficient scoping. Either way, the event mapping document should record the lesson learned and link back to the relevant content.

For example, if process execution and memory-related telemetry are central to your use case, Process Injection Detection Guide: Safe Simulations, Data Sources, and False Positive Tuning offers a useful companion for separating weak evidence from stronger multi-source coverage.

When to revisit

The best time to revisit this reference is before a gap becomes visible during an incident. In practice, revisit your Windows-to-ATT&CK mapping when any of the following happens:

• A new logging policy, GPO, or Sysmon configuration is deployed
• Your SIEM parser, schema, or normalization pipeline changes
• An EDR rollout adds or removes overlapping telemetry
• You create or retire a high-value detection rule
• A safe emulation test fails to produce expected events
• An analyst repeatedly reports missing context during triage
• You onboard a new server role, admin toolset, or remote management workflow
• You complete a monthly or quarterly telemetry review cycle

To make this practical, end each review with a short action list:

1. Pick three ATT&CK techniques that matter most to your environment.
2. Confirm the primary and secondary Windows events for each.
3. Check whether the required fields are present and searchable.
4. Run or review a safe validation scenario.
5. Update your coverage status and note gaps.
6. Assign an owner and next review date.

If you want to extend this work into analytics, hunting, and content validation, the next useful reads are Defender XDR Hunting Queries for Safe Adversary Emulation Labs and Elastic Detection Rules for Endpoint Telemetry: Safe Tests and Coverage Gaps.

A Windows event mapping reference is most valuable when it stays modest in its claims and disciplined in its updates. Treat Event IDs as evidence sources, not verdicts. Tie them to ATT&CK techniques, track their quality over time, and revisit them on a schedule. That habit turns ordinary log review into a durable detection engineering practice.