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.
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.
[email protected]:~# 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.
First, I had to enable SSH root logins on my Kali host.
[email protected]:~# 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
[email protected]:~/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.
[email protected]:~# echo 1 > /proc/sys/net/ipv4/ip_forward
Next, I configured some iptables rules on the Kali box. These rules will:
- 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 220.127.116.11 on port 3389
- Add a forwarding rule to accept any TCP packets on port 3389.
[email protected]:~# iptables -t nat -A PREROUTING -p tcp --dport 3389 -j DNAT --to-destination 172.16.44.128:3389 [email protected]:~# 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.
[email protected]:~# 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.
[email protected]:~# 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.
[email protected]:~# 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.
[email protected]:~# 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.
Ray Doyle is an avid pentester/security enthusiast/beer connoisseur who has worked in IT for almost 16 years now. From building machines and the software on them, to breaking into them and tearing it all down; he’s done it all. To show for it, he has obtained an OSCE, OSCP, eCPPT, GXPN, eWPT, eWPTX, SLAE, eMAPT, Security+, ICAgile CP, ITIL v3 Foundation, and even a sabermetrics certification!
He currently serves as a Senior Staff Adversarial Engineer for Avalara, and his previous position was a Principal Penetration Testing Consultant for Secureworks.
This page contains links to products that I may receive compensation from at no additional cost to you. View my Affiliate Disclosure page here. As an Amazon Associate, I earn from qualifying purchases.