DET0773: Detection of Manipulate I/O Image
DET0773 is a MITRE ATT&CK detection strategy for identifying attempts to manipulate a PLC I/O image, associated with ICS technique T0835. In business terms...
Analyst context for executives and security teams
DET0773 is a MITRE ATT&CK detection strategy for identifying attempts to manipulate a PLC I/O image, associated with ICS technique T0835. In business terms, this matters because the I/O image is part of how a controller understands field inputs and drives outputs; if it is altered or overridden, physical equipment may behave differently than operators, logic, or safety assumptions expect. The ATT&CK object provides no official detection logic or platform scope, so organizations should treat this as a validation prompt for cyber-physical monitoring coverage rather than a ready-made analytic.
Executive priority
Prioritize this where PLC-controlled processes affect safety, production continuity, environmental controls, or regulated operations. Leaders should ask whether the organization can prove when PLC input/output states are overridden, forced, or inconsistent with expected process behavior, and whether incident responders can quickly distinguish authorized testing from abnormal manipulation. This is also relevant to audit and resilience evidence: coverage depends on engineering workstation controls, PLC change visibility, historian/process data, and ICS network monitoring being available and reviewable.
Technical view
The related ATT&CK technique describes manipulation of PLC I/O image behavior through direct memory manipulation or use of override functions commonly associated with testing PLC programs. Because MITRE provides no official detection text for DET0773, SOC and ICS defenders should validate whether their environment can observe controller override/force states, engineering actions against PLCs, unexpected writes or memory-level changes where observable, and mismatches between field reality, PLC image values, and process historian records. Detection engineering should be coordinated with control engineers to define normal commissioning, maintenance, and testing patterns before alerting on changes.
Likely telemetry
- PLC force/override status and controller diagnostic records, where available
- Engineering workstation activity and project/change logs
- PLC program, configuration, and memory change records, where supported
- ICS network traffic involving engineering or write operations to controllers
- Process historian values for inputs, outputs, and actuator/sensor states
Detection direction
- Validate whether monitoring can identify PLC I/O forces, overrides, or abnormal image-table-related changes rather than only detecting full logic downloads.
- Correlate controller-level events with engineering workstation users, maintenance windows, and approved test activity to reduce false positives.
- Look for inconsistencies between commanded outputs, observed process state, historian data, and HMI/operator expectations.
- Assess blind spots where PLCs do not expose sufficient diagnostic data, where engineering actions are not centrally logged, or where ICS network traffic is not decoded at the protocol level.
- Use the relationship to T0835 as the behavioral anchor; do not assume platform, tactic, or analytic coverage because the DET0773 object does not specify them.
Mitigation priorities
- Establish governance for authorized PLC testing, force/override use, and removal of temporary overrides after maintenance.
- Restrict and monitor engineering workstation access and controller change capability based on operational need.
- Maintain recoverable baselines for PLC logic, configuration, and expected I/O behavior.
- Improve ICS visibility through controller diagnostics, historian correlation, and network monitoring where safe and supported.
- Include I/O manipulation scenarios in incident response playbooks and tabletop exercises involving operations, engineering, safety, and security teams.
Analyst notes and limits
This take is based on DET0773 and its relationship to T0835 Manipulate I/O Image. The supplied ATT&CK detection strategy has no official description, detection logic, platforms, tactics, aliases, or labels. The practical guidance therefore focuses on defensible validation questions and telemetry classes implied by the related technique description, especially PLC I/O image manipulation through overrides or direct memory manipulation.
Coverage and feasibility are highly environment-specific. The supplied fields do not identify affected vendors, protocols, platforms, adversaries, campaigns, or validated analytics. Local PLC capabilities, engineering practices, historian quality, and network visibility determine whether this behavior can be detected reliably.
Detection of Manipulate I/O Image
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0835 | Manipulate I/O Image | This object detects Manipulate I/O Image. |
All related ATT&CK context
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 | 2e840ba4aa9a… |
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 DET0773Open 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.