Look for unexpected relay services, non-standard tunnel ports, remote access tooling on endpoints and command execution that stays local while only the tunnel is visible on the network. If the host runs a reverse proxy that your environment does not require, the likely purpose is to preserve operator access while reducing external visibility.
How reverse tunneling hides command traffic
Reverse tunneling works by shifting the visible network pattern away from direct operator-to-target traffic. The exposed connection often looks like an outbound session from the host to a relay, proxy, or remote access service, while the actual command stream moves inside that tunnel. That makes the host’s local process behaviour and the tunnel endpoint more important than the apparent source and destination pairs.
That distinction matters because defenders who only inspect inbound connections can miss the real control path. The tunnel may carry interactive shell traffic, file transfer, or tasking that never appears as a normal management connection on the wire. In practice, the question is less “is there a connection?” and more “does this connection make sense for this host, user, and service profile?”
When the tunnel is doing concealment work, the operator usually wants to preserve access while reducing external visibility. That means the traffic pattern can be intentionally mundane: long-lived outbound sessions, periodic keepalives, or a small number of allowed ports that blend into legitimate remote administration or proxy use.
Network and host signs that usually stand out
On the network side, look for unexpected relay services, unusual outbound paths, and non-standard tunnel ports that do not match approved remote administration tools. A reverse tunnel may terminate on a cloud host, VPS, or relay address that has no business relationship to the environment, especially when the destination changes frequently or uses ports that are atypical for the application owner.
On the endpoint side, check for remote access tooling, tunnel clients, or proxy utilities that were not installed or approved through normal administration channels. A common pattern is that command execution stays local to the endpoint while the only obvious network artifact is the tunnel process. That can make the host look quiet even though an operator is actively sending instructions through a separate channel.
Another useful clue is service mismatch. If a system suddenly runs a reverse proxy, listener, or relay component that the environment does not require, it may be there to preserve external reachability through an outbound path. The problem is not the presence of a proxy by itself, but the absence of a legitimate operational reason for it on that host and in that segment.
What to confirm before calling it malicious
Not every tunnel is hostile, so the first task is to compare the traffic against the host’s intended role and change history. Confirm whether the service owner expected remote administration, whether the port and destination are approved, and whether the process lineage matches a known toolchain. If the tunnel is tied to a sanctioned bastion, VPN, or support workflow, the same signals may be benign.
Cross-check the network evidence with endpoint telemetry. If the tunnel is real, you should usually be able to tie it to a process, parent process, service, or scheduled task on the host. If the network path exists but there is no credible administrative justification, or if local execution activity clusters around the same time, the case becomes much stronger.
Also look for persistence and recurrence. A one-off outbound connection can be noise, but a tunnel that re-establishes after reboot, survives user logout, or comes back on a schedule is more consistent with a deliberate access path than with incidental traffic.
Risk and Threat Considerations
Reverse tunneling is attractive because it can bypass perimeter assumptions and make operator traffic harder to distinguish from ordinary outbound communication. The main risk is not just concealment, but durable remote control that survives basic network filtering and frustrates simple source-and-destination review.
Failure mechanism: The tunnel relocates the control channel into an outbound session, so defenders may see only a benign-looking egress connection while commands, relay traffic, or interactive access continue inside the tunnel. That reduces visibility unless endpoint telemetry, process lineage, and destination reputation are also examined.
Impact: A hidden tunnel can preserve attacker access, enable repeated tasking, and delay detection of lateral movement or follow-on activity. If the tunnel endpoint is trusted operationally, the same path can also be reused for persistence after the initial compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1090 — Proxy | Reverse tunneling often hides command traffic through proxy-like relay paths. |
| T1071 — Application Layer Protocol | Tunnel traffic often blends into normal application-layer communications to evade notice. | |
| T1021 — Remote Services | Reverse tunnels commonly preserve remote access while avoiding direct inbound exposure. | |
| Recommendation — Map outbound relay behavior to proxy abuse and hunt for hidden control channels. Inspect application-layer sessions for command traffic masquerading as normal protocol use. Review remote service use and validate that each access path is authorized and expected. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | Tunnel concealment is detected through network monitoring and anomalous egress. |
| DE.AE-01 — Anomalous events are analyzed to understand attack targets and methods | Unexpected relay services and local-only execution require anomaly analysis. | |
| Recommendation — Monitor egress paths and flag unusual tunnel destinations, ports, and session patterns. Analyze unusual relay and proxy activity to determine whether it indicates concealed operator control. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Tunnel abuse is confirmed by correlating network and endpoint records. |
| AC-4 — Information Flow Enforcement | Reverse tunnels can bypass expected communication boundaries and flow restrictions. | |
| SI-4 — System Monitoring | Detecting hidden command traffic depends on host and network monitoring. | |
| Recommendation — Correlate logs across endpoint and network sources to validate the tunnel’s purpose. Enforce approved communication paths and block unauthorized outbound relay channels. Use host and network monitoring to identify tunnel processes, unusual ports, and persistent relays. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Network and endpoint logs are needed to spot concealed command channels. |
| CIS-13 — Network Monitoring and Defense | Non-standard tunnel ports and unexpected relays are network-defense signals. | |
| Recommendation — Centralize and review logs that show tunnel creation, relay use, and local execution activity. Alert on unusual egress tunnels, relay services, and destination changes. | ||
Practitioner Guidance
What to prioritise: Correlate the tunnel with the host process that created it, the destination’s business justification, and the time window in which local commands were executed. If those three do not line up, treat the tunnel as a lead, not a standalone indicator.
What to verify: Confirm whether the host should ever run relay, proxy, or remote access software, and whether the port, hostname, and certificate or key material belong to an approved support or administration workflow. A sanctioned tunnel should have a clear owner and an auditable reason to exist.
Practitioner takeaway: Hidden command traffic is usually exposed by inconsistency, not by the tunnel alone, so the strongest detections combine network visibility with endpoint context and a clean understanding of what that host is supposed to do.
Related resources from NHI Mgmt Group
- Why do secrets stay dangerous even when they are no longer actively used?
- What are the signs that Tor traffic is being used for automated abuse?
- What are the signs that automated traffic is being used for fraud rather than normal browsing activity?
- What are the signs that an SSH client may be used to exfiltrate credentials through DNS traffic?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org