Skip to content

PowerShell Encoded Command

Attackers pass base64-encoded scripts to powershell.exe via -EncodedCommand to obfuscate intent and evade command-line inspection under a trusted shell.

powershell.exe is the signed, ubiquitous Windows shell and scripting host. Its -EncodedCommand (-e, -enc, -ec) parameter accepts a base64-encoded, UTF-16LE string and runs it as a script. The feature exists so callers can safely pass scripts containing quotes and special characters, but attackers use it to hide the real command from anyone — or anything — reading the command line. Instead of a readable script, the analyst sees one trusted binary and a long opaque base64 blob.

The technique is attractive because it defeats naive command-line string matching, lets attackers smuggle download cradles and in-memory loaders past content filters, and runs entirely under a Microsoft-signed interpreter that allow-listing trusts. It almost always appears alongside other tells — execution-policy bypass, a hidden window, and a non-interactive profile — and is one of the most common first stages dropped by phishing maldocs. Analysts encounter it constantly in the execution phase; the job is to decode the blob and recover the true intent.

How it works

The attacker invokes PowerShell with the encoded payload and the usual stealth switches:

text
powershell.exe -nop -w hidden - exec bypass -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoA...

-nop skips the profile, -w hidden hides the window, -exec bypass ignores execution policy, and -enc carries the base64. Decoding the blob (base64 → UTF-16LE) reveals the real script — frequently an IEX (New-Object Net.WebClient).DownloadString(...) cradle, a FromBase64String loader, or reflective shellcode injection.

The recognisable indicators are the -enc/-encodedcommand flag with a long base64 argument, almost always combined with -nop, -w hidden/-windowstyle hidden, and -exec bypass/-ep bypass. The base64 frequently decodes to UTF-16 text whose first bytes look like alternating-null patterns (SQBFAFgA... decodes to IEX ).

Detection & analysis

Static analysis:

  • Always decode the blob: base64-decode the argument, then interpret as UTF-16LE to recover the script. Triage the decoded text for download cradles (DownloadString, DownloadData, Net.WebClient, Invoke-WebRequest), in-memory execution (IEX, Invoke-Expression), and loaders (FromBase64String, VirtualAlloc, [Reflection.Assembly]::Load).
  • Regex the command line for -enc/-encodedcommand/-e with a long base64 token, especially co-occurring with -nop, -w hidden, and -exec bypass. Recognise that SQBFAFgA / JAB / aQBlAHgA prefixes are common decodings of IEX/$/iex.

Dynamic analysis:

  • Enable Script Block Logging (Event ID 4104) and Module Logging — these capture the deobfuscated script after PowerShell decodes it, defeating the -enc obfuscation entirely. Pair with a sandbox run to observe the resulting network fetch and dropped or injected payload.
  • Inspect the parent/child tree. Benign encoded commands come from management tooling (SCCM, GPO, scheduled tasks). Malicious instances are commonly spawned by winword.exe, excel.exe, wscript.exe, mshta.exe, or cmd.exe, and often spawn further children or open outbound connections.

Detection rule hint:

Alert on Sysmon Event ID 1 where Image ends with \powershell.exe AND the command line contains -enc/-encodedcommand/-e with a long base64 string, especially combined with -nop, -w hidden/hidden, or -exec bypass/-ep bypass. Correlate with Event ID 4104 (Script Block Logging) to recover the decoded script, and with Event ID 3 (network connection) and an Office/script-host parent to confirm a malicious download or loader.

Votes

Comments(0)