T0846.002: Broadcast Discovery
Adversaries may perform broadcast discovery requests to enumerate systems and devices on a network. Broadcast discovery works by one system or device sending messages to all systems and devices on a network (or subnet) and then waiting for a response. If a response is received that means the system or device that responded is live and can communicate over that protocol. Adversaries may leverage different protocols supported on the network for sending broadcast messages.
Some common OT protocols that have broadcast discovery mechanisms are Building Automation and Control Network (BACNet) Who-Is requests, Common Industrial Protocol (CIP) List Identity User Datagram Protocol (UDP) broadcast requests, and Siemens S7 broadcast identification requests.[1][2]
Analyst context for executives and security teams
Broadcast Discovery matters because it can quickly reveal live devices in an ICS network by sending broadcast requests and observing who answers. In OT environments, responses from BACnet, CIP, or Siemens S7 discovery mechanisms can expose the shape of control networks, including workstations, HMIs, PLCs, RTUs, safety controllers, gateways, and network infrastructure. For leaders, the issue is not just scanning noise; it is whether an unauthorized or poorly controlled system can map critical operational assets before follow-on activity.
Executive priority
Treat this as an OT visibility and segmentation validation item. Executives and risk owners should ask which ICS segments allow broadcast discovery, which tools are authorized to perform it, whether remote access paths such as VPN servers and jump hosts can initiate it, and whether evidence exists for audits or incident reviews. Because ATT&CK maps this behavior to broad ICS asset classes and to related campaign/software context, it should influence control prioritization around critical process control and safety-related zones without assuming local exposure.
Technical view
ATT&CK does not provide platforms, tactics, or detection text for T0846.002, but the object describes broadcast requests used to enumerate systems and devices, with examples including BACnet Who-Is, CIP List Identity UDP broadcast requests, and Siemens S7 broadcast identification. SOC and IR teams should validate that OT network monitoring can see broadcast discovery inside the relevant subnet or control zone, identify the requesting source, and correlate it to approved engineering, asset management, or maintenance activity. Relationship context includes DET0908 for detection strategy and mitigations M0930 Network Segmentation and M0814 Static Network Configuration.
Likely telemetry
- Passive OT network sensor or packet capture visibility inside ICS segments
- Protocol-aware network evidence for BACnet Who-Is, CIP List Identity UDP broadcast, and Siemens S7 broadcast identification where those protocols are present
- Broadcast or subnet-wide traffic records from switches, routers, firewalls, or network monitoring tools
- Source-host context from engineering workstations, HMIs, application servers, data gateways, jump hosts, and VPN servers
- Asset inventory and approved discovery-tool records to distinguish expected discovery from anomalous sources
Detection direction
- Confirm monitoring placement: broadcast discovery may not traverse routed boundaries, so sensors outside the local segment can miss it.
- Baseline legitimate discovery from vendor tools, engineering workstations, and authorized asset inventory processes before alerting broadly.
- Prioritize alerts for new or unexpected sources, discovery from remote-access infrastructure, cross-zone attempts, or discovery against critical control and safety segments.
- Tune for false positives from normal commissioning, maintenance, diagnostics, and inventory activities.
- Use the relationship to DET0908 as a prompt to build or validate a local detection strategy, since the ATT&CK object itself does not include detailed detection logic.
Mitigation priorities
- Use Network Segmentation to restrict which systems can reach critical ICS segments and to prevent enterprise or unrelated business networks from accessing process control systems.
- Restrict broadcast discovery to approved management, engineering, or monitoring systems where operationally required.
- Use Static Network Configuration where feasible, recognizing ATT&CK notes that it may not always be usable due to device features or network configuration constraints.
- Document authorized discovery paths and maintenance exceptions so SOC and compliance teams can distinguish expected behavior from suspicious enumeration.
- Review jump host, VPN, firewall, router, switch, and data gateway controls because these assets can determine whether discovery remains contained.
Analyst notes and limits
This take is based on ATT&CK T0846.002 Broadcast Discovery, its cited examples, and supplied relationships. The relationship set shows broad targeting across ICS assets and use by C0063 and S1009, which increases defensive relevance, but local risk depends on which protocols, segments, and assets exist in the environment.
No official ATT&CK detection text, tactics, or platforms were supplied for this object. Protocol presence, normal discovery behavior, sensor coverage, and control feasibility must be validated locally before drawing conclusions about exposure or detection coverage.
Broadcast Discovery
Adversaries may perform broadcast discovery requests to enumerate systems and devices on a network. Broadcast discovery works by one system or device sending messages to all systems and devices on a network (or subnet) and then waiting for a response. If a response is received that means the system or device that responded is live and can communicate over that protocol. Adversaries may leverage different protocols supported on the network for sending broadcast messages.
Some common OT protocols that have broadcast discovery mechanisms are Building Automation and Control Network (BACNet) Who-Is requests, Common Industrial Protocol (CIP) List Identity User Datagram Protocol (UDP) broadcast requests, and Siemens S7 broadcast identification requests.[1][2]
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
S1009: Triton
C0063: 2025 Poland Wiper Attacks
2025 Poland Wiper Attacks is a Russian state-sponsored campaign that conducted destructive cyberattacks against Polish energy infrastructure in December 2025. Targets included more than 30 wind and photovoltaic farms, a combined heat and power (CHP) plant, and a manufacturing sector company. The attacks on the distributed energy resources (DER) disrupted communications between affected facilities and the distribution system operator, but did not impact electricity generation or heat supply. Across the campaign, threat actors deployed two previously undocumented wiper tools, DynoWiper, a Windows-based wiper and LazyWiper, a PowerShell wiper, distributed via malicious Group Policy Objects. At the CHP plant, threat actors had maintained access since at least March 2025, using that foothold to obtain credentials and move laterally before attempting wiper deployment. Some reporting has assessed the activity to be consistent with Russian Federal Security Service (FSB) threat activity group Dragonfly, also tracked as STATIC TUNDRA, while other reporting attributes the destructive wiper activities to the Russian General Staff Main Intelligence Directorate (GRU) threat activity group ELECTRUM, also tracked as Sandworm Team.[1][2][3][4]
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 | 1a9e64280d3e… |
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]
Broadcasting BACnet
H. Michael Newman. (2010, November). Broadcasting BACnet®. Retrieved April 23, 2026.
Open source URL -
[2]
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 -
[3]
mitre-attack T0846.002Open 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.