Welcome to the third and final part of the blog series on the RDP honeypot that I set up. The first part took a look at RDP and how it can be better secured, while the second post analyzed what the attackers did once they got into the honeypot. In this post I’ll talk about the honeypot itself, how it was set up, and what mistakes were made.

For those who don’t want to read through the detailed description, jump down to the tl;dr section at the end of the post for a synopsis of what I did.

Installing the Honeypot

My goal for this was to create an RDP honeypot that was 100% free (outside of the hardware) and could be easily saved and reset. To start off, I installed a new instance of Linux Mint (my preferred distro) onto an old laptop, locked it down a bit, and installed the VirtualBox virtual machine software.

Once that was installed, I needed to set RDP up somehow. I toyed with the idea of hacking the source of FreeRDP, but ultimately decided that was too time consuming. Plus, by this point I decided I wanted to see what the attackers did and not just log authentication attempts, so that meant I needed to install Windows—a free version of Windows. Fortunately, Microsoft helped me out with this.

Microsoft offers free 90-day virtual machines for download in order to test applications and browsers. The VMs are fully featured versions of Windows 7, 8.1, and 10 and were perfect for my honeypot. Since I was using an older laptop, Windows 10 wouldn’t run well on it, so I opted for the IE10 on Windows 7 VM.

The VM itself was set up to have two (2) processors and 8 GB of RAM. Often VM-based honeypots and sandboxes will be given a single processor and 4 GB of RAM, which attackers and malware know to look for. Increasing these resources makes the VM look more legitimate.

Tasty, Tasty Morsels

Once Windows was installed, it needed to be configured. I wanted to give attackers some juicy morsels to tempt them to attack the box, so I decided to turn the honeypot into a payroll system that was being reimaged. I started by renaming the system 'payroll.'

The free Windows VMs come with a user named IEUser, which could be a good way to fingerprint a potential honeypot. Therefore, I renamed this account to 'payroll' and set the password to 'password.' This would make the honeypot easy to break into, but the attackers still had to work a little as payroll isn’t a default Windows account.

To continue to make the system look legitimate, I downloaded a number of random documents from the Internet and renamed them interesting things like accounts payable.xls and employee records.pdf. Further, in order to make it less suspicious since there wasn’t much on the system, I added a readme.txt file on the desktop, which was a note from the systems administrator to the owner, stating they hadn’t finished restoring their computer and would do so after the holidays.

Did that work? Yes! There were multiple times when I saw attackers open up the documents to see what was in there. Sadly, I did not use any canary token documents to get more intelligence. That will be in version 2 of the honeypot.

Somebody’s Watching Me

Next, I had to set up some type of instrumentation, so I could actually see what the attackers were doing. I started by turning up Windows event logging using Malware Archaeology’s Windows Logging Cheat Sheet, one of the best security resources online. This included turning on Process Creation Logs (event ID 4688) with command line logging turned on, Account Logon and Logoff events, Filtering Platform Connection events, and many more.

Additionally, I downloaded and installed Microsoft Sysmon. While the logs I had already turned on would grab process creation information, I wanted Sysmon to act as a second source of information in case the attackers cleared the Security Event Logs. Sysmon also records other information such as the hash of the executing program and the command line of the parent process. This information turned out to be invaluable during my later analysis.

To configure Sysmon, I used SwiftOnSecurity’s Sysmon configuration as my starting point and turned off a few things I wasn’t concerned about. This was mainly done for performance reasons, as my VM wasn’t getting a lot of resources due to it being on older hardware.

Since many attackers use PowerShell, I didn’t want to leave that out. I upgraded the PowerShell to version 5 to take full advantage of logging capabilities, and then turned on ScriptBlock and ModuleLoad logging within the local Group Policy. I also set up PowerShell transcript logging so I could see exactly what attackers were running. If you don’t know how to do this, check out Malware Archaeology’s PowerShell Logging cheat sheet.

I needed a way to look at the logs without having to log on to the system. For that, Humio came into play. Often compared to Splunk and Graylog, Humio is an online service that you can send your logs to and query from a web-based console. The best part is that Humio has a free tier that limits you to 2GB of data per day, and a seven-day retention. For this honeypot, that was more than enough.

Once again, Malware Archaeology’s cheat sheets were invaluable in getting this set up. After logs were being sent to Humio, I set up an alert so that any time a successful logon occurred I would get an email notification. This way I could look at all the logs in near real-time.

Finally, I wanted to actually see what the attacker was doing on the honeypot. After looking at a number of screen-recording software, I ended up on ffmpeg, which is command-line based and free. To prevent it from popping up a window or icon when it ran (and thus notifying the attacker they were being recorded), I wrote a small batch script and converted it to an executable using BAT to EXE Converter. So it would start up when an attacker logged on, the executable was set up through the HKCU Run key as well as a scheduled task.

Unfortunately, this failed. Hard. Despite it working in my testing, videos of the screen only successfully recorded once out of all the times attackers logged in. The recording would start and then a few seconds later would mysteriously die. I never had a chance to troubleshoot the issue, so I still don’t know why it didn’t work.

Traversing the Network

Lastly, the honeypot needed network and Internet connectivity. To create something of a barrier between my network and the honeypot, I set up the VM to be in NAT mode within VirtualBox. To allow attackers to still access RDP, port forwarding was set up so any incoming connections to the host OS on TCP/3389 would be forwarded to the same port on the virtual machine.

This did cause one issue. Since port forwarding was being used, any RDP connection being forwarded would appear to be coming from the IP address of the host system and not the actual source from the Internet. As a workaround so those IP addresses could be recorded, along with other network information, the Zeek IDS (formerly Bro) was installed on the host system. Using this to monitor all network traffic allowed me to correlate RDP connections with IP addresses.

After that was done, I allowed RDP into the system from the Internet and waited. As was shown in part 2 of this series, I didn’t have to wait long.

Lessons Learned

In the end, the honeypot was successful. I got the data I set out to get and gained some amazing insight into the activities of attackers. However, there are definitely things that could have been done better.

• Passwords - While my instrumentation allowed me to see the user IDs that were being sent in the brute-force attacks, I was blind to the passwords. Since my honeypot was run, some very smart interns at GoSecure came up with a potential solution that I will be looking at closely the next time around.
  
  
• Desktop Recording – The desktop recording I attempted was a huge fail. The previously mentioned GoSecure post has another potential solution, which I will look at as well. Fortunately, this failure didn’t prevent the honeypot from getting the data I needed, but it would have been a nice enhancement.
  
  
• Network Addresses – My network architecture had a huge gap in it—the inability to see the true source of the incoming connection in the honeypot logs. While I was still able to correlate the data, this was an extra step that could have been avoided.
  
  
• Limited Attack Visibility – During the execution of the honeypot, I never let the attack go longer than the initial compromise. This was mostly due to the data I wanted to gather, but it would be interesting to see what happens on a long-term honeypot after the attacker does the initial compromise. How long does it take them to come back? What do they do? What happens if there are other resources for the attacker to access?

My plan is to incorporate fixes for these lessons into the next version of the RDP honeypot. This will allow better, more in-depth data for analysis. Expect to hear some more results in a few months' time!

tl;dr

1. Install VirtualBox onto a Linux VM
2. Download and install free Windows from Microsoft into VM
3. Configure VM to look normal (e.g., 2 processors, > 4 GB RAM)
4. Install Sysmon
5. Turn up Windows logging
6. Forward logs to free Humio instance
7. Monitor the network
8. Open the VM up to the Internet
9. Wait for the bad guys