DC0054: Drive Access

Refers to the act of accessing a data storage device, such as a hard drive, SSD, USB, or network-mounted drive. This data component logs the opening or mounting of drives, capturing activities such as reading, writing, or executing files within an assigned drive letter (e.g., `C:\`, `/mnt/drive`) or mount point. Examples:

- Removable Drive Insertion: A USB drive is inserted, assigned the letter `F:\`, and files are accessed. - Network Drive Mounting: A network share `\\server\share` is mapped to the drive `Z:\`. - External Hard Drive Access: An external drive is connected, mounted at `/mnt/backup`, and accessed for copying files. - System Volume Access: The system volume `C:\` is accessed for modifications to critical files. - Cloud-Synced Drives: Cloud storage drives like OneDrive or Google Drive are accessed via local mounts.

EnterpriseDC0054Data ComponentObject v2.0 Modified Nov 12, 2025, 22:03 UTC (UTC+00:00)

Drive Access is a telemetry category for evidence that a storage location was opened, mounted, or used, including local disks, removable media, network-mounted drives, external drives, system volumes, and cloud-synced local mounts. For leaders, its value is not that drive access is suspicious by itself, but that it often answers important incident questions: what data locations were reachable, whether removable or network storage was involved, and whether activity touched business-critical or regulated storage paths.

Executive priority

Treat Drive Access as a coverage and evidence-readiness issue. During investigations, executives and risk owners may need defensible answers about access to sensitive file locations, removable media, mapped shares, cloud-synced drives, or critical system volumes. Security leaders should ask whether the organization can reconstruct drive mounting and access activity across important endpoints and file storage paths, and whether those records are retained long enough to support incident response, audit, and business-continuity decisions.

Technical view

Because ATT&CK provides no detection logic, platforms, tactics, or relationships for this data component, SOC and IR teams should use it as a validation checklist rather than as a standalone analytic. Confirm whether telemetry records drive insertion, mount events, assigned drive letters or mount points, mapped network shares, and subsequent read, write, or execute activity within those locations. Prioritize validation for high-value paths such as system volumes, network shares, removable media, external drives, and locally mounted cloud-synced storage. Any detection should be contextual: drive access is common administrative and user behavior, so alerts generally need enrichment with user, host, device, path, process, time, and data sensitivity context.

Likely telemetry

Drive mount and unmount events
Removable storage insertion and access records
Network share mapping or mounted network drive records
Local drive letter or mount point assignment records
File read, write, and execute activity within mounted drives

Detection direction

Validate that collection distinguishes local disks, removable media, external drives, network-mounted drives, and cloud-synced local mounts where available.
Correlate drive access with file activity so teams can determine whether a drive was merely mounted or actively used for reading, writing, copying, or execution.
Tune detections around business context, such as unusual users, unusual hosts, sensitive paths, after-hours access, new removable devices, or unexpected network share mappings.
Account for false positives from normal user workflows, endpoint management, backups, software deployment, administrative maintenance, and legitimate cloud-sync activity.
Identify blind spots where drive access is not logged, where mount events are captured without file-level activity, or where cloud-synced local folders look like ordinary local paths.

Mitigation priorities

Establish logging requirements for drive mounting and access events on systems and storage paths that matter to investigations and compliance evidence.
Define policy and control expectations for removable media, external drives, network share mapping, and access to sensitive mounted storage locations.
Use identity, host, and data sensitivity context to prioritize monitoring for high-risk users, privileged systems, regulated data locations, and critical operational shares.
Set retention and normalization standards so incident responders can reconstruct drive access across endpoints, mapped shares, and cloud-synced local mounts.
Regularly test whether SOC and IR teams can answer: which drives were mounted, by whom, on which host, when, and what files were accessed.

Analyst notes and limits

This object is a data component, not a technique. It describes an evidence class that may support detection and investigation across multiple behaviors, but no ATT&CK tactics, platforms, detection text, or relationship context were supplied. The most useful local analysis is to map this component to actual log sources, retention, field quality, and investigative workflows.

The supplied ATT&CK object does not provide official detection guidance, platforms, tactics, mitigations, or related techniques. Any operational analytic must be developed from local telemetry, asset criticality, identity context, and storage architecture. This summary does not imply active exploitation, adversary attribution, or existing detection coverage.

Official MITRE ATT&CK definition

Drive Access

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

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: Oct 20, 2021, 15:05 UTC (UTC+00:00)
Modified: Nov 12, 2025, 22:03 UTC (UTC+00:00)
Raw hash: 4bd48be57c5b049c...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	2.0	Nov 12, 2025, 22:03 UTC (UTC+00:00)	Current bundle	`4bd48be57c5b…`

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.

Open mirrored raw JSON Open MITRE-hosted copy

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]
mitre-attack DC0054
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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use