Windows Event Log Guide for Security Teams: Key Event IDs Explained

Most Windows intrusions leave a trail in the event logs, but only if the right audit subcategories are switched on, the logs are kept off the host, and someone knows which of the hundreds of event IDs matter. By default Windows does not record process command lines, Microsoft's own baseline leaves Kerberos authentication auditing off, and local logs roll over quickly on busy servers. This guide explains how the Windows Security log and its companion channels work, which event IDs to watch for logons, account and group changes, services, scheduled tasks, file shares and log clearing, and how to configure and forward them at scale. Every event ID described here has been checked against Microsoft's own documentation. It is written for SOC analysts, detection engineers, incident responders and Windows administrators.

Key takeaways

• Configure advanced audit policy deliberately. Process creation auditing is not configured by default and Kerberos authentication auditing appears only in Microsoft's stronger profile; set subcategories with auditpol or Group Policy and force subcategory settings to win over legacy categories.
• Read logon events by logon type. Event 4624 means little until you know whether it was type 2 (interactive), 3 (network), 5 (service), 9 (NewCredentials) or 10 (RemoteInteractive), and which account and source produced it.
• A small set of IDs carries most of the signal. 4624, 4625, 4648, 4672, 4688, 4697 and 7045, 4698, 4720, 4728, 4732, 4756, 4740, 4771, 4719 and 1102 cover the common attack paths.
• Logs on the host are not evidence. Forward them with Windows Event Forwarding or an agent before an attacker can clear them, and alert on 1102, 104 and 4719.
• Service accounts are where the noise and the risk overlap. Baseline which hosts and logon types each service account uses, then alert on anything outside that pattern.

How Windows event logging works

Windows writes events to channels, stored as .evtx files in %SystemRoot%\System32\winevt\Logs. Event Viewer, Get-WinEvent and wevtutil read the same channels. Security teams need more than the Security log:

• Security: logons, account management, process creation, policy change and object access, controlled by audit policy.
• System: service installation (7045), event log service events and the "other log cleared" event (104).
• Microsoft-Windows-PowerShell/Operational: script block logging (4104) once the policy Turn on PowerShell Script Block Logging is enabled under Windows Components > Windows PowerShell. PowerShell 7 writes to the separate PowerShellCore/Operational channel.
• Task Scheduler, Windows Defender, CodeIntegrity, AppLocker and Sysmon operational channels: task registration, antivirus detections, application control blocks and Sysmon telemetry.

If an event's audit subcategory is off, the event is never written, so check audit policy first when a detection returns nothing.

Configuring advanced audit policy

Use Advanced Audit Policy Configuration (Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration), not the nine legacy categories. Enable the security option Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings, otherwise a legacy category policy can silently override your subcategories. Check the effective result on a host with auditpol /get /category:*.

The table shows Microsoft's published recommendations for the subcategories behind the events in this guide (S = Success, F = Failure).

Process command lines in 4688 are empty unless you enable Administrative Templates\System\Audit Process Creation\Include command line in process creation events. Microsoft warns that command lines can contain passwords readable by anyone with Security log access, so restrict log read rights. Object access subcategories have no Microsoft baseline value; enable them selectively.

Logon events and logon types

Event 4624 ("An account was successfully logged on") is generated on the computer that was accessed, not the one the user sat at. Its Logon Type field is the first thing to read.

Other 4624 fields worth reading: Elevated Token ("Yes" means an administrator session), Virtual Account ("Yes" for managed and group managed service accounts), Authentication Package (Kerberos, NTLM or Negotiate) and Source Network Address. The Logon ID links a logon to that session's 4688 process events and its closing 4634 ("An account was logged off"); it is only unique per computer between reboots, so correlate on both.

Failures, lockouts and explicit credentials

• 4625 (An account failed to log on): read the Status and Sub Status codes: 0xC000006A is a bad password, 0xC0000064 an unknown user name (a run of them suggests enumeration), 0xC0000234 a locked account, 0xC0000072 a disabled account, 0xC000006F outside permitted hours, 0xC0000070 an unauthorised workstation, 0xC0000193 an expired account and 0xC000015B a logon type the account has not been granted.
• 4771 (Kerberos pre-authentication failed): logged only on domain controllers. Failure code 0x18 (KDC_ERR_PREAUTH_FAILED) is a wrong password, and bursts suggest brute force or spraying; 0x17 is an expired password. Password guessing against domain accounts is seen most completely on domain controllers, so collect 4771 and 4776 from every one of them.
• 4740 (A user account was locked out): Caller Computer Name names the host the failing attempts came from, often a stale service account password.
• 4648 (A logon was attempted using explicit credentials): raised by RUNAS, scheduled tasks and some normal operating system activity. Alert when the subject should not hold those credentials or the process is unexpected.
• 4672 (Special privileges assigned to new logon): raised for sessions given sensitive privileges such as SeDebugPrivilege, SeTcbPrivilege, SeBackupPrivilege, SeImpersonatePrivilege or SeLoadDriverPrivilege. Every SYSTEM logon raises it, so alert only when the subject is not SYSTEM, NETWORK SERVICE, LOCAL SERVICE or an expected administrator.

Account and group management events

These events are written where the change happens: domain controllers for domain accounts, the local machine for local accounts. Collect from both.

Microsoft's Appendix L ("Events to Monitor") rates group additions as low criticality, which reflects volume, not impact: an addition to Domain Admins, Enterprise Admins or a server's local Administrators group deserves an alert every time. It rates 4765 and 4766 (SID History added, or a failed attempt) as high, meaning a single occurrence should be investigated. See the Active Directory and Entra ID Hardening Guide.

Process, service, task and script events

• 4688 (A new process has been created): with command line logging on, this is the single most useful hunting event in the Security log. Token Elevation Type %%1937 on a standard workstation means a user ran something elevated; %%1936 with a real user account can mean User Account Control is disabled. Alert on processes started from temporary or user-writable folders.
• 4697 (A service was installed in the system) and 7045: 4697 is in the Security log (Audit Security System Extension, Windows 10 and Server 2016 onwards); 7045 is the System log equivalent ("New Service Installed"). Alert when the service file is outside %windir% or Program Files, when the Service Type is a kernel or file system driver (0x1, 0x2, 0x8), when the start type is boot or system (0, 1), and when the service runs as an account other than LocalSystem, LocalService or NetworkService. Service creation maps to ATT&CK T1543.003.
• 4698 and 4702 (A scheduled task was created / updated): the Task Content field holds the full task XML. Watch tasks in the root of the Task Scheduler Library (\TASK_NAME) and <LogonType>Password</LogonType>, which stores the account password in Credential Manager where an administrator can recover it.
• 4104 (PowerShell script block logging): records the content of all script blocks PowerShell processes, so you see what a script or encoded command actually ran rather than only how it was launched. Microsoft recommends Protected Event Logging when script block logging is used beyond diagnostics, because scripts can contain secrets.

File share, object access and network events

• 5140 (A network share object was accessed): useful on servers for access to administrative shares such as C$ and ADMIN$, and for sources outside internal ranges. Microsoft's page is inconsistent on whether it logs per access or once per session, so test before counting.
• 5145 (A network share object was checked to see whether client can be granted desired access): logged for every file or folder accessed over a share. Failure events appear only for share-level denials, not NTFS denials. Scope it to file servers holding sensitive data.
• 4663 (An attempt was made to access an object): only logged where the object's SACL has a matching audit entry. Use it on a short list of sensitive files and registry keys, filtered on write, delete, WRITE_DAC and WRITE_OWNER.
• 5156 (The Windows Filtering Platform has permitted a connection): records application, direction, addresses, ports and protocol. High volume: keep it for servers that should make few connections and use EDR or Sysmon event 3 elsewhere.

Log clearing and audit tampering

Attackers clear or disable logging to remove evidence (ATT&CK T1685.005, Clear Windows Event Logs, and T1685.001, Disable or Modify Windows Event Log). The events that reveal it:

Clearing is a single command (wevtutil cl Security). Once events are forwarded, clearing the local copy removes nothing the SOC relies on and 1102 becomes a high-fidelity alert. Also alert on hosts that go silent, which can mean logging was stopped.

Collecting and querying logs at scale

Windows Event Forwarding (WEF) is built in: clients forward to a Windows Event Collector (WEC) over WinRM (default ports 5985 for HTTP and 5986 for HTTPS). Microsoft recommends source-initiated subscriptions pushed by Group Policy because they scale best; collector-initiated subscriptions require the collector's account in each client's Event Log Readers group. In a domain, traffic is encrypted with Kerberos by default.

Microsoft plans for about 3,000 events per second per commodity WEC server, says to manage more than 50,000 lifetime sources with wecutil, and warns that above 100,000 the collector's registry can become unreadable. Two caveats: WEF forwards only events created after a subscription reaches the client unless configured to read existing events, and events overwritten in the local log before forwarding are lost silently. Size the local Security log generously with wevtutil sl Security /ms:<bytes>.

For triage on a single host or exported .evtx file:

• wevtutil: wevtutil qe Security /q:"*[System[(EventID=1102)]]" /c:10 /rd:true /f:text returns the ten most recent log-clearing events; wevtutil epl Security C:\IR\security.evtx exports the log for analysis.
• PowerShell: Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} filters at source, far faster than Where-Object.
• DeepBlueCLI: an open source PowerShell module from the SANS blue team that hunts Security, System, PowerShell and Sysmon logs for new users, group additions, password spraying, suspicious services and encoded commands. Run .\DeepBlue.ps1 -log security or point it at an exported .evtx file.

Rolling out Windows security logging

1. Inventory current state. Run auditpol /get /category:* on representative hosts and record log sizes.
2. Pilot the baseline. Apply the Microsoft baseline subcategories, command line capture and script block logging to a pilot group through a dedicated GPO. Measure daily event volume per host for a week.
3. Stand up collection. Deploy at least two WEC servers (clients forward to every published URI) or your agent, and confirm delivery times.
4. Write detections in alert-only mode. Start with 1102, 104, 4719, privileged group additions, new services and tasks, and type 10 or type 2 logons by service accounts. Tune for two to four weeks before paging anyone.
5. Expand by tier. Domain controllers and tier 0 first, then servers, then workstations; apply the stronger settings to domain controllers once storage is sized.
6. Add selective object access. Enable 5145 and 4663 only on named servers and keys, each with an owner.
7. Roll back cleanly. Because settings live in a dedicated GPO, unlinking it reverts hosts at the next refresh; if a subcategory floods a collector, disable that subcategory alone rather than the whole policy.

Where identity fits

Much Security log volume comes from non-human identities: service accounts logging on as type 5, scheduled tasks as type 4, applications authenticating as type 3. Stolen service account credentials produce events that look routine. Build a baseline per service account of the hosts it logs on to, the logon types it uses and whether it receives an elevated token (4672). Alert on interactive (type 2) or Remote Desktop (type 10) logons by any service account, on 4648 events where a process uses a service account's credentials unexpectedly, and on 4698 tasks that store a password. Group managed service accounts show Virtual Account = "Yes" in 4624, separating them from password-based accounts. See the Service Account Security Guide and the ITDR Guide.

Measuring coverage and effectiveness

• Audit policy compliance: percentage of hosts whose effective auditpol output matches the target baseline, by tier.
• Forwarding coverage: percentage of domain-joined hosts that sent Security events in the last 24 hours; every domain controller should be at 100%.
• Forwarding latency: median and 95th percentile time from event creation to arrival in the SIEM for alerting events.
• Log survival: hours of history the local Security log holds on busy servers before rollover, compared with your forwarding delay.
• Detection outcomes: mean time to triage 1102, 4719 and privileged group change alerts, and the false positive rate per rule after tuning.

Framework mapping

Common failure patterns

• Relying on defaults: without Audit Process Creation and command line capture, 4688 is missing or empty and most post-incident questions go unanswered.
• Collecting only from domain controllers: local account creation, local Administrators additions (4732), services (4697, 7045) and tasks (4698) are written on member servers and workstations, where intrusions start.
• Treating EDR as the only record: attackers who reach administrator rights disable security tools. Storm-0501 tampered with security products after moving to domain controllers with Cobalt Strike, as described in the Storm-0501 hybrid cloud attack. Forwarded Security and System logs give an independent trail when the agent goes quiet.
• Logs that roll over before forwarding: a default-sized Security log on a busy file server with 5145 enabled can roll over very quickly. Size logs to cover the longest plausible forwarding outage.
• Alerting on every 4625: failed logons are constant noise. Alert on patterns: bursts of 0xC000006A or 0x18 across many accounts, or failures against privileged or disabled accounts.
• Ignoring the secrets in logs: command lines and script blocks capture passwords and tokens. Restrict log read access, use Protected Event Logging where possible, and scan collected logs for credentials. See the Secrets Management Guide.

Practitioner checklist

• Enable the force-subcategory security option and deploy advanced audit policy through a dedicated GPO.
• Turn on Audit Process Creation with command line capture, and PowerShell script block logging.
• Collect Security, System, PowerShell Operational, Task Scheduler, Defender and (if used) Sysmon channels from every tier, domain controllers first.
• Alert on 1102, 104, 1100 (unplanned) and 4719 with minimum-latency forwarding.
• Alert on additions to privileged groups via 4728, 4732 and 4756, and on 4765 SID History changes.
• Alert on new services (4697, 7045) and scheduled tasks (4698, 4702) outside change windows or with password logon types.
• Baseline logon types and source hosts for every service account and alert on deviations.
• Collect 4771 and 4776 from all domain controllers and detect password spraying by pattern, not single failures.
• Size local logs to survive forwarding outages and alert on hosts that stop reporting.
• Restrict who can read Security and PowerShell logs, because they contain command lines and script content.

Standards and references

• Microsoft: Appendix L, Events to Monitor
• Microsoft: Audit Policy Recommendations
• Microsoft: 4624(S) An account was successfully logged on
• Microsoft: Use Windows Event Forwarding to help with intrusion detection
• Microsoft: Command line process auditing
• Microsoft: wevtutil command reference
• NIST: The NIST Cybersecurity Framework (CSF) 2.0
• SANS Blue Team: DeepBlueCLI

Related NHI Mgmt Group resources: ITDR Guide · Active Directory and Entra ID Hardening Guide · Service Account Security Guide · Privileged Access Management Guide