LiveActive security incident?Get immediate response
MITRE ATT&CK® Technique

T1140: Deobfuscate/Decode Files or Information

Adversaries may use Obfuscated Files or Information to hide artifacts of an intrusion from analysis. They may require separate mechanisms to decode or deobfuscate that information depending on how they intend to use it. Methods for doing that include built-in functionality of malware or by using utilities present on the system.

One such example is the use of certutil to decode a remote access tool portable executable file that has been hidden inside a certificate file.CitationMalwarebytes Targeted Attack against Saudi Arabia Another example is using the Windows copy /b or type command to reassemble binary fragments into a malicious payload.CitationCarbon Black Obfuscation Sept 2016CitationSentinel One Tainted Love 2023

Sometimes a user's action may be required to open it for deobfuscation or decryption as part of User Execution. The user may also be required to input a password to open a password protected compressed/encrypted file that was provided by the adversary.CitationVolexity PowerDuke November 2016

EnterpriseT1140TechniqueObject v2.0Modified
Glexia's Take · Automated analysis

Security context for executives and security teams

Automation confidenceHigh

Deobfuscate/Decode Files or Information matters because hidden payloads often become usable only after an endpoint, server, or user action decodes, decrypts, or reassembles them. For leaders, this is a practical detection gap: the malicious file may not look dangerous at rest, but the decoding activity can expose the transition from staging to execution. ATT&CK lists this as a stealth technique across Windows, Linux, macOS, and ESXi.

Executive priority

Prioritize this technique where business-critical systems rely on endpoint visibility, email attachment handling, server integrity, or incident reconstruction. Executives should ask whether SOC and IR teams can prove they collect process, file, and command telemetry around decoding utilities and reassembly behavior, especially on non-Windows platforms such as Linux, macOS, and ESXi where monitoring may be thinner. This also supports audit and readiness discussions: can the organization show evidence that suspicious file transformation activity is logged and reviewable?

Technical view

ATT&CK provides no official detection text for T1140, but it does link a detection strategy, DET0275: Detect Adversary Deobfuscation or Decoding of Files and Payloads. Defenders should validate visibility for utilities and behaviors described in the technique, including certutil decoding, Windows copy /b or type used to reassemble binary fragments, malware-embedded decoding, and user-assisted opening of password-protected compressed or encrypted files. Tune detections around unusual parent-child process chains, newly created executable content following decode or archive activity, and decoding on systems or user roles where such behavior is uncommon.

Likely telemetry

  • Process creation and command-line telemetry for Windows, Linux, macOS, and ESXi where available
  • File creation, modification, rename, and write events showing decoded, decrypted, or reassembled payloads
  • Endpoint detection or host audit logs showing use of built-in utilities such as certutil, copy, or type where applicable
  • Archive, compressed-file, and password-protected file handling evidence from endpoints or secure email controls
  • Script, shell, and command interpreter logs that show decoding or file concatenation behavior

Detection direction

  • Start by confirming whether DET0275-style logic is implemented or mapped in the detection program, since ATT&CK does not provide native detection guidance for this object.
  • Look for decode or reassembly activity followed by execution, persistence, network communication, or movement of the resulting file; decoding alone can be legitimate.
  • Baseline administrative, development, certificate-management, backup, and packaging workflows to reduce false positives from legitimate encoding, archive, or binary handling.
  • Pay special attention to user-driven workflows involving password-protected attachments or encrypted archives, because user execution may be part of the deobfuscation chain.
  • Validate coverage outside standard Windows endpoints. ATT&CK lists ESXi, Linux, macOS, and Windows, and gaps on servers or virtualization infrastructure may materially affect IR readiness.

Mitigation priorities

  • Improve visibility first: ensure process command lines, file writes, and archive/decode activity are logged and retained on supported platforms.
  • Harden attachment and download handling processes, especially for encrypted or password-protected files that reduce automated inspection value.
  • Restrict or monitor misuse-prone built-in utilities where operationally feasible, without assuming the utility itself is malicious.
  • Use least privilege and application control principles to reduce the chance that decoded content can execute from user-writable or temporary locations.
  • Include this behavior in incident response playbooks so analysts preserve both the obfuscated source artifact and the decoded output for scope and timeline analysis.
Additional notes and limits

The relationship set shows broad use of this technique by multiple campaigns and groups, which supports treating it as a common tradecraft pattern rather than a niche behavior. The supplied examples include certutil decoding, binary reassembly with Windows commands, and password-protected compressed or encrypted files requiring user action. Use the campaign and group relationships for threat-informed prioritization only; they do not by themselves prove current exposure or activity in a specific environment.

ATT&CK does not provide official detection text for this technique in the supplied object. The relationship context names many campaigns and groups, but local telemetry is required to determine whether this behavior occurred, whether it was malicious, and whether controls would detect it. No vendor-specific coverage or guaranteed detection should be inferred.

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Official MITRE ATT&CK definition

Deobfuscate/Decode Files or Information

Adversaries may use Obfuscated Files or Information to hide artifacts of an intrusion from analysis. They may require separate mechanisms to decode or deobfuscate that information depending on how they intend to use it. Methods for doing that include built-in functionality of malware or by using utilities present on the system.

One such example is the use of certutil to decode a remote access tool portable executable file that has been hidden inside a certificate file.CitationMalwarebytes Targeted Attack against Saudi Arabia Another example is using the Windows copy /b or type command to reassemble binary fragments into a malicious payload.CitationCarbon Black Obfuscation Sept 2016CitationSentinel One Tainted Love 2023

Sometimes a user's action may be required to open it for deobfuscation or decryption as part of User Execution. The user may also be required to input a password to open a password protected compressed/encrypted file that was provided by the adversary.CitationVolexity PowerDuke November 2016

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.

ATT&CK release
19.1
Object version
2.0
Created
Modified
Raw hash
234e71e36f49f454...
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.