Module 3: Windows Event Logs & Finding Evil

This module is about using Windows logs to find suspicious activity. I kept the Skill Assessment separate because it is much more command-heavy. This page is the main Module 3 notes page, with the same images and same technical points from my draft, just organized into a cleaner blog structure.

Module 3 Navigation

Reusable PowerShell detectors and XML first-pass queries: HTB-CDSA on GitHub

Windows Event Logs

Windows Event Logs are one of the most important artifacts from a Windows operating system. They are crucial for intrusion detection and diagnostic analysis, but they can also get overwhelming because of the amount of logs a system might generate.

The default Windows logs include:

Windows Event Log anatomy showing the five core log categories, essential event components, severity levels, and XML-level filter fields.

XML Filtering and Correlation

Filtering with XML is very useful when you want to sort for specific fields. For example, it can help correlate multiple events back to a specific user session and build a timeline of activity.

It is also very important to understand what is normal in the network. That helps reduce false positives. Log centralization also matters because it allows logs to be collected, parsed, correlated, and alerted on in real time. This connects directly to what the previous SIEM module covered.

Key security Event IDs are important to keep in mind, but the real conclusion usually comes from correlation.

Mind map of critical Windows Security Event IDs for XML filtering and correlation, split between access/authentication and system tampering/persistence.

Sysmon

Then comes Sysmon.

Sysmon is a Windows system service and device driver that remains active across system reboots. It provides deep forensic visibility by logging system activity that typically does not appear in standard Security Event logs.

Meme reference from the module (not a technical diagram).

Sysmon uses an XML-based configuration file to filter which events to include or exclude, for example based on process names or IP addresses. Popular configurations include SwiftOnSecurity’s Sysmon config, which I also used while working on labs.

Log Location: Once configured and running, Sysmon events can be viewed in Event Viewer under:

Applications and Services -> Microsoft -> Windows -> Sysmon

Sysmon has different Event IDs.

Reference: Sysmon Event IDs 1-12 with category and description (see References - Microsoft Sysmon / Cyberdom).

In this module, the main Sysmon Event IDs discussed were 1, 3, 7, and 10. The module then used those Event IDs across different detection scenarios where Sysmon can help.

Detection Scenario A: DLL Hijacking and Injection

This section incorporates different types of DLL hijacking and injection to give a more complete overview for my notes.

Context

At its core, DLL hijacking is a technique where an attacker tricks a trusted, legitimate application into loading a malicious DLL instead of the one it actually needs. Attackers use this for stealthy execution, persistence, and privilege escalation.

While people often use terms like “DLL Injection,” “DLL Spoofing,” and “DLL Side-Loading” interchangeably, DLL Hijacking works well as the umbrella term when a malicious DLL takes over from a legitimate one.

Different Types of DLL Hijacking and Injection

Depending on how an application is configured to load its required files, attackers can choose from a variety of injection and hijacking approaches.

Reference: DLL hijacking and injection techniques (see References - Wietze Beukema).

Indicators of Compromise to Monitor

By monitoring Sysmon Event ID 7 (Image / Module Loaded), defenders can spot signs of injection and hijacking regardless of which specific executable is being exploited.

Detection Scenario B: Unmanaged PowerShell / C# Injection

C# is a “managed” language, meaning it relies on the Common Language Runtime (CLR) to process its bytecode. Standard Windows processes, like the print spooler spoolsv.exe, are “unmanaged” and do not use the CLR.

The Attack

Attackers inject unmanaged PowerShell or C# bytecode into an unmanaged process.

Indicators of Compromise

You will see a sudden transition of a process from an unmanaged to a managed state. Using Event ID 7 or tools like Process Hacker, look for unexpected loading of Microsoft .NET Runtime components into processes that typically never require them.

It is also worth noting that a legitimate .NET application loads clr.dll within milliseconds of starting. If a process has been running for 60+ seconds and suddenly loads clr.dll, that is injection behavior, not normal startup.

Detection Scenario C: Credential Dumping / Mimikatz

Attackers read LSASS memory to extract credentials. Sysmon Event ID 10 logs every time one process opens a handle to another, making it the primary detection point.

The Four IOCs, in Order of Confidence

GrantedAccess examples:

The important reminder here is that detection should be agnostic. Do not anchor only on process names. LSASS itself can be renamed, and dumping tools can be renamed too. GrantedAccess, path, user mismatch, and CallTrace anomalies are harder to hide.

ETW: Event Tracing for Windows

Another section was ETW.

According to Microsoft, ETW is a general-purpose, high-speed tracing facility built deep within the Windows operating system. It relies on a buffering and logging mechanism implemented directly in the kernel to trace events generated by both user-mode applications and kernel-mode device drivers.

Why Use ETW?

In threat detection, relying only on standard log data can fall short. ETW captures a wide range of telemetry sources, such as system calls, network activity, process creation and termination, and file or registry modifications. This provides much deeper system activity.

Performance

ETW is designed to be lightweight with minimal performance impact, making it useful for real-time monitoring. To prevent system resource exhaustion, many high-volume event providers are disabled by default and only activate when a tracing session specifically requests them.

ETW Architecture

ETW publish-subscribe architecture: Controllers, Providers, Sessions, Consumers, and Trace Files.

Some useful ETW providers mentioned in the module:

ETW monitoring areas for kernel activity and protocol/execution telemetry.

Some telemetry is so sensitive and powerful that Microsoft actively shields it from both standard users and potential attackers.

To harness ETW, analysts use the Publish-Subscribe architecture: Controllers manage sessions, Providers generate events, and Consumers read them, often saving them to .ETL files for offline analysis.

Real-Time Monitoring vs Long-Term Storage

When implementing ETW or standard logging strategies, organizations must understand the difference between active monitoring and historical archiving.

Practical ETW Hunting with SilkETW

For practicality, a toolset I am keeping on my radar is SilkETW. It helps bridge some gaps left by standard monitoring tools.

Reference: SilkETW ETW collection wrapper (see References).

While ETW provides incredible telemetry, interacting with it natively can be complex. SilkETW acts as a user-friendly wrapper that collects ETW data, saves it to formats like JSON, and can even forward event logs into the standard Windows Event Viewer through SilkService for centralized visibility.

Detection Scenario 1: Defeating Parent PID Spoofing

Understanding normal parent-child process relationships is crucial. For example, calc.exe should never spawn cmd.exe. However, attackers know this and try to manipulate those relationships.

• The Attack (Parent PID Spoofing): Attackers spoof the parent process ID. For instance, code executed through powershell.exe can spoof process creation to make it look like a legitimate system service, such as spoolsv.exe, spawned a malicious cmd.exe.
• The Sysmon Blindspot: Sysmon Event ID 1 is vulnerable to this technique and may incorrectly log the spoofed parent.
• The SilkETW Solution: Capturing data from the Microsoft-Windows-Kernel-Process ETW provider can bypass spoofed metadata and identify the true creator of the process.

Detection Scenario 2: “Bring Your Own Land” (BYOL) Attacks

• The Evolution: Defenders became good at catching “Living off the Land” attacks, where attackers abuse native tools like PowerShell. In response, attackers pivoted to “Bring Your Own Land.”
• How BYOL Works: Instead of relying on native tools, attackers bring custom-built .NET assemblies, such as C# tools or payloads like Seatbelt, and execute them entirely in memory.
• Why Attackers Love .NET: It is installed by default on Windows. The CLR handles memory automatically, leaving fewer artifacts. It can execute purely in memory without dropping files to disk, and it provides built-in libraries for HTTP connections and cryptography. Cobalt Strike’s execute-assembly command heavily relies on this.
• The Sysmon Limitation: Sysmon Event ID 7 can detect .NET attacks by watching for sudden loading of core .NET DLLs like clr.dll and mscoree.dll. However, this is noisy and does not provide granular details about the actual content or payload of the loaded assembly.

Deep Inspection with the DotNETRuntime Provider

To get the full picture of an in-memory .NET attack, analysts can use SilkETW to tap into the Microsoft-Windows-DotNETRuntime ETW provider.

By using filters in SilkETW, such as keyword 0x2038, defenders can extract useful information, including actual method names being executed.

Get-WinEvent Notes

The Get-WinEvent cmdlet is the main tool I used for deep, programmatic log analysis and threat hunting. I spent a good amount of time with it, so I made this table for myself to remember the important commands and parameters.

The simple rule for reference

Whenever I am building custom filters, especially for things like encoded PowerShell in Sysmon Event ID 1, I want to follow this three-step rule:

1. Grab one single event.
2. Look closely at its XML structure.
3. Then build the specific filter.

Where AI Can Help

This module is where AI started to feel practically useful for me, not as a replacement for analysis, but as a way to move faster through the repetitive parts of log hunting.

For my own workflow, I built a Claude Skill and used NotebookLM connectors to give the model better context, especially around Microsoft documentation for Get-WinEvent, XML filtering, Sysmon fields, and event log structure. That helped me ask better questions and generate cleaner PowerShell query ideas during the Skill Assessment.

For hunters, this can be crucial. Query writing takes time, especially when dealing with large .evtx files, nested XML fields, and different Sysmon event IDs. If the model already has the right documentation and examples in context, it can help draft Get-WinEvent, FilterXPath, or XML parsing logic much faster.

But the important part is still verification. LLMs helped me when I had the right context, especially during the Skill Assessment, but I still had to inspect the XML and understand the fields myself. The model can help write the query, but I have to know whether the query is actually looking at the right field, event ID, timestamp, or process relationship and can be your best friend in times when you get stuck.

The practical AI workflow I want to keep using:

1. Use official docs and notes as context.
2. Ask AI to help draft the first query.
3. Test the query manually.
4. Inspect one raw event’s XML.
5. Correct the query based on the real fields.
6. Use AI again to clean or extend the query once the logic is proven . Can take many iterations but helpful enough.

That balance matters. AI speeds up the hunting workflow, but the analyst still owns the evidence.

References

[HTB Academy] Certified Defensive Security Analyst (CDSA) - Module 3: Windows Event Logs & Finding Evil. https://academy.hackthebox.com/

[HTB-CDSA] Sysmon threat detection scripts and XML queries for CDSA Module 3. https://github.com/kismatkunwar89/HTB-CDSA

[SBousseaden] Common Windows Normal Processes Parent/Child Relationships (process tree mind map). https://twitter.com/SBousseaden

[SwiftOnSecurity] sysmon-config (Sysmon configuration baseline). https://github.com/SwiftOnSecurity/sysmon-config

[Cyberdom] Microsoft Sentinel and Sysmon 4 Blue Teamers. https://cyberdom.blog/microsoft-sentinel-and-sysmon-4-blue-teamers/

[Wietze Beukema] Hijacking DLLs in Windows. https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows

[Microsoft] Get-WinEvent (PowerShell cmdlet documentation). https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent

[Microsoft] About Event Tracing (ETW overview). https://learn.microsoft.com/en-us/windows/win32/etw/about-event-tracing

[FireEye] SilkETW (ETW collection wrapper). https://github.com/fireeye/SilkETW

[EtwExplorer] ETW provider metadata explorer. https://github.com/zodiacon/EtwExplorer

Skill Assessment

Since the skill assessment notes are much longer and more command-heavy, I kept them separate from this page. The Key Takeaway, full .evtx investigation walkthrough, and all six questions are here: Module 3: Skill Assessment