Obfuscated Files or Information (T1027)

Plain-language definition

An adversary encodes, encrypts, packs, fragments, or otherwise transforms files and information to make discovery or analysis more difficult.

MITRE ATT&CK® identifies this behavior as T1027. In the Enterprise knowledge base it is associated with the Stealth tactical objective and is represented here for the following platform scope: Windows, Linux, macOS, IaaS, Network Devices, Containers, ESXi.

The identifier describes behavior, not intent, actor identity, malware family, or severity by itself. A defensible mapping requires evidence that the observed action matches the behavior in the affected environment.

How the behavior fits an intrusion

Obfuscated Files or Information can appear as one step in a longer chain of activity. The adversary’s access, privileges, objectives, and technology choices determine whether the behavior succeeds and what follows it.

For the Stealth objective, the important analytic question is not simply whether a tool or command exists. It is whether the action changed the adversary’s capability, knowledge, access, concealment, control, collection, transfer, or effect in a way supported by the evidence.

Analysts should record attempted and failed behavior as well as successful actions. Failed attempts can expose targeting, tool choice, assumptions, and future paths even when a preventive control worked.

Preconditions and attack path

Before assigning this technique, identify what the adversary already needed: access, network reachability, credentials, permissions, user interaction, vulnerable software, trusted infrastructure, or knowledge of the environment. Those preconditions often reveal the most effective place to interrupt the path.

Then identify the output of the behavior. The output may be information, code execution, a durable configuration, a secret, a new connection, staged data, or operational disruption. Connecting precondition to output makes the mapping useful for architecture and response.

• Required access or exposure for Obfuscated Files or Information
• Identity, privilege, and trust assumptions
• Affected asset, workload, application, or external surface
• Expected legitimate behavior that could look similar
• The follow-on action made possible by success

Defensive design and mitigation

Defending against obfuscated files or information requires controls at the decision points that make the behavior possible. A control relationship should be treated as a hypothesis to validate, not proof that purchasing or enabling one feature resolves the technique.

Use independent layers where consequence is high. Prevention should be paired with protected evidence, bounded privileges, exception governance, and recovery. Document where the control applies and where the platform, identity, or workload remains outside its scope.

• Protect and centralize logs away from monitored hosts.
• Use allowlisting, integrity monitoring, and protected telemetry pipelines.
• Harden administrative tools and restrict dual-use utilities.
• Correlate endpoint, identity, network, and cloud evidence.
• Define which legitimate roles, tools, and workflows may perform activity resembling obfuscated files or information.
• Test controls against both a benign simulation of obfuscated files or information and a representative administrative use case.

Detection engineering and evidence

A useful detection for obfuscated files or information describes the observable sequence, required data, analytic logic, expected benign behavior, and response action. The ATT&CK identifier is metadata for the analytic; it is not the analytic itself.

Validate field meaning, timestamps, parsing, retention, and source health before claiming coverage. When host evidence may be altered, correlate it with identity, network, application, cloud-control-plane, or centralized security records.

• File and metadata changes
• Log deletion and audit-policy changes
• Hidden artifacts and unusual storage locations
• Cross-source inconsistencies and telemetry gaps
• Events that attribute obfuscated files or information to a specific process, account, host, workload, application, or external destination
• Time-synchronized context from at least one independent evidence source

Investigation questions

Investigators should begin with the event and affected object, then expand backward to enabling access and forward to consequences. The questions below are intended to reveal both the behavior and the conditions that made it possible.

• What observation most directly supports T1027 Obfuscated Files or Information?
• Which identity, process, service, application, or external infrastructure initiated it?
• Was the activity expected for that actor, asset, location, and time?
• What access, privilege, or configuration was required?
• What information or capability did the behavior produce?
• Which related actions occurred immediately before and after it?
• What evidence might be missing, impaired, or controlled by the adversary?
• What must be revoked, contained, restored, or monitored before recovery?

Safe practitioner lab

Never disable security controls or erase evidence on production systems. A tabletop or synthetic log exercise is appropriate when safe simulation is not possible.

Record the starting state, expected event sequence, timestamps, and rollback method. The purpose is to understand evidence and control behavior, not to recreate harmful tradecraft or evade detection.

• Use a disposable host with a test log source and a nonproduction protective control.
• Simulate the configuration or artifact condition associated with obfuscated files or information without disabling real protection.
• Confirm that an independent source records the change or loss of telemetry.
• Restore the original state and document the alert and recovery sequence.
• Compare the observed evidence with the fields required by a proposed analytic.
• Document one false-positive condition and one telemetry gap.
• Restore the lab and verify the baseline before retaining sanitized notes.

Common misconceptions

• Seeing a tool associated with T1027 proves that Obfuscated Files or Information occurred. Tools have many functions; map the observed behavior.
• A technique occurs only once in a linear attack. Behaviors can repeat, overlap tactics, and appear in different orders.
• A vendor rule mapped to the ID proves organization-wide coverage. Local data quality, scope, testing, tuning, and response determine coverage.
• A preventive control eliminates the need for detection. Attempts and control failures still provide valuable evidence.
• The platform list proves applicability to every product in that category. Validate the actual architecture and configuration.

Attribution, version, and scope

© 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. Bare Metal Cyber is not affiliated with or endorsed by MITRE.

This is an original Bare Metal Cyber educational profile reviewed against Enterprise ATT&CK catalog v19.2. The official T1027 page controls current object name, status, relationships, procedure examples, and source citations.

Certification relevance

This subject appears in or supports the following certification bodies of knowledge:

Authoritative sources

• MITRE ATT&CK® T1027 — Obfuscated Files or Information
• MITRE ATT&CK® Data & Tools
• MITRE ATT&CK® Legal and Branding Guidance