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]
Analyst context for executives and security teams
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.
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]
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.
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1564 | Hide Artifacts | This object subtechnique of Hide Artifacts. |
Groups, software, and campaigns
G0020: Equation
G0041: Strider
S0126: ComRAT
S0019: Regin
S0114: BOOTRASH
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]
All related ATT&CK context
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 59c7748da224… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
MalwareTech VFS Nov 2014
Hutchins, M. (2014, November 28). Virtual File Systems for Beginners. Retrieved June 22, 2020.
Open source URL -
[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]
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]
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]
mitre-attack T1564.005Open source URL
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.