ATT&CK for ICS Command and Control Tactic Guide: Spotting Adversary Channels in Industrial Networks

In an industrial network the command channel an adversary uses often looks exactly like the plant's own traffic: Modbus on TCP 502, HTTPS to a vendor, a proxy that relays through a trusted host. ATT&CK for ICS describes the Command and Control tactic (TA0101) as the adversary "trying to communicate with and control compromised systems, controllers, and platforms with access to your ICS environment", and notes that adversaries mimic expected ports, protocols and IT resources to avoid suspicion. The defender's advantage is that OT traffic is far more predictable than enterprise traffic, so a well-maintained baseline turns blending in into an anomaly. This guide covers the three Command and Control techniques and two sub-techniques in ATT&CK v20, how malware and campaigns have used them, the mitigations MITRE maps, the v20 detection strategies and a rollout plan. It is written for OT network engineers, OT SOC analysts and threat hunters, and builds on the MITRE ATT&CK for ICS Guide without repeating the matrix overview.

Key takeaways

• The industrial protocol can be the command channel. FrostyGoop sends commands over Modbus on TCP 502 and Triton talks to its implant through the TriStation protocol on UDP 1502, so "C2" in OT does not always mean an internet beacon.
• Internal proxies hide the path. Industroyer reaches its external server through an internal proxy on TCP 3128, and INCONTROLLER's PLCProxy module routes traffic through a Schneider PLC's CODESYS gateway.
• Network Intrusion Prevention is mapped to every technique. In v20, M0931 covers all 5 Command and Control techniques and sub-techniques, and Filter Network Traffic (M0937) covers 3.
• Newer IoT and OT malware uses broker protocols. IOControl, the only recorded user of the two v20 sub-techniques, connects over MQTT on ports 1883 and 8883 and resolves its servers with DNS over HTTPS.
• Determinism is the defender's lever. Field devices and controllers should almost never start outbound connections, so a communication matrix with alerting on any new flow catches most of this tactic.

Where Command and Control sits in an ICS intrusion

Command and Control runs alongside the rest of the intrusion rather than at one point in it. It begins once a foothold exists (after Initial Access) and carries the operator's instructions for discovery, collection and finally the commands that impair a process. In OT there are two distinct layers of command and control, and defenders need to watch both.

• Outer channel: from the adversary's infrastructure to a compromised Windows or Linux host in the enterprise, DMZ or Level 3, typically over HTTP, HTTPS or DNS. BlackEnergy's HTTP POST requests and Stuxnet's contact attempts on port 80 are examples recorded in ATT&CK.
• Inner channel: from that host, or from malware placed on it, to controllers and field devices, using the industrial protocol itself. FrostyGoop (Modbus), Triton (TriStation) and INCONTROLLER (HTTP/HTTPS to a malicious agent on Omron PLCs) fall here.

To see how the tactic is used, we counted the "uses" relationships in the official ATT&CK v20 ICS dataset (ics-attack-20.0.json; groups, software and campaigns, excluding revoked and deprecated objects). 13 entities have a Command and Control procedure: 8 software families, 3 groups (CyberAv3ngers, OilRig and Sandworm Team) and 2 campaigns (the 2015 Ukraine Electric Power Attack and the 2025 Poland Wiper Attacks), with 19 procedure examples in total. All 8 software families with a Command and Control procedure also have procedures under other ICS tactics, most often Execution (7 of the 8), which confirms that the channel exists to deliver later actions.

The techniques in ATT&CK v20

ATT&CK v20 lists three Command and Control techniques for ICS, one of which has two sub-techniques. None of them sits under another ICS tactic.

T0885 lists the ports adversaries rely on being open, including TCP 80 and 443, TCP/UDP 53, TCP 23, UDP 161, TCP 502 (Modbus), TCP 102 (S7comm/ISO-TSAP), TCP 20000 (DNP3), TCP 44818 (EtherNet/IP) and the dynamic ranges used by classic OPC. ATT&CK also records CyberAv3ngers using TCP 22 together with TCP 44818, TCP and UDP 2222, TCP 102 and TCP 502. The lesson is that a firewall rule permitting "port 502" says nothing about who should be sending Modbus to whom; the allowlist has to name source, destination and protocol.

Which techniques matter most for defenders

1. T0869 Standard Application Layer Protocol: the most used technique in the tactic and the one that covers both layers. Inner channel use (Modbus, TriStation, CODESYS) goes straight to process impact.
2. T0885 Commonly Used Port: nearly as common, and the reason port-based rules fail. Pair it with protocol-aware monitoring rather than port filtering alone.
3. T0884 Connection Proxy: fewer examples, but used by the two best-known grid attacks (Sandworm Team in 2015 and Industroyer) and by INCONTROLLER. A proxy defeats segmentation that assumes traffic originates where it appears to.
4. T0869.001 and T0869.002: currently one recorded user each, but they reflect the growth of IIoT gateways, cloud-connected devices and MQTT in OT, where many sites have no inspection at all.

Mitigations MITRE maps to the tactic

ATT&CK v20 maps 7 distinct ICS mitigations to the 5 Command and Control techniques and sub-techniques. All of them are network or boundary controls.

For the highest-risk flows, a one-way path removes the inner and outer channel altogether: historian replication and monitoring data can leave the control network through a unidirectional gateway with no return route. See the Data Diodes and Unidirectional Gateways Guide. For the cross-tactic list of mitigations, see ATT&CK Mitigations.

Detection and measurement

The v20 detection strategies for this tactic are built around one OT-specific idea that MITRE calls an operational-fidelity gate: alert only when a flow is outside the asset's documented role and approved communication baseline. That makes the communication matrix (which host may talk to which, on which protocol) the most valuable detection asset an OT team can build.

Telemetry to enable first

1. Flow records at every zone boundary: NetFlow or IPFIX from OT firewalls and core switches, retained long enough to reconstruct a slow beacon.
2. Passive OT protocol monitoring: a sensor on a SPAN or TAP port that decodes Modbus, S7comm, EtherNet/IP, DNP3 and vendor protocols. The joint advisory AA22-103A points defenders to CISA's open-source ICSNPP parsers for this purpose.
3. DNS logs from the designated OT resolvers, plus a firewall rule that denies DNS to anything else so bypass attempts are logged.
4. Host telemetry on Windows and Linux OT hosts: Sysmon network connection events (Event ID 3) or auditd connect calls, and firewall rule changes.

Metrics that show it is working

• Baseline coverage: share of OT zones with a documented communication matrix that is enforced or alerted on.
• Outbound exceptions: number of Level 0 to 2 assets with any permitted path to the internet, trending to zero.
• New-flow alert time: minutes from a new peer relationship appearing on a controller network to an analyst reviewing it, tested with planned purple-team flows.
• Protocol visibility: share of OT network segments covered by a protocol-decoding sensor.
• DNS hygiene: count of OT hosts resolving through anything other than designated resolvers.

Where identity fits

Command and control in OT often rides on machine identities that nobody reviews: the service account a historian uses to pull data, the client certificate an IIoT gateway presents to its MQTT broker, the OPC UA application certificate an HMI trusts. MITRE's v20 analytics for publish/subscribe misuse look for unexpected client identities and topics, which only works if those identities are inventoried. Issue each gateway and broker client its own credential, restrict topics per identity, and for OPC UA enable application authentication with explicit trust lists, as the AA22-103A advisory recommends. See the Identity for OT Environments Guide.

Implementation roadmap

1. Map the real flows: collect two to four weeks of passive flow and protocol data per zone, review it with control engineers and record each legitimate peer relationship, protocol and direction.
2. Remove direct outbound: route any required internet access from OT through the DMZ via proxies the security team monitors; deny everything else. Apply in log-only mode first and keep the previous rule set for rollback.
3. Pin name resolution: designate OT resolvers, block outbound UDP and TCP 53 and known DNS over HTTPS endpoints from other hosts.
4. Alert on matrix violations: turn the documented matrix into detection rules, starting with controller networks, where new peers are rarest.
5. Add host controls: alert on firewall rule creation and new listening services on HMIs, historians and engineering workstations.
6. Review IIoT and cloud paths: list every MQTT broker, cloud connector and vendor telemetry agent, and give each an owner and an approved destination list.

Decision guidance

• Detect or block at Level 0 to 2: blocking control traffic can stop a process, so most operators detect inside cell and area zones and enforce at the IT/OT boundary and DMZ.
• SSL/TLS inspection: worthwhile at the IT/OT boundary for vendor and cloud traffic; rarely practical inside control networks.
• Small sites: start with denying all outbound from OT except named destinations and logging firewall denies; a full sensor deployment can follow.
• Large operators: invest in central OT monitoring with per-site sensors and a shared communication matrix format so detections can be reused.

Framework mapping

Common failure patterns

• Port-based allowlists: permitting TCP 502 or 443 between zones without naming source and destination hosts, which is exactly what T0885 relies on.
• Trusting the DMZ host: treating any traffic from a jump host or historian as legitimate, which is how internal proxies hide the outer channel.
• No DNS control in OT: hosts resolving through public resolvers, so tunnelling and DNS over HTTPS go unseen.
• Unreviewed IIoT connectors: cloud telemetry and MQTT links added by projects or vendors without security review or an approved broker list.
• Sensor blind spots: monitoring only the IT/OT boundary, so controller-to-controller relays such as INCONTROLLER's PLCProxy never cross a sensor.
• Firewall changes on hosts not monitored: a new rule named to look like an update service goes unnoticed without rule-change alerting.

Practitioner checklist

• Document a communication matrix for each OT zone and review it with control engineers.
• Deny direct outbound internet access from all Level 0 to 2 assets.
• Designate OT DNS resolvers and block other DNS and DNS over HTTPS paths.
• Deploy protocol-decoding monitoring on controller networks as well as at the boundary.
• Alert on any host holding an inbound ICS session and an outbound non-ICS session at once.
• Alert on firewall rule creation and new listening ports on HMIs and engineering workstations.
• Inventory MQTT brokers, IIoT gateways and cloud connectors with their approved destinations.
• Give each gateway and broker client its own credential or certificate.
• Test detection with planned flows between unapproved peers twice a year.

Standards and references

• MITRE ATT&CK for ICS: Command and Control (TA0101)
• MITRE ATT&CK for ICS: Standard Application Layer Protocol (T0869)
• MITRE ATT&CK for ICS: Connection Proxy (T0884)
• MITRE ATT&CK for ICS: Commonly Used Port (T0885)
• CISA: AA22-103A APT Cyber Tools Targeting ICS/SCADA Devices
• CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · OT Network Security Monitoring Guide · Industrial Protocol Security Guide · ATT&CK for ICS Initial Access Tactic Guide · ATT&CK for ICS Persistence Tactic Guide