ATT&CK for ICS T0872: Indicator Removal on Host in OT

Indicator Removal on Host (T0872) is an adversary deleting, overwriting or covering up the traces they left on an OT system, from Windows event logs on an HMI to the program memory of a safety controller. In OT the loss is worse than in IT: many controllers and field devices keep little or no history, so the few records that exist are often the only evidence of what changed in the process. MITRE ATT&CK for ICS v20 lists T0872 under Evasion for Embedded, Windows, Linux and Network Devices platforms, with no sub-techniques. This guide is for OT security engineers, OT SOC analysts and incident responders: what the recorded cases show, what ATT&CK's analytics look for, and how to keep evidence somewhere an intruder cannot reach. Log clearing on ordinary IT hosts is covered in the T1070 Indicator Removal Defensive Guide; this page covers what is different in OT.

Key takeaways

Controllers can be cleaned too. ATT&CK records Triton overwriting its malicious program on a safety controller with invalid data when the controller did not recover, which Mandiant assessed as anti-forensics.
Wipers double as indicator removal. ESET reports CaddyWiper scheduled to run on the machine that launched Industroyer2 in April 2022, to erase its traces.
Forward logs off the host. ATT&CK's only listed mitigation is M0922 Restrict File and Directory Permissions; central collection is what keeps evidence when permissions fail.
Gaps are a signal. One v20 analytic looks for missing syslog sequence numbers or forwarding interruptions on ICS network devices during suspicious activity.
Offline baselines are evidence. An approved copy of each controller program lets you prove what changed even after the attacker cleaned up.

What T0872 covers in OT

ATT&CK for ICS describes adversaries attempting to remove indicators of their presence on a system to cover their tracks, and, where detection seems imminent, overwriting, deleting or covering up changes they have made to the device. The phrase "changes they have made to the device" is the OT-specific part: reverting or overwriting controller logic is indicator removal, not only log deletion.

Where indicators live	What removal looks like	Where to keep a copy
Windows HMI, SCADA server, engineering workstation	Clearing Security, System or Application logs; deleting ICS vendor application logs	Central log collector outside the zone
Linux ICS servers and gateways	Truncating application or auth logs; editing shell history	Remote syslog; audit records forwarded in real time
Controllers and safety systems	Restoring the previous program, writing a dummy program, clearing device event logs over the ICS protocol	Approved offline program copies; network captures of engineering sessions
Network devices in OT	Clearing local logs; interrupting syslog forwarding	Remote syslog with sequence numbers

The recorded cases

Triton (S1009) and the Triton Safety Instrumented System Attack (C0030): ATT&CK records Triton trying to reset the controller to its previous state over TriStation and, if that failed, writing a dummy program to memory, likely as anti-forensics. For the campaign, ATT&CK records TEMP.Veles (G0088) programmatically returning the controller to a normal running state if the malware failed and, if it could not recover in a defined time window, overwriting the malicious program with invalid data. Mandiant's December 2017 report adds that the incident came to light because some safety controllers entered a failed safe state and shut down the process.
KillDisk (S0607): ATT&CK records KillDisk deleting application, security, setup and system event logs from Windows systems.
CaddyWiper with Industroyer2: ESET's April 2022 analysis reports CaddyWiper scheduled on the machine that ran Industroyer2, ten minutes after it, to erase its traces, and Linux wipers deleting files under /var/log among other destruction. ATT&CK's Windows analytic for T0872 cites the CaddyWiper deployment as intended to destroy evidence and slow forensic recovery. Wiping on this scale is also Data Destruction (T0809), which has its own page.

The common thread is timing: removal happens when the attack fails or finishes. Evidence collected only after an incident is declared will often be gone.

Detection: ATT&CK v20 analytics

MITRE's detection strategy DET0750 has four analytics, each gated to alert only when the activity breaks an approved signer, hash, path, parent, process or tool allowlist, or comes from an unauthorised user or tool, and is tied to an OT asset or follow-on OT action, while suppressing approved engineering utilities, diagnostics, patching, backup and documented maintenance.

Platform	What the analytic looks for	Data needed
Windows	An audit log clearing event, or deletion or truncation of an ICS vendor application log, shortly after other suspicious activity on the same host	Security Event ID 1102 and System Event ID 104 (log cleared), file deletion events on vendor log paths
Linux	Truncation or deletion of ICS application or auth logs, or changes to shell history, by a user ID that does not normally manage log rotation	auditd watches on log directories and history files
Network devices	Gaps in expected syslog sequence numbers, or a forwarding interruption, coinciding with suspicious activity on the device	Remote syslog with sequence numbers enabled; collector health monitoring
Embedded	Field device event logs cleared through ICS protocol commands from a source not on the approved engineering workstation list, right after other suspicious ICS activity	Protocol-aware OT network monitoring

For controllers, add a check ATT&CK's cases point to: compare the running program with the approved offline copy after any unexplained engineering session, fault or unplanned restart. A controller that was "restored" by an attacker may match the baseline while network captures still show the download that preceded it, which is why captures of engineering traffic are worth retaining. See the OT Network Security Monitoring Guide.

Prevention: keeping evidence out of reach

M0922 Restrict File and Directory Permissions: ATT&CK says to protect locally stored files with proper permissions to limit opportunities to remove indicators. On Windows OT hosts, operators and service accounts should not hold rights to clear logs; on Linux, log files should be writable only by the logging service.
Forward in near real time: send Windows events, Linux audit records and network device syslog to a collector in a separate zone, so a cleared local log leaves a copy behind. See the CIS Control 8 Audit Log Management Guide.
Protect the collector: the collector and its storage need separate administrative credentials from the OT hosts they watch, or one compromised account removes both copies.
Keep offline program baselines: CISA's AA22-103A advice includes offline backups of controller configurations and firmware verified by hashing. See the OT Backup, Recovery and Golden Image Guide.
Limit who can write to controllers: Mandiant's Triton recommendations include keeping safety controller key switches out of program mode except during scheduled programming, auditing key state and segregating safety networks. An attacker who cannot download cannot overwrite either.

Where identity fits

Log clearing needs a privileged account. In OT that is often a shared local administrator on HMIs, a shared engineering account or a vendor support login, which makes the removal both easy and unattributable. Named accounts, removal of standing local admin rights from operator logons and separate credentials for the log collector turn a clean-up into an attributable, alertable event. See the OT and ICS Identity and Access Guide.

How to implement

Inventory evidence sources per zone: which hosts, devices and controllers produce logs or history, and where each is stored.
Turn on forwarding for Windows, Linux and network devices, with sequence numbers on syslog where supported, and monitor collector health so silence is noticed.
Tighten permissions on log files and remove log clearing rights from operator and service accounts, after testing that vendor applications still write their logs.
Deploy DET0750-style alerts in alert-only mode through a maintenance cycle (our recommendation), suppressing documented log rotation and patching.
Baseline controller programs offline, with hashes, and schedule comparisons with the running program.
Keep a rollback: record permission and audit policy changes with prior values so a change that breaks a vendor application can be reversed.

Decision guidance

What to forward first: engineering workstations and SCADA servers, since they can reach controllers and their logs show who did what.
Devices without logging: rely on network captures of engineering sessions and offline program comparison; there is no host evidence to protect.
Small sites: forwarding from a handful of Windows hosts to one protected collector, plus offline program copies, covers most of the risk.
Large sites: add sequence gap and forwarding interruption alerts, protocol-aware detection of device log clearing and regular program integrity checks. See the OT Security Operations Centre Guide.

Responding when indicators are removed

Treat a cleared log on an OT host as a sign of a wider intrusion, not a housekeeping error. Confirm process safety with operations first. Preserve what remains: the central log copy, network captures, memory and disk images where the host can be taken out of service, and the controller's current program. Compare controller programs with approved copies before restarting anything. Expect further destructive activity, as with CaddyWiper, and prepare known-good images before restoring. See the OT Incident Response Guide and the Anti-Forensics Detection Guide.

Detection and measurement

Forwarding coverage: percentage of OT Windows, Linux and network devices sending logs to the central collector.
Silence detection: time to alert when an OT source stops sending logs.
Clearing rights: number of accounts able to clear logs on OT hosts, tracked down to administrators only.
Program baselines: percentage of controllers with a current, hashed offline program copy.
Log clear events: count of log clearing events not matched to a change record, each investigated.

Framework mapping

Framework	Reference	How it applies
MITRE ATT&CK for ICS v20	T0872; M0922; DET0750; related T0809 Data Destruction	Technique, mitigation and analytics
MITRE ATT&CK Enterprise v20	T1070 Indicator Removal	Enterprise equivalent for IT hosts in OT zones
NIST SP 800-53 Rev. 5	AU-9 Protection of Audit Information, AU-6 Audit Record Review, Analysis, and Reporting, SI-7 Software, Firmware, and Information Integrity	Protecting logs, reviewing them and checking controller program integrity
NIST SP 800-82 Rev. 3	OT overlay guidance on audit and integrity	Applying these controls to OT

Common failure patterns

Logs only on the host: the evidence lives where the attacker has administrator rights.
Nobody notices silence: a source that stops sending is treated as a network glitch.
No program baseline: after a controller fault, nobody can say whether the running logic is the approved version.
Shared admin accounts: a log clear event exists but cannot be tied to a person.
Rebuilding before preserving: hosts are reimaged to restore operations and the remaining evidence goes with them.

Practitioner checklist

Forward OT host and network device logs to a collector in a separate zone.
Alert on Windows Event IDs 1102 and 104 on OT hosts.
Watch Linux log directories and history files with auditd.
Alert when an OT log source goes silent.
Remove log clearing rights from operator, vendor and service accounts.
Keep hashed offline copies of every controller program and compare after unexplained events.
Retain network captures of engineering sessions to controllers and safety systems.
Preserve evidence before reimaging or restoring during an incident.

T0872 Indicator Removal on Host: Protecting OT Evidence from Erasure