T0869 Standard Application Layer Protocol: Spotting Command and Control in OT Traffic

Standard Application Layer Protocol (T0869) is command and control hidden inside protocols an industrial network already carries, such as HTTP(S), DNS, MQTT, Modbus or a vendor's own controller protocol. Because the traffic is expected, signature thinking alone rarely finds it: the useful question is whether this asset, in its documented role, should talk this protocol to this destination at all. MITRE ATT&CK for ICS v20 lists T0869 under Command and Control for Embedded, Windows, Linux and Network Devices platforms, and in 2026 added two sub-techniques, DNS (T0869.001) and Publish/Subscribe Protocols (T0869.002). This guide is for OT security engineers and OT SOC analysts: what the procedure examples show, what ATT&CK's analytics look for, and how to build the communication baseline that makes detection work. The enterprise view is in the MITRE ATT&CK T1071 Application Layer Protocol guide; this page covers what is different in OT.

Key takeaways

• The baseline is the detection. All four ATT&CK v20 analytics for T0869 alert only when a connection falls outside the asset's approved communication profile, so a documented communication matrix comes first.
• OT protocols carry C2 too. ATT&CK records FrostyGoop sending commands over Modbus, Triton using a TriStation diagnostic command to reach its implant, and Stuxnet using a PLC data block as a command channel.
• IoT-style protocols are now in scope. IOCONTROL, added to ATT&CK in 2026, used MQTT over ports 1883 and 8883 for C2 and resolved its servers through DNS over HTTPS.
• Field devices should rarely start outbound sessions. An embedded device or gateway opening a web, DNS or MQTT session to an unknown destination is high signal in most plants.
• Segmentation and allowlists are the mitigations. ATT&CK maps M0930 Network Segmentation, M0807 Network Allowlists and M0931 Network Intrusion Prevention to T0869, with M0937 Filter Network Traffic on the sub-techniques.

What T0869 covers in OT

ATT&CK for ICS describes adversaries establishing command and control over commonly used application layer protocols such as HTTP(S), OPC, RDP, telnet, DNP3 and Modbus, to disguise their actions as benign traffic, sometimes on the standard port and sometimes on a non-standard one. The channel can lead out of the network to an external server, or stay inside it between infected devices. That second case matters in OT: C2 between an implant on an engineering workstation and a controller never crosses the internet boundary.

Related ICS techniques sit next to T0869 and have their own pages: Commonly Used Port (T0885) is about the port choice, and Connection Proxy (T0884) about relaying traffic. Map detections to whichever applies.

The procedure examples

• FrostyGoop (S1165): ATT&CK records FrostyGoop using Modbus to transmit commands to victim devices, citing Dragos. The command channel is the plant's own control protocol. See the FrostyGoop Modbus Malware Guide.
• INCONTROLLER (S1045): ATT&CK records it sending commands over HTTP or HTTPS to a malicious agent uploaded to Omron PLCs. CISA advisory AA22-103A (April 2022, revised May 2022) describes the tooling loading a custom agent on Omron Sysmac NJ and NX PLCs that accepts commands over HTTP and/or HTTPS, including file manipulation, packet capture and code execution.
• Triton (S1009): ATT&CK records Triton communicating with its implant using the TriStation "get main processor diagnostic data" command, looking for a specially crafted packet body that carries a command value and arguments. A safety system diagnostic function became the C2 channel.
• Stuxnet (S0603): ATT&CK records a thread that probes a PLC data block (DB890) every five minutes and reads and writes it when a magic value is present, likely to adjust behaviour when the Step 7 editor is opened.
• IOCONTROL (S9046): Claroty Team82 (December 2024) reports the malware publishing to and subscribing from MQTT topics derived from a per-device identifier on port 8883, and resolving its C2 hostname through Cloudflare's DNS over HTTPS service so a network tap cannot see the name. ATT&CK v20 maps this to both sub-techniques. Team82 notes the sample had no antivirus detections when examined in September 2024.
• Enterprise families in OT environments: ATT&CK also lists BlackEnergy (HTTP POST to external C2), REvil (HTTPS POST with random URLs) and OilRig (HTTP C2). These are the cases where the enterprise detections in the Beaconing and C2 Detection Guide apply directly to OT Windows hosts.

Detection: ATT&CK v20 analytics

MITRE's detection strategy DET0799 has four analytics. Each carries the same OT operational fidelity gate: alert only when the asset's documented role does not permit the connection and the destination, proxy or service is outside the approved communications profile, with process or service identity as corroboration, and suppress approved vendor support, update repositories, remote operations, failover paths and documented temporary connectivity.

Industrial protocols as C2

The analytics above catch new destinations. FrostyGoop, Triton and Stuxnet show the harder case: C2 inside an allowed protocol between allowed endpoints. Detection there needs protocol decoding, comparing function codes, commands and data blocks with what each master and controller pair normally exchanges, and attention to engineering and diagnostic commands from hosts that do not usually send them. See the OT Network Security Monitoring Guide.

DNS and MQTT in OT

• DNS: the v20 mitigations for T0869.001 say to require ICS assets to use approved resolvers, restrict direct DNS, DoT and DoH to external services, and monitor exceptions rather than assume all encrypted DNS is malicious. Log queries at the OT resolver so you have the data. See the Encrypted DNS Enterprise Guide and the DNS Logging and Detection Guide.
• Publish/subscribe: the v20 mitigations for T0869.002 say to restrict MQTT, AMQP, DDS and similar traffic to approved brokers, peers, ports, topics, namespaces and zones, and block unauthorised external broker access while preserving documented IIoT paths. A device reaching a broker you do not run is the signal. See the MQTT Security Guide.

Prevention: the mitigations in practice

• M0930 Network Segmentation: ATT&CK says to segment higher level corporate resources from the control process environment. Route all OT egress through a conduit you control, so there is one place to see and filter it. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
• M0807 Network Allowlists: allowlists by address, port and protocol on hosts or network devices. ATT&CK notes that allowlists operating at the application layer, for DNP3, Modbus or HTTP, are covered under Filter Network Traffic (M0937), which is where protocol-aware firewalls restrict which commands each source may send.
• M0931 Network Intrusion Prevention: signatures for known malware traffic at the network level, applied in OT in detect mode first and blocking only where operationally safe, as the v20 sub-technique mitigations themselves say.
• Remove direct internet paths: CISA's AA22-103A advice includes isolating ICS networks from corporate and internet networks, restricting traffic at their perimeters and limiting ICS connections to approved engineering and management workstations.

Where identity fits

Outbound connections that look legitimate often belong to a non-human identity: a vendor remote support agent, a historian's cloud connector, an MQTT client with a broker username and password. Each needs an owner, a documented destination and a credential that is not shared across sites. IOCONTROL authenticated to its own broker with credentials derived from its device identifier, which is why broker-side controls on who may connect to your brokers, and egress blocks on brokers you do not run, both matter. See the OT and ICS Identity and Access Guide and the OT Remote Access Guide.

How to implement

1. Build the communication matrix. From passive monitoring and engineering records, list for each zone which assets talk which protocols to which destinations, including vendor support, update and cloud services.
2. Force egress through one conduit and one resolver. Log all denied outbound attempts for a period before enforcing, and route DNS through an OT resolver that logs queries.
3. Deploy DET0799-style alerts in alert-only mode through at least one maintenance cycle (our recommendation), suppressing documented vendor and maintenance connectivity.
4. Add protocol decoding for the industrial protocols on your critical conduits, and baseline function codes per master and controller pair.
5. Enforce allowlists zone by zone, starting with field devices and safety networks where the expected set of peers is smallest.
6. Keep a rollback. Record every firewall rule change with the prior rule, and agree with operations who can revert a block that interrupts a process or a remote support session.

Decision guidance

• Block or alert: block unapproved outbound connections from field devices and safety networks, where false positives are rare; alert first on Windows supervisory hosts, where vendor services change more often.
• Encrypted DNS: where vendor software needs DoH, allow it only to named services and log it, rather than allowing all port 443 traffic from the OT zone.
• Small sites: a conduit firewall with default deny egress and a logged resolver removes most T0869 exposure without new tools.
• Large sites: add passive OT monitoring with protocol decoding and an OT SOC process for baseline deviations. See the OT Security Operations Centre Guide.

Responding to a suspected C2 channel

Confirm the process is safe with operations before acting, since blocking a channel that a controller or HMI depends on can affect production. Preserve evidence first: packet captures from the conduit, resolver logs, the host's process and network events and, for an embedded device, its current configuration and firmware version. Contain at the conduit by blocking the destination or broker rather than isolating hosts operators need. If the channel ran inside an industrial protocol, compare controller programs and configuration with approved offline copies. See the OT Incident Response Guide.

Detection and measurement

• Matrix coverage: percentage of OT zones with a documented and reviewed communication matrix.
• Egress control: number of OT assets with any direct route to the internet that bypasses the conduit.
• Resolver use: percentage of OT DNS traffic going through the logged OT resolver.
• Protocol visibility: percentage of critical conduits with industrial protocol decoding.
• Unexplained connections: count of outbound connections outside the matrix each month, each closed with a matrix update or an investigation.

Framework mapping

Common failure patterns

• No communication matrix: every new connection is "probably the vendor", so nothing is ever investigated.
• Open port 443 from the OT zone: allowed for one update service, used by everything else.
• Field devices with their own internet path: cellular routers and cloud connectors added outside the conduit design.
• Flow data only: monitoring shows a Modbus session between two approved hosts but not the commands inside it.
• Ignoring DNS: hosts use public resolvers directly, so the query log that would show unknown domains does not exist.

Practitioner checklist

• Document the communication matrix for each OT zone, including vendor and cloud destinations.
• Route all OT egress through a conduit firewall with default deny outbound.
• Run a logging OT resolver and block direct external DNS, DoT and DoH except named services.
• Restrict MQTT and other broker traffic to brokers you operate.
• Alert on field devices and gateways initiating outbound sessions outside the matrix.
• Decode industrial protocols on critical conduits and baseline commands per pair.
• Give each vendor or cloud connector a named owner and its own credential.
• Review the matrix after every project or vendor change.

Standards and references

• MITRE ATT&CK for ICS: Standard Application Layer Protocol (T0869)
• MITRE ATT&CK: Detection of Standard Application Layer Protocol (DET0799)
• CISA and partners: AA22-103A, APT Cyber Tools Targeting ICS/SCADA Devices
• Claroty Team82: Inside a New OT/IoT Cyberweapon, IOCONTROL
• Mandiant: Attackers Deploy New ICS Attack Framework TRITON
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · MITRE ATT&CK T1071 Application Layer Protocol · Command and Control (C2) Guide · ICS Malware History Guide · OT Network Security Monitoring Guide