Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0908: Detection of Broadcast Discovery

DET0908 is a detection strategy entry for identifying Broadcast Discovery in ICS environments. The business value is recognizing when devices are being enu...

ICSDET0908Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0908 is a detection strategy entry for identifying Broadcast Discovery in ICS environments. The business value is recognizing when devices are being enumerated through broadcast-style network requests, because this can expose the shape of an operational network before later activity. For leaders, the key question is whether OT network monitoring can distinguish normal engineering or asset-management discovery from unexpected discovery behavior.

Executive priority

Prioritize this as an OT visibility and incident-readiness issue rather than as a standalone control. Broadcast discovery can reveal live devices and supported protocols, so coverage depends on whether the organization has reliable evidence from ICS network segments and a baseline of normal broadcast traffic. Executives should ask whether SOC and OT teams can prove they monitor broadcast discovery paths, explain expected sources, and escalate unusual discovery without disrupting operations.

Technical view

The supplied ATT&CK object has no official detection text, platforms, or tactics, but it is explicitly related to ICS technique T0846.002, Broadcast Discovery. SOC and detection teams should validate monitoring for broadcast messages and responses on relevant OT subnets, then compare observed sources, timing, protocols, and responding devices against known engineering workstations, asset inventory systems, and normal operational behavior. IR teams should ensure playbooks can quickly determine whether discovery traffic is authorized maintenance, asset inventory activity, or suspicious enumeration.

Likely telemetry

  • OT/ICS network traffic captures or flow records showing broadcast requests and device responses
  • Protocol-aware ICS network monitoring where available
  • Switch, firewall, or network sensor logs for OT subnet broadcast activity
  • Asset inventory or passive discovery records showing expected devices and communication patterns
  • Change, maintenance, or engineering activity records to explain legitimate discovery events

Detection direction

  • Establish a baseline of normal broadcast discovery sources, frequency, protocols, and responding devices in each OT subnet.
  • Alert on unexpected systems initiating broadcast discovery, unusual timing, abnormal volume, or discovery of device groups not normally contacted by that source.
  • Correlate network observations with approved maintenance windows, engineering workstation activity, and asset-management scans to reduce false positives.
  • Check for monitoring blind spots between OT subnets, unmanaged switches, SPAN/TAP gaps, and networks where broadcast traffic is not captured.
  • Because MITRE provides no official detection logic for this object, detection engineering should be locally validated against the organization’s actual ICS protocols and network architecture.

Mitigation priorities

  • Confirm OT asset inventory and network diagrams are accurate enough to define expected broadcast discovery behavior.
  • Limit and document which systems are authorized to perform discovery or asset enumeration in OT networks.
  • Segment OT networks where appropriate so broadcast discovery is constrained to intended subnets.
  • Use monitoring and change-management evidence to distinguish approved engineering activity from unexpected enumeration.
  • Include broadcast discovery review steps in OT incident response and compliance evidence collection where network visibility is required.
Analyst notes and limits

This take is based only on the ATT&CK detection strategy metadata and its relationship to T0846.002 Broadcast Discovery. The source object does not provide an official description, official detection guidance, platforms, or tactics, so recommendations are framed as validation questions and telemetry priorities rather than definitive detection content.

Local protocol use, network topology, sensor placement, and maintenance practices determine what is normal and detectable. This object does not support claims about active exploitation, specific adversaries, vendor products, or guaranteed detection coverage.

Official MITRE ATT&CK definition

Detection of Broadcast Discovery

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Techniques used

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.

1 rows
Domain ID Name Relationship / procedure
ICS T0846.002 Broadcast Discovery Sub-technique This object detects Broadcast Discovery.
Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
662d15cf8fd93d3c...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 662d15cf8fd9…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0908
    Open source URL
Source and licensing

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.