Multi-Layer Base64: Malware to Manifests

You decoded a base64 string and got more base64. You decoded that and got more base64 again. The payload you need is buried under 2, 3, sometimes 4 layers of encoding, and every tool in your workflow assumes you have already unwrapped those layers before you hand it the data. This pattern, multi-layer base64 encoding, is not exotic. It is one of the most common encoding structures encountered in security work. It appears in obfuscated PowerShell loaders, encrypted C2 configurations, APT backdoor delivery chains, and content protection systems. The encoding is different in each context but the analytical problem is identical: iteratively decode until the output is no longer valid base64 text, then examine what remains.

Why Attackers Stack Base64 Layers

Multi-layer encoding is not theatrical complexity. Each layer targets a specific detection surface. A YARA rule that matches cleartext strings in base64-decoded output fires on nothing if the output is itself hex-encoded or XOR-encrypted. An entropy heuristic that flags high-entropy blobs misses payloads that are compressed first and then base64-encoded, because the encoding normalises the byte distribution. A C2 config extractor that strips a single base64 layer extracts only an encrypted intermediate value rather than the plaintext config.

The number of encoding layers in a sample is roughly proportional to the number of detection tools the author was aware of when building the loader. Each pass targets a different heuristic: static string matching, file-type signatures, entropy analysis, or naive single-pass decoders. This makes the decoder chain itself a fingerprint of the author's awareness of the detection landscape.

Case Study 1: XWorm - Four Base64 Layers in a Phishing Chain

In February 2026, FortiGuard Labs documented an XWorm RAT campaign that chains four consecutive base64 encoding passes across a single delivery pipeline (Xiaopeng Zhang, "Deep Dive into New XWorm Campaign," FortiGuard Labs, February 2026).

The delivery chain starts with a phishing email carrying an XLAM attachment that exploits CVE-2018-0802 in the Microsoft Equation Editor. The shellcode downloads an HTA file containing a base64-encoded PowerShell payload interspersed with junk data. The PowerShell downloads a JPEG from Cloudinary (a legitimate CDN), where a .NET module is appended after the image content between BaseStart- and -BaseEnd markers, itself base64-encoded. The .NET module receives a parameter that is a base64-encoded string in reverse order. Reversing and decoding it produces the URL from which the XWorm PE is fetched. That file contains another base64-encoded string. Decoding it recovers the PE payload.

Case Study 2: METASTEALER - Double Base64 Inside Crypto for C2 Config

METASTEALER, an infostealer sold as Malware-as-a-Service and marketed as a RedLine derivative, uses a multi-layer encoding chain to protect all C2 configuration strings at startup (Salim Bitam et al., "Globally Distributed Stealers," Elastic Security Labs, May 2024).

The decoding sequence in the Strings class initialiser: base64-decode the AES key and IV, XOR-decrypt with an embedded key, then apply two consecutive base64-decode passes to the XOR output, and finally AES-CBC-decrypt the result. The double base64 means that even after XOR removal, a single decode pass produces intermediate ciphertext rather than plaintext config data. The C2 IP address and port are only visible after all four steps complete.

Case Study 3: Netwalker - Triple-Encoding a Fileless Ransomware DLL

Netwalker ransomware, operated as RaaS from 2019 to 2021, distributed its payload as a PowerShell script containing the ransomware DLL encoded in three layers: base64 as the outermost wrapper, hexadecimal encoding at the middle layer, and XOR encryption as the innermost protection (MITRE ATT&CK T1027.010, procedure entry for Netwalker; Trend Micro, "Netwalker Fileless Ransomware Injected via Reflective Loading," May 2020).

The DLL never touches disk as cleartext. After decoding all three layers, it is loaded entirely in memory via reflective DLL injection. Most AV and EDR products scan PowerShell command lines for base64 indicators but do not fully decode nested payloads. After base64 decoding, the hex-encoded blob looks like digit pairs, not a PE file, and matches no YARA signatures. The inner XOR layer means even a sandbox that decodes the hex sees encrypted bytes.

The encoding complexity was standardised in the Netwalker kit. Affiliates received pre-encoded scripts without needing to understand the encoding chain. CISA advisory AA21-131A (March 2021) documents the campaign infrastructure and initial access methods.

Case Study 4: POWERSTATS - Compression Inside Base64 (MuddyWater)

POWERSTATS, the primary backdoor of MuddyWater (Iranian APT linked to MOIS), uses a three-layer encoding chain: zlib compression of the backdoor code, base64 encoding of the compressed bytes, and environment variable substitution to fragment the base64 string itself (MITRE ATT&CK T1027.010, procedure entry for POWERSTATS; ClearSky, "MuddyWater Adds Exploits to Their Arsenal," June 2019).

The compression-inside-base64 pattern is a deliberate entropy manipulation tactic. A raw PowerShell script has recognisable token entropy. Compressing it first produces a high-entropy byte stream that base64-encodes to an opaque string without any recognisable PowerShell keywords. The environment variable layer fragments the base64 string so it cannot be extracted by static analysis without reconstructing the variable namespace first.

The Same Pattern in Content Protection Systems

Multi-layer base64 is not exclusive to malware. The same encoding structure appears in MPEG-DASH streaming manifests, where PSSH (Protection System Specific Header) boxes carry DRM initialisation data. The PSSH box is binary. Base64 makes it XML-safe for embedding in MPD manifests. But when that manifest passes through CDN proxies, license server intermediaries, or repackaging pipelines, the already-encoded value is base64-encoded again as part of the transport layer. Each hop can add a layer.

The result is identical to the malware cases: 2-4 layers of base64 wrapping a binary payload, with no structural marker distinguishing single-encoded from multi-encoded data. Tools that assume clean input (standard PSSH parsers, DRM debuggers) fail in the same way that single-pass decoders fail on Netwalker or POWERSTATS.

Security teams encounter PSSH data during investigations of streaming infrastructure abuse and digital forensics on devices involved in content theft. Microsoft's Storm-0408 campaign in late 2024 documented a pipeline from illegal streaming sites to info-stealer delivery affecting nearly one million devices. The delivery chain that starts with a streaming manifest and ends with malware is a real attack surface, and the multi-layer base64 pattern is the encoding structure that connects them.

Iterative Decoding: The General Solution

Regardless of whether the encoded content is a ransomware DLL, C2 config, APT backdoor, or DRM header, the decode procedure is the same:

• Start with the extracted base64 string. Strip whitespace and any container markers.
• Base64-decode the value.
• Check the decoded output. If it is valid ASCII text matching the base64 alphabet `[A-Za-z0-9+/=]`, another layer is present. Decode again.
• If the output is binary, check for known signatures: `pssh` at bytes 4-7 (DRM box), `MZ` at bytes 0-1 (PE), `PK` at bytes 0-1 (ZIP/OOXML), or known compression magic (`1F 8B` for gzip, `78 9C` for zlib). Route to the appropriate parser.
• If the output is XOR-encrypted or hex-encoded, apply the appropriate decoder and continue the chain.
• Quality-check the final output. If it contains recognisable structure (script keywords, URLs, IP addresses, file paths), extraction succeeded. If it is high-entropy noise, a crypto layer may remain.

What the Decoder Chain Reveals

The specific sequence of encoding layers in a sample is intelligence, not just a problem to solve. Two samples with the same chain of obfuscation layers almost certainly came from the same builder tool, even if the final payloads and C2 infrastructure are completely different.

The encoding chain is as distinctive as a compiler fingerprint, and it persists even when attackers rotate infrastructure, recompile payloads, and change C2 domains. For more on how decoder chains function as attribution signals, see Decoder Chain as Attack Fingerprint. For the full taxonomy of encoding techniques that appear in these chains, see Malware Obfuscation Techniques: Types, Examples, and Detection.

MITRE ATT&CK Mapping

Key Takeaways