How I Investigate a Suspicious PowerShell Alert in a SOC Lab
A walkthrough of the exact triage workflow, event correlation steps, and command-line decoding techniques used to analyze suspicious PowerShell execution.
1. Evaluating the Initial Alert Context
Key heuristic: Standard business users opening Word or Excel should almost never spawn PowerShell or cmd.exe as child processes.
When a SIEM alert fires indicating that powershell.exe has executed with unusual flags (such as -EncodedCommand, -ExecutionPolicy Bypass, or -WindowStyle Hidden), the first instinct should not be panic. System administrators and automated IT software (such as SCCM, Datadog, or backup utilities) frequently use PowerShell.
An analyst must immediately examine three primary attributes: the user account executing the command, the host role (desktop workstation vs. domain controller), and whether the execution occurred interactively or via an automated parent service.
2. The Critical Role of Parent Process Trees
In Windows Event Log analysis, Event ID 4688 (Process Creation) or Sysmon Event ID 1 provides the ParentImage and ParentCommandLine fields. This is where high-fidelity triage begins.
If WINWORD.EXE or EXCEL.EXE is the parent of powershell.exe, malicious macro execution is by far the most likely explanation. Conversely, if the parent process is C:\Program Files\ManagementAgent\agent.exe, the alert is far more likely to be a benign administrative task requiring rule tuning.
index=endpoint_winevt EventCode=1 (Image="*\\powershell.exe" OR Image="*\\pwsh.exe")
| table _time, ComputerName, User, ParentImage, Image, CommandLine
| sort -_time3. Decoding Obfuscated Command Lines
Attackers frequently use the -EncodedCommand parameter. In Windows PowerShell, this expects a Base64-encoded Unicode (UTF-16LE) string. An analyst should never paste suspicious commands directly into an active terminal to see what happens.
Instead, decode the string safely using an offline tool like CyberChef or a local Python script using base64.b64decode(). Inspect the decoded string for download cradles (e.g. Net.WebClient, Invoke-WebRequest) or references to remote IP addresses.
python3 -c "import base64; print(base64.b64decode('SQBFAFgAIAAoAE4AZQB3AC0ATwBi...').decode('utf-16le'))"4. Correlating Process Activity with Network Sockets
Once you know what the script attempted, you must determine whether the attempt succeeded. This is the difference between an attempted attack and an active breach.
Query Sysmon Event ID 3 (Network Connection) matching the ProcessGuid or ProcessId of the PowerShell instance. Look for outbound connections to external or non-standard internal IP addresses. A connection to the same host and port that the decoded command references, followed by a new file write (Sysmon Event ID 11) or process creation, indicates the download cradle succeeded.
5. Determining True Positive vs. Benign Admin Tooling
If the payload reached out to an unknown staging IP and dropped a secondary script into %TEMP% or %APPDATA%, classify the alert as a True Positive. Immediately notify the incident response team, isolate the host at the network layer, and capture forensic memory if required by your runbook.
Document every indicator of compromise (IOC)—the parent hash, the script hash, destination IPs, and domain names—in your ticketing system.