In this project, Ill be creating a Windows 10 virtual machine honeypot and connect it to my Microsoft Defender File Integrity Monitor in Azure. The purpose of this project is to expose a virtual machine to the internet, allow hackers to brute force into it, and then see what changes they make to the system. This will give me insights on what hackers want to target so that I know how to better protect those assets in a real production environment.
Resources
The following is a list of resources I used for this project.
https://docs.microsoft.com/en-us/azure/defender-for-cloud/file-integrity-monitoring-overview
https://docs.microsoft.com/en-us/azure/defender-for-cloud/file-integrity-monitoring-usage
https://docs.microsoft.com/en-us/azure/defender-for-cloud/adaptive-network-hardening
https://docs.microsoft.com/en-us/azure/defender-for-cloud/defender-for-servers-introduction
What is a FIM (File Integrity Monitor)?
To explain what a File Integrity Monitor is, I will use the description directly from the Microsoft documentation.
File integrity monitoring (FIM), also known as change monitoring, examines operating system files, Windows registries, application software, Linux system files, and more, for changes that might indicate an attack. FIM informs you about suspicious activity such as:
- File and registry key creation or removal
- File modifications (changes in file size, access control lists, and hash of the content)
- Registry modifications (changes in size, access control lists, type, and the content)
Why Use a FIM?
To explain the purpose of using a File Integrity Monitor, I will again use the description from the Microsoft documentation.
Operating system, applications, and associated configurations control the behavior and security state of your resources. Therefore, attackers target the files that control your resources, in order to overtake a resource’s operating system and/or execute activities without being detected. In fact, many regulatory compliance standards such as PCI-DSS & ISO 17799 require implementing FIM controls.
https://docs.microsoft.com/en-us/azure/defender-for-cloud/file-integrity-monitoring-usage#why-use-fim
Step 1 – Create a Windows 10 Virtual Machine
The first step in this project is to create the vulnerable virtual machine. For this, I’m using Windows 10 with the minimal amount of resources provisioned. I was not going to add any software to it. It will be an out-of-the-box default install with nothing on it.
Step 2 – Create a Log Analytics Workspace
After making the virtual machine, I had to make a LAW (Log Analytics Workspace) to collect the logs from it. I won’t go into much detail on this as prerequisite knowledge of Microsoft Azure is expected to follow this project. But there was nothing special about the LAW I made; it was a default workspace which I connected with my virtual machine.
Step 3 – Configure the FIM
Now I had to configure the File Integrity Monitor. To do this, I followed the documentation linked above in the Resources section. I will write a brief overview of the steps here.
- Go to Microsoft Defender for Cloud
- Click on Workload protections which is in the menu under the Cloud Security section
- Click on File Integrity Monitoring box at the bottom
- Click on your Log Analytics Workspace
- Click on the ENABLE button to start the FIM on the workspace.
- Enable with the recommended settings for Windows Files, Registry, and Linux Files.
- This may take some time for the components to connect, but when it is finished, the virtual machine should appear in the list of servers in the File Integrity Monitoring blade.
- At the start, it should have 0 changes across the board.
Step 4 – Testing the FIM
As of the last step, there should be 0 changes listed in the FIM because the virtual machine is brand new. To make sure it works, I will make changes to a registry key to see if the alert is triggered.
Refer to this section for recommended items to monitor using FIM.
https://docs.microsoft.com/en-us/azure/defender-for-cloud/file-integrity-monitoring-overview#which-files-should-i-monitor
I will make a change to the following registry key
HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile
In this registry, I changed the DisableNotifications key to have a new value of 1 (it was 0 by default).
To make sure a different event was triggered, I also deleted a file that was being monitored.
C:\Windows\win.ini
Now there should be a change logged for the registry and one for files.
Step 5 – Expose the Virtual Machine
Once the File Integrity Monitor has been successfully connected and tested against the new virtual machine, it was time for me to open it up to the internet. To do this, I disabled the firewall on the virtual machine itself, and also created a new rule in Azure to allow all connections from anywhere on any port.
Now that the defenses were removed, I had to make it easier for an attacker to gain access to my machine. I created a new user with the following credentials so it wouldn’t take so long for a brute force attack to work.
Username: Administrator
Password: password
Step 6 – Monitoring the FIM
The honeypot was finally prepared so all I had to do was wait now.
At 10:12pm that evening, I received an email from Microsoft Azure alerting me that my virtual machine was successfully hacked using a brute force attack.
In most circumstances, this would be a terrifying email to receive. But in this instance, I was delighted to see this email as I knew then that I could start collecting data on the activities from this attacker.
It took some time to collect a decent amount of data as I had only configured my FIM to monitor the recommended Registry Keys and Files listed by default in the Windows settings. However there were changes being made throughout the evening and into the next days.
Review
I let the virtual machine run for a few days and received multiple emails from Microsoft mentioning that different attackers brute forced my machine. So in this honeypot were at least 4 different individuals making changes to the system.
By the time I decommissioned the honeypot, I recorded 63 total changes made by hackers. The screenshot above mentions 83 total changes, but 20 of those were from me testing the FIM and disabling the firewall.
There were a few interesting registry key changes I found during this time. I could see that one attacker actually re-enabled one of my firewall settings which was unusual. I saw some DLLs being removed and others added.
I also found an additional administrator account was made presumably as a failsafe for the attacker in case I changed the password on the primary admin account.
Conclusion
I went through the security logs and filtered by audit failures to see what usernames these hackers were trying to brute force with. Many of these usernames were common individual names like JOHN, ROSE, and KATE. However there were other usernames tried that hackers are using in their dictionaries. Based on this experience, I strongly suggest not using any of these names as they are common targets for hackers.
- AZUREUSER
- STUDENT
- ITADMIN
- SYSADMIN
- FTP
- HOSTMASTER
- VMADMIN
- SUPERUSER
- BACKUPADMIN
- ENGINEER
- SCHEDULE
- TECHADMIN
- WORKSTATION
- TSUSER