DET0736: Detection of Commonly Used Port
DET0736 is a detection strategy for spotting ICS adversary communications that hide on ports organizations commonly allow, such as web, DNS, OPC-related ra...
Analyst context for executives and security teams
DET0736 is a detection strategy for spotting ICS adversary communications that hide on ports organizations commonly allow, such as web, DNS, OPC-related ranges, and other routine services. The business issue is not the port itself; it is the assumption that “allowed” traffic is also “safe.” In industrial environments, that blind spot can weaken segmentation, SOC visibility, and incident response decisions when suspicious command-and-control or lateral communications blend into normal network flows.
Executive priority
Security leaders should treat this as a validation item for network monitoring and segmentation governance in ICS environments. Ask whether the organization can prove what protocols are actually running over commonly open ports, whether ICS network zones have baselined expected communications, and whether firewall exceptions are reviewed with enough evidence to support audit, resilience, and incident response decisions. This is especially relevant where operational continuity depends on distinguishing legitimate industrial traffic from traffic merely using a trusted port.
Technical view
The supplied ATT&CK relationship states that DET0736 detects T0885 Commonly Used Port in the ICS domain. Detection engineering should focus on identifying mismatches between port, protocol, source/destination role, and expected ICS communication patterns. Validate monitoring around commonly allowed ports and ranges listed in the related technique context, including TCP 80, TCP 443, TCP/UDP 53, and OPC-related TCP ranges 1024-4999 and 49152-65535. Because the detection strategy object has no official detection text and no specified platforms or tactics, teams should build local logic from asset inventories, network baselines, firewall policy, and protocol-aware inspection where available.
Likely telemetry
- Network flow records showing source, destination, port, protocol, byte counts, session duration, and timing
- Firewall and segmentation device allow/deny logs for commonly open ports
- DNS logs and resolver telemetry for TCP/UDP 53 activity
- Proxy, web gateway, or TLS metadata for TCP 80 and TCP 443 where present
- Protocol-aware network inspection or industrial network monitoring that can identify protocol-port mismatches
Detection direction
- Baseline which assets, zones, and conduits are expected to use common ports, then alert on new sources, new destinations, unusual directionality, or unusual timing.
- Look for protocol-port mismatches, such as non-HTTP traffic over TCP 80, non-TLS or unusual TLS metadata over TCP 443, or unexpected use of DNS transport.
- Tune detections against known industrial services and management workflows to reduce false positives from legitimate engineering, monitoring, or vendor-support activity.
- Correlate common-port traffic with firewall rule changes, new assets, remote access activity, or incidents involving ICS network segmentation.
- Do not rely on port-based monitoring alone; the related technique explicitly includes use of the expected protocol or a different protocol on a commonly allowed port.
Mitigation priorities
- Prioritize accurate ICS asset inventory and network zone/conduit documentation so common-port activity can be judged against expected behavior.
- Review firewall and segmentation rules that broadly allow common ports across ICS boundaries, and tighten them where business process requirements allow.
- Add or validate protocol-aware monitoring for high-risk ICS paths, especially where traffic over common ports crosses trust boundaries.
- Use change management and exception review to keep port allowances tied to asset owners, operational need, and expiration or recertification dates.
- Prepare incident response playbooks that include rapid validation of suspicious common-port sessions, affected assets, and whether the observed protocol matches the approved service.
Analyst notes and limits
This object is a detection strategy, DET0736, for the ICS ATT&CK technique T0885 Commonly Used Port. The official detection strategy record supplied here contains no description, no detection text, no tactics, and no platforms. The practical value comes from the relationship to T0885, whose supplied description explains that adversaries may communicate over commonly used or commonly open ports to bypass firewalls or network detection systems and blend into normal activity.
Assessment is limited to the supplied STIX fields, the MITRE external reference, and the relationship to T0885. No active exploitation, adversary attribution, affected products, guaranteed detections, or platform coverage are stated. Local network architecture, asset roles, firewall policy, and telemetry availability are required before converting this into production detection logic.
Detection of Commonly Used Port
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0885 | Commonly Used Port | This object detects Commonly Used Port. |
All related ATT&CK context
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | f676172fbf4b… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0736Open source URL
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.