ATT&CK for ICS T1693: Modify Firmware in OT

Modify Firmware (T1693) is the technique where an adversary installs malicious or vulnerable firmware on an industrial device, gaining control below the level that most monitoring and recovery tools can see. MITRE ATT&CK for ICS v20 created T1693 in April 2026 for the Embedded platform under three tactics: Persistence (TA0110), Inhibit Response Function (TA0107) and Impair Process Control (TA0106). Its sub-techniques, System Firmware (T1693.001) and Module Firmware (T1693.002), replace the revoked T0857 and T0839. This guide is for OT security engineers, control engineers and maintenance teams who update PLCs, RTUs, relays, communication modules and gateways. It covers how firmware is modified, the cases ATT&CK records, the v20 detection chain, the twelve ATT&CK mitigations and safe recovery. For firmware and boot security outside OT see the Firmware and Boot Security Guide; this page covers the industrial case.

Key takeaways

The update feature is the attack path. ATT&CK describes adversaries using built-in firmware update functions, locally or over the network, to load malicious or out-of-date firmware.
Downgrades count. Installing an older, vulnerable version is part of the technique; ATT&CK records a firmware downgrade in the FrostyGoop incident.
Modules are softer targets. Communication cards and other modules carry their own firmware, often with less integrity checking than the main CPU.
The outcome can be a brick. In Ukraine in 2015 and Poland in 2025, corrupted firmware left gateways and RTUs disabled or unable to communicate.
Integrity needs a baseline. Detection hinges on recorded authorised firmware hashes per device and module, checked after every update or reboot.

What T1693 covers

ATT&CK defines firmware as low-level software embedded in hardware that enables systems and devices to function, and notes that it is common in ICS. Malicious or vulnerable firmware can be delivered through Replication Through Removable Media (T0847), Supply Chain Compromise (T0862) or Remote Services (T0886), and once installed can provide Rootkit (T0851) and Hooking (T0874) functionality, Exploitation for Privilege Escalation (T0890) or Denial of Service (T0814). Putting a device into a state that accepts firmware is itself a separate technique, Activate Firmware Update Mode (T0800).

Sub-technique	Target	What ATT&CK highlights	Replaces
T1693.001 System Firmware	The main firmware of a controller, RTU, relay, gateway or other device	Update features let vendors patch remotely and are often delegated to users through update packages, sometimes over the network; malicious firmware may give root access to the device	T0857 System Firmware
T1693.002 Module Firmware	Firmware on modular hardware such as Ethernet communication cards	Modules may lack the integrity checking of the main device; an Ethernet card may have its own CPU, RAM and operating system, and its compromise can support delayed attacks, bricking, attacks spread across many field devices of one model, and a route to other modules such as the CPU	T0839 Module Firmware

The Enterprise matrix covers server and workstation firmware (for example UEFI) under separate techniques; this page stays with industrial devices. For the tactic overview see the ATT&CK for ICS Inhibit Response Function Tactic Guide.

Real cases recorded by ATT&CK

2015 Ukraine Electric Power Attack (C0028): Sandworm Team (G0034) overwrote serial-to-Ethernet gateways with custom firmware, leaving them disabled, shut down or unrecoverable. See the Sandworm Threat Actor Profile and the Industrial Switch and Serial Gateway Hardening Guide.
2025 Poland Wiper Attacks (C0063): ATT&CK records the adversaries corrupting firmware in RTUs, causing a fault that triggered a reboot loop. CERT Polska's report on the attacks of 29 December 2025 says RTUs at wind and photovoltaic grid connection points had controller firmware damaged, and the stations lost communication with the distribution system operator and could not be controlled remotely, while generation continued.
FrostyGoop Incident (C0041): ATT&CK records that the adversary initiated a firmware downgrade on affected devices, citing Dragos. See the FrostyGoop Modbus Malware Guide.
Triton (S1009): ATT&CK records that Triton could read, write and execute code in memory at an arbitrary address within the safety controller's firmware region, changing the running firmware in memory and how the device operates. See the Safety Instrumented Systems Security Guide.

The first two cases are destructive: the aim was to make recovery slow by forcing physical replacement or reflashing of many devices. Spares and offline firmware images decide how long such an outage lasts.

Detection: the ATT&CK v20 firmware chain

MITRE's detection strategy DET0904 has one Embedded analytic, AN2047, that follows the full modification chain. It applies the OT operational fidelity gate: alert only when the activity cannot be attributed to an authorised engineering source and falls outside approved change context, and suppress approved maintenance and commissioning.

Step in the chain	Signal	Data source named by ATT&CK
1. Update mode	Device enters firmware update mode	Device and controller events
2. Transfer	Large data transfer on a firmware-capable protocol port from a source not on the approved engineering workstation list, outside a change window	Network security monitoring content
3. Reboot	Device reboots within the update window of the flagged transfer	Operational database alarm events
4. Verification	Post-reboot firmware hash of the main processor or a module is not in the authorised firmware inventory	Asset inventory firmware hash records

Each step is useful on its own. Any firmware transfer from a non-engineering host deserves review, and any firmware version or hash that does not match the inventory needs an explanation, even if the transfer was missed. Version strings reported by a device come from the device itself, so a compromised device can lie; where the vendor supports it, compare hashes read through vendor tools or by reading the image offline. Downgrades show up as a version going backwards, which a simple inventory comparison catches. See the OT Network Security Monitoring Guide.

Prevention: the ATT&CK mitigations in practice

ATT&CK lists twelve mitigations for T1693. Grouped by purpose:

Purpose	Mitigations	What ATT&CK says to do
Verify the image	M0945 Code Signing; M0947 Audit; M0946 Boot Integrity	Devices should verify the vendor's signature before installing; check firmware with cryptographic hashes against a trusted value before uploading; check boot integrity and move the root of trust to hardware where possible
Control who can update	M0801 Access Management; M0804 Human User Authentication; M0813 Software Process and Device Authentication	Require authentication for all device changes and administrative functions, for both people and software, including remote firmware management
Control where updates come from	M0807 Network Allowlists; M0930 Network Segmentation; M0937 Filter Network Traffic	Accept management connections only from known engineering workstations, segment critical functions, filter firmware activation and update protocols and payloads
Protect the channel and the image	M0802 Communication Authenticity; M0808 Encrypt Network Traffic; M0941 Encrypt Sensitive Information	Authenticate device management messages; consider encrypting firmware so adversaries cannot easily study it for vulnerabilities

CISA's joint advisory AA22-103A recommends the same practice for asset owners: keep known-good offline backups and hash and integrity-check firmware and controller configuration. Many controllers also have a physical key or run mode that blocks firmware updates; using it outside maintenance closes the remote path. For device-side design, including signed updates and anti-rollback, see the IoT Secure Firmware Update Guide (SUIT, signed OTA) and the Hardware Root of Trust Guide; ask OT suppliers for the same.

Where identity fits

Firmware updates are privileged operations, and in OT they are often done with shared maintenance logins, vendor default credentials or a vendor's remote session. CISA's AA23-335A advisory on CyberAv3ngers describes PLCs reachable from the internet with default or no passwords, and the actors changing device settings, including moving the device port from the default TCP 20256 to 20257, which hindered owners reconnecting. Give each engineer a named account where devices support it, remove default credentials, restrict firmware tools to hardened engineering workstations, and time-limit vendor access. Code signing keys held by suppliers are non-human identities too: ask how they are protected and revoked. See the OT and ICS Identity and Access Guide and the Engineering Workstation Security Guide.

How to implement

Inventory firmware per device and module: model, firmware version, and hash where it can be read, including communication cards, I/O modules, relays, gateways and switches.
Record the authorised baseline and the vendor's published hash or signature for each version in use; store approved images offline.
Turn on what devices already offer: signed firmware enforcement, anti-rollback, run mode or key switch protection, and authentication on management interfaces, each tested on a spare first.
Route all firmware through a staging step where signature and hash are checked from a separate channel. See the MITRE ATT&CK for ICS T0862 Supply Chain Compromise guide.
Restrict update paths: firmware protocols and ports reachable only from approved engineering workstations, filtered at the conduit.
Deploy DET0904-style alerts in alert-only mode, tuned against the maintenance calendar, then add post-update hash re-checks as a standard maintenance step.
Prepare recovery: spares for critical device types, offline images and a tested reflash procedure. See the OT Backup, Recovery and Golden Image Guide.

Decision guidance

Devices with signed firmware support: enforce it, after confirming the vendor's rollback and recovery process, because a bad update cannot then be undone by loading an unsigned image.
Devices without it: rely on hash checks before upload, restricted update paths, run mode protection and post-update verification, and plan replacement in the lifecycle budget.
Applying vendor updates: balance the risk of known vulnerabilities against outage risk using advisory triage. See the ICS Advisory Triage and OT Vulnerability Management Guide.
Small sites: a spreadsheet of device firmware versions and hashes, an offline image store and a key switch policy cover the essentials.
Large estates: an OT asset inventory platform that reads firmware versions continuously makes downgrades and unexpected changes visible at scale.

Responding to suspected firmware modification

Process safety comes first: agree with operations whether the device's function can be carried by redundancy, manual control or a safe shutdown. Do not reflash immediately. Preserve the evidence: the firmware image if it can be read out, version and hash, device logs, the engineering workstation and network records of the transfer. Assume a modified device cannot be trusted to report its own state. Isolate the device's management access, identify the source of the update and check every device of the same model and module type, because module attacks can spread across a fleet. Recover by reflashing from the vendor's verified image or replacing hardware where reflashing is not trusted or not possible, then re-verify hashes and controller programs. Report to your national authority and inform the vendor through a known channel. See the OT Incident Response Guide.

Detection and measurement

Firmware baseline coverage: percentage of controllers, modules and network devices with a recorded authorised version and hash.
Post-update verification: percentage of firmware changes followed by a hash re-check within one week.
Unattributed firmware events: number of firmware transfers or version changes without a change ticket, per quarter.
Signed enforcement coverage: percentage of capable devices with signature verification turned on.
Recovery readiness: percentage of critical device types with a spare and an offline verified image.

Framework mapping

Framework	Reference	How it applies
MITRE ATT&CK for ICS v20	T1693, T1693.001, T1693.002; M0801, M0802, M0804, M0807, M0808, M0813, M0930, M0937, M0941, M0945, M0946, M0947; DET0904	Technique, mitigations and analytics
NIST SP 800-53 Rev. 5	SI-7 Software, Firmware, and Information Integrity, SI-7(15) Code Authentication, CM-14 Signed Components, CM-3 Configuration Change Control, IA-3 Device Identification and Authentication	Firmware integrity, signed components, controlled change
NIST CSF 2.0	PR.PS-01, PR.PS-02, DE.CM-09	Configuration management, software maintenance, monitoring of hardware and software
NIST SP 800-82 Rev. 3	OT security architecture and countermeasures	See the NIST SP 800-82 OT Security Guide

Common failure patterns

Only the CPU is inventoried: communication modules and gateways carry firmware nobody records.
Trusting the version the device reports: a compromised device can report what it likes.
Key switches left in program or remote mode: convenient for engineers and for adversaries.
No offline images or spares: after a destructive firmware attack, recovery waits on vendor shipping.
Downgrades not flagged: inventory checks that look for "changed" but not "older" miss the FrostyGoop pattern.

Practitioner checklist

Record firmware version and hash for every controller, module, gateway and network device.
Keep approved firmware images and vendor hashes offline.
Enforce signed firmware and anti-rollback where devices support them.
Restrict firmware update protocols to approved engineering workstations.
Use run mode or key switch protection outside maintenance.
Alert on firmware transfers from unapproved hosts and on unexplained version changes or downgrades.
Re-check hashes after every update and reboot.
Hold spares and a tested reflash procedure for critical device types.

T1693 Modify Firmware: Detecting and Preventing Firmware Tampering on Controllers and Modules