Windows Event ID Threat Mapping: The SOC Analyst’s Secret Weapon for Detecting Hackers in Real Time + Video

By /

Listen to this Post

Featured Image

Introduction:

Windows Event Logs are the heartbeat of any mature security operations center (SOC), but most analysts drown in a sea of IDs without understanding the attacker’s perspective. This article transforms raw Event IDs into a threat-informed detection framework, organizing them by attack phases—from credential abuse to lateral movement—so you can hunt like a seasoned DFIR investigator, not a log reader.

Learning Objectives:

  • Map Windows Event IDs to the MITRE ATT&CK framework and real-world attacker behavior
  • Build detection rules for brute force, persistence, LSASS dumping, and defense evasion using native tools and Sysmon
  • Correlate multiple event IDs (e.g., 4625 → 4624) to identify successful compromises and reduce false positives

You Should Know:

  1. Authentication & Credential Abuse – Detecting Brute Force and Lateral Movement
    Attackers rely on failed logons (4625) followed by a success (4624) to confirm access. Logon Type matters: Type 3 indicates network logon (lateral movement), Type 10 is remote interactive (RDP), and Type 2 is local console. To hunt credential spraying, look for multiple 4625 events across different accounts from the same source IP within seconds.

Step-by-step guide to brute-force detection using PowerShell:

 Query failed logons in the last 24 hours
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4625; StartTime=(Get-Date).AddDays(-1)} | 
Select-Object TimeCreated, @{Name='Account';Expression={$<em>.Properties[bash].Value}}, 
@{Name='SourceIP';Expression={$</em>.Properties[bash].Value}} |
Group-Object SourceIP | Where-Object {$_.Count -gt 10} | 
Format-Table -AutoSize

Windows Audit Policy Configuration (Command Line):

auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Account Logon" /success:enable /failure:enable
  1. Process Execution & LOLBins – Hunting Living-off-the-Land Binaries
    Event ID 4688 (process creation) is gold—but only if command-line logging is enabled. Attackers abuse powershell.exe -EncodedCommand, certutil -urlcache, mshta.exe script.hta, and rundll32.exe javascript:"\..\mshtml,RunHTMLApplication". Enable command-line inclusion via GPO or registry to see the full payload.

Enable command-line logging in Windows:

reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

Detect encoded PowerShell commands with Event ID 4104 (Script Block Logging):

Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" | Where-Object {$<em>.Id -eq 4104 -and $</em>.Message -match "EncodedCommand"}

Sysmon config snippet to log all process creations with hashes:

<Sysmon schemaversion="4.30">
<EventFiltering>
<ProcessCreate onmatch="include">
<CommandLine condition="contains">cmd.exe</CommandLine>
<CommandLine condition="contains">powershell</CommandLine>
</ProcessCreate>
</EventFiltering>
</Sysmon>
  1. Persistence Mechanisms – Scheduled Tasks, Services, and Registry Run Keys
    Attackers love Event ID 4698 (scheduled task created) and 7045 (new service installed). Check for tasks that run as SYSTEM or launch from temp directories. Registry persistence (4657) targets HKLM\Software\Microsoft\Windows\CurrentVersion\Run.

Monitor for suspicious scheduled tasks using wevtutil:

wevtutil qe Security /rd:true /f:text /c:20 /q:"[System/EventID=4698]" | findstr /i "schtasks.exe"

Detect new services pointing to non-system paths (PowerShell one-liner):

Get-WinEvent -LogName System | Where-Object {$<em>.Id -eq 7045} | 
Select-Object TimeCreated, @{n='ServiceName';e={$</em>.Properties[bash].Value}}, 
@{n='ImagePath';e={$<em>.Properties[bash].Value}} |
Where-Object {$</em>.ImagePath -1otmatch "C:\Windows\System32"}

Manual persistence hunting (Registry Run keys):

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /s
reg query HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /s
  1. LSASS & Credential Dumping – Detecting Mimikatz and Procdump
    Event ID 4656 (handle to LSASS requested) and Sysmon Event ID 10 (ProcessAccess) with `TargetImage` containing `lsass.exe` are critical. Attackers use `procdump -ma lsass.exe` or mimikatz sekurlsa::logonpasswords. Enable Sysmon with process access monitoring.

Sysmon config to log LSASS access attempts:

<ProcessAccess onmatch="include">
<TargetImage condition="end with">lsass.exe</TargetImage>
<CallTrace condition="contains">dbghelp.dll|dbgcore.dll</CallTrace> <!-- Typical for dumpers -->
</ProcessAccess>

Detect LSASS dump using Event Viewer command line:

wevtutil qe "Microsoft-Windows-Sysmon/Operational" /rd:true /c:50 /q:"[System/EventID=10 and EventData/Data[@Name='TargetImage']='C:\Windows\System32\lsass.exe']"

Windows Defender Attack Surface Reduction (ASR) rule to block LSASS theft:

Add-MpPreference -AttackSurfaceReductionRules_Ids "9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2" -AttackSurfaceReductionRules_Actions Enabled
  1. Lateral Movement – Network Logons, Share Access, and Remote Service Creation
    Event ID 4624 with LogonType 3 (network logon) combined with 5140 (share accessed) and 7045 (service installed) indicates PsExec/WMI lateral movement. Track `LogonProcessName` = `NtLmSsp` for NTLM or `Kerberos` for domain auth.

Correlate network logon to share access (PowerShell):

$netLogons = Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} | Where-Object {$_.Properties[bash].Value -eq 3}
$shareAccess = Get-WinEvent -FilterHashtable @{LogName='Security'; ID=5140}
 Manual correlation by timestamp and computer name

Enable network share auditing:

auditpol /set /subcategory:"File Share" /success:enable /failure:enable

Detect PsExec service creation (Event ID 7045 with service name “PSEXESVC”):

Get-WinEvent -FilterHashtable @{LogName='System'; ID=7045} | Where-Object {$_.Message -match "PSEXESVC"}
  1. Defense Evasion – Log Clearing, Policy Changes, and Service Takedowns
    Event ID 1102 (audit log cleared) is a screaming indicator of compromise. Attackers also use `wevtutil cl Security` or powershell Clear-EventLog. Event ID 4719 indicates audit policy changes (disabling logging). Monitor 7036 for security service stops (e.g., WinDefend, Sysmon).

Detect log clearing attempts:

Get-WinEvent -LogName Security -MaxEvents 100 | Where-Object {$<em>.Id -eq 1102} | 
Select-Object TimeCreated, @{n='User';e={$</em>.Properties[bash].Value}}

Prevent non-administrators from clearing logs via GPO:

  • Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment → “Manage auditing and security log” → Add only `SYSTEM` and `Administrators`

    Monitor for Sysmon service stop (Event ID 7036 from Service Control Manager):

    wevtutil qe System /rd:true /c:10 /q:"[System/EventID=7036 and EventData/Data[@Name='param1']='Sysmon']"
  1. High-Risk Detection Combinations – From Brute Force to Ransomware
    Three killer combos every SOC must build rules for:
  2. 4625 → 4624 (within 10 seconds) = successful brute force. Add `LogonType=3` for lateral movement.
  3. 4688 (powershell.exe) + 7045 (new service) = download cradle leading to persistence. Look for `-EncodedCommand` and temp paths.
  4. 4104 (EncodedCommand) + 4656 (LSASS handle) = PowerShell-based credential dumping (e.g., Invoke-Mimikatz).

Example KQL query (for Sentinel/Splunk) for combo 1:

EventID=4625 | join kind=inner (EventID=4624) on $left.AccountName==$right.AccountName
| where (timediff(TimeCreated_left, TimeCreated_right) between (0s..10s))
| project TimeCreated_right, AccountName, SourceIP

Splunk correlation search:

index=windows sourcetype="WinEventLog:Security" (EventCode=4625 OR EventCode=4624)
| transaction AccountName maxspan=10s
| where eventcount=2
| table _time, AccountName, Source_Network_Address

What Undercode Say:

  • Key Takeaway 1: Memorizing Event IDs is useless without understanding the attack chain. The shift from Tier-1 alert triage to detection engineering requires mapping IDs to MITRE tactics (TA0006 – Credential Access, TA0008 – Lateral Movement) and building behavioral correlations, not single-signature rules.
  • Key Takeaway 2: Most organizations fail to enable command-line logging (4688 with details) and PowerShell Script Block Logging (4104), leaving 90% of modern attacks invisible. This single misconfiguration is why attackers still succeed with LOLBins—enabling these logs should be the first hardening step.

Analysis (10+ lines): The structured categorization by attack phase transforms raw telemetry into actionable intelligence. For SOC analysts, understanding that a 7045 (service install) alone is noise, but when paired with a 4688 from `powershell.exe` downloading a remote payload, it becomes a high-fidelity detection, is the difference between missing Cobalt Strike and catching it pre-execution. The post correctly emphasizes “normal vs. malicious” baselining—for example, 4624 LogonType 3 from a jump box is normal, but from a random workstation at 3 AM is a red flag. Threat hunters should build watchlists for event combinations rather than isolated IDs. Additionally, Sysmon (especially Event IDs 1, 3, 10, 11, 22) dramatically enriches Windows logging, yet less than 20% of enterprises deploy it. The DFIR community increasingly relies on Event ID 4769 (Kerberos service ticket) for Golden Ticket detection and 4776 for NTLM relay. Finally, the rise of EDR has not replaced Event Logs—instead, logs provide the forensic truth when EDR telemetry is tampered with. The future belongs to detection-as-code where these event relationships are version-controlled and tested continuously.

Prediction:

  • +1 Proliferation of automated threat-informed SIEM rules – Tools like Sigma will convert these event combos into detection rules for Splunk, Sentinel, and ELK, lowering the barrier for small SOCs to hunt like Fortune 500 teams.
  • +1 Integration of Event ID mapping into AI-driven co-pilots – LLMs trained on DFIR knowledge will auto-generate hunt queries from plain English (e.g., “show me brute force success”) and explain why a specific event combo matters.
  • -1 Attackers shift to abusing Event Tracing for Windows (ETW) blind spots – As Event IDs become universally monitored, adversaries will increasingly target ETW providers that are not logged by default (e.g., Microsoft-Windows-Kernel-Process) and disable logging via kernel callbacks.
  • -1 Rise of “log-less” living-off-the-land attacks – Using WMI persistent subscriptions, .NET assembly injection without process creation, or callback functions in trusted processes (e.g., Outlook VBA) will bypass Event ID 4688 entirely, requiring new detection primitives.

▶️ 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: Dharamveer Prasad – 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

Related Posts: