Detecting Deobfuscate and Decode Files or Information (T1140)

Attackers hide things. They pack, encode, split and encrypt files so scanners miss them. But a hidden payload has to be turned back into something that runs, and that step happens on your machine. T1140, Deobfuscate/Decode Files or Information, is the technique for that step. MITRE files it under stealth and lists ESXi, Linux, macOS and Windows as platforms.

How attackers use it

MITRE connects T1140 to Obfuscated Files or Information (T1027). Adversaries obfuscate artifacts of an intrusion to hide them from analysis, and they need a separate mechanism to decode them depending on how they plan to use them. The mechanism can be built into the malware, or it can be a utility already on the system.

The page gives two examples:

• certutil. One example is using certutil to decode a remote access tool portable executable that was hidden inside a certificate file.
• Windows copy and type. The Windows copy /b or type commands can reassemble binary fragments into a malicious payload.

Sometimes a user is part of it. A user may need to open a file to trigger the decoding, as part of User Execution, or type a password to open a password protected compressed or encrypted file the adversary provided.

This is one of the most widely observed behaviors in the ATT&CK matrix. The page lists a long run of malware families that decode or decrypt their own components, and the utility certutil.

How to detect it

MITRE's detection strategy has one variant per platform family, and they share a shape: a decoding or reassembly tool runs shortly after a file is staged or downloaded, and it is often followed by a script interpreter or the payload itself.

• Windows. certutil.exe, powershell.exe or copy.exe used to decode, reassemble or extract hidden content from obfuscated containers or encoded formats.
• Linux. Native tools such as base64, gzip, tar or openssl decode, decompress or decrypt previously staged files. They may be chained with curl or wget and run through bash or zsh to extract an embedded payload or a reverse shell script.
• macOS. Tools such as base64, plutil or AppleScript-based utilities decode files embedded in staging artifacts, often after a download, through zsh, Python or osascript.

What makes these hard is that every one of those tools is legitimate. So the signal is the sequence and the context:

1. A file lands (download, email attachment, archive extraction).
2. A decoder touches it within seconds.
3. The output is executed, or a new executable appears in a user or temp folder.

Log process creation with full command line (Security 4688 with command line auditing, or Sysmon event ID 1) and file creation (Sysmon event ID 11) so you can join those steps. A certutil command line with -decode is a classic example worth a specific alert. So is -urlcache, which is a separate behavior but often sits next to decoding in the same intrusion.

How to reduce the risk

MITRE's record for T1140 does not list a specific mitigation, and the page explains why: this behavior is hard to prevent because it uses legitimate tools and built-in functions. The defensive value comes from visibility, and from limiting the steps before and after decoding:

• Restrict the tools. If certutil is not needed on servers, application control can block it from running there.
• Control where code can run from. Application allow-listing that blocks execution from user profile and temp folders turns a successful decode into a dead end.
• Reduce user execution. Mark-of-the-web handling, blocking password protected archives at the mail gateway, and training for the password protected archive trick all cut the human part.
• Keep command line logging on and send it somewhere searchable.

Check your own environment

Windows, read-only look at recent process creations that mention certutil (requires command line auditing in 4688):

wevtutil qe Security /q:"*[System[(EventID=4688)]]" /c:200 /rd:true /f:text | findstr /i certutil

Linux, list active audit rules so you know whether decoding tools are watched:

auditctl -l

Questions to take to your team:

• Do we log full command lines on Windows endpoints and servers?
• Is certutil blocked or alerted on where it is not needed?
• Can we find every file that was created by a process within a few seconds of a decoder running?
• Do we block password protected archives from outside at the mail gateway, or at least flag them?

Quick check

Sources

• MITRE ATT&CK, T1140 Deobfuscate/Decode Files or Information