Windows security event IDs that matter

Windows logs hundreds of event IDs. A few dozen answer almost every investigation question. This reference lists those, what each one means, the fields that matter and the pitfalls that trip up analysts. It complements the audit policy and Sysmon baseline, which covers which audit subcategories to turn on. Here, the focus is on reading and using what they produce.

Unless noted, events are in the Security log. Events from domain controllers are marked DC.

Logon types

Event 4624 (and 4625) carries a Logon Type that tells you how someone logged on. Learn these before anything else:

Type 3 logons by admin accounts to workstations, type 10 to servers from non-admin hosts, and type 9 anywhere outside admin workstations are all worth a second look.

Authentication and sessions

Correlate 4624 and 4672 by Logon ID: that shows which logons were privileged. Authentication Package NTLM with Package Name NTLM V1 should not exist in a modern network. Audit and phase it out as part of your NTLM restriction work.

For 4625, the Sub Status tells you why:

Many 0xC0000064 failures from one source mean someone is guessing account names. Many 0xC000006A failures across different accounts from one source mean password spraying. Repeated 0xC000015B for admin accounts on workstations is often your tiering restrictions working as designed.

Domain controllers: Kerberos and NTLM

Encryption types in 4768/4769: 0x11 is AES128, 0x12 is AES256, 0x17 is RC4. As domains move away from RC4, any remaining 0x17 tickets point to accounts or services that need fixing. On Windows Server 2019 and later, and on Server 2016 since the January 2025 cumulative update, 4768 and 4769 also carry MSDS-SupportedEncryptionTypes, Available Keys, Advertized Etypes (what the client offered) and Session Encryption Type. These fields show whether an account or client can do AES before you disable RC4.

Directory and account changes

Alert on 4728, 4732 and 4756 when the group is privileged: Domain Admins, Enterprise Admins, Administrators, Account Operators, Backup Operators, DnsAdmins, Group Policy Creator Owners and your own Tier 0 groups.

DCSync appears as 4662 on a DC where the properties include the replication rights GUIDs 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 (Get-Changes) and 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (Get-Changes-All), requested by an account that is not a domain controller.

Execution and persistence

The task XML in 4698 includes the command the task runs: read it, don't just count events. For process-level detail beyond 4688, see Sysmon deployment and tuning.

Tampering and policy changes

Each of these should be rare. 1102, 104 and 4719 outside a change window are strong indicators on their own. Defender events are covered in more depth in Microsoft Defender Antivirus hardening.

Remote access and PowerShell

RDP leaves traces in three places (Security 4624 type 10, 1149 and 21). If one is missing, you still have the others. Harden the service itself with the RDP hardening guide. For PowerShell hunting patterns, see detecting malicious PowerShell.

Querying the events

Get-WinEvent with a filter hashtable is fast because filtering happens in the event log service:

# Failed logons in the last 24 hours, grouped by account, source and reason
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4625; StartTime = (Get-Date).AddDays(-1) } |
  ForEach-Object {
    $d = @{}; ([xml]$_.ToXml()).Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{ Account = $d.TargetUserName; Source = $d.IpAddress; SubStatus = $d.SubStatus }
  } | Group-Object Account, Source, SubStatus | Sort-Object Count -Descending | Select-Object -First 20 Count, Name

To filter on event data fields, use XPath:

# RDP logons
Get-WinEvent -LogName Security -MaxEvents 50 `
  -FilterXPath "*[System[EventID=4624] and EventData[Data[@Name='LogonType']='10']]"

# RC4 service tickets on a DC
Get-WinEvent -LogName Security -MaxEvents 100 `
  -FilterXPath "*[System[EventID=4769] and EventData[Data[@Name='TicketEncryptionType']='0x17']]"

Local queries are for investigation and testing. For detection, send these events to a central store with Windows Event Forwarding or an agent.

What breaks

• Missing events usually mean the subcategory is off, the log wrapped, or a SACL is missing. auditpol /get /category:* shows the effective policy.
• Volume: 4624, 4634, 4688, 4769 and 5140 are high-volume on servers and DCs. Collect them, but alert on aggregates and anomalies rather than single events.
• Misread fields: 4624 on a server lists the server's view; the source address may be a NAT, a proxy or empty for local logons. 4740 appears on domain controllers, not on the client.
• Localised messages: parse fields from the event XML, not from the rendered message text, which changes with the OS language.

Verify it

On a test machine and a test DC, generate a few events and confirm they are logged and forwarded: a failed logon with a wrong password (4625, 0xC000006A), a test user added to a test group (4732 or 4728), a scheduled task created with Register-ScheduledTask (4698) and a service created with New-Service (7045, 4697). Remove the test objects afterwards. If an event doesn't appear, fix the audit policy before building detections on it. More on the logging stack on the audit and logging topic page.

Checklist

• Logon types and 4625 sub-status codes known by every analyst
• Audit subcategories and SACLs in place so each listed event can actually fire
• Alerts on 1102, 104, 4719, 7045/4697, privileged group changes and Defender 5001/5013
• Kerberos monitoring on DCs: RC4 tickets, pre-authentication disabled, 4771 spikes
• DCSync detection via 4662 replication GUIDs from non-DC accounts
• Task Scheduler Operational log enabled; RDP logs collected
• Queries parse event XML fields, not rendered messages
• Test events generated and confirmed end-to-end after every policy change