Deobfuscate/Decode Files or Information

T1140 sits in the middle of the chain, after the encoded or fragmented payload has already survived delivery (phishing attachment, drive-by download, or a dropped secondary stage) and before execution proper. It exists specifically to defeat the static and signature-based scanning that runs at the delivery boundary: an antivirus engine or email gateway inspecting update.crt sees certificate-looking Base64, not a PE header, so the malicious content clears the gate encoded and only becomes detectable at decode time.

MITRE documents this as standard tradecraft across a wide actor set: APT28, APT39, FIN13, OilRig, menuPass, and Earth Lusca have all used certutil -decode to stage tools, while APT29, Kimsuky, and MuddyWater favor the PowerShell FromBase64String path. The 2025 Poland wiper attacks used Base64-encoded ZIP archives decoded on the endpoint, and the SolarWinds compromise decoded the Raindrop loader out of a 7-Zip archive. The consistent downstream move is execution, whether that means running the freshly decoded executable, loading a decoded DLL, or feeding decoded bytes into a script interpreter for in-memory execution.

Certutil's -decode flag has a real job: administrators use it to convert Base64-encoded certificate requests and responses in genuine PKI workflows, and some backup or provisioning scripts lean on it too. A rule that fires on every certutil -decode without context will catch IT operations alongside attackers, especially in environments that still manage certificates manually.

The tuning move is the same one that works across most living-off-the-land detections: baseline which accounts and hosts run certutil decode legitimately (typically a small set of admin workstations or a PKI service account), then treat any decode from outside that set, or any decode followed by execution of the output file, as the alert. For PowerShell FromBase64String, distinguish between decode calls embedded in signed, version-controlled administrative modules versus decode calls inside a short, unsigned, heavily obfuscated one-liner delivered via a scheduled task or Office macro. The latter pattern (short script, obfuscated variable names, immediate IEX) is what separates malicious use from a legitimate deployment script.

When a decode alert fires, first identify what got decoded and where it went: did certutil or PowerShell write a new file to disk, and if so, what is its hash and does it match a known-bad sample? If the decode stayed in PowerShell memory, pull the full command line and any nearby script-block logging (Event 4104) to recover what was actually executed, since the visible process-creation event alone will not show you the payload's behavior.

Escalate immediately if the decoded artifact executed, spawned a child process, or established a network connection; this is no longer a decode event but active execution and should be handled as such, isolating the host and preserving the artifact for analysis. If the decode has no matching execution yet, this may be an early-stage stager, worth a fast look at how the encoded file arrived (email attachment, download, USB) to close the delivery vector before the attacker retries. Either way, hunt the same decode pattern (command-line string, source file hash, or parent process) across the rest of the fleet, since this technique is frequently scripted and run identically on multiple hosts.