T0801 Monitor Process State: Detecting Unauthorised Reads of Live Process Values

Monitor Process State (T0801) is an adversary reading live process values, such as tag values, register contents or historian data, to learn how the plant behaves and to choose the moment to act. It is passive: nothing is written, no setpoint moves and operators see nothing unusual, which is why it so often goes unnoticed until a later, damaging step. MITRE ATT&CK for ICS v20 lists T0801 under Collection (TA0100) for Embedded, Windows, Linux and Network Devices platforms, and records it in four of the best known ICS malware families. This guide is for OT security engineers, control engineers and OT SOC analysts: what the technique covers, what the procedure examples teach, how ATT&CK's v20 analytics detect it, and why prevention here is mostly about who can reach a device at all. For the matrix overview see the MITRE ATT&CK for ICS Guide.

Key takeaways

• Reading is the reconnaissance for impact. ATT&CK notes process state can be used to learn the process or as a trigger for malicious actions, as Stuxnet did.
• ATT&CK rates prevention as limited. The only mitigation mapped is M0816 Mitigation Limited or Not Effective, because the technique abuses normal system features.
• Source identity and rate are the signals. Detection strategy DET0727 alerts on read polling from sources outside the approved SCADA and OPC client lists, or at rates and address ranges outside the baseline.
• Baselines must come from real traffic. ATT&CK's tunable fields include a measured poll rate per device and the documented tag address ranges legitimate polling actually queries.
• Reachability is the real control. If only named SCADA, HMI and historian servers can reach field devices, an intruder has to compromise one of them to read process state.

What T0801 covers

ATT&CK for ICS describes T0801 as adversaries gathering information about the physical process state, either to understand the process or as a trigger for malicious actions. It names the possible sources: OPC tags, historian data, specific PLC block information and network traffic. In practice that maps to four places an adversary can read from:

T0801 sits close to two other Collection techniques. Point and Tag Identification (T0861) is about learning which points and tags exist and what they mean; Automated Collection (T0802) is about scripting collection at scale. T0801 is the act of watching the values themselves. Map detections to all three, since the same unauthorised polling source often shows up in each.

The procedure examples and what they teach

ATT&CK v20 records four software entries for T0801. Each reads state in a different protocol, which is the main lesson: monitoring has to understand the protocols your plant actually uses.

Context from the primary reports: ESET assesses with high confidence that Industroyer2 was Sandworm's work, with actions scheduled for 8 April 2022 to cut power in a Ukrainian region, and that its configuration (device IP addresses, ASDU address and IOAs) was hardcoded for that target. Dragos links FrostyGoop to a disruptive attack on a district energy company in Lviv, Ukraine, that caused a two day loss of heating to customers, and notes the network was not adequately segmented. See the FrostyGoop Modbus Malware Guide and the Sandworm Threat Actor Profile.

Detection: ATT&CK v20 analytics

MITRE's v20 detection strategy for T0801 is DET0727, with four platform analytics. All carry ATT&CK's OT operational fidelity gate: do not alert on novelty, scan or read volume alone; alert when the source role is not authorised for polling and the target scope, address or tag range, protocol or rate deviates from the baseline; suppress normal SCADA, HMI and historian polling, commissioning, asset inventory, backup, diagnostics and approved engineering work.

The four tunable inputs ATT&CK names are ApprovedOPCClients, ApprovedSCADAServers, BaselinePollRate (measured per device from real captures) and KnownTagAddressRanges. Because the activity is read-only, ATT&CK states that source identity and rate deviation are the only distinguishing signals, so the quality of these lists decides whether the analytics work.

Telemetry worth turning on

• Protocol-aware network monitoring at the control network, recording function codes, source and destination, and register or IOA ranges. See the OT Network Security Monitoring Guide.
• OPC client connection logging on OPC servers, so new client identities stand out. See the OPC UA Security Guide.
• Historian query logging, scoped to accounts and applications, so a new reader of process history is visible.
• Linux audit rules on SCADA and historian hosts that record interpreter execution and outbound connections to device subnets.

Prevention: what actually reduces exposure

ATT&CK maps only M0816 to T0801, stating that it cannot be easily mitigated with preventive controls because it abuses system features. Reads are what SCADA does all day. The practical controls below are NHI Mgmt Group recommendations aimed at making the adversary compromise an approved polling host first, rather than reading from anywhere.

• Restrict who can poll: allow control protocol traffic to field devices only from named SCADA, HMI, historian and engineering hosts at the conduit firewall, and block it everywhere else. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
• Remove internet exposure: no control protocol port, such as Modbus TCP 502, reachable from the internet; the FrostyGoop case shows why.
• Replicate outward, not inward: give business users process data from a historian replica in the DMZ, so nobody outside the control zone needs to read devices or the primary historian.
• Use OPC UA security features: require client application certificates and user authentication on OPC UA servers, so each reader has an identity you can allowlist.
• Harden the polling hosts: since approved hosts become the attack path, treat SCADA servers and historians as critical assets. See the HMI and SCADA Server Hardening Guide.

Where identity fits

Every approved poller is a non-human identity: a historian service account, an OPC UA application certificate, a SCADA server's network address. ATT&CK's Linux analytic keys on the user ID not matching the historian or SCADA service account, and its Windows and embedded analytics key on approved OPC client identities. Shared service accounts across hosts, or one OPC certificate reused by several applications, make these signals worthless. Give each polling application its own service account and certificate, record its owner, and review the list when integrators or vendor tools change. See the OT and ICS Identity and Access Guide.

How to implement

1. Inventory pollers. From passive monitoring and engineering records, list every host and application that reads each device family, with the protocols and address ranges it uses. See the OT Asset Visibility Guide.
2. Measure baselines. Capture normal poll rates per device across at least one full operating cycle, including shift changes and batch transitions.
3. Restrict in log mode first. Add conduit rules that permit only listed pollers, logging would-be denies for a period before enforcing, so a missed historian interface does not blind operators.
4. Deploy DET0727-style alerts in alert-only mode through at least one maintenance cycle, suppressing commissioning and asset inventory scans logged against change tickets.
5. Enforce and keep a rollback: record each rule change with the previous rule set so an unexpected loss of view can be reversed in minutes.
6. Review quarterly: reconcile the approved lists with actual traffic and with engineering change records.

Decision guidance

• Small sites: conduit firewall rules and removing internet exposure deliver most of the value; flow data (AN2169) is often enough to spot a new poller.
• Large or distributed sites: protocol-aware monitoring per zone, central allowlists and an OT SOC process are needed, because remote stations and telecontrol links multiply the pollers. See the OT Security Operations Centre Guide.
• Read-only remote monitoring requests: serve them from a DMZ replica rather than opening device access; reading is still T0801 if an attacker holds that access.

Responding to an unapproved poller

An unapproved reader is usually a sign of an earlier compromise and possibly of preparation for impact. Confirm with operations that the process is stable; do not shut down approved SCADA paths in reaction. Preserve packet captures, flow records, OPC and historian logs and the source host's process history. Block the source at the conduit rather than isolating supervisory systems operators depend on. Then investigate the source host and the identity it used, and check for follow-on writes or program changes on the devices it read. See the OT Incident Response Guide.

Detection and measurement

• Poller allowlist coverage: percentage of device families with a documented list of approved polling hosts and applications.
• Reachability: number of hosts able to reach field device protocol ports, tracked against the approved list.
• Baseline freshness: age of the measured poll rate baseline per zone.
• Protocol decoding coverage: percentage of control network segments monitored with decoding for the protocols in use.
• Unexplained pollers: count of new reading sources not matched to a change ticket, each investigated.

Framework mapping

Common failure patterns

• Read access treated as harmless: any host can poll any device because "it only reads", so an intruder gets full process visibility.
• Baselines guessed, not measured: thresholds set from configuration files fire constantly or never.
• Control ports exposed to the internet: the FrostyGoop case began with Modbus TCP reachable from outside.
• Shared historian and OPC identities: every client uses the same account or certificate, so a new reader looks approved.
• Monitoring without protocol decoding: flow data shows a connection but not which points were read or how often.

Practitioner checklist

• List approved polling hosts and applications per device family with control engineers.
• Measure poll rates and address ranges from real traffic, per device.
• Permit control protocol reads only from approved hosts at each conduit.
• Confirm no control protocol port is reachable from the internet.
• Serve business users from a DMZ historian replica.
• Give each polling application its own service account and OPC UA certificate.
• Deploy DET0727-style alerts in alert-only mode, then tune and enforce.
• Investigate every unexplained poller and check its targets for follow-on writes.

Standards and references

• MITRE ATT&CK for ICS: Monitor Process State (T0801)
• MITRE ATT&CK: Detection of Monitor Process State (DET0727)
• MITRE ATT&CK: Industroyer2 (S1072)
• ESET: Industroyer2: Industroyer reloaded
• Dragos: Protect Against FrostyGoop ICS Malware Targeting Operational Technology
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · OT Network Security Monitoring Guide · Modbus TCP and Modbus Security Guide · IEC 60870-5-104 Telecontrol Security Guide · OT and ICS Identity and Access Guide · T0802 Automated Collection · T0861 Point and Tag Identification · T0830 Adversary-in-the-Middle