Base64 and Hex Encoding for Undetectable Command Injection Payloads

When the filter catches quotes, backslashes, carets, and case variations, you stop trying to disguise the command name. You encode the entire command into a format the filter cannot pattern-match, then decode and execute it at runtime. Base64 is the go-to because every Linux and Windows system has a decoder built in.

The encode-decode-execute pattern

Three steps. Encode your command locally. Embed the encoded string in a decode-and-execute wrapper. Send the wrapper as your injection payload. The filter sees a base64 blob. The shell sees your original command.

That base64 string contains slashes, pipes, spaces, and the word cat. All potentially filtered. But the encoded form contains none of those characters. Just alphanumerics, plus, equals, and forward slash (which you can handle separately if needed).

Linux: decode and execute with bash here-string

The inner <<< feeds the base64 string to base64 -d for decoding. The outer <<< feeds the decoded command to bash for execution. No pipes in the payload. No slashes. No recognizable command names. Just a base64 blob and two here-strings.

Handling spaces in the wrapper

The wrapper command bash <<< $(base64 -d <<< STRING) contains spaces. Replace them with tabs or ${IFS} as you learned in the previous module. The final injection payload becomes:

Windows PowerShell: UTF-16 base64 encoding

PowerShell uses UTF-16LE encoding for its base64 command strings. The iex (Invoke-Expression) cmdlet executes the decoded result. The filter sees a base64 string and .NET class names. It does not see whoami.

Manual encoding works for one-off payloads. But when you need dozens of variations, or when the WAF uses behavioral analysis rather than static signatures, you need a tool that generates structurally unique payloads every time. That tool is Bashfuscator, and it is the subject of the next lesson.