I/O Image (T0877) is an adversary reading the input and output tables a PLC builds on every scan, to learn exactly what the process is doing or to record values for later replay. It is a Collection (TA0100) technique in ATT&CK for ICS, limited to embedded devices: PLCs, PACs, DCS controllers and safety controllers. ATT&CK says the technique may not be effectively mitigated, which shifts the work to detection and to the controls around the access that makes it possible. This guide explains what the I/O image is, the one documented case, the ATT&CK v20 detection analytic and how to build it, and what to do when it fires. It is for OT security engineers, control engineers and OT SOC analysts.
Key takeaways
- The I/O image is the controller's view of the plant. The user program reads inputs from, and writes outputs to, these tables rather than touching physical I/O directly.
- Collection is a precursor. ATT&CK notes the collected state can be used to replace values or to inform later attack stages, which is what Stuxnet did.
- Direct mitigation is limited. ATT&CK maps only M0816 Mitigation Limited or Not Effective, so you protect the paths into the controller instead.
- Detect the shape of the read, not its existence. Legitimate SCADA polling reads a sparse, fixed tag set; ATT&CK's analytic looks for a session reading the whole image from an unapproved source.
- On-controller collection is hard to see. Code running inside the PLC needs no network read at all, so program integrity checks carry real weight.
What the I/O image is
ATT&CK for ICS describes it as follows. During the scan cycle a PLC reads the status of all inputs and stores them in an image table, the controller's internal storage for the input and output values of one scan while it runs the user program. After the logic has been solved, the PLC updates the output image table, and its contents are written to the output points on the I/O modules. Together the input and output image tables make up the I/O image. Adversaries may collect it by using the device's Native API (T0834) to access those memory regions directly.
| Access path | How the image could be read | Where it is visible |
|---|---|---|
| Network protocol session from a host | Reading the I/O address range over the controller's industrial protocol | OT network monitoring with protocol decoding |
| Code running on the controller | Malicious logic copying image areas into data blocks | Program and block integrity comparison against the approved project |
| Engineering software on a compromised host | Online monitoring or diagnostic views of I/O values | Engineering workstation logs; session source in network monitoring |
For the controller fundamentals behind this, see the PLC Security Guide. This page focuses on the technique itself.
The documented case: Stuxnet
T0877 has one procedure example in ATT&CK v20. ATT&CK records that Stuxnet (S0603) copied the input area of an I/O image into data blocks with a one second interval between copies, forming a 21 second recording of the input area, such as the current state of a valve or the temperature of a device. The Symantec W32.Stuxnet Dossier describes a monitoring routine that recorded values from frames sent by frequency converter drives over Profibus, and later attack stages that sent frames which partly depended on what had been recorded.
Lesson: collection was done by code inside the controller, so a network read detector would not have seen it. Stuxnet also hid its blocks from the engineering software through a hooked library (see ATT&CK for ICS T0874 Hooking). Program integrity must be verified from a trusted path. No other public procedure examples are listed by ATT&CK for this technique.
Detection: the ATT&CK v20 analytic
The detection strategy for T0877 (DET0774, Detection of I/O Image) has one analytic, AN1906, for embedded devices. It identifies a single ICS protocol session reading the complete I/O image from a field device, rather than the sparse, fixed tag subset that legitimate SCADA polling queries, from a source that is not in the approved control server list. ATT&CK's operational fidelity gate applies: do not alert on novelty, read volume or enumeration alone; alert when the source role is not authorised for polling and the target scope, address or tag range, protocol or rate departs from the baseline; suppress normal SCADA, HMI and historian polling, commissioning, asset inventory, backup, diagnostics and approved engineering work.
Building it
- Inventory the legitimate readers. For each controller, list the SCADA servers, HMIs, historians and engineering stations that poll it, and which address or tag ranges each reads. Your OT monitoring platform's communication map is the starting point; see the OT Asset Visibility Guide.
- Know each controller's I/O size. The analytic's coverage threshold is a percentage of the device's total I/O space, so you need that size per controller from the project files.
- Decode the protocol. Coverage depends on the monitoring sensor parsing read requests and address ranges for the protocols in use; check which of your controller protocols it decodes fully.
- Set the threshold with engineers. Choose a coverage percentage that normal polling never reaches, and list the sources that may legitimately exceed it (backup and commissioning tools).
- Run in observation mode first. Compare alerts with the maintenance calendar for several weeks before paging anyone.
| Signal | Likely benign | Worth investigating |
|---|---|---|
| Full-range read from the engineering station during a scheduled change | Yes, if a change ticket matches | If no ticket exists or it occurs outside the window |
| Full-range read from a historian or SCADA server | Rarely, usually a configuration change | Yes, confirm with the system owner |
| Any read from a host outside the approved list | Asset inventory or diagnostic tool if documented | Yes, especially from IT-side or remote access subnets |
| Repeated reads of the same input area at fixed intervals | Trending configured by engineers | Yes, if the source is new or the pattern is new |
Network detection covers only the first path. For code inside the controller, rely on comparing the running program with the approved project, from a trusted host, after every download and on a schedule. See the OT Network Security Monitoring Guide for sensor placement.
Prevention: controlling the paths in
Because ATT&CK maps only M0816 to T0877, prevention means narrowing who and what can reach controller memory:
- Restrict protocol access to controllers: allow controller protocols only from named SCADA servers, HMIs and engineering stations, and block them at every other conduit. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
- Use controller access protections: where the product supports read and write protection levels or passwords on online access, turn them on and replace defaults.
- Protect the engineering station: it can read everything the controller holds. See the Engineering Workstation Security Guide.
- Verify program integrity: on-controller collection needs modified logic, so integrity checks after downloads close the second path.
| Framework | Reference | Relevance to T0877 |
|---|---|---|
| ATT&CK for ICS | M0816 Mitigation Limited or Not Effective | Signals that controls must target the access paths |
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection | Limits which hosts can reach controller protocols |
| NIST SP 800-53 Rev. 5 | SI-4 System Monitoring | Protocol-aware monitoring of read scope |
| NIST SP 800-53 Rev. 5 | SI-7 Software, Firmware, and Information Integrity | Detects logic added to copy image areas |
| NIST CSF 2.0 | DE.CM-09, DE.AE-02 | Monitoring and analysis of adverse events on OT assets |
Where identity fits
Most legitimate I/O reads come from service accounts and applications: SCADA servers, historians and their collectors. Treat the approved reader list as an identity inventory for machines, and review vendor and integrator remote access that can reach controllers. See the OT and ICS Identity and Access Guide.
When the analytic fires
- Identify the source host and its owner, then check for a matching change ticket or maintenance activity.
- Do not disrupt the controller. A read does not change the process; avoid restarts or mode changes as a first reaction.
- Contain the source, for example by blocking it at the conduit firewall, after agreeing with operations that it is not a needed HMI or SCADA server.
- Look for the next stage: program downloads, parameter writes or mode changes to the same controller, since collection informs later steps.
- Verify the controller program against the approved project from a trusted host. See the OT Incident Response Guide.
Measuring coverage
- Reader inventory: share of controllers with a documented list of approved reading hosts and address ranges.
- Protocol decode coverage: share of controller protocols in use that your sensors parse down to address ranges.
- Integrity check cadence: share of controllers whose program was compared with the approved project in the last period you set.
- Conduit enforcement: number of hosts outside the approved list that can reach controller protocol ports, which should trend to zero.
Common failure patterns
- Alerting on any new reader: ATT&CK advises against novelty-only alerts; commissioning and inventory tools will flood the queue.
- Relying on the network alone: Stuxnet's collection ran inside the controller and would not appear as a network read.
- No per-controller I/O size: without it, the coverage threshold cannot be set and the analytic is guesswork.
- Flat access to controllers: when any host in the control network can talk to any PLC, the approved list has no meaning.
Practitioner checklist
- Document the approved reading hosts and address ranges for each controller.
- Record each controller's total I/O space from the project files.
- Confirm your OT sensors decode read requests and address ranges for each protocol in use.
- Implement AN1906 in observation mode, then tune with control engineers.
- Restrict controller protocol access at conduits to the approved hosts.
- Turn on controller access protection where the product supports it.
- Compare running programs with approved projects after every download and on a schedule.
Standards and references
- MITRE ATT&CK for ICS: T0877 I/O Image
- MITRE ATT&CK: Stuxnet (S0603)
- MITRE ATT&CK for ICS: M0816 Mitigation Limited or Not Effective
- Symantec: W32.Stuxnet Dossier
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: PLC Security Guide, ATT&CK for ICS Impair Process Control Tactic Guide, ICS Malware History Guide, OT Security Guide.