Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T0885: Commonly Used Port

Adversaries may communicate over a commonly used port to bypass firewalls or network detection systems and to blend in with normal network activity, to avoid more detailed inspection. They may use the protocol associated with the port, or a completely different protocol. They may use commonly open ports, such as the examples provided below. * TCP:80 (HTTP) * TCP:443 (HTTPS) * TCP/UDP:53 (DNS) * TCP:1024-4999 (OPC on XP/Win2k3) * TCP:49152-65535 (OPC on Vista and later) * TCP:23 (TELNET) * UDP:161 (SNMP) * TCP:502 (MODBUS) * TCP:102 (S7comm/ISO-TSAP) * TCP:20000 (DNP3) * TCP:44818 (Ethernet/IP)

ICST0885TechniqueObject v1.1 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Commonly Used Port matters because ICS environments often must allow traffic on ports that look routine, including HTTP/HTTPS, DNS, OPC ranges, Telnet, SNMP, Modbus, S7comm, DNP3, and Ethernet/IP. An adversary can use these allowed paths to blend communications into normal operations or to avoid deeper inspection. For leaders, the issue is not the port number alone; it is whether the organization can prove that traffic on allowed ports is expected, segmented, authenticated where feasible, and monitored without disrupting control or safety functions.

Executive priority

Prioritize this as an operational resilience and control-assurance issue for ICS networks. The technique targets a broad set of ICS assets, including workstations, HMIs, PLCs, RTUs, IEDs, historians, control servers, application servers, data gateways, VPN servers, jump hosts, routers, switches, firewalls, safety controllers, DCS controllers, PACs, and field I/O. Executives should ask whether firewall rules and remote-access paths are based on required systems and services, whether commonly open ports receive protocol-aware scrutiny, and whether security teams can produce audit evidence showing segmentation, authentication, and intrusion-prevention decisions are appropriate for real-time industrial operations.

Technical view

SOC, detection engineering, and IR teams should validate visibility and baselining for traffic using common enterprise and ICS ports listed by ATT&CK: TCP 80, TCP 443, TCP/UDP 53, OPC dynamic ranges, TCP 23, UDP 161, TCP 502, TCP 102, TCP 20000, and TCP 44818. Because ATT&CK provides no official detection text for this object, detection work should be anchored to the related detection strategy DET0736, local asset inventories, approved communication matrices, and ICS protocol expectations. The key validation question is whether traffic on an allowed port matches the expected source, destination, protocol, role, timing, and operational purpose, especially across business-to-ICS boundaries, jump hosts, VPN servers, firewalls, data gateways, control servers, HMIs, and field devices.

Likely telemetry

  • Firewall allow/deny logs for ICS, enterprise-to-ICS, and DMZ boundaries
  • Network flow records showing source, destination, port, protocol, direction, volume, and timing
  • Packet capture or protocol inspection for common ICS protocols such as Modbus, S7comm/ISO-TSAP, DNP3, Ethernet/IP, OPC, SNMP, Telnet, DNS, HTTP, and HTTPS where feasible
  • IDS/IPS alerts and signature matches at network boundaries
  • VPN server and jump host connection logs for remote access paths into ICS networks

Detection direction

  • Do not treat a common port as benign by default; validate whether the protocol and communicating assets are expected for that segment and asset role.
  • Tune detections around deviations from approved ICS communication patterns, such as unexpected source-destination pairs, unusual cross-zone flows, protocol mismatch on a common port, or new use of Telnet, SNMP, Modbus, S7comm, DNP3, Ethernet/IP, OPC, DNS, HTTP, or HTTPS paths.
  • Use DET0736 as the relationship-supported detection strategy reference, but confirm the local data sources required to implement it because the ATT&CK object does not include official detection details.
  • Account for false positives from legitimate engineering, maintenance, historian, gateway, and remote-access activity; compare alerts against change windows and approved operational workflows.
  • Pay special attention to boundary assets and pathways: firewalls, VPN servers, jump hosts, data gateways, routers, switches, and servers that bridge business and control environments.

Mitigation priorities

  • Start with network segmentation: isolate critical systems, functions, and resources; use DMZs for internet-facing services; and restrict network access to required systems and services only.
  • Review and reduce unnecessary services or software that expose commonly abused ports, consistent with the related mitigation to disable or remove unnecessary features or programs.
  • Apply network intrusion prevention at appropriate boundaries, with ICS-specific care so blocking does not disrupt real-time control or safety communications.
  • Require human user authentication before allowing access to data or accepting device commands where feasible, recognizing that strong multi-factor authentication may not always be practical in ICS and should be paired with related controls.
  • Maintain an approved communication matrix for ICS assets so firewall rules, monitoring, and incident triage can distinguish required operational traffic from unexpected use of common ports.
Analyst notes and limits

The relationship context is broad: this technique targets many ICS asset classes and is associated with the 2015 Ukraine Electric Power Attack campaign. That campaign relationship supports historical relevance, but it should not be read as evidence of current activity in any specific environment. The supplied object has no tactics, no platforms on the technique itself, and no official detection text, so local architecture, asset criticality, and operational constraints are decisive.

This take is limited to the supplied ATT&CK STIX fields, external reference, and relationships. It does not assert active exploitation, attribution, customer exposure, or guaranteed detection coverage. Platform references are limited to related ICS asset records, not the technique object itself. Detection and mitigation recommendations require validation against local ICS network design, safety requirements, maintenance practices, and available telemetry.

Official MITRE ATT&CK definition

Commonly Used Port

Adversaries may communicate over a commonly used port to bypass firewalls or network detection systems and to blend in with normal network activity, to avoid more detailed inspection. They may use the protocol associated with the port, or a completely different protocol. They may use commonly open ports, such as the examples provided below. * TCP:80 (HTTP) * TCP:443 (HTTPS) * TCP/UDP:53 (DNS) * TCP:1024-4999 (OPC on XP/Win2k3) * TCP:49152-65535 (OPC on Vista and later) * TCP:23 (TELNET) * UDP:161 (SNMP) * TCP:502 (MODBUS) * TCP:102 (S7comm/ISO-TSAP) * TCP:20000 (DNP3) * TCP:44818 (Ethernet/IP)

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Associated objects

Groups, software, and campaigns

Malware ICS

S1165: FrostyGoop

FrostyGoop is a Windows-based binary written in Golang that allows for interaction with industrial control system (ICS) equipment via Modbus TCP over port 502. FrostyGoop allows for reading and writing data to holding registers on targeted devices, manipulating the operation of systems for malicious purposes. FrostyGoop is associated with the FrostyGoop Incident in Ukraine.[1][2]

Control ServerField Controller/RTU/PLC/IED
Malware ICS

S0603: Stuxnet

Stuxnet was the first publicly reported malware to specifically target industrial control systems devices. Stuxnet is a large and complex malware that utilized multiple behaviors, including numerous zero-day vulnerabilities, a sophisticated Windows rootkit, and network infection routines.[1][2][3][4] Stuxnet was discovered in 2010, with some components being used as early as November 2008.[1]

Windows
Campaign ICS

C0063: 2025 Poland Wiper Attacks

2025 Poland Wiper Attacks is a Russian state-sponsored campaign that conducted destructive cyberattacks against Polish energy infrastructure in December 2025. Targets included more than 30 wind and photovoltaic farms, a combined heat and power (CHP) plant, and a manufacturing sector company. The attacks on the distributed energy resources (DER) disrupted communications between affected facilities and the distribution system operator, but did not impact electricity generation or heat supply. Across the campaign, threat actors deployed two previously undocumented wiper tools, DynoWiper, a Windows-based wiper and LazyWiper, a PowerShell wiper, distributed via malicious Group Policy Objects. At the CHP plant, threat actors had maintained access since at least March 2025, using that foothold to obtain credentials and move laterally before attempting wiper deployment. Some reporting has assessed the activity to be consistent with Russian Federal Security Service (FSB) threat activity group Dragonfly, also tracked as STATIC TUNDRA, while other reporting attributes the destructive wiper activities to the Russian General Staff Main Intelligence Directorate (GRU) threat activity group ELECTRUM, also tracked as Sandworm Team.[1][2][3][4]

Relationship explorer

All related ATT&CK context

mitigates · Mitigation M0804: Human User Authentication ICS targets · ICS Asset A0014: Routers ICS targets · ICS Asset A0013: Field I/O ICS detects · Detection Strategy DET0736: Detection of Commonly Used Port ICS targets · ICS Asset A0006: Data Historian ICS targets · ICS Asset A0011: Virtual Private Network (VPN) Server ICS targets · ICS Asset A0003: Programmable Logic Controller (PLC) ICS uses · Campaign C0063: 2025 Poland Wiper Attacks ICS targets · ICS Asset A0005: Intelligent Electronic Device (IED) ICS uses · Campaign C0028: 2015 Ukraine Electric Power Attack ICS uses · Malware S1165: FrostyGoop ICS mitigates · Mitigation M0931: Network Intrusion Prevention ICS targets · ICS Asset A0017: Distributed Control System (DCS) Controller ICS uses · Malware S1009: Triton ICS targets · ICS Asset A0016: Firewall ICS targets · ICS Asset A0010: Safety Controller ICS targets · ICS Asset A0001: Workstation ICS uses · Malware S0603: Stuxnet ICS mitigates · Mitigation M0930: Network Segmentation ICS mitigates · Mitigation M0942: Disable or Remove Feature or Program ICS targets · ICS Asset A0012: Jump Host ICS targets · ICS Asset A0009: Data Gateway ICS targets · ICS Asset A0002: Human-Machine Interface (HMI) ICS targets · ICS Asset A0018: Programmable Automation Controller (PAC) ICS
Mitigations

Mitigation direction

Mitigation ICS

M0804: Human User Authentication

Require user authentication before allowing access to data or accepting commands to a device. While strong multi-factor authentication is preferable, it is not always feasible within ICS environments. Performing strong user authentication also requires additional security controls and processes which are often the target of related adversarial techniques (e.g., Valid Accounts, Default Credentials). Therefore, associated ATT&CK mitigations should be considered in addition to this, including Multi-factor Authentication, Account Use Policies, Password Policies, User Account Management, Privileged Account Management, and User Account Control.

Mitigation ICS

M0931: Network Intrusion Prevention

Use intrusion detection signatures to block traffic at network boundaries. In industrial control environments, network intrusion prevention should be configured so it will not disrupt protocols and communications responsible for real-time functions related to control or safety.

Mitigation ICS

M0930: Network Segmentation

Architect sections of the network to isolate critical systems, functions, or resources. Use physical and logical segmentation to prevent access to potentially sensitive systems and information. Use a DMZ to contain any internet-facing services that should not be exposed from the internal network. Restrict network access to only required systems and services. In addition, prevent systems from other networks or business functions (e.g., enterprise) from accessing critical process control systems. For example, in IEC 62443, systems within the same secure level should be grouped into a zone, and access to that zone is restricted by a conduit, or mechanism to restrict data flows between zones by segmenting the network. [1] [2]

Change history

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 .

ATT&CK release
19.1
Object version
1.1
Created
Modified
Raw hash
c773157ad0dc5017...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle c773157ad0dc…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack T0885
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use