Event logs are commonly one of the first places analysts turn to during triage. When they are available (and properly configured), few artifacts on a Windows host are as rich. This cheatsheet groups commonly referenced event IDs by the investigative question they help answer.

Interpreting event IDs #

A log channel (Windows sometimes calls it a provider) is the named event log that an event is written to: Security, System, Application, or one of the many Microsoft-Windows-* channels like Microsoft-Windows-PowerShell/Operational.

Windows event IDs are not unique. The same integer can mean very different things depending on the provider that emitted it. For example, event ID 104 in the System log (via the Microsoft-Windows-Eventlog provider) means the log file was cleared, a high-signal anti-forensics indicator (T1070.001).

The same integer 104 appears in other channels (for example, Microsoft-Windows-TaskScheduler/Operational) with a completely unrelated meaning. Because of this, every row in this cheatsheet pairs the channel (or provider) with the numeric ID.

Authentication and logon #

These Security events can help answer who touched the host, how they authenticated (console, network, RDP, runas, etc.), and when they came and went. Together with the logon-type codes, they are often a great place to look when reconstructing attacker access or validating insider activity.

LogonType reference for 4624 / 4625 #

The LogonType field records how the authentication happened. Without it, a raw 4624 cannot distinguish a human logon from a service start or a network auth.

For the full field-by-field reference, see Microsoft’s documentation on event 4624 and event 4625.

Domain authentication (Domain Controllers) #

Domain Controllers broker Kerberos and NTLM authentication for the whole domain, so these events are a useful hunting ground for ticket abuse (golden/silver), Kerberoasting, AS-REP roasting, NTLM validation traces, and password-spray activity.

Account and group management #

These events track lifecycle changes to accounts and group membership, which makes them a reliable signal for persistence (attacker-created accounts), privilege escalation (additions to Administrators or Remote Desktop Users), and identity-object tampering.

They live in the Security log, on a Domain Controller for domain objects or on the local host for local accounts.

Process execution #

Process execution events can record details such as the binary, command-line arguments, user context, and parent process for each new process on the host. They can help reconstruct execution timelines, hunt living-off-the-land abuse, and flag anomalous parent-child relationships.

Windows can be configured to record process creation as event ID 4688 in the Security channel.

Sysmon, part of the Sysinternals suite, can be installed to provide richer and more configurable process-creation telemetry under event ID 1 in Microsoft-Windows-Sysmon/Operational.

Note: Process execution and command-line auditing are not enabled on Windows by default.

PowerShell activity #

PowerShell telemetry is split across two providers:

• The modern Microsoft-Windows-PowerShell/Operational channel
• The legacy Windows PowerShell log

Script block logging (Microsoft-Windows-PowerShell/Operational 4104) is the highest-signal event for post-exploitation because it captures the decoded script text even when the attacker delivered it obfuscated or base64-encoded.

Note: The high-value modern PowerShell events (4103, 4104, 4105 / 4106) are not enabled by default.

Services and drivers #

Services run as SYSTEM and survive reboots, which makes them a popular landing spot for persistence and privilege escalation. Driver loads are worth watching for the same reason: a malicious or vulnerable driver gives an attacker kernel-level execution and a foothold that survives most remediation short of reimaging.

Scheduled tasks #

Scheduled tasks are a favourite persistence and privilege-escalation mechanism (T1053.005) because they run on a trigger, can execute as SYSTEM, and survive reboots.

Lifecycle events live in the Security log:

Note: These Security events depend on Audit Other Object Access Events, which is off by default, so they are often missing.

Execution-level detail (registration, action start, per-task PID) surfaces in Microsoft-Windows-TaskScheduler/Operational:

Remote access and lateral movement #

Once an attacker has a foothold, they usually need to reach other hosts to escalate impact or move toward higher-value targets. Each remote-access transport (RDP, SMB, WinRM, and others) writes to its own channel, so reconstructing the movement path typically means correlating events across several logs by timestamp, source IP, and account.

RDP #

RDP activity is split across two Terminal Services channels:

• RemoteConnectionManager/Operational handles the initial network-level authentication to the listener
• LocalSessionManager/Operational records the full lifecycle of the resulting session (logon, shell start, disconnect, reconnect, logoff).

Correlating events across both is usually necessary to reconstruct a full RDP session.

SMB / file shares #

SMB is a common lateral-movement vector (admin shares like ADMIN$ and C$, tool staging, psexec-style service installs over the network) and all of the relevant activity lands in the Security log.

WinRM / PowerShell Remoting #

WinRM carries Invoke-Command, Enter-PSSession, and the WS-Management protocol underneath them, making it a frequent vehicle for interactive lateral movement without dropping a shell on the remote host.

Connection-level activity shows up in Microsoft-Windows-WinRM/Operational, but the actual commands run over the session are logged on the target side via the PowerShell events covered earlier (Microsoft-Windows-PowerShell/Operational 4104 in particular).

You typically need both sides of the coin to reconstruct what an attacker did.

Defense evasion and log tampering #

Log tampering is one of the strongest single indicators of deliberate attacker activity, since log clears, audit-policy changes, and logging-service shutdowns rarely have benign causes on a production host.

Associated ATT&CK coverage: T1070.001 (Clear Windows Event Logs), T1562.002 (Disable Windows Event Logging).

Microsoft Defender #

Defender activity is logged to Microsoft-Windows-Windows Defender/Operational and captures both malware detections and configuration changes. The configuration events are often the higher-signal half for DFIR, since disabling real-time protection or tampering with Defender settings is a well-known pre-ransomware staging step.

Microsoft publishes the complete Defender Antivirus event ID reference with full field-level detail for every event.

Windows Firewall #

Firewall rule and profile changes surface in the Microsoft-Windows-Windows Firewall With Advanced Security/Firewall event log and can be a strong lateral-movement indicator. Attackers routinely add inbound rules to open SMB, RDP, or WinRM for pivoting, disable profiles, or allow outbound traffic to stage C2 (T1562.004).

AppLocker #

AppLocker is the built-in Windows application control feature, and its events are split across four sub-channels under Microsoft-Windows-AppLocker/*:

• Microsoft-Windows-AppLocker/EXE and DLL
• Microsoft-Windows-AppLocker/MSI and Script
• Microsoft-Windows-AppLocker/Packaged app-Deployment
• Microsoft-Windows-AppLocker/Packaged app-Execution

Even in audit-only mode these events reveal what users and attackers attempted to run, which makes them valuable forensic breadcrumbs regardless of whether enforcement is turned on.

Sysmon essentials #

Sysmon (System Monitor) is a Sysinternals tool that extends Windows’ native logging with detailed process, network, file, registry, and image-load telemetry, and it is arguably the single most valuable telemetry source on a Windows host once properly configured.

Sysmon events are found in Microsoft-Windows-Sysmon/Operational, but default installs provide little investigative value. Community baselines like SwiftOnSecurity’s sysmon-config and Olaf Hartong’s sysmon-modular are a very approachable starting point for organizations of any size.

SwiftOnSecurity/sysmon-configPublic

Sysmon configuration file template with default high-quality event tracing

5.5k1.8k

olafhartong/sysmon-modularPublic

A repository of sysmon configuration modules

PowerShell3.0k645

For the complete list of Sysmon event IDs, see the Sysmon documentation.

References #

• MITRE ATT&CK: attack.mitre.org
• Microsoft Security Auditing reference: learn.microsoft.com/windows/security/threat-protection/auditing/
• JPCERT/CC, Detecting Lateral Movement through Tracking Event Logs: jpcert.or.jp/english/pub/sr/ir_research.html
• Sysmon documentation: learn.microsoft.com/sysinternals/downloads/sysmon
• SwiftOnSecurity Sysmon config: github.com/SwiftOnSecurity/sysmon-config
• Olaf Hartong, sysmon-modular: github.com/olafhartong/sysmon-modular
• Microsoft Learn, 4946(S): A rule was added to the Windows Firewall exception list: learn.microsoft.com/…/event-4946
• Ultimate Windows Security, Event ID 4948, rule deleted: ultimatewindowssecurity.com/…/event.aspx?eventid=4948
• Sigma / Detection.FYI, A rule has been deleted from the Windows Firewall exception list: detection.fyi/…/win_firewall_as_delete_rule
• Microsoft Learn, 4624(S): An account was successfully logged on: learn.microsoft.com/…/event-4624
• Microsoft Learn, 4625(F): An account failed to log on: learn.microsoft.com/…/event-4625
• Microsoft Support, PowerShell 2.0 removal from Windows: support.microsoft.com/…/powershell-2-0-removal
• Microsoft Learn, Microsoft recommended driver block rules: learn.microsoft.com/…/microsoft-recommended-driver-block-rules
• Microsoft Learn, Just Enough Administration (JEA) overview: learn.microsoft.com/…/jea/overview
• Microsoft Learn, Troubleshoot Microsoft Defender Antivirus event IDs: learn.microsoft.com/…/troubleshoot-microsoft-defender-antivirus
• Microsoft Learn, AppLocker overview: learn.microsoft.com/…/applocker-overview
• Microsoft Tech Community, Native Sysmon functionality coming to Windows: techcommunity.microsoft.com/…/4468112