Windows Event IDs Cheat Sheet: The 31 That Matter

A handful of Windows Event IDs carry most of the tier-1 signal. The authentication pair 4624 (successful logon) and 4625 (failed logon) anchor nearly every investigation; 4648 paired with a 4624 type 3 is the lateral-movement tell; 4688 or Sysmon 1 expose the process chains behind execution; 4768/4769 with RC4 encryption flag Kerberoasting; 7045 marks service-based persistence; and 1102 or 104 mean someone is clearing logs. Learn the story behind those and you cover the overwhelming majority of what a SIEM queue throws at you.

This cheat sheet maps all thirty-one IDs to the question each one answers in triage, with the exact fields to read and a few detection sketches you can adapt. Keep it open during your first months on shift; the recognition becomes automatic faster than you expect.

→ Jump to the master table below for the full reference.

The Master Table: 31 Windows Event IDs for SOC Analysts

The table below covers the Security channel (prefix 4xxx/5xxx), the System channel (7045, 104), and Sysmon events (vendor-provided, not built-in). For Sysmon to generate events, the Sysmon agent from Sysinternals must be deployed with a configuration such as the community SwiftOnSecurity Sysmon Config.

Authentication Events: Where Most Investigations Start

Event ID 4624 (Successful Logon) is the most frequently generated event in any Windows environment and the anchor for authentication triage. The most important field is LogonType. Type 2 is interactive (keyboard at the console). Type 3 is network (SMB, mapped drives). Type 10 is RemoteInteractive (RDP). Type 7 is unlock. A type 10 logon from an internal server IP to another internal server is not normal. That combination almost never appears in legitimate administrative workflows and is one of the clearest indicators of lateral movement via RDP.

Event ID 4625 (Failed Logon) carries its own diagnostic field: SubStatus. The value 0xC000006A means the correct username but wrong password. The value 0xC0000064 means the username does not exist. A wave of 0xC000006A failures across many accounts from one source IP is a password spray. A wave of 0xC0000064 failures suggests the attacker is enumerating accounts. Microsoft's documentation on 4625 SubStatus codes maps every value.

Below is a realistic 4625 XML payload as it would appear in a Splunk SIEM raw event view. Each field is annotated:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{...}" />
    <EventID>4625</EventID>                    <!-- Failed logon -->
    <TimeCreated SystemTime="2026-06-12T02:47:18.334Z" />
    <Computer>CORPDC01.corp.internal</Computer> <!-- Target: Domain Controller -->
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-0-0</Data>        <!-- Null SID = no prior session -->
    <Data Name="TargetUserName">j.hartley</Data>       <!-- Account being attacked -->
    <Data Name="TargetDomainName">CORP</Data>
    <Data Name="Status">0xC000006E</Data>              <!-- Account restriction -->
    <Data Name="SubStatus">0xC000006A</Data>           <!-- Wrong password -->
    <Data Name="LogonType">3</Data>                    <!-- Network logon (SMB/WMI) -->
    <Data Name="WorkstationName">-</Data>              <!-- Empty = remote, no workstation -->
    <Data Name="IpAddress">185.220.101.47</Data>       <!-- Source IP: Tor exit node -->
    <Data Name="IpPort">49218</Data>
    <Data Name="ProcessName">-</Data>
    <Data Name="AuthenticationPackageName">NTLM</Data> <!-- NTLM used, not Kerberos -->
  </EventData>
</Event>

Reading from the bottom up: NTLM authentication was used (not Kerberos), the source IP 185.220.101.47 has no legitimate relationship to the corporate domain, the logon type is 3 (network), and the SubStatus confirms the password was wrong. A single occurrence of this is noise. Twenty occurrences against twenty different accounts from the same IP in a three-minute window is a confirmed password spray.

Event ID 4648 (Logon with Explicit Credentials) fires whenever a process passes credentials other than those of the current session: RunAs, WMI remote execution, PsExec, and most lateral movement tools. The key correlation is 4648 on the source machine paired with 4624 (type 3) on the destination. That sequence in sequence is lateral movement.

Event ID 4672 (Special Privileges Assigned) fires immediately after a successful 4624 when the logon grants sensitive privileges including SeDebugPrivilege, SeTakeOwnershipPrivilege, and SeLoadDriverPrivilege. It does not fire for standard user logons, so its presence is meaningful. An attacker who has compromised an account that holds these privileges will generate 4672 consistently.

Kerberos Events: Detecting AS-REP Roasting and Kerberoasting

Event ID 4768 (Kerberos Authentication Service Request) records every request for a Ticket Granting Ticket. The encryption type field is the key indicator: value 0x17 means RC4-HMAC, which is a weaker cipher that Kerberos tickets can be requested with even from modern environments. AS-REP Roasting targets accounts with Kerberos pre-authentication disabled, and the resulting TGT is encrypted with the account's password hash. A burst of 4768 events with EncryptionType=0x17 across multiple accounts from one workstation is a strong Kerberoasting precursor.

Event ID 4769 (Kerberos Service Ticket Request) records requests for service tickets. Kerberoasting requests service tickets for accounts with Service Principal Names (SPNs), then cracks them offline. The signature is EncryptionType=0x17 combined with service account targets (accounts ending in svc, service, sql, or similar naming conventions). Microsoft's Kerberoasting detection guidance recommends alerting on any RC4 service ticket requests in environments that have been configured to prefer AES.

Event ID 4771 (Kerberos Pre-Authentication Failed) is the Kerberos equivalent of 4625 for domain accounts. High volume from one source indicates a password spray targeting Kerberos directly. This event only fires on the domain controller, so correlation requires collecting DC logs into your SIEM.

Account Manipulation Events

Event IDs 4720, 4722, 4724, 4728, 4732, 4740, 4756 all describe changes to the account landscape.

Event ID 4740 (User Account Locked Out) fires on the domain controller when an account reaches the lockout threshold defined in the domain password policy. The event records the source workstation that triggered the lockout, which is the critical field for triage. A single 4740 on one account is typically a user who has mistyped their password. Ten 4740 events across ten different accounts from the same source workstation within a two-minute window is an active password spray. Correlating 4740 with 4625 (failed logon) from the same source IP provides the full picture of the attempt: how many passwords were tried, which sub-status code the failures carried, and whether any lockout was followed by a successful 4624 (suggesting a password was found before the threshold was hit on some accounts). The highest-priority among these is any addition to privileged groups. Event 4728 fires when a member is added to a global security group such as Domain Admins. Event 4732 fires for local groups such as Administrators on a workstation or server. Event 4756 covers universal groups.

Event ID 4719 (System Audit Policy Changed) deserves special mention. Attackers who understand Windows auditing will disable the specific audit subcategories that generate the events listed in this article. A 4719 event showing any audit category being disabled during an active investigation is a clear defense-evasion indicator.

Process and Execution Events

Event ID 4688 (Process Created) is the built-in Windows equivalent of Sysmon 1. It requires enabling the "Audit Process Creation" policy and the "Include command line in process creation events" setting. Without that setting, the command line field is blank and the event loses most of its detection value. CISA's Windows Event Log guidance explicitly recommends enabling command-line logging as a baseline requirement.

Sysmon Event ID 1 (Process Creation) provides all the same information as 4688 plus the process hash, the parent command line, and a more reliable process GUID for correlation. If Sysmon is deployed, it replaces 4688 as the primary process creation source. The single most valuable detection in Sysmon 1 is suspicious parent-child process chains. Legitimate Word processes do not spawn cmd.exe. Legitimate browsers do not spawn powershell.exe. MITRE ATT&CK technique T1059 maps the common execution chains that generate these events.

A minimal detection logic sketch using SPL for suspicious parent-child chains in Sysmon data:

index=sysmon EventCode=1
| eval parent_child=ParentImage." -> ".Image
| search parent_child IN (
    "*.doc -> *\\cmd.exe",
    "*.docx -> *\\cmd.exe",
    "*\\winword.exe -> *\\powershell.exe",
    "*\\excel.exe -> *\\powershell.exe",
    "*\\outlook.exe -> *\\cmd.exe",
    "*\\mshta.exe -> *\\powershell.exe"
  )
| table _time, Computer, User, ParentImage, Image, CommandLine
| sort -_time

This query catches the most common malicious document macro and living-off-the-land execution patterns. Tune the IN list to your environment; a developer using Word macros for automation will need an exclusion. The SIGMA rule project maintains community-maintained detection rules in this format that you can translate to your SIEM's query language.

Event ID 7045 (New Service Installed) appears in the System log rather than Security. Attackers install services for persistence and for lateral movement via tools like PsExec (which drops a temporary service on the target). The critical field is ImagePath: legitimate services point to known system directories. A service with an ImagePath pointing to C:\Users\Public\, C:\Temp\, or a network UNC path is almost always malicious.

Log Tampering Events

Event ID 1102 and Event ID 104 are short events with an outsized triage priority.

Event ID 1102 (Audit Log Cleared) fires in the Security channel when that specific log is cleared. It records the account that performed the action. The NSA's event log monitoring guide treats 1102 as a tier-1 alert with no tuning exceptions: the Security log is cleared legitimately only in specific decommissioning and compliance workflows, and even those should generate a change ticket.

Event ID 104 (Event Log Cleared) fires in the System log and covers the clearing of any event log channel. An attacker who clears Sysmon's Microsoft-Windows-Sysmon/Operational channel, for example, generates a 104 rather than a 1102. Monitoring 104 across all channels catches comprehensive log-tampering attempts.

Lateral Movement Patterns

Lateral movement rarely generates a single obvious event. It generates a sequence. The most common sequence uses Events 4648, 4624, and 5140.

The attacker on the source machine executes a remote command via WMI or PsExec. The source machine generates Event 4648 (logon with explicit credentials, because the attacker is passing a harvested credential, not the current user's token). The destination machine generates Event 4624 type 3 (network logon) from the same credential. If the attacker then accesses file shares, the destination machine also generates Event 5140 (network share accessed). The combination of these three events in a short time window, with source and destination being peer workstations rather than a workstation and a server, is lateral movement with high confidence.

Event 5145 (Share Object Access Checked) provides the file-level detail behind 5140. It is extremely noisy in environments with active file server access, so most teams apply it only to high-value shares (containing credentials, financial data, or source code) rather than enabling it globally.

PowerShell Events

Event IDs 4103 and 4104 live in the Windows PowerShell or Microsoft-Windows-PowerShell/Operational channels, not the Security channel. They require enabling PowerShell Script Block Logging via Group Policy.

Event 4103 (Module Logging) records each module that PowerShell loads. Event 4104 (Script Block Logging) is the more valuable of the two: it captures the deobfuscated content of every script block that PowerShell executes, regardless of how the attacker encoded it on disk. An attacker who uses Invoke-Expression with a base64-encoded payload will have the decoded payload captured in 4104. The PowerShell security guidance from the NSA and CISA recommends both module logging and script block logging as baseline requirements.

The events to watch within 4104: Invoke-Mimikatz, Invoke-Bloodhound, Net.WebClient with a DownloadString or DownloadFile method, and any use of -EncodedCommand. These strings in 4104 payloads are direct matches for known post-exploitation frameworks.

Putting It Together: Building the Habit

Knowing these event IDs by number matters less than understanding the story each one tells. When you see a 4625, you ask about volume, sub-status, and the target account's sensitivity. When you see a 4728, you ask who performed the action and whether there is a change ticket. When you see a 1102, you escalate.

The practical workflow is to keep this table open during your first months of shift work. Over time, the IDs become pattern recognition rather than lookup. What turns the lookup into instinct is repetition: seeing 4625 in volume, 4648 chained to a 4624 type 3, a stray 7045 with a suspicious ImagePath — in context and in combination — until the shape of an attack reads as fast as the shape of a word. Training operations provides realistic Windows event queues where these exact IDs appear in live investigation scenarios, which is the fastest way to build that recognition without waiting for a production incident.

Bookmark this page as a reference. When you need the frameworks for turning raw event data into a verdicted ticket, alert triage covers them in full, and SOC analyst interview questions includes the event-based scenarios hiring managers lean on at the tier-1 level.