A month after RDP vulnerability BlueKeep was publicized, search engine Shodan shows there are still millions of devices exposing RDP on the Internet. If that wasn't bad enough, the giant GoldBrute botnet is also out there, slowly brute-forcing its way onto any RDP server it can find.

RDP is used for remote control of a Windows system, but was never designed for direct access over the Internet. It's buggy, especially older versions, and doesn't support modern security controls on its own. The prevalence of exposed RDP is particularly disconcerting, considering that the admins exposing it are generally not the type to keep their systems patched and with additional safeguards implemented.

In the spirit of BlueKeep, this tutorial will cover how to anonymize RDP using the same technologies that hide identities on the dark web.

Before We Begin

Warning! If you aren't already familiar with TOR, stop here. The TOR browser can access what is essentially an entirely different Internet, commonly referred to as the Dark Web, which often contains harmful, illegal, and very disturbing materials.  

Another warning: TOR is prone to mistakes, and for the inexperienced user there is a strong chance of accidentally revealing identifiable information.  Remember this if there is a genuine, potentially life threatening need for anonymity in your connection.

Disclaimer: There are few legitimate reasons I can think of for doing this. The information is provided for educational purposes only.

Going Dark

TOR is a service which seamlessly handles onion routing, the magic that keeps traffic untraceable. The service functions as a SOCKS proxy, and will route a SOCKS compatible service over the TOR network.  The proxy is accessible at the localhost address (127.0.0.1) on port 9150 by default. (The TOR browser, an offshoot of Firefox, is pre-configured to route through the proxy.  You can see this in the TOR browser's general options, under network proxy settings. A technical description of how onion routing works is available on the TOR website and elsewhere on the Internet).

Unfortunately the native Windows RDP client doesn't support SOCKS proxies.   We can download a nifty program called RDtoS5 which will bridge the gap for us.

Making the Connection

  • Download and install TOR and RDtoS5
  • Start TOR
  • Start RDtoS5
  • Click the "Start Log" button to show what's happening behind the scenes and display any errors
  • Leave the proxy address and port at the default settings
  • In the section "Forward Remote Desktop Traffc," enter the remote destination host and port (3389 by default)
  • Under the SOCKS5 proxy address, enter 127.0.0.1 and 9150. This points to to the local TOR proxy
  • Leave username and password blank (this is asking for credentials to the SOCKS proxy, not the remote RDP host)
  • Click the start button

‌Start the RDP client and connect to 127.0.0.1:757.  This will send the connection to RDtoS5, which will send it to the TOR proxy, which will send it to the destination via the TOR network.  Enter credentials and be sure to qualify the username with either a domain name or with .\ to signify a local account.  This will prevent Windows accidentally sending your workstation name in the credentials (as a general precaution, use a fake and meaningless hostname on your workstation).

Skinning the Cat

There are many ways to accomplish similar results.  Some other ideas to consider:

  • There are a few RDP clients avaialble which support SOCKS natively
  • Open source programs are available for applications which don't natively support SOCKS. Try torsocks or socat
  • Tails is usually a good idea

‌For anyone concerned, it is possible to script RDP connections over TOR, and it's a relatively simple task to add brute force capabilities. For a more targeted attack, it's also possible to leverage password dumps and general OS-Int to guess credentials.

Running RDP as an onion service, which can be used to hide the destination IP of an RDP server, is another possibility.  A good tutorial for this was published on All Things DFIR.  Make sure to block access from the open  Internet, and remember that anyone tunnelling the client over TOR, as described in this article, will be able to reach it.