Investigating Suspicious PowerShell: A SOC Analyst Evidence Chain
A lab-based walkthrough from alert to structured investigation using process context, command-line evidence, network indicators, ATT&CK mapping, and reporting.
PowerShell is common in legitimate administration, so its presence alone is not a conclusion. In a controlled lab investigation, I build an evidence chain that explains who launched it, from where, what it attempted to do, and what happened next.
Starting from the alert
I first preserve the alert time, host, user, rule reason, and source event. I also note the detection's assumptions. This prevents the investigation from becoming a search for facts that merely confirm the alert.
Parent and child process context
The process tree often changes the interpretation. A generic example is PowerShell launched by an expected administration tool versus PowerShell spawned by an unusual document process. I review the parent image, user session, integrity context, nearby child processes, and whether the sequence matches normal activity for that host.
Command-line evidence
I examine arguments for execution style, referenced files or URLs, unusual encoding, and attempts to reduce visibility. I do not reproduce operational commands in reports. Instead, I describe the observed behavior and retain the original evidence in the controlled case record.
Network and external indicators
Sysmon network events, DNS data, proxy records, or firewall telemetry may connect a process to a destination. I compare timestamps and process identifiers before attributing traffic. Generic indicators such as example.invalid or documentation IP ranges are sufficient when explaining a sanitized case.
ATT&CK mapping
ATT&CK mapping communicates observed behavior; it does not prove intent. I map only techniques supported by evidence and distinguish direct observations from analyst inference.
Writing the conclusion
A useful conclusion states the disposition, evidence, scope, uncertainty, and recommended next action. For example: the process chain was inconsistent with expected administration, related network activity occurred within the same time window, and further host review is required. It avoids labels that the evidence cannot support.
Turning findings into detection logic
The investigation can improve detection by identifying stable relationships: unusual parent processes, required command-line fields, correlated network activity, or expected administrative exceptions. I document data requirements and likely false positives alongside the rule idea.
Conclusion
Suspicious PowerShell investigations are strongest when each claim is traceable to an event. My Blue Team Portfolio documents similar lab-based investigation and detection reasoning.