Live Active 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.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Hidden File System is a stealth technique where an adversary conceals malware components or file activity outside the places normal users and many tools expect to look, such as unused disk space, portable partition images, or fragmented non-standard storage. For leaders, the significance is not ordinary hidden files; it is the possibility that endpoint visibility, file inventory, and routine triage may miss the evidence needed to understand persistence, scope, and recovery requirements.

Executive priority

Prioritize this where compromise of Windows, Linux, or macOS systems would create high business impact, sensitive data exposure, or difficult recovery decisions. The technique is associated in ATT&CK with advanced malware and groups, and it can complicate incident response because normal file-system review may not show the full implant footprint. Executives should ask whether SOC and IR teams can acquire and analyze disk-level evidence, not just endpoint file events, and whether recovery playbooks include rebuild or forensic imaging decisions when hidden storage is suspected.

Technical view

ATT&CK lists this as a stealth sub-technique of Hide Artifacts for Linux, macOS, and Windows. No official ATT&CK detection text is provided, but the relationship to DET0461 indicates a detection strategy exists for hidden file system abuse. SOC and IR teams should validate visibility beyond standard file enumeration: disk layout anomalies, unusual partition or image files, unexpected raw disk access, suspicious boot/VBR/MFT-related changes where applicable, and discrepancies between file-system metadata and physical storage usage. Relationship context includes Equation, Strider, Regin, Uroburos, BOOTRASH, and ComRAT, so threat hunting should treat this as a high-sophistication concealment pattern rather than a commodity hidden-file check.

Likely telemetry

  • Endpoint file and process telemetry from Windows, Linux, and macOS systems
  • Disk and volume inventory, including partition tables, reserved or unused space, and mounted images
  • Raw disk access events and privileged process activity interacting with storage devices
  • File-system metadata and integrity data, such as NTFS structures where available
  • Forensic disk images or triage collections for systems under investigation

Detection direction

  • Confirm whether endpoint tooling can see raw disk access and storage artifacts, not only normal file create/read/write events.
  • Hunt for mismatches between expected disk layout and observed storage use, including unexplained portable partition images or hidden containers on the standard file system.
  • Correlate suspicious privileged processes with disk, volume, or boot-record access to reduce noise from legitimate administration, backup, encryption, and virtualization tools.
  • Use DET0461 as the ATT&CK-related detection strategy reference, but validate coverage locally because the official technique object provides no detection procedure.
  • During IR, consider disk-level acquisition when malware is suspected but standard file-system review is inconclusive.

Mitigation priorities

  • Start with asset criticality: identify systems where disk-level concealment would materially affect recovery, evidence preservation, or regulatory reporting.
  • Ensure endpoint hardening limits unnecessary privileged access to raw disks and storage management functions.
  • Maintain reliable forensic imaging and rebuild procedures for Windows, Linux, and macOS endpoints where compromise cannot be confidently scoped through normal file telemetry.
  • Baseline legitimate disk, partition, image-mounting, backup, encryption, and virtualization activity to support detection tuning.
  • Include hidden file system scenarios in incident response exercises so teams know when to escalate from live triage to deeper forensic collection.
Analyst notes and limits

This object is most useful as a coverage and response-readiness test: can the organization detect or investigate storage that is intentionally abstracted away from the normal file system? The ATT&CK relationships show use by several named groups and malware families, including Windows and cross-platform software examples, but those relationships should inform prioritization rather than imply current exposure or attribution.

The official ATT&CK detection field is not provided, so detection recommendations are derived from the official description, platforms, parent technique, external references, and the DET0461 relationship. Local operating system configuration, endpoint tooling depth, forensic capability, and legitimate storage-management activity determine practical coverage.

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
Domain ID Name Relationship / procedure
Enterprise T1564 Hide Artifacts This object subtechnique of Hide Artifacts.
Associated objects

Groups, software, and campaigns

Group Enterprise

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]

Group Enterprise

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]

Malware Enterprise

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
Malware Enterprise

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
Malware Enterprise

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
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.1
Object version
2.0
Created
Modified
Raw hash
59c7748da2245927...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle 59c7748da224…
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-attack T1564.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.