AN1882: Analytic 1882
Monitor executed commands and arguments that may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Monitor for API calls that may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Monitor for changes made to Windows Registry keys or values that may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. For added context on adversary procedures and background see Indicator Removal and applicable sub-techniques. Monitor for contextual file data that may show signs of deletion or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Monitor Windows registry keys that may be deleted or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. For added context on adversary procedures and background see Indicator Removal and applicable sub-techniques. Monitor for a file that may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Monitor for changes made to a file may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Monitor for newly executed processes that may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware.
Analyst context for executives and security teams
This analytic is about preserving and monitoring evidence that attackers may try to delete or alter after activity on a host, such as logs, captured files, quarantined malware, registry artifacts, or file changes. For executives and security leaders, the practical value is not just detection; it is whether the organization can still reconstruct what happened during an incident if local artifacts are tampered with.
Executive priority
Prioritize this as an incident-readiness and evidence-integrity concern. If attackers or unauthorized processes can remove local artifacts without detection, SOC triage, incident response scoping, audit evidence, and recovery decisions become less reliable. Leaders should ask whether critical host telemetry is centrally collected, protected from local tampering, and retained long enough to support investigations, especially in ICS environments where operational continuity and forensic clarity matter.
Technical view
The supplied ATT&CK analytic describes monitoring executed commands and arguments, API calls, file activity, process execution, contextual file data, and Windows Registry key or value changes that may indicate deletion or alteration of generated host artifacts. SOC and IR teams should validate whether these evidence classes are collected, normalized, and correlated around suspicious artifact removal. Because ATT&CK does not provide tactics, platforms, relationships, or a separate detection implementation for this object, teams should tune locally against expected administrative, cleanup, security-tool, and maintenance behavior.
Likely telemetry
- Process execution events and command-line arguments
- API call telemetry related to file or artifact deletion or modification
- File creation, deletion, modification, and metadata/contextual file events
- Host log deletion or alteration events where available
- Security-tool quarantine or captured-file activity logs
Detection direction
- Validate that host artifact deletion or alteration events are forwarded off-host before local tampering can remove evidence.
- Correlate process execution, command arguments, file changes, registry changes, and API activity rather than relying on a single event type.
- Tune for legitimate noise from administrators, patching, cleanup scripts, endpoint security products, and maintenance jobs.
- Pay special attention to deletion or modification of logs, captured files, quarantine locations, and other investigation-relevant artifacts.
- Use the ATT&CK reference to Indicator Removal as context, but do not assume a specific technique, platform, or adversary from this analytic alone.
Mitigation priorities
- Centralize and protect logging so host-local deletion does not eliminate investigation evidence.
- Restrict unnecessary permissions to delete or alter logs, captured files, quarantine stores, and registry areas relevant to investigation.
- Define retention and integrity requirements for incident evidence, including ICS-relevant hosts where applicable.
- Review administrative cleanup processes so expected artifact removal is documented and distinguishable from suspicious behavior.
- Test incident response playbooks to confirm analysts can recover evidence when local artifacts are missing or modified.
Analyst notes and limits
This is a detection analytic object, not a full ATT&CK technique entry. Its value is strongest as a coverage-validation checklist for evidence integrity and post-activity cleanup monitoring. The official text explicitly mentions commands, API calls, files, process execution, contextual file data, and Windows Registry changes, but it does not supply platforms, tactics, relationships, or a concrete detection query.
No official detection logic, platforms, tactics, related techniques, or relationships were supplied. The analytic references Indicator Removal for background, but this response does not infer specific adversary behavior, active exploitation, or guaranteed detection coverage. Local asset roles, logging architecture, endpoint controls, and retention policy are required to determine actual risk and coverage.
Analytic 1882
Monitor executed commands and arguments that may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Monitor for API calls that may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Monitor for changes made to Windows Registry keys or values that may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. For added context on adversary procedures and background see Indicator Removal and applicable sub-techniques. Monitor for contextual file data that may show signs of deletion or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Monitor Windows registry keys that may be deleted or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. For added context on adversary procedures and background see Indicator Removal and applicable sub-techniques. Monitor for a file that may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Monitor for changes made to a file may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Monitor for newly executed processes that may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware.
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 | dd467bcefe5c… |
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 AN1882Open 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.