RDP Tunnel Your Way to Internal Networks

I wanted to share a few ways to setup an RDP Tunnel, as it’s proved very helpful during some engagements.

RDP Tunnel – Introduction

I’ve you’ve never performed RDP tunneling before, then it’s straightforward, and super useful during things like internal penetration tests.

You can also use it for accessing your own hosts, if you don’t want to use something like Guacamole.

For an in-depth write-up on bypassing some network restrictions using RDP tunneling, I recommend this FireEye post.

Finally, for another in-depth guide, I really like this Black Hills post for some of the things that it covers.

Enabling RDP

First, I configured my Windows “target” box to have a host-only network adapter.

Next, I enabled RDP and verified that the host was listening on port 3389.

C:\Users\IEUser>netstat -a | findstr LISTEN
  TCP    0.0.0.0:22             IEWIN7:0               LISTENING
  TCP    0.0.0.0:135            IEWIN7:0               LISTENING
  TCP    0.0.0.0:445            IEWIN7:0               LISTENING
  TCP    0.0.0.0:3389           IEWIN7:0               LISTENING

I then grabbed the IP address of the host, as this is what I would be connecting to.

C:\Users\IEUser>ipconfig

Windows IP Configuration


Ethernet adapter Local Area Connection 2:

   Connection-specific DNS Suffix  . : localdomain
   Link-local IPv6 Address . . . . . : fe80::f547:4c87:9209:9d40%14
   IPv4 Address. . . . . . . . . . . : 172.16.44.128
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

As you can see, my Kali box also had a network adapter on my host-only (172.16.44.0/24) network.

root@kali:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 00:0c:29:76:3e:f7  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.44.129  netmask 255.255.255.0  broadcast 172.16.44.255
        inet6 fe80::250:56ff:fe2f:ad0c  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:2f:ad:0c  txqueuelen 1000  (Ethernet)
        RX packets 3  bytes 746 (746.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 21  bytes 2112 (2.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Finally, I used rdesktop to verify connectivity from my Kali host to the Windows target.

Local Forwarding

First, I had to enable SSH root logins on my Kali host.

root@kali:~# tail -1 /etc/ssh/sshd_config 
PermitRootLogin yes

Next, I setup an SSH tunnel through my Kali box. The following command opens port 3389 on my local machine, and forwards it to port 3389

doyler@mbp:~/Documents$ ssh -L 3389:172.16.44.129:3389 [email protected]
[email protected]'s password: 
Linux kali 5.2.0-kali2-amd64 #1 SMP Debian 5.2.9-2kali1 (2019-08-22) x86_64

The programs included with the Kali GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Kali GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Nov 13 15:19:31 2019 from 172.16.8.1

I then setup an RDP connection to localhost using Royal TSX.

Unfortunately, I received an error when I tried to connect.

If you noticed above, I put the wrong IP address for the target (172.16.44.129 instead of .128). Once I corrected this error, I was able to successfully connect!

RDP Tunnel – Remote Forwarding

While my tunneling was successful, I wanted to expand on it a bit more. In this case, I wanted to be able to RDP to a box that would forward my RDP connection without having to first create an SSH tunnel.

This would be useful for scenarios where SSH wasn’t available, or for further tunneling into internal networks.

First, I enabled port-forwarding on my Kali box.

root@kali:~# echo 1 > /proc/sys/net/ipv4/ip_forward

Next, I configured some iptables rules on the Kali box. These rules will:

1. Add a rule to the nat table that will modify TCP packets as soon as they come in. Any packets intended for port 3389 will be forwarded to 172.168.44.128 on port 3389
2. Add a forwarding rule to accept any TCP packets on port 3389.

root@kali:~# iptables -t nat -A PREROUTING -p tcp --dport 3389 -j DNAT --to-destination 172.16.44.128:3389
root@kali:~# iptables -A FORWARD -p tcp --dport 3389 -j ACCEPT

With my firewall rules in place, I configured a new connection in Royal TSX.

Unfortunately, I was unable to connect initially.

When I looked at my iptables status, the rules were successfully capturing and modifying packets.

root@kali:~# iptables -t nat -L -v -n
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   47  2896 DNAT       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:3389 to:172.16.44.128:3389

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Additionally, I checked my conntrack file and saw a successful connection over port 3389.

root@kali:~# cat /proc/net/nf_conntrack
ipv4     2 tcp      6 431808 ESTABLISHED src=172.16.8.1 dst=172.16.8.155 sport=65061 dport=22 src=172.16.8.155 dst=172.16.8.1 sport=22 dport=65061 [ASSURED] mark=0 zone=0 use=2

I also ran a quick tcpdump on port 3389, to make sure that I was sending packets.

root@kali:~# tcpdump port 3389
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:28:26.251351 IP 172.16.8.1.65261 > kali.3389: Flags [SEW], seq 436934892, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1274886715 ecr 0,sackOK,eol], length 0
15:28:26.352071 IP 172.16.8.1.65261 > kali.3389: Flags [S], seq 436934892, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1274886815 ecr 0,sackOK,eol], length 0
15:28:26.453273 IP 172.16.8.1.65261 > kali.3389: Flags [S], seq 436934892, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1274886916 ecr 0,sackOK,eol], length 0

After a bit of debugging and searching, I found this ServerFault thread.

I hadn’t setup masquerading, so that was more than likely my issue.

root@kali:~# iptables -t nat -A POSTROUTING -j MASQUERADE

After updating my rules again, I was able to successfully connect to my Windows target vi my Kali box!

RDP Tunnel – Conclusion

I’m glad that I finally finished this post, as it is a useful technique for lab environments or internal penetration tests.

If you know of any simpler ways to setup this forwarding, then please let me know.

RDP is a great tool to use and is usually expected in target environments anyway.