T0848: Rogue Master
Adversaries may setup a rogue master to leverage control server functions to communicate with outstations. A rogue master can be used to send legitimate control messages to other control system devices, affecting processes in unintended ways. It may also be used to disrupt network communications by capturing and receiving the network traffic meant for the actual master. Impersonating a master may also allow an adversary to avoid detection.
In the case of the 2017 Dallas Siren incident, adversaries used a rogue master to send command messages to the 156 distributed sirens across the city, either through a single rogue transmitter with a strong signal, or using many distributed repeaters. [1] [2]
Analyst context for executives and security teams
Rogue Master matters because it turns trust in an ICS control hierarchy into a business and safety risk. If an unauthorized system can impersonate a legitimate master/control server, it may send commands that field devices accept as valid or intercept traffic intended for the real master. For leaders, the key question is not only whether the network is segmented, but whether control messages are authenticated, constrained to approved sources, and visible to operations and security teams.
Executive priority
Prioritize this behavior where control servers, HMIs, RTUs, PLCs, IEDs, gateways, historians, safety controllers, DCS controllers, or PACs support critical operations. The Dallas siren example cited by ATT&CK shows why this is relevant to cyber-physical resilience: unauthorized command capability can affect distributed physical systems. Executives should ask for evidence that only approved masters can communicate with outstations, that command paths are monitored, and that incident responders know how to distinguish legitimate failover or maintenance activity from impersonation.
Technical view
ATT&CK provides no platform or tactic assignment and no official detection text for T0848, but it does relate DET0792, Detection of Rogue Master, and multiple mitigations focused on authentication, allowlisting, segmentation, and protocol filtering. SOC and OT teams should validate the expected master-to-outstation communication map across the targeted ICS assets and look for unexpected command sources, duplicate or competing masters, unusual automation protocol message types, abnormal command rates or sequences, and traffic redirection or capture symptoms. IR playbooks should include coordination with operators before blocking traffic, because legitimate backup masters, gateways, maintenance tools, or failover scenarios may resemble rogue-master behavior.
Likely telemetry
- ICS network traffic between control servers/masters and outstations or field devices
- Automation protocol metadata, including source, destination, port, protocol, function/message type, sequence, and rate where available
- Control server, HMI, data gateway, historian, RTU, PLC, IED, PAC, DCS controller, and safety controller event or command logs where available
- Network allowlist, firewall, segmentation, and protocol-filtering logs
- Device and software process authentication events for remote connections and APIs
Detection direction
- Establish a baseline of authorized masters, outstations, protocols, message types, and normal command timing for each control zone.
- Alert on command traffic from non-approved sources, new masters, duplicate master behavior, or sources that should only receive telemetry but begin issuing control messages.
- Tune detections with OT context for maintenance windows, engineering activity, backup-master operation, data gateways, and failover testing to reduce false positives.
- Correlate network observations with process alarms, historian data, and operator reports; a rogue master may look protocol-valid while producing unintended process behavior.
- Because official ATT&CK detection text is not provided, validate any DET0792-aligned analytics against local architecture and asset inventories before treating them as coverage evidence.
Mitigation priorities
- Implement Communication Authenticity for untrusted communications so receivers can authenticate senders and verify message integrity using MACs or digital signatures where appropriate.
- Require Software Process and Device Authentication for devices and remote software processes that communicate with control systems or APIs.
- Use Network Allowlists to restrict which IP addresses, MAC addresses, ports, and protocols may communicate with control devices.
- Apply Network Segmentation to isolate critical control systems and restrict enterprise or other business-network paths into process control environments.
- Use Filter Network Traffic, including application-layer protocol filtering, to allow only expected automation messages, sequences, rates, and patterns where those are well defined.
Analyst notes and limits
The relationship set makes this technique broadly relevant across core ICS assets, including HMIs, PLCs, RTUs, IEDs, historians, control servers, data gateways, safety controllers, DCS controllers, and PACs. The Maroochy Water Breach campaign is listed as using this technique, and the description cites the 2017 Dallas siren incident as an example involving rogue command messages to distributed sirens. These references support treating rogue-master risk as both an OT security and operational resilience concern.
ATT&CK does not provide official detection text, tactics, platforms, aliases, or labels for this object. The mitigation and asset relationships provide useful defensive direction, but local protocol details, network topology, approved master inventory, wireless use, and operational procedures are required to assess real exposure and detection quality. This take does not imply active exploitation or guaranteed detection coverage.
Rogue Master
Adversaries may setup a rogue master to leverage control server functions to communicate with outstations. A rogue master can be used to send legitimate control messages to other control system devices, affecting processes in unintended ways. It may also be used to disrupt network communications by capturing and receiving the network traffic meant for the actual master. Impersonating a master may also allow an adversary to avoid detection.
In the case of the 2017 Dallas Siren incident, adversaries used a rogue master to send command messages to the 156 distributed sirens across the city, either through a single rogue transmitter with a strong signal, or using many distributed repeaters. [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.
Groups, software, and campaigns
C0020: Maroochy Water Breach
Maroochy Water Breach was an incident in 2000 where an adversary leveraged the local government’s wastewater control system and stolen engineering equipment to disrupt and eventually release 800,000 liters of raw sewage into the local community.[1]
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.2 | Current bundle | 467db625aacc… |
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]
Bastille April 2017
Bastille 2017, April 17 Dallas Siren Attack Retrieved. 2020/11/06
Open source URL -
[2]
Zack Whittaker April 2017
Zack Whittaker 2017, April 12 Dallas' emergency sirens were hacked with a rogue radio signal Retrieved. 2020/11/06
Open source URL -
[3]
mitre-attack T0848Open 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.