ATT&CK for ICS Impair Process Control Tactic Guide: Stop Unauthorised Commands and Setpoint Changes

Impair Process Control is the ATT&CK for ICS tactic in which an adversary changes what an industrial process physically does, by sending unauthorised commands, altering setpoints, spoofing reports or replacing firmware. MITRE describes the tactic (TA0106) as the adversary "trying to manipulate, disable, or damage physical control processes". It is where an OT intrusion stops being an IT problem: breakers open, pumps change speed and operators see values that are no longer true. This guide covers each technique in the tactic as published in ATT&CK v20, the incidents ATT&CK links to them, the controls that make unauthorised writes hard, and how to detect them in protocol traffic. It is for OT security engineers, control engineers, SOC analysts covering industrial networks and asset owners planning OT defences. For the matrix overview see the MITRE ATT&CK for ICS Guide.

Key takeaways

• A short tactic with a long reach. ATT&CK v20 lists four techniques: Brute Force I/O (T0806), Modify Firmware (T1693), Modify Parameter (T0836) and Unauthorized Message (T1692, with Command Message and Reporting Message sub-techniques).
• Industrial protocols trust the sender. Modbus, IEC 60870-5-104, IEC 61850 MMS and many vendor protocols act on any well-formed command, which is why Industroyer could open breakers with legitimate protocol messages.
• Writes are the thing to control. Restrict which hosts may write to which controllers, and validate written values against safe ranges (M0818 Validate Program Inputs).
• Reporting can be spoofed too. Spoofed Reporting Messages (T1692.002) hide the real state, so independent measurement and cross-checks matter.
• Detection is practical. Writes from unexpected sources, values outside documented ranges and rapid toggling of the same points are all visible to passive OT monitoring.

What the tactic covers

MITRE says Impair Process Control techniques "disrupt control logic and cause determinantal effects to processes", may target "active procedures or parameters that manipulate the physical environment", and can include "prevention or manipulation of reporting elements". The tactic sits between Execution and Impact. Adversaries often pair it with Inhibit Response Function (TA0107), which stops alarms and safety systems from catching the change. See the ATT&CK for ICS Inhibit Response Function Tactic Guide.

Modify Firmware (T1693) also appears under Persistence and Inhibit Response Function, and Unauthorized Message (T1692) also appears under Evasion. If your detection mappings still use pre-v20 IDs for unauthorised command and spoofed reporting messages, update them to T1692.001 and T1692.002.

How the reference incidents worked, in defensive terms

• Industroyer (S0604), Ukraine, December 2016: attributed by ATT&CK to Sandworm Team. It carried payloads for IEC 60870-5-101, IEC 60870-5-104, IEC 61850 and OPC DA, and used them to send commands that changed the state of substation equipment, including toggling breakers open. Its IEC 104 module could step through Information Object Addresses and switch them repeatedly (Brute Force I/O). The defensive lesson is that the commands were valid protocol messages, so only source control and behavioural monitoring would have stopped them.
• Industroyer2 (S1072), 2022: sets specified Information Object Addresses to ON or OFF for configured ASDU addresses, a narrower and pre-configured version of the same approach.
• Stuxnet (S0603): sent frames over Profibus that changed frequency converter drive parameters such as maximum motor speed, while reporting normal values.
• FrostyGoop (S1165): reads and writes device registers over Modbus; in the FrostyGoop Incident (C0041) ATT&CK records that changed parameters caused controllers to report incorrect measurements.
• INCONTROLLER (S1045): used HTTP CGI scripts on Omron PLCs to change parameters on EtherCAT-connected servo drives. See the PIPEDREAM (INCONTROLLER) ICS Toolkit Guide.
• Maroochy Water Breach (C0020): an insider case in which altered control data caused pumping stations to fail or run incorrectly, leading to a sewage spill that ATT&CK puts at about 800,000 litres.
• 2026 U.S. Water Utilities Attacks (C0066): ATT&CK records changes to the IP addresses of internet-facing MicroLogix controllers, a reminder that exposed controllers remain the easiest path. See the Pro-Russia Hacktivists Targeting OT Guide.

Mitigations MITRE maps to the tactic

See the Modbus TCP and Modbus Security Guide, the DNP3 and DNP3 Secure Authentication Guide and the OPC UA Security Guide for protocol-specific settings.

Engineering controls that limit unauthorised writes

1. Engineer limits into the logic: put hard high and low limits on setpoints and speed references inside the controller program, so an out-of-range write is clamped or rejected regardless of source. This is the most direct form of M0818.
2. Use write protection features: many PLCs offer hardware keyswitches, write-protect bits or memory protection. Enable them on production controllers and record any change.
3. Separate read and write paths: historians, MES and reporting systems need reads only. Give them read-only access through a data diode, a read-only gateway or protocol filtering.
4. Interlock dangerous combinations: logic that refuses incompatible commands (for example opening a breaker under conditions engineering has marked unsafe) limits what a valid but malicious command can do.
5. Independent measurement: where spoofed reporting would hide a hazard, compare the reported value with a second instrument or physical indication, and alarm on disagreement.
6. Firmware governance: keep an inventory of firmware versions, obtain updates only from the vendor, verify hashes or signatures before loading, and prefer devices that enforce signed firmware. See the Firmware and Boot Security Guide.

Protocol reference for write control

Protocol-aware filtering and monitoring need to know which operations change the process. The table summarises the common protocols named in the incidents above. Ports are the registered defaults; sites often change them, so confirm against your own asset inventory.

A useful first rule set for any zone is: permit read operations from the historian and reporting hosts, permit write operations only from the named SCADA servers and HMIs, and permit programming and firmware operations only from engineering workstations during approved windows. Alert on everything else before you block it.

Lessons from incidents

• Valid commands are the weapon: none of the reference incidents needed a protocol exploit to change the process. Industroyer, Industroyer2 and FrostyGoop used ordinary protocol operations, so the defensive question is always "should this source be writing to this device at all?".
• The operator view can lie: Stuxnet and the FrostyGoop Incident show that what the HMI reports may not match the physical process. Independent measurement and physical checks belong in the response plan.
• Insiders and former contractors count: the Maroochy Water Breach involved someone with knowledge of the system. Remove access promptly when contracts end and review who knows shared credentials.
• Exposure is still the easy path: the internet-facing controllers in the 2026 U.S. Water Utilities Attacks required no advanced tooling.

Where identity fits

A legitimate command is legitimate because of who or what sent it. Most industrial protocols carry no user identity at all, so identity has to be enforced around them.

• Engineering workstation identity: treat engineering workstations as the privileged identities of OT. Named logins, MFA at the jump host and recorded sessions for every parameter change.
• Application certificates: where OPC UA or other authenticated protocols are available, issue each HMI and SCADA server its own certificate and trust only those, which turns M0813 into an inventory of machine identities.
• Service accounts: SCADA servers and integration services that write to controllers hold some of the most powerful credentials on site. Restrict where they can log on and rotate their secrets. See the Identity for OT Environments Guide.

Detection and measurement

These signals match the detection strategies ATT&CK v20 publishes for the techniques. They depend on knowing the normal write pattern, so build a list of which sources write to which controllers before turning on alerts. See the OT Network Security Monitoring Guide.

Metrics:

• Percentage of controllers where write access is restricted to an allowlist of sources.
• Number of controller writes per month from sources outside the allowlist (target zero after tuning).
• Percentage of critical setpoints with engineered limits in logic.
• Percentage of critical devices with known, baselined firmware.
• Mean time to detect a test parameter change in an exercise.

Implementation roadmap

1. Inventory writers: from passive monitoring, list every host that writes to each controller and which function codes it uses. See the OT Asset Visibility Guide.
2. Remove internet exposure: no controller or HMI should be reachable from the internet. This addresses the easiest path recorded in the 2026 U.S. Water Utilities Attacks.
3. Alert before blocking: turn on alerts for unexpected writers and out-of-range values, and tune them with operations for several weeks.
4. Enforce allowlists: apply protocol filtering at zone boundaries, starting with one cell. Keep the previous rule set ready to restore if production is disturbed.
5. Harden logic: add limits and interlocks during planned outages, test on a simulator or offline controller first, and document the change through management of change.
6. Adopt authenticated protocols in new projects: specify OPC UA security modes, DNP3 Secure Authentication or vendor secure protocols in procurement. See the OT Product Procurement Guide.

Decision guidance: where devices cannot authenticate commands, rely on segmentation, filtering and logic limits. Where they can, enable authentication on new assets first rather than retrofitting live plant. Small sites get most value from removing exposure and adding logic limits; large operators should centralise register maps and detection rules so every site measures the same thing.

Framework mapping

For the OT tailoring of these controls see the NIST SP 800-82 OT Security Guide, and for zone, conduit and security level requirements the IEC 62443 Guide.

Common failure patterns

• Flat control networks: any compromised host can write to any controller, which is the condition Industroyer and similar tools rely on.
• Historians with write access: read-only systems given full protocol access become a path to controllers.
• Limits only in the HMI: range checks in the HMI do nothing when commands come from another source. Put limits in the controller.
• Trusting a single reading: without a second measurement, spoofed reporting goes unnoticed until physical effects appear.
• Exposed controllers: internet-reachable PLCs and HMIs with default credentials remain the most common entry point in recent water sector incidents.

Practitioner checklist

• Each controller has a documented list of hosts allowed to write to it, enforced at the network.
• No controller or HMI is reachable from the internet.
• Critical setpoints have engineered high and low limits in controller logic.
• Reporting-only systems have read-only access.
• Passive monitoring alerts on unexpected writers, out-of-range values and rapid toggling.
• Firmware versions are baselined and only vendor-verified images are loaded.
• Engineering workstation sessions are named, MFA-protected and recorded.
• Detection mappings use ATT&CK v20 IDs T1692.001, T1692.002 and T1693.

Standards and references

• MITRE ATT&CK for ICS: Impair Process Control (TA0106)
• MITRE ATT&CK for ICS: Modify Parameter (T0836)
• MITRE ATT&CK: Industroyer (S0604)
• MITRE ATT&CK for ICS: Inhibit Response Function (TA0107)
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · PLC Security Guide · OT and ICS Identity and Access Guide · OT Security Guide