DC0042: Drive Creation
The activity of assigning a new drive letter or creating a mount point for a data storage device, such as a USB, network share, or external hard drive, enabling access to its content on a host system. Examples:
- USB Drive Insertion: A USB drive is plugged in and automatically assigned the letter `E:\` on a Windows machine. - Network Drive Mapping: A network share `\\server\share` is mapped to the drive `Z:\`. - Virtual Drive Creation: A virtual disk is mounted on `/mnt/virtualdrive` using an ISO image or a virtual hard disk (VHD). - Cloud Storage Mounting: Google Drive is mounted as `G:\` on a Windows machine using a cloud sync tool. - External Storage Integration: An external HDD or SSD is connected and assigned `/mnt/external` on a Linux system..
Analyst context for executives and security teams
Drive Creation is a telemetry concept for when a host gains a new accessible storage location, such as a USB device, mapped network share, mounted virtual disk, cloud storage mount, or external drive. For leaders, the value is not the drive letter or mount point itself; it is whether the organization can see when new storage paths appear, because those paths can change where sensitive data is accessed, copied, synchronized, or staged during an investigation.
Executive priority
Treat this as a coverage-validation item for endpoint, identity, cloud-sync, and data-handling controls. Security leaders should ask whether the SOC can prove when removable, network, virtual, or cloud-backed storage becomes available on important systems, and whether that evidence is retained for incident response, audit support, and data movement investigations. Because ATT&CK provides no tactic, platform list, detection guidance, or relationships for this object, prioritization should be based on local risk: critical endpoints, regulated data environments, administrator workstations, and systems where unauthorized storage paths would affect business continuity or compliance evidence.
Technical view
This data component should be used to validate visibility into creation or assignment of new drive letters and mount points. SOC and IR teams should confirm they can reconstruct events such as USB insertion, network drive mapping, virtual disk mounting, cloud storage mounting, and external storage integration as described by ATT&CK. Detection engineering should focus on whether telemetry records the storage type, user or process context where available, host, timestamp, assigned path, source target such as a share or device, and whether the event can be correlated with file access or transfer activity. No ATT&CK detection text or relationship context was supplied, so local baselining is required before treating any instance as suspicious.
Likely telemetry
- Endpoint operating system events showing new drive letters or mount points
- Removable media insertion or external storage connection records
- Network share mapping or mounted remote storage records
- Virtual disk, ISO, or VHD mount activity where collected
- Cloud storage client mount or sync tool activity where collected
Detection direction
- Inventory which security tools actually collect drive creation or mount point events across managed hosts; do not assume coverage because file telemetry exists.
- Baseline expected drive mappings and approved removable or cloud storage use for high-value systems to reduce false positives.
- Correlate new storage availability with unusual file access, large copy activity, new synchronization paths, or activity by privileged users.
- Separate common administrative behavior, standard network drive mappings, and approved external media workflows from rare or policy-violating storage creation.
- Validate retention and searchability so incident responders can determine when a storage path first appeared and what files were accessed afterward.
Mitigation priorities
- Define policy for removable media, network drive mapping, virtual disk mounting, and cloud storage mounting based on business need and data sensitivity.
- Prioritize monitoring and control enforcement on systems handling regulated, sensitive, or operationally critical data.
- Ensure endpoint and logging configurations capture drive creation or mount point evidence with sufficient user, process, host, and path context.
- Use access control, device control, and approved storage workflows where appropriate, but validate with telemetry rather than relying only on policy.
- Include drive creation evidence requirements in incident response playbooks and compliance evidence plans for data movement investigations.
Analyst notes and limits
ATT&CK identifies this as data component DC0042 in the enterprise-attack domain. The official description gives representative examples across USB, network share, virtual disk, cloud storage, and external storage scenarios, but the object does not specify platforms, tactics, detection logic, or relationships. A defensible Glexia use case is therefore coverage assessment: can the organization observe and investigate newly available storage paths?
This take is limited to the supplied ATT&CK fields and references. No active exploitation, adversary use, specific ATT&CK techniques, affected platforms, or guaranteed detections are supported by the provided object. Local environment evidence is required to determine risk, normal behavior, detection fidelity, and control priorities.
Drive Creation
The activity of assigning a new drive letter or creating a mount point for a data storage device, such as a USB, network share, or external hard drive, enabling access to its content on a host system. Examples:
- USB Drive Insertion: A USB drive is plugged in and automatically assigned the letter `E:\` on a Windows machine. - Network Drive Mapping: A network share `\\server\share` is mapped to the drive `Z:\`. - Virtual Drive Creation: A virtual disk is mounted on `/mnt/virtualdrive` using an ISO image or a virtual hard disk (VHD). - Cloud Storage Mounting: Google Drive is mounted as `G:\` on a Windows machine using a cloud sync tool. - External Storage Integration: An external HDD or SSD is connected and assigned `/mnt/external` on a Linux system..
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 8b78a3cebd53… |
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 DC0042Open 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.