Windows Security Event IDs Every Defender Should Know

Windows security event IDs are the vocabulary of every Windows investigation. When an alert says “4625 spike” or a colleague asks whether anyone saw a 4688, they are pointing at numbered records that Windows writes whenever something security-relevant happens. Learn a short list of these IDs and you can read most Windows incidents like a timeline.

This is Part 3 of 30 in the Blue Team Learning Path. Windows Event Logs 101 explained where the logs live. Here we go through the IDs that matter, the logon types that give them meaning, and the attacker behavior each one can reveal.

Key takeaways

• Memorize a short core: 4624, 4625, 4648, 4672, 4688, 4720, 4732, 4768, 4769, 4776, 1102 and 7045.
• A successful logon (4624) means little until you read its logon type and source address.
• Some IDs only exist if you enable the audit policy first. 4688 is the classic example.
• One event is a clue. Two or three related events in sequence are a detection.

Where Windows Security Event IDs Come From

Most of the IDs in this post are written to the Security log by the Local Security Authority when auditing is enabled. A few important ones, such as service installs and log clearing, appear in the System log. Each event carries a numeric ID, a timestamp, the computer name and a set of fields that change with the ID. Microsoft maintains a long reference in Appendix L: Events to Monitor, which is worth bookmarking.

The Core Windows Security Event IDs

Start with this table. The last column shows why a defender cares.

ID	Log	What it records	Why defenders care
4624	Security	An account was successfully logged on	Baseline of who logged in, how and from where
4625	Security	An account failed to log on	Password guessing and spraying
4648	Security	A logon was attempted using explicit credentials	Runas-style use of other credentials, possible lateral movement
4672	Security	Special privileges assigned to a new logon	Marks administrator-level sessions
4688	Security	A new process has been created	Process execution, with the command line if enabled
4698	Security	A scheduled task was created	Common persistence mechanism
4720	Security	A user account was created	Backdoor accounts
4732	Security	A member was added to a security-enabled local group	Privilege escalation, such as a new local administrator
4768 and 4769	Security (domain controller)	Kerberos TGT and service ticket requests	Kerberos abuse in Active Directory
4776	Security	Credential validation using NTLM	NTLM authentication activity
4740	Security	A user account was locked out	Often follows repeated failures
1102	Security	The audit log was cleared	Attackers hiding their tracks
104	System	An event log was cleared	Same goal as 1102 for other channels
7045	System	A service was installed	Persistence or remote execution through services

Event 4697 also records a service install in the Security log, and 4728 and 4756 are the global and universal group equivalents of 4732.

Windows Logon Types: Read the Number After 4624

A 4624 on its own tells you very little. The Logon Type field says how the session was created:

Logon type	Meaning	Typical example
2	Interactive	Someone at the keyboard
3	Network	File share access, many remote administration tools
4	Batch	Scheduled task
5	Service	A service starting under an account
7	Unlock	Workstation unlocked
8	NetworkCleartext	Credentials sent in a form that can be read, such as basic authentication
9	NewCredentials	Runas with /netonly
10	RemoteInteractive	Remote Desktop
11	CachedInteractive	Logon using cached credentials

For example, a type 10 logon to a database server from an unfamiliar workstation deserves a closer look, while type 5 entries for service accounts at boot are normal background noise. Microsoft documents every field in the 4624 reference.

Reading One Event: A 4624 Walkthrough

This is an illustrative event with the key fields only. The names and addresses are made up. [SCREENSHOT: the same 4624 in Event Viewer from your own lab, with the Logon Type and Network Information sections visible]

Event ID:            4624
Log:                 Security
Logon Type:          3
New Logon:           Account Name: svc-backup  Account Domain: LAB
Network Information: Source Network Address: 192.0.2.44
Process Information: Process Name: -
Authentication:      Logon Process: NtLmSsp   Authentication Package: NTLM

Read it as a sentence: the account svc-backup logged on over the network from 192.0.2.44 using NTLM. Is that normal for this account? Does svc-backup usually come from that address? Is NTLM expected here, or does the environment normally use Kerberos? Those three questions turn an event into an investigation. The same pattern from an address that has never touched the server is exactly what a pass-the-hash or stolen-credential case looks like, a topic Part 20 covers.

Pulling Events from the Command Line

You do not need a SIEM to practice. From an elevated prompt on a lab machine, wevtutil can query the Security log directly:

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

The same query in PowerShell is shorter and returns objects you can filter, which Part 4 covers in depth:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20

If a query returns nothing, the first thing to check is whether the audit policy for that event is on. List the current settings with:

auditpol /get /category:*

Attacker Behavior These Events Reveal

Pairing an event with the behavior it can expose is what turns knowledge into detection. Technique names below come from MITRE ATT&CK.

• Many 4625 events, then a 4624 from the same source. Password guessing that eventually worked. See Brute Force (T1110). Many 4625s across many different usernames from one source point to password spraying, T1110.003.
• 4720 followed by 4732. A new account added to a privileged group, matching Create Account: Local Account (T1136.001).
• 7045 or 4697 with an unfamiliar service name. A new service, matching Create or Modify System Process: Windows Service (T1543.003).
• 4698. A new scheduled task, matching Scheduled Task (T1053.005).
• 4688 with powershell.exe and a long encoded command line. Matches PowerShell execution (T1059.001), but only visible if command line logging is on.
• 1102 or 104. Someone cleared the logs. In the current ATT&CK release this is listed as Clear Windows Event Logs under T1685.005, and earlier versions of the matrix list it as T1070.001.

Turning On the Events You Need

Several of these IDs are silent by default. Process creation is the one beginners notice first. In a lab, you can enable the audit subcategory with:

auditpol /set /subcategory:"Process Creation" /success:enable

Event 4688 only contains the command line if you also enable the policy Include command line in process creation events, found under Computer Configuration, Administrative Templates, System, Audit Process Creation. Apply changes like this to systems you own or administer, and test the log volume first.

From Event IDs to Detection Ideas

Knowing an ID is step one. Step two is deciding when it becomes an alert. These starting ideas are deliberately simple, and each comes with the tuning problem you will hit in real environments. Part 16 and Part 17 turn ideas like these into proper rules.

Event	Detection idea	Tuning note
4625	Many failures from one source in a short window, or many different usernames from one source	Exclude vulnerability scanners and service accounts with a stale saved password
4624, type 10	Remote Desktop logon to a server from a workstation that never connects there	Allow-list approved jump hosts
4688	powershell.exe with -EncodedCommand in the command line	Needs command line logging, and some admin scripts use it legitimately
7045	Service binary path in a user-writable folder such as a temp or profile directory	Installers trigger it, so baseline normal installs first
4732	Member added to the local Administrators group	Expect changes during approved maintenance windows
1102	Any occurrence at all	Very low volume, so alerting on every one is realistic

Notice the pattern: each idea names the behavior, then names what makes it noisy. A detection without a tuning note is a future source of alert fatigue. You can read more about that trade-off in detection engineering basics, and about writing portable rules in Sigma rules.

Common Pitfalls

• Reading 4624 without the logon type. The ID alone is nearly meaningless. Always read the type, the account and the source.
• Assuming an event exists. If audit policy is off, the absence of 4688 proves nothing. Check policy before trusting a negative.
• Ignoring machine accounts. Account names ending in $ are computers. They log on constantly and are rarely the story.
• Forgetting time zones. Events are stored in UTC and displayed in local time. A timeline built from mixed sources must use one reference.
• Letting the log roll over. A small Security log can overwrite days of history during a busy incident. Size and forward your logs before you need them.
• Hunting one ID in isolation. A lone 4625 is a typo. Fifty in a minute is a pattern.

What to Practice Next

Pick a lab machine you own, fail a login on purpose, then find the matching 4625 and read its Status and SubStatus fields. A SubStatus of 0xC000006A means the password was wrong for a valid account, while 0xC0000064 means the username does not exist, a distinction documented in the 4625 reference. Then continue to Part 4 on the Get-WinEvent PowerShell guide, and when you reach Part 12 on Sysmon event IDs you will see how richer endpoint logging fills the gaps in native Windows auditing. The previous Part, SOC analyst tools, shows where these logs end up.

Frequently Asked Questions