ATT&CK for ICS Discovery Tactic Guide: Detecting and Containing Discovery in OT

Before an adversary can change a physical process they have to find the controllers that run it, and in a well-understood OT network that search is one of the most visible things they do. MITRE ATT&CK for ICS defines the Discovery tactic (TA0102) as the adversary "locating information to assess and identify their targets in your environment": surveying the network, the control system devices and how processes interact. Because industrial networks are small, stable and repetitive, a new host speaking an industrial protocol, a broadcast identity request or a sweep of TCP port 102 stands out far more than it would on an office network. This hub covers all 5 techniques and 3 sub-techniques under the tactic in ATT&CK v20, the procedures recorded for real ICS malware and campaigns, and the detection and network design choices that turn discovery into an early warning. It is for OT security engineers, network owners and SOC analysts. For the framework itself, see the MITRE ATT&CK for ICS Guide.

Key takeaways

• Discovery in OT speaks industrial protocols. Recorded procedures use Siemens S7 on TCP port 102, TriStation broadcasts on UDP port 1502, OPC UA on TCP port 4840, Omron FINS and Schneider multicast on UDP port 27127, not just generic ping sweeps.
• Remote System Information Discovery is the most used technique. T0888 has 6 procedure examples in the v20 dataset, and Remote System Discovery (T0846) and its Port Scan sub-technique have 5 each: adversaries want make, model, role and configuration, not just a host list.
• The recorded actors are malware and campaigns. All 25 procedure examples under the tactic come from 10 software entries and 2 campaigns, which reflects how much ICS discovery is automated inside purpose-built tooling.
• Static, deterministic networks are the main mitigation. Static Network Configuration (M0814) is mapped to 6 of the 8 technique entries and Network Segmentation (M0930) to 4; a fixed allowlist of who talks to whom makes any new conversation an alert.
• Passive monitoring is the best detector. Protocol-aware network monitoring sees identity requests, broadcasts and scans that host logs never record, and it does so without adding risk to fragile devices.

What Discovery means in an ICS environment

ATT&CK for ICS describes Discovery as the way adversaries learn the internal network, control system devices and how their processes interact, so they can select targets and plan Lateral Movement. The tactic description also notes that discovery is often an act of progression: adversaries move from one zone to the next and repeat it each time. That matters for defence because discovery tends to happen several times in one intrusion: once on the corporate side, again on reaching the OT DMZ or a SCADA server, and again on reaching the cell or safety network.

There are two kinds of question an adversary asks. The first is "what is here?" (Remote System Discovery, Network Connection Enumeration and the sniffing techniques). The second is "what exactly is this device and what does it control?" (Remote System Information Discovery), which in ICS often means reading device identity objects, module inventories or logical node lists through the industrial protocol itself.

How adversaries perform and chain Discovery

Counts in this section come from the official ATT&CK v20 ICS STIX data, counting non-revoked "uses" relationships from software, groups and campaigns to each technique in the tactic: 25 procedure examples from 10 software entries and 2 campaigns.

• Protocol-native scanning: PLC-Blaster finds other Siemens S7 PLCs by checking for a service on TCP port 102, and Industroyer's IEC 61850 component tries the same port across its subnet. INCONTROLLER can scan TCP port 4840 for OPC UA servers, use FINS to obtain MAC addresses of Omron devices, and send a UDP multicast scan on port 27127 to find Schneider PLCs. Triton used a Python script that sends a UDP broadcast on port 1502 to detect Triconex controllers.
• Device interrogation: Industroyer's IEC 61850 component sends MMS getNameList requests to learn which logical nodes a device supports; Industroyer2 polls IEC 104 devices for their common address and information object addresses; Backdoor.Oldrea collects OPC server details such as vendor, version and running state; Stuxnet parses System Data Blocks to confirm it has found the configuration it was built for.
• Living off the land: in the 2025 Poland Wiper Attacks the adversaries used netstat on HMI computers, nslookup, ping and arp, and commercial IP and port scanners, then ran PsExec to gather process and connection information from remote systems. In the 2015 Ukraine Electric Power Attack, Sandworm Team remotely discovered operational assets once on the OT network.
• Passive capture: INCONTROLLER can deploy tcpdump to collect PCAP files, and VPNFilter's sniffer looked for basic authentication and ICS traffic on compromised routers.

The output of discovery feeds three later steps directly: choosing which controllers to target, choosing the protocol and engineering function to use (see Execution and Lateral Movement in ATT&CK for ICS), and harvesting credentials seen in cleartext. The ICS Malware History Guide covers the families named above.

All Discovery techniques in ATT&CK for ICS v20

Wireless Sniffing (T0887) is also listed under Collection. It covers radio frequency links used for remote control and reporting in distributed environments; ATT&CK notes that frequencies range from 3 kHz to 300 GHz but are commonly between 300 MHz and 6 GHz.

Which techniques matter most for defenders

• Remote System Information Discovery (T0888): the highest-value signal. A device identity read, module inventory request or MMS name list from a host that is not the engineering workstation or the asset inventory tool is rarely benign, and it indicates an adversary is choosing targets.
• Remote System Discovery and its sub-techniques (T0846): broadcasts (EtherNet/IP ListIdentity, Modbus, TriStation) and multicast queries reach every device on a segment. Segmentation limits how far they travel, and static configuration makes the sender stand out.
• Network Sniffing (T0842): many industrial protocols carry no encryption, so a capture on the right switch port yields commands, set points and credentials. This is where Encrypt Network Traffic (M0808), MFA (M0932) and Privileged Account Management (M0926) apply.
• Network Connection Enumeration (T0840): ATT&CK maps only M0816, so it is a detection problem: netstat and similar commands on HMIs and SCADA servers by unusual accounts.

Detection priorities

Every technique in the tactic has an ATT&CK v20 detection strategy. Most of them name network traffic content from a network security monitoring sensor first and host process creation second.

The common thread is source allowlisting: in a typical cell only a handful of hosts (engineering workstations, the historian, the asset inventory platform and the SCADA servers) should ever send identity, inventory or broadcast requests to controllers. Build that list once and every discovery analytic becomes a simple "source not in list" rule. CISA's open-source ICSNPP parsers add Zeek visibility into protocols such as S7comm, EtherNet/IP and CIP, OPC UA Binary, BACnet and Omron FINS. See the OT Network Security Monitoring Guide and the Industrial Protocol Security Guide.

Mitigation priorities across the tactic

See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide for zone design.

Defenders doing discovery safely

Defenders need the same information an adversary seeks, and the better the defender's own inventory, the less novel the adversary's discovery looks. The joint CISA-led guidance Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators (August 2025) lists high-priority attributes for each asset, including supported communication protocols, asset criticality, role or type, IP and MAC address, manufacturer, model, operating system, ports and services, logging and user accounts. Gathering these mostly from passive traffic capture and engineering project files, and running any active queries from a fixed, documented inventory host during agreed windows, lets SOC rules treat every other source of identity requests as suspicious. Active scanning of fragile field devices can disrupt them, so test any active method on spare or lab equipment first. See the OT Asset Visibility Guide.

Where identity fits

Discovery is partly an identity problem in OT. Network Sniffing is aimed at login information as well as process data, and VPNFilter specifically looked for basic authentication. Cleartext Telnet, FTP, HTTP and vendor protocols expose passwords for shared engineering and service accounts that rarely change. Treat any credential seen in cleartext on an OT network as exposed: move the account to an authenticated, encrypted channel where the device supports it, rotate it, and give each integrator or service its own account. The asset inventory attribute "user accounts" is the starting point. See the OT and ICS Identity and Access Guide.

How to implement coverage

1. Build the communication baseline: deploy passive sensors on SPAN or TAP ports at each zone boundary and core cell switch, and record which hosts talk to which devices with which protocol and function codes over a full operating cycle.
2. Write the approved-source list: name the engineering workstations, historians, SCADA servers and inventory hosts allowed to send identity, inventory, broadcast and multicast requests.
3. Turn on the rules in alert-only mode: start with port sweeps across industrial ports, identity reads and broadcasts from unlisted sources, new SPAN sessions and capture drivers. Tune for two to four weeks against maintenance activity.
4. Tighten the network: apply static configuration and segmentation so broadcasts and multicasts stay inside cells, and block industrial protocols across conduits except approved flows. Change one zone at a time, with a rollback plan to restore the previous firewall rule set.
5. Harden hosts: restrict who can run scanners, capture tools and PsExec on OT Windows hosts, and log process creation with command lines.
6. Test: during a maintenance window, run an approved discovery from an unlisted laptop on a test segment and confirm alerts reach the SOC with enough context to triage.

Small sites versus large estates: a single site can start with one passive sensor on the core switch and a short approved-source list. Large estates should standardise sensor placement per site and feed one detection rule set, so a discovery alert means the same thing everywhere.

Detection and measurement

• Sensor coverage: percentage of OT zones and cells with passive monitoring of east-west industrial traffic.
• Baseline completeness: percentage of controllers whose normal communication partners are documented and in the approved-source list.
• Unexplained discovery events: count per month of identity reads, broadcasts or port sweeps from unlisted sources, with time to triage.
• Cleartext credential exposure: number of accounts observed authenticating in cleartext on OT networks, trending down.
• Inventory accuracy: percentage of devices seen on the wire that already exist in the asset inventory.

Common failure patterns

• Flat cell networks: one large layer 2 segment lets a single broadcast or multicast query enumerate every controller on the site.
• Monitoring only the IT/OT boundary: a sensor at the firewall misses discovery that starts from a compromised HMI inside the cell.
• Uncontrolled defender scanning: unscheduled scans by IT tools both risk device disruption and train analysts to ignore scan alerts.
• No approved-source list: without one, every identity read looks like normal engineering activity and nothing alerts.
• Ignoring SPAN changes: switch mirror sessions created outside change control give an adversary a full copy of process traffic.

Framework mapping

NIST SP 800-82 Rev. 3 gives the OT overlay for these controls. For zone-based requirements see the IEC 62443 Guide.

Practitioner checklist

• Deploy passive, protocol-aware monitoring inside cells, not only at the IT/OT boundary.
• Document the approved sources of identity, inventory, broadcast and multicast requests per zone.
• Alert on industrial port sweeps, identity reads and broadcasts from any other source.
• Alert on new SPAN or mirror sessions and on packet capture drivers on undesignated hosts.
• Keep broadcasts and multicasts inside small segments and block industrial protocols across conduits except approved flows.
• Run defender inventory from a fixed host in agreed windows, test active methods in a lab first.
• Find and retire cleartext credentials on OT networks, and rotate any seen on the wire.
• Restrict scanners, capture tools and remote execution utilities on OT hosts.

Standards and references

• MITRE ATT&CK: Discovery, Tactic TA0102 (ICS)
• MITRE ATT&CK: Remote System Information Discovery (T0888)
• MITRE ATT&CK: Remote System Discovery (T0846)
• CISA, DOE, NSA and FBI: APT Cyber Tools Targeting ICS/SCADA Devices (AA22-103A)
• CISA and partners: Foundations for OT Cybersecurity, Asset Inventory Guidance for Owners and Operators
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• CISA: ICSNPP, Industrial Control Systems Network Protocol Parsers
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · OT Network Security Monitoring Guide · OT Asset Visibility Guide · Industrial Protocol Security Guide · OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide