DC0040: File Deletion
Refers to events where files are removed from a system or storage device. These events can indicate legitimate housekeeping activities or malicious actions such as attackers attempting to cover their tracks. Monitoring file deletions helps organizations identify unauthorized or suspicious activities.
Analyst context for executives and security teams
File deletion events matter because they can be routine maintenance or a sign that someone is removing evidence, disrupting operations, or changing stored data without authorization. For leaders, the value is not simply logging deletions; it is knowing whether the organization can distinguish expected housekeeping from suspicious removal of files when an incident, audit question, or recovery decision depends on it.
Executive priority
Prioritize this as an evidence-quality and operational resilience control area. Security and IT leaders should ask whether critical systems, shared storage, endpoint estates, and relevant cloud or backup locations produce reliable deletion records, how long those records are retained, and whether incident responders can use them to reconstruct activity. This data component can support SOC investigations, IR timelines, compliance evidence, and recovery decisions, but the ATT&CK object does not specify platforms or tactics, so local asset criticality should drive priority.
Technical view
DC0040 is a data component for events where files are removed from a system or storage device. Because ATT&CK provides no platform scope, tactic mapping, or detection logic for this object, SOC and detection teams should validate coverage by environment rather than assuming universal visibility. Useful validation includes confirming which operating systems, file services, endpoint tools, storage platforms, and audit configurations generate deletion events; whether events identify the file path, actor/account, host, timestamp, process or service where available, and result; and whether telemetry survives endpoint tampering or log rotation long enough to support investigations.
Likely telemetry
- Endpoint or host file system audit events recording file removal
- File server or shared storage audit logs for deleted objects
- Endpoint detection and response telemetry that records file delete activity
- Operating system security or audit logs where file deletion auditing is enabled
- Backup, snapshot, or storage metadata showing removed files or changed object state
Detection direction
- Baseline expected deletion patterns for administrative cleanup, software updates, user workflows, and retention jobs before alerting on volume alone.
- Tune for suspicious context such as deletion of security-relevant files, unusual paths, high-volume deletion, deletion by unexpected accounts, or deletion occurring near other investigation-relevant activity, using local telemetry because no ATT&CK detection text is provided.
- Validate whether deletion events include enough identity and asset context to distinguish user action, service account activity, automated jobs, and system processes.
- Check blind spots where file deletion auditing is disabled, logs are overwritten quickly, shared storage lacks object-level auditing, or backup/storage deletion records are not forwarded to the SOC.
- Treat file deletion alerts carefully because legitimate housekeeping can create high false-positive volume; correlation with asset criticality, account behavior, timing, and change records is usually needed.
Mitigation priorities
- Enable and standardize file deletion auditing on systems and storage locations that hold business-critical, regulated, or investigation-relevant data.
- Forward deletion telemetry to centralized logging with retention aligned to incident response and compliance needs.
- Restrict and review permissions for users and service accounts that can delete sensitive or high-value files.
- Protect logs and backups so deletion activity can still be investigated after local data changes.
- Document expected maintenance and retention jobs so SOC teams can separate authorized deletion from suspicious activity.
Analyst notes and limits
This object is a data component, not an ATT&CK technique. Its main decision value is to help teams verify whether they collect a class of evidence needed during investigations. The official description explicitly notes both legitimate housekeeping and malicious track-covering as possible interpretations, so analysis must be context-driven.
The supplied ATT&CK fields provide no platforms, tactics, relationships, or official detection guidance. Any assessment of coverage, priority systems, detection thresholds, or control effectiveness requires local environment details and telemetry review.
File Deletion
Refers to events where files are removed from a system or storage device. These events can indicate legitimate housekeeping activities or malicious actions such as attackers attempting to cover their tracks. Monitoring file deletions helps organizations identify unauthorized or suspicious 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 | 3.0 | Current bundle | 93085d1c6a02… |
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 DC0040Open 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.