Prior to the holidays, I helped start put together a work project that then spun me off to take on this personal project to allow me to get a better handle of the problem. The goal was to better understand how attackers are leveraging RDP and how an organization can deploy security measures to protect their instances. This goes beyond traditional types of honeypots which are typically using some form of simulated service to be able to captured different types of indicators such as dropped files + IP addresses.
By deploying a fully functioning RDP server we would be able to gather much more detailed information from the attackers that would help us better understand the TTPs and what to look for as potential indicators of malicious activity. For this very first blog on the topic, I’ll cover the step by step process of setting up your very own honeypot including leveraging some build in functionality within the cloud environment, in this case using AWS.
Build Principles
Since I’m a huge fan of the KISS (Keep it Simple Stupid) philosophy, I decided to embark into as a simple build process and try to leverage as many built in capabilities found in AWS to make the process easier for me. Obviously there’s some lessons I have learned the hard way, so hopefully I can provide enough information for you not to have to repeat those same errors. At the end of the process you should have a running Windows Server 2016 with centralized logging. This isn’t the only way to set one of these up and I’m sure that there are better ways, but I wanted to share my process so that other people can also leverage it.
Getting Started
Step 1: is set up an account on the AWS. Not much involved with process, you will of course need to provide a credit card and all that fun jazz.
Step 2. Build your base system. For my build, I choose to leverage a Windows 2016 server, you can choose whichever version of Windows you want based on what you want to test and what type of information you really want to collect.
Since this is an intentionally weak system, you will have to be diligent in terms of maintaining the security groups. I created three main security groups:
One is the World Open, in which I open up RDP (3389) to everyone inbound and open outbound.
Second security group, Restricted, is the one I used to configure the systems in which I feel they’re safe, I will whitelist only my external IPs to access RDP and open outbound.
Last security group I used is my Isolate, I will whitelist my inbound and block ALL outbound traffic except RDP traffic to my IP address. The reason we block the outbound is that from the drops I’ve seen, adversaries like to maintain their persistence beyond just using the same door they first came in through.
Step 3. Configure IAM Roles. IAM roles grants out permissions to different AWS resources and is key to allowing the system to interact both with System Manager and Cloud watch. You’ll want to create the following policies [AmazonEC2RoleforSSM and CloudWatchAgentAdminPolicy], which I have named as cloudwatch_agent. This role will then be attached to the newly spun up EC2 instance.
Step 4. Set up SSM System Manager is installed by default on the Windows and Linux versions of images provided by AWS, however you need to provision them access back to AWS to allow them to show up in your managed instances. So if you’re opening your system manager “managed instance” view and your need seeing your instance, try this simple trick by creating a new IAM role that allows access right to write to system manager (also key if you want to save your locally build CWA configuration to aws so your other agents can leverage it.) Make this change and hopefully you should see your instance now in the managed instance list.
Step 5. Set up cloudwatch agents on the system. Since I’m going fully AWS native for this build and I want a means of collecting logs off of the system, I’ll be using cloudwatch agents to forward logs to my cloudwatch instance and ultimately into elasticsearch (if that’s what I want to do). There’s multiple ways that you can set up the cloudwatch agent (CWA), you can manually log into the system and pull down the package OR you can use build in AWS functionalities such as SSM to help you with the process. You’ll use the SSM configuration from the previous step to push a cloudwatch agent to the system. Go to ‘RUN COMMAND” and select AWS-ConfigureAWSPackage and select install with name of AmazonCloudWatchAgent. Hopefully you should be able to push the Run command option and have the platform set up cloudwatch.
Step 6. Some system configurations. Before I let the system loose, there were a few changes I wanted to make. My first focus was to get an understanding of how much damage a regular user can cause on a system (spoiler alert, alot). The first of which I wanted to change the name of the real Administrator account to something that reasonably wouldn’t be brute forced, since I really want to get our attackers to use a fake Administrator with just username. After I had renamed my real Administrator to something secret, I then created my fake Admin account, called “Administrator”, put them in the RemoteDesktopUser group, changed the password to something STUPID simple, feel free to grab them from a list of Top100 weakest or most common passwords. I also make sure that they can’t change password upon logging in AND also can’t change passwords at all, this became key as one of the techniques I noticed once my honeypot was well established, was that people would then try to claim it as theirs by changing the password.
Step 7: Set up some logging on the system. Since we now have a Cloudwatch agent on the system pushing our sweet sweet logs somewhere else, we’ll need to start looking into some different logs. For shits and giggles, I really wanted to log not only successful logins but also failed ones. So you can go to Local System Policy Editor and configure the setting to log both success and failed remote logins. I also went ahead and install Sysmon and got it all configured up and running on the system. Now that I have the logs I want, I need to tell cloudwatch where they are and update configuration file. In the Amazon/Cloudwatch directory you should be able to find a configuration tool turn it on and you’ll activate the CWA configuration wizard. Make some determination if you want to collect metrics from the system and all that jazz. After it asks if you want to collect logs, click no and the next menu will ask if you want to collect event logs, and that’s where you’ll want to create the following. These are the ones that I’ve set up by name:
- System
- Security
- Microsoft-Windows-Sysmon/Operational
And at the end, you’ll ask if you want to save the configuration remotely (I’d suggest yes, if you plan on setting more honeypots in the future). If you got the right permissions set up, then you should be able to save to a parameter store that you can then push out to your future CWA. Alternatively, you can use the parameters I have stored and saved here that identifies some of the logs that you could possibly want https://gist.github.com/planglois925/f75939ad9f0240157a86e8015b9a165c
Step 8. Clear your logs. This is something I do, you’re probably not required to, but JUST in case, it might be beneficial for you to clear some of the logs that might have information tying back to you. Clear and don’t save them.
Step 9. Check to see if you can manage CWA from System Manager. Now that you have built out the configuration file and have saved, lets see if you can push the configuration to the cwa. Using system manager, you should be able to select the Run Command “Configure CWA”, and select by name the configuration file you have. I don’t save to S3 buckets, cause most of the commands don’t really bring back that much data. Run the command and hopefully it will show success. Under the same “Run Command” you can also check the current status of the CWA and start and stop it and all the fun jazz. Now since you have parameters stored, any new CWA can just be configured using that document set.
Step 10. Check cloud watch to see if your logs are being sent. I will admit THIS TOOK ME THE LONGEST TIME to figure out, so I hope that the steps above helped make the process easier for you and you can avoid the pitfalls I made. So you have your cloud agent running (which we can check through SSM) we have our permissions to attached to the EC2 instance so that it can log to Cloudwatch, we should be able to find streams named after what we put in on the configuration file. Within each of these streams, you should be able to see what the uniqe_id of your EC2 instance and hopefully some logs behind that. If you do, then that means you are now officially logging to Cloudwatch.
Step 11. Now there’s a couple different options as to what you do with the logs. You can use Cloud insight to create certain metrics and graphs with the data OR if you want a more robust but pricey model you push your logs to elasticsearch. Fortunately both options are relatively easy to do. I originally used ElasticSearch for my honeypot, but holy s*** that got expensive fast and since I’m paying this out of beer funds I decided that it wasn’t fiscally wise to continue down that path. As an aside, it’s super easy to do and functions more or less just out of the box (just need to stream to lambda, which has a built in function to convert to ES, and set up a domain and all that jazz). You’ll find that process pretty easy and relatively well documented. I opted to use Cloud Insight since it was free and allowed me to set up a useable dashboard within my AWS environment without having to manage a separate system.
Step 12: Setting up cloud watch insight. For my purposes I set up 4 main reports that I wanted for my dashboard. The first of which I wanted to know the number of successful interactive logins account per half hour. This is the query “
fields @timestamp, @message
| sort @timestamp desc
| limit 20
| filter @message like “<EventID>4624</EventID>”
| filter @message like “<Data Name=’LogonType’>3</Data>”
| stats count() by bin(1h)
I also want to have unsuccessful logins, which is eventid 4625:
fields @timestamp, @message
| sort @timestamp desc
| limit 20
| filter @message like “<EventID>4625</EventID>”
| filter @message like “<Data Name=’LogonType’>3</Data>”
| stats count() by bin(1h)
For just general interest, I also created some line charts that shows how many events are coming in through the different log streams, such as Sysmon, Security + Netflow (just an easy toggle to set at the VPC).
Now change your Security Group settings to your World Open and let it rip!!!! Which means just letting it run for an extended amount of time. Now it’s more like fishing than anything particularly thrilling, you got your lure and hopefully you should be seeing some activity relatively soon. At least from the failed logins cause folks are CONSTANTLY spraying that and poking and prodding systems. The quickest I’ve had in terms of successful login to the Administrator account is about 5 hours, so it takes some patience.Keep an eye on the system and make sure stuff doesn’t get out of hand.
And there you go, you got yourself a full blown rdp honeypot in aws. If you have any comments or questions, don’t hesitate to reach out!
Analytical Security 