DET0538: Detection Strategy for Protocol Tunneling accross OS platforms.
This detection strategy matters because protocol tunneling can let adversaries hide command-and-control traffic inside traffic that appears normal or permi...
Analyst context for executives and security teams
This detection strategy matters because protocol tunneling can let adversaries hide command-and-control traffic inside traffic that appears normal or permitted, potentially bypassing network filtering and reaching systems that would otherwise be inaccessible. Even though this ATT&CK detection strategy has no official detection text, its relationship to Protocol Tunneling (T1572) makes it a useful prompt for leaders to ask whether network visibility, egress controls, and SOC workflows can distinguish legitimate encrypted or tunneled traffic from suspicious encapsulation behavior.
Executive priority
Prioritize this as a resilience and visibility issue: if the organization cannot account for unusual tunneling, unexpected encrypted channels, or traffic relays across Windows, Linux, macOS, and ESXi environments associated with T1572, incident responders may lose time determining whether suspicious network activity is benign remote access, authorized VPN/proxy use, or adversary command-and-control. The business decision is not to block all tunneling, but to validate where tunneling is expected, who owns it, what is logged, and how exceptions are governed for audit and incident response.
Technical view
The supplied detection strategy object does not include official detection logic, tactics, or platforms, but it detects T1572 Protocol Tunneling, a command-and-control technique associated with ESXi, Linux, macOS, and Windows. SOC and detection teams should validate coverage around network connections that encapsulate one protocol inside another, especially outbound traffic to unusual destinations, unexpected use of VPN-like or encrypted channels, traffic that bypasses normal routing expectations, or systems acting as relays. IR teams should be prepared to correlate endpoint process activity with network flow, proxy, DNS, firewall, and authentication evidence to determine whether tunneling is authorized administration or suspicious command-and-control behavior.
Likely telemetry
- Network flow metadata showing source, destination, ports, protocol, volume, duration, and timing
- Firewall, proxy, secure web gateway, and egress filtering logs
- DNS query and response logs for destinations associated with tunneled sessions
- Endpoint process and network connection telemetry on Windows, Linux, macOS, and ESXi where available
- VPN, remote access, bastion, and proxy service logs for authorized tunneling baselines
Detection direction
- Establish baselines for approved tunneling, VPN, proxy, relay, and remote administration patterns before alerting on anomalies.
- Look for systems initiating persistent or high-volume outbound sessions to uncommon destinations or ports, especially where the traffic path does not match documented business use.
- Correlate network anomalies with endpoint process lineage and user identity to separate authorized administrative tooling from suspicious encapsulated command-and-control.
- Tune detections to reduce false positives from legitimate VPNs, developer tools, security scanners, cloud connectors, and managed service infrastructure.
- Validate visibility gaps where encryption, unmanaged endpoints, ESXi hosts, or limited network sensor placement may prevent inspection of encapsulated traffic.
Mitigation priorities
- Inventory and document authorized tunneling, VPN, proxy, and remote access mechanisms, including business owners and expected destinations.
- Apply least-privilege egress controls so systems can only initiate required outbound connections through approved paths.
- Centralize logging for network egress, DNS, proxy, firewall, VPN, and endpoint connection activity so IR can reconstruct suspected tunneled sessions.
- Review segmentation and routing controls to reduce the value of tunneling as a path to otherwise unreachable systems.
- Require change control and exception review for new tunneling services or persistent relays.
Analyst notes and limits
The ATT&CK object is a detection strategy, not a full technique description, and it has no official description or detection content. The practical guidance here is derived from the supplied relationship showing that DET0538 detects T1572 Protocol Tunneling, whose stated tactic is command-and-control and whose related platforms are ESXi, Linux, macOS, and Windows.
Coverage depends heavily on local architecture, encryption visibility, asset inventory quality, and whether network and endpoint telemetry are retained and correlated. The supplied fields do not provide specific analytics, data sources, mitigations, adversary examples, or evidence of active exploitation, so organizations must validate applicability against their own environment.
Detection Strategy for Protocol Tunneling accross OS platforms.
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 |
|---|---|---|---|
| Enterprise | T1572 | Protocol Tunneling | This object detects Protocol Tunneling. |
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 | 1fda3087372f… |
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 DET0538Open 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.