ATT&CK for ICS Persistence Tactic Guide: Finding and Removing Footholds in Controllers and Workstations

Persistence in an industrial environment often lives where endpoint tools cannot look: in controller logic, device firmware, engineering project files and credentials that the asset owner cannot change. ATT&CK for ICS describes the Persistence tactic (TA0110) as the adversary "trying to maintain their foothold in your ICS environment" across restarts, changed credentials and other interruptions, including by replacing or hijacking code, firmware and project files. Rebuilding a Windows HMI does not remove a modified PLC program or a malicious firmware image, and a password reset does not help if the credential is hardcoded. This guide covers the five Persistence techniques and five sub-techniques in ATT&CK v20, how campaigns used them, the mitigations MITRE maps, the v20 detection strategies and how to plan integrity checks and recovery. It is written for control system engineers, OT security engineers and incident responders, and builds on the MITRE ATT&CK for ICS Guide without repeating the matrix overview.

Key takeaways

• Valid Accounts is the most observed persistence route. T0859 has 8 recorded procedure examples in v20, including both Ukraine power grid attacks and the Triton safety system attack.
• Controllers and firmware are persistence locations. Modify Program (T0889) and System Firmware (T1693.001) have 4 examples each, and both survive a rebuild of every Windows host on site.
• Insecure credentials are a v20 technique in their own right. Default Credentials (T1694.001) has 4 examples, covering the Unitronics defacements, the 2026 U.S. water utility attacks and the 2025 Poland wiper attacks.
• Integrity controls carry most of the mapped mitigations. Access Management (M0801) and Audit (M0947) each map to 7 of the 10 techniques and sub-techniques, and Code Signing (M0945) to 6.
• Recovery depends on known-good copies. Without verified offline backups of logic, configuration and firmware, an operator cannot prove that persistence has been removed.

Where Persistence sits in an ICS intrusion

Persistence follows Initial Access and often overlaps with Lateral Movement: two of the five techniques (Valid Accounts and Insecure Credentials) are listed under both tactics, and Modify Firmware also sits under Inhibit Response Function and Impair Process Control. That overlap is the point. The same change that keeps an adversary in place on a controller can also be the change that disables protection or alters the process.

To see how the tactic is used, we counted the "uses" relationships in the official ATT&CK v20 ICS dataset (ics-attack-20.0.json; groups, software and campaigns, excluding revoked and deprecated objects). 15 entities have a Persistence procedure: 7 campaigns, 5 software families and 3 groups (ALLANITE, CyberAv3ngers and OilRig), with 23 procedure examples in total. The records show three layers of persistence.

The AA23-335A advisory on the Unitronics campaign shows a fourth effect that defenders should plan for: locking the owner out. CISA describes the actors erasing ladder logic, renaming devices, changing the communication port from 20256 to 20257, disabling upload and download functions and adding password protection to upload settings, so operators could not easily connect to recover.

The techniques in ATT&CK v20

ATT&CK v20 lists five Persistence techniques for ICS with five sub-techniques between them. Procedure counts are recorded at the level ATT&CK attaches them to, which for three techniques is the sub-technique.

How the techniques differ

• T0859 versus T1694: Valid Accounts covers credentials that belong to real users or services and were stolen or reused; Insecure Credentials covers credentials the product ships with (defaults) or cannot change (hardcoded), such as the WinCC database password Stuxnet used and the Omron PLC credential INCONTROLLER used, documented as CVE-2022-34151.
• T0873 versus T0889: Project File Infection lives on the engineering workstation and spreads when an engineer opens or downloads the project; Modify Program lives on the controller itself.
• T1693.001 versus T1693.002: System Firmware is the main device image; Module Firmware targets components such as Ethernet cards, which MITRE notes may have their own CPU, memory and operating system and less integrity checking.

Which techniques matter most for defenders

1. T0859 Valid Accounts: the most observed and the cheapest to defend, through account hygiene, MFA on remote paths and removal of shared engineering accounts.
2. T1694.001 Default Credentials: concentrated in recent internet-exposure campaigns against water utilities and in the 2025 Poland attacks on RTUs, relays and serial device servers.
3. T0889 Modify Program: the persistence that also changes the process. Program integrity monitoring is the only reliable way to notice it before operators do.
4. T1693.001 System Firmware: fewer environments can detect it, and its consequences (reboot loops, bricked gateways, a compromised safety controller) are severe.
5. T0873 Project File Infection: low count, but it reinfects controllers every time a project is downloaded, so it undermines recovery.

Mitigations MITRE maps to the tactic

ATT&CK v20 maps 22 distinct ICS mitigations to the 10 Persistence techniques and sub-techniques. The table lists those mapped to three or more.

Two further points from the mapping are worth acting on. Password Policies (M0927) is mapped to T1694.001 Default Credentials, and Restrict File and Directory Permissions (M0922) to project file infection, which means locking down the folders where engineering projects live. For the cross-tactic view, see ATT&CK Mitigations.

Controller and firmware controls in practice

• Key switches and run mode: where controllers have a physical key or software mode that blocks remote programming, keep it in run mode outside approved changes. See the PLC Security Guide.
• Remote programming disabled where not needed: the AA23-335A advisory recommends disabling remote programming, changing default ports and passwords, and keeping devices off the internet.
• Firmware from verified sources only: check vendor hashes and signatures, and stage updates through a controlled engineering host. See the Firmware and Boot Security Guide.
• Engineering workstation hardening: the AA22-103A advisory recommends credential and driver protections, least privilege and installing only necessary applications on engineering hosts. See the Engineering Workstation Security Guide.

Detection and measurement

The v20 detection strategies for this tactic combine host events with OT-specific evidence: program hashes from asset inventory, firmware hashes, device alarms and protocol content showing writes to controllers.

Metrics that show it is working

• Program integrity coverage: share of controllers whose running logic is compared against an approved baseline at least monthly.
• Firmware baseline coverage: share of controllers, RTUs, IEDs and gateways with a recorded approved firmware version and hash.
• Default credential count: devices still using vendor default credentials, trending to zero.
• Backup recency: share of controllers with a verified offline backup of logic and configuration taken after the last approved change.
• Unexplained changes: program or firmware changes detected that do not match a change record, and the time to explain each one.

Where identity fits

Half of this tactic is about credentials. Valid accounts, default passwords and hardcoded credentials all let an adversary return after hosts are cleaned, and many OT accounts are shared or embedded in devices, so they are rarely reset. Treat engineering, vendor and service accounts as identities with named owners; remove shared logins on jump hosts; reset every credential that touched a compromised segment after an incident, including device passwords; and record hardcoded credentials in the risk register with compensating network controls, because the owner cannot rotate them. See the OT and ICS Identity and Access Guide.

Implementation roadmap

1. Capture known-good state: take offline backups of controller logic, configuration and project files, and record firmware versions and hashes for every controller, RTU, IED and gateway. See the OT Backup, Recovery and Golden Image Guide.
2. Remove default credentials: change defaults on every device that allows it and record the ones that cannot be changed.
3. Restrict who can change things: limit programming and firmware update protocols to named engineering workstations, use run mode or key switches, and require authentication for program changes where supported.
4. Compare regularly: schedule program and firmware comparisons against the baseline, starting with safety and high-consequence controllers; review differences with control engineers before treating them as incidents.
5. Alert on change events: enable the v20 analytics for program writes, firmware update mode and project file writes, tied to the change management calendar.
6. Rehearse recovery: restore a controller from backup on a test bench, confirm the logic matches, and record how long it takes; keep spare hardware for devices whose firmware cannot be trusted after an incident.

Decision guidance

• Agent-based or network-based integrity checks: vendor or OT monitoring tools that read program and firmware state over the network avoid installing anything on controllers; schedule polling during stable operation and confirm with the vendor that it is supported.
• Reload or replace after compromise: reloading verified logic is usually enough for Modify Program; firmware compromise, especially on safety controllers, may justify replacement and vendor analysis.
• Small sites: manual monthly comparison of exported logic against backups, plus default credential removal, covers most observed cases.
• Large operators: centralise baselines and change records so that any detected change can be matched to a work order automatically.

Framework mapping

Common failure patterns

• Rebuilding hosts but not controllers: responders reimage HMIs and servers and declare the site clean while modified logic remains on the PLC.
• Restoring infected projects: project files backed up after infection are restored and downloaded, reintroducing the adversary's code.
• No firmware baseline: without recorded versions and hashes, nobody can tell whether a gateway or RTU runs the vendor's image.
• Credential resets that skip devices: domain passwords are reset after an incident but PLC, HMI and switch passwords are not.
• Remote programming left enabled: controllers stay in a mode that accepts program downloads from any host on the network.
• Backups that were never restored: a backup that has not been tested on a bench may be incomplete or tied to software versions no longer installed.

Practitioner checklist

• Take and verify offline backups of logic, configuration and project files after every approved change.
• Record firmware versions and hashes for all controllers, RTUs, IEDs and gateways.
• Change every changeable default credential and record those that cannot be changed.
• Restrict programming and firmware protocols to named engineering workstations.
• Keep controllers in run mode outside approved maintenance.
• Compare running logic against baselines at least monthly, starting with safety systems.
• Alert on project file writes by non-engineering processes.
• Include device and service credentials in post-incident resets.
• Rehearse a controller restore on a test bench each year.

Standards and references

• MITRE ATT&CK for ICS: Persistence (TA0110)
• MITRE ATT&CK for ICS: Valid Accounts (T0859)
• MITRE ATT&CK for ICS: Modify Program (T0889)
• MITRE ATT&CK for ICS: Modify Firmware (T1693)
• CISA: Cybersecurity Advisory AA23-335A on IRGC-affiliated actors exploiting PLCs
• CISA: AA22-103A APT Cyber Tools Targeting ICS/SCADA Devices
• NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · PLC Security Guide · OT Backup, Recovery and Golden Image Guide · ATT&CK for ICS Initial Access Tactic Guide · ATT&CK for ICS Command and Control Tactic Guide