SIEM Lab

Overview

I created a SIEM emulation that I can run from my home. I configured a VM and utilized Microsoft Azure and Sentinel in order to detect network traffic and security incidents or vulnerabilities.

*This project is still in progress.. I’m continuing to update documentation as I progress

I documented the process below.

Documentation

The resource group is the container for all of the things I’m going to be creating:

I chose Windows 11 Pro as my operating system for this VM.

I decided to leave this option allowed initially, in order to see the brute force attempts to RDP into my network.

I was able to deploy Microsoft Sentinel to my resource group. This will allow us to streamline our SIEM through their user interface.

Now, we can access this interface (which is empty for now):

Then, I installed Windows Security Events under the Data connectors tab in Sentinel, in order to be able to send the data and logs from my VM to the interface.

It gives us two agents, as one of them is a legacy agent. I used the ‘Windows Security Events via AMA’ as that’s the one being supported and I didn’t want to risk anything with the legacy agent.

Then, I configured the data collection rule in order to send the logs to Sentinel.

This option wasn’t preset, I had to manually check my VM to collect data from it. I enabled the option that allows it to capture all security events so our interface will be thorough.

I ran the ‘SecurityEvent’ query in order to see if there was any traffic.

There is some traffic as you can see here. System accounts are signing in, so it is not particularly a worry. I implemented a new Sentinel rule that allows me to see if a user account is able to brute-force his or her way into my network.

If a non-system account is successfully able to access the network, it will notify me. Thankfully, there are no results found. We’re going to turn this into a rule that can notify me if someone accesses the network every five minutes.

This is the configuration for the Sentinel rule (quick note, I forgot to change the rule period, so I went ahead and changed that to 5 minutes):

After downloading the RDP file, I was able to connect to my VM to test the Sentinel alert.

As you can see here, Sentinel caught my RDP login. After seeing this incident, I was able to close it under this reasoning:

Although, the logic wasn’t wrong. The rule did exactly what I wanted it to!

After a couple of days, I looked back at the logs to see just how many brute force attempts were logged from user accounts.

As you can see, there were attempts logged nearly every minute to RDP into my VM. I was able to trace some of these IPs to places like Dubai, Cambodia, Russia, etc.

There were around 2400 attempts to access my open RDP port. All failed, but still a ton of attempts. Thankfully, no incidents.

Running a query to see the failed logins, it seems most of the hackers tried to login directly to my administrator account. Some even tried using general names to guess a username.