Understanding Base64 and PowerShell -EncodedCommand

Base64 is an encoding scheme, not encryption. It converts arbitrary binary data into a text format made up only of the characters A–Z, a–z, 0–9, + and / (with = used as padding at the end). It exists because many older systems — email (MIME attachments), URLs, JSON, XML — were only designed to safely carry plain text, not arbitrary bytes. Base64 lets binary data travel through those text-only channels without corruption.

Because it's an encoding and not a cipher, Base64 provides zero confidentiality. Anyone can decode it instantly with no key. If you see Base64 used to "hide" something, it's obfuscation at best, not protection.

A few visual tells help you spot Base64-encoded data in logs, scripts or captured traffic before you even decode it:

• Only contains A-Z, a-z, 0-9, +, /, and possibly trailing = or == padding.
• Length is always a multiple of 4 characters (padding with = makes this true).
• No spaces, and a noticeably even mix of upper/lowercase compared to typical readable text.

Try it yourself with the Base64 Encoder / Decoder — paste any text to see what its encoded form looks like.

The text Hello, IT! encodes to Base64 as follows:

Notice the == padding at the end — this pads the encoded output to a multiple of 4 characters, since Base64 processes input in 3-byte groups and encodes each group as 4 characters. Decoding reverses the exact same process. This round-trip is straightforward for plain ASCII text — the complication starts with PowerShell, covered next.

PowerShell supports running a command passed as Base64 via the -EncodedCommand (or -e) flag, which is common in legitimate automation (avoiding quoting/escaping headaches when passing complex commands through another process) and, just as commonly, in malicious scripts trying to obscure their payload from casual inspection or simple string-matching security tools.

Here's the gotcha that catches people out: PowerShell does not Base64-encode the plain ASCII text of the command. It first converts the command to UTF-16LE (2 bytes per character, little-endian) and then Base64-encodes that. If you take a PowerShell encoded command and run it through a standard Base64 decoder expecting plain ASCII output, you'll get garbled text with what looks like null bytes or odd spacing between every character — because you're seeing the raw UTF-16LE byte pairs decoded as if they were single-byte ASCII.

Take the simple command Get-Process. Encoded the way PowerShell expects for -EncodedCommand, it becomes:

Decoding that string with a plain Base64-to-ASCII decoder gives you unreadable output. Decoding it correctly requires first Base64-decoding to raw bytes, then interpreting those bytes as UTF-16LE. The Base64 tool includes a dedicated PowerShell mode that handles this UTF-16LE step automatically — paste the encoded string in and it returns the readable command directly.

Encoded PowerShell commands show up constantly in malware analysis, phishing-attachment review and endpoint detection alerts, because -EncodedCommand is a simple way to slip a command past naive keyword filters and make a quick visual read of a script or scheduled task harder. Seeing powershell.exe -enc or -EncodedCommand in a process command line, a scheduled task, or an AV/EDR alert is a strong signal worth decoding immediately rather than dismissing — it does not by itself confirm malicious intent (plenty of legitimate deployment tooling uses it too), but it always deserves a look at what's actually being run.