Back to Blog
WindowsLogs

Windows Event IDs for Security Monitoring

Nikhil Tank·July 11, 2026·10 min read

Essential Windows Event IDs for Security Monitoring

Windows event logs are the foundation of endpoint visibility in any enterprise environment. Every Windows machine generates a stream of events recording user logons, process creations, service installations, and privilege changes. Knowing which Event IDs to monitor — and what to look for within them — separates a mature security operation from one that is drowning in noise.

Below is a guide to the most critical Windows Security Event IDs every analyst should know, including why each matters and what anomalies to hunt for. Shieldlix SIEM ingests and correlates these events automatically, surfacing the signals that matter.

4624 — An Account Was Successfully Logged On

Event ID 4624 is generated every time a user or system account authenticates successfully. This is one of the highest-volume events, so effective triage requires filtering for the unusual.

  • Logon Type is the key field: Type 2 (Interactive — keyboard/screen), Type 3 (Network — SMB, RPC), Type 10 (RemoteInteractive — RDP), Type 7 (Unlock — screen saver unlock). Type 10 logons from unexpected source IPs are a major red flag.
  • Account Domain\Name should be cross-referenced against known service accounts. A domain admin logging into a workstation is anomalous.
  • Workstation Name mismatch with the source IP often indicates lateral movement.
  • Logon ID links 4624 to other events in the same session, enabling full session reconstruction.

4625 — An Account Failed to Log On

Event ID 4625 records failed authentication attempts. High cardinality of 4625 events from a single source is the canonical indicator of a brute-force attack.

  • Watch for multiple logon types: failed RDP attempts (Type 10) are common for external brute-forcing; failed Type 3 attempts (network) may indicate pass-the-hash or lateral movement attempts.
  • The Sub Status field provides the reason. 0xC000006D means bad username/password; 0xC000006F means account is locked out; 0xC0000070 means workstation restriction.
  • Correlate with 4776 (Credential Validation) on domain controllers to pinpoint the target account.

4688 — A New Process Has Been Created

Event ID 4688 is the single most important event for detecting malicious execution. Every process spawn generates this event, making it the backbone of endpoint detection.

  • Enable command-line auditing via GPO (Administrative Templates > System > Audit Process Creation > Include command line in process creation events). Without it, you see process names but not the arguments passed to them.
  • Hunt suspicious parent-child pairs: winword.exe spawning powershell.exe, wscript.exe, or cmd.exe is a classic phishing indicator.
  • Monitor for execution from suspicious paths: %TEMP%, %APPDATA%, %LOCALAPPDATA%, browser download directories, and C:\Users\*\AppData\Local\Temp\.
  • Track Creator Process ID and Process ID to reconstruct process trees during incident response.

4648 — A Logon Was Attempted Using Explicit Credentials

Event ID 4648 fires when a process explicitly uses alternate credentials via RunAs or similar mechanisms. This is a critical lateral-movement signal.

  • If an account with SeDebugPrivilege (typically administrators) uses explicit credentials, it may indicate credential dumping or token theft.
  • Correlate 4648 with 4624 using the Target Logon ID to chain the full authentication path.

4672 — Special Privileges Assigned to New Logon

Event ID 4672 accompanies any logon that receives super-user privileges like SeTcbPrivilege, SeDebugPrivilege, or SeBackupPrivilege. Every domain admin logon triggers this event.

  • Baseline normal administrative activity (e.g., IT team member logging onto a server). Alert on 4672 events from non-admin accounts — this signals privilege escalation from user to SYSTEM.
  • Cross-reference against known admin workstations. A privileged logon originating from an unmanaged or personal device is suspicious.

4719 — System Audit Policy Was Changed

Event ID 4719 logs changes to the Windows audit policy. Adversaries commonly alter audit settings to disable detection before executing their payload.

  • Any 4719 event from a non-administrative source should trigger an immediate investigation.
  • Track the Audit Policy Change fields to see exactly which categories were disabled (e.g., Audit Process Creation turned off).

1102 — The Audit Log Was Cleared

Event ID 1102 is a zero-noise indicator. A user or process has cleared the Security event log. This is almost never legitimate in production.

  • Capture the Subject User SID and Subject User Name to identify the account that cleared the log.
  • Retain Windows Event Logs on a central log collector (such as Shieldlix) so that cleared logs do not eliminate forensic evidence.

7045 — A Service Was Installed in the System

Event ID 7045 (from the System log, not Security) records new service installations. Many malware families and post-exploitation tools (Cobalt Strike, Metasploit) install services for persistence.

  • The Service Name field often mimics legitimate Microsoft or third-party names. Look for typos, suspicious characters, or random strings.
  • The Image Path tells you the binary being executed. Paths in %TEMP% or C:\Users\Public\ are highly suspicious.
  • Correlate 7045 with 4688 to see what process performed the installation — sc.exe or powershell.exe installing a service is a common Cobalt Strike artifact.

Sysmon Integration

While native Windows Event Logging is essential, it lacks depth in several areas — file creation, network connections, registry modification, and driver loading. Sysmon (System Monitor) fills these gaps with high-fidelity events. For example, Sysmon Event ID 1 (Process Creation) is richer than 4688, including process hashes, signed status, and parent GUID tracking. Run Sysmon alongside native event collection for comprehensive visibility.

Centralizing Windows Events with Shieldlix

Manually reviewing Windows Event Logs across hundreds or thousands of endpoints is impossible. Shieldlix SIEM ingests Windows Event Logs via WinRM, Event Forwarding (WEF), or direct agent deployment, normalizing every Event ID into a searchable, correlated stream. Built-in detection rules map these events to MITRE ATT&CK techniques, so a 4625 storm automatically triggers a brute-force alert tied to T1110. Stop chasing individual logs — start understanding the attack chain.


Written by
Nikhil Tank
Founder & CEO, Shieldlix
← Back to Blog