Microsoft Sentinal Lab

Summary
Creating my Azure lab allowed me to get hands-on experience and configure a Sential cloud-based environment. I learned how to manage Azure core components like VMs, LAWS and Sentinel and see how they can all be connected together to support security operations. I configured log ingestion from a Windows server and confirmed that security events such as failed and successful logons, process creation, and system heartbeat messages were being collected correctly.

I explored Sentinel's detection capabilities by creating my own analytics rule for failed logins using a KQL query. This helped me understand how alerts are generated and how they can be used to pick up on suspicious patterns. This lab has helped me develop foundational skills in Azure monitoring, log analysis, and security event correlation.

Initial Setup

I began my Azure labs using the Microsoft Learn modules, starting with Introduction to Microsoft Sentinel. To build on this, I supplemented my learning with YouTube tutorials and hands-on lab guides.

Creating my  environment

• Created a resource group for the lab environment.

• Deployed a Server VM running Windows for log generation and monitoring.

• Set up a Log Analytics Workspace (LAW).

• Enabled Microsoft Sentinel on the LAW.

• Connected an external VM to simulate authentication attempts and generate security events.

Verifying setup

To verify that I had set up my environment correctly, I conducted a couple of tests to show that my LAW was receiving data. I simulated multiple failed login attempts (Event ID 4625) and observed them in Sentinel and then verified successful logons (4624), process creation events (4688) to make sure I was getting the successful side too. I checked for my VM's heartbeat (running), and everything was running as planned.

KQL Rules

I created an analytic rule to alert on Event ID 4625 (Failed Logon Attempts) and tested it successfully, confirming that my Sentinel is detecting and notifying on suspicious behaviour.

In the future, I would love to build on this by adding a customised rule for if an Event ID 4624 follows x amount of logins, then this would be flagged. This would aim to combat spraying, or the off chance a brute force worked.