AN1905: Analytic 1905
A manipulated I/O image requires analyzing the application program running on the PLC for specific data block writes. Detecting this requires obtaining and analyzing a PLC’s application program, either directly from the device or from asset management platforms.
Analyst context for executives and security teams
This analytic matters because it focuses on a control-system integrity problem that ordinary IT monitoring may miss: whether a PLC program is writing to data blocks in a way that could manipulate the I/O image. For executives and security leaders, the practical question is not “do we have an alert,” but “can we obtain, preserve, and review PLC application logic when operational integrity is in question?”
Executive priority
Prioritize this as an ICS visibility and assurance issue. It supports incident response readiness, operational resilience, and compliance evidence by testing whether engineering, security, and asset-management teams can retrieve PLC application programs and analyze them for suspicious data block writes. Because ATT&CK provides no platform, tactic, or relationship context for this analytic, leaders should treat it as a validation requirement rather than a complete detection capability.
Technical view
SOC, OT security, and IR teams should validate whether they can collect PLC application programs directly from devices or from asset management platforms, then review the logic for specific data block writes associated with a manipulated I/O image. The key operational dependency is access to trustworthy PLC program copies and a process for comparing or analyzing logic without disrupting production. Since no official detection logic is supplied, local engineering knowledge is required to distinguish expected program behavior from suspicious writes.
Likely telemetry
- PLC application program exports or backups
- Asset management platform records containing PLC program versions
- Engineering workstation or change-management records showing PLC logic versions
- Program comparison or logic review outputs focused on data block writes
Detection direction
- Confirm that PLC application programs can be obtained from the device or asset management platforms when needed.
- Validate that program analysis can identify data block writes relevant to the PLC I/O image.
- Establish a baseline of expected PLC logic and authorized data block write behavior where operationally feasible.
- Account for false positives from legitimate engineering changes, maintenance activity, or approved program revisions.
- Do not assume network telemetry alone will provide coverage; the supplied analytic depends on PLC application program analysis.
Mitigation priorities
- Maintain reliable PLC program backups and asset-management records to support comparison and investigation.
- Define an approved process for retrieving PLC application logic that minimizes operational disruption.
- Coordinate OT engineering and security review of PLC logic changes, especially data block writes affecting I/O behavior.
- Use change control and version evidence to support incident response and audit questions around PLC program integrity.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic in the ICS domain. It states that detecting a manipulated I/O image requires analyzing the PLC application program for specific data block writes, using a program obtained directly from the PLC or from asset management platforms. No tactics, platforms, relationships, or official detection query are provided.
This take is limited by sparse ATT&CK fields. It does not identify specific PLC vendors, protocols, adversaries, techniques, impacts, or active exploitation. Local asset inventories, engineering documentation, approved logic baselines, and safe collection procedures are required to turn this analytic into operational detection coverage.
Analytic 1905
A manipulated I/O image requires analyzing the application program running on the PLC for specific data block writes. Detecting this requires obtaining and analyzing a PLC’s application program, either directly from the device or from asset management platforms.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.0 | Current bundle | 8351be22e027… |
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]
mitre-attack AN1905Open 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.