Commonly Used Port (T0885) is command and control that hides on the ports an industrial network already allows, so a port-based firewall rule alone will never catch it. MITRE ATT&CK for ICS places T0885 in the Command and Control tactic and lists both IT ports (80, 443, 53) and industrial ports (502 for Modbus, 102 for S7comm, 20000 for DNP3, 44818 for EtherNet/IP) as places to blend in. The procedure examples run from Stuxnet calling home on port 80 to FrostyGoop speaking Modbus on TCP 502. This guide is for OT security engineers, network architects and SOC analysts who need to decide which flows each zone really needs, how to spot the ones that do not belong, and how to respond without disturbing the process. For the matrix as a whole see the MITRE ATT&CK for ICS Guide.
Key takeaways
- The port number tells you very little. ATT&CK notes that an adversary may use the protocol normally associated with the port or a completely different one, so judge each flow by its source, destination, protocol and the asset's documented role.
- Industrial ports are command channels too. FrostyGoop used Modbus on TCP 502 and Triton used the TriStation UDP port 1502, so an allowed OT protocol on its normal port can carry hostile commands.
- Least functionality is the main prevention. The ICS mitigations for T0885 are Network Segmentation (M0930), Disable or Remove Feature or Program (M0942), Network Intrusion Prevention (M0931) and Human User Authentication (M0804).
- Detection is a role check, not a port check. ATT&CK's detection strategy alerts when an ICS host whose documented role needs no external connectivity opens a flow on 80, 443, 8080 or 53 to a destination outside the approved vendor list.
- Write the communications profile before you write the rule. Without a per-zone list of approved flows, every alert becomes an argument with operations, and the allow rules drift wider each outage.
What T0885 covers and how it differs from nearby techniques
ATT&CK for ICS v20 (page last modified 13 October 2026) describes T0885 as communicating over a commonly used port to bypass firewalls or network detection and to blend in with normal activity, avoiding closer inspection. It applies to Embedded, Windows, Linux and Network Devices platforms. ATT&CK's own list of example ports is reproduced below, because it shows why OT is different: several of the ports are industrial protocols that exist only inside the plant.
| Port (as listed by ATT&CK) | Usual protocol | Where you normally see it in OT |
|---|---|---|
| TCP 80, TCP 443 | HTTP, HTTPS | Vendor update and support portals, web HMIs, historian web clients, IT/OT DMZ services |
| TCP/UDP 53 | DNS | Name resolution, ideally only to an internal resolver in the DMZ |
| TCP 1024-4999 (Windows XP/2003), TCP 49152-65535 (Vista and later) | Dynamic ports used by OPC (DCOM) | OPC Classic between SCADA servers, HMIs and historians |
| TCP 23 | Telnet | Legacy device management |
| UDP 161 | SNMP | Network and device monitoring |
| TCP 502 | Modbus TCP | Controller polling and writes from SCADA and HMIs |
| TCP 102 | S7comm (ISO-TSAP) | Siemens S7 engineering and HMI traffic |
| TCP 20000 | DNP3 | Utility SCADA to outstations |
| TCP 44818 | EtherNet/IP | CIP explicit messaging to controllers |
Neighbouring techniques overlap but are not the same thing, and each has its own page:
- T0869 Standard Application Layer Protocol: the emphasis is on the protocol (an adversary speaking HTTP or an OT protocol); T0885 is about the port choice. Real activity often shows both.
- T0884 Connection Proxy: traffic relayed through an intermediate host. A proxy often listens on a common port, which is where the two meet.
- Enterprise T1571 Non-Standard Port: the opposite choice, a protocol on a port it does not normally use. See the MITRE ATT&CK T1571 Non-Standard Port, and for web-protocol command and control on IT hosts the MITRE ATT&CK T1071 Application Layer Protocol.
The procedure examples and what they teach
ATT&CK v20 records six procedure examples for T0885. Each is described below only as ATT&CK or the cited source states it.
| Example (ATT&CK ID) | Port use recorded by ATT&CK | Defensive lesson |
|---|---|---|
| Stuxnet (S0603) | Contacted command and control servers on port 80 to send basic information about the compromised computer | Engineering and HMI hosts with outbound web access give malware an easy channel; most need none |
| 2015 Ukraine Electric Power Attack (C0028), Sandworm Team (G0034) | Used port 443 to communicate with command and control servers | Encrypted 443 from the control centre side looks normal unless destinations are allowlisted |
| FrostyGoop (S1165) | Communicates using Modbus over the standard TCP 502 | An industrial port open from the wrong network segment is itself a command channel |
| Triton (S1009) | Used the TriStation default UDP port 1502 to talk to devices | Safety system engineering ports should be reachable only from the designated safety engineering station |
| CyberAv3ngers (G1027) | Observed using SSH on TCP 22 and industrial ports TCP 44818, TCP and UDP 2222, TCP 102 and TCP 502 during the 2026 Iranian Water Campaign (C0065), as ATT&CK records it | Internet exposure of controller ports is the root problem; inventory and close it |
| 2025 Poland Wiper Attacks (C0063) | Adversaries enabled TCP 445 on HMI devices with a new firewall rule named "Microsoft Update" | Monitor host firewall rule changes on HMIs, and treat a legitimate-sounding rule name as no assurance |
Dragos's FrostyGoop brief adds context: the January 2024 attack hit a municipal district energy company in Ukraine that heated over 600 apartment buildings, the router, management servers and controllers were not adequately segmented, and hardcoded routes let adversary hosts send Modbus commands directly to the controllers. Dragos also assessed with medium confidence that internet-accessible TCP 502 on the targeted controller type was the reason they were chosen. CERT Polska's report on the 29 December 2025 attacks dates the "Microsoft Update" rule on a Mikronika HMI to 8 December 2025, three weeks before the wiper ran, which is the window where firewall change monitoring would have paid off. For more on these families see the ICS Malware History Guide.
Detection: ATT&CK's analytics with the OT fidelity gate
ATT&CK v20 ships a detection strategy for T0885 with four analytics. All four share an "operational fidelity gate": alert only when the asset's documented role does not permit the connection and the destination is outside the approved communications profile, and suppress approved vendor support, update repositories, remote operations, failover paths and documented temporary connectivity.
| Platform | Data source named by ATT&CK | What to look for |
|---|---|---|
| Network devices | IPFIX or NetFlow records; Zeek ssl.log | Egress on 443, 80, 8080 or 53 from an ICS host on the "no external connectivity" role list to a destination outside approved vendor domains; TLS SNI or certificate issuer not matching approved vendors or their CDN |
| Windows | Sysmon Event ID 3 (network connection) | Connections on 80, 443 or 8080 from a process not on the ICS vendor update process allowlist |
| Linux | auditd SYSCALL records for connect() | An ICS service process connecting on a common port to a destination outside approved vendor domains |
| Embedded | Network security monitoring connection logs | A field device initiating an outbound connection on 443, 80 or 8080 outside its documented profile |
Add two OT-specific checks that follow directly from the procedure examples:
- Industrial protocol from an unexpected source: Modbus, S7comm, DNP3, EtherNet/IP or a safety engineering protocol reaching a controller from any host that is not a listed SCADA server, HMI or engineering workstation. Protocol-aware passive monitoring does this best. See the OT Network Security Monitoring Guide.
- Host firewall changes on OT Windows hosts: new inbound allow rules on HMIs, SCADA servers and engineering workstations, whatever their name. Forward Windows Firewall rule-change events to the OT SOC and review each against the change record.
Prevention: least functionality per zone
- Write the communications profile. For each zone and conduit list the approved flows: source role, destination, protocol, port and business reason. This is the baseline both the firewall and the detection gate rely on. The OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide covers the zone design.
- Deny by default at every conduit (M0930). ATT&CK's guidance is to block common ports that are unnecessary for that segment. Controllers and field devices should have no direct path to the internet, and level 3 hosts should reach external services only through a DMZ proxy with a destination allowlist.
- Close what is not used (M0942). Disable Telnet, web servers, SNMP and file sharing on devices and hosts that do not need them. Record each change so operations can reverse it.
- Remove internet exposure of industrial ports. Search your external address space for 502, 102, 20000, 44818 and similar listeners, and move any needed remote access behind a brokered solution. See the OT Remote Access Guide.
- Add protocol-aware inspection (M0931). Industrial firewalls or IPS that parse OT protocols can restrict which hosts may write, not just which may connect. Start in monitor mode for a full operating cycle, including maintenance windows, before blocking.
- Require authentication on controllers (M0804). ATT&CK's mitigation text asks that field controllers require users to authenticate for all remote and local management sessions, so an open port does not equal control.
Testing and rollback: apply new conduit rules in log-only mode first, compare hits against the communications profile for at least one full production cycle, then enforce in a pilot cell with operations on hand. Keep the previous rule set exported and a named person who can restore it within the agreed recovery time.
Decision guidance
| Situation | Practical choice | Trade-off |
|---|---|---|
| Small site, few staff, flat network | One firewall between IT and OT with deny-by-default, plus flow logging exported to IT's SIEM | No protocol awareness; catches egress to the internet but not misuse of Modbus inside the cell |
| Larger site with an OT SOC | Passive OT network monitoring at level 2 and 3, flow allowlists per conduit, alert on role violations | Needs an accurate asset role list and ongoing tuning with operations |
| Vendor needs cloud telemetry | Broker through a DMZ with a fixed destination list and TLS inspection where contracts allow | Inspection may break vendor certificate pinning; agree it with the vendor first |
| Legacy OPC Classic with wide dynamic ranges | Restrict OPC hosts to named peers, or move to OPC UA or a tunnelling gateway | Migration needs engineering time and vendor support |
Safe response
- Confirm with operations first: check whether the flow is a forgotten vendor support path, a failover link or a temporary commissioning connection before calling it hostile.
- Contain at the conduit, not the controller: block the destination or the flow at the zone boundary firewall, which is reversible, rather than isolating an HMI or controller that operators depend on.
- Preserve evidence: keep flow records, packet captures from the OT monitoring sensor, host firewall configuration exports and the change history for any rule that allowed the traffic.
- Check the other end: if a controller port was reachable from outside, review controller logic and configuration against a known-good backup before trusting process values.
The OT Incident Response Guide covers the full process with safety and operations roles.
Where identity fits
Common-port command and control usually starts with a foothold gained through a remote access account. In the CERT Polska case the attackers came in through a VPN portal using statically defined accounts without two-factor authentication. Vendor support accounts, shared engineering logins and service accounts on DMZ proxies deserve the same inventory, owner and rotation discipline as human administrators. See the Identity for OT Environments Guide.
Metrics that show it is working
- Percentage of conduits with a documented communications profile and deny-by-default enforcement.
- Number of industrial protocol listeners reachable from the internet (target: zero), rechecked monthly.
- Number of OT assets with outbound internet access that their role does not require.
- Role-violation alerts per month and the share closed as "approved but undocumented", which should fall as the profile matures.
- Median time from a new host firewall rule on an OT host to review against a change record.
Framework mapping
| Framework | Reference | How it applies to T0885 |
|---|---|---|
| ATT&CK for ICS mitigations | M0930, M0942, M0931, M0804 | Segmentation, least functionality, protocol-aware IPS, controller authentication |
| NIST SP 800-53 Rev 5 | SC-7 and SC-7(5); CM-7; SI-4(4) | Boundary protection with deny by default, least functionality, monitoring inbound and outbound traffic |
| NIST CSF 2.0 | ID.AM-03; PR.IR-01; DE.CM-01 | Documented data flows, protected networks, monitored networks |
| IEC 62443 | Zones and conduits | Each conduit carries only the flows the zone needs. See the IEC 62443 Guide |
| NIST SP 800-82 Rev 3 | OT security architecture | Segmentation and monitoring guidance for OT. See the NIST SP 800-82 OT Security Guide |
Common failure patterns
- "Allow 443 outbound" from level 3: granted once for a vendor update and never narrowed to named destinations, which is exactly the channel Sandworm used in 2015.
- Industrial ports reachable from IT or the internet: Modbus on TCP 502 open beyond the control network, the condition Dragos linked to FrostyGoop targeting.
- Trusting rule names: a host firewall rule called "Microsoft Update" was enough to pass unnoticed for three weeks in the 2025 Poland attacks.
- Port-only IDS signatures: alerts keyed on unusual ports miss traffic deliberately placed on common ones; role and destination context is needed.
- No owner for vendor flows: undocumented support paths make every alert look plausible and erode trust in monitoring.
Practitioner checklist
- Publish a communications profile for every OT zone and conduit, with an owner.
- Enforce deny by default at each conduit and log every denied and allowed flow.
- Remove direct internet access from controllers, field devices and level 2 hosts.
- Scan your external ranges monthly for industrial protocol listeners and close them.
- Deploy the four ATT&CK T0885 analytics with the role-based fidelity gate.
- Alert on new host firewall rules on HMIs, SCADA servers and engineering workstations.
- Restrict safety system engineering ports to the designated safety engineering station.
- Test new rules in log-only mode for a full production cycle, with a written rollback.
Standards and references
- MITRE ATT&CK for ICS: T0885 Commonly Used Port
- MITRE ATT&CK for ICS: M0930 Network Segmentation
- MITRE ATT&CK: S1165 FrostyGoop
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
- Dragos: FrostyGoop ICS Malware Intel Brief
- CERT Polska: Energy Sector Incident Report 2025
Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · OT Network Security Monitoring Guide · OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide · HMI and SCADA Server Hardening Guide · OT Security Operations Centre Guide