T0801: Monitor Process State
Adversaries may gather information about the physical process state. This information may be used to gain more information about the process itself or used as a trigger for malicious actions. The sources of process state information may vary such as, OPC tags, historian data, specific PLC block information, or network traffic.
Analyst context for executives and security teams
Monitor Process State matters because it turns normal ICS visibility into adversary decision support. By reading OPC tags, historian data, PLC block information, or network traffic, an adversary can understand when a physical process is in a useful state and potentially time later malicious actions. For executives and operations leaders, the risk is not just data access; it is loss of confidence that process visibility, alarms, and control context are only being used by authorized operators and engineering systems.
Executive priority
Prioritize this as an ICS resilience and assurance issue. MITRE notes that this behavior is difficult to prevent with simple controls because it abuses legitimate system features. Leaders should ask whether access to process state data is governed, logged, and reviewed across HMIs, PLCs, RTUs, IEDs, historians, control servers, data gateways, safety controllers, Field I/O, DCS controllers, and PACs. The key business decision is whether the organization can distinguish authorized process monitoring from suspicious collection before it becomes a trigger for unsafe or disruptive actions.
Technical view
ATT&CK provides no official detection text and no technique-level platforms or tactics for T0801. Detection engineering should therefore start from asset-specific visibility and the related DET0727 detection strategy. Validate monitoring around reads or queries of process state sources named by MITRE: OPC tags, historian data, PLC block information, and ICS network traffic. Because the technique targets many ICS assets, SOC and IR teams should baseline which HMIs, historians, control servers, gateways, controllers, RTUs, IEDs, and field devices normally request process values, at what frequency, and through which paths. Relationship context to Stuxnet, Industroyer, Industroyer2, and FrostyGoop supports treating this as a meaningful behavior in ICS threat hunting, without assuming current local exposure or activity.
Likely telemetry
- Historian query and access logs for process values, events, alerts, and alarms
- HMI access logs and operator/session activity where available
- Control server communications with lower-level control devices
- OPC tag access or equivalent process data request records
- PLC, RTU, IED, PAC, DCS controller, and safety controller communication logs where supported
Detection direction
- Confirm whether DET0727 or equivalent local analytics are implemented for monitoring process state access patterns.
- Baseline normal process state reads by asset, role, source host, protocol path, and time window; alert on unusual sources, excessive polling, new cross-zone access, or reads inconsistent with operational duties.
- Correlate process data access with authentication, remote access, engineering activity, and network flow records to reduce false positives from legitimate operator, engineering, and business analysis use.
- Pay special attention to historians and data gateways because the supplied relationships describe them as aggregation or exchange points that may bridge operational and business needs.
- Account for blind spots: embedded controllers and field devices may have limited local logging, and MITRE provides no official detection procedure for this technique.
Mitigation priorities
- Treat prevention as limited: the related MITRE mitigation states this behavior is not easily mitigated with preventative controls because it abuses system features.
- Prioritize least-privilege access to process state data across HMIs, historians, control servers, gateways, and controller-facing systems.
- Segment and govern paths that allow corporate, engineering, or remote users to query historian or live process data.
- Maintain asset and data-flow inventories for the targeted ICS asset classes so monitoring can distinguish expected process visibility from abnormal collection.
- Use logging, review, and incident response playbooks as primary compensating controls where direct prevention is not practical.
Analyst notes and limits
This Glexia take is based on ATT&CK T0801 version 1.0 in ICS ATT&CK release 19.1, its official description, one detection-strategy relationship, one mitigation relationship, targeted ICS asset relationships, and software-use relationships. The presence of software relationships indicates the behavior appears in known ICS malware entries, but it does not prove activity in any specific environment.
ATT&CK does not provide official detection text, tactics, aliases, labels, or technique-level platforms for this object. Local conclusions require environment-specific asset inventory, network architecture, process data access patterns, and available ICS logging. Do not infer complete prevention or detection coverage from the ATT&CK relationships alone.
Monitor Process State
Adversaries may gather information about the physical process state. This information may be used to gain more information about the process itself or used as a trigger for malicious actions. The sources of process state information may vary such as, OPC tags, historian data, specific PLC block information, or network traffic.
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]
S1165: FrostyGoop
FrostyGoop is a Windows-based binary written in Golang that allows for interaction with industrial control system (ICS) equipment via Modbus TCP over port 502. FrostyGoop allows for reading and writing data to holding registers on targeted devices, manipulating the operation of systems for malicious purposes. FrostyGoop is associated with the FrostyGoop Incident in Ukraine.[1][2]
S1072: Industroyer2
Industroyer2 is a compiled and static piece of malware that has the ability to communicate over the IEC-104 protocol. It is similar to the IEC-104 module found in Industroyer. Security researchers assess that Industroyer2 was designed to cause impact to high-voltage electrical substations. The initial Industroyer2 sample was compiled on 03/23/2022 and scheduled to execute on 04/08/2022, however it was discovered before deploying, resulting in no impact.[1]
S0604: Industroyer
Industroyer is a sophisticated malware framework designed to cause an impact to the working processes of Industrial Control Systems (ICS), specifically components used in electrical substations.[1] Industroyer was used in the attacks on the Ukrainian power grid in December 2016.[2] This is the first publicly known malware specifically designed to target and impact operations in the electric grid.[3]
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.0 | Current bundle | 7777a92c0398… |
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 T0801Open 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.