Manipulation of View (T0832) makes the control room believe something false: the HMI shows normal values while the process is in a different, possibly dangerous, state. MITRE ATT&CK for ICS places it under the Impact tactic and describes adversaries manipulating the information reported back to operators or controllers, for a short or sustained period, so that operators may take harmful actions or fail to act, and business systems receive inaccurate data. It is harder to spot than a loss of view, because a screen that keeps updating looks healthy. This guide is for OT security engineers, control engineers, SCADA administrators and incident responders. It covers how T0832 differs from its neighbours, the two recorded procedure examples, practical ways to cross-check what operators see, the ATT&CK mitigations and a safety-aware response. For the wider matrix see the MITRE ATT&CK for ICS Guide.
Key takeaways
- False values beat no values. Denial or loss of view prompts operators to investigate; a manipulated view prompts them to trust the screen, which is why Stuxnet replayed recorded process values.
- The only reliable test is a second, independent source. ATT&CK's Out-of-Band Communications Channel mitigation (M0810) is worded as validating the integrity of data from the primary channel.
- There is no standard detection for the technique itself. ATT&CK detection strategy DET0785 says so, so detection relies on consistency checks across sensors, protocols and physics.
- Manipulation of view usually accompanies another impact. In both recorded cases it hid or misdirected attention from an attack on control or protection.
- Response starts by distrusting the HMI. Operators confirm critical states in the field or through independent instruments before acting on what the screen says.
What T0832 covers and how it differs from nearby techniques
ATT&CK v20 lists T0832 under Impact (TA0105) with no platform ("None") and no sub-techniques. It describes an effect on what humans and systems are told, and the technique text notes that inaccurate data can also mislead business analysis systems, which matters where historian data feeds billing, compliance reporting or planning.
| Technique | What the operator sees | Typical means |
|---|---|---|
| T0832 Manipulation of View | Plausible but false values, statuses or alarms | Spoofed or replayed reporting messages, altered I/O image, compromised HMI or historian |
| T0815 Denial of View | Frozen or missing updates, temporary | Blocked reporting messages, communication disruption |
| T0829 Loss of View | No view, sustained | Wiped HMIs or servers, destroyed gateways |
| T0835 Manipulate I/O Image | Values the controller itself uses are altered | Overrides of the PLC input or output image table |
| T1692 Unauthorized Message | Reporting messages that make the process appear in another state | Injected reporting or command messages |
| T0831 Manipulation of Control | Equipment moves without an intended command | Command injection, setpoint changes |
See the T0815 Denial of View, T0829 Loss of View, T0835 Manipulate I/O Image and T1692 Unauthorized Message guides for the neighbouring techniques. T0831 Manipulation of Control is the control-side counterpart.
Real cases recorded by ATT&CK
- Stuxnet (S0603): ATT&CK records that Stuxnet manipulated the view of operators by replaying process input and manipulating the I/O image to evade detection and inhibit protection functions. Symantec's W32.Stuxnet Dossier describes the mechanism at the controller level: malicious PLC code monitored Profibus frames from frequency converters, recorded values including the current output frequency, and later, while the original control code was halted, sent frames based on the recorded values while it changed drive speeds.
- Industroyer (S0604): ATT&CK records that its OPC module can brute force values and send a 0x01 status which, for the target systems, equates to "Primary Variable Out of Limits", misdirecting operators from understanding protective relay status.
The two cases show the two layers at which view can be manipulated: inside the controller, before any network monitor sees the data (Stuxnet), and in the supervisory layer that aggregates status for operators (Industroyer's OPC module). A defence that checks only network traffic will miss the first; one that checks only the controller will miss the second. For the malware background see the ICS Malware History Guide.
Detecting a manipulated view
ATT&CK's detection strategy DET0785 contains one analytic: "No standard detection method currently exists for this technique." The practical approach is to look for inconsistency, because a manipulated value has to agree with everything else to stay hidden.
| Cross-check | How to implement it | What disagreement suggests |
|---|---|---|
| Redundant or diverse sensors on critical variables | Compare readings from instruments on separate I/O, or from the safety system's own sensors | Altered values in one control path |
| Physics and mass balance | Historian analytics: flow in versus flow out, power versus speed, level versus pump run time | Values that are individually plausible but jointly impossible |
| Replay signature | Look for values with unnaturally low noise, repeating sequences or identical patterns across days | Recorded data played back, as Stuxnet did |
| Wire values versus displayed values | Compare values decoded by an OT network sensor with what the HMI and historian store | Manipulation in the HMI, OPC server or historian layer |
| Status messages from unexpected sources | OT protocol monitoring of which hosts send reporting traffic to masters and OPC servers | Injected reporting messages (T1692) |
| Changes to HMI screens, tag databases and OPC configurations | File integrity monitoring and change journals on HMI, SCADA and OPC hosts | Altered displays, scaling or tag mappings |
| Controller logic or I/O force changes | Comparison of running logic with the approved project; controller force and override indicators | Manipulated I/O image inside the PLC (T0835) |
Making the checks practical
- Start with the variables that matter for safety and quality: a short list of critical tags with an independent second source is worth more than broad but shallow coverage.
- Agree tolerances with control engineers: sensors drift and disagree in normal operation; thresholds need process knowledge to avoid alert fatigue.
- Protect the reference source: a cross-check is only useful if the second path does not share the compromised host, network or credentials.
Sensor placement and protocol decoding are covered in the OT Network Security Monitoring Guide, and the collection side in the T0801 Monitor Process State guide.
Mitigations: the three ATT&CK lists and how to apply them
- Communication Authenticity (M0802): ATT&CK advises authenticity through MAC functions or digital signatures for control protocols, or bump-in-the-wire devices or VPNs where devices such as legacy controllers and RTUs cannot support it. Authenticated reporting stops injected status messages from unauthorised hosts; it does not help if the legitimate sender is compromised.
- Out-of-Band Communications Channel (M0810): ATT&CK's wording is to use out-of-band communication to validate the integrity of data from the primary channel. Examples include local gauges and panels, a separate telemetry path for critical points, and the safety system's own indication.
- Data Backup (M0953): hardened, separated backups and gold copies of HMI projects, OPC and historian configurations and controller logic, so a trusted view can be rebuilt. See the OT Backup, Recovery and Golden Image Guide.
Upstream controls matter as much: hardening of HMI and SCADA servers (see the HMI and SCADA Server Hardening Guide), protection of engineering workstations that can change displays and logic (see the Engineering Workstation Security Guide), and the joint CISA, FBI, EPA and DOE primary mitigations: no internet exposure, changed default passwords, secured remote access with phishing-resistant MFA, IT and OT segmentation and the ability to operate manually.
Choosing between options
| Situation | Preferred control | Trade-off |
|---|---|---|
| Critical safety variables | Independent sensor path, ideally the safety system's own, displayed alongside the control value | Instrument cost and engineering change |
| Large plant with a historian and OT network monitoring | Automated comparison of wire values, historian values and physics checks | Tuning effort with process engineers |
| Remote sites on unauthenticated links | Authenticated tunnels or bump-in-the-wire devices on reporting links | Latency and device management |
| Small site with little budget | Scheduled field rounds comparing local gauges with HMI values for a short tag list | Slow, but independent of any digital path |
Safety-aware response
- Treat the HMI as untrusted: operations confirms critical states through local indication, field checks and the safety system before making control decisions.
- Decide the operating mode: the shift supervisor decides whether the process can continue, move to manual or shut down safely, given that the view cannot be relied on.
- Check protection functions: both recorded cases used false view to cover an attack on control or protection. Confirm the safety instrumented system and protective relays are healthy. See the Safety Instrumented Systems Security Guide.
- Locate the layer: compare field values, wire values, controller values and displayed values to find whether the manipulation is in the controller, network, OPC or HMI layer.
- Preserve evidence: historian data, network captures, HMI and OPC configuration files, controller projects read from the device and host images.
- Rebuild a trusted view: restore from gold copies, verify displayed values against independent measurements, and only then return to normal supervision.
The wider process is in the OT Incident Response Guide.
Metrics that show it is working
- Independent coverage of critical tags: share of safety and quality critical variables with a second, independent measurement path.
- Cross-check alerts reviewed: count per month of sensor or physics disagreement alerts and share closed with a root cause.
- Integrity monitoring coverage: share of HMI, OPC and historian hosts with change monitoring on screens, tag databases and configurations.
- Authenticated reporting links: share of inter-zone and wireless reporting links with message authentication or an authenticated tunnel.
- Time to verify view: time in exercises for operators to confirm a critical state independently once the HMI is in doubt.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK for ICS mitigation |
|---|---|---|---|
| Authentic reporting messages | SC-8 Transmission Confidentiality and Integrity; IA-3 Device Identification and Authentication | PR.DS-02 | M0802 Communication Authenticity |
| Independent validation of displayed data | SI-4 System Monitoring | DE.CM-01; DE.AE-02 | M0810 Out-of-Band Communications Channel |
| Integrity of HMI, OPC and controller configuration | SI-7 Software, Firmware, and Information Integrity; CM-3 Configuration Change Control | DE.CM-09; PR.PS-01 | No standard detection for T0832 itself (DET0785) |
| Backups and trusted rebuild | CP-9 System Backup | RC.RP-01 | M0953 Data Backup |
For OT tailoring see the NIST SP 800-82 OT Security Guide.
Common failure patterns
- Monitoring that only alarms on missing data: communication health checks catch denial of view but not a view that keeps updating with false values.
- A "second source" that shares the compromised path: a backup display fed by the same OPC server or historian repeats the same false values.
- Trusting smooth data: real process values are noisy; unusually flat or repeating values deserve a look rather than relief.
- Untracked HMI and tag changes: changes to scaling, display logic or tag mapping made without change control can hide or create false values, and nobody can tell which.
- Restoring control without restoring view: rebuilding controllers while the HMI layer remains compromised leaves operators acting on false information.
Practitioner checklist
- List critical safety and quality variables and give each an independent second measurement path.
- Compare wire values from OT network monitoring with HMI and historian values for those variables.
- Add physics and mass balance checks to historian analytics with tolerances agreed by process engineers.
- Monitor HMI screens, tag databases and OPC configurations for unapproved change.
- Compare running controller logic and force status with the approved project on a schedule.
- Authenticate reporting links that cross zones or use wireless paths.
- Keep gold copies of HMI, OPC and historian configurations and test restore.
- Train operators to confirm critical states locally when the HMI is in doubt.
Standards and references
- MITRE ATT&CK for ICS: Manipulation of View (T0832)
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- CISA, FBI, EPA and DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology
- Symantec: W32.Stuxnet Dossier
- MITRE ATT&CK: Industroyer (S0604)
- MITRE ATT&CK: Stuxnet (S0603)
Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · ATT&CK for ICS Impact Tactic Guide · OT Security Operations Centre Guide · OT Security Guide