T0846.003: Multicast Discovery
Adversaries may perform multicast discovery requests which is when one system or device sends messages to all systems and devices in a pre-defined group on a network (or subnet) and then waits for a response. If a response is received that means the system or device that responded is live and can communicate over that protocol. Multicast discovery tends to be stealthier than broadcast discovery because every system or device on the network (or subnet) is not being messaged.
One common OT protocol that has a multicast discovery mechanism is the Process Field Network (PROFINET) Discovery and Configuration Protocol (DCP) with its Identify All requests.[1]
Analyst context for executives and security teams
Multicast Discovery matters in ICS because it can let an actor quietly learn which control-system devices are reachable without noisy whole-subnet broadcast scanning. For executives and OT security leaders, the business issue is not the discovery packet alone; it is whether an unauthorized system can enumerate HMIs, PLCs, RTUs, controllers, gateways, historians, jump hosts, VPN servers, and network infrastructure inside operational networks. That visibility can shape later movement or targeting decisions, especially in environments where discovery protocols such as PROFINET DCP are expected during engineering or maintenance activity.
Executive priority
Prioritize this as an OT network visibility and segmentation validation issue. Leaders should ask whether multicast discovery is limited to authorized engineering paths, whether critical process-control segments are isolated from enterprise and remote-access networks, and whether the SOC can distinguish normal engineering discovery from unexpected enumeration. This also supports audit and resilience evidence: asset boundaries, approved discovery sources, static network configuration where feasible, and documented exceptions for protocols that require discovery.
Technical view
ATT&CK provides no tactic, platform, or detection text for this sub-technique, so defensive validation should be environment-driven. SOC and IR teams should confirm whether DET0909-style detection of multicast discovery is implemented for ICS network traffic, especially protocol-specific discovery such as PROFINET DCP Identify All requests. Review which sources are allowed to send multicast discovery, which asset classes respond, and whether responses expose critical assets such as PLCs, HMIs, RTUs, IEDs, safety controllers, control servers, data gateways, switches, routers, firewalls, jump hosts, VPN servers, and historians. Relationship context notes INCONTROLLER uses this technique, so threat-informed detection engineering can include this behavior without assuming current activity or attribution.
Likely telemetry
- Passive ICS network traffic captures or metadata showing multicast discovery requests and responses
- Protocol-aware OT monitoring for PROFINET DCP Identify All and similar multicast discovery mechanisms
- Switch, router, firewall, and segmentation device logs showing cross-segment multicast traffic where available
- Asset inventory observations showing which ICS devices respond to discovery
- Engineering workstation, jump host, and remote-access session records to correlate discovery with authorized maintenance activity
Detection direction
- Validate that multicast discovery is visible at the OT network monitoring points that matter; many blind spots occur when sensors are placed only at enterprise/OT boundaries and not within control segments.
- Baseline authorized discovery sources, expected maintenance windows, normal responding asset groups, and protocol-specific behavior such as PROFINET DCP Identify All.
- Alert on discovery from unexpected sources, remote-access paths, enterprise-adjacent systems, or segments that should not initiate OT enumeration.
- Tune carefully: legitimate engineering tools and vendor maintenance workflows may use discovery, so detections should combine source, segment, timing, protocol, and response scope rather than packet presence alone.
- Use the INCONTROLLER relationship as context for threat-informed hunting, but do not treat multicast discovery by itself as proof of malware or compromise.
Mitigation priorities
- Start with Network Segmentation: restrict which networks and systems can reach critical process-control assets and prevent unnecessary enterprise-to-ICS discovery paths.
- Use Static Network Configuration where possible to reduce dependence on dynamic discovery or addressing mechanisms, while documenting operational exceptions where device limitations or network design make this impractical.
- Restrict discovery-capable protocols to approved engineering workstations, jump hosts, or management zones and verify that firewalls, switches, and routers enforce those boundaries.
- Maintain an OT asset inventory and approved communication matrix so unexpected multicast discovery has context during triage.
- Review remote-access, VPN, and jump-host paths because these assets are in scope for this technique’s target relationships and can become discovery launch points if misused.
Analyst notes and limits
This is an ICS sub-technique of Remote System Discovery. The official description emphasizes multicast discovery as more selective and potentially stealthier than broadcast discovery, with PROFINET DCP Identify All given as an example. ATT&CK relationships identify broad ICS asset targeting and list DET0909 as a detection strategy, M0814 Static Network Configuration and M0930 Network Segmentation as mitigations, and INCONTROLLER as software that uses the behavior.
The supplied ATT&CK object does not provide official detection logic, tactics, or platforms for the technique itself. Asset relationships include platforms, but those should not be interpreted as the technique’s own platform coverage. Local protocol use, network architecture, sensor placement, maintenance practices, and asset inventory quality are required to determine real detection coverage and risk.
Multicast Discovery
Adversaries may perform multicast discovery requests which is when one system or device sends messages to all systems and devices in a pre-defined group on a network (or subnet) and then waits for a response. If a response is received that means the system or device that responded is live and can communicate over that protocol. Multicast discovery tends to be stealthier than broadcast discovery because every system or device on the network (or subnet) is not being messaged.
One common OT protocol that has a multicast discovery mechanism is the Process Field Network (PROFINET) Discovery and Configuration Protocol (DCP) with its Identify All requests.[1]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0846 | Remote System Discovery | This object subtechnique of Remote System Discovery. |
Groups, software, and campaigns
S1045: INCONTROLLER
INCONTROLLER is custom malware that includes multiple modules tailored towards ICS devices and technologies, including Schneider Electric and Omron PLCs as well as OPC UA, Modbus, and CODESYS protocols. INCONTROLLER has the ability to discover specific devices, download logic on the devices, and exploit platform-specific vulnerabilities. As of September 2022, some security researchers assessed INCONTROLLER was developed by CHERNOVITE.[1][2][3][4][5]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 7ff9e85b8c5f… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Cisco Active Discovery
Cisco Systems, Inc.. (2024, March 5). Cisco Cyber Vision Active Discovery Configuration Guide, Release 4.3.0. Retrieved April 23, 2026.
Open source URL -
[2]
mitre-attack T0846.003Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.