Windows Event IDs: The Highest-Signal Logs for Detection

Windows logs almost everything, which is the problem. A busy domain controller writes millions of events a day, and most detection failures are not missing data but missing the few IDs that carry the signal. This reference is that short list: the Security and Sysmon event IDs that repay the attention, what each one means, and where it fits in a detection.

Two sources matter. The native Security log records authentication, privilege, and account activity out of the box, though process command-line capture and some auditing must be switched on. Sysmon, a free Sysinternals tool, adds process, network, and registry telemetry that native logging either lacks or logs poorly. Together they cover most of the attack lifecycle.

Native Security log events

These are standard Windows Security channel event IDs. The example-use column is a starting point for a hunt or rule.

ID	Meaning	Why it matters	Example use
4624	Successful logon	Every access starts here; the Logon Type field says how	Alert on Type 10 (RDP) from unexpected sources
4625	Failed logon	Brute force, password spray, and misconfig show up here	Threshold on many 4625 for one account, or one source hitting many accounts
4634	Logoff	Pairs with 4624 to measure session duration	Correlate session start and end for a host timeline
4672	Special privileges assigned to new logon	Marks an administrative or high-privilege session	Watch for admin logons outside change windows
4688	A new process was created	Command lines and parent process, the core of behavioural detection	Detect Office spawning script hosts or LOLBins
4720	A user account was created	New accounts are a persistence and backdoor signal	Alert on account creation off change tickets
4728	Member added to a security-enabled global group	Privileged group changes grant lasting access	Alert on additions to Domain Admins
4732	Member added to a security-enabled local group	Local admin additions enable lateral movement	Alert on additions to local Administrators
4768	Kerberos authentication ticket (TGT) requested	The start of Kerberos auth, useful for account baselining	Baseline TGT requests, spot anomalous encryption types
4769	Kerberos service ticket (TGS) requested	Kerberoasting requests service tickets to crack offline	Alert on many 4769 with RC4 for service accounts
4776	Domain controller attempted to validate credentials (NTLM)	NTLM auth path, pass-the-hash and spray visibility	Correlate 4776 failures across hosts
7045	A new service was installed	Services are a classic persistence and lateral-movement vector	Alert on service installs from user-writable paths
1102	The audit log was cleared	Log clearing is almost always an attacker covering tracks	Alert immediately on any 1102

A handful of these deserve emphasis. The Logon Type on 4624 and 4625 is what makes them useful: Type 3 is a network logon (share or authentication), Type 10 is RemoteInteractive (RDP), and a Type 10 from an unusual source at an odd hour is a strong lead. Event 1102 is the cleanest signal on the list, since almost no legitimate process clears the security log.

Sysmon events

Sysmon writes to its own operational channel and gives you telemetry native logging does not. These are the highest-value Sysmon event IDs.

ID	Meaning	Why it matters	Example use
1	Process creation	Full command line, hashes, and parent process with strong detail	Detect LOLBin abuse and suspicious parent-child chains
3	Network connection	Ties a process to its outbound connections	Flag script hosts or Office apps making network connections
7	Image (DLL) loaded	Reveals DLL side-loading and unsigned module loads	Hunt for unsigned DLLs loaded from user-writable paths
8	CreateRemoteThread	Code injection between processes	Detect process injection into lsass or browsers
11	File created	Dropped payloads and staged files become visible	Alert on executables written to Temp or Startup folders
13	Registry value set	Persistence and configuration changes in the registry	Watch Run keys and service registry entries

Sysmon event 1 overlaps with native 4688 but is generally richer: it includes file hashes and the parent process image, and it captures the command line without extra policy. Many detection teams run both, using 4688 as a fallback and Sysmon 1 as the primary source.

Event 8 (CreateRemoteThread) and event 7 (image load) cover techniques native logging barely sees. Injection into lsass.exe and DLL side-loading are common post-exploitation moves, and these two IDs are often the only place they surface.

Where the events meet attacker behaviour

The value of this list comes from correlation, not single events. A short chain tells a story that no one ID does alone:

• Initial execution: 4688 or Sysmon 1 shows winword.exe spawning powershell.exe, a parent-child pair that is almost never legitimate. This is where living-off-the-land activity becomes visible in logs, and the delivery file that triggered it (a macro doc, an LNK, a mounted image) is often recorded by Sysmon 11 just beforehand. Our File-Format Abuse Atlas maps which delivery formats produce which process chains, so you can read a Sysmon 11 file-create plus a Sysmon 1 process-create as a single delivery event.
• Privilege and persistence: 4720 (new account), then 4732 (added to local Administrators), then 7045 (new service) in a short window is a textbook foothold-and-persist sequence.
• Credential access: a burst of 4769 with RC4 encryption for service accounts is the fingerprint of Kerberoasting, and Sysmon 8 into lsass.exe points at credential dumping.
• Anti-forensics: 1102 says someone cleared the log, which is both an alert and a prompt to pull the same events from your central log store where they cannot be erased locally.

Notes on the individual high-value IDs

A table gives the shape of each event. A few of them repay a closer look, because the way you use them in practice is not obvious from a one-line description.

Event 4672, special privileges assigned, fires alongside a logon when the session receives sensitive privileges such as those an administrator holds. It is a fast way to spot every high-privilege logon without parsing group membership, and it pairs naturally with 4624 to answer whether a given session was privileged. An administrative logon outside a change window, or on a host that no administrator should be touching, is a strong early lead.

Event 4720, account creation, is low volume in most environments and high meaning. Legitimate account creation flows through provisioning systems and change tickets, so an account created directly on a host or domain controller with no matching ticket is worth immediate attention. The follow-on events matter as much as the creation: a new account added to a privileged group and then used to install a service is a foothold-and-persist sequence in miniature.

Events 4728 and 4732, additions to privileged groups, are where lasting access is granted. 4728 covers security-enabled global groups such as Domain Admins, and 4732 covers local groups such as the machine's Administrators. Additions to these groups grant durable, high-value access, and they are rare enough that alerting on every one is affordable. The account doing the adding is as interesting as the account being added.

Event 7045, new service installed, is a persistence and lateral-movement classic. Attackers install services to run code at boot and to execute remotely on other hosts. Services whose binary path points at a user-writable directory, a temporary folder, or an unusual location are especially suspicious, as are services with random-looking names installed outside a maintenance window.

Event 1102, audit log cleared, is the cleanest signal on the list. Legitimate operations almost never clear the Security log, so treat any occurrence as an incident until proven otherwise. It is both an alert and an instruction to pull the same window of events from your central store, where a local clear cannot reach them.

Reading logon types on 4624 and 4625

The single most useful field on the authentication events is the Logon Type. The same event ID means very different things depending on how the logon happened, and most detection logic keys off this number rather than the event ID alone.

Logon Type	Name	What produced it	Why it matters
2	Interactive	Console logon, someone at the keyboard	Unexpected on a headless server
3	Network	Access to a share or a network authentication	The most common type; where lateral movement and share access appear
4	Batch	Scheduled task running	Scheduled-task persistence shows here
5	Service	A service starting under an account	Service account misuse and new-service persistence
7	Unlock	Workstation unlocked	Session continuity on a host
8	NetworkCleartext	Network logon with cleartext credentials	Rare and worth scrutiny, often basic-auth style
9	NewCredentials	Runas with alternate credentials	Credential use for outbound access, seen in some lateral techniques
10	RemoteInteractive	RDP and Terminal Services	Remote hands-on access; high value for intrusion detection
11	CachedInteractive	Logon using cached domain credentials	Offline or disconnected logon, useful on laptops

A 4624 with Type 10 from an internal host that never normally initiates RDP, at an hour outside the account's pattern, is one of the higher-signal single events you can alert on. A flood of Type 3 failures in 4625 across many accounts from one source is password spraying. The same flood against one account from many sources is distributed brute force. The type field turns one event ID into several distinct detections.

Detection chains worth building

Single events rarely convict. The strongest detections are short sequences that only fit an attack. These map onto MITRE ATT&CK techniques and are a good starting backlog for rule writing.

• Suspicious parent-child execution. 4688 or Sysmon 1 showing an Office application, a browser, or a script host spawning a command interpreter or powershell.exe. This covers execution via user-facing applications and much living-off-the-land activity. Enrich with the Sysmon 11 file-create that dropped the delivery file just before.
• Foothold and persist. 4720 (account created), then 4732 or 4728 (added to a privileged group), then 7045 (new service) or a Sysmon 13 Run-key write, inside a short window. This is account creation for persistence followed by privilege and a persistence mechanism.
• Credential access on a domain controller. A burst of 4769 service-ticket requests with RC4 encryption for service accounts is the Kerberoasting fingerprint. Sysmon 8 (CreateRemoteThread) or a process opening a handle into lsass.exe points at credential dumping from memory.
• Lateral movement. 4624 Type 3 or Type 10 to hosts the account does not normally touch, correlated with a service install (7045) or scheduled task on the destination, is a remote-execution and lateral-movement pattern.
• Defense evasion and anti-forensics. 1102 (audit log cleared), a sudden stop in expected event volume from a host, or Sysmon showing the Sysmon service being stopped. Log clearing is rarely benign and should page immediately.

Getting value from the Sysmon events

The Sysmon IDs reward specific hunts rather than blanket alerting. Event 1 (process creation) is the anchor, because its command line, hashes, and parent image let you write parent-child rules that native logging cannot express as cleanly. Start there and treat the others as enrichment.

Event 3 (network connection) ties a process to where it talked. The high-value pattern is a process that should never reach the network, a script host, an Office application, or a system binary running from an odd path, opening an outbound connection. Rather than alerting on all connections, which is unmanageable, scope the rule to unexpected processes.

Event 7 (image load) surfaces DLL side-loading and unsigned modules loaded from user-writable paths. Legitimate software loads many DLLs, so the useful hunt is narrow: unsigned or unusually located modules loaded by trusted binaries, a hallmark of side-loading. Event 8 (CreateRemoteThread) catches code injection between processes, and a remote thread created into lsass.exe or a browser is a strong post-exploitation signal.

Event 11 (file create) makes dropped payloads visible, and the productive scope is executables or scripts written to temporary and startup locations. Event 13 (registry value set) catches persistence through Run keys and service registry entries. Both are noisy without scoping, and both become high-signal when you focus on the specific locations attackers reuse.

Common mistakes with Windows logging

Relying on 4688 without command-line auditing. Out of the box, 4688 records the process name and not its arguments. The intent of most malicious execution lives in the arguments. Enable command-line capture in Group Policy, or lean on Sysmon 1, before you build detections that assume you can see the full command.

Trusting local logs during an incident. An attacker with administrative rights can clear or tamper with logs on the host. If your only copy is local, 1102 is a dead end. Forward events to a collector or SIEM in near real time so the evidence has already left the host.

Deploying Sysmon with an empty or default configuration. Sysmon does little useful work without a curated configuration that decides what to include and exclude. A noisy default drowns analysts; a thoughtful configuration focused on process, network, image-load, and registry events makes the high-value IDs usable.

Alerting on high-volume IDs without a baseline. 4624, 4625, 4768, and 4769 are voluminous. Alerting on raw occurrence buries the team. Baseline normal per account and per host, then alert on anomalies such as unusual logon types, encryption downgrades, or volume spikes.

Forgetting clock and time-zone consistency. Correlating a chain across hosts depends on comparable timestamps. Skewed clocks or mixed time zones make sequences impossible to reconstruct. Sync time and normalise to one zone at ingest.

How Windows logging evolved

Early Windows security logging centred on the Security channel: logons, privilege use, and account management. It answered who authenticated and what accounts changed, and it was thin on what processes actually did. Process-creation logging existed but did not capture command lines by default, which left the most telling detail out of reach.

Two shifts changed defensive visibility. Native process-creation events gained optional command-line capture, closing part of the gap once administrators enabled it. Separately, Sysmon brought process hashes, network connections, image loads, remote-thread creation, file creation, and registry activity into a dedicated operational channel with a configuration model that let teams tune the noise. The result is that a modern Windows estate can produce telemetry rich enough to reconstruct an intrusion step by step, provided the sources are enabled, tuned, and forwarded off the host. The detection-engineering discipline that grew around this, expressing chains as portable rules, is what turns the raw channels into repeatable coverage.

Frequently asked questions

Do I need Sysmon if I already collect the Security log? The Security log covers authentication, privilege, and account changes well. Sysmon adds process detail, network connections, image loads, remote-thread injection, file creation, and registry changes that the native log covers poorly or not at all. Most mature detection programs run both, using 4688 as a fallback for process creation and Sysmon 1 as the richer primary.

Why does event 4688 not show the command line? Command-line capture in 4688 is off by default and must be enabled through Group Policy. Until then you see the process name and parent but not the arguments, which is where malicious intent usually lives. Enable it, or use Sysmon 1, which captures the command line without that extra policy.

What is the single most important event to alert on? 1102, the audit-log-cleared event, is the cleanest high-signal alert, because almost no legitimate process clears the Security log. It should page immediately and prompt you to pull the same events from your central store, where they cannot be erased locally.

How do I tell Kerberoasting from normal Kerberos traffic? 4768 and 4769 are normal and high volume. The Kerberoasting fingerprint is a burst of 4769 service-ticket requests using RC4 encryption for service accounts, since attackers request tickets they can crack offline. Baseline normal ticket activity and encryption types, then alert on the RC4 anomaly for service accounts.

Which logon types deserve the most attention? Type 10 (RemoteInteractive/RDP) and Type 3 (network) carry the most intrusion signal. Type 10 from unusual sources or at odd hours suggests remote hands-on access. Patterns of Type 3 failures reveal spraying and brute force. The Logon Type field is what makes 4624 and 4625 actionable.

How long should I retain these events? Long enough to investigate intrusions that are discovered late, which is often months after the initial access. Retention depends on volume and storage, and the low-volume high-meaning IDs such as 1102, 7045, 4720, and privileged group changes are cheap to keep for extended periods even when you cannot retain everything.

Can an attacker disable Sysmon to blind me? Yes, with sufficient privileges. Watch for the Sysmon service stopping, a sudden gap in expected Sysmon volume from a host, and tampering with its configuration. Forwarding events off the host means the last events before the blind spot are already safe in the SIEM.

How to use this reference

1. Enable the sources first. Turn on process-creation command-line auditing, deploy Sysmon with a vetted configuration, and confirm the events actually reach your SIEM.
2. Start with the low-volume, high-meaning IDs. 1102, 7045, 4720, and privileged group changes (4728/4732) are cheap to alert on and rarely benign.
3. Build chains, not single alerts. The strongest detections correlate a parent-child process pair, then a persistence event, then network activity.
4. Baseline the noisy IDs. 4624, 4625, 4768, and 4769 are high volume, so learn normal for your environment before alerting, and focus on logon types and encryption anomalies.
5. Express the logic as rules. Sigma and your SIEM's native language turn these chains into repeatable detections that survive staff turnover.

You do not need every Windows event ID memorised. You need the two dozen that carry the signal, the auditing switched on to capture them, and the correlation logic to read them as a story rather than a stream. That is what turns the log flood into detection.

Related guides

• Threat Hunting Guide
• Sigma Rules Explained
• LOLBins Explained
• Pass the Hash Explained
• Incident Response 101