T0877: I/O Image
Adversaries may seek to capture process values related to the inputs and outputs of a PLC. During the scan cycle, a PLC reads the status of all inputs and stores them in an image table. [1] The image table is the PLCs internal storage location where values of inputs/outputs for one scan are stored while it executes the user program. After the PLC has solved the entire logic program, it updates the output image table. The contents of this output image table are written to the corresponding output points in I/O Modules.
The Input and Output Image tables described above make up the I/O Image on a PLC. This image is used by the user program instead of directly interacting with physical I/O. [2]
Adversaries may collect the I/O Image state of a PLC by utilizing a devices Native API to access the memory regions directly. The collection of the PLCs I/O state could be used to replace values or inform future stages of an attack.
Analyst context for executives and security teams
I/O Image matters because it represents the controller’s current view of process inputs and outputs during a PLC scan cycle. If an adversary can collect this state through controller features such as a native API, they may gain process-aware insight that can support later manipulation or replacement of values. For leaders, the business issue is not ordinary data theft; it is loss of visibility and trust in the values used to operate industrial equipment.
Executive priority
Prioritize this as an ICS resilience and safety-relevant visibility question: do teams know which PLCs, safety controllers, DCS controllers, and PACs expose memory or native API access to I/O image data, who can access it, and whether that access is monitored? ATT&CK lists mitigation as limited or not easily effective because the behavior abuses legitimate system features, so executive focus should be on asset knowledge, access governance, monitoring, incident response readiness, and evidence that engineering-approved access is distinguishable from suspicious collection.
Technical view
SOC, OT security, and IR teams should validate coverage around access to controller memory regions and native APIs associated with PLC I/O image data. Because ATT&CK does not provide official detection text for T0877, use the related detection strategy DET0774 as a prompt to define local analytics rather than assuming coverage. Review controller engineering access, memory-read operations, API calls, controller communications, and changes in interaction patterns with PLCs, safety controllers, DCS controllers, and PACs. Relationship context also links this behavior to Stuxnet, but the supplied data should be treated as historical technique context, not evidence of current activity.
Likely telemetry
- Controller communication logs or network captures involving PLC, safety controller, DCS controller, or PAC access
- Engineering workstation activity involving controller APIs, memory reads, or diagnostic functions
- Authentication, session, and authorization records for controller or engineering software access where available
- Asset inventory mapping of controllers, exposed services, and approved engineering systems
- Change-management and maintenance-window records to distinguish authorized troubleshooting from unexpected collection
Detection direction
- Confirm whether DET0774 or an equivalent local detection strategy is implemented for I/O Image access; do not assume default SOC tooling observes embedded controller memory access.
- Baseline legitimate engineering and maintenance activity that reads controller state so alerts can focus on unusual sources, timing, volume, or controller scope.
- Correlate controller access with approved users, engineering workstations, maintenance windows, and asset criticality.
- Look for unexpected systems communicating with embedded controllers or using functions consistent with native API access to process values.
- Account for false positives from normal diagnostics, commissioning, troubleshooting, and vendor support activity.
Mitigation priorities
- Treat prevention as limited because ATT&CK identifies this technique as abuse of system features rather than a simple preventable exploit.
- Reduce unnecessary access to controller native APIs and engineering functions through least privilege and controlled engineering workstation use.
- Segment and monitor paths to PLCs, safety controllers, DCS controllers, and PACs so unauthorized systems cannot casually query controller state.
- Maintain accurate inventories of controllers, approved tools, and authorized users to support detection and incident triage.
- Use change-control and maintenance-window discipline to make legitimate I/O state collection auditable.
Analyst notes and limits
This take is based on ATT&CK T0877 I/O Image, its description, external references, and relationships to DET0774, M0816, targeted ICS assets, and Stuxnet software. The core defensive value is validating visibility into legitimate controller features that expose process I/O state, especially because conventional IT logs may not show the behavior.
ATT&CK provides no official detection text, no tactics, and no platform field for the technique itself. The target assets are embedded ICS controllers, but local controller models, protocols, vendor tooling, and logging capabilities determine what can actually be monitored. This summary does not assert active exploitation, attribution, or guaranteed detection coverage.
I/O Image
Adversaries may seek to capture process values related to the inputs and outputs of a PLC. During the scan cycle, a PLC reads the status of all inputs and stores them in an image table. [1] The image table is the PLCs internal storage location where values of inputs/outputs for one scan are stored while it executes the user program. After the PLC has solved the entire logic program, it updates the output image table. The contents of this output image table are written to the corresponding output points in I/O Modules.
The Input and Output Image tables described above make up the I/O Image on a PLC. This image is used by the user program instead of directly interacting with physical I/O. [2]
Adversaries may collect the I/O Image state of a PLC by utilizing a devices Native API to access the memory regions directly. The collection of the PLCs I/O state could be used to replace values or inform future stages of an attack.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Groups, software, and campaigns
S0603: Stuxnet
Stuxnet was the first publicly reported malware to specifically target industrial control systems devices. Stuxnet is a large and complex malware that utilized multiple behaviors, including numerous zero-day vulnerabilities, a sophisticated Windows rootkit, and network infection routines.[1][2][3][4] Stuxnet was discovered in 2010, with some components being used as early as November 2008.[1]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | a246d8ad038e… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Nanjundaiah, Vaidyanath
Nanjundaiah, Vaidyanath PLC Ladder Logic Basics Retrieved. 2021/10/11
Open source URL -
[2]
Spenneberg, Ralf 2016
Spenneberg, Ralf 2016 PLC-Blaster Retrieved. 2019/06/06
Open source URL -
[3]
mitre-attack T0877Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.