DET0426: Detection of Direct Volume Access for File System Evasion
DET0426 matters because Direct Volume Access is a way to read or write data below normal file-access paths, potentially bypassing file permissions and file...
Analyst context for executives and security teams
DET0426 matters because Direct Volume Access is a way to read or write data below normal file-access paths, potentially bypassing file permissions and file-system monitoring. For leaders, the issue is not just a single alert rule; it is whether endpoint, identity, and response programs can see activity that deliberately avoids the controls they often rely on for evidence.
Executive priority
Prioritize this as a validation item for environments where Windows systems or network devices hold sensitive operational data, credentials, or regulated records. Ask whether security teams can prove visibility into raw or direct volume access, whether privileged access is tightly governed, and whether incident responders have alternate evidence sources if normal file monitoring is bypassed.
Technical view
This detection strategy is linked to ATT&CK T1006 Direct Volume Access under the stealth tactic. Because the ATT&CK object does not provide an official detection description and does not specify platforms for the strategy itself, SOC teams should anchor validation to the related technique: direct logical-volume access on Windows and relevant network-device contexts. Validate whether telemetry captures processes opening raw volume handles, unusual PowerShell or utility behavior associated with direct file extraction, and activity that reads or writes files without normal file-system audit trails.
Likely telemetry
- Endpoint process creation and command-line telemetry
- PowerShell execution, script block, and module logging where enabled
- Operating system events or EDR telemetry for raw disk or logical volume handle access
- File-system monitoring and its gaps or bypass conditions
- Privilege use and administrative access events
Detection direction
- Test whether existing endpoint controls can observe direct logical-volume access rather than only normal file open/read/write events.
- Correlate raw volume access with process identity, parent process, command line, user privilege level, and host role.
- Tune for legitimate administrative, backup, forensic, and disk-management tools to reduce false positives while preserving visibility into unusual use.
- Review PowerShell-related telemetry because the related technique notes utilities such as NinjaCopy can perform this behavior.
- Do not assume file-system monitoring alone is sufficient; the technique is specifically relevant because it may bypass that monitoring.
Mitigation priorities
- Limit and review privileges that allow direct volume access, especially local administrative rights on sensitive systems.
- Maintain endpoint telemetry that records process behavior and privileged access, not only file access events.
- Include direct-volume-access scenarios in incident response and detection validation exercises.
- Document control coverage and known gaps for audit, compliance, and risk acceptance decisions.
- For network devices, confirm vendor-supported logging and administrative controls locally because this ATT&CK object does not provide device-specific detection detail.
Analyst notes and limits
The strongest decision value is coverage validation: can the organization still investigate when an adversary bypasses normal file controls and file-system monitoring? This is especially relevant to managed detection, incident response readiness, identity governance, and evidence preservation.
The supplied detection strategy has no official description, no official detection text, and no platforms or tactics specified on the strategy object. Platform and tactic context comes only from the relationship to T1006 Direct Volume Access. Local operating system, EDR, PowerShell, and network-device logging capabilities must be verified before making coverage claims.
Detection of Direct Volume Access for File System Evasion
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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 | T1006 | Direct Volume Access | This object detects Direct Volume Access. |
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 | 1.0 | Current bundle | 96e5f36e9517… |
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]
mitre-attack DET0426Open 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.