Developer tools · Base64 encoder & decoder
How to decode a suspicious Base64 PowerShell command without running it
· Why it matters
base64 security
Attackers use Base64 to hide scripts from casual inspection. This post shows how to decode an -EncodedCommand payload without executing it, why the output may look odd in a UTF-8 decoder, and what to look for.
The scheduled task with a 2,000-character argument — where encoded commands turn up and why they are a red flag
A sysadmin discovers a scheduled task with a 2,000-character -EncodedCommand argument that looks suspicious. The task runs under a service account with high privileges.
The temptation to paste the command into PowerShell and run it to see what it does is dangerous; if the command is malicious, executing it compromises the system. The safer approach is to decode the Base64 locally and read the output as text before deciding whether to run anything. This post explains how to decode PowerShell commands safely without executing them, why the output may look garbled in a standard UTF-8 decoder, and what to look for to assess whether a command is safe or suspicious.
Decode, never execute — the rule that keeps analysis safe, and why a browser-only decoder is a good fit
The key insight is that PowerShell uses UTF-16LE encoding for -EncodedCommand, not UTF-8, so every other byte is a zero which standard tools interpret as null terminators. The rule for analyzing any suspicious code is simple: decode, never execute. This applies to Base64-encoded commands, compressed scripts, scripts from untrusted sources and anything in a chain of unfamiliar encoding. Executing a script is the point of no return; once it runs, changes to the system have happened, access has been granted and data has been exfiltrated.
Decoding and reading the script as text lets you evaluate it before the irreversible step. The second rule is to use a tool that runs locally and makes no network requests. A browser-based decoder is ideal because it is portable, requires no additional software and keeps the suspicious payload on your device without uploading it to any server. If the tool is the kind that posts to a remote decoder service, do not use it; the payload is then exposed to that service. PowerShell -EncodedCommand parameter accepts a Base64 string that, when decoded, contains a PowerShell script.
Why the decoded bytes look unlike UTF-8 text — inspect the UTF-16LE byte pattern in hex rather than asking this UTF-8 text tool to interpret it
However, PowerShell does not use UTF-8 encoding for this; it uses UTF-16LE (little-endian UTF-16). In UTF-16, every ASCII character is represented as two bytes: the character code followed by a zero byte. The letter A is 41 00 in hex. The letter B is 42 00. A string like Hello appears as 48 00 65 00 6C 00 6C 00 6F 00 in UTF-16LE bytes. When this is Base64-encoded, the result contains the encoded form of all those bytes, including all the zeros. Decoding with a standard UTF-8 decoder produces garbled text or truncates at the first zero byte because UTF-8 treats null bytes as string terminators.
The output looks like H e l o instead of Hello, with seemingly random characters or missing text. A worked example shows the problem and the solution. Suppose a PowerShell command encodes the simple string Write-Host Hello. PowerShell UTF-16LE-encodes this to bytes including all the zeros, Base64-encodes the bytes and produces a long string like VwByAGkAdABlAC0ASwBvAHMAaAAgACIASABlAGwAbABvACIA. Copy this string into Base64 encoder & decoder in your browser and click Decode. The default decoder will try to interpret the result as UTF-8 text and produce corrupted or truncated output because of the embedded zeros.
Worked example: decoding a harmless sample encoded command — reading the text past the interleaved zero bytes
The solution is to use the hex view instead. Switch to the hex view and you see the bytes: 57 00 72 00 69 00 74 00 65 00 2D 00 4B 00 6F 00 73 00 68 00 20 00 22 00 48 00 65 00 6C 00 6C 00 6F 00 22 00. Reading those bytes as UTF-16LE pairs yields W-r-i-t-e---K-o-s-h---H-e-l-l-o-. With experience you can read UTF-16LE hex directly, or you can write the bytes to a file and decode them with a PowerShell or Python script running locally.
The practical approach is to note the pattern and remember that PowerShell uses UTF-16LE. When you decode PowerShell -EncodedCommand in the browser and the output looks wrong, look at the hex view instead of the text view. The hex view shows each byte individually. Every ASCII character appears as two bytes with a zero between them. If the bytes spell out malicious commands like New-AdminAccount, reverse dns lookups or export of security credentials, the command is suspicious. If the bytes spell out something innocuous like a directory listing or a simple script, the command is likely benign.
Nested encoding and compression — Base64 inside Base64, and gzip streams you cannot read as text
The hex view is harder to read than plain text, but it is safer than guessing from corrupted UTF-8 output. Nested encoding and compression add complexity to malware analysis. A PowerShell command might Base64-encode another Base64 string, or compress a script with gzip and then Base64-encode the result. In a nested scenario you decode the outer Base64, read the result and discover it is itself base64. Decode that too and continue until you find readable text or a binary format you cannot interpret. Gzip and other compression formats start with magic bytes (1F 8B for gzip) visible in the hex view.
If you decode Base64 and the hex view starts with 1F 8B, the bytes are a compressed stream that requires decompression. Base64 encoder & decoder shows you the hex, helping you identify these patterns without executing anything. Compressed or further-encoded payloads are suspicious because they add obfuscation layers.
What to record for an incident report — the decoded text, the source, and hashes rather than the payload itself
Legitimate commands rarely require multiple encoding steps. Recording findings for an incident report requires discipline and accuracy. Write down the exact Base64 string you analyzed, where you found it and when. If you decoded it and found suspicious commands, describe the commands but do not include the full script in the report yet; the script might be intricate or long.
Include a hash (SHA-256) of the decoded script so that the finding can be verified and tracked. If the command is clearly malicious or uses known exploitation techniques, involve incident response and security teams before taking any action. Never execute the command yourself to see what it does. If incident responders need to execute it for testing, they do so in a sandboxed environment where any damage is contained. Your job is to decode and assess the risk at a safe distance. This article does not cover the full scope of malware analysis, sandbox environments or attack attribution.
What this does not cover — sandbox execution, malware analysis tooling and attribution
Those are topics for security professionals and incident response teams. The scope here is narrowly focused on safely decoding an encoded PowerShell command without executing it, so you can read the script and assess whether it is worth investigating further. Base64 encoding is obfuscation, not protection. Anyone with the encoding and a decoder can extract the script. Attackers use Base64 to evade basic detection and to prevent casual inspection, not to conceal their intent from analysis. A decoded PowerShell command that fetches and executes a remote script is malicious whether you decode it yourself or a security tool does.
The practical next step after decoding a suspicious command is to report it to the appropriate team. If it is your own system, determine whether the task was created intentionally and by whom. Check the creation date and the account that scheduled it. If the task is unauthorized, disable it, preserve the details for forensics and investigate how the attacker gained the privilege to create it. If the command contains network requests or persistence mechanisms like registry changes or scheduled task creation, it is almost certainly malicious.
Takeaway: Base64 is obfuscation, not protection — how the Base64 encoder & decoder decodes the payload locally without it ever leaving your machine
If it performs legitimate administration functions and the creation details are normal, it might be a legitimate administrative script that happens to be encoded for reasons related to security policy or integration with a larger automation tool. Do not execute it either way; let your assessment of the decoded text inform your decision. Safe decoding of suspicious Base64 PowerShell commands follows a straightforward process. Use Base64 encoder & decoder to decode the string without uploading it or executing anything. Look at the hex view to understand what the bytes represent.
If you see UTF-16LE patterns (interleaved zero bytes) remember that PowerShell uses UTF-16LE and read accordingly. Identify any suspicious patterns like network requests, privilege elevation or persistence mechanisms. Record the details accurately for your incident report, including the original Base64 string and its hash. Never execute the command yourself; leave that to incident responders in a controlled environment. Trust your local decoding and your assessment of the plaintext, and let that guide your next action.