PowerShell logs & command context

PowerShell can support administration, launcher maintenance, collection, or malicious activity. Establish what telemetry was enabled and which engine produced it. Windows PowerShell and newer installations can use different provider or channel contexts. Collect the actual logs instead of assuming one default location covers every invocation.

Preserve original text and record identifiers before decoding or reformatting a command. Document every transformation. A script record is useful because it preserves observed content or context, not because a long or encoded string is automatically suspicious.

1. Record the engine and existing configuration; new logging cannot create historical evidence.
2. Collect original logs and inspect record fields rather than searching screenshots for a keyword.
3. Group fragmented content using available identifiers and note missing portions.
4. Decode data offline without invoking the recovered command; retain original and derived text.
5. Interpret behavior using process and user context, then seek corroborating file, persistence, or network records.

Coverage depends on configuration and engine behavior. Missing script text from an unconfigured source does not prove no script ran. A command may contain unavailable variables or incomplete content; its outcome needs support beyond the recorded text.

Encoding and downloaded text can have legitimate purposes. A collector can generate PowerShell artifacts during a screenshare. Compare timestamps with the collection log so that your own tooling is not attributed to earlier activity.

• Engine, provider, channel, and coverage are recorded.
• Original and decoded text are retained.
• Fragments and unresolved variables are identified.
• Collector activity is separate from earlier activity.

• Microsoft: PowerShell logging ↗
• Microsoft: Sysmon context ↗

The workflow and scenario are authored investigation guidance. Confirm source-system and parser support for the build you examine.