Windows Event ID Library
Every reference here is built for detection work, not trivia: the real Microsoft field tables, a simulated log sample you can copy, the status codes decoded, and SIEM queries you can run as written. Each page links to hands-on practice in SOCSimulator Operations.
System
The audit log was cleared
Event ID 1102 records that someone cleared the Windows Security event log. Microsoft's own guidance is blunt: you should almost never see this event, and every occurrence deserves investigation. The event names the account (SubjectUserName, SubjectDomainName) and the SubjectLogonId that performed the clear, which is your starting point for tracing who did it and why.
Read the reference 7045A service was installed in the system
Event ID 7045 is logged by the Service Control Manager to the System log every time a new service is registered on a Windows host, whether by an installer, an admin using sc.exe, or an attacker using PsExec-style remote execution. It records the service name, image path, start mode, and account.
Read the referenceApplication
Creating Scriptblock text
Event ID 4104 is the Windows PowerShell Script Block Logging event, written to the Microsoft-Windows-PowerShell/Operational channel whenever PowerShell compiles a script block. It captures the full, deobfuscated code, including decoded Base64 and reconstructed download-and-execute chains, making it one of the richest sources for hunting fileless PowerShell activity.
Read the reference 4103Executing Pipeline (Module Logging)
Event ID 4103 fires from PowerShell Module Logging: it records the cmdlet name, who ran it, and the parameters passed, independent of whether Script Block Logging (4104) is enabled. On a host where 4104 was never turned on, 4103 is frequently the only PowerShell telemetry a SOC has at all.
Read the referenceLogon/Logoff
An account was successfully logged on
Event ID 4624 is the Windows Security log entry generated on the destination machine every time a logon session is created successfully, regardless of logon method. It fires for interactive desktop logons, network share access, RDP sessions, scheduled task execution, and service starts alike, so the Logon Type field is what actually tells an analyst what happened.
Read the reference 4625An account failed to log on
Event ID 4625 is the Windows Security log entry generated on the Audit Logon and Audit Account Lockout subcategories whenever a logon attempt fails, whether from a wrong password, a locked account, or a disabled one. It fires on the machine where the attempt happened and carries a Status/SubStatus code pair that tells you why the logon was rejected.
Read the reference 4648A logon was attempted using explicit credentials
Event ID 4648 fires when a process explicitly supplies a different account's credentials instead of using the caller's own logon session, most often through runas, scheduled tasks with stored credentials, or net use with /user:. It logs three identities at once: who initiated the action, whose credentials got used, and which server the new process ran on.
Read the reference 4672Special privileges assigned to new logon
Event ID 4672 (Security log, Audit Special Logon subcategory) records that a new logon session was handed one or more sensitive Windows privileges, such as SeDebugPrivilege or SeBackupPrivilege. It fires immediately after a matching 4624 logon. Most instances come from SYSTEM and service accounts; the ones worth chasing are standard or service accounts receiving privileges they have never held before.
Read the reference 4634An account was logged off
Event ID 4634 records that a Windows logon session ended. It shares the TargetLogonId hex value with the 4624 that opened the session, which is the pivot for computing exactly how long that session lasted and for catching sessions that opened but never closed cleanly.
Read the referenceDetailed Tracking
Account Management
A user account was created
Event ID 4720 fires on Windows Server and workstations every time a new local or domain user account is created, logged to the Security channel under Audit User Account Management. It records who created the account (SubjectUserName) and who was created (TargetUserName), plus initial account attributes analysts use to spot backdoor accounts fast.
Read the reference 4732A member was added to a security-enabled local group
Event ID 4732 is the Windows Security event logged when a member is added to a security-enabled local group, including the built-in Administrators group and domain-local groups on a domain controller. It records who made the change (Subject), which principal was added (Member SID) and which group received it, making it a primary privilege escalation signal.
Read the reference 4740A user account was locked out
Event ID 4740 fires in the Security log when a user account gets locked out after exceeding the domain's bad-password threshold. Windows itself (SYSTEM) performs the lockout, so the event names the locked account, not an attacker. The CallerComputerName field is the pivot: it names the machine that generated the failed attempts.
Read the reference 4738A user account was changed
Event ID 4738 fires whenever an existing Windows account's attributes are modified: password state, account-control flags, delegation rights, and more. Comparing its OldUacValue and NewUacValue fields tells you exactly which control bit flipped, which is what turns a generic "account changed" event into an actionable privilege-escalation alert.
Read the reference 4724An attempt was made to reset an account's password
Event ID 4724 records that one account (the Subject) reset another account's password (the Target) without needing to know the previous one. That Subject/Target split is what lets you catch both a targeted reset against a privileged account and a mass reset across many accounts from a single actor.
Read the reference 4723An attempt was made to change an account's password
Event ID 4723 records a self-service password change: the account holder supplied their current password to set a new one, so the Subject and Target fields are identical. That single fact is what separates it from 4724, an administrative reset performed by someone else.
Read the reference 4728A member was added to a security-enabled global group
Event ID 4728 records that an account was added to a security-enabled global group such as Domain Admins. Matching TargetUserName or TargetSid against Domain Admins and other tracked global groups turns a routine membership-change log into a privilege-escalation alert. Enterprise Admins and Schema Admins are universal groups, so their additions log as 4756, not 4728.
Read the reference 4729A member was removed from a security-enabled global group
Event ID 4729 records that an account was removed from a security-enabled global group, the direct counterpart to a 4728 addition. Most removals are routine, but a known administrator quietly dropped from a privileged group, or the same member removed minutes after being added, are both signals worth an alert.
Read the reference 4725A user account was disabled
Event ID 4725 records that an account was disabled, a reversible state change that blocks logon domain-wide while leaving the account object intact. The pattern worth alerting on is a security or backup service account disabled outside any documented maintenance window, since that is a known pre-ransomware impact step.
Read the reference 4726A user account was deleted
Event ID 4726 records that an account was permanently deleted, an irreversible action since Windows never reuses a SID. Correlating it with an earlier same-day 4720 creation for the same TargetSid catches the disposable-account pattern: an attacker who creates, uses, and deletes an account within hours to erase the persistence artifact.
Read the reference 4798A user's local group membership was enumerated
Event ID 4798 records that a process queried a specific account's local group memberships. It is one of the noisiest security events on a healthy host, so the useful signal is not the event itself but the CallerProcessName, net.exe, whoami.exe, or an unfamiliar PowerShell session, paired with a sweep across many target accounts.
Read the reference 4799A security-enabled local group membership was enumerated
Event ID 4799 records that a process listed the members of a specific security-enabled local group, most notably Administrators. Unlike 4798, which enumerates a user's memberships, 4799's TargetUserName is the group itself, and the highest-value alert pairs a 4799 on Administrators with a 4732 add for the same account minutes later.
Read the referenceAccount Logon
A Kerberos authentication ticket (TGT) was requested
Event ID 4768 records a Kerberos TGT request, the first authentication step of any domain logon. Only domain controllers write it, which makes it the authoritative record of where a logon began even when the client is not onboarded. Read the Result Code, the Pre-Authentication Type and the Client Address together.
Read the reference 4769A Kerberos service ticket was requested
Event ID 4769 is the Windows Security event a domain controller writes every time the Key Distribution Center receives a Kerberos service ticket (TGS) request. It records who asked, which service principal they asked for, the encryption type of the issued ticket, and the client address. RC4 (0x17) tickets for user-account SPNs are the Kerberoasting signal.
Read the reference 4776The computer attempted to validate the credentials for an account
Event ID 4776 is the Windows Security log entry written every time a computer validates an account's credentials over NTLM, under the Audit Credential Validation subcategory. It fires on the machine that owns the account (the domain controller for domain accounts, the local box for local accounts) and reports success or failure through its Error Code field.
Read the reference 4771Kerberos pre-authentication failed
Event ID 4771 fires when a domain controller's Key Distribution Center refuses to issue a Kerberos Ticket Granting Ticket for an account it knows. Its Status field carries a hex RFC 4120 failure code: 0x18 means a wrong password, 0x17 an expired one. The code, and how many accounts share one source, separates a password spray from routine noise.
Read the referenceFrequently Asked Questions
- What are Windows event IDs?
- Windows event IDs are numeric codes the operating system assigns to every entry it writes into the Event Log. Each ID identifies one specific occurrence: Event 4625 is a failed logon, 4688 a new process, 7045 a new service. SOC analysts read them as the ground-truth telemetry behind most Windows detections.
- Which Windows event IDs matter most for security monitoring?
- The Security log auditing events carry most of the signal: 4624/4625 (logons), 4688 (process creation), 4672 (privileged logons), 4720/4740 (account creation and lockout), 1102 (audit log cleared), plus PowerShell 4104 and Service Control Manager 7045. Every entry in this library explains one of them with its fields, codes, and detection queries in SPL, KQL and Lucene.
- Where do I find Windows event IDs?
- Open Event Viewer (eventvwr.msc) and browse Windows Logs: Security, System, and Application, or the Applications and Services Logs tree for channels like Sysmon and PowerShell Operational. In a SOC you rarely read Event Viewer directly: endpoints forward these logs to a SIEM, where you query them by event ID at scale.
- How do I practice investigating Windows event logs?
- Reading references only gets you part of the way. SOCSimulator Operations puts realistic Windows telemetry in front of you inside simulated SIEM, XDR, and Firewall consoles, so you can pivot on event IDs, correlate logons with process activity, and close investigations the way a working analyst does. A free tier is available.