MITRE ATT&CK for ICS T0809 Data Destruction: Detect Wipers and Keep OT Recoverable

Data Destruction (T0809) in industrial networks is about stopping operators recovering: wipers erase HMIs, engineering files, device memory and backups so that a cyber attack becomes a long outage. MITRE ATT&CK for ICS lists it under Inhibit Response Function, and its procedure examples cover most of the destructive ICS incidents on record: Industroyer and KillDisk in Ukraine, INCONTROLLER's ability to wipe PLC memory, Fuxnet's destruction of sensor gateway storage and the wipers used against Polish energy sites in December 2025. This guide is for OT security engineers, SOC analysts and recovery owners at asset owners. It covers what gets destroyed, how to detect wiping early, how to protect the data needed to recover and how to respond while the process keeps running safely. For the wider matrix see the MITRE ATT&CK for ICS Guide.

Key takeaways

• The target is response and recovery. ATT&CK says data destruction can make operator interfaces unable to respond, disrupt response functions and destroy backups vital to recovery.
• Field devices are in scope, not just Windows. CERT Polska describes deleted files on RTUs and protection relays in 2025; ATT&CK records INCONTROLLER wiping Omron PLC memory and Fuxnet destroying NAND memory on gateways.
• Configuration files are a deliberate target. ATT&CK records Industroyer's wiper overwriting ICS configuration files, specifically targeting ABB PCM600 files, across local and mapped network drives.
• Offline, tested copies decide the outcome. ATT&CK's M0953 Data Backup calls for central storage, remote backups, local redundant storage for outstation event recorders and backup control platforms, preferably hot standbys.
• Detection must be fast. Bulk deletion runs in minutes, so alerting on mass file changes and configuration erase commands, then containing at the conduit, is what limits the damage.

What T0809 covers

ATT&CK for ICS (v20) describes T0809 as data destruction performed during an operation. It covers two purposes: removing the adversary's own tools and files to keep a small footprint, and destroying data to make operator interfaces unable to respond, disrupt response functions and remove backups needed for recovery. ATT&CK notes that standard file deletion commands exist on most operating systems and device interfaces, and names Windows Sysinternals SDelete and Active@ KillDisk as examples of other tools used. The technique applies to Embedded, Windows, Linux and Network Devices platforms.

See the ATT&CK for ICS Inhibit Response Function Tactic Guide, the T0872 Indicator Removal on Host page and the Wiper Malware Guide for wipers in general IT.

The procedure examples and what they teach

CERT Polska's report on the 29 December 2025 attacks adds the device-level detail: default root SSH access on Linux RTUs used to delete all files, built-in FTP accounts with default credentials on relays used to delete files essential for operation so the devices could not restart, serial servers factory reset with unreachable IP addresses set to delay restoration, and wiper distribution at a heat and power plant through a malicious Group Policy object. The report says an endpoint protection canary-file mechanism halted disk overwriting on more than 100 machines. See the Sandworm Threat Actor Profile and the ICS Malware History Guide.

What gets destroyed and what to protect

See the OT Backup, Recovery and Golden Image Guide and the Backup Security and Immutable Backup Guide.

Prevention: limiting reach and keeping copies

ATT&CK lists three mitigations for T0809.

• M0953 Data Backup: use central storage servers such as historians for critical operations, keep remote backups, use local redundant storage for outstation event recorders and keep backup control system platforms, preferably hot standbys, to respond immediately to data destruction.
• M0922 Restrict File and Directory Permissions: protect locally stored files with proper permissions to limit the chance of tampering with stored data.
• M0926 Privileged Account Management: minimise permissions and access for service accounts to limit the data that malicious users or software can affect.

The cases show three more controls that matter in practice. First, remove default accounts on field devices: CERT Polska's device-level destruction ran through default SSH and FTP accounts. Second, limit how software reaches OT hosts: Group Policy was the distribution path for CaddyWiper and for the 2025 wiper, so OT domains or Group Policy scopes should be separate from IT. Third, restrict mapped drives and shares, since Industroyer's wiper followed every mapped network drive.

Phased rollout

1. Back up what you cannot rebuild: collect current controller programs, relay settings, HMI projects and network configurations into an offline repository, with hashes, and test one restore per asset class.
2. Separate backup credentials: backup systems should not share administrator accounts with the OT domain. See the Backup Identity Isolation Guide.
3. Remove default device accounts: start with relays, RTUs and serial servers that offer SSH, FTP, Telnet or web management.
4. Constrain distribution paths: review which Group Policy objects and software deployment tools can reach OT hosts, and remove IT-wide scope.
5. Test the restore: rebuild a spare HMI and reload a spare controller from backups in a planned exercise; record the time taken. See the Backup and Recovery Testing Checklist.

Small sites can start with offline copies of programs and settings plus spare hardware; large estates should add standby control platforms and automated configuration collection.

Detection: ATT&CK's analytics with the OT fidelity gate

ATT&CK v20 attaches the detection strategy Detection of Data Destruction to T0809. Each analytic uses the same gate: alert only when the action is not attributable to an authorised operator or engineering source for that target and function, and is outside an approved change or maintenance window or lacks change-control context; where telemetry allows, require a corroborating device, configuration or process-state effect. Suppress activity that fully matches approved maintenance, commissioning, failover, recovery or tested control procedures.

• Watch distribution paths: new or changed Group Policy objects that apply to OT hosts, and new scheduled tasks or services created across many OT hosts at once, deserve immediate review.
• Use canary files where the endpoint tool supports them: CERT Polska credits a canary-file mechanism with stopping overwriting on more than 100 machines.
• Treat sudden device silence as possible destruction: a relay or RTU that stops communicating after a management session from an unexpected source should be checked, not just restarted.
• Forward logs off the host: wipers remove local logs, so central collection is what preserves the timeline.

See the OT Network Security Monitoring Guide and the OT Security Operations Centre Guide.

Safety-aware response

1. Keep the process safe: if HMIs or engineering hosts are being wiped, operators move to manual operation or local panels. CISA, the FBI, EPA and DOE list practising and maintaining manual OT operation among their primary mitigations.
2. Contain the distribution path: stop the Group Policy object, deployment tool or account spreading the wiper, and block the conduit between IT and OT, before isolating individual operator hosts.
3. Protect what is left: disconnect backup repositories and engineering archives from the network until the spread is understood.
4. Preserve evidence: image a sample of affected hosts before rebuilding, keep sensor captures and central logs, and record the state of failed field devices.
5. Recover in priority order: restore protection and safety devices first, then control, then supervisory systems, from verified offline copies. Plan for replacing devices whose storage was physically damaged, as in the Fuxnet case.

Follow the Wiper Attack Response Playbook and the OT Incident Response Guide.

Where identity fits

The destructive steps in the cases ran on privileged identities: domain accounts that could change Group Policy, default device accounts on RTUs and relays, and service accounts with write access to engineering shares. Limiting those identities, as ATT&CK's M0926 says, limits how much a single compromise can destroy. See the OT and ICS Identity and Access Guide.

Metrics that show it is working

• Backup coverage: share of controllers, relays, HMIs and network devices with a current offline backup and hash. Target 100% for safety and protection devices.
• Restore time: measured time to rebuild an HMI and reload a controller in the last exercise.
• Default device accounts: field devices still using vendor default credentials, trending to zero.
• OT reach of IT distribution tools: Group Policy objects or deployment packages from IT that apply to OT hosts. Target zero.
• Spare hardware: share of critical device types with a spare on site or under contract.

Framework mapping

NIST SP 800-82 Rev. 3 (final, September 2023) is the OT tailoring reference; see the NIST SP 800-82 OT Security Guide.

Common failure patterns

• Backups on the same network and credentials: a wiper that reaches the domain reaches the backups too.
• No copies of device settings: relay and RTU settings that exist only on the device and one engineering laptop are lost with them.
• IT Group Policy applying to OT hosts: ATT&CK records CaddyWiper deployed via Group Policy, and CERT Polska describes the same path in 2025.
• Default device accounts: the 2025 field device destruction used default SSH and FTP credentials.
• Untested restores: backups that have never been restored often miss licences, drivers or project dependencies.
• No spares: devices with physically damaged storage, as in Fuxnet, need replacement hardware.

Practitioner checklist

• Keep offline, hashed copies of controller programs, relay settings, HMI projects and network configurations.
• Store backup credentials and repositories separately from the OT domain.
• Remove default accounts on relays, RTUs, serial servers and controllers.
• Remove IT-wide Group Policy and software deployment scope from OT hosts.
• Restrict mapped drives and shares on HMIs and engineering workstations.
• Deploy the ATT&CK T0809 analytics, including configuration erase and bulk deletion alerts.
• Forward OT host and device logs to central collection.
• Run a restore exercise for each asset class at least once a year (NHI Mgmt Group recommendation).
• Hold spare hardware for critical controllers, relays and gateways.

Standards and references

• MITRE ATT&CK for ICS: Data Destruction (T0809)
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• CERT Polska: Energy Sector Incident Report 2025
• CISA, FBI, EPA and DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• ESET: Industroyer2, Industroyer Reloaded
• CISA, DOE, NSA and FBI: AA22-103A, APT Cyber Tools Targeting ICS/SCADA Devices
• Claroty Team82: Unpacking the Blackjack Group's Fuxnet Malware

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · Wiper Malware Guide · OT Backup, Recovery and Golden Image Guide · T1490 Inhibit System Recovery Defensive Guide · OT Security Guide