Chapin Bryce
Posted on November 20, 2019
This is a short post, largely inspired by alt3kx and their awesome post here:
Build an easy RDP Honeypot with Raspberry PI 3 and observe the infamous attacks as (BlueKeep) CVE-2019–0708 | by alt3kx | Medium
alt3kx ・ ・
Medium
Please go check it out!
Where this post differs is implementing on a Debian cloud instance of your choice and adding in email reporting. We will run through all the steps just to have a cohesive post, though most of the steps do mirror those in the aforementioned post.
# Requirements
We will be setting up in a virtual/cloud-based environment. This has pros/cons (versus your own RaspberryPi or other hardware), though we can save that for the comments ;)
- Access to a Windows 2008 R2 server that you don’t mind making insecure temporarily. One option is to spin up an EC2 instance in a new security group just for this sole use. You can also use Azure/other platforms supporting Windows 2008 R2 images.
- A Debian based compute instance on your cloud hosting provider of choice. This will actually host our honeypot, so we will want to set this up separate from everything else. This guide won’t walk thru a hosting provider specific setup, as there are too many to cover. You will also want to ensure you have X11 forwarding configured over SSH.
# Windows 2008 Setup
- Spin up both your Windows 2008 R2.
- RDP into the Windows 2008 R2 instance and disable “Network Level Authentication” (this guide walks through the process).
# Debian/Honeypot Setup
This setup has a few more stages:
## Installing and configuring RDPY
This honeypot will leverage the GitHub project RDPY, as it covers the tooling needed to setup an RDP listener on a Linux host. This can be installed using a Python 2.7 version of pip
.
pip install rdpy
We will also need to install a few more tools using apt install python-qt4 xauth screen freerdp2-x11
. You may need to install pip
as well.
Once these are setup (and X11 forwarding is configured for your SSH session) we will generate the fake RDP prompt that will show on connection.
I recommend using screen for this part, though you can also open a second SSH connection to the host.
In one terminal, 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
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.
At this point we will want to use
screen
ornohup
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 can safely destroy our Windows 2008 R2 instance now and save on the cloud hosting fees!
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 \*.rss
Congrats! The honeypot is live!
## Getting intel out of your honeypot
This next step is where we can automate a few tasks to send reports to our mailbox.
To start, we will want a few tools to capture, process, and report on the activity. Let’s install them:
apt install tcpdump bro bro-aux zip
We first will use tcpdump to capture all traffic on TCP/3389 into a PCAP file:
tcpdump tcp port 3389 -i eth0 -vvX -w ‘rdp.%FT%H-%M-%S.pcap’ -C 500 -G 86400 -W 10
Please sub in your own interface (ie eth0) and file naming convention. For full details on this tcpdump command line, check ExplainShell. This capture should also run as an admin in a screen or
nohup
session to prevent it closing on disconnect. Neither of these solutions will assist in the case of a reboot.
Now we can move to our report generation! For this, we will use bro to generate easy to consume logs from the PCAP files. We will then take these logs and create a summary report that we send via email. This is all possible in the below script (please modify as you see fit!)
You will need to sub in your own information for Mailgun if you want to use that API, otherwise feel free to plug in your own email sending routine.
Now that we have the script setup, we can create a cron job to run it for us daily and fill our inbox with a summary of what we caught in our honeypot!
Please play around with this configuration and fine tune further to your liking. If possible, please share back to the community!
Posted on November 20, 2019
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.