Detecting Encoded PowerShell Attacks

When you see powershell.exe -nop -w hidden -enc SQBFAFgA..., several things should raise your eyebrows at once.

Why it's suspicious

• -enc / -EncodedCommand takes a Base64-encoded, UTF-16LE string. Legitimate admins occasionally use it, but attackers love it because it hides the real command from a glancing look.
• -w hidden runs with no window - nothing a normal interactive user needs.
• -nop (NoProfile) avoids loading the user's profile, another automation tell.
• The parent process. PowerShell spawned by winword.exe or excel.exe is a maldoc pattern - Office should not be launching shells.

Decode it safely

The encoded blob is Base64 of UTF-16LE. Decode Base64, then read as UTF-16 to recover the script. Do this in an isolated analysis environment, never on the affected host.

Detect it reliably

The tell is rarely a single field. Combine:

1. Process lineage - Office/PDF readers spawning powershell.exe/cmd.exe.
2. Command-line flags - -enc, -e, hidden window, download cradles (IEX (New-Object Net.WebClient)...).
3. Script Block Logging (Event ID 4104) - the gold source; it logs the deobfuscated script.

Enable PowerShell Script Block Logging and Sysmon process creation, and correlate the parent-child chain rather than alerting on one keyword.