3-Step RDP Honeypot: Step 1 | Honeypot Setup

Visibility is the name of the game in information security, and one way we can learn more about the risks to these internet facing remote desktop services is to attract and capture requests from bots, malicious actors, and other threats targeting this service.

This mini-series will walk thru the process of setting up a remote desktop honeypot, capturing requests to the service, processing the captured data, and operationalizing it for internal or external consumption. In our case, we will implement this plan with the following steps:

1. Stand up our honeypot, on a cloud hosted instance, capturing full PCAP data on port 3389. (This post)
2. Setting up Moloch to process our PCAP data on a separate instance.
3. Building a bot to extract IOCs from Moloch and share with the community through Twitter and Pastebin.

Our end goal is to generate a dashboard like this to help operationalize the RDP Honeypot request traffic.

This process is tested and operational, resulting in the RDPSnitch Twitter bot, sharing daily IP addresses, usernames, and ASN information captured by our honeypot.

RDP Snitch

Today we will cover step 1 in this process, setting up your own remote desktop honeypot, inspired by alt3kx’s original post:

Build an easy RDP Honeypot with Raspberry PI 3 and observe the infamous attacks as (BlueKeep)…

The Prep Work

A few things to consider before jumping in:

1. Let’s be thoughtful where we place our honeypot. In the case a threat actor is able to get in to the honeypot, what further damage could they do?
2. We will host this on a Linux system (for cost and accessibility reasons) though will need access to a Windows server to set up a spoofed RDP landing session.
3. And lastly we should define what we want to do with the data we collected. Implemented in subsequent posts, our ultimate goal is to capture requests and operationalize intelligence we can extract from the requests.

Since we are inviting the internet to scan and attack our honeypot, we should seriously consider hosting this service outside our networks on a separate instance, preferably cloud hosted to isolate further impacts. In our case, we are using a low cost cloud hosted instance of Debian 10.

Once initialized, we will need to set up a few tools on our instance (available via your package manager):

• tcpdump — To capture PCAP data for RDP traffic
• python-qt4 — Python bindings for QT4 UI framework
• xauth — X authentication utilities
• freerdp2-x11 — RDP Client to help setup our spoofed instance
• screen — Allow us to keep commands running on disconnection

And for our honeypot tools, we will need to install a Python 2.7 package using pip install rdpy. This toolkit, below, includes tools to host our RDP honeypot service. We will use a few tools from this kit, including rdpy-rdpymitm.py and rdpy-rdpyhoneypot.

citronneur/rdpy

Making the Honey

Now that we have our tools in place, we can generate the mock RDP session we will present to scanners. At this stage, we will need access to a Windows system. We tested this with a Windows 2008 R2 system, though as of writing this OS has reached its end of life support. For this reason, we are sharing the .rss file generated from this process to allow you to skip to the next section of this post if you are having issues with the following steps. Just download it from Pastebin and name it “win2008r2-rdp.rss” for ease of reference with the remainder of the post.

win2008r2-rdp.rss - Pastebin.com

Setting up a custom RDP Session

We will want to use a Windows server operating system as our target of the remote desktop connection; it is important to use a system where we can downgrade the security to not use network level authentication. For us, this was possible with a Windows 2008 R2 server hosted on Azure. Once we have this setup, we can move back to our Linux box to setup our capture of the session.

I recommend using screen for this part, though you can also open a second SSH connection to the Linux host.

In one terminal on our Linux host, run the below command, where 1.1.1.1 is the IP address of your Windows 2008 R2 host:

rdpy-rdpymitm.py -o ./ 1.1.1.1

In the second terminal, we will use our xfreerdp client to connect to our MiTM proxy, providing the username Administrator and forcing the client not to use Network Level Authentication:

xfreerdp --no-nla -u Administrator 127.0.0.1

In this case we do want to use the IP address 127.0.0.1 since that is where our man-in-the-middle proxy is listening for RDP traffic. You can also substitute “Administrator” for another username if you’d like, whatever you chose will end up in the recording displayed on an attempted connection.

A window should pop up and show the xfreerdp interface with a prompt to select a user account. There is no need to interact with the interface at this point and we can close out.

Feel free to use ctrl-c in the terminal with our MiTM script. You should see a new file in the same directory as the script, with the extension rss. This file contains a play back (which for bonus points you can view with rdpy-rssplayer.py) needed for the honeypot script.

We can now safely destroy our target Windows 2008 R2 instance and save on the cloud hosting fees! If it is an existing server, please remember to re-enable secure authentication protocols and disallow insecure options.

Starting the Honeypot

At this point we will want to use screen or nohup to start our honeypot and keep it running on disconnect (so we don’t have to keep our connection alive for the honeypot to remain up).

We should also evaluate setting it up as a start up task to survive reboots, though this guide won’t dive into those details as that varies widely depending on our Linux distribution.

Now we are ready to run the honeypot script, it is as simple as the below, where you provide the name of your RSS file as the only argument:

rdpy-rdpyhoneypot.py win2008r2-rdp.rss

Congrats, the honeypot is live!

Capturing Traffic

Now that our honeypot service is listening, we can configure our data capture utilities. This part is quick and painless, as much effort has gone into setting up PCAP captures.

While there are many approaches, we will use tcpdump to store the network traffic in PCAP format for further analysis.

Since tcpdump is already installed (if you’ve been following along), we can execute the below command to begin our captures:

tcpdump tcp port 3389 -i eth0 -vvX -w 'rdp.%F-%H.pcap' -C 100 -G 3600 -W 5 -U

This is another command that you will want to configure to run in the background and start following a system reboot.

Let’s break down this command:

• tcpdump tcp port 3389 — This invokes tcpdump and filters the capture to only 3389/tcp traffic.
• -i eth0 — This specifies your network interface to capture on. Please ensure that you’ve updated this to reflect the name of your desired capture interface.
• -vvX — The -vv switches increase verbosity of the output, while -X includes the data of each packet in the output
• -w 'rdp.%F-%H.pcap' — This instructs tcpdump to write the output to a pcap file with the specified pattern. The %F-%H pattern will produce a file named with the following date format rdp.2020-02-14-14.pcap, where it is the date and hour substituted in place of the formatters.
• -C 100 — This sets an upper limit for an individual PCAP file size, where if it is larger than 100 MB in this case (1000**3 bytes) it will create a new file using the filename pattern specified by -w and append an incrementing number, such as 1, to the name.
• -G 3600 — This defines a number of seconds that tcpdump should rotate the PCAP files; in this case once per hour.
• -W 5 — Specifies the number of segments (when paired with -C) that tcpdump will preserve before overwriting. In our case, we will keep 500MB of data before overwriting prior captures within the same hour.
• -U — Write packets to output PCAP file on receipt instead of once the buffer fills up.

Though it may seem like a monotonous list, these types of complex invocations are easy to digest when using a service such as ExplainShell.com:

https://explainshell.com/explain?cmd=tcpdump+tcp+port+3389+-i+eth0+-vvX+-w+%27rdp.%25F-%25H.pcap%27+-C+100+-G+3600+-W+5+-U#

Concluding thoughts

In this post we’ve accomplished setting up a honeypot that listens for RDP traffic, where, on connection shows an authentic RDP Login screen while not allowing authentication. Then we have leveraged tcpdump to record all request data on our honeypot 3389/tcp port to hourly PCAP files for our later consumption.

In the next post, we will operationalize this PCAP data — Processing all of the requests, extracting IP addresses and usernames, resolving IP address location and organization information, and generate statistics on the activity we see in the wild.