Investigating a Suspicious PowerShell Alert with Wazuh and Sysmon

The purpose of this exercise was to practise a simple L1 workflow. When an alert appears, I want to be able to quickly understand what happened, identify the parts that make it suspicious, collect the relevant context, and know when I have enough information to escalate.

The Alert

The investigation started with a PowerShell alert appearing in Wazuh.

I opened the alert to see what had actually triggered it.

The command line immediately caught my attention:

"powershell.exe" -NoProfile -WindowStyle Hidden -Command "Write-Output 'SOC lab simulation'"

"powershell.exe" -NoProfile -WindowStyle Hidden -Command "Write-Output 'SOC lab simulation'"

At first glance, the command itself doesn't actually do anything harmful. It simply outputs the text SOC lab simulation.

That is because this was a controlled lab environment. I intentionally created the command so that it would generate PowerShell telemetry without performing any destructive or malicious activity.

However, as an analyst, I wouldn't only look at what the command does. I would also look at how it is being executed.

Two arguments stood out:

-NoProfile
-WindowStyle Hidden

-NoProfile
-WindowStyle Hidden

Neither of these automatically means that PowerShell is malicious. PowerShell is a legitimate administrative tool, and these options can have legitimate uses.

However, hidden PowerShell execution is also a technique that can appear in real-world attacks. An attacker who wants to execute PowerShell without presenting an obvious window to the user may use hidden execution.

That made the command worth investigating further.

What I Checked

Rather than immediately deciding that the alert represented a compromise, I started collecting the context around the PowerShell process.

The information I wanted to establish included:

• Hostname
• User account
• Timestamp
• PowerShell command line
• Parent process
• Process ID
• Activity immediately before execution
• Activity immediately after execution

The Sysmon Event ID 1 event provided much of this information.

The event showed:

FieldFindingProcesspowershell.exeUserDESKTOP-96GH4UH\cyberlabHostDESKTOP-96GH4UHEventSysmon Event ID 1 — Process CreateParent processpowershell.exeCommandpowershell.exe -NoProfile -WindowStyle Hidden ...

The parent process was another PowerShell process.

The process relationship was therefore:

powershell.exe
    └── powershell.exe

powershell.exe
    └── powershell.exe

This was useful context because it showed how the process had been created rather than simply showing that PowerShell existed on the system.

What Made It Suspicious?

At this point, I wanted to separate suspicious from malicious.

The command itself was harmless in this lab.

I therefore couldn't honestly say that I had discovered malware.

What I could say was that the execution contained characteristics that warranted investigation.

The use of -WindowStyle Hidden was particularly interesting because hidden PowerShell execution can be seen in malicious activity where an attacker wants to reduce visibility.

The important point is that this was a contextual indicator, not proof of compromise.

This is why I didn't treat every PowerShell execution as malicious. PowerShell is extremely common in Windows environments, and legitimate administrators and applications use it regularly.

The alert simply gave me a reason to investigate.

When I Stopped

After reviewing the command line and collecting the relevant process context, I decided to stop my L1 investigation.

I could have continued much deeper by analysing the PowerShell activity, looking for network connections, persistence, child processes, or other indicators of compromise.

But that wasn't necessary for this exercise.

My objective at L1 was to establish:

What happened?

PowerShell executed.

What did it execute?

A command using -NoProfile and -WindowStyle Hidden.

Who and where?

The cyberlab user on DESKTOP-96GH4UH.

When?

The timestamp recorded by Sysmon.

What launched it?

Another PowerShell process.

Is there enough reason for further investigation?

Yes.

At that point, I had enough context to escalate the suspicious activity rather than attempting to determine the entire attack chain myself.

L1 Assessment

The appropriate disposition for the lab exercise was:

Suspicious — Escalate to L2

The escalation would allow the next analyst to investigate the PowerShell activity in greater depth and determine whether there was a legitimate explanation or additional malicious behaviour.

Useful follow-up investigation could include reviewing:

• Process and child-process activity
• PowerShell operational logs
• Network connections
• Persistence mechanisms
• Other activity from the same user or endpoint
• Similar PowerShell executions elsewhere in the environment

What I Learned

This investigation reinforced an important lesson for me:

PowerShell itself isn't suspicious. Context is what matters.

If I saw powershell.exe in an alert and immediately called it malicious, I would be making an assumption.

Instead, I looked at the command line, noticed characteristics that can be associated with attacker behaviour, and then gathered the surrounding context.

I also learned that a harmless command can still be useful for practising detection and investigation. The goal of the lab wasn't to execute real malware. It was to generate realistic telemetry and practise the analyst workflow.

Most importantly, I practised knowing when to stop.

Once I had enough information to explain why the activity was suspicious and why deeper investigation was warranted, I didn't need to keep digging simply to make the investigation longer.

That is where I would hand the case to L2.

Conclusion

This was a relatively small investigation compared with the RDP scenario, but that was part of the point.

The workflow was straightforward:

Wazuh alert → inspect command → identify suspicious characteristics → collect context → assess → escalate

The investigation demonstrated how a relatively simple PowerShell alert can be assessed using endpoint telemetry without immediately assuming that the activity is malicious.

This investigation was performed in a controlled lab environment. The PowerShell command was intentionally harmless and was created solely to generate telemetry for SOC investigation practice.

About Me

I'm a software developer transitioning into cybersecurity, with a focus on SOC operations and defensive security. I'm BTL1 certified and currently building hands-on experience through SOC labs involving Wazuh, Sysmon, Windows Security Logs and incident investigation.

More of my security projects and investigation reports are available on my GitHub.

I'm currently open to SOC Analyst / Cybersecurity Analyst opportunities.

GitHub LinkedIn