Windows Event Logs and the Event IDs Defenders Use Most

#What the Windows event logs are

Windows keeps a running record of what happens on the machine: services starting, programs crashing, people signing in. Each record is an event. Every event has a timestamp, a provider (the component that wrote it), a numeric Event ID, a level and a set of fields that depend on the event type. Events are grouped into logs, also called channels, and stored as .evtx files under %SystemRoot%\System32\Winevt\Logs.

Three logs matter most when you start:

• Application holds events written by programs and some Windows components. A crashing app or a failed update usually lands here.
• System holds events from Windows itself and from drivers: services starting and stopping, the event log service starting at boot (Event ID 6005), driver errors.
• Security holds audit events: logons, logoffs, use of sensitive privileges, process creation, changes to accounts and policy. Most of this article is about it, and it is the only one of the three that a normal user cannot open.

You can see the difference in access from PowerShell. On the machine used for this article (Windows 11, Windows PowerShell 5.1), this ran in a shell without administrator rights:

Get-WinEvent -ListLog System,Application | Format-Table LogName,RecordCount,IsEnabled -Auto

LogName     RecordCount IsEnabled
-------     ----------- ---------
System            36196      True
Application       19965      True

Adding Security to the same command produced an error for that log: Windows could not retrieve its information because the operation was unauthorized. Your record counts will differ.

#Why it matters

Many Windows detections are built on the Security log. A SIEM rule for password guessing counts 4625 events. A rule for a suspicious admin session looks at 4624 and 4672 together. A rule for log tampering watches for 1102. The Field Manual's SIEM article covered how those rules work. Reading the events by hand on one machine lets you check whether a rule's assumptions hold on your systems.

The Security log only contains what the audit policy tells Windows to record. If the policy does not audit failed logons, Windows writes no 4625 events, and a rule that counts them never fires. From the SIEM side, that looks exactly like a quiet machine. So checking the audit policy comes before reading the log.

#How auditing works

#Audit policy decides what exists

Windows groups audit settings into categories, and each category into subcategories. Each subcategory can record successes, failures, both or nothing. The categories are Account Logon, Account Management, Detailed Tracking, DS Access, Logon/Logoff, Object Access, Policy Change, Privilege Use and System.

The Logon/Logoff category holds the subcategories behind most events in this article: Logon (4624 and 4625), Logoff (4634), Account Lockout (which Microsoft also lists for 4625) and Special Logon (4672). Process creation, event 4688, belongs to the Process Creation subcategory under Detailed Tracking.

auditpol is the built-in tool for reading the policy. auditpol /list prints category and subcategory names and works in a normal shell. auditpol /get reads the actual settings. Microsoft's reference says it needs Read permission on the policy or the "Manage auditing and security log" right (SeSecurityPrivilege), and a normal, non-elevated shell has neither.

auditpol /list /category /v

On the machine used for this article, whose Windows display language is Portuguese, that command ran without elevation and printed every category with a translated name and a GUID. Logon/Logoff had the GUID {69979849-797A-11D9-BED3-505054503030}. The English name still worked there with auditpol /list /subcategory:"Logon/Logoff", which listed twelve subcategories. If your system rejects a name, pass the GUID.

#The event IDs you will use most

#4624 and 4625: logons

Both events are written on the computer where the logon happened. If someone types a wrong password at your laptop, the 4625 lands in your laptop's Security log. The two events share most of their fields:

• Subject is the account that reported the logon, often the computer itself or SYSTEM.
• Logon Type says how the logon happened. The common values are 2 (Interactive, at the keyboard), 3 (Network, such as a file share), 4 (Batch), 5 (Service), 7 (Unlock), 10 (RemoteInteractive, Remote Desktop) and 11 (CachedInteractive, domain credentials cached on the machine).
• New Logon (in 4624) or Account For Which Logon Failed (in 4625) is the account being logged on, with its Security ID, name and domain. In 4624 this section also carries the Logon ID of the new session.
• Failure Information (4625 only) has a Status and a Sub Status code. Microsoft's page lists the codes worth watching: 0xC000006A for a bad password, 0xC0000064 for a user name that does not exist, 0xC000006D for a bad user name or bad authentication information, 0xC0000072 for a disabled account. The same page gives 0xC0000234, "Account locked out", as the typical status when the failure comes from a locked account. Several 0xC0000064 failures in a row can be a sign of someone enumerating user names.
• Process Information shows the process that attempted the logon, and Network Information gives the workstation name, source address and source port. 127.0.0.1 or ::1 means localhost, and the port is 0 for interactive logons.

On Windows 10 and later, 4624 also carries Elevated Token, which says whether the session has administrator privileges.

#4634: logoff, and why the Logon ID matters

4634 says a logon session ended. On its own it tells you little. Its value comes from the Logon ID: the same hexadecimal value appears in the 4624 that opened the session, in any 4672 for that session, in 4688 events for processes the session started, and in the 4634 that closed it. Following one Logon ID through the log reconstructs a session from start to finish. Microsoft notes that Logon IDs are only unique between reboots on the same computer, so always pair the ID with a time range.

#4672: special privileges

Windows writes 4672 when a new logon receives one of a list of sensitive privileges, such as SeDebugPrivilege (debug programs), SeBackupPrivilege (back up files and directories) or SeTcbPrivilege (act as part of the operating system).

Every SYSTEM logon triggers 4672, so the log holds many of them. Microsoft recommends looking at the ones where the account is not LOCAL SYSTEM, NETWORK SERVICE or LOCAL SERVICE, and not an admin you expect to hold those privileges.

#4688: process creation

4688 is written every time a new process starts, when the Process Creation subcategory is audited. It records the new process name, the creator (parent) process name, the account, the Token Elevation Type (whether the process ran with a full, elevated or limited token) and the integrity level.

It also has a Process Command Line field, which is empty by default. Microsoft's page says it is filled only when the Group Policy setting "Administrative Templates\System\Audit Process Creation\Include command line in process creation events" is enabled. Without it, you know powershell.exe started but not what it was told to do.

#1102: the log was cleared

1102 means someone cleared the Security log. It is written by the Microsoft-Windows-Eventlog provider and records the account that did it. Microsoft's guidance is short: you should not normally see this event, there is rarely a reason to clear the Security log by hand, and each occurrence is worth investigating.

#What Sysmon adds

Sysmon (System Monitor) is a Sysinternals tool published by Microsoft. It installs as a service and a driver, stays resident across reboots and writes its own events to Applications and Services Logs/Microsoft/Windows/Sysmon/Operational. It is a separate download, not part of a default Windows install, and Microsoft lists Windows 11 and Windows Server 2019 or later as supported.

Compared with the built-in Security log, Sysmon gives you more detail on activity you would otherwise see only partly:

• Event ID 1, process creation, includes the full command line, file hashes (SHA1 by default, with MD5, SHA256 and IMPHASH available) and a ProcessGuid that stays unique even when Windows reuses process IDs.
• Event ID 3 logs network connections with the process behind each one. It is disabled by default.
• Other IDs cover file creation (11), DNS queries (22), registry changes, named pipes, WMI subscriptions and one process opening another, such as lsass.exe (10).

An XML configuration file decides which events Sysmon includes or excludes. Microsoft states that Sysmon does not analyze its events and does not try to hide from attackers. A SIEM or an analyst does the reading.

Installing Sysmon changes the system, so this article's lab does not do it.

#Hands-on: find your own failed logon

You will create one failed logon on your own computer, with your own account, and find it three ways. Do not change the audit policy during this lab. If the policy turns out not to record failed logons, that result is the lesson: write it down and stop there.

#Step 1: open an elevated PowerShell

Right-click Windows PowerShell or Terminal and choose Run as administrator. Check that the shell really is elevated:

([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

True means you can read the Security log. On the machine used for this article, the available shell returned False. The commands below were run there anyway and their failures are reported as observed, because they are worth knowing. Where elevated output would go, this article describes the fields to look for, from Microsoft's documentation.

#Step 2: check the audit policy

auditpol /get /category:"Logon/Logoff"

In an elevated shell this prints each subcategory with its setting. Find the Logon line. For this lab it needs to include Failure, so either "Success and Failure" or "Failure". If it says "No Auditing", Windows will not write 4625 and the rest of the lab will find nothing.

Without elevation, on the machine used for this article, the command printed error 0x00000522 with a message that the client does not hold a required privilege, and exited with code 1314.

#Step 3: generate the event

Press Win+L to lock the screen. Type a wrong password once, then sign in with the right one. Note the time.

Use your password, not a PIN. If you normally use Windows Hello, pick the password option on the sign-in screen. This article did not test what a wrong PIN produces.

#Step 4: find the failure with Get-WinEvent

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 | Format-List TimeCreated, Message

-FilterHashtable applies the filter while events are read, which Microsoft's documentation describes as more efficient than piping everything to Where-Object. -MaxEvents 5 keeps the five newest matches, because Get-WinEvent returns newest first.

In an elevated shell, the top result should carry the time you noted. In its Message, check:

• Logon Type. Microsoft's sample 4625 is an interactive logon, type 2, with the caller process C:\Windows\System32\winlogon.exe.
• Account For Which Logon Failed, which should be your account.
• Status and Sub Status. For a wrong password, look for 0xC000006A in one of them.
• Source Network Address and Source Port. For a logon at your own keyboard, expect a local value such as 127.0.0.1 and port 0, as in Microsoft's sample.

Without elevation, this exact command misleads you. On the machine used for this article, it did not report a permission problem. It printed the error that no events were found matching the selection criteria. A plain Get-WinEvent -LogName Security -MaxEvents 1 in the same shell reported the real cause, an unauthorized operation. If you see "no events found" from a non-elevated shell, check elevation before you conclude the log is empty.

#Step 5: find the successful logon

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 5 | Select-Object TimeCreated, Id

You should see a 4624 a few seconds after your 4625, with other 4624 events around it, because services and the system log on all the time. Open the full message of the one closest to your time and check the Logon Type and account name. Adding StartTime=(Get-Date).AddMinutes(-15) to the hashtable limits the search to the last fifteen minutes.

A wrong password followed by a right one from the same account, at the keyboard, seconds apart, is a typo. The same failure repeated against many accounts from one network address points to guessing, and detection rules are written to tell those two cases apart.

#Step 6: the same search with wevtutil

wevtutil qe Security /c:5 /rd:true /f:text /q:"*[System[(EventID=4625)]]"

wevtutil is the older command-line tool for event logs. qe queries events, /c:5 limits the count, /rd:true reads newest first, /f:text prints text instead of XML, and /q takes an XPath filter. Elevated, you get the same events as step 4. Drop /f:text to see the raw XML, with the field names detection rules use, such as TargetUserName, Status and LogonType. On Windows in another language, the message text is translated, while the field names in the XML stay in English.

Without elevation, on the machine used for this article, it printed that it failed to open the event query because access was denied, and exited with code 5.

#Step 7: look at it in Event Viewer

Run eventvwr.msc. If you are asked, allow it to run as administrator. Go to Windows Logs > Security, choose Filter Current Log and enter 4625 in the Event IDs box. Open the event. The General tab shows the same message you read in PowerShell. The Details tab, in XML view, shows the raw field names. Keep this event open: the Sigma article compares a rule against it.

#Common mistakes

• Trusting "no events found" from a normal shell. As step 4 showed, a non-elevated Get-WinEvent -FilterHashtable query on the Security log can report no matches instead of access denied.
• Assuming an event exists without checking the policy. No audit setting, no event. The same goes for fields: the 4688 command line stays empty until a separate policy turns it on.
• Reading one event in isolation. A single 4625 means little. Look at the 4624 that follows, the Logon ID and the time range.
• Clearing the log after a lab to tidy up. You destroy the evidence you just created, and you generate a 1102 that someone may have to investigate.
• Forgetting that logs roll over. On the machine used for this article, Get-WinEvent -ListLog Application showed a maximum size of 20971520 bytes in Circular mode: when the log fills, old events are overwritten. Check the Security log the same way, elevated, before you count on last month's events.

#How to go further

• Read the Microsoft page for each event in this article. Each one ends with security monitoring recommendations that are close to ready-made detection ideas.
• Set up a virtual machine in a legal home lab, install Sysmon there with a configuration file, run a few commands and compare Sysmon event 1 with 4688 for the same process.
• Turn the event you found into a detection: the next article, writing your first Sigma rule, builds and tests a rule for exactly this 4625.

#Sources

• Microsoft Learn, 4625(F) An account failed to log on
• Microsoft Learn, 4624(S) An account was successfully logged on
• Microsoft Learn, 4634(S) An account was logged off
• Microsoft Learn, 4672(S) Special privileges assigned to new logon
• Microsoft Learn, 4688(S) A new process has been created
• Microsoft Learn, 1102(S) The audit log was cleared
• Microsoft Learn, Get-WinEvent
• Microsoft Learn, Sysmon
• Microsoft Learn, auditpol get
• Microsoft Learn, wevtutil