DC0046: Drive Modification
The alteration of a drive letter, mount point, or other attributes of a data storage device, which could involve reassignment, renaming, permissions changes, or other modifications. Examples:
- Drive Letter Reassignment: A USB drive previously assigned `E:\` is reassigned to `D:\` on a Windows machine. - Mount Point Change: On a Linux system, a mounted storage device at `/mnt/external` is moved to `/mnt/storage`. - Drive Permission Changes: A shared drive's permissions are modified to allow write access for unauthorized users or processes. - Renaming of a Drive: A network drive labeled "HR_Share" is renamed to "Shared_Resources." - Modification of Cloud-Integrated Drives: A cloud storage mount such as Google Drive is modified to sync only specific folders.
This data component can be collected through the following measures:
Windows Event Logs
- Relevant Events: - Event ID 98: Indicates changes to a volume (e.g., drive letter reassignment). - Event ID 1006: Logs permission modifications or changes to removable storage. - Configuration: Enable "Storage Operational Logs" in the Event Viewer: `Applications and Services Logs > Microsoft > Windows > Storage-Tiering > Operational`
Linux System Logs
- Auditd Configuration: Add audit rules to track changes to mounted drives: `auditctl -w /mnt/ -p w -k drive_modification` - Command-Line Monitoring: Use `dmesg` or `journalctl` to observe drive modifications.
macOS System Logs
- Unified Logs: Collect mount or drive modification events: `log show --info | grep "Volume modified"` - Command-Line Monitoring: Use `diskutil` to track changes:
Endpoint Detection and Response (EDR) Tools
- Configure policies in EDR solutions to monitor and log changes to drive configurations or attributes.
SIEM Tools
- Aggregate logs from multiple systems into a centralized platform like Splunk to correlate events and alert on suspicious drive modification activities.
Analyst context for executives and security teams
Drive Modification is evidence that storage access paths or attributes changed: drive letters, mount points, names, permissions, or cloud-integrated drive sync settings. For leaders, this matters because changes to where data is mounted or who can write to it can affect data access, monitoring assumptions, investigation timelines, and operational continuity. The ATT&CK object is a data component, not a technique, so its value is in confirming whether teams can see and explain storage configuration changes when an incident, audit question, or access-control review depends on them.
Executive priority
Prioritize this as a visibility and control-validation issue. Security leaders should ask whether changes to removable storage, shared drives, mounted volumes, and cloud-integrated drives are logged centrally and reviewable. This evidence can support incident response scoping, access governance, compliance evidence around storage permissions, and operational resilience when critical data paths or shared resources are altered.
Technical view
SOC, detection engineering, and IR teams should validate collection for drive letter reassignment, mount point changes, drive renaming, permission modifications, and cloud-integrated drive configuration changes. The official object lists collection options including Windows Storage Operational Logs, Linux auditd and system logs, macOS Unified Logs and diskutil-related observations, EDR logging of drive configuration or attribute changes, and SIEM aggregation for correlation. Because ATT&CK provides no official detection logic and no relationship context, local baselining is required to separate normal administration from suspicious or unauthorized changes.
Likely telemetry
- Windows Event Logs related to storage or volume changes, including the cited Event ID 98 and Event ID 1006 examples where applicable
- Windows Storage-Tiering Operational log collection where enabled
- Linux auditd records for monitored mount paths such as /mnt/
- Linux dmesg or journalctl entries related to mounted drive changes
- macOS Unified Logs showing volume or drive modification activity
Detection direction
- Confirm that drive modification events are collected before an incident; this data is often missing because storage operational logging or audit rules may not be enabled by default.
- Tune alerts around unauthorized or unusual changes to drive letters, mount points, drive names, permissions, and cloud sync scope rather than treating every administrative change as malicious.
- Correlate drive modification events with user identity, host, time, administrative change windows, and follow-on file access or permission changes.
- Review false positives from help desk activity, system provisioning, removable media use, backup operations, and storage maintenance.
- Test whether SIEM parsing preserves the original device, prior path or label, new path or label, permissions, and actor context needed for IR reconstruction.
Mitigation priorities
- Establish change-management expectations for storage mount points, shared drive permissions, and cloud-integrated drive configuration changes.
- Enable and centrally retain the relevant storage, system, audit, EDR, and SIEM telemetry described by the ATT&CK object.
- Restrict who can modify drive permissions, mounted storage locations, and shared storage attributes using existing administrative access controls.
- Periodically review shared drive permissions and mount configurations for drift from approved baselines.
- Document retention and retrieval procedures so IR and audit teams can reconstruct storage changes when needed.
Analyst notes and limits
This object is best treated as a coverage checklist item for defensive telemetry. It does not describe adversary behavior by itself; it describes the evidence class that may be useful when investigating or validating storage-related changes. The most useful local questions are: who can change storage attributes, where are those changes logged, how long are records retained, and can analysts tie the change to a user, host, and approved business reason?
No ATT&CK tactics, platforms, official detection, or relationships were supplied for this object. The operating-system examples come from the official description, but actual event availability and field quality depend on local configuration, logging policy, EDR behavior, and SIEM normalization. No active exploitation, attribution, or guaranteed detection coverage is implied.
Drive Modification
The alteration of a drive letter, mount point, or other attributes of a data storage device, which could involve reassignment, renaming, permissions changes, or other modifications. Examples:
- Drive Letter Reassignment: A USB drive previously assigned `E:\` is reassigned to `D:\` on a Windows machine. - Mount Point Change: On a Linux system, a mounted storage device at `/mnt/external` is moved to `/mnt/storage`. - Drive Permission Changes: A shared drive's permissions are modified to allow write access for unauthorized users or processes. - Renaming of a Drive: A network drive labeled "HR_Share" is renamed to "Shared_Resources." - Modification of Cloud-Integrated Drives: A cloud storage mount such as Google Drive is modified to sync only specific folders.
This data component can be collected through the following measures:
Windows Event Logs
- Relevant Events: - Event ID 98: Indicates changes to a volume (e.g., drive letter reassignment). - Event ID 1006: Logs permission modifications or changes to removable storage. - Configuration: Enable "Storage Operational Logs" in the Event Viewer: `Applications and Services Logs > Microsoft > Windows > Storage-Tiering > Operational`
Linux System Logs
- Auditd Configuration: Add audit rules to track changes to mounted drives: `auditctl -w /mnt/ -p w -k drive_modification` - Command-Line Monitoring: Use `dmesg` or `journalctl` to observe drive modifications.
macOS System Logs
- Unified Logs: Collect mount or drive modification events: `log show --info | grep "Volume modified"` - Command-Line Monitoring: Use `diskutil` to track changes:
Endpoint Detection and Response (EDR) Tools
- Configure policies in EDR solutions to monitor and log changes to drive configurations or attributes.
SIEM Tools
- Aggregate logs from multiple systems into a centralized platform like Splunk to correlate events and alert on suspicious drive modification activities.
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 | 6320ff650d2d… |
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 DC0046Open 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.