AN0393: Analytic 0393
Detects deletion of suspicious files (e.g., payloads, temp exes, scripts) via `rm`, `unlink`, or secure deletion tools like `shred`, especially when performed by unexpected users or shortly after execution.
Analyst context for executives and security teams
This analytic matters because suspicious file deletion on Linux can remove evidence needed to understand an incident. Deleting payloads, temporary executables, or scripts with tools such as rm, unlink, or shred shortly after execution can indicate cleanup activity that reduces SOC and incident response visibility, even when the original intrusion behavior is not yet understood.
Executive priority
Prioritize this as an evidence-preservation and response-readiness control for Linux environments. Leaders should ask whether critical Linux systems generate and retain enough process and file activity telemetry to show who deleted suspicious files, when deletion occurred, and whether it followed execution. The business value is faster incident scoping, stronger audit evidence, and reduced risk that responders lose the artifacts needed to determine impact.
Technical view
For Linux, validate whether detections can identify deletion of suspicious files such as payloads, temporary executables, and scripts using rm, unlink, or secure deletion utilities such as shred. Since no ATT&CK detection logic is provided, teams should build local criteria around unexpected users, unusual paths, file types, and temporal proximity to execution events. IR teams should confirm that logs can link process execution, user context, command-line details where available, and file deletion activity into a defensible timeline.
Likely telemetry
- Linux process execution events
- Command-line arguments for deletion utilities where collected
- File deletion or file system activity events
- User and privilege context associated with the deleting process
- Timestamps that allow correlation between file execution and subsequent deletion
Detection direction
- Validate visibility for rm, unlink, and shred execution on Linux hosts.
- Correlate deletion events with prior execution of the same or related file, especially within short time windows.
- Tune for unexpected users, privileged contexts, temporary directories, script locations, and uncommon deletion patterns in the local environment.
- Account for legitimate administrative cleanup, software installation, log rotation, build processes, and maintenance jobs to reduce false positives.
- Pay special attention to secure deletion tools because they may reduce recoverability of artifacts.
Mitigation priorities
- Ensure Linux endpoint logging and retention are sufficient for process, user, command-line, and file activity investigation.
- Restrict unnecessary use of secure deletion utilities on systems where they are not operationally required.
- Define baselines for expected administrative cleanup activity and service accounts.
- Protect and centralize relevant audit and endpoint telemetry so deletion on the host does not remove investigative evidence.
- Include suspicious file deletion scenarios in incident response playbooks and tabletop validation for Linux systems.
Analyst notes and limits
The supplied object is a detection analytic, not a technique entry, and it has no tactics or relationship context. The strongest use is as a validation prompt: can the organization observe and investigate suspicious Linux file deletion, especially after execution and by unexpected users? Local baselines are essential because deletion commands are common in normal administration.
Official detection logic was not provided, and no relationships, tactics, or additional ATT&CK context were supplied. This take is therefore limited to the official description, Linux platform scope, external reference, and object metadata. It should not be interpreted as evidence of active exploitation, attribution, or existing detection coverage.
Analytic 0393
Detects deletion of suspicious files (e.g., payloads, temp exes, scripts) via `rm`, `unlink`, or secure deletion tools like `shred`, especially when performed by unexpected users or shortly after execution.
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 | 1.0 | Current bundle | ccc74091d51e… |
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 AN0393Open 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.