Microsoft Sentinel Lab

To help my learning, I created my own Microsoft Azure Lab with the intention of gaining experience with Microsoft Sentinel, including the creation of DCRs, LAWs, Resource groups and utilising VMS.

Summary
Creating my Azure lab allowed me to get hands-on experience and configure a Sentinel 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.

Real brute-force activity, caught in the wild

With RDP briefly exposed to the internet during setup, the environment picked up a genuine brute-force campaign within hours of going live: 76 distinct external IPs hammering failed logons (Event ID 4625) against the Administrator account on the domain controller (DC01). The heaviest single source made 7 attempts, and a cluster of IPs from the same subnet pointed to coordinated, likely botnet-driven scanning rather than a single attacker.

I confirmed no successful external logon ever landed (Event ID 4624, LogonType 3 zero results), mapped the activity to MITRE ATT&CK T1110 (Brute Force) and T1133 (External Remote Services), and remediated by locking the NSG's inbound RDP rule down to my own IP. I wrote it up as a formal SOC incident report — scope, timeline, MITRE mapping, before and after remediation — and followed up with a Bicep IaC script so the environment redeploys on demand instead of being rebuilt by hand.

Adjacent lab work

The work below was completed in separate provided and guided lab environments as part of structured coursework, not in the DC01 and WS01 home lab described above.

Page updated

Google Sites

Report abuse