T0872: Indicator Removal on Host
Adversaries may attempt to remove indicators of their presence on a system in an effort to cover their tracks. In cases where an adversary may feel detection is imminent, they may try to overwrite, delete, or cover up changes they have made to the device.
Analyst context for executives and security teams
Indicator Removal on Host matters because it can reduce an organization’s ability to understand what changed in an ICS environment after suspicious activity. In operational technology, deleted or overwritten evidence on workstations, HMIs, controllers, historians, jump hosts, VPN servers, firewalls, and other ICS assets can slow incident response and complicate decisions about whether operations are safe to continue.
Executive priority
Treat this as an incident-readiness and resilience issue, not just a logging issue. Leaders should ask whether critical ICS assets preserve enough evidence to support root-cause analysis, safety decisions, regulatory/audit questions, and recovery prioritization if an adversary attempts to cover tracks. ATT&CK links this technique to ICS-relevant software/campaign context including KillDisk, Triton, and the Triton Safety Instrumented System Attack, so the business concern is evidence integrity around systems that may support control, monitoring, remote access, and safety functions.
Technical view
MITRE provides no official detection text and no technique-level platform list, but relationships show broad ICS asset targeting across Windows, Linux, embedded, and network-oriented assets. SOC and IR teams should validate the related detection strategy DET0750 against the actual asset classes in scope: workstations, HMIs, PLCs, RTUs, IEDs, historians, control servers, application servers, data gateways, safety controllers, VPN servers, jump hosts, switches, firewalls, DCS controllers, and PACs. Practical validation should focus on whether deletion, overwrite, or concealment of host/device indicators can be observed and corroborated from independent sources.
Likely telemetry
- Host file and directory audit records for deletion, overwrite, and permission changes where available
- Security, system, application, and ICS application logs from workstations, HMIs, servers, jump hosts, and VPN servers
- Device configuration, project, logic, firmware, and diagnostic records for embedded controllers and field devices where supported
- Historian events, alarms, and operational event records that may corroborate host-side activity
- Firewall, switch, data gateway, and remote access logs that can provide independent timing and session context
Detection direction
- Validate whether DET0750 is implemented as a practical detection strategy in the local ICS environment; MITRE does not provide detailed detection logic for this object.
- Prioritize correlation across independent telemetry sources so removal of local evidence on one host can still be investigated using network, historian, remote access, or backup records.
- Tune for expected engineering and maintenance activity, since legitimate administrators may delete logs, rotate files, modify projects, or perform cleanup during approved work.
- Pay special attention to assets with limited host logging, especially embedded controllers and network devices, where evidence may need to come from configuration management, device diagnostics, or surrounding network infrastructure.
- Test IR playbooks for scenarios where primary host evidence is incomplete, overwritten, or unavailable.
Mitigation priorities
- Apply the related mitigation M0922 by restricting file and directory permissions on critical ICS systems and evidence-bearing paths.
- Prioritize permission hardening and change control for HMIs, engineering workstations, control servers, historians, jump hosts, VPN servers, and safety-related assets before less critical systems.
- Limit who can modify or delete logs, configurations, project files, and diagnostic artifacts; verify that privileged access is reviewed and operationally justified.
- Maintain independent records such as backups, configuration baselines, and centralized or segmented logging where feasible for the asset type.
- Include evidence preservation requirements in incident response and maintenance procedures so legitimate operational work does not erase needed forensic context.
Analyst notes and limits
This technique is especially decision-relevant in ICS because the targeted asset relationships span operator workstations, control and monitoring systems, remote access infrastructure, network boundary devices, and embedded control/safety equipment. The key defensive question is whether the organization can still reconstruct activity when local indicators are removed from a host or device.
The ATT&CK object has no official detection text, no specified tactics, and no technique-level platforms. Telemetry and control recommendations therefore require local validation against the actual ICS asset inventory, logging capabilities, vendor constraints, and operational safety requirements.
Indicator Removal on Host
Adversaries may attempt to remove indicators of their presence on a system in an effort to cover their tracks. In cases where an adversary may feel detection is imminent, they may try to overwrite, delete, or cover up changes they have made to the device.
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.
Groups, software, and campaigns
S1009: Triton
S0607: KillDisk
KillDisk is a disk-wiping tool designed to overwrite files with random data to render the OS unbootable. It was first observed as a component of BlackEnergy malware during cyber attacks against Ukraine in 2015. KillDisk has since evolved into stand-alone malware used by a variety of threat actors against additional targets in Europe and Latin America; in 2016 a ransomware component was also incorporated into some KillDisk variants.[1][2][3][4]
C0030: Triton Safety Instrumented System Attack
Triton Safety Instrumented System Attack was a campaign employed by TEMP.Veles which leveraged the Triton malware framework against a petrochemical organization.[1] The malware and techniques used within this campaign targeted specific Triconex Safety Controllers within the environment.[2] The incident was eventually discovered due to a safety trip that occurred as a result of an issue in the malware.[3]
All related ATT&CK context
Mitigation direction
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 | 20b4c40ef225… |
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 T0872Open 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.