T0835: Manipulate I/O Image
Adversaries may manipulate the I/O image of PLCs through various means to prevent them from functioning as expected. Methods of I/O image manipulation may include overriding the I/O table via direct memory manipulation or using the override function used for testing PLC programs. [1] During the scan cycle, a PLC reads the status of all inputs and stores them in an image table. [2] 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.
One of the unique characteristics of PLCs is their ability to override the status of a physical discrete input or to override the logic driving a physical output coil and force the output to a desired status.
Analyst context for executives and security teams
Manipulate I/O Image matters because it targets the internal PLC/controller view of inputs and outputs, not just the physical signal itself. If that image table or force/override function is abused, an industrial process may behave differently than operators or control logic expect. For leaders, the key issue is whether engineering, operations, and security teams can prove when controller I/O values were forced, overridden, or changed in memory, especially on PLCs, safety controllers, DCS controllers, and PACs.
Executive priority
Treat this as a cyber-physical resilience issue more than a standard IT malware issue. ATT&CK lists mitigation as limited or not effective because the behavior can abuse legitimate controller features used for testing and operations. Executives should ask whether override/force use is governed, logged, reviewed, and included in incident response playbooks, and whether safety-critical controllers have operational procedures to distinguish authorized engineering activity from suspicious manipulation.
Technical view
SOC, OT security, and IR teams should validate visibility around controller I/O image changes, force/override status, direct memory manipulation indicators where available, and engineering workstation activity associated with PLC, safety controller, DCS controller, and PAC logic or I/O operations. Because no official ATT&CK detection text is provided, detection engineering should start from the related DET0773 detection strategy and local controller capabilities. Focus on distinguishing normal commissioning, testing, and troubleshooting from unexpected override activity, unexplained I/O state mismatches, or changes outside approved maintenance windows.
Likely telemetry
- Controller event and diagnostic logs showing force/override status or I/O table changes where supported
- Engineering workstation activity related to controller programming, testing, or online edits
- Change-management records for approved PLC, safety controller, DCS controller, and PAC maintenance
- Process historian or HMI data showing discrepancies between expected physical state and controller-reported I/O state
- Network or protocol telemetry between engineering systems and embedded control assets where collected
Detection direction
- Use DET0773 as the ATT&CK-linked detection starting point, but confirm what each controller family can actually log or expose.
- Tune detections around unauthorized or out-of-window force/override use, while accounting for legitimate testing and commissioning activity.
- Correlate controller I/O state changes with engineering workstation sessions, approved work orders, and process observations.
- Look for mismatches between physical process behavior, HMI/historian values, and controller I/O image values when telemetry permits.
- Document blind spots where controllers do not retain sufficient logs or where SOC tooling cannot ingest OT engineering or controller diagnostics.
Mitigation priorities
- Prioritize governance and procedural controls for force/override functions because ATT&CK notes preventative mitigation is limited or not effective for abuse of legitimate features.
- Restrict and review who can perform controller testing, online edits, direct memory access, or I/O override operations.
- Require change approval and evidence capture for maintenance that alters I/O behavior on PLCs, safety controllers, DCS controllers, or PACs.
- Maintain known-good controller logic and configuration baselines to support incident response comparison.
- Include I/O image manipulation scenarios in OT incident response and safety coordination exercises.
Analyst notes and limits
The relationship context makes this especially relevant to embedded industrial controllers, including PLCs, safety controllers, DCS controllers, and PACs. ATT&CK also links the technique to Stuxnet and PLC-Blaster, but that should be used as historical/contextual threat intelligence only, not as evidence of current activity in any environment.
The supplied ATT&CK object has no official detection text, no listed tactics, and no listed platforms on the technique itself. Practical detection and response depend heavily on local controller models, engineering tools, logging capability, process historian coverage, and change-management discipline.
Manipulate I/O Image
Adversaries may manipulate the I/O image of PLCs through various means to prevent them from functioning as expected. Methods of I/O image manipulation may include overriding the I/O table via direct memory manipulation or using the override function used for testing PLC programs. [1] During the scan cycle, a PLC reads the status of all inputs and stores them in an image table. [2] 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.
One of the unique characteristics of PLCs is their ability to override the status of a physical discrete input or to override the logic driving a physical output coil and force the output to a desired status.
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
S1006: PLC-Blaster
PLC-Blaster is a piece of proof-of-concept malware that runs on Siemens S7 PLCs. This worm locates other Siemens S7 PLCs on the network and attempts to infect them. Once this worm has infected its target and attempted to infect other devices on the network, the worm can then run one of many modules. [1] [2]
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 | 3c502ce79338… |
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]
Dr. Kelvin T. Erickson December 2010
Dr. Kelvin T. Erickson 2010, December Programmable logic controller hardware Retrieved November 17, 2024.
Open source URL -
[2]
Nanjundaiah, Vaidyanath
Nanjundaiah, Vaidyanath Dr. Kelvin T. Erickson 2010, December Programmable logic controller hardware Retrieved. 2018/03/29 PLC Ladder Logic Basics Retrieved. 2021/10/11
Open source URL -
[3]
mitre-attack T0835Open 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.