T1070: Indicator Removal
Adversaries may selectively delete or modify artifacts generated to reduce indications of their presence and blend in with legitimate activity. Rather than broadly removing evidence, adversaries may target specific artifacts that appear anomalous or are likely to draw scrutiny, while leaving sufficient data intact to maintain the appearance of normal system behavior.
Artifacts such as command histories, log entries, or file metadata may be altered in ways that align with expected user or system activity. Location, format, and type of artifact (such as command or login history) are often platform-specific, allowing adversaries to tailor modifications that minimize suspicion.
These actions may not prevent detection entirely but can delay recognition of malicious activity or reduce the fidelity of alerts by making events appear benign or consistent with routine operations. Additionally, selectively removed or modified artifacts may still be recoverable through deeper forensic analysis, though their absence or alteration can complicate timeline reconstruction and attribution.
Security context for executives and security teams
Indicator Removal matters because it can make an incident look smaller, later, or less suspicious than it really is. The business risk is not just “lost logs”; it is delayed containment, weaker forensic timelines, harder legal/audit evidence collection, and reduced confidence in whether recovery is complete. Because ATT&CK lists broad platforms including Windows, Linux, macOS, ESXi, containers, network devices, and Office Suite, leaders should treat this as a cross-environment evidence protection problem, not only an endpoint logging issue.
Executive priority
Prioritize controls that preserve trustworthy evidence before and during an incident. Ask whether critical logs, command histories, mailbox artifacts, file metadata, network connection history, and persistence evidence are protected from local tampering and retained centrally. This technique is especially relevant to incident response readiness, compliance evidence, privileged access governance, cloud/SaaS auditability for Office Suite activity, and resilience of network and virtualization infrastructure. Budget decisions should favor centralized/off-host logging, least-privilege access to sensitive files and directories, and tested forensic collection procedures.
Technical view
SOC, detection engineering, and IR teams should validate coverage across the parent technique and its sub-techniques: clearing command history, file deletion, network share connection removal, timestomping, clearing network connection history/configurations, clearing mailbox data, clearing persistence, and relocating malware. Since the ATT&CK object provides no official detection text, use the related DET0184 behavioral detection strategy as direction: look for selective tampering patterns rather than only bulk log clearing. Focus on discrepancies between local artifacts and centralized records, unusual deletion or modification of security-relevant files, suspicious timestamp inconsistencies, removal of network/share history, mailbox data changes, and cleanup of persistence artifacts.
Likely telemetry
- Centralized security, system, application, authentication, and audit logs forwarded off-host
- Endpoint file creation, deletion, rename, metadata, and permission-change events
- Command shell and command-history artifacts where collection is authorized and available
- Windows network share and SMB connection history evidence
- Linux, macOS, ESXi, and network device configuration and connection-history logs
Detection direction
- Validate that local logs are compared with off-host copies so selective deletion or modification becomes observable.
- Tune for suspicious absence, alteration, or mismatch of artifacts, not only explicit log-clearing commands.
- Correlate indicator removal behavior with nearby activity such as tool transfer, remote services, mailbox access, persistence changes, or file deletion when those events are available.
- Review false positives from legitimate administration, cleanup jobs, privacy retention processes, mailbox lifecycle actions, patching, and system maintenance.
- Confirm that network devices, ESXi, containers, and Office Suite sources are not blind spots, since endpoint-only monitoring will miss supported platforms.
Mitigation priorities
- Implement restricted file and directory permissions so ordinary users, groups, or processes cannot modify sensitive logs, security artifacts, or system evidence unnecessarily.
- Forward critical logs and audit data to secure remote storage or centralized log management to reduce the value of local artifact tampering.
- Apply least privilege to administrative, service, mailbox, and infrastructure accounts that can delete or modify evidence.
- Protect sensitive information and integrity-relevant data with appropriate encryption where applicable, consistent with the ATT&CK mitigation relationship.
- Test incident response playbooks for evidence preservation, including collection from endpoints, mail systems, network devices, ESXi, containers, and centralized logs.
Additional notes and limits
The relationship context shows this technique is used by multiple ATT&CK campaigns, groups, and software entries, and it has several sub-techniques that make the behavior operationally broad. For Glexia clients, the practical assessment should be evidence survivability: if a privileged actor can alter local artifacts, can the SOC still reconstruct activity from independent sources? The presence of SolarWinds Compromise, Cutting Edge, Lazarus Group, Mustang Panda, APT5, APT42, and several software relationships supports treating this as a common tradecraft category, but not as proof of current activity in any specific environment.
MITRE did not provide official detection text for this object. Platform applicability is broad, but exact log sources, retention, and forensic recoverability depend on the local operating systems, SaaS configuration, infrastructure devices, and collection architecture. This take does not assert active exploitation, customer exposure, or guaranteed detection coverage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Indicator Removal
Adversaries may selectively delete or modify artifacts generated to reduce indications of their presence and blend in with legitimate activity. Rather than broadly removing evidence, adversaries may target specific artifacts that appear anomalous or are likely to draw scrutiny, while leaving sufficient data intact to maintain the appearance of normal system behavior.
Artifacts such as command histories, log entries, or file metadata may be altered in ways that align with expected user or system activity. Location, format, and type of artifact (such as command or login history) are often platform-specific, allowing adversaries to tailor modifications that minimize suspicion.
These actions may not prevent detection entirely but can delay recognition of malicious activity or reduce the fidelity of alerts by making events appear benign or consistent with routine operations. Additionally, selectively removed or modified artifacts may still be recoverable through deeper forensic analysis, though their absence or alteration can complicate timeline reconstruction and attribution.
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.
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.
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.