Imagine you are the security guard of a massive office building. Every time someone enters, leaves, opens a cabinet, or tries to break in — it gets recorded in a logbook. Now imagine if that logbook could automatically tell you when something suspicious happened. That is exactly what Windows Event Logs are — the logbook of your Windows system, and for a SOC analyst, it is the single most important source of truth.
In this blog, we will break down Windows Event Logs from scratch — what they are, how to read them, how to query them like a pro using PowerShell, and most importantly, which Event IDs you must memorize for your SOC analyst interview. Let's dive in.
1. What Are Windows Event Logs?
Windows Event Logs are records that Windows automatically creates whenever something significant happens on the system — a user logs in, a service crashes, a file is accessed, an audit policy changes, a script runs. Think of it as the operating system constantly writing a diary of everything that happens.
These logs are stored as .evtx files on the system and can be viewed using multiple tools. The default location is:
C:\Windows\System32\winevt\Logs\Each log entry (called an Event) contains:
- Event ID — a unique number identifying what happened
- Source — which application or component generated the log
- Level — severity: Information, Warning, Error, Critical, Verbose
- Timestamp — when it happened (always in UTC in raw logs)
- User — which account was involved
- Computer — which machine it happened on
- Description / Details — the full story of what happened
2. Types of Windows Event Logs
There are five default log categories in Windows:
| Log Name | What It Records | SOC Relevance |
|---|---|---|
| Security | Logons, logoffs, privilege use, object access, policy changes | 🔴 Highest — this is where attacks show up |
| System | OS-level events: driver failures, service crashes, reboots | 🟡 Medium — useful for detecting persistence |
| Application | Events from installed applications and programs | 🟡 Medium — malware may write here |
| Setup | Events during Windows installation and updates | 🟢 Low — rarely used in SOC |
| Forwarded Events | Logs collected from remote machines via WEF | 🔴 High — centralized monitoring |
Beyond these defaults, Windows also has Applications and Services Logs — these are more specific logs like:
Microsoft-Windows-PowerShell/Operational— PowerShell activity (critical for detecting attacks)Microsoft-Windows-Sysmon/Operational— Sysmon events (process creation, network connections)Microsoft-Windows-TaskScheduler/Operational— Scheduled task activity
3. Tools to Read and Query Event Logs
There are three main ways to interact with Windows Event Logs. As a SOC analyst, you will use all three depending on the situation.
A. Event Viewer (GUI)
The built-in graphical tool. Open it by running eventvwr.msc. Good for quick manual investigation, but not scalable when you have thousands of events. You can
create Custom Views to filter by Event ID, time range, and log source — great for narrowing down during an investigation.
B. wevtutil (Command Line)
A powerful command-line tool built into Windows. Great for scripting and automation.
# List all available logs
wevtutil el
# Get details about the Security log
wevtutil gl Security
# Query the last 5 Security events in readable text format
wevtutil qe Security /c:5 /rd:true /f:text
# Export a log to a file
wevtutil epl Security C:\backup\security.evtxC. Get-WinEvent (PowerShell) — The Analyst's Best Friend
This is the most powerful and flexible method. You can filter by Event ID, time, keyword, XPath, and even query offline .evtx files — perfect for forensic investigation.
# Query live Security log for failed logons (Event ID 4625)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625}
# Query an offline evtx file with XPath — find PowerShell script block logs
Get-WinEvent -Path "$env:USERPROFILE\Desktop\merged.evtx" `
-FilterXPath "*[System[(EventID=4104)]]" -Oldest -MaxEvents 1 | Format-List
# Filter by Event ID and time range
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4624
StartTime = '2024-01-01'
EndTime = '2024-01-31'
}
# Search for specific username in failed logon events
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} |
Where-Object { $_.Message -like "*administrator*" }
# Count events grouped by Event ID
Get-WinEvent -LogName Security |
Group-Object Id | Sort-Object Count -Descending | Select-Object -First 10Format-List shows ALL fields of an event. Format-Table gives a compact view. Always use Format-List when you need to
read the full event message during investigation.
4. XPath Filtering — Precision Querying
XPath is a query language used to filter events with surgical precision. Think of it like SQL but for event logs. Windows Event Viewer actually generates XPath in the background when you use its filter UI — you can copy it directly and use it in PowerShell.
# XPath: Find Event ID 4625 (failed logon) from Security log
Get-WinEvent -LogName Security `
-FilterXPath "*[System[(EventID=4625)]]"
# XPath: Find events in a specific time range
Get-WinEvent -LogName Security -FilterXPath `
"*[System[TimeCreated[@SystemTime>='2024-01-01T00:00:00.000Z']]]"
# XPath: Filter by Event ID AND a specific username from an evtx file
Get-WinEvent -Path "C:\Logs\security.evtx" -FilterXPath `
"*[System[(EventID=4625)] and EventData[Data[@Name='TargetUserName']='admin']]"The XPath structure always follows: *[System[(condition)]] for system-level fields and EventData[Data[@Name='FieldName']='Value'] for event-specific
data fields.
5. Key Event IDs Every SOC Analyst Must Know
This is the most important section for your interview. Hiring managers love asking "which Event IDs do you monitor for X attack?" Here is a grouped reference:
Account Logon & Authentication
| Event ID | What It Means | Why SOC Cares |
|---|---|---|
| 4624 | Successful logon | Baseline normal activity; anomalies = lateral movement |
| 4625 | Failed logon | Multiple failures = brute force attack |
| 4634 | Account logoff | Session duration tracking |
| 4648 | Logon with explicit credentials | Pass-the-Hash, runas abuse |
| 4740 | Account locked out | Brute force or password spray attack |
| 4768 | Kerberos TGT requested | Kerberoasting, AS-REP Roasting detection |
| 4769 | Kerberos service ticket requested | Kerberoasting — watch for RC4 encryption type (0x17) |
| 4771 | Kerberos pre-auth failed | Password guessing against domain accounts |
Account & Group Management
| Event ID | What It Means | Why SOC Cares |
|---|---|---|
| 4720 | New user account created | Attacker creating backdoor accounts |
| 4726 | User account deleted | Covering tracks after creating rogue account |
| 4728 / 4732 / 4756 | Member added to security / local / universal group | Privilege escalation — especially adding to Administrators |
| 4738 | User account changed | Password reset, account modifications by attacker |
Process & Execution
| Event ID | What It Means | Why SOC Cares |
|---|---|---|
| 4688 | New process created | Detect malicious processes: cmd.exe spawned by word.exe |
| 4104 | PowerShell script block logged | Detects obfuscated/malicious PowerShell — most important for detecting living-off-the-land attacks |
| 4103 | PowerShell module logging | Module-level PowerShell activity |
| 7045 | New service installed | Malware installing as a service for persistence |
Scheduled Tasks
| Event ID | What It Means | Why SOC Cares |
|---|---|---|
| 4698 | Scheduled task created | Classic persistence mechanism used by malware |
| 4702 | Scheduled task updated | Attacker modifying existing tasks to execute malware |
| 4699 | Scheduled task deleted | Covering tracks after execution |
Audit & Log Tampering — Critical Red Flags
| Event ID | What It Means | Why SOC Cares |
|---|---|---|
| 1102 | Security audit log was cleared | 🚨 Major red flag — attacker destroying evidence |
| 104 | System log was cleared (in System log) | 🚨 Same as above but for System log |
| 4719 | System audit policy changed | Attacker disabling logging to avoid detection |
| 4656 | Handle to an object was requested | File/registry access monitoring |
6. Logon Types — What 4624 Is Really Telling You
Event ID 4624 (Successful Logon) includes a Logon Type field. This single field tells you HOW someone logged in, which completely changes the meaning of the event.
| Logon Type | Name | Meaning |
|---|---|---|
| 2 | Interactive | Physical keyboard logon at the machine |
| 3 | Network | Accessing shared folders, network resources — most common |
| 4 | Batch | Scheduled task ran as a specific user |
| 5 | Service | A service started and logged on |
| 7 | Unlock | Workstation unlocked from screensaver |
| 8 | NetworkCleartext | Network logon with password sent in plaintext — 🚨 suspicious |
| 10 | RemoteInteractive | RDP logon — very important to monitor |
| 11 | CachedInteractive | Logon using cached domain credentials (offline) |
In an investigation, Type 3 logons from unexpected machines or times = lateral movement. Type 10 logons from external IPs = suspicious RDP access. Type 8 = credentials sent in cleartext = immediate concern.
7. Detecting Real Attacks Using Event Logs
Scenario 1: Brute Force Attack
An attacker tries to guess a user's password repeatedly. You will see a flood of Event ID 4625 (failed logon) from the same source IP, followed eventually by either 4740 (account lockout) or 4624 (successful logon) — which means they got in.
# Detect multiple failed logons
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} |
Group-Object {$_.Properties[5].Value} |
Sort-Object Count -Descending |
Select-Object Name, CountScenario 2: Suspicious PowerShell Execution
Attackers love using PowerShell because it is already installed on every Windows machine. Event ID 4104 logs the actual script content — even if it was obfuscated, Windows logs the decoded version.
# Find PowerShell script block events from an evtx file
Get-WinEvent -Path "$env:USERPROFILE\Desktop\merged.evtx" `
-FilterXPath "*[System[(EventID=4104)]]" -Oldest -MaxEvents 1 | Format-ListLook for keywords in the message: Invoke-Mimikatz, IEX, DownloadString, EncodedCommand, bypass,
hidden — these are classic signs of malicious PowerShell.
Scenario 3: Attacker Clearing Logs
After a successful attack, experienced attackers clear logs to destroy evidence. This generates Event ID 1102 in the Security log — ironically logged just before they wipe everything else.
# Check if security log was cleared
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102}Scenario 4: Persistence via Scheduled Task
Malware creates a scheduled task to survive reboots. Watch for Event ID 4698 (task created) especially when the task points to unusual paths like
%TEMP%, %APPDATA%, or runs encoded PowerShell.
8. Log Tampering — The Attacker's Cover-Up
Sophisticated attackers do not just exploit systems — they cover their tracks. There are multiple ways they try to tamper with event logging:
- Clearing logs —
wevtutil cl Securityor via Event Viewer → Event ID 1102 - Disabling audit policy —
auditpol /set /category:* /success:disable→ Event ID 4719 - Stopping the event log service —
sc stop eventlog→ logged in System log before it stops - ETW tampering — manipulating Event Tracing for Windows at the provider level (advanced, stealthy)
- Patching the log service in memory — most advanced technique, covered in the Palantir blog on ETW tampering
9. Interview Q&A — SOC Analyst Edition
Q: What Event ID would you look for to detect a brute force attack?
A: Event ID 4625 (failed logon). I would look for a high volume of 4625 events from the same source IP or targeting the same account in a short time window. I would then correlate with 4740 (account lockout) and check if it was followed by a 4624 (successful logon), which would indicate the attacker succeeded.
Q: An attacker cleared the Security event log. How do you know?
A: Windows logs Event ID 1102 when the Security log is cleared, and this event itself captures who cleared it and when. I would also check the System log for Event ID 104. Additionally, a sudden gap in event timestamps is a strong indicator even if 1102 itself was removed.
Q: How do you detect malicious PowerShell activity?
A: I would look at Event ID 4104 in the Microsoft-Windows-PowerShell/Operational log, which captures script block logging. This logs the actual
decoded content of PowerShell scripts. I would search for suspicious keywords like Invoke-Expression, IEX, DownloadString,
EncodedCommand, and Mimikatz. I would use: Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; Id=4104}
Q: What is the difference between Event ID 4624 Logon Type 3 and Logon Type 10?
A: Logon Type 3 is a network logon — accessing shared folders or resources over the network. Logon Type 10 is a RemoteInteractive logon — meaning someone connected via RDP. In an investigation, Type 10 from an unexpected external IP is a strong indicator of unauthorized RDP access, while unusual Type 3 logons from machines that should not be talking to each other indicate lateral movement.
Q: How would you query an offline .evtx file for a specific Event ID?
A: Using PowerShell's Get-WinEvent with the -Path parameter and XPath filter:
Get-WinEvent -Path "C:\path\to\file.evtx" `
-FilterXPath "*[System[(EventID=4625)]]" | Format-ListThis is extremely useful in forensic investigations where I am analysing a disk image or exported log files from a compromised machine.
Q: What is Kerberoasting and which Event ID helps detect it?
A: Kerberoasting is an attack where an attacker requests Kerberos service tickets for service accounts and then attempts to crack them offline. The key indicator is Event ID
4769 (Kerberos service ticket requested) where the Ticket Encryption Type is 0x17 (RC4-HMAC). Legitimate modern environments use AES
encryption, so RC4 requests are a red flag — especially if many are seen from one account in a short period.
Q: How would you detect a new persistence mechanism via scheduled tasks?
A: I would monitor Event ID 4698 (scheduled task created) in the Security log, or Microsoft-Windows-TaskScheduler/Operational log. I would look
for tasks that run from unusual paths like %TEMP%, %APPDATA%, or execute encoded PowerShell commands. Any task created outside of known change windows or
by non-admin accounts warrants immediate investigation.
Q: What is the significance of Event ID 4719?
A: Event ID 4719 means the System Audit Policy was changed. Attackers use this to disable logging so their subsequent actions are not recorded. If I see 4719 followed by a drop in expected event volume, it is a strong sign that an attacker is trying to blind our monitoring. This should trigger an immediate alert in any SIEM.
10. Quick Reference Cheat Sheet
=== MUST-KNOW EVENT IDs ===
LOGON/AUTHENTICATION
4624 - Successful logon
4625 - Failed logon (brute force indicator)
4648 - Logon with explicit credentials (Pass-the-Hash)
4740 - Account locked out
4768 - Kerberos TGT requested
4769 - Kerberos service ticket requested (Kerberoasting)
4771 - Kerberos pre-auth failed
ACCOUNT MANAGEMENT
4720 - User account created
4726 - User account deleted
4728/4732/4756 - Member added to group
EXECUTION / PERSISTENCE
4688 - New process created
4104 - PowerShell script block logged
4698 - Scheduled task created
7045 - New service installed
TAMPERING / COVER TRACKS
1102 - Security log cleared 🚨
104 - System log cleared 🚨
4719 - Audit policy changed
=== POWERSHELL QUICK COMMANDS ===
# Query live log
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625}
# Query offline evtx file
Get-WinEvent -Path "C:\path\to\file.evtx" -FilterXPath "*[System[(EventID=4104)]]" | Format-List
# Count by Event ID
Get-WinEvent -LogName Security | Group-Object Id | Sort-Object Count -Descending
# Filter by username
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} |
Where-Object { $_.Message -like "*administrator*" }Final Thoughts
Windows Event Logs are not just a collection of system messages — they are the story of everything that happened on a machine. As a SOC analyst, your job is to read that story and find the chapters where something went wrong. The more fluent you become with Event IDs, PowerShell querying, and XPath filtering, the faster you will be able to identify threats before they become full-blown incidents.
Start with the Security log. Learn the critical Event IDs. Practice querying .evtx files with PowerShell. And always remember — if someone cleared the logs, that itself is the loudest alarm of all.
Keep practising on TryHackMe, and you will be investigation-ready in no time.
Comments
Post a Comment
Please do not enter any spam link here.