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:
- Stand up our honeypot, on a cloud hosted instance, capturing full PCAP data on port 3389. (This post)
- Setting up Moloch to process our PCAP data on a separate instance.
- Building a bot to extract IOCs from Moloch and share with the community through Twitter and Pastebin.
This process is tested and operational, resulting in the RDPSnitch Twitter bot, sharing daily IP addresses, usernames, and ASN information captured by our honeypot.
The latest Tweets from RDP Snitch (@RdpSnitch). A bot who snitches on RDP Scanners, sharing IOCs with the #DFIR and…
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)…
Last weeks a big activity on networks trying to attack RDP service , maybe a botnets looking an infected “zombies” on…
The Prep Work
A few things to consider before jumping in:
- 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?
- 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.
- 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
Remote Desktop Protocol in twisted python. RDPY is a pure Python implementation of the Microsoft RDP (Remote Desktop…
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.
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
screenfor 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 126.96.36.199 is the IP address of your Windows 2008 R2 host:
rdpy-rdpymitm.py -o ./ 188.8.131.52
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
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:
Congrats, the honeypot is live!
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.
-vvswitches increase verbosity of the output, while
-Xincludes 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-%Hpattern 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
-wand 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:
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.