Skip to main content

RDP Over Tor

Happy Tuesday, everyone! Recently, I encountered a threat actor leveraging Tor to establish Remote Desktop Protocol (RDP) sessions from a victim system to an attacker-controlled server. The best part of this is, because the threat actor was using Tor, all encrypted communications were sent over port 443. Therefore, there wasn’t any evidence of RDP (port 3389) being used on the network illegitimately. In fact, we could have closed port 3389 on their firewall and the attacker would have still had access to the system via RDP. I found this very sneaky by the threat actor, but realized how simple it was to configure it and thought I would share it with everyone. In this blog post, we will cover the basics of proxying RDP traffic over TOR and how to set it up, with tips to avoid being detected.

Before We Get Started
For those of you who are unfamiliar with Tor, it’s a free and anonymous network that provides anonymity when browsing the Internet. Also known as “The Onion Router”, users of this service can “employ this network by connecting through a series of virtual tunnels rather than making a direct connection, thus allowing both organizations and individuals to share information over public networks without compromising their privacy” (Tor Project). In case you were wondering where or how to try this web browser out, download Tor from their website (www.torproject.org).

At the time of this blog post, we were using a Windows Server 2016 Datacenter to access via RDP, Parallels Remote Application Server version 16.5.0 to use as an RDP client with proxy capabilities, and Tor Browser version 7.5.6. This was tested in a network that we built specifically for this demo/exercise.

IMPORTANT NOTE: This blog post is intended for educational purposes only. Do not try this on systems and networks that you do not own or do not have the permission to test.


Setting Up
In order to set this up, you first need to download and install Tor Browser (www.torproject.org) on your system. Once you do that, make sure that you run it at least once so the configuration files for Tor get created for the first time. I have set my Tor installation path to be on the Desktop folder for my user account: “C:\Users\Administrator\Desktop\Tor Browser”. For the sake of this demo/exercise, I will be referencing “%TorInstallPath%” as the directory where you have installed Tor.

Once you have executed Tor, close the browser and open up the following file in any text editor: “%TorInstallPath%\Tor Browser\Browser\TorBrowser\Data\Tor\torrc”. You should see something similar to the contents in the figure below:


Figure 1: Contents of the file “%TorInstallPath%\Tor Browser\Browser\TorBrowser\Data\Tor\torrc”

The “torrc” file is a configuration file that contains instructions and settings that tell your Tor browser how it should operate. For a full list of the commands that you can add to your “torrc” configuration file, you can refer to Tor Project’s manual page (www.torproject.org/docs/tor-manual.html.en). For our exercise we will create a hidden service that runs in the background without having a Tor window open. To do that we will need to modify the “torrc” configuration file and add two lines to it.

The first line that we will be including is “HiddenServiceDir”. This is a directory for the Tor browser to store files related to the hidden service that we will be creating. I have created the directory “%TorInstallPath%\Tor Browser\hiddenService” just to keep it simple. The first line that we need to add looks something like this:

HiddenServiceDir C:\Users\Administrator\Desktop\Tor Browser\hiddenService

By creating this directory, Tor will create a “hostname” and a “private_key” file. These files are pretty self explanatory, but for this demo, we will be focusing on the “hostname” file as it will contain the “onion” address that we will need to use to later connect to our host.

The second line that we will need to add to the “torrc” configuration file is “HiddenServicePort”. This tells the Tor hidden service to redirect any traffic that comes from a specific local port, to a different port that you have set it for. For this exercise, we will be using port 80 to tunnel RDP traffic (port 3389) from our server. This is what the second line that we need to add looks like:

HiddenServicePort 80 127.0.0.1:3389

Now that we have added these two lines, the “torrc” configuration file should look something like the following figure below:


Figure 2: Contents of the file “%TorInstallPath%\Tor Browser\Browser\TorBrowser\Data\Tor\torrc” after modification

After saving the “torrc” configuration file, open up a Tor Browser. Once a Tor connection has been established, leave the Tor Browser open and go to the hidden service directory that we added to our Tor configuration file. As mentioned before, you will see two files being created. The “hostname” file is what is important for this demo, as this is the onion address that we need to connect to the server (save this address for later use). Refer to the figure below for a sample excerpt of what to expect in the “hostname” file.


Figure 3: Contents of the file “%TorInstallPath%\Tor Browser\hiddenService\hostname”

Now that we have configured the server, we simply need to configure the client to be able to connect to the server via RDP over Tor. For now, let’s leave the server with the open Tor Browser on the side so that we can focus on setting up the client. To configure the client system, simply install Tor Browser and modify the “torrc” configuration file on the client to include a configuration for a SOCKS port. The SOCKS port will allow our RDP client to proxy and connect to the server via RDP using an onion address. To make that modification on the Tor configuration file, we added the following line to it:

SocksPort 127.0.0.1:9050

After making that change to the configuration file, open up a Tor browser on the client and leave it open. By keeping the Tor Browser available, the SOCKS port that you have created will remain open. Now, onto the fun part: In this demo, we are using Parallels Remote Application Server (Parallels Client) as our RDP client. This application allows us to “customize” our RDP connection by including a proxy setting, thus making it much easier for us to establish a connection to our server over Tor. However, before we can connect to our server we need to make some modifications to our RDP connection on our Parallels Client.

Once you have the Parallels application installed, create a new connection and select the “Standard RDP” option. When a new window pops up, click on “Advanced Settings >” and from there you can customize the settings  you want. As mentioned earlier, we need to establish a proxy that usesour Tor service so that we can communicate to our server using its onion address. To configure this, we have to change the settings on the “Network” and “Connection” tab within the advanced settings view. On the “Connection” tab, we included the onion address and the port number (Port 80) that we assigned on the server using the “HiddenServicePort” setting. On the “Network” tab, we rerouted our traffic to our local host on the SOCKS port (Port 9050) that we have assigned for it. The following figure depicts the changes made to the settings on Parallels Client as a reference.

Figure 4: Advanced settings for a new connection on Parallels Client

As shown in the figure above, this will allow us to establish a connection. The figure below shows what that connection should look like using Parallels Client.
Figure 5: Screenshot of an active RDP session over Tor using Parallels Client


Taking It Further

Now that we have successfully established an RDP connection over Tor, there are a lot of things that we can do to make our “presence” less obvious. For example, if a legitimate user spots an open Tor browser on their session, they will most likely be inclined to close it. To avoid that, you can run Tor via the Command Prompt in Windows. Additionally, you can specify the “torrc” configuration file via command-line arguments to the TOR executable in case you have multiple configuration files or are explicitly testing your configuration, without unintentionally loading default configurations. However, if you don’t specify the configuration file, it will ultimately take the one that is within the installation directory. You can run the following command in Windows to run Tor in the background using a specific configuration file:
tor.exe -f “%TorInstallPath%\Tor Browser\Browser\TorBrowser\Data\Tor\torrc”

Note that in the command highlighted above, make sure that you specify the Tor installation path instead of “%TorInstallPath%”. For our demo in this blog, we would have used “C:\Users\Administrator\Desktop\” if we were to run the command via a Command Prompt in Windows.

Another way to take this to the next level would be by creating a service. You can either use Windows to create a service or a third-party application. I personally would use “Non-Sucking Service Manager” (NSSM) (www.nssm.cc) to do this. There are some drawbacks for using NSSM or other third-party applications for creating a service, including having more of your tools on the remote system. A threat actor would generally try to live off the land as much as possible to reduce their visible footprint on disk and forensic artifacts generated by their actions. However, should you choose to install Tor as a service using Windows, you can run the following command in a Command Prompt session on a Windows system:
tor.exe –service install

If you’re like me, and would rather use NSSM to create a service, you can run the following command, which will spin up the NSSM’s graphical user interface (GUI):

nssm.exe install <servicename>

Note that for service name, you can put in the name of the service that you would like. However, you can still change it when the GUI spins up. Once it does, you will be able to customize the service by indicating the application path and the arguments that you would like to include for whenever the service runs. In terms of what you will include, you can refer to the first command that we mentioned in this section, where you specify the “torrc” configuration file upon the execution of Tor via Command Prompt in Windows. The following figure provides a screenshot of the NSSM GUI, which has the sections filled out for our demo.
Figure 6: Screenshot of NSSM with the settings configured

As you can see in the figure above, we simply specify the “Path” (it will automatically fill out the “Startup directory” field), the “Arguments”, and the “Service name” fields and we can create a service on Windows.

As you can see, from a security analyst’s perspective, if they spot this service being created, the first thing that stands out is Tor; here are a couple of additional things that you can do to make it less obvious:

  • Change the service name to something less conspicuous such as “Windows Backup”, “Firefox Update”, or even “Windows Defender Update Service”.
  • Change the directory or the path for where the “torrc” configuration file and the Tor executable are located, to a directory that may seem far more legitimate, such as “C:\Windows”, “C:\Windows\System32”, “C:\Users\Admin\AppData\Local\Microsoft\Internet Explorer”, etc.
  • Change the name of the executable and the configuration file. Instead of using “tor.exe” or “torrc”, you can change it to something such as “cmd.exe”, “config”, or “update.exe”.
  • If you would like to create a far more sophisticated service with NSSM, you can modify items in the “Details” tab, which include “Display Name”, “Description”, and “Startup type”. By modifying these fields, it will make your service appear far more legitimate.

There are many ways that you can take this to the next level, and these are some things that can help you get started. From a naming convention standpoint, if you are stuck thinking about different service, file or folder names, take a look at the system and look for tools and utilities that are used. Try to rename your Tor service and/or tool names with things that you see on the system. This will help you stay unnoticed.

Comments

Popular posts from this blog

Revealing malware relationships with GraphDB: Part 1

In this post, we will learn how using a Graph Database like Neo4j can help visualize malware relationships and extend these relationships to identify patterns between samples. Before we dig into Neo4j, let’s start with some fundamental graph terminologies:   
Nodes represent entities such as a human, car, laptop or phone. Properties are attributes nodes can contain. A steering wheel or tires would be a property of the “car” node. Labels are a way to group together nodes of a similar type. For example, a label of “FastFood” may include nodes such as “Taco Bell, McDonald’s, and Chipotle”. Edges (or vertices) represent the relationship connection between two nodes. Relationships can also have their own properties. Getting started with Neo4jLink: https://neo4j.com/
Neo4j is a Graph Database commonly known for its pure simplicity and easy to use interface. I find the structure of a graph database quite fascinating, on top of learning how to normalize malware analysis data for each sample into a …

Analyzing and detecting web shells

Of the various pieces of malware i’ve analyzed, I still find web shells to be the most fascinating. While this not a new topic, i've been asked by others to do a write up on web shells, so here it is ;). 
For those new to web shells, think of this type of malware as code designed to be executed by the web server - instead of writing a backdoor in C, for example, an attacker can write malicious PHP and upload the code directly to a vulnerable web server. Web shells span across many different languages and server types. Let's take a looks at some common servers and some web extensions:
Operating System Service Binary Name Extensions Windows IIS (Internet Information Services) w3wp.exe .asp/.aspx Windows/Linux apache/apache2/nginx httpd/httpd.exe/nginx .php Windows/Linux Apache Tom

Introduction to Malware Analysis

Why malware analysisMalware analysis (“MA”) is a fun and excited journey for anyone new or seasoned in the career field. Taking a specimen (malware sample) and reverse engineering it to better understand its inner workings can be a long, tedious adventure. With the sheer number of malware samples circulating the internet, in addition to the various formats specimens are found in, makes malware analysis a good challenge. Outside of learning MA as a hobby, here are some other reasons why we perform malware analysis:To better understand how a specimen works. This may yield certain unique attributes about how the malware was written, methods it performs or its dependencies.To collect intelligence and build Indicators of Compromise (“IOCs”), usually comprised of Host Based Indicators (“HBIs”) and/or Network Based Indicators (“NBIs”).For general knowledge or research purposes.How do I get started?!If you’re new to malware analysis, you want to ensure you’ve taken the right precautions befor…