I Investigated PowerShell With Event ID 4104 and Sysmon. One Event Wasn’t Enough.

In Article 7, I added Sysmon to my Windows endpoint and proved that the telemetry was reaching Splunk.

That gave me visibility into processes, network connections, DNS activity, file creation and registry changes.

But collecting telemetry was not the goal.

I wanted to use it.

So for the next stage of the lab, I created controlled PowerShell activity and investigated what Windows recorded about it.

The question was simple:

Could I move from seeing that PowerShell executed to understanding what it actually did?

First, I Verified Script Block Logging

Before generating anything to investigate, I wanted to verify that PowerShell Script Block Logging was enabled.

I checked:

Get-ItemProperty `
"HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"

The result showed:

EnableScriptBlockLogging : 1

Verifying that PowerShell Script Block Logging was enabled before generating the controlled test activity.

This mattered because I did not want to assume that the telemetry I needed would exist.

Article 7 taught me to validate the sensor.

This time, I was validating the logging capability before relying on it during the investigation.

Then I Created Something I Could Trace

For the test, I used a harmless marker:

SOC-LAB-ARTICLE8-TEST

The activity was intentionally simple.

I was not trying to create a sophisticated attack simulation.

I wanted something distinctive enough that I could generate it, find it again and follow the evidence through the telemetry.

The test included:

$marker = "SOC-LAB-ARTICLE8-TEST"
Write-Output $marker
Get-Process | Select-Object -First 5

Now I had something specific to hunt for.

Event ID 4104 Showed Me the PowerShell Content

I queried the PowerShell Operational log for Event ID 4104 and searched for my marker.

The result was exactly what I wanted.

The event showed:

Id: 4104
ProviderName: Microsoft-Windows-PowerShell

And inside the message was the PowerShell content associated with my controlled test:

$marker = "SOC-LAB-ARTICLE8-TEST"
Write-Output $marker
Get-Process | Select-Object -First 5

Event ID 4104 recording the PowerShell script block used during the controlled lab test.

That changed the investigation.

I was no longer limited to:

PowerShell ran.

I had evidence showing the PowerShell content that had been recorded.

That distinction is important.

Knowing that powershell.exe executed gives me one piece of context.

Seeing the script content gives me another.

Then I Looked at the Same Activity From Sysmon

Next, I moved into Splunk and searched the Sysmon Operational telemetry.

I filtered for Sysmon Event ID 1 and searched for the Article 8 marker.

The search returned 3 events during the displayed window.

Inside the raw Sysmon event, I could see powershell.exe in the process data and the marker appearing within the command-line context.

Sysmon process creation telemetry in Splunk providing process and command-line context around the controlled PowerShell activity.

Now I had two different views of the activity.

PowerShell logging showed me the script block.

Sysmon showed me process creation context.

Neither source had to tell the entire story by itself.

This Is Where Correlation Started Making Sense

Earlier in the lab, I often treated individual log sources as separate things.

Linux authentication logs told one story.

Wazuh alerts gave me another starting point.

Sysmon gave me Windows endpoint telemetry.

But this investigation made the value of combining evidence much clearer.

My investigation path looked like this:

Controlled PowerShell activity
        ↓
PowerShell Script Block Logging
        ↓
Event ID 4104
        ↓
Script content

At the same time:

Controlled PowerShell activity
        ↓
Sysmon
        ↓
Event ID 1
        ↓
Process and command-line context
        ↓
Splunk

Those are different telemetry paths describing related activity.

That is more useful than asking one event to answer every question.

Process Execution and Script Content Answer Different Questions

Sysmon Event ID 1 helped me examine the process execution.

PowerShell Event ID 4104 helped me examine the PowerShell content.

That gave me a better way to think about investigations.

Instead of asking:

Which log source is better?

I can ask:

What question can each source help me answer?

For process telemetry, I may want to know:

What executable ran?

What command line was used?

What process context surrounded it?

For PowerShell logging, I may want to know:

What PowerShell content was recorded?

What commands appeared inside the script block?

Does that content help explain what the process was doing?

The investigation becomes stronger when those answers support each other.

A PowerShell Event Is Not Automatically Malicious

This was also an important reminder.

The activity in this article was generated deliberately by me inside my lab.

The presence of powershell.exe does not prove malicious activity.

Neither does the existence of Event ID 4104.

Those events are evidence of activity.

The analyst still has to interpret that activity in context.

In this case, I already knew the expected behavior because I created the test.

That gave me a controlled way to learn what the telemetry looked like before trying to interpret more suspicious PowerShell behavior.

The Marker Made the Investigation Repeatable

Using:

SOC-LAB-ARTICLE8-TEST

might seem like a small detail.

But it made the experiment easier to validate.

I could generate known activity.

Search for a unique value.

Find the corresponding telemetry.

Then compare what different data sources recorded.

That gave me a repeatable workflow:

Generate known activity
→ identify expected evidence
→ search the telemetry
→ validate the event
→ correlate supporting sources

Instead of starting with an unknown event and guessing what happened, I could first learn what known behavior looked like.

That makes the next investigation easier.

What I Learned

Article 7 was about gaining deeper Windows visibility.

Article 8 was about using it.

The biggest lesson was that one event rarely has to carry the entire investigation.

Sysmon can give me process context.

PowerShell logging can give me script content.

Splunk gives me somewhere to search and connect that evidence.

And the analyst still has to determine what those events mean together.

I started this lab wanting more logs.

Now I am becoming much more interested in a different question:

Which pieces of telemetry do I need to reconstruct what actually happened?

That is the shift I wanted from this project.

Not collecting events for the sake of collecting them.

Using evidence to build the story.