Using Microsoft Sentinel SIEM to Monitor a Honeypot Server

Getting hands on with the Microsoft Sentinel SIEM platform and honeypot technologies

Arion Martin
4 min readJun 22, 2023

Disclaimer: I first built this lab back in 2022. Since then, I went to rebuild this lab in May 2023 for further testing and discovered some updates to Azure have broken the functionality of this project. This guide outlines a general (but longer comprehensive) project overview.

Project Summary

The motivation behind this project was to gain familiarity with Azure and gain hands on experience with the Sentinel SIEM platform and honeypot technologies. This project was inspired by Josh Makador in his YouTube video.

This project exposed a cloud-hosted Windows virtual machine to the internet and encouraged brute force RDP login attempts by disabling the firewall. The purpose of this was to plot on a geographical map the locations that the attacks were coming from by using Windows event logs, a PowerShell script and a geolocation API key.

Project Setup

Create an Azure Account

This project required an Azure account. Signing up for an accountprovided $200 worth of credit for 30 days.

Create Virtual Machine

Once logged in, we created a virtual machine.

The VM was setup with a username of ‘local-admin’, and a very complex 32 character password consisting of capital and lowercase letters, numbers, and special characters.

Firewall Configuration

In the initial setup, we added a network security group firewall rule to allow any and all traffic into the VM. This is to increase the visibility of the machine. We wanted it to be as discoverable as possible whether an attacker is doing a scan or ICMP ping. Typically you would not want to do this, but this is the nature of the project.

Log Analytics Workspace

Log analytics workspaces collect, store, and analyze log and telemetry data from various sources, in this case it was our honeypot VM.

Log Ingestion

For this step, we enabled Microsoft Defender and enabled all logging events from endpoints to be forwarded. This included events recorded from AppLocker.

Connecting Log Analytics Workspace to VM

Going back to the log analytics workspace, we were able to connect the VM to the log repository.

Setup Sentinel

In order to visualize the attack data, Microsoft Sentinel was enabled.

Login to VM

Using the public IP address, we were able to log in to the Windows VM.

Observing Logs in Event Viewer

By looking for event ID 4625 inside of the Honeypot VM’s Event Viewer, we saw that I put in the password incorrectly on one of the prior login attempts.

Disabling Firewall

The host based firewall was disabled to increase the virtual machine’s visibility so attackers can more easily interact with it.

PowerShell Script

We used Josh’s PowerShell script to take the ‘source network address’ field from the 4625 ‘logon failure’ events in event viewer, use an IP geolocation API to turn the IP address into useful location metadata such as city, longitude and latitude and eventually create a map showcasing attack origin from this data.

This script continuously ran in the background, pulled any 4625 events from event viewer and created a new log file with the geolocation data pulled from the API.

Geolocation Using an API Key

The PowerShell script used an API key from ipgeolocation.io.

Creating a Custom Log

We did this by copying the contents of the failed_rdp log the PowerShell script outputs, saving a local copy to our PC to upload to Azure, and then telling analytics workspace where to look for the logs in the future.

These logs basically train log analytics on what to look for.

Preliminary Results from the Map

--

--

Arion Martin

Information Security Specialist · Blue Team Enthusiast