Build an Azure SIEM and Detect Attacks

Deploy Microsoft Sentinel, simulate a brute-force attack, and build KQL detection rules.

Introduction

30 Second Summary

Every day, thousands of automated bots scan the internet for exposed login pages and hammer them with password guesses. Organizations need security teams who can spot these attacks in real time and respond before damage is done.

In this project, you will deploy a cloud-native Security Operations Center using Microsoft Sentinel as your SIEM, simulate a real brute-force attack against a Windows Server, and build an automated detection rule that catches it.

What You'll Build

By the end, you can trigger a brute-force login attempt against your server and watch Sentinel automatically flag it as a security incident within minutes.

By the end of this project, you'll have:

A Windows Server honeypot streaming real security event logs into Sentinel, so you can see every login attempt as it happens.
A KQL hunting query that identifies brute-force patterns in raw log data, proving you can manually track down an attacker.
A scheduled analytics rule that automatically fires an alert and creates a triageable incident when it detects 5+ failed logins in 5 minutes.
Secret Mission: Build a password-spray detection rule that catches an attacker targeting multiple accounts from a single IP, and investigate the incident using Sentinel's entity timeline.

Are there any prerequisites?

You need an active Azure for Students subscription with available credit. This project uses your $100 free credit. You should also be comfortable navigating the Azure Portal basics like searching for services and creating resources.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters. This step is your moment to commit to the mission before any hands-on work begins.

Deploy the SIEM Infrastructure

Every Security Operations Center needs three things before it can detect a single threat: a place to store logs, a detection engine to analyze them, and a source of security events to monitor.

In this step, you deploy all three in Azure. You create a Log Analytics Workspace for log storage, enable Microsoft Sentinel as your SIEM, and spin up a Windows Server VM that generates the security events you will hunt for later.

In this step, get ready to:

Create a Resource Group and Log Analytics Workspace in Azure.
Enable Microsoft Sentinel on the workspace.
Deploy a Windows Server 2022 VM with restricted network access.

Create the Resource Group and Log Analytics Workspace

A Resource Group is a container that holds related Azure resources together. A Log Analytics Workspace is the database where your security logs will be stored and queried.

Sign in to the Azure Portal at portal.azure.com.
In the top search bar, type Resource groups and select it from the results.
Click + Create.
For Subscription, select your Azure for Students subscription.
For Resource group, enter SecurityLab-RG.
For Region, select (US) East US.
Click Review + create, then click Create.

You should see a "Deployment succeeded" notification. Your Resource Group is ready.

In the top search bar, type Log Analytics workspaces and select it from the results.
Click + Create.
For Resource group, select SecurityLab-RG.
For Name, enter SecurityLab-LAW.
For Region, select (US) East US.
Click Review + Create, then click Create.

Wait for the deployment to complete. You should see another "Deployment succeeded" notification.

What is a Log Analytics Workspace?

A Log Analytics Workspace is the database behind Microsoft Sentinel. All security logs from your connected sources land here, and you query them using KQL (Kusto Query Language).

Think of it as the hard drive for your SIEM. The better organized the data, the faster you can hunt threats.

Enable Microsoft Sentinel on the workspace

With log storage in place, you now activate the detection engine. Microsoft Sentinel is the SIEM layer that sits on top of your Log Analytics Workspace, providing threat hunting, analytics rules, and incident management.

In the Azure Portal search bar, type Microsoft Sentinel and select it from the results.
Click + Create.
Select SecurityLab-LAW from the workspace list.
Click Add.

Sentinel takes a moment to enable. Once complete, you land on the Sentinel overview page showing your workspace with 0 incidents.

What about the free trial?

Enabling Sentinel activates a 31-day free trial. During this trial, the first 10 GB/day of ingested data is free. Both Log Analytics ingestion and Sentinel analysis charges are waived.

Your Azure for Students $100 credit covers any costs after the trial ends.

Seeing a Defender portal prompt?

Since July 2025, new Sentinel customers may be redirected to the Microsoft Defender portal instead of the classic Azure Portal experience. Both portals work for this project. If you see a prompt to use the Defender portal, you can accept it or stay in the Azure Portal.

Don't see SecurityLab-LAW in the list?

Confirm the Log Analytics Workspace deployment completed successfully by navigating back to Log Analytics workspaces and checking that SecurityLab-LAW appears.
Make sure you created the workspace in East US. If it is in a different region, it may not appear in the Sentinel workspace picker.
Help me find my Log Analytics Workspace when enabling Sentinel.

Deploy the Windows Server VM

Your SIEM needs something to monitor. You deploy a Windows Server VM that generates real security events (successful logins, failed logins, privilege changes) and streams them to your workspace in the next step.

In the Azure Portal search bar, type Virtual machines and select it under Services.
Click Create at the top, then select Azure virtual machine.

The VM creation wizard opens. Fill in the Basics tab with these settings:

For Resource group, select SecurityLab-RG.
For Virtual machine name, enter labadmin-vm.
For Region, select (US) East US.
For Security type, select Standard.
For Image, select Windows Server 2022 Datacenter: Azure Edition - x64 Gen2.
For Size, click See all sizes and search for B1s. Select Standard_B1s.
For Username, enter labadmin.
For Password, create a strong password (at least 12 characters) and note it somewhere safe. You will need it to log into the VM later.

Why Standard_B1s?

The B1s size costs approximately $0.01/hour. It is the cheapest VM size available that still generates real Windows Security Events. You are not running heavy workloads on this VM. It exists only to produce log data for Sentinel to ingest.

Still on the Basics tab, scroll down to Inbound port rules:

For Public inbound ports, select Allow selected ports.
For Select inbound ports, choose RDP (3389).

Now switch to the Networking tab at the top of the page to restrict who can connect:

Under NIC network security group, confirm it is set to Basic.
For the Source of the RDP rule, select My IP address. This restricts RDP access to only your current public IP.

What is a Network Security Group?

A Network Security Group (NSG) is a firewall that controls which traffic can reach your VM. By selecting My IP address as the source, you allow RDP connections only from your machine. Anyone else on the internet is blocked.

This is critical for a security lab. Leaving RDP open to the entire internet invites real brute-force attacks from bots within minutes.

Now switch to the Management tab to enable auto-shutdown:

In the Auto-shutdown section, check Enable auto-shutdown.
Set the Shutdown time to a time after you plan to finish working today (for example, 2 hours from now).
Set the Time zone to your local time zone.

Auto-shutdown saves credit

Auto-shutdown prevents the VM from running overnight and burning through your Azure for Students credit. You can always start the VM again manually when you return.

Click Review + create at the bottom of the page.
Review your settings, then click Create.

The deployment takes 1-3 minutes. Wait for the "Your deployment is complete" notification, then click Go to resource.

You should see your VM's overview page with Status: Running.

VM deployment failed?

If you see a quota error, the B1s size may not be available in East US for your subscription. Try selecting East US 2 as the region instead.
If the password was rejected, make sure it is at least 12 characters and contains uppercase, lowercase, a number, and a special character.
Help me troubleshoot my Azure VM deployment failure.

Confirm Sentinel is ready

Before you move on, what do you expect to see if you navigate to Microsoft Sentinel right now? Think about it. You have not connected any data sources yet.

In the Azure Portal search bar, type Microsoft Sentinel and select it.
Click on your SecurityLab-LAW workspace.

You should see the Sentinel overview page showing 0 incidents, 0 alerts, and your workspace in a connected state. The SIEM infrastructure is live but empty. No data sources are streaming yet.

Your SIEM foundation is in place. Next up, you connect your Windows VM as a data source so Sentinel actually has security events to analyze.

Connect Windows Security Events to Sentinel

Your SIEM infrastructure is live. Sentinel is enabled, your VM is running, and everything is ready to go.

But right now, Microsoft Sentinel is empty. It has no data to analyze because nothing is shipping logs to it yet. In this step, you connect your Windows VM's security event logs to Sentinel so it can see every login attempt, every failed password, and every security-relevant action happening on that machine.

In this step, get ready to:

Install the Windows Security Events solution from Content Hub.
Configure the data connector with a Data Collection Rule targeting your VM.
Confirm security event data is flowing into Sentinel with a KQL query.

Install the Windows Security Events solution

Before you can configure a data connector, you need to install the solution package that contains it. Solutions in Sentinel bundle related content like connectors, analytics rules, and workbooks together.

In the Azure Portal, navigate to your Microsoft Sentinel workspace (SecurityLab-LAW).
In the left navigation under Content management, select Content hub.
In the search box, type Windows Security Events and press Enter.
Select the Windows Security Events solution from the results list.
Click Install in the details pane on the right.
Wait for the installation to complete. The status changes to Installed when done.

What is a Content Hub solution?

A solution in Content Hub is a package that bundles a data connector with related analytics rules, hunting queries, and workbooks. Installing the solution makes the connector available for configuration.

Configure the data connector with a Data Collection Rule

With the solution installed, you now configure the actual data pipeline. A Data Collection Rule tells the Azure Monitor Agent which events to collect from your VM and where to send them.

In the Sentinel left navigation under Configuration, select Data connectors.
Search for and select Windows Security Events via AMA from the list.
Click Open connector page in the details pane.

You are now on the connector configuration page. Follow the instructions under the Configuration section to create a Data Collection Rule.

Click +Add data collection rule.
Under Basics, enter a Rule name such as SecurityLab-DCR.
Set the Subscription to your Azure for Students subscription.
Set the Resource group to SecurityLab-RG.
Click Next: Resources.

Click +Add resource(s).
In the Select a scope dialog, expand your subscription, then expand SecurityLab-RG.
Check the box next to your Windows Server VM.
Click Apply.
Click Next: Collect.

Under the event collection options, select Common.
Click Next: Review + create.
Review the summary, then click Create.

What happens when you create the rule?

Two things happen automatically. First, the Azure Monitor Agent installs itself on your VM. Second, the agent begins collecting Common security events (including EventID 4624 for successful logins and EventID 4625 for failed logins) and shipping them to your Log Analytics Workspace.

The Common event set includes the most useful security events without flooding your workspace with noise. It covers logon events, process creation, and privilege use.

Don't see the connector in the list?

Make sure the Windows Security Events solution finished installing in Content Hub. Return to Content management > Content hub and confirm the solution shows Installed status.

If you were redirected to the Microsoft Defender portal, you can still access Data connectors from Microsoft Sentinel > Configuration > Data connectors in that portal.

Help me find the Windows Security Events via AMA connector in Sentinel.

Generate and verify security events

The Azure Monitor Agent takes 5-10 minutes to install on your VM and begin shipping logs. While you wait, you will RDP into the VM to generate a successful logon event (EventID 4624) that you can later query.

Wait 5-10 minutes for the agent to finish deploying.
Press the Windows key to open your search bar.
Type Remote Desktop Connection and press Enter to open it.
In the Computer field, enter your VM's public IP address (find this in the Azure Portal under Virtual Machines > your VM > Overview).
Click Connect.
Enter the username labadmin and the password you set during VM creation.
Accept any certificate warnings and wait for the Windows Server desktop to appear.

You have successfully logged in. This RDP session generates an EventID 4624 (successful logon) in the Windows Security log, which the Azure Monitor Agent will ship to Sentinel.

You can disconnect from the RDP session now. The login event has already been recorded.

What is EventID 4624?

EventID 4624 means "An account was successfully logged on." Every time someone authenticates to a Windows machine (via RDP, local login, or network share), Windows writes this event to its Security log. Your RDP connection just created one of these records.

Now confirm that Sentinel is receiving data. Wait a few more minutes after your RDP session for the events to flow through the pipeline.

Return to your Microsoft Sentinel workspace in the Azure Portal.
In the left navigation under General, select Logs.
Close any welcome dialogs or query templates that appear.
Run the following KQL query to see a summary of all events flowing in:

SecurityEvent
| summarize count() by EventID
| sort by count_ desc

What does this query do?

This KQL (Kusto Query Language) query reads the SecurityEvent table, counts how many times each EventID appears, and sorts by the most frequent. It gives you a quick overview of all security events your VM is generating.

You should see a table of EventIDs with their counts. If you see results, data is flowing successfully.

Before you run the next query, think about this: what specific event would prove your RDP session was recorded?

Run this query to confirm your own login event was captured:

SecurityEvent
| where EventID == 4624
| take 5

You should see at least one row showing a successful logon event. This is your own RDP session being recorded by the Azure Monitor Agent and shipped to Sentinel.

Not seeing any results?

Log ingestion can take up to 10 minutes after the Data Collection Rule is created. If you see no data, wait a few more minutes and run the query again.

If data still does not appear after 15 minutes, go back to Configuration > Data connectors and confirm that the Windows Security Events via AMA connector shows a status of Connected. Also verify your Data Collection Rule lists your VM under Resources.

Help me troubleshoot why SecurityEvent data is not appearing in my Sentinel Logs.

Your data pipeline is live. Sentinel is now ingesting real Windows Security Events from your VM. Next up, you will simulate a brute-force attack and discover what happens when attacks go undetected.

Simulate a Brute-Force Attack

Your Sentinel workspace is now ingesting real Windows Security Events from the VM. The next step is to give it something malicious to detect.

In this step, you'll simulate a real-world brute-force attack by hammering the VM with failed RDP logins from PowerShell. Then you'll check whether Sentinel automatically catches it. The result reveals an important gap in your detection coverage.

In this step, get ready to:

Simulate 15 failed RDP login attempts against your VM.
Check Sentinel Incidents for any alerts.
Query raw logs to prove the attack data exists.

Simulate failed RDP logins from PowerShell

A brute-force attack is when an attacker tries many passwords against a single account, hoping one works. Each failed attempt generates an EventID 4625 ("An account failed to log on") in the Windows Security log.

You'll run a PowerShell loop on your local machine that stores wrong credentials with cmdkey, attempts an RDP connection with mstsc, then cleans up. Each failed connection attempt generates a 4625 event on the VM.

Find your VM's public IP address in the Azure Portal by navigating to Virtual Machines, selecting your VM, and copying the Public IP address from the Overview page.
Open PowerShell on your local Windows machine by pressing the Windows key, typing PowerShell, and pressing Enter.
Set your VM's IP address as a variable by running this command:

$vmIP = "[[VMIP="your VM's public IP address"]]"

Run the brute-force simulation by executing this command:

for ($i=1; $i -le 15; $i++) { cmdkey /generic:$vmIP /user:labadmin /pass:WrongPass$i; mstsc /v:$vmIP; Start-Sleep 2; cmdkey /delete:$vmIP }

Expect RDP windows to appear

Each iteration of this loop opens a Remote Desktop Connection window that attempts to authenticate with wrong credentials. You will see credential error dialogs or login prompts appear for each attempt. Close or dismiss each one as it appears. This is expected behavior.

The important thing is that each failed attempt generates an EventID 4625 on the VM, regardless of whether you dismiss the dialogs quickly or slowly.

What does this script do?

cmdkey /generic:$vmIP /user:labadmin /pass:WrongPass$i stores fake credentials (WrongPass1, WrongPass2, etc.) in Windows Credential Manager for your VM's IP.
mstsc /v:$vmIP launches Remote Desktop Connection using those stored credentials. Authentication fails because the passwords are wrong.
Start-Sleep 2 pauses 2 seconds between attempts to space out the events.
cmdkey /delete:$vmIP removes the stored credentials before the next iteration.

Wait for all 15 iterations to complete. Dismiss the RDP error dialogs as they appear.

Script not running?

Make sure you're running PowerShell as a regular user (not inside a Linux terminal like WSL).
Confirm you replaced the IP variable with your actual VM public IP address. If you see connection timeouts, double-check that your NSG allows RDP from your current IP.
If mstsc is not recognized, you may be in a non-Windows shell. Switch to Windows PowerShell.

Ask for help: Why isn't my brute-force simulation generating events?

Check Sentinel for incidents

Your 15 failed login attempts just hit the VM. Now check whether Sentinel detected anything.

Wait 3-5 minutes for log ingestion. The Azure Monitor Agent batches events before shipping them to the workspace.
In the Azure Portal, navigate to Microsoft Sentinel.
Select your SecurityLab-LAW workspace.
In the left-hand menu under Threat management, select Incidents.

Before you look at the results, think about this: you just ran 15 failed login attempts against your VM. Do you expect Sentinel to have created an incident?

The answer: zero incidents. The Incidents page is empty.

Why are there zero incidents?

Sentinel only creates incidents when an analytics rule fires an alert. Right now, your workspace has no detection rules configured. The raw event data is flowing in perfectly, but Sentinel has no logic telling it what counts as suspicious.

This is the gap that every SOC engineer must solve. Logs without detection rules are just noise. In the next steps, you'll write the logic that turns this raw data into actionable alerts.

Prove the attack data exists with KQL

The events are there. Sentinel just has no rule to surface them. Prove it by querying the raw data directly.

In your Sentinel workspace, select Logs from the left-hand menu.
Close any welcome dialogs that appear.
Run this KQL query to see your failed login events:

SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(15m)
| project TimeGenerated, TargetAccount, Computer, IpAddress

What does this query do?

SecurityEvent is the table where all Windows Security Events land.
EventID == 4625 filters to failed logon events only.
TimeGenerated > ago(15m) limits results to the last 15 minutes.
project selects only the columns you care about: when it happened, which account was targeted, which computer, and the attacker's IP.

You should see multiple rows showing labadmin as the target account, your VM's computer name, and your IP address as the source.

Now confirm the total count by running:

SecurityEvent
| where EventID == 4625
| count

You should see 10 or more failed logon events in the count result. This proves the brute-force data landed in your workspace.

Not seeing any EventID 4625 results?

If zero results appear, wait another 5 minutes. Log ingestion can take up to 10 minutes in some cases.
Expand the time range from ago(15m) to ago(30m) in case there was a delay.
Verify your VM's NSG allows RDP from your current IP. If your IP changed (VPN, network switch), the connection attempts may have been blocked before reaching the VM.

Ask for help: Why can't I see EventID 4625 in my Sentinel logs?

You now have hard evidence: the brute-force attack generated real security events in your workspace, but Sentinel reported zero incidents. Next up, you'll hunt through those raw logs with KQL to understand what the attack pattern actually looks like.

Hunt the Attack with KQL

Your brute-force attack generated real malicious data in the SecurityEvent table. You confirmed the events exist. But Sentinel stayed silent.

Before building automated detection, a SOC analyst must understand what an attack looks like in raw log data. In this step, you write a threat-hunting query that aggregates failed logins by account within time windows, revealing the brute-force pattern. This is the core skill that separates a SOC analyst from someone who just clicks buttons.

In this step, get ready to:

Write a KQL query that identifies brute-force login patterns in 5-minute windows.
Enrich the query with attacker IP address and MITRE ATT&CK context.
Save the query as a reusable Sentinel hunting query.

Write your brute-force detection query

A brute-force attack shows up in logs as a cluster of failed login events (EventID 4625) targeting the same account in a short time window. Your query needs to group these events and count them to surface the pattern.

In Microsoft Sentinel, select Logs from the left navigation menu.
If the query editor opens in Simple mode, switch to KQL mode using the toggle at the top of the page.
Clear any existing text in the query window, then paste the following KQL query:

SecurityEvent
| where EventID == 4625
| summarize FailedAttempts = count(),
    FirstAttempt = min(TimeGenerated),
    LastAttempt = max(TimeGenerated)
    by TargetAccount, Computer
| where FailedAttempts >= 5

Click Run (or press Shift+Enter) to execute the query.

What does this query do?

SecurityEvent | where EventID == 4625 filters the raw log table down to only failed logon events.
summarize ... by TargetAccount, Computer groups those events by which account was targeted and on which machine, then counts them.
FirstAttempt and LastAttempt give you the time window the attack occurred in.
where FailedAttempts >= 5 filters out normal one-off failures and keeps only accounts with 5+ fails, which signals a brute-force pattern.

You should see at least one row in the results showing labadmin with 10+ failed attempts. That is your simulated brute-force attack surfacing in the data.

No results returned?

Check the time range selector at the top of the Logs page. Set it to Last 1 hour or Last 24 hours to ensure it covers when you ran your brute-force simulation.
If you ran the simulation more than an hour ago, change the time range to Last 4 hours or Last 24 hours.
Confirm the Windows Security Events connector still shows Connected in the Data Connectors page.

Why isn't my KQL brute-force query returning results in Sentinel Logs?

Enrich the query with attacker IP and MITRE context

Your base query identifies the brute-force pattern, but a real SOC analyst needs more context. Adding the source IP reveals who is attacking. Adding MITRE ATT&CK labels maps the behavior to a known framework that every SOC team uses for communication.

Clear the query window and paste this enriched version:

SecurityEvent
| where EventID == 4625
| summarize FailedAttempts = count(),
    FirstAttempt = min(TimeGenerated),
    LastAttempt = max(TimeGenerated)
    by TargetAccount, Computer, IpAddress
| where FailedAttempts >= 5
| extend MitreTactic = 'Credential Access',
    MitreTechnique = 'T1110 - Brute Force'

Click Run to execute the enriched query.

What changed in this version?

IpAddress is now included in the by clause of summarize. This groups failed logins by source IP, so you can identify exactly where the attack came from.
extend MitreTactic = 'Credential Access' adds a new column labeling this behavior under the MITRE ATT&CK framework's Credential Access tactic.
extend MitreTechnique = 'T1110 - Brute Force' maps to the specific technique ID. This context helps SOC teams communicate findings using a shared language.

Your results should now include the IpAddress, MitreTactic, and MitreTechnique columns alongside the original fields. You can see your own public IP as the attacker source.

IpAddress column is empty?

The IpAddress field for RDP logon failures may be empty if the connection was reset before authentication completed. If you see empty values, your failed attempts still count toward detection. The analytics rule in the next step handles this gracefully.
Confirm you still see labadmin with 10+ FailedAttempts in the results. That is the important signal.

Why is the IpAddress column empty in my EventID 4625 results?

Save the query as a Sentinel hunting query

A hunting query saved in Sentinel persists for future investigations. You and your SOC team can re-run it anytime without rewriting it from scratch.

In the left navigation menu of Microsoft Sentinel, under Threat management, select Hunting.
Select the Queries tab at the top of the page.
Click New query in the command bar.
In the Name field, enter Brute Force Detection - Failed RDP Logins.
Paste your enriched KQL query into the Custom query field:

SecurityEvent
| where EventID == 4625
| summarize FailedAttempts = count(),
    FirstAttempt = min(TimeGenerated),
    LastAttempt = max(TimeGenerated)
    by TargetAccount, Computer, IpAddress
| where FailedAttempts >= 5
| extend MitreTactic = 'Credential Access',
    MitreTechnique = 'T1110 - Brute Force'

Under Tactics & Techniques, select Credential Access from the tactic dropdown.
Select technique T1110 - Brute Force from the expanded list.
Click Create to save the hunting query.

Why save a hunting query separately?

Hunting queries live in Sentinel's Hunting section and are designed for on-demand, analyst-driven investigations. They let you quickly re-run proven detection logic without rebuilding it each time. In the next step, you will convert this same logic into an automated analytics rule that runs on a schedule.

You should see your new query appear in the Queries list under the Credential Access tactic grouping.

Don't see the New query button?

Make sure you are in Threat management > Hunting > Queries tab. The button appears in the command bar at the top of the Queries tab.
If you were redirected to the Microsoft Defender portal, navigate to Microsoft Sentinel > Threat management > Hunting in the left menu.

I can't find the New query button in Sentinel Hunting. Where is it?

Before you verify your final result, think about what the query should return. Do you expect to see your labadmin account with 10+ failed attempts in a single row?

Return to Logs in the left navigation and run your saved query one more time to confirm it still returns results:

SecurityEvent
| where EventID == 4625
| summarize FailedAttempts = count(),
    FirstAttempt = min(TimeGenerated),
    LastAttempt = max(TimeGenerated)
    by TargetAccount, Computer, IpAddress
| where FailedAttempts >= 5
| extend MitreTactic = 'Credential Access',
    MitreTechnique = 'T1110 - Brute Force'

You should see at least one row showing labadmin with 10+ failed attempts. The MitreTactic column reads Credential Access and MitreTechnique reads T1110 - Brute Force. The brute-force pattern is now identifiable and documented.

You now have a working hunting query that reveals brute-force patterns hiding in raw security logs. Next up, you will convert this query into a scheduled analytics rule that runs automatically and creates Sentinel incidents without any manual hunting.

Build the Automated Detection Rule

Your hunting query proved that the brute-force pattern exists in the logs. But hunting is reactive. You had to go looking for the attack manually.

A real SOC needs detection rules that fire automatically when attacks happen. In this step, you convert your hunting query into a scheduled analytics rule that runs every 5 minutes, creates an alert when it spots 5+ failed logins, and generates a Microsoft Sentinel incident for triage.

In this step, get ready to:

Create a scheduled analytics rule from your hunting query.
Configure entity mapping so incidents show attacker details.
Trigger a second brute-force simulation and confirm Sentinel auto-generates an incident.

Create the scheduled analytics rule

The analytics rule wizard has several tabs. You will start on the General tab to set the rule's name, severity, and MITRE mapping. Then you will move to the Set rule logic tab to paste your query and configure scheduling.

In the Azure Portal, navigate to Microsoft Sentinel and select your SecurityLab-LAW workspace.
In the left menu under Configuration, select Analytics.
At the top of the Analytics page, click Create, then select Scheduled query rule.

The Analytics rule wizard opens on the General tab.

In the Name field, enter Brute Force RDP - Multiple Failed Logins.
Set Severity to Medium.
Under Tactics and techniques, select Credential Access.
Leave Status set to Enabled.
Click Next: Set rule logic.

You are now on the Set rule logic tab. This is where you paste the KQL query and configure how often the rule runs.

In the Rule query window, paste your hunting query:

SecurityEvent
| where EventID == 4625
| summarize FailedAttempts = count(), FirstAttempt = min(TimeGenerated), LastAttempt = max(TimeGenerated) by TargetAccount, Computer, IpAddress
| where FailedAttempts >= 5
| extend MitreTactic = 'Credential Access', MitreTechnique = 'T1110 - Brute Force'

Why this exact query?

This is the same hunting query you wrote and validated in Step 4. It counts failed logins (EventID 4625) per account, groups by IP address, and filters for 5+ attempts. The extend line adds MITRE ATT&CK context that surfaces in the incident.

Scroll down to the Query scheduling section.
Set Run query every to 5 Minutes.
Set Lookup data from the last to 10 Minutes.
In the Alert threshold section, set Generate alert when number of query results to Is greater than and enter 0 in the number field.
In the Event grouping section, select Group all events into a single alert.

Why is the lookback longer than the interval?

The lookback period (10 minutes) is double the run interval (5 minutes). This overlap ensures no events are missed between rule executions due to ingestion delays.

Configure entity mapping

Entity mapping tells Sentinel which fields in your query results represent real-world assets like accounts, machines, and IP addresses. When an incident is created, Sentinel uses these mappings to display structured entity information for triage.

Still on the Set rule logic tab, scroll up to the Alert enhancement section and expand Entity mapping.
Click Add new entity.
In the Entity dropdown, select Account.
In the Identifier dropdown, select Name.
In the Value dropdown, select TargetAccount.
Click Add new entity again.
In the Entity dropdown, select Host.
In the Identifier dropdown, select HostName.
In the Value dropdown, select Computer.
Click Add new entity one more time.
In the Entity dropdown, select IP.
In the Identifier dropdown, select Address.
In the Value dropdown, select IpAddress.

What do entity mappings do?

Each mapping links a column from your KQL results to a Sentinel entity type. When Sentinel creates an incident, these entities appear as clickable objects. You can investigate the account's activity timeline, see what else the IP has targeted, and check the host's event history.

Click Next: Incident settings.
On the Incident settings tab, confirm that Create incidents from alerts triggered by this analytics rule is set to Enabled.
Click Next: Automated response.
Skip the Automated response tab for now. Click Next: Review and create.
On the Review and create tab, confirm validation passes, then click Create.

Your rule now appears in the Active rules tab. It begins running immediately on a 5-minute cycle.

Rule validation failed?

Check that the query runs without errors in the Rule query window. A red underline indicates a syntax issue. Make sure you have no trailing pipe character or extra whitespace after the last line.

Also confirm the lookback period (10 minutes) is greater than or equal to the query interval (5 minutes). Sentinel rejects rules where the lookback is shorter.

Why won't my analytics rule validate?

Trigger the second brute-force simulation and verify the incident

Your rule is live and checking for brute-force patterns every 5 minutes. Time to test it with a second simulated attack.

On your local machine, open PowerShell.
Set a variable for your VM's public IP address and run the brute-force simulation by running this script:

$vmIP = "[[VM_PUBLIC_IP=\"your VM public IP address\"]]"
for ($i=1; $i -le 7; $i++) {
    cmdkey /generic:$vmIP /user:labadmin /pass:WrongPass$i
    mstsc /v:$vmIP
    Start-Sleep 2
    cmdkey /delete:$vmIP
}

What does this script do?

The loop attempts 7 RDP connections using deliberately wrong passwords. Each failed attempt generates an EventID 4625 in the VM's Security log. The cmdkey command stores credentials temporarily, mstsc launches the RDP client, and the Start-Sleep 2 pause gives each attempt time to register.

Each RDP window will fail to connect. Close them as they appear. The failed login events are what matter.

Close any RDP windows that opened during the simulation.
Wait 5-10 minutes for the Azure Monitor Agent to ship the new EventID 4625 events and for the analytics rule to execute its next cycle.

Use the time wisely

While waiting, you can check Sentinel Logs and run a quick query to confirm the new failed login events are flowing in: SecurityEvent | where EventID == 4625 | where TimeGenerated > ago(15m) | count.

Before you check the Incidents page, predict: do you think Sentinel will have generated an incident this time? What changed since Step 3 when you checked and saw zero incidents?

In Microsoft Sentinel, select Incidents in the left menu under Threat management.

You should now see at least one incident with severity Medium and the title matching your rule name.

Click the incident to open its details.
Examine the Entities section. You should see your mapped entities: the labadmin account, the target computer name, and your attacker IP address.
Check the MITRE ATT&CK section. It should show Credential Access as the tactic.
Review the incident timeline and evidence to see the raw events that triggered the alert.

What makes this different from Step 3?

In Step 3, you ran the same attack but Sentinel had no detection rule. The failed logins sat silently in the logs with zero incidents. Now your analytics rule continuously monitors for the pattern and fires an alert the moment it detects it. This is the difference between reactive hunting and proactive detection.

No incident after 10 minutes?

Verify your rule is enabled by checking the Active rules tab. A disabled rule will never fire.

Confirm the new EventID 4625 events exist by running the hunting query in Logs. If no results appear, your VM's NSG may be blocking the RDP attempts. Check that port 3389 is open from your current IP.

If events exist but no incident appears, check that the alert threshold is set to greater than 0 (not a higher number like 100). Also verify the lookback is 10 minutes, not 5.

Help me troubleshoot my Sentinel analytics rule not firing

Your SIEM now detects brute-force attacks automatically and surfaces them as actionable incidents. Next, the Secret Mission challenges you to build a more advanced detection for password-spray attacks.

Secret mission

Detect a Password Spray and Investigate

A brute-force attack is noisy. A password spray is sneaky. One IP tries a few passwords against many accounts, staying below per-account thresholds. Can you design a detection rule that catches it anyway, then investigate the incident like a real SOC analyst?

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses Azure cloud resources that cost approximately $0.01/hr while the VM is running, covered by your Azure for Students $100 credit.

Cost warning

If you leave the VM running continuously without deallocating, it costs approximately $8.50/month. Your Sentinel free trial covers log ingestion and analysis for 31 days (up to 10 GB/day). After the trial ends, pay-as-you-go pricing applies.

Deallocate the VM between sessions to keep total costs under $1-3 for this project. Setting a budget alert at $10 catches any unexpected charges early.

Resources you used:

SecurityLab-RG resource group (East US) containing all project resources.
SecurityLab-LAW Log Analytics Workspace with Microsoft Sentinel enabled (31-day free trial).
Windows Server 2022 VM (B1s size) with associated OS disk, NIC, public IP, and NSG.
Windows Security Events via AMA data connector and Data Collection Rule.
Two analytics rules (Brute Force RDP, Password Spray) and saved hunting query.
Sentinel incidents generated from brute-force and password-spray simulations.

Keep everything running

No action needed. Choose this if you are still actively building or plan to extend this lab with additional detection rules.

Your Sentinel free trial lasts 31 days from activation. Log ingestion up to 10 GB/day and analysis charges are waived during the trial.
Keep the VM deallocated between sessions to minimize costs. Only start it when you need to generate new security events.
Data retention is 90 days with Sentinel enabled on the workspace.
Set a budget alert to catch unexpected charges. In the Azure Portal, search for and select Resource groups, then select SecurityLab-RG.
In the left menu, select Budgets under the Cost Management section.
Click Add, set the budget amount to $10, configure an alert threshold at 80%, and enter your email address for notifications.

Pause - I'll come back to this later

Shut down the VM to stop compute charges while keeping all your Sentinel configuration, analytics rules, and log data intact.

In the Azure Portal, search for Virtual machines and select your VM.
Click the Stop button in the top toolbar. Confirm the action when prompted. This deallocates the VM and stops compute billing.
Verify the VM status changes to Stopped (deallocated). Only disk storage costs remain (approximately $1.50/month for the 30 GB OS disk).
Sentinel and Log Analytics persist at no additional cost during the free trial period. Your analytics rules, hunting queries, and incidents are preserved.
When you are ready to resume, return to Virtual machines, select your VM, and click Start.

Delete - I don't want to use this again

Remove all project resources by deleting the entire resource group. This is irreversible and removes the VM, Sentinel workspace, analytics rules, log data, and all associated resources instantly.

In the Azure Portal, search for Resource groups and select SecurityLab-RG.
Click Delete resource group in the top toolbar.
Type SecurityLab-RG in the confirmation text box to confirm, then click Delete.
Wait for the deletion to complete. All resources within the group (VM, disk, NIC, public IP, NSG, Log Analytics Workspace, Sentinel, data connector, analytics rules, and incidents) are removed.

What about the Log Analytics Workspace data?

After you delete the resource group, the Log Analytics Workspace enters a soft-delete state for 14 days. During this window, the workspace and its data can be recovered if you recreate it with the same name in the same resource group and region. After 14 days, it is permanently deleted.

Nice Work!

You just built a fully operational cloud-native Security Operations Center environment from scratch. You deployed Microsoft Sentinel as your SIEM, connected a live Windows Server honeypot, hunted an attack in raw logs, and built an automated detection rule that surfaces brute-force attempts as triageable incidents.

You've learned how to:

Deploy Microsoft Sentinel with a Log Analytics Workspace ingesting real Windows Security Events from a VM via Azure Monitor Agent.
Simulate a brute-force attack and write KQL hunting queries that identify attack patterns in raw EventID 4625 log data.
Build a scheduled analytics rule that automatically detects brute-force attempts and creates Sentinel incidents with entity mapping and MITRE ATT&CK alignment.
(Secret Mission) Design a password-spray detection rule for evasive multi-account attacks and investigate the incident using entity timelines.

Ready to quiz yourself?