How do you detect RDP tunnelling through SSH or Plink on Windows?

How RDP tunnelling through SSH or Plink shows up in telemetry

The behaviour is usually visible as a chain of events, not a single alert. On Windows, SSH or Plink may be launched to create a local forward, then an RDP client connects to the forwarded port on localhost or another loopback address. The key question is whether the host normally uses SSH at all and whether the local port is acting as a bridge to an RDP target that would otherwise be unreachable.

That makes process creation, command-line logging, and network telemetry equally important. A good hunt starts by lining up SSH or Plink execution with unusual listening ports, then checking whether the same host generates RDP logons that land on those forwarded ports rather than on the standard 3389 path. The pattern is often clearest when the forwarded port is non-standard but the RDP protocol behaviour is obvious.

For defenders who want a broader Remote Desktop baseline, NHIMG’s Remote Desktop (RDP) Security Guide covers exposure patterns, RDP logon monitoring, and session abuse signals that help you distinguish normal administration from suspicious forwarding.

What to correlate when a forwarded RDP session is suspected

Start with the process tree. Plink or ssh.exe running with port-forwarding arguments is the strongest indicator, especially when the command line exposes a local bind port, a remote destination, or both. Then correlate that process with loopback or local connections to the forwarded port, because the RDP client may never speak directly to the final destination on the wire.

Next, compare the network path with the host’s normal behaviour. Outbound SSH from a workstation that rarely uses it is a stronger signal than the same traffic from an admin jump host. Likewise, repeated connections to 127.0.0.1 or localhost on an unusual port, followed by successful RDP authentication, should be treated as a likely tunnelling sequence until proven otherwise.

When you need to distinguish the transport layer from the credential layer, SSH telemetry and key governance matter as much as the RDP session itself. NHIMG’s SSH Key and SSH Certificate Management Guide is useful for understanding how legitimate SSH usage should be controlled, rotated, and removed when it is no longer required.

How to block or validate suspicious tunnelling without breaking admin workflows

The practical challenge is that not every SSH forward is malicious. Some administrators genuinely use SSH or Plink as an ad hoc tunnel to reach legacy Windows hosts, so detection must be paired with allowlisting, change control, and host role awareness. If a workstation has no documented need for SSH, treat any successful forward as suspect until the business justification is confirmed.

Detection quality improves when you combine process, socket, and authentication evidence. The most useful pattern is a signed-in user who starts an SSH or Plink process, opens a local listener, and then immediately generates RDP logons through that listener. If you only monitor remote destination ports, you will miss the forwarding layer that made the connection possible in the first place.

For follow-up investigation, preserve the command line, parent process, destination host, bound local port, and the RDP session timeline. If tunnelling was not expected, review whether the same host also shows any other SSH activity, since that may indicate a reusable access path rather than a one-off shortcut.

Risk and Threat Considerations

RDP tunnelling through SSH or Plink can hide remote desktop access inside an encrypted channel, which reduces visibility for network controls and makes normal RDP detections less reliable. The risk increases when users can create forwards without approval, because the tunnel can become a quiet path to a sensitive system from a host that should not reach it directly.

Failure mechanism: An operator launches SSH or Plink, binds a local port, and forwards traffic to an internal RDP service. Defenders who rely only on direct 3389 monitoring may see a benign local connection instead of the real remote endpoint.

Impact: Unauthorised interactive access, weak attribution, and missed lateral movement are the main consequences, especially if the tunnel is used to reach an administrative target from an unmanaged workstation.

Practitioner Guidance

What to prioritise: Alert on the combination, not the tool alone. The highest-value rule is SSH or Plink execution plus a new local listener plus an RDP connection to that listener, because that sequence is much harder to explain as routine use.

What to verify: Check whether the host has an approved reason to run SSH forwards, whether the user normally administers systems this way, and whether the target RDP endpoint is reachable by any sanctioned path. If the answer to any of those is unclear, treat the session as suspicious and escalate for review.

Practitioner takeaway: The best detections tie command-line evidence to port-forwarding behaviour and then to the resulting RDP session, because the tunnel is the abuse path, not just the SSH process.

Related resources from NHI Mgmt Group

• How can you detect attackers enabling or weakening RDP settings on Windows?
• How do you detect EDR silencing through Windows Filtering Platform rules?
• How do you detect privilege escalation through weak Windows service permissions?
• How do you detect RDP logons from public IP addresses on Windows?