Honeypot and SIEM Lab

Background:

One of the things that I wanted to do was set up a honeypot as a virtual machine in Azure and utilize Microsoft Sentinel to view that traffic. After some research, I settled on Josh Madakor's Youtube guide on setting up a honeypot, and geo-tagging login information. This would be a good way to get a little experience with Microsoft Sentinel, Log Analytics workspaces, SIEM management, and Kusto Query Language (KQL).

General Procedure:

So, the general steps for this project are as follows:

Create a Virtual Machine in Azure, and expose it to all traffic from the Internet.
Use Powershell and an IP Geolocation API to retrieve attacker information.
Configure a Log Analytics workspace to ingest logs from the Windows Virtual Machine to Microsoft Sentinel.
Create a Microsoft Sentinel workbook to visualize attacker data on a world map based on their IP location.

The Project:

The first thing that I did was create a resource group for the project. I did this so that I could easily manage all of the resources in the project. It's pretty straightforward--you search for resource groups, click Create, and go through the wizard.

The next step was to create a Windows 10 VM in Azure. Again, it is all straightforward (by selecting Create a resource > Virtual Machine > Create). The only non-default option that I chose here (outside of the name) was to create a new Network Security Group. A network security group contains rules that allow/deny traffic to the network. Since I wanted the network to be open, I had to create a new rule allowing everything inbound (using the "*" as a wildcard).

Creating an inbound rule allowing all traffic to reach the VM.

Once the rule was created in the NSG, I just finalized the rest of the creation of the virtual machine.

While the VM was being created, I created a Log Analytics workspace to store and query log information.

After the Log Analytics workspace was done, I had to configure the environment for the honeypot in Defender for Cloud. It took a bit to find, but the menu was in Microsoft Defender for Cloud > Management > Environment settings. After navigating to the Log Analytics workspace, I enabled the Foundational Cloud Security Posture Management (CPSM) and Server plans for Defender.

The VM had finalized creation at this point, so I went to connect the Log Analytics workspace to the VM. The Virtual Machines subsection of Log Analytics workspaces had recently been moved. It is currently under Classic > Virtual Machines (and labeled as deprecated).

VM connection in the LA workspace. This is deprecated, and a bit hard to find.

Once I had found the page, the process of connecting the LA workspace to the VM was simple enough--you click Connect.

Connection button for the LA to VM connection.

Then, back to Microsoft Sentinel to connect to the workspace:

Now, onto configuring the VM. I used the RDP connection settings from Azure to get into the honeypot, and disabled the firewall settings for all domains.

To verify that the honeypot was open to all connections, I ran a ping from my home computer to the VM.

In the VM, I opened Josh Madakor's custom log script. For the geolocation to work, I had to create an account on IPGeolocation.io. Once my account was created, I copied my API key, and entered it as the $API_KEY variable in the script.

Once the script configuration was set, I saved and ran it. After a few minutes, I could see remote connections to the computer.

Once all of the honeypot setup was complete, I had to create a custom log in the Log Analytics workspace. Sidenote - this is where things got confusing. There are now two Custom log options for Log Analytics workspaces. For this project, I used the MMA-based log since it appeared to be simpler to import logs from a virtual machine.

Custom log setup was simple enough. I uploaded my failed_rdp.log from my VM to the LA workspace (Azure needs a sample of a custom log file for parsing) and pointed the collection path to where the log file resides on the VM.

To verify the custom log functionality, I used its name as the query in the Log Analytics workspace. I did have to wait a while for the VM's log to sync to the workspace, but I was eventually able to see the entries in the custom log.

The next step was to extract the custom fields from the log data (the workspace reads the log data as one long string). More confusion here -- there used to be a menu in the LA workspace for this (accessible by right-clicking the log entry and clicking Extract Fields). This menu no longer exists. The way that I got this to work was to create a KQL query to parse the raw data directly in a Microsoft Sentinel workbook.

In case you're using this page as a guide, the full query is as follows:

FAILED_RDP_WITH_GEO_CL | extend RawData = tostring(RawData) | parse RawData with * "latitude:" latitude ",longitude:" longitude ",destinationhost:" destinationhost ",username:" username ",sourcehost:" sourcehost ",state:" state ", country:" country ",label:" label ",timestamp:" timestamp | summarize event_count=count() by sourcehost, latitude, longitude, label, destinationhost, country | where destinationhost != "samplehost" | where sourcehost != ""

Once the query was set in the workboook, I just had to set the vizualization to "Map", and modify the map settings to use the custom fields.

That was all! The final product -- a workbook in Sentinel that shows a heat map of failed RDP sessions, grouped by geographical location.

Conclusion/Lessons Learned:

With this lab, I've used a custom PowerShell script to extract metadata from Windows Event Viewer and sent it to a third-party API for location data. The data was ingested into an Azure Log Analytics Workspace and visualized in a Microsoft Sentinel workbook, displaying global RDP brute force attacks on a world map by physical location and attack count. What I've learned is that Microsoft frequently moves, removes, or deprecates features in Azure, requiring me to stay vigilant and keep up with these changes.