T0848 Rogue Master: Detecting Rogue Masters on Industrial Networks

A rogue master is an unauthorised device that talks to field equipment as if it were the real control server, and most industrial protocols give the outstation no way to tell the difference. MITRE ATT&CK for ICS tracks this as T0848 Rogue Master under the Initial Access tactic (TA0108), on Embedded, Windows, Linux and Network Devices platforms. The technique matters because the commands it sends are legitimate protocol messages: a write, a start, a trip or a siren activation that the device is designed to obey. This guide is for OT security engineers, control system owners and SOC analysts who need to find unauthorised masters, stop them reaching outstations and respond without upsetting the process. For the wider discipline see the OT Security Guide.

Key takeaways

• The outstation trusts the address, not the sender. Classic master and outstation protocols accept a correctly formed command from whoever sends it, so a rogue master needs network or radio reach, not credentials.
• The two documented cases are radio and wireless. ATT&CK cites the Maroochy Water Breach (C0020, 2000) and the 2017 Dallas siren incident, both of which reached field devices over radio links rather than routed Ethernet.
• Allowlisting of masters is the core control. ATT&CK lists five mitigations: Communication Authenticity (M0802), Software Process and Device Authentication (M0813), Network Allowlists (M0807), Filter Network Traffic (M0937) and Network Segmentation (M0930).
• Detection is a question of who is allowed to be a master. ATT&CK's detection strategy DET0792 alerts on master-role traffic from any source outside the approved control server inventory, which only works if that inventory exists.
• Redundant masters are the main false positive. Hot standby promotion, failover and commissioning laptops all look like a second master, so baseline them and suppress them explicitly.

What T0848 covers

ATT&CK describes a rogue master as a set-up that uses control server functions to communicate with outstations. It can send legitimate control messages that affect the process in unintended ways, it can capture traffic meant for the real master and so disrupt communications, and impersonating a master may also help the adversary avoid detection. The technique sits in Initial Access because, in the documented cases, the rogue master is the first and only foothold: the attacker never compromised the control centre at all.

The distinction from nearby techniques is useful for detection engineering:

• Rogue Master (T0848): a new or impersonated master device issuing commands. The question is "is this sender allowed to be a master?"
• Unauthorized Message (T1692) and its Command Message and Reporting Message sub-techniques: the messages themselves. ATT&CK lists both sub-techniques for the Maroochy campaign alongside T0848, because the rogue master is the means and the messages are the action.
• Adversary-in-the-Middle (T0830): sitting between a real master and its outstations and altering traffic, rather than standing up a separate master.
• Wireless Compromise (T0860): gaining access through a wireless link, which Maroochy also shows.

The documented cases and what they teach

No other procedure examples are listed for T0848 in ATT&CK v20. Malware that sends protocol commands from a compromised host inside the control network is tracked under other techniques; see the IEC 60870-5-104 Telecontrol Security Guide for how that telecontrol protocol is protected.

Why the protocols allow it

Most fieldbus and telecontrol protocols were designed for closed serial or radio networks where any device on the wire was assumed to belong there. The practical effect for a defender:

Where a legacy controller or RTU cannot authenticate messages itself, ATT&CK's Communication Authenticity mitigation (M0802) suggests bump-in-the-wire devices or VPNs to enforce authenticity between the devices.

Detection: ATT&CK's analytics for a rogue master

ATT&CK v20 attaches detection strategy DET0792 to T0848 with four analytics. Each carries an "OT operational fidelity gate": alert only when the master or station identity is not authorised for the target device and command function, or when an authorised master breaks its configured role and causes a corroborating device or process change, and suppress legitimate redundancy, failover, hot standby promotion and commissioning.

In practice the strongest signal comes from passive OT network monitoring: build the list of which hosts issue write and control function codes to which outstations, and alert on any new pair. Radio links need their own monitoring; a wired sensor will not see a transmitter in a car park.

Metrics that show it is working

• Master inventory coverage: percentage of outstations whose authorised masters are recorded and enforced by allowlist.
• Authenticated command share: proportion of control links using DNP3 Secure Authentication, Modbus/TCP Security, IEC 62351 or an authenticating tunnel.
• Unknown master alerts: count per month of control traffic from non-inventoried sources, and time to triage each.
• Radio link assessment: share of radio telemetry links reviewed for encryption and replay protection in the last 12 months.
• Commissioning hygiene: engineering laptops seen acting as masters outside an approved change window.

Prevention, in order of effect

1. Inventory every master. Record each SCADA server, DCS server, front end processor, data concentrator and engineering workstation that is allowed to send commands, with the outstations and function types it may use.
2. Enforce allowlists at the outstation (M0807). Many PLCs, RTUs and protocol gateways can restrict accepted connections to named master addresses. Apply them during a maintenance window, starting with the most critical stations.
3. Segment and filter (M0930, M0937). Put outstations in zones whose conduits admit control protocols only from the master zone, and use inline allowlisting of protocol commands where a deep packet inspection firewall supports it. ATT&CK warns the rules must be accurate enough not to block valid reporting messages. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
4. Add authentication (M0802, M0813). Turn on the protocol's secure mode where both ends support it; otherwise place an authenticating tunnel in front of legacy devices. Test failover first, because authentication changes can break a standby master.
5. Secure radio links. Use encryption with managed keys and message authentication, and remove the ability to replay captured commands.
6. Control engineering equipment. Maroochy used stolen vendor hardware and software. Track configuration tools and spare devices, and revoke access promptly when contractors leave.

Roll back by keeping the previous allowlist and firewall rule set staged on the device or management console, and by agreeing with operations which stations return to monitor-only mode if a legitimate master is blocked.

Where identity fits

A master is a non-human identity: a device that the process trusts to issue commands. Treat the list of authorised masters as an access control list, review it like one, and remove entries when a server is decommissioned or a contractor's laptop leaves the site. Vendor and integrator access to master stations is a common route; see the Engineering Workstation Security Guide.

Safe response

• Process safety first: confirm with operations what state the affected outstations are in and whether any commands executed, before blocking anything that might also carry legitimate traffic.
• Locate the source: for wired networks use switch port and MAC tables; for radio, involve the radio engineers, as the transmitter may be outside the site boundary.
• Contain at the conduit: block the rogue source at the zone firewall or switch port once operations agree.
• Preserve evidence: packet captures, outstation event logs, radio logs and historian trends showing the commanded changes.
• Restore trust: verify outstation configuration and setpoints against known good values before returning to normal operation.

Framework mapping

Common failure patterns

• Relying on a station address or DNP3 link address as proof of identity, which Maroochy shows an intruder can change at will.
• Monitoring wired OT networks while radio telemetry and repeaters go unassessed.
• No written list of authorised masters, so a new polling host cannot be distinguished from a legitimate one.
• Inline command filtering written too tightly, blocking reporting messages and causing a loss of view.
• Former contractors keeping vendor configuration tools or spare field devices after their engagement ends.

Practitioner checklist

• List every authorised master and the outstations and functions it may command.
• Enable source allowlists on outstations and gateways that support them.
• Restrict control protocol ports at each conduit to the master zone.
• Turn on DNP3 Secure Authentication, Modbus/TCP Security or IEC 62351 where both ends support it.
• Assess every radio telemetry link for encryption, message authentication and replay protection.
• Alert on control traffic from any source outside the master inventory, with failover suppressed.
• Track vendor configuration software and spare field devices as controlled assets.
• Agree a response runbook with operations that starts with process state.

Standards and references

• MITRE ATT&CK: Rogue Master (T0848)
• MITRE ATT&CK: Maroochy Water Breach (C0020)
• MITRE: Malicious Control System Cyber Security Attack Case Study, Maroochy Water Services, Australia
• Bastille: Dallas Siren Attack
• MITRE ATT&CK: Communication Authenticity (M0802)
• MITRE ATT&CK: Network Allowlists (M0807)
• NIST: SP 800-53 Rev 5, Security and Privacy Controls

Related NHI Mgmt Group resources: OT Security Guide · Modbus TCP and Modbus Security Guide · DNP3 and DNP3 Secure Authentication Guide · IEC 60870-5-104 Telecontrol Security Guide · OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide