T0809: Data Destruction
Adversaries may perform data destruction over the course of an operation. The adversary may drop or create malware, tools, or other non-native files on a target system to accomplish this, potentially leaving behind traces of malicious activities. Such non-native files and other data may be removed over the course of an intrusion to maintain a small footprint or as a standard part of the post-intrusion cleanup process. [1]
Data destruction may also be used to render operator interfaces unable to respond and to disrupt response functions from occurring as expected. An adversary may also destroy data backups that are vital to recovery after an incident.
Standard file deletion commands are available on most operating system and device interfaces to perform cleanup, but adversaries may use other tools as well. Two examples are Windows Sysinternals SDelete and Active@ Killdisk.
Analyst context for executives and security teams
Data Destruction in ICS matters because it can turn a cyber intrusion into an operational recovery problem. ATT&CK describes adversaries deleting files, tools, backups, or other data, including actions that may make operator interfaces unresponsive or interfere with response functions. For executives and security leaders, the key issue is not only whether malware is found, but whether critical workstations, HMIs, controllers, historians, gateways, jump hosts, and backups can be trusted and restored quickly after destructive activity.
Executive priority
Prioritize this technique where loss of data, configurations, backups, or operator visibility would delay safe operations or incident recovery. Leaders should ask whether ICS recovery depends on a small number of privileged accounts, shared engineering workstations, HMIs, historians, or backup repositories; whether gold-copy images and configurations exist for key systems; and whether restoration procedures have been exercised. This behavior is especially material for operational resilience, audit evidence, and incident decision-making because backup destruction and loss of operator interfaces can directly affect recovery timelines.
Technical view
SOC, detection engineering, and IR teams should validate visibility across the ICS assets ATT&CK relates to this technique, including workstations, HMIs, PLCs, RTUs, IEDs, historians, control servers, application servers, data gateways, safety controllers, VPN servers, jump hosts, routers, switches, firewalls, DCS controllers, PACs, and field I/O. ATT&CK provides no official detection text for T0809, but it does identify a related detection strategy, DET0758 Detection of Data Destruction. Defensive validation should focus on suspicious deletion or wiping activity, use of non-native tools such as SDelete or Active@ Killdisk where observable, deletion of malware/tools during cleanup, and attempts to remove backups or critical configuration data. Relationship context also ties this behavior to Industroyer and the 2025 Poland Wiper Attacks campaign, so IR playbooks should treat destructive activity in ICS as a high-severity recovery and safety coordination event rather than a routine endpoint cleanup case.
Likely telemetry
- File creation, modification, deletion, and mass-delete events on ICS workstations, servers, HMIs, historians, and jump hosts
- Process execution and command-line telemetry for standard file deletion utilities and known wiping tools named by ATT&CK, including SDelete and Active@ Killdisk
- Privileged account authentication, session, and authorization logs, especially for SYSTEM/root or administrative accounts
- Backup platform logs showing deletion, failed restore points, repository access, or changes to backup retention
- Configuration, project, logic, image, and firmware integrity records for controllers and embedded ICS assets where available
Detection direction
- Map DET0758-style detection expectations to actual local telemetry because ATT&CK does not provide detailed detection logic for this object.
- Baseline legitimate engineering, maintenance, backup rotation, and decommissioning activity before alerting on deletion volume alone; false positives are likely during planned patching, upgrades, and system rebuilds.
- Prioritize alerts where deletion activity involves backups, historian data, HMI/control server application files, controller configurations, or gold-copy images rather than ordinary temporary files.
- Correlate destructive file activity with privileged account use, remote access through VPN or jump hosts, and recent creation of non-native tools or malware-like files.
- Validate coverage beyond Windows and Linux servers: many related ICS assets are embedded or network devices where endpoint telemetry may be limited and configuration integrity or backup comparison may be the better evidence source.
Mitigation priorities
- Harden and separate backups as described by ATT&CK mitigation M0953, including gold-copy images and configurations for key ICS systems and exercised incident response recovery plans.
- Apply privileged account management per M0926 so destructive actions require controlled, attributable, and limited administrative access, including SYSTEM/root-equivalent permissions.
- Restrict file and directory permissions per M0922, especially on directories containing HMI projects, historian data, control server applications, engineering workstation files, and backup repositories.
- Review which ICS assets require write access to critical data and configurations; reduce shared administrative access where operationally feasible.
- Exercise restoration procedures for the most important target asset classes identified in ATT&CK relationships, not only enterprise servers.
Analyst notes and limits
This take is based on ATT&CK T0809 Data Destruction, its description, external references, and supplied relationships. The broad target list means the practical priority is asset-specific: an HMI, historian, backup store, controller, jump host, or firewall can each create different operational consequences if data or configuration is destroyed. The most decision-useful validation is whether the organization can detect destructive actions early enough and restore trusted configurations quickly enough.
ATT&CK supplies no official detection text, no platforms directly on the technique object, and no tactics in the provided fields. Telemetry and control recommendations therefore require local validation against the actual ICS architecture, logging capabilities, vendor constraints, safety requirements, and recovery procedures. Related campaign and software context should be treated as ATT&CK relationship context, not as evidence of current activity in any specific environment.
Data Destruction
Adversaries may perform data destruction over the course of an operation. The adversary may drop or create malware, tools, or other non-native files on a target system to accomplish this, potentially leaving behind traces of malicious activities. Such non-native files and other data may be removed over the course of an intrusion to maintain a small footprint or as a standard part of the post-intrusion cleanup process. [1]
Data destruction may also be used to render operator interfaces unable to respond and to disrupt response functions from occurring as expected. An adversary may also destroy data backups that are vital to recovery after an incident.
Standard file deletion commands are available on most operating system and device interfaces to perform cleanup, but adversaries may use other tools as well. Two examples are Windows Sysinternals SDelete and Active@ Killdisk.
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
S0604: Industroyer
Industroyer is a sophisticated malware framework designed to cause an impact to the working processes of Industrial Control Systems (ICS), specifically components used in electrical substations.[1] Industroyer was used in the attacks on the Ukrainian power grid in December 2016.[2] This is the first publicly known malware specifically designed to target and impact operations in the electric grid.[3]
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]
S1045: INCONTROLLER
INCONTROLLER is custom malware that includes multiple modules tailored towards ICS devices and technologies, including Schneider Electric and Omron PLCs as well as OPC UA, Modbus, and CODESYS protocols. INCONTROLLER has the ability to discover specific devices, download logic on the devices, and exploit platform-specific vulnerabilities. As of September 2022, some security researchers assessed INCONTROLLER was developed by CHERNOVITE.[1][2][3][4][5]
S1157: Fuxnet
C0063: 2025 Poland Wiper Attacks
2025 Poland Wiper Attacks is a Russian state-sponsored campaign that conducted destructive cyberattacks against Polish energy infrastructure in December 2025. Targets included more than 30 wind and photovoltaic farms, a combined heat and power (CHP) plant, and a manufacturing sector company. The attacks on the distributed energy resources (DER) disrupted communications between affected facilities and the distribution system operator, but did not impact electricity generation or heat supply. Across the campaign, threat actors deployed two previously undocumented wiper tools, DynoWiper, a Windows-based wiper and LazyWiper, a PowerShell wiper, distributed via malicious Group Policy Objects. At the CHP plant, threat actors had maintained access since at least March 2025, using that foothold to obtain credentials and move laterally before attempting wiper deployment. Some reporting has assessed the activity to be consistent with Russian Federal Security Service (FSB) threat activity group Dragonfly, also tracked as STATIC TUNDRA, while other reporting attributes the destructive wiper activities to the Russian General Staff Main Intelligence Directorate (GRU) threat activity group ELECTRUM, also tracked as Sandworm Team.[1][2][3][4]
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 | ea637effc2dd… |
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]
Enterprise ATT&CK January 2018
Enterprise ATT&CK 2018, January 11 File Deletion Retrieved. 2018/05/17
Open source URL -
[2]
mitre-attack T0809Open 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.