Remote System Discovery (T0846) is an adversary building a list of the controllers, HMIs, servers and field devices on a control network so they can choose what to reach next. Industrial networks make this easier than IT networks in some ways: devices are long-lived, addressing is often static, and several automation protocols answer discovery requests from any host on the segment. MITRE ATT&CK for ICS lists T0846 under Discovery for Embedded, Windows, Linux and Network Devices platforms, and in v20 it has three sub-techniques: Port Scan, Broadcast Discovery and Multicast Discovery. This guide is for OT security engineers and OT SOC analysts: the procedure examples ATT&CK records, how to tell adversary discovery from your own asset inventory, the v20 analytics and safe response. For the wider matrix see the MITRE ATT&CK for ICS Guide, and for building your own inventory the OT Asset Visibility Guide.
Key takeaways
- Discovery precedes most OT attacks. ATT&CK records Sandworm Team remotely discovering operational assets once on the OT network during the 2015 Ukraine Electric Power Attack.
- OT protocols have discovery built in. ATT&CK names BACnet Who-Is, CIP List Identity, Siemens S7 broadcast identification and PROFINET DCP Identify All as discovery mechanisms adversaries can use.
- ICS-aware tooling exists. ATT&CK records Industroyer enumerating OPC servers, Backdoor.Oldrea using Windows networking to find OPC servers, and INCONTROLLER scanning Omron devices over FINS.
- Your own scanning looks identical. The v20 analytics alert only on discovery from sources and tools outside an approved list, so the inventory of who may scan is the control.
- Static configuration reduces exposure. ATT&CK's mitigation is to minimise IT discovery protocols and the discovery functions in automation protocols.
What T0846 covers and its sub-techniques
ATT&CK for ICS describes T0846 as adversaries attempting to get a listing of other systems by IP address, hostname or other logical identifier for subsequent Lateral Movement or Discovery, using adversary tools, operating system utilities or vendor software. The Enterprise equivalent is T1018; see the T1018 Remote System Discovery guide for the host-side detail.
| Sub-technique | How ATT&CK describes it | OT examples ATT&CK names |
|---|---|---|
| T0846.001 Port Scan | Scanning a system, device or network to identify live hosts, open ports and services and operating systems; results inform discovery, lateral movement and exploitation decisions | Common tools named include nmap, netcat and Advanced Port Scanner |
| T0846.002 Broadcast Discovery | Sending a message to every system on a network or subnet and waiting for responses | BACnet Who-Is, CIP List Identity UDP broadcast, Siemens S7 broadcast identification |
| T0846.003 Multicast Discovery | Sending a message to a predefined group and waiting for responses; quieter than broadcast because not every device is messaged | PROFINET DCP Identify All |
Two neighbouring techniques have their own pages: Remote System Information Discovery (T0888), which gathers detail about a device once found, and Network Connection Enumeration (T0840), which reads a host's existing connections.
Procedure examples in ATT&CK
| Example | What ATT&CK records | Lesson for defenders |
|---|---|---|
| 2015 Ukraine Electric Power Attack (C0028) | Sandworm Team remotely discovered operational assets once on the OT network | Monitoring inside the control network, not only at the IT boundary, is what sees this step |
| Industroyer (S0604) | An OPC DA module enumerates OPC servers by category and checks which are running | Discovery can use legitimate OPC interfaces on a compromised server, with no scanning traffic |
| Backdoor.Oldrea (S0093) | Uses Windows networking (WNet) to discover all servers, including OPC servers, reachable from the compromised machine | Hosts that can reach many OPC servers are high-value; restrict what each can see |
| INCONTROLLER (S1045) | Can use the FINS protocol to scan for Omron devices and obtain their MAC addresses | Protocol-aware monitoring should flag device scans from non-engineering sources |
| 2025 Poland Wiper Attacks (C0063) | The adversaries used nslookup and ping for remote system discovery | Built-in tools are enough; the account and host context is the signal |
Two sources add detail. ESET's Industroyer analysis describes its IEC 61850 payload deriving target addresses from the host's own subnet masks and trying each on port 102, and a custom port scanner run against operator-specified address and port ranges. CISA advisory AA22-103A describes the Schneider component of the INCONTROLLER tools rapidly scanning for Schneider PLCs on the local network using UDP multicast to port 27127, and the Omron component scanning over FINS. CERT Polska's report on the December 2025 Poland incidents records Advanced Port Scanner and Advanced IP Scanner on the combined heat and power plant network, and network scanning logged on remote terminal units days before the destructive attack.
Telling adversary discovery from your own
Defenders discover assets too, and the methods matter for both safety and detection:
| Approach | How it works | Safety and detection notes |
|---|---|---|
| Passive monitoring | Analyses mirrored traffic from SPAN ports, TAPs or uplinks without touching devices | Suits fragile OT devices; only sees devices that talk during the capture window, typically 24 to 72 hours per CSIAC |
| Unauthenticated active scanning | Probes ports or sends protocol discovery requests | CSIAC warns many OT products are fragile and may not withstand scanning; use OT-aware tools, approved windows and named sources |
| Authenticated active queries | Logs in to devices to read software and configuration detail | Uses privileged credentials, which must be managed as non-human identities |
Whatever you choose, register every approved scanning source, tool and schedule. That register is the allowlist the v20 analytics depend on. Unapproved scanning of OT should also be prohibited in policy, since it creates process risk regardless of intent. See the OT Penetration Testing Guide for safe testing practice.
Detection: ATT&CK v20 analytics
MITRE's v20 detection strategy for T0846 (DET0739) has four analytics, with ATT&CK's OT operational fidelity gate: do not alert on scan volume or novelty alone; alert when the source is not authorised for discovery and the scope, protocol or rate departs from the baseline; suppress SCADA, HMI and historian polling, commissioning, asset inventory and approved engineering work.
| Platform | What the analytic looks for | Data needed |
|---|---|---|
| Windows | Network discovery tools or ICS-specific scanners run on an ICS host from a process not associated with recognised network management or engineering tools | Sysmon Event ID 1 process creation |
| Linux | Network discovery tools run on an ICS Linux asset by a UID that does not normally scan | Linux audit execve records |
| Embedded | ICS discovery broadcasts or sequential connection attempts across a device subnet from a source not in the approved engineering and SCADA inventory; ATT&CK cites EtherNet/IP ListIdentity broadcasts and the INCONTROLLER toolset's CODECALL module | IPFIX or NetFlow; protocol-aware network content inspection |
| Network devices | ICMP echo sweeps, ARP broadcast floods or ICS discovery packets to every address in a subnet in sequence, unlike normal traffic to known device addresses | IPFIX or NetFlow from OT switches and firewalls |
The tunable inputs are approved SCADA and engineering sources, authorised network tools and a discovery time window. Because OT traffic is highly regular, a host contacting addresses it has never contacted before is usually visible quickly. See the OT Network Security Monitoring Guide.
Prevention and hardening
- M0814 Static Network Configuration: ATT&CK advises that ICS environments typically have more statically defined devices, so minimise IT discovery protocols such as DHCP and LLDP and the discovery functions in automation protocols, naming OPC UA device discovery, BACnet and EtherNet/IP as examples. Disable those functions where the device and operations allow, after testing.
- Segmentation and filtering: block broadcast and multicast discovery from crossing zones, and allow scanning only from approved sources. CISA's AA22-103A recommends limiting ICS network connections to specifically allowed management and engineering workstations. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
- Remove internet exposure: CISA, FBI, EPA and DOE list removing OT connections to the public internet first among their primary mitigations, which stops discovery from outside entirely.
- Limit host reach: an HMI that can only reach its own controllers yields a short list when it is compromised.
Where identity fits
Two identity points matter. Authenticated discovery tools hold credentials that can log in to many devices, so treat their service accounts as privileged non-human identities with vaulting, rotation and narrow scope. And CERT Polska's Poland report records HMIs left with default local administrator passwords that were used to log in over Remote Desktop. See the OT and ICS Identity and Access Guide.
How to implement
- Register approved discovery: monitoring sensors, inventory tools, engineering software and their schedules.
- Collect flow and protocol data inside control zones, not only at the IT and OT boundary.
- Deploy DET0739-style analytics in alert-only mode through a full maintenance cycle, then tune.
- Reduce discovery surface: disable unneeded discovery protocols and block broadcast and multicast discovery between zones, one cell at a time with operations, recording previous settings for rollback.
- Promote alerts to the OT SOC with a playbook. See the OT Security Operations Centre Guide.
Responding to discovery activity
Confirm the source against the register. If it is not approved, do not answer with your own active scanning of the control network. Preserve flow records, protocol logs and the source host's process history. Contain by restricting the source host at the conduit in agreement with operations, then investigate how it was compromised and which devices responded, since those are the likely next targets. Check those devices for configuration or program changes. See the OT Incident Response Guide.
Detection and measurement
- Register completeness: percentage of observed discovery sources that are in the approved register.
- Visibility inside zones: percentage of control zones with flow or protocol monitoring.
- Discovery surface: number of devices answering broadcast or multicast discovery from outside their zone.
- Time to triage: median time from a discovery alert to source confirmation.
- Unexplained sweeps: count of sweeps from unapproved sources, each with a finding.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| MITRE ATT&CK for ICS v20 | T0846, T0846.001, T0846.002, T0846.003; M0814; DET0739; related T0840, T0888 | Technique, sub-techniques, mitigation and analytics |
| MITRE ATT&CK Enterprise v20 | T1018 Remote System Discovery | Host-level equivalent |
| MITRE D3FEND | D3-NTA Network Traffic Analysis, D3-CAA Connection Attempt Analysis, D3-BDI Broadcast Domain Isolation | Defensive techniques relevant to detecting sweeps and limiting broadcast reach |
| NIST SP 800-53 Rev. 5 | SI-4 System Monitoring, SC-7 Boundary Protection, CM-7 Least Functionality, CM-8 System Component Inventory | Monitoring, segmentation, disabling discovery functions, maintaining the approved inventory |
| NIST CSF 2.0 | ID.AM-01, DE.CM-01, PR.IR-01 | Asset inventory, network monitoring, network protection |
Common failure patterns
- Monitoring only at the boundary: sweeps inside the control network are never seen.
- No register of approved scanners: every sweep is either alerted and ignored or never alerted.
- Discovery protocols left on everywhere: any host on the segment can list every device.
- Ad hoc active scanning by staff or contractors: risks the process and hides adversary scans.
- Default credentials behind discovery: a device list becomes a login list.
Practitioner checklist
- Maintain a register of approved discovery sources, tools and schedules.
- Collect flow and protocol data inside control zones.
- Alert on sweeps and ICS discovery broadcasts from unapproved sources.
- Disable unneeded DHCP, LLDP and automation protocol discovery functions after testing.
- Block broadcast and multicast discovery between zones.
- Manage credentials used by authenticated discovery tools as privileged NHIs.
- Prohibit unapproved active scanning of OT in policy.
- Check devices that responded to unapproved discovery for changes.
Standards and references
- MITRE ATT&CK for ICS: Remote System Discovery (T0846)
- MITRE ATT&CK: Detection of Remote System Discovery (DET0739)
- MITRE ATT&CK: 2015 Ukraine Electric Power Attack (C0028)
- CISA and partners: AA22-103A, APT Cyber Tools Targeting ICS/SCADA Devices
- ESET: Win32/Industroyer, A new threat for industrial control systems
- CERT Polska: Energy Sector Incident Report, 29 December
- CSIAC: Practical Industrial Control System (ICS) Cybersecurity, Discover and Defend Your Assets
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · OT Asset Visibility Guide · T1018 Remote System Discovery · OT Network Security Monitoring Guide · Sandworm Threat Actor Profile