AN0392: Analytic 0392
Detects adversary behavior deleting artifacts (e.g., dropped payloads, evidence files) using native or external utilities (e.g., del, erase, SDelete). Detects deletion events correlated with unusual process lineage or timing post-execution.
Analyst context for executives and security teams
This analytic is about spotting cleanup behavior on Windows: adversaries deleting dropped payloads, evidence files, or other artifacts after execution using native or external utilities such as del, erase, or SDelete. For leaders, the practical value is incident confidence: if cleanup activity is missed, responders may underestimate scope, lose evidence, and struggle to reconstruct what happened.
Executive priority
Prioritize this as an incident response and SOC readiness control rather than a standalone prevention measure. The key business question is whether the organization can preserve and correlate Windows process and file-deletion evidence quickly enough to support containment decisions, legal/audit evidence needs, and post-incident root-cause analysis. Because the ATT&CK object provides no tactic mapping or relationships, use it as a validation prompt for detection coverage around suspicious artifact deletion, not as proof of a specific campaign or impact scenario.
Technical view
Validate whether Windows telemetry can correlate file deletion events with process lineage and timing after process execution. Detection engineering should focus on deletion activity by native or external utilities, especially when the parent/child process chain is unusual for the host, user, or workload. Since no official detection logic is provided, teams should build or tune analytics around process creation, command-line context where available, file deletion evidence, executable names associated with deletion utilities, and temporal proximity to suspicious execution events.
Likely telemetry
- Windows process creation events, including process name, parent process, user, host, and command-line context where collected
- File deletion or file system auditing events for deleted artifacts and paths
- Endpoint detection and response telemetry showing process lineage and file operations
- Timing correlation between prior execution events and subsequent deletion activity
- Host and user baselines to identify unusual deletion utilities or unexpected parent-child process relationships
Detection direction
- Confirm that deletion utilities and file deletion events are visible on Windows endpoints; many environments collect process starts but not reliable file-deletion evidence.
- Correlate deletion activity with unusual process lineage and timing after execution, as specified by the analytic description.
- Tune for administrative and software-maintenance false positives, including scripts, installers, update processes, cleanup jobs, and legitimate secure deletion tools.
- Prioritize alerts where deletion occurs shortly after suspicious execution or where the deleting process has an uncommon parent, path, user context, or host role.
- Document blind spots where command-line logging, endpoint file-operation telemetry, or retention is insufficient to reconstruct deleted artifacts.
Mitigation priorities
- First, ensure Windows endpoint logging and EDR policies retain enough process lineage and file-operation detail for investigation.
- Second, define normal administrative cleanup patterns so the SOC can separate routine maintenance from suspicious post-execution deletion.
- Third, restrict or monitor use of external secure deletion utilities where business need is limited, using existing endpoint control and software governance processes.
- Fourth, incorporate deletion-event review into incident response playbooks so responders preserve volatile evidence and investigate preceding execution activity.
- Finally, use audit and compliance evidence to show that artifact deletion attempts are detectable, investigated, and retained according to organizational requirements.
Analyst notes and limits
This object is a detection analytic, not a technique. It applies to Windows and describes detection of artifact deletion using native or external utilities, correlated with unusual process lineage or post-execution timing. No tactic, relationship context, or official detection query was supplied, so local telemetry design and baselining are required.
The supplied ATT&CK fields do not include official detection logic, tactics, related techniques, data sources, mitigations, or relationships. This take does not infer attribution, active exploitation, impact, or guaranteed coverage. Effectiveness depends on local Windows logging, EDR visibility, retention, baselines, and incident response procedures.
Analytic 0392
Detects adversary behavior deleting artifacts (e.g., dropped payloads, evidence files) using native or external utilities (e.g., del, erase, SDelete). Detects deletion events correlated with unusual process lineage or timing post-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 | 67a1a77452fe… |
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 AN0392Open 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.