T0835 Manipulate I/O Image: Detecting Tampering with PLC Input and Output Values

Manipulate I/O Image (T0835) is an adversary changing the values a PLC holds for its inputs and outputs, so the controller acts on false inputs or drives outputs its logic never asked for. Because the I/O image sits inside the controller between the field and the program, tampering there can defeat the logic and hide the result from the HMI at the same time. MITRE ATT&CK for ICS lists T0835 under the Inhibit Response Function tactic, on the Embedded platform, and states that it may not be effectively mitigated. This guide is for control engineers, OT security engineers and OT SOC analysts: how the I/O image works, what Stuxnet and PLC-Blaster did, how ATT&CK's v20 analytic detects manipulation with an independent measurement, and the controls that reduce the chance an adversary gets that far. For the tactic as a whole see the ATT&CK for ICS Inhibit Response Function Tactic Guide.

Key takeaways

• The I/O image is the PLC's working copy of the field. Inputs are read into an image table each scan; the program writes an output image that is then sent to the output modules.
• Two methods, both built into PLCs. ATT&CK names direct memory manipulation and the override (force) function used for testing programs.
• Prevention at the technique level is weak. ATT&CK's only mitigation entry is M0816, Mitigation Limited or Not Effective: protect the access that leads to it instead.
• Detection needs a second truth. The v20 analytic compares the controller's reported I/O values with an independent physical measurement, not with network data alone.
• Treat force use as a controlled change. Forces are a normal commissioning tool, which is why unexplained forces in production deserve attention.

How the I/O image works and where it can be manipulated

ATT&CK describes the cycle: during the scan, a PLC reads the status of all inputs and stores them in an image table, its internal storage for input and output values during one scan while the user program runs. After solving the logic, the PLC updates the output image table, and its contents are written to the output points on the I/O modules. ATT&CK also notes a characteristic of PLCs: they can override the status of a physical discrete input, or override the logic driving an output coil and force the output to a chosen state.

Collecting the I/O image without changing it is a separate technique, I/O Image (T0877), under Collection; adversaries often read it first to learn normal values.

What ATT&CK records about real use

• Stuxnet (S0603): when the peripheral output was written to, its sequence C intercepted the output and ensured it was not written to the process image output. By intercepting the peripheral output, ATT&CK records, Stuxnet prevented operators from noticing unauthorised commands sent to the peripheral.
• PLC-Blaster (S1006): could manipulate any output of the PLC; using the POU POKE, any value within the process image could be modified.

Both cases depended on malicious code already running on the controller. That is the practical lesson: once logic on the PLC is hostile, the PLC's own view of its I/O cannot be trusted, so detection has to come from outside it.

Detection: the ATT&CK v20 analytic

ATT&CK's detection strategy for T0835 (DET0773) has one Embedded analytic. It looks for an ICS protocol write to output register addresses on a field device from a source not on the approved write-source list, correlated with a discrepancy between the value reported by the I/O image and an independent measurement of the actual physical output state. ATT&CK is explicit that the independent measurement is process-state telemetry, not network flow evidence, and needs a separately trusted sensor, historian or measurement path with time alignment and an engineering-defined tolerance.

The fidelity gate suppresses activity that matches approved maintenance, commissioning, failover, recovery or tested control procedures, and alerts only when the write is not attributable to an authorised operator or engineering source and falls outside a change window or lacks change-control context.

Practical sources of an independent measurement

• Redundant sensors wired to a different controller or to the safety system, compared in the historian.
• Feedback signals such as a valve position or motor running contact, compared with the commanded output.
• Physical consequences visible elsewhere: flow, pressure or power that should follow from the output state.

Start with the few outputs whose false state would matter most to safety or quality; a comparison for every point is rarely worth it.

Watching force and override use

Because ATT&CK names the override function as a method, find out whether your controllers report active forces or overrides in their diagnostics or status, and whether that status can be read by the HMI, historian or monitoring platform. If it can, alert on forces present outside a commissioning or maintenance window. Monitor engineering software sessions that change forces in the same way as program changes.

Prevention: protect the path to the PLC

ATT&CK advises considering controls for the assets and processes that lead to this technique. In practice that means the steps an adversary needs first:

• Restrict program and online edit access: only named engineering workstations should reach controller programming services. See the PLC Security Guide.
• Use controller protections: run mode or key switch settings, project passwords and write protection where the product supports them.
• Verify program integrity: compare running logic with an approved offline copy, since T0835 usually follows malicious logic being loaded.
• Restrict protocol writes: filter writes to output register ranges at the conduit so only approved sources can send them. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
• Keep safety independent: a safety instrumented system with its own sensors is both a protection and a source of independent measurement. See the Safety Instrumented Systems Security Guide.

How to implement

1. Pick the critical outputs: with process engineers, choose the outputs and inputs whose false value would matter most.
2. Find an independent signal for each and agree a tolerance and time alignment.
3. Build the comparison in the historian or monitoring platform in report-only mode and tune through normal operations and at least one maintenance period.
4. Add write-source monitoring: decode protocol writes to output ranges and compare sources with the approved list.
5. Add force status monitoring where the controller exposes it.
6. Agree the response: who checks the field, who can stop the process, and when an alert becomes an incident.

Decision guidance

• Safety-relevant outputs: independent measurement is worth the engineering effort; use the safety system or hardwired feedback.
• Quality or efficiency outputs: historian comparison against downstream measurements is usually enough.
• Legacy PLCs without protections: rely on network restriction, program comparison and independent measurement.
• Small sites: start with feedback signals that are already wired, and a manual force check during rounds.

Responding

A mismatch between the PLC's reported value and an independent measurement is a process safety question first. Operations confirm the real state locally and decide whether to move to manual or a safe state. Preserve the controller program, force table and diagnostics, the historian data for both signals, and protocol captures. Compare the program with the approved copy and remove forces only under engineering supervision, since removing a force can itself move equipment. See the OT Incident Response Guide.

Detection and measurement

• Independent coverage: percentage of critical outputs with an independent measurement compared automatically.
• Write-source compliance: number of output register writes from sources not on the approved list.
• Force hygiene: number of forces active in production outside a change window.
• Program integrity: percentage of controllers whose running program matched the approved copy at the last check.

Framework mapping

Common failure patterns

• Trusting the HMI alone: it shows the PLC's view, which is the thing being manipulated.
• Forces left in after commissioning: normalises force use so a malicious one blends in.
• Any host can write output registers: no filtering at the conduit.
• Comparisons without tolerances: noisy alerts lead to the comparison being switched off.
• No approved program copy: manipulated logic cannot be identified quickly.

Practitioner checklist

• Identify the critical inputs and outputs with process engineers.
• Pair each with an independent measurement and tolerance.
• Monitor protocol writes to output register ranges against an approved source list.
• Monitor force and override status where controllers expose it.
• Remove forces before handover and control any force in production as a change.
• Restrict programming access and enable controller protections.
• Keep and compare approved program copies.
• Write the response steps with operations before the first alert.

Standards and references

• MITRE ATT&CK for ICS: Manipulate I/O Image (T0835)
• MITRE ATT&CK for ICS: I/O Image (T0877)
• MITRE ATT&CK: Stuxnet (S0603)
• MITRE ATT&CK: PLC-Blaster (S1006)
• 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 · ATT&CK for ICS Inhibit Response Function Tactic Guide · PLC Security Guide · Safety Instrumented Systems Security Guide · MITRE ATT&CK for ICS T0877 I/O Image