File Deletion (MITRE ATT&CK T1070.004) is a Stealth technique. MITRE lists ESXi, Linux, macOS and Windows as platforms.
Intrusions leave things behind. Malware, tools, and other non-native files an adversary drops or creates, for example after Ingress Tool Transfer, can show what was done and how. Removing those files reduces the footprint and the evidence.
How attackers use it
MITRE says deletion can happen during an intrusion, or as a post-intrusion cleanup step. The host operating system already has tools for it, and adversaries may also bring others. The built-in commands MITRE names are del on Windows, rm or unlink on Linux and macOS, and rm on ESXi.
The deletion commands are the same ones your own admins use. The difference is timing, location and who runs them.
How to detect it
MITRE's detection strategy has four analytics:
- Windows: deletion of artifacts such as dropped payloads and evidence files through native or external utilities (del, erase, SDelete), correlated with unusual process lineage or timing after execution.
- Linux: deletion of suspicious files such as payloads, temporary executables and scripts through rm, unlink or secure deletion tools like shred, especially by unexpected users or soon after execution.
- macOS: removal of artifacts through rm, unlink or secure tools, with focus on shell sessions, temporary files, and changed LaunchAgents or system directories.
- ESXi: manual or scripted removal of logs, artifacts or malware droppings through rm or PowerCLI in the ESXi shell, focusing on /tmp/, /var/core/ and /scratch.
What to collect:
- File deletion events. On Windows, Sysmon Event ID 23 (file delete archived) and Event ID 26 (file delete logged) record deletions. Event ID 23 can also keep a copy of the deleted file if you configure it, which can preserve a dropped payload for analysis, so plan storage before you turn it on.
- Process creation with command line and parent, so you can see who ran the deletion.
- On Linux, auditd rules on unlink and related system calls for sensitive directories.
The strongest pattern is a file created and then deleted soon after, by the process that created it. Malware that deletes its own dropper is the classic case.
How to reduce the risk
MITRE states that this technique cannot be easily mitigated with preventive controls, because it abuses system features. Deleting a file is a normal operation. The practical answer is to make sure the deleted file is not the only copy of the evidence:
- Forward events and endpoint telemetry off the host so the record outlasts the file.
- Use endpoint tooling that records file creation and deletion together.
- Where it is feasible, use file integrity monitoring on directories that should rarely change.
Check your own environment
# Linux (auditd): list loaded audit rules (read only)
sudo auditctl -l
# Linux or macOS: list files in /tmp, newest first (read only)
ls -lt /tmp | head -20
# Windows PowerShell: recent Sysmon file delete events (read only; needs Sysmon)
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=23,26} -MaxEvents 20 -ErrorAction SilentlyContinue
Then check these points:
- Do your endpoints record file creation and deletion with the process responsible?
- Is there a place where a deleted file can still be recovered for analysis, such as Sysmon archiving or EDR file capture?
- Are deletions in temp directories, startup folders and ESXi scratch space visible to your monitoring?
Quick check
Why is this technique hard to prevent?
Deleting files is a normal system function. MITRE says it cannot be easily mitigated with preventive controls.
Which Sysmon events record file deletion?
Event ID 23 (file delete archived) and Event ID 26 (file delete logged).
