One of my biggest imaginations when I started my cybersecurity journey was assuming that security tools were the most important thing to learn.

I thought learning SIEMs, EDRs, and dashboards would make me a better analyst.

What I eventually discovered is that the real skill lies in understanding the evidence.

This Windows Endpoint Investigation completely changed how I approach endpoint security monitoring. Instead of looking at alerts, I learned how to reconstruct attacker activity using Sysmon telemetry and Windows logs, just like a SOC analyst responding to a real incident.

This investigation involved USB malware execution, malicious HTA files, registry persistence, scheduled tasks, Alternate Data Streams (ADS), Empire C2 communications, and credential access attempts.

By the end of the investigation, I was no longer hunting for answers. I was hunting for evidence.

The Challenge

The objective was straightforward.

Investigate several Windows hosts and determine:

• How malware initially executed
• How persistence was established
• How command and control communications occurred
• What evidence remained on the endpoint

Unlike previous labs, there was no step-by-step guide.

The logs contained the answers.

My job was to find them.

Building an Investigation Mindset

One of the lessons I learned early in this exercise was that opening every event log is not investigation.

Investigation starts by asking:

• What behavior am I looking for?
• Which event IDs record that behavior?
• What evidence would exist if the activity actually occurred?

This shifted my approach completely.

Instead of reading everything, I began filtering aggressively.

Key Sysmon Event IDs

Throughout the investigation, I relied heavily on:

• Event ID 1 – Process Creation
• Event ID 3 – Network Connection
• Event ID 9 – RawAccessRead
• Event ID 11 – File Creation
• Event ID 13 – Registry Value Modification

These five event IDs told almost the entire attack story.

Investigation 1 – USB Malware Execution

The first scenario involved a suspicious USB device.

My first challenge was determining whether the USB had actually executed anything malicious.

I began investigating registry activity and quickly identified the connected device:

HKLM\System\CurrentControlSet\Enum\WpdBusEnumRoot\UMB...

This provided evidence that the removable device had been connected to the host.

Next, I pivoted to Sysmon Event ID 9.

This revealed:

\Device\HarddiskVolume3

Raw disk access immediately stood out because legitimate software rarely interacts with removable media at that level without reason.

Finally, I reviewed process creation activity.

The first executable launched was:

rundll32.exe

At this point the attack timeline became clear:

USB Device Connected
↓
Registry Artifact Created
↓
RawAccessRead Activity
↓
rundll32.exe Execution

The evidence strongly suggested malicious execution originating from the USB device.

Investigation 2 – HTML That Wasn't Really HTML

The second investigation initially looked harmless.

A user had downloaded:

update.html

However, Sysmon process creation events revealed a different story.

The file ultimately launched:

C:\Windows\System32\mshta.exe

This immediately raised suspicion.

The actual payload executed was:

update.hta

stored within Temporary Internet Files.

The attack chain looked like this:

update.html
↓
mshta.exe
↓
update.hta
↓
Outbound Network Connection

Using Sysmon Event ID 3, I identified the remote host:

10.x.x.18

and the back-connect port:

4443

This demonstrated how attackers abuse trusted Microsoft binaries to bypass basic defenses.

Investigation 3 – Registry Persistence and Empire C2

This was my favorite part of the entire room.

The attacker stored a payload inside the registry:

HKLM\SOFTWARE\Microsoft\Network\debug

Initially, I was overwhelmed by the number of logs available.

Eventually, I focused exclusively on:

• Event ID 3
• Event ID 13

That decision made the investigation much easier.

The registry value contained an encoded payload which was later executed using PowerShell.

The launch command retrieved data from the registry and executed it dynamically.

Further investigation revealed communication with:

empirec2

and the remote host:

172.xx.1.2x3

At this point the attack chain became:

Registry Payload
↓
PowerShell Retrieval
↓
Execution
↓
Empire Command and Control

This was the first time I truly understood how attackers can hide payloads inside seemingly harmless registry locations.

Investigation 3.2 – Scheduled Task Persistence

The next persistence mechanism involved:

schtasks.exe

The attacker stored payload data within an Alternate Data Stream:

c:\users\q\AppData:blah.txt

and created a scheduled task to execute it.

This technique was particularly interesting because it combined:

• ADS abuse
• PowerShell execution
• Scheduled Task persistence

While investigating the task creation activity, I also discovered suspicious access to:

lsass.exe

which immediately suggested credential access attempts.

Investigation 4 – Command and Control Communications

The final scenario focused on command and control infrastructure.

Using network connection events, I traced communications back to:

172.xx.1.2x3

Further evidence identified the framework being used:

Empire

At this point, the complete attacker workflow had become visible.

Challenges I Faced

The biggest challenge was not understanding Sysmon.

The biggest challenge was understanding where to focus.

Initially, I opened everything.

This quickly became overwhelming.

Eventually I learned to ask:

"What evidence should exist if this behavior occurred?"

That single question transformed the investigation.

Instead of reading logs, I started hunting.

SOC Analyst Report Notes

Executive Summary

During endpoint investigation activities, multiple malicious behaviors were identified, including execution from removable media, HTA-based malware delivery, registry-based persistence, scheduled task persistence, command and control communications, and credential access attempts.

Findings

• USB-based malware execution identified through registry artifacts and RawAccessRead events.
• Malicious HTA payload executed through mshta.exe.
• Registry-stored payload discovered under HKLM\SOFTWARE\Microsoft\Network\debug.
• Empire C2 communications detected.
• Scheduled task persistence established using schtasks.exe.
• Alternate Data Streams used to conceal payload data.
• Suspicious access to lsass.exe observed.

Recommendations

• Enable Sysmon across Windows endpoints.
• Monitor Event IDs 1, 3, 11, and 13.
• Alert on mshta.exe execution.
• Alert on schtasks.exe creating new tasks.
• Monitor PowerShell registry retrieval activity.
• Detect access attempts against lsass.exe.
• Implement centralized logging and threat hunting procedures.

Final Thoughts

This Windows Endpoint Investigation taught me more about real-world endpoint monitoring than many dashboard-focused labs.

The value was not in learning a tool. The value was learning how to reconstruct attacker behavior from evidence.

I felt more like a SOC analyst building a timeline from telemetry. That shift in mindset is what made this investigation memorable.

See the next storyline on Endpoint Security Monitoring: Threat Hunting with Osquery through real endpoint investigations

Visit my everyday Cyber Playground