How to Read Windows Event Logs: A SOC Analyst Guide

To read a Windows event log, open Event Viewer, go to the channel that matters (Security, System, Application, or a Sysmon log), filter by Event ID, and read the XML view instead of the friendly summary. The XML exposes every EventData field, including LogonType and SubStatus codes, that the plain-English tab hides or blurs into one vague sentence.

What Windows Event Logs Actually Are

Every Windows machine keeps a running record of what happened on it, split into channels by purpose. Open Event Viewer (eventvwr.msc) and the left pane shows Windows Logs at the top: Application, Security, Setup, System, and Forwarded Events. Below that sits Applications and Services Logs, a larger tree where individual applications, drivers, and optional tools like Sysmon write their own dedicated channels.

Application captures events from software running on the machine: a service crashing, an installer finishing, a driver logging a warning. It's the least security-relevant of the three main channels, though malware sometimes trips it incidentally.

System captures operating-system-level events: a service starting or stopping, a driver failing to load, the machine booting or shutting down. It populates automatically with no configuration required, useful for confirming timeline basics (when did this host last reboot) even when nobody turned on security auditing.

Security is where most tier-1 triage happens, and it's the one channel that doesn't populate on its own: it logs only what the local or domain audit policy tells it to, covering logons, object access, privilege use, and account or group changes. A default install audits comparatively little; a hardened, SOC-monitored environment audits logon events, process creation, and several account-management categories at minimum. If an event you expect isn't showing up, check the audit policy before assuming the log itself is broken.

Sysmon, Microsoft's free System Monitor tool from the Sysinternals suite, is not a Windows Log at all. It installs its own channel under Applications and Services Logs > Microsoft > Windows > Sysmon > Operational, filling gaps native logging leaves open: full command lines on process creation, network connection metadata, and file hashes the built-in Security log skips by default. It has to be installed deliberately, so an environment with no Sysmon channel present is worth flagging, not assuming.

Opening and Filtering in Event Viewer

Launch the console with eventvwr.msc from the Run dialog, or search "Event Viewer" from the Start menu. Remote viewing needs the right permissions and the Remote Event Log Management firewall rule enabled on the target.

Once a channel is open, Filter Current Log (right-click the channel, or the Actions pane) is where almost all real work happens. The dialog lets you filter by:

• Event level (Critical, Warning, Verbose, Error, Information)
• Event ID, entered as a comma-separated list (4624,4625,4648) or a range
• Time range, from the last hour to a custom window
• Keywords, task category, and user

For anything beyond a single ad hoc filter, build a Custom View instead. Custom Views pull from multiple channels at once and save as a named, reusable query. That's the closest Event Viewer gets to SIEM-style behavior on one machine: a saved query for "every 4625 across Security in the last 24 hours" you can reopen without rebuilding the filter each time.

The XML tab inside the Filter Current Log dialog is worth learning early. It exposes the filter as a raw XPath query against the log, and once you can read and edit it directly, you can write filters the point-and-click UI does not expose cleanly, like combining an Event ID list with a specific field value.

Anatomy of a Single Event: Why the XML View Beats the Friendly View

Click any event and Event Viewer shows two tabs: General and Details. General renders a plain-English sentence describing what happened. Details has two sub-views: Friendly View, a formatted but still simplified rendering, and XML View, the raw structured data.

Every event has two parts. The System block carries metadata identical in shape across every event type: Provider Name, EventID, Level, Task, Keywords, TimeCreated, EventRecordID, Channel, Computer, and, for security-relevant events, the Security UserID of the account involved. The EventData block carries fields specific to that event ID: a 4625's EventData includes TargetUserName, LogonType, IpAddress, Status, and SubStatus; a 4688's includes NewProcessName, ParentProcessName, and (if command-line auditing is on) CommandLine.

The friendly view causes three specific problems. It flattens hex status codes into a paraphrase, so a SubStatus of 0xC000006A can render as a vague "unknown user name or bad password" line that hides which of the two happened, and the two point to different investigations. It drops fields the template author didn't consider important, which isn't the same as unimportant to you. And you cannot copy a friendly-view sentence into a SIEM search or a detection rule; you can copy the exact field name and value straight out of the XML.

The Security Events Analysts Live In

A small set of Security event IDs covers the overwhelming majority of tier-1 triage. Here is what each one is actually for, not just what it's named.

4624, successful logon, is your baseline. Every legitimate session starts with one, and the field that matters most is LogonType: type 2 is interactive at the console, type 3 is a network logon (accessing a share, say), and type 10 is RemoteInteractive, meaning RDP. A type 10 4624 on a server that should never take interactive remote logons reads very differently than the same event on an admin's own workstation (Microsoft's 4624 reference has the full logon-type table).

4625, failed logon, is the other half of the pair, and its value sits almost entirely in the SubStatus field, not the raw count. A wave of 4625s can mean an active brute-force attempt or a scheduled task retrying an expired password every five minutes. MITRE ATT&CK catalogs this under T1110, Brute Force; its sub-techniques (password guessing, spraying, credential stuffing) map directly onto the SubStatus and TargetUserName patterns in the worked example below.

4688, process created, is the native process-execution event. It fires whenever a new process starts, but the CommandLine field only populates if command-line auditing is separately enabled by policy. Without that, a 4688 tells you powershell.exe ran, not what it was told to do, exactly the gap Sysmon's Event ID 1 closes.

4672, special privileges assigned, fires alongside a logon when the account gets admin-equivalent rights (SeDebugPrivilege, SeBackupPrivilege) for that session. Seeing it paired with a logon from an account that shouldn't normally carry those rights is worth chasing, especially when the logon itself traces back to a stolen but valid credential.

4720, user account created, matters because unauthorized account creation is a common persistence move: an attacker with enough access adds a new account, often under an innocuous name, as a foothold that survives a password reset on the account they actually compromised.

1102, security log cleared, is one of the highest-priority events in the entire channel, because legitimate reasons to clear the audit log outside a documented maintenance window are rare. It maps to T1070, Indicator Removal, the defense-evasion technique covering an attacker erasing evidence after the fact. Seeing it fire is a strong argument for treating everything before it as suspect.

These six IDs are a starting point, not the ceiling. For the full reference (all 31 Windows and Sysmon event IDs tier-1 analysts are expected to recognize, with the exact fields and detection notes for each) see the Windows event IDs cheat sheet; for the technique IDs behind them, the technique library has the detection detail. The point of this guide is the reading skill, not the list.

Reading Logs at Scale: Event Viewer vs. a SIEM

Event Viewer is genuinely useful, and fundamentally single-host. It can't tell you the same source IP hit three different servers in the last ten minutes, because each server keeps its own log on its own disk with its own retention limit. Once a channel's configured size caps out, older events get overwritten, and on a busy domain controller that can mean a Security log covering only the last few hours.

This is why centralized logging is a discipline, not a convenience. Joint guidance from CISA and international partners on event logging best practices frames comprehensive, centrally collected logging as foundational to network visibility and threat detection, not an optional hardening step. Microsoft's own Events to Monitor reference lists the high-value Active Directory and Windows events organizations are expected to forward and retain centrally.

A SIEM, or Windows Event Forwarding feeding into one, ingests the same raw events at the same field level from every monitored host at once. The TargetUserName, LogonType, and IpAddress fields you'd read manually in XML View become searchable columns across the whole environment. Reading a 4625 in Event Viewer and reading one in Splunk or Sentinel is the same field-level literacy, just at different scale. Analysts who only click through pre-built SIEM alerts, without ever reading the raw event, tend to struggle the moment a rule is slightly off or a technique has no rule written for it yet.

A Worked Micro-Triage Example: A Burst of 4625s

Your SIEM flags 40 events with EventID=4625 across a three-minute window on a domain-joined server. Here is what you actually read, in order, and why each field changes the conclusion.

LogonType first. If every event shows LogonType=3 (network logon), the attempts are coming in over the network, likely against SMB or RPC, rather than someone physically at the console. LogonType=10 would point instead toward RDP.

TargetUserName next. This is where the pattern splits into two very different stories.

Pattern A: all 40 events target the same account, say j.martinez, from the same source IpAddress. This is a brute-force attempt against one account, MITRE T1110.001, and the next field to check is SubStatus.

Pattern B: the 40 events spread across 35 different TargetUserName values, most not real accounts, from the same source IpAddress, with LogonType=3 throughout. This is reconnaissance-flavored, closer to T1110.003, password spraying: testing which usernames exist and trying a small set of common passwords against each, staying under any single-account lockout threshold.

Status and SubStatus confirm which story you're in. Microsoft's 4625 documentation lists the sub-status codes in full; the four worth knowing cold are 0xC0000064 (username does not exist), 0xC000006A (correct username, wrong password), 0xC0000234 (account locked out), and 0xC0000072 (account disabled). In Pattern A, a long run of 0xC000006A against one account is a guessing attack in progress. In Pattern B, mostly 0xC0000064 (the attacker is still probing which accounts are real) with a handful of 0xC000006A mixed in tells you which of those 35 usernames are actually valid, useful intelligence regardless of whether the spray succeeds.

IpAddress ties the burst to a single source, internal or external, and is what you pivot on next: has that address touched anything else in the environment in the same window?

The step that changes everything: check whether any 4624 follows from the same IpAddress against the same TargetUserName the burst was hitting. No success means an attempt, worth blocking and monitoring. A success means compromise, and the investigation moves straight into what that account did next, starting with whether a 4672 fired alongside it granting elevated rights.

Common Beginner Mistakes

Reading the friendly-view sentence and stopping there. "An account failed to log on" is true of every single 4625 regardless of cause. The SubStatus code is the actual finding; the sentence is not.

Ignoring LogonType entirely. A 4624 with LogonType=10 on a server with no business taking interactive RDP is a materially different event than the same ID with LogonType=3 from an expected service account. Treating every successful logon as equivalent throws away the field that would have told you something was wrong.

Assuming every 4625 burst is an attack. Expired credentials on a scheduled task, a stale mapped drive, or a misconfigured service account retrying on a loop all generate the same event ID at volume. TargetUserName and timing (steady, evenly spaced retries vs. a sudden burst) usually distinguish the two; jumping to "brute force" on count alone produces false escalations.

Not correlating 4625 with the 4624 that might follow it. A burst of failures alone is an attempt. The same burst followed by one success from the same source is a compromise, and the two deserve very different urgency. Analysts who close the alert without checking for a following success are the ones who miss the actual incident.

Treating 1102 as automatically malicious, or automatically benign. Log clearing inside a documented, ticketed maintenance window is routine. The same event with no change record, especially right after a suspicious logon sequence, is one of the strongest single indicators of an attacker covering their tracks. The event ID alone doesn't tell you which situation you're in; the surrounding context does.

Where This Fits Into Your Triage Workflow

Reading Windows event logs well is a field-level habit, not a memorized list of numbers. The events above are worth knowing, but the real skill is reflexively pulling up XML View, reading LogonType, Status, SubStatus, and the account and IP fields, and asking what story those values tell before reaching a conclusion. That habit is what alert triage actually is at the log level: not recognizing an event ID, but reading the fields underneath it fast enough to know what to do next.

The same discipline scales once those events land in a SIEM instead of a single machine's Event Viewer: the query language changes, but the fields you're reading and the questions you're asking of them do not. If you want to practice this on a console that behaves like a real one, with noisy, realistic Windows telemetry instead of a clean textbook example, SOCSimulator's SIEM and XDR environments are built around exactly that gap, free to start.