Top 20 Windows Event IDs That Catch Every Hacker Red-Handed: SOC Analyst’s Ultimate Detection Cheat Sheet + Video

Listen to this Post

Featured Image

Introduction:

Windows Event Logs are the silent witnesses of every digital crime—they capture authentication attempts, privilege escalations, and attacker movements in real time. For SOC analysts and defenders, mastering key Event IDs transforms raw log data into actionable threat intelligence that can stop breaches before they escalate. This article unpacks the most critical Windows Event IDs every defender must monitor, provides hands-on hunting techniques using native tools, and guides you through building a detection strategy aligned with the MITRE ATT&CK framework.

Learning Objectives:

  • Identify the top 20 Windows Security Event IDs that reveal malicious activity, including brute-force attacks, privilege escalations, and persistence mechanisms.
  • Execute advanced log hunting using PowerShell’s Get-WinEvent, Sysmon, and Windows Event Collector for real-world threat detection.
  • Implement defensive logging configurations and SIEM correlation rules to minimize blind spots in enterprise Windows environments.

You Should Know:

  1. The Essential Windows Event IDs Defenders Must Track

Windows Event IDs serve as breadcrumbs that trace an attacker’s journey through a compromised system. Below is a curated list of high-impact Event IDs every SOC analyst should prioritize, organized by attack phase.

Authentication & Logon Activity:

  • 4624 – Successful Logon: Tracks every successful authentication. Pay close attention to Logon Type—Type 10 (RDP) and Type 3 (Network) often indicate lateral movement.
  • 4625 – Failed Logon: The classic brute-force indicator. A rapid succession of 4625 events from a single source points to password spraying or dictionary attacks.
  • 4648 – Logon with Explicit Credentials: Triggered when `RunAs` or pass-the-hash techniques are used. This is a red flag for credential replay attacks.
  • 4672 – Special Privileges Assigned: Marks admin-level logons. Service accounts generating this event often suggest privilege misuse.
  • 4768 – Kerberos TGT Requested: Essential for detecting Golden Ticket attacks. Watch for unusual request volumes or tickets with abnormally long lifetimes.
  • 4769 – Kerberos Service Ticket Requested: Correlate with 4768 to identify Kerberoasting attempts, especially when paired with weak RC4 encryption (encryption type 0x17).

Account & Group Manipulation:

  • 4720 – User Account Created: Unexplained account creations often signal attacker-controlled backdoor accounts.
  • 4728 / 4732 – Added to a Security Group: Unauthorized additions to Domain Admins or Local Administrators groups are high-severity events. Monitor 4732 for local group changes.
  • 4740 – Account Locked Out: Can indicate brute-force success or account takeover attempts.

Persistence & Execution:

  • 7045 – New Service Installed: Attackers frequently install malicious services for persistence. Cross-reference unknown service names with process creation logs.
  • 4688 – New Process Created: A goldmine for threat hunting when process command-line auditing is enabled. Focus on parent-child process anomalies (e.g., `winword.exe` spawning powershell.exe).

Defense Evasion:

  • 1102 – Audit Log Cleared: Almost always malicious—attackers erase traces of their activity. This event should trigger an immediate high-severity alert.
  • 4719 – System Audit Policy Changed: Rare in legitimate scenarios; tampering indicates an attempt to disable logging.

Sysmon Events (if deployed):

  • Event ID 1 – Process Creation: Provides richer process details than 4688, including parent process and hash.
  • Event ID 3 – Network Connections: Reveals outbound C2 beaconing and lateral movement over RDP, WinRM, or SMB.
  • Event ID 10 – ProcessAccess: Detects LSASS memory access attempts, a telltale sign of credential dumping.
  1. Hunting Like a Pro: PowerShell and Native Tools for Log Analysis

Mastering native Windows tools transforms raw logs into actionable intelligence. Below are step-by-step guides using PowerShell’s `Get-WinEvent` and the command-line utility wevtutil.

Step 1: Enumerate Available Event Logs

 PowerShell: List all logs with record counts
Get-WinEvent -ListLog  | Where-Object { $_.RecordCount } | Format-Table LogName, RecordCount
 Command List log names
wevtutil el

This reveals which logs (Security, System, Application, Sysmon/Operational) are actively populated. It is important to identify all available data sources before hunting.

Step 2: Hunt for Suspicious Process Creations

The following query searches the Security log for process creation events (4688) where a Microsoft Office application spawned a command-line process.

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4688} | Where-Object {
$<em>.Message -match 'winword.exe|excel.exe|powerpnt.exe' -and
$</em>.Message -match 'powershell|cmd|wscript|cscript'
} | Select-Object TimeCreated, @{Name='ProcessInfo'; Expression={$_.Message}}

This command filters event ID 4688 and then narrows results to suspicious parent-child relationships, a common tactic used in phishing attacks.

Step 3: Detect Brute-Force Attacks by Aggregating Failed Logons
This snippet groups failed logon events (4625) by source IP address and counts occurrences over the last hour, identifying potential brute-force activity.

$StartTime = (Get-Date).AddHours(-1)
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4625; StartTime=$StartTime} |
Group-Object { $_.Properties[bash].Value } |  Property 18 is source IP
Where-Object Count -gt 10 |
Select-Object Name, Count

When more than 10 failures originate from the same IP within an hour, it is a strong indicator of an ongoing password spray or brute-force attack.

Step 4: Audit Log Clearing Detection

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=1102} |
Select-Object TimeCreated, @{Name='User'; Expression={$_.Properties[bash].Value}}

Event ID 1102 is rare in healthy environments. Any occurrence should trigger an immediate investigation.

Step 5: Export Logs for Deeper Analysis

For advanced hunting, export filtered logs to CSV and analyze them in tools like Excel or Splunk.

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624,4625,4688,4672} |
Export-Csv -Path "C:\SecurityLogs\suspicious_events.csv" -1oTypeInformation

CSV exports enable correlation across time ranges and event types, which is essential for building timelines.

3. Deploying Sysmon: A Step-by-Step Configuration Guide

Sysmon dramatically enhances visibility into process injection, network connections, and registry changes. Follow these steps to deploy and configure Sysmon for threat detection.

Step 1: Download and Install Sysmon

 Download Sysmon from Microsoft
Invoke-WebRequest -Uri "https://live.sysinternals.com/sysmon64.exe" -OutFile "C:\Sysmon\sysmon64.exe"
 Install Sysmon with default schema
C:\Sysmon\sysmon64.exe -accepteula -i

The default schema captures minimal events. For full coverage, a custom configuration file is required.

Step 2: Deploy a Production-Ready Configuration

A recommended starting point is the Wazuh-optimized Sysmon configuration, which includes 150+ detection rules for process creation and 200+ exclusions to reduce false positives. Use the following command to apply it:

sysmon64.exe -c sysmon_config.xml

This configuration captures Event IDs 1, 2, 3, 5, 6, 7, 8, 9, and 10, providing deep coverage of MITRE ATT&CK techniques.

Step 3: Verify Sysmon is Logging Correctly

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; ID=1} -MaxEvents 10

If results appear, Sysmon is operational and capturing process creation events.

Step 4: Correlate Sysmon Events with Security Logs

For advanced detection, join Sysmon process creation events with Security log logon events:

$processEvents = Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; ID=1} -MaxEvents 100
$logonEvents = Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} -MaxEvents 100
 Correlate by ProcessId (Sysmon) and LogonId (Security)

Correlation between Sysmon Event ID 1 (process creation) and Security Event ID 4624 (successful logon) allows analysts to link suspicious processes directly to the user who launched them.

4. Forwarding Logs with Windows Event Collector (WEC)

Centralizing logs from multiple endpoints is critical for enterprise detection. Windows Event Collector (WEC) enables subscription-based log forwarding.

Step 1: Configure the Collector Server

Open Event Viewer, navigate to Subscriptions, and create a new subscription. Set the source computers to the desired endpoint group and select critical events (e.g., 4624, 4625, 4688, 1102).

Step 2: Enable Forwarding on Source Machines via Group Policy

 Enable WinRM
Enable-PSRemoting -Force
 Set Windows Remote Management service to automatic
Set-Service WinRM -StartupType Automatic
 Start the service
Start-Service WinRM

The source computers must have WinRM enabled and firewall rules allowing inbound traffic on TCP 5985.

Step 3: Verify Event Forwarding

 On the collector, check subscription status
wevtutil gl "Microsoft-Windows-EventCollector/Operational"

Successful forwarding is evidenced by events appearing in the collector’s ForwardedEvents log.

  1. Building a Threat Hunting Dashboard with ELK / Wazuh

For SOC analysts, a centralized SIEM turns raw logs into actionable dashboards. Below is a simplified approach using open-source tools.

Step 1: Install Wazuh (All-in-One)

curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh
sudo bash wazuh-install.sh -a

Wazuh provides a pre-configured dashboard and automatically ingests Windows Event Logs when the Wazuh agent is installed on endpoints.

Step 2: Configure Windows Agent to Forward Event IDs

In `C:\Program Files (x86)\ossec-agent\ossec.conf`, add:

<localfile>
<location>Security</location>
<log_format>eventchannel</log_format>
</localfile>

Restart the Wazuh agent service. The Security log will then be streamed to the Wazuh manager for real-time analysis.

Step 3: Create Detection Rules

Wazuh uses custom rules. Add the following to `local_rules.xml` to alert on log clearing:

<group name="windows,security,">
<rule id="100010" level="12">
<if_sid>60101</if_sid>
<id>1102</id>
<description>Audit log was cleared on $(hostname)</description>
</rule>
</group>

This rule triggers a level 12 alert (high severity) whenever Event ID 1102 is detected, allowing immediate response to log tampering.

What Undercode Say:

  • Mastering Windows Event IDs is non-1egotiable for SOC analysts; the difference between a missed breach and a timely containment often lies in interpreting a single event code like 4624 or 1102.
  • Automated hunting with PowerShell `Get-WinEvent` and `wevtutil` enables rapid, scriptable log analysis at scale—essential for enterprises lacking a full SIEM.
  • Event logs without proper audit policy configuration create dangerous detection blind spots; ensure advanced audit policies (e.g., process command-line, PowerShell logging) are enabled via GPO.
  • Sysmon deployment transforms Windows logging from basic to forensic-grade, but must be tuned with exclusions to avoid log overload—start with community configurations like Wazuh’s.
  • Forwarding logs to a central collector or SIEM is the only way to maintain visibility across distributed environments; Windows Event Collector offers a free, native solution for log aggregation.

Prediction:

  • -1 Attackers are rapidly shifting to living-off-the-land techniques that blend into normal process execution, making simple event ID monitoring insufficient without behavioral analytics and entity baselining.
  • +1 The adoption of community-driven Sysmon configurations and open-source SIEMs like Wazuh will democratize enterprise-grade detection, enabling smaller teams to achieve high-fidelity threat hunting.
  • +1 AI-powered log analysis tools will increasingly automate the correlation of Event IDs across multiple logs, reducing mean time to detection by flagging anomaly clusters (e.g., rapid 4625→4624→4688 sequences).
  • -1 As attackers gain access to endpoint logging configurations, we will see a rise in attacks that disable or tamper with Event Tracing for Windows (ETW) before execution, bypassing standard log sources entirely.
  • +1 Integration of LetsDefend-style hands-on simulations into SOC training programs will produce a new generation of analysts capable of interpreting Event IDs in real attack contexts, closing the skills gap in threat detection.

▶️ Related Video (76% Match):

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: Syed Muneeb – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky