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

T1564.005: Hidden File System

Adversaries may use a hidden file system to conceal malicious activity from users and security tools. File systems provide a structure to store and access data from physical storage. Typically, a user engages with a file system through applications that allow them to access files and directories, which are an abstraction from their physical location (ex: disk sector). Standard file systems include FAT, NTFS, ext4, and APFS. File systems can also contain other structures, such as the Volume Boot Record (VBR) and Master File Table (MFT) in NTFS.[1]

Adversaries may use their own abstracted file system, separate from the standard file system present on the infected system. In doing so, adversaries can hide the presence of malicious components and file input/output from security tools. Hidden file systems, sometimes referred to as virtual file systems, can be implemented in numerous ways. One implementation would be to store a file system in reserved disk space unused by disk structures or standard file system partitions.[1][2] Another implementation could be for an adversary to drop their own portable partition image as a file on top of the standard file system.[3] Adversaries may also fragment files across the existing file system structure in non-standard ways.[4]

EnterpriseT1564.005Sub-techniqueObject v2.0Modified
Glexia's Take · Automated analysis

Security context for executives and security teams

Automation confidenceMedium

T1564.005: Hidden File System describes Adversaries may use a hidden file system to conceal malicious activity from users and security tools. File systems provide a structure to store and access data from physical storage. Typically, a user engages with a file system through applications that allow them to access files and directories, which are an abstraction from their physical location (ex: disk sector). Standard file systems include FAT, NTFS, ext4, and APFS. File systems can also contain other structures, such as the Volume Boot Record (VBR) and Mas...

Executive priority

T1564.005: Hidden File System is an official MITRE ATT&CK technique. Glexia treats it as defensive behavior context for prioritizing monitoring, control validation, and response planning without using the object by itself as an attribution claim.

Technical view

Security teams should validate T1564.005: Hidden File System by reviewing the official ATT&CK relationships, mapped tactics (stealth), supported platforms (Linux, macOS, Windows), and available local telemetry before making detection or mitigation decisions.

Likely telemetry

  • Official ATT&CK relationships and object metadata
  • Network, endpoint, and security-tool telemetry

Detection direction

  • Validate whether T1564.005: Hidden File System appears in your detection coverage and tabletop scenarios.
  • Use the object to align executive risk language with SOC, incident response, and detection engineering work.
  • Do not treat ATT&CK relationship context as attribution without corroborating evidence.

Mitigation priorities

  • Map the object to existing controls and identify missing telemetry or response ownership.
  • Prioritize mitigations that reduce exposure on the listed platforms and tactics.
  • Review adjacent ATT&CK relationships before changing policy, detections, or reporting language.
Additional notes and limits

Baseline Glexia take generated from the official MITRE ATT&CK STIX object, source hash, tactics, platforms, and detection fields. It is safe to replace with a richer model-generated take for the same source hash later.

This baseline take is source-grounded and schema-validated, but it does not include environment-specific telemetry, incident evidence, or threat-intelligence corroboration.

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

Official MITRE ATT&CK definition

Hidden File System

Adversaries may use a hidden file system to conceal malicious activity from users and security tools. File systems provide a structure to store and access data from physical storage. Typically, a user engages with a file system through applications that allow them to access files and directories, which are an abstraction from their physical location (ex: disk sector). Standard file systems include FAT, NTFS, ext4, and APFS. File systems can also contain other structures, such as the Volume Boot Record (VBR) and Master File Table (MFT) in NTFS.[1]

Adversaries may use their own abstracted file system, separate from the standard file system present on the infected system. In doing so, adversaries can hide the presence of malicious components and file input/output from security tools. Hidden file systems, sometimes referred to as virtual file systems, can be implemented in numerous ways. One implementation would be to store a file system in reserved disk space unused by disk structures or standard file system partitions.[1][2] Another implementation could be for an adversary to drop their own portable partition image as a file on top of the standard file system.[3] Adversaries may also fragment files across the existing file system structure in non-standard ways.[4]

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.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
DomainIDNameRelationship / procedure
EnterpriseT1564Hide ArtifactsThis object subtechnique of Hide Artifacts.
Associated objects

Groups, software, and campaigns

GroupEnterprise

G0041: Strider

Strider is a threat group that has been active since at least 2011 and has targeted victims in Russia, China, Sweden, Belgium, Iran, and Rwanda.[1][2]

GroupEnterprise

G0020: Equation

Equation is a sophisticated threat group that employs multiple remote access tools. The group is known to use zero-day exploits and has developed the capability to overwrite the firmware of hard disk drives. [1]

MalwareEnterprise

S0019: Regin

Regin is a malware platform that has targeted victims in a range of industries, including telecom, government, and financial institutions. Some Regin timestamps date back to 2003. [1]

Windows
MalwareEnterprise

S0022: Uroburos

Uroburos is a sophisticated cyber espionage tool written in C that has been used by units within Russia's Federal Security Service (FSB) associated with the Turla toolset to collect intelligence on sensitive targets worldwide. Uroburos has several variants and has undergone nearly constant upgrade since its initial development in 2003 to keep it viable after public disclosures. Uroburos is typically deployed to external-facing nodes on a targeted network and has the ability to leverage additional tools and TTPs to further exploit an internal network. Uroburos has interoperable implants for Windows, Linux, and macOS, employs a high level of stealth in communications and architecture, and can easily incorporate new or replacement components.[1][2]

LinuxWindowsmacOS
MalwareEnterprise

S0126: ComRAT

ComRAT is a second stage implant suspected of being a descendant of Agent.btz and used by Turla. The first version of ComRAT was identified in 2007, but the tool has undergone substantial development for many years since.[1][2][3]

Windows
Relationship explorer

All related ATT&CK context

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.2
Object version
2.0
Created
Modified
Raw hash
59c7748da2245927...
Imported snapshots across ATT&CK releases(2)
ReleaseBundle importedObject versionModifiedStatusRaw hash
19.22.0Current bundle59c7748da224…
19.12.0Older bundle59c7748da224…
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 references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    MalwareTech VFS Nov 2014

    Hutchins, M. (2014, November 28). Virtual File Systems for Beginners. Retrieved June 22, 2020.

    Open source URL
  2. [2]
    FireEye Bootkits

    Andonov, D., et al. (2015, December 7). Thriving Beyond The Operating System: Financial Threat Group Targets Volume Boot Record. Retrieved May 13, 2016.

    Open source URL
  3. [3]
    ESET ComRAT May 2020

    Faou, M. (2020, May). From Agent.btz to ComRAT v4: A ten-year journey. Retrieved June 15, 2020.

    Open source URL
  4. [4]
    Kaspersky Equation QA

    Kaspersky Lab's Global Research and Analysis Team. (2015, February). Equation Group: Questions and Answers. Retrieved December 21, 2015.

    Open source URL
  5. [5]
    mitre-attackT1564.005
    Open source URL
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.