T0888 Remote System Information Discovery: Spotting Controller Reconnaissance in OT

Remote System Information Discovery (T0888) is how an adversary learns the make, model, role and configuration of a controller before deciding what to do to it. In OT this reconnaissance uses the same automation and management protocols that vendor software queries every day, which is why it blends in. ATT&CK for ICS records it in some of the most significant ICS malware: Stuxnet checking for specific PLC and drive types, Industroyer and Industroyer2 enumerating substation devices, and INCONTROLLER requesting Modbus device IDs. This guide is for OT security engineers and SOC analysts: what the technique looks like on the wire, how to separate it from legitimate polling, how to reduce what devices give away, and how to respond. For the matrix as a whole see the MITRE ATT&CK for ICS Guide.

Key takeaways

• Identity queries are targeting decisions. ATT&CK notes that a device's role and model can decide whether it is a relevant target, and its configuration can scope what the adversary does next.
• The traffic is normal; the source is not. Device identification requests are routine from engineering software, so detection hinges on which host is asking and whether that role should.
• Ask for metadata, not process values. ATT&CK's embedded analytic looks for queries of module inventories, identity objects and device attributes from sources that are not approved SCADA servers.
• Static networks are easier to defend. The ATT&CK mitigation, Static Network Configuration (M0814), is to minimise IT discovery protocols and the discovery functions of automation protocols.
• Discovery precedes impact. In the ATT&CK examples, information discovery came before commands to circuit breakers and drives, so an alert here is an early warning worth acting on.

What T0888 covers and how it differs from nearby techniques

ATT&CK for ICS v20 (page last modified 13 October 2026) describes T0888 as getting detailed information about remote systems and their peripherals, such as make and model, role and configuration, to aid targeting and shape follow-on behaviour. It applies to Embedded, Windows, Linux and Network Devices platforms. ATT&CK points out that such requests are typically made with automation and management protocols and are often sent automatically by vendor software, which uses the answers to tailor actions such as program download and firmware updates. An adversary can make the same calls directly.

For the IT equivalents see T1018 Remote System Discovery and T1082 System Information Discovery.

The procedure examples and what they teach

ATT&CK v20 records six procedure examples. Each is summarised only as ATT&CK or the cited source states it.

ESET's analysis adds that Industroyer2, deployed against Ukrainian high-voltage substations in April 2022 and attributed by ESET to Sandworm with high confidence, carried a configuration hardcoded for its targets, including device IP addresses and information object addresses. That depth of target knowledge comes from earlier discovery. The CERT Polska report on the 29 December 2025 attacks lists the PsExec reconnaissance at a combined heat and power plant, with output written to a single file. For history of these families see the ICS Malware History Guide.

Detection: ATT&CK's analytics with the OT fidelity gate

ATT&CK v20's detection strategy for T0888 has four analytics. Their shared 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, address 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.

To make the embedded analytic work you need two lists: the hosts allowed to issue identification and configuration requests (engineering workstations, asset inventory sensors, named SCADA servers) and the hosts that only read process values. Passive OT monitoring that decodes S7, CIP, Modbus, IEC 61850 and IEC 104 can then flag a metadata query from the wrong list. See the OT Network Security Monitoring Guide and the OT Security Operations Centre Guide.

Prevention: give away less, to fewer hosts

1. Use static configuration (M0814). ATT&CK advises minimising IT discovery protocols such as DHCP and LLDP and discovery functions in automation protocols, naming OPC UA device discovery, BACnet and EtherNet/IP as examples with discovery features. Turn off what operations do not use, one cell at a time.
2. Restrict who can talk to controllers. Allow engineering and management protocols only from named engineering workstations and SCADA servers at the zone conduit; HMIs that only read values should not be able to send configuration queries if the firewall can tell the difference. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
3. Harden the engineering workstation. Stuxnet ran its checks through the vendor library on the engineering host, so that host is the most valuable vantage point. See the Engineering Workstation Security Guide.
4. Lock down SNMP and remote management. Limit SNMP to the management subnet, prefer SNMPv3 where devices support it, and limit WinRM, WMI and SSH on OT hosts to the management jump host.
5. Run your own discovery on purpose. A sanctioned passive asset inventory gives you the baseline for the detection gate and removes the excuse for ad hoc active scans. See the OT Asset Visibility Guide.

Testing and rollback: before disabling a discovery feature, confirm with the control system vendor that engineering software and redundancy functions do not depend on it; change one cell during a maintenance window, keep the prior device configuration backup, and verify HMI and historian data before moving on.

Decision guidance

Safe response

• Identify the asking host first: check whether it was a commissioning laptop, a vendor tool or an inventory sensor before escalating.
• If it is not explained, assume targeting: review which devices were queried, then check those controllers' programs, firmware versions and operating modes against known-good backups.
• Contain the source, not the targets: isolate the querying host at its conduit, in agreement with operations, rather than taking controllers offline.
• Preserve evidence: packet captures of the queries, monitoring alerts, process creation logs and the account used on the source host.

The OT Incident Response Guide covers coordination with operations and safety.

Where identity fits

The Windows and Linux analytics both hinge on the account doing the asking. Shared engineering logins, vendor support accounts and service accounts used by inventory and historian software should be individually named, limited to the hosts they need and reviewed, so an unexpected account stands out. See the Identity for OT Environments Guide.

Metrics that show it is working

• Percentage of controllers whose engineering ports are reachable only from named engineering hosts.
• Number of hosts authorised to issue identification queries, kept as small as practical and reviewed quarterly.
• Percentage of OT zones covered by protocol-aware passive monitoring.
• Identification-query alerts per month from unapproved sources, and median time to explain each.
• Percentage of cells where unused discovery protocols have been disabled.

Framework mapping

Common failure patterns

• Any host can query any controller: flat level 2 and 3 networks let a compromised HMI ask a PLC for its full module inventory.
• Alerting on every scan: without the role-based gate, routine polling floods the queue and real reconnaissance is lost.
• Discovery features left on by default: protocols with device discovery stay enabled in cells that never use them.
• Unmonitored engineering workstations: process creation and remote management on the one host that can talk to every controller go unlogged.
• Shared engineering accounts: when everyone uses the same login, a query from an attacker looks like a query from an engineer.

Practitioner checklist

• List the hosts allowed to send identification and configuration queries to controllers.
• Enforce that list at zone conduits and on host firewalls.
• Deploy ATT&CK's four T0888 analytics with the role-based fidelity gate.
• Disable unused discovery protocols and functions, cell by cell, with vendor confirmation.
• Restrict SNMP to the management subnet and remote management to the jump host.
• Log process creation and remote management on engineering workstations and SCADA servers.
• Replace shared engineering and vendor logins with named accounts.
• On an unexplained query, verify the targeted controllers against known-good backups.

Standards and references

• MITRE ATT&CK for ICS: T0888 Remote System Information Discovery
• MITRE ATT&CK for ICS: M0814 Static Network Configuration
• MITRE ATT&CK: S1072 Industroyer2
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• ESET: Industroyer2, Industroyer reloaded
• CERT Polska: Energy Sector Incident Report 2025

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · OT Asset Visibility Guide · Engineering Workstation Security Guide · OT Network Security Monitoring Guide · ICS Malware History Guide