Point & Tag Identification (T0861) is an adversary collecting the names and values of a process's points and tags so they can work out which value controls which piece of equipment. Points are inputs, outputs, memory locations and other process variables; tags are the human-readable names given to them, such as a pump status or a tank level. With the tag list an adversary can map the process and choose what to watch and what to change. MITRE ATT&CK for ICS lists T0861 under Collection for Embedded, Windows, Linux and Network Devices platforms. This guide is for OT security engineers and OT SOC analysts: where tag data lives, what Backdoor.Oldrea and INCONTROLLER did, how ATT&CK's v20 analytics separate enumeration from normal polling, and how to restrict it. For collection techniques in context see the MITRE ATT&CK for ICS Guide.
Key takeaways
- Tags are a map of the plant. ATT&CK notes tag collection lets an adversary map inputs, outputs and other values to their control processes.
- OPC is the usual route. Both ATT&CK procedure examples for T0861 used OPC: Backdoor.Oldrea enumerated OPC tags and INCONTROLLER read OPC UA structure.
- Breadth is the signal. Legitimate SCADA polling reads a fixed, sparse set of tags; ATT&CK's analytic looks for a full walk of the namespace from a source not on the approved list.
- Do not alert on reads alone. ATT&CK's gate suppresses normal HMI, historian, inventory, backup and engineering activity, and alerts only when the source role and scope break the baseline.
- Treat tag data as confidential. ATT&CK's Authorization Enforcement mitigation asks systems to restrict access to point and tag information.
Where point and tag data lives
| Location | What it holds | How it can be read |
|---|---|---|
| OPC UA and OPC Classic servers | The address space or namespace: nodes, tag names, descriptions and live values | Browse and read services by any client the server accepts |
| Controllers | Tag databases and data tables in the controller program | Controller protocols that return object or attribute lists, and program upload |
| HMI and SCADA servers | Tag configuration that links screens to points | Project and configuration files on the server |
| Historians | Tag lists with long-term values | Historian client interfaces and database queries |
| Engineering workstations | Project files with full tag databases and comments | File access on the workstation or backups |
The network routes are the subject of this technique. File-based routes overlap with Program Upload (T0845) and with Theft of Operational Information (T0882), which are separate techniques. See the OPC UA Security Guide and the OPC Classic and DCOM Hardening Guide.
The procedure examples and what they teach
- Backdoor.Oldrea (S0093): ATT&CK describes it as a modular backdoor used by Dragonfly against energy companies since at least 2013, distributed through supply chain compromise, with modules to enumerate ICS systems and protocols. For T0861, ATT&CK records that its payload could enumerate OPC tags as well as general OPC server information, and that server data and tag names can reveal the names and functions of control devices. See the Berserk Bear Threat Actor Profile Guide.
- INCONTROLLER (S1045): ATT&CK records that it can remotely read OPC UA structure from devices. The joint advisory AA22-103A (DOE, CISA, NSA and FBI, April 2022) describes a tool that identifies OPC UA servers, connects using default or previously compromised credentials, reads the server's structure and can potentially write tag values, and maps it to Point & Tag Identification. The advisory notes that a proper OPC UA security configuration can significantly reduce this threat.
Both cases point at the same control: an OPC server that accepts any client, or default credentials, hands over the plant map.
Detection: ATT&CK v20 analytics
MITRE's v20 detection strategy for T0861 has four analytics. All share ATT&CK's OT operational fidelity gate: do not alert on novelty, read volume or enumeration alone; alert when the source role is not authorised for discovery or polling and the target scope, tag range, protocol or rate departs from the operational baseline; suppress normal SCADA, HMI and historian polling, commissioning, asset inventory, backup, diagnostics and approved engineering work.
| Where | What the analytic looks for | Data needed |
|---|---|---|
| Network content | OPC UA namespace browsing, a DNP3 read of all object variations, or a CIP Get_Attributes_All request, from a source not on the approved SCADA server list, covering most of a device's tag space | OT protocol decoding at the controller and server conduits |
| Windows OT hosts | An OPC client process that is not a recognised HMI or historian tool browsing the full tag tree | OPC server or client application logs |
| Linux OT hosts | An OPC UA client browsing the full namespace from a user identity not tied to recognised monitoring tools | OPC UA request decoding or server logs |
| Network flow | One source connecting in sequence to many field devices, each returning large responses typical of directory listings rather than value reads | NetFlow or IPFIX from OT segments |
The baseline is what makes these work. Record which clients normally browse each server (usually engineering tools during commissioning) and which only read a fixed tag set (HMIs and historians). An HMI that suddenly browses, or a new client that browses everything, is the event. See the OT Network Security Monitoring Guide.
Prevention: ATT&CK mitigations in practice
| ATT&CK mitigation | What ATT&CK says for T0861 | How to apply it |
|---|---|---|
| M0800 Authorization Enforcement | Restrict access to data with confidentiality concerns, including point and tag information | Use OPC UA user roles and node permissions so only engineering roles can browse the full namespace |
| M0801 Access Management and M0804 Human User Authentication | Authenticate all access to field controllers and all management sessions | Disable anonymous access on OPC UA servers; replace default credentials |
| M0813 Software Process and Device Authentication | Devices should authenticate messages between master and outstation assets | OPC UA application certificates with an explicit trust list, as AA22-103A recommends |
| M0802 Communication Authenticity | Control protocols should provide authenticity; otherwise use bump-in-the-wire devices or VPNs | Signed OPC UA security modes; VPNs for legacy links |
| M0807 Network Allowlists | Devices accept connections only from master stations or known engineering workstations | Allowlist OPC and controller clients at each server and conduit |
| M0937 Filter Network Traffic | Inline allowlisting of automation protocol commands, designed accurately enough not to block valid messages | Where a protocol-aware firewall exists, permit read services from HMIs and block browse or enumeration services from them |
| M0930 Network Segmentation | Segment assets by functional role, with stricter isolation for more critical information | Keep OPC servers that expose the full namespace out of reach of the enterprise network |
Where identity fits
OPC UA clients are non-human identities: application instance certificates and service accounts on HMIs, historians and integration tools. AA22-103A notes the tooling used default or previously compromised credentials. Give each client its own certificate and account with only the node access it needs, keep the trust list short, and remove clients when integrations are retired. See NHIs in OT.
How to implement
- List tag sources. Inventory every OPC server, historian and controller that exposes a browsable tag space, and who connects to each.
- Baseline clients. Using monitoring data from a normal operating period, record which clients browse and which read fixed sets.
- Tighten OPC configuration. Turn off anonymous access, require signed security modes and set an explicit certificate trust list, testing each server with its clients before enforcing. Keep the previous configuration for rollback.
- Restrict browse rights. Limit full browsing to engineering roles; give HMIs and historians read access to their tags.
- Allowlist at the conduit. Permit OPC and controller protocols only from known clients; start in log-only mode.
- Turn on the analytics. Alert on full-namespace walks from sources outside the browse baseline, with the ATT&CK gate applied.
Decision guidance
- Node permissions or network allowlists: allowlists are quicker to deploy and protect servers that cannot set fine-grained permissions; node permissions limit damage from an approved client that is compromised. Larger estates need both.
- Protocol-aware filtering: worth it on conduits to critical controllers; ATT&CK warns that rules must be accurate enough not to block valid messages, so tune in monitor mode first.
- Small sites: disabling anonymous OPC access and changing default credentials removes the easiest route.
Responding to unexplained tag enumeration
- Treat it as early-stage reconnaissance. Enumeration usually precedes manipulation, so raise priority on other alerts from the same source.
- Identify the client. Find the host, process and account behind the session and confirm with engineering whether it was planned.
- Preserve evidence. Keep OPC server logs, network captures and host logs from the source.
- Contain without disrupting operations. Revoke the client's certificate or account, or block it at the conduit, after operations confirms nothing legitimate depends on it.
- Look for writes. Check for writes to the tags that were enumerated, since INCONTROLLER's OPC UA tooling could potentially write tag values.
See the OT Incident Response Guide.
Detection and measurement
- Anonymous access: number of OPC servers accepting anonymous or default-credential sessions (target zero).
- Trust list coverage: percentage of OPC UA servers enforcing an explicit certificate trust list.
- Browse baseline: percentage of tag sources with a documented list of clients allowed to browse.
- Monitoring coverage: percentage of OPC and controller conduits with protocol decoding.
- Triage time: median time to attribute an enumeration alert to a person and purpose.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK for ICS | T0861; related T0845, T0882, T0801 | Collection of tag data and what usually follows |
| NIST SP 800-53 Rev. 5 | AC-3, AC-6, IA-3, SC-7, SI-4 | Access enforcement, least privilege, device authentication, boundary protection, monitoring |
| NIST CSF 2.0 | PR.AA-05, PR.IR-01, DE.CM-01 | Authorisations, protection from unauthorised logical access, network monitoring |
| NIST SP 800-82 Rev. 3 | OT guidance | Applying the controls above in OT |
Common failure patterns
- Anonymous OPC access left on after commissioning. Any client can browse the whole plant.
- Trusting every certificate. An OPC UA server set to accept all client certificates gives encryption without access control.
- Alerting on every browse. Without the baseline, engineering activity floods the SOC and real enumeration is ignored.
- Forgetting project files and backups. The network is locked down but full tag databases sit on shared drives.
Practitioner checklist
- Inventory every OPC server, historian and controller with a browsable tag space.
- Disable anonymous OPC access and replace default credentials.
- Enforce signed OPC UA modes and an explicit certificate trust list.
- Limit full browse rights to engineering roles; give HMIs and historians read access only.
- Allowlist OPC and controller clients at each conduit.
- Baseline browsing clients and alert on full-namespace walks from others.
- Protect project files and backups that contain tag databases.
Standards and references
- MITRE ATT&CK for ICS: Point & Tag Identification (T0861)
- MITRE ATT&CK: Backdoor.Oldrea (S0093)
- MITRE ATT&CK: INCONTROLLER (S1045)
- CISA, DOE, NSA and FBI: AA22-103A APT Cyber Tools Targeting ICS/SCADA Devices
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- MITRE ATT&CK for ICS: Authorization Enforcement (M0800)
Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · OPC UA Security Guide · OPC Classic and DCOM Hardening Guide · HMI and SCADA Server Hardening Guide · OT Network Security Monitoring Guide