Building a Real SOC Lab with Microsoft Sentinel from Scratch

I recently completed a hands-on Microsoft Sentinel lab where I set up a full SOC environment, onboarded real machines, wrote detection rules for actual attack scenarios, and automated incident response with a playbook. This blog walks through everything I did, step by step, in a way that should be easy to follow even if you are new to Sentinel or Azure. I will explain what each component actually is before jumping into the steps, because that context is what makes the whole thing click.

What is Microsoft Sentinel?

Microsoft Sentinel is a cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation, and Response) platform built on top of Azure. It collects logs from your machines and services, lets you write detection rules in a query language called KQL, generates incidents when something suspicious is found, and lets you automate responses through playbooks.

Think of it as a central hub where all your security logs land, and where you define what "suspicious" means for your environment. When a rule fires, Sentinel creates an incident that an analyst (you) can investigate.

Lab Overview

The lab covers five modules:

1. Setting up the Sentinel environment (Resource Group, Log Analytics Workspace, Data Collection Endpoint, enabling Sentinel)
2. Preparing the on-premises virtual machines (Windows 11 and Ubuntu)
3. Onboarding both machines and validating that logs are flowing
4. Building custom threat detection rules for four attack scenarios
5. Automating incident response with a Logic App playbook

For the machines, I used Windows 11 and Ubuntu running on Parallels on my Mac. These act as simulated on-premises endpoints. The entire Sentinel infrastructure runs on an Azure free trial.

Module 1: Setting Up the Sentinel Environment

Step 1: Create a Resource Group

A Resource Group in Azure is basically a folder. It holds all the related resources for a project together so you can manage, monitor, and delete them as a unit. For this lab everything lives in one resource group called sentinel-lab.

Go to the Azure Portal, search for Resource Groups, click Create, give it a name (sentinel-lab), pick a region (I used East US), and create it.

copy

Keep all your resources in the same region throughout this lab. If your Log Analytics Workspace is in East US and your Data Collection Rule is in a different region, things will break. Azure is strict about this.

Step 2: Create a Log Analytics Workspace

A Log Analytics Workspace (LAW) is the database that stores all your logs. Every piece of telemetry from your machines ends up here. Sentinel sits on top of this workspace and queries it.

Search for Log Analytics Workspaces in the portal, click Create, assign it to sentinel-lab, give it a name (I used sentinel-log), set the region to East US, and create it.

Once created, you will see the workspace overview page showing the Workspace ID, pricing tier, and status. The pricing tier will be Pay-as-you-go on a free trial, but Sentinel gives you a 31-day free trial with 10 GB/day included, which is plenty for a lab.

Step 3: Create a Data Collection Endpoint

A Data Collection Endpoint (DCE) is the HTTPS gateway through which the Azure Monitor Agent on your machines sends data into Azure. When your Windows or Linux machine wants to ship logs to the cloud, it does not send them directly to the Log Analytics Workspace. It sends them to the DCE first, which then routes them to the correct workspace based on your Data Collection Rules.

Search for Data Collection Endpoints in the portal. Click Create, name it sentinel-dce, assign it to sentinel-lab, set the region to East US, and create it.

After creation you will see two important URLs on the overview page:

• Configuration Access URL - used by the agent to fetch its configuration
• Logs Ingestion URL - the endpoint where your logs actually get sent

Troubleshooting tip: If you hit an error that says "The subscription is not registered to use namespace microsoft.insights", it means your Azure free trial has not registered the Microsoft.Insights resource provider yet. Go to Subscriptions in the portal, click your subscription, find Resource providers in the left sidebar, search for Microsoft.Insights, select it, and click Register. Wait a minute or two and try again. You may also need to register Microsoft.OperationsManagement and Microsoft.SecurityInsights for other Sentinel components.

Step 4: Enable Microsoft Sentinel

Now we add Sentinel on top of the Log Analytics Workspace we created.

Search for Microsoft Sentinel in the portal, click Create, and you will see a list of existing workspaces. Select sentinel-log and click Add. Sentinel will activate its 31-day free trial automatically.

Once inside Sentinel, you land on the Guides page. This is Sentinel's home, and the left sidebar is where everything lives: Logs, Analytics, Data Connectors, Automation, and so on.

Step 5: Set Up RBAC (Access Control)

RBAC stands for Role-Based Access Control. In Azure, it controls who can do what with which resources. The main roles are:

• Owner - full control, can manage access
• Contributor - can create and manage resources but cannot manage access
• Reader - read-only, can view logs and dashboards but not make changes

In a real SOC, you would give junior analysts the Reader role on Sentinel so they can view incidents and run queries without accidentally changing anything. Senior analysts and engineers get Contributor. The lab defaults to Owner since you created everything.

To see this in action, go to your sentinel-lab Resource Group, click Access control (IAM) in the left menu, and explore the Role assignments tab. You can click Add role assignment to assign roles to users, groups, or managed identities.

The principle to remember here is least privilege: give people only the access they actually need.

Module 2: Preparing the On-Premises VMs

This module is about getting the two machines ready. They will act as our "corporate endpoints" that we want to monitor.

Windows 11 Machine

I had Windows 11 running on Parallels on my Mac. Once you have Windows running, open PowerShell as administrator and run this command to create a test event in the Windows Event Log:

eventcreate /T INFORMATION /ID 100 /L APPLICATION /D "SENTINEL LAB: WIN11"

If it responds with "SUCCESS: An event of type 'INFORMATION' was created", your Windows Event Log is working and the machine is ready to be onboarded.

Ubuntu Machine

For Linux I used Ubuntu running on Parallels. Ubuntu acts as our simulated Linux server that we will monitor for SSH activity and syslog events.

Make sure the machine has internet access and can reach Azure endpoints. That is the main requirement before onboarding.

At the end of this module we have two machines ready to connect to Sentinel. Neither is talking to Azure yet. That happens in Module 3.

Module 3: Onboarding and Log Validation

This is where the actual connectivity happens. We use Azure Arc to register our on-premises machines with Azure, which then lets us install the Azure Monitor Agent (AMA) on them and route their logs into Sentinel.

What is Azure Arc?

Azure Arc is a service that lets Azure manage machines that are not running in Azure. Normally Azure can only manage resources it hosts directly (like Azure VMs). Azure Arc extends that management plane to physical servers, VMs on-premises, and machines on other clouds. Once a machine is registered with Arc, Azure sees it as a resource and can deploy agents, policies, and configurations to it.

For this lab, Azure Arc is how we bridge the gap between our Parallels VMs and Azure.

What is the Azure Monitor Agent (AMA)?

The AMA is the agent software that runs on your machine and is responsible for collecting logs and shipping them to your Log Analytics Workspace. It replaces older agents like MMA (Microsoft Monitoring Agent) and OMS agent. The AMA reads the data sources you configure (Windows Event Logs, Syslog, etc.) and forwards them through the Data Collection Endpoint to your workspace.

Onboarding Windows 11 via Azure Arc

In the Azure Portal, search for Azure Arc, go to Machines, and click Add/Create > Add a machine > Add a single server.

Fill in the project details:

• Subscription: Azure subscription 1
• Resource Group: sentinel-lab
• Region: East US
• Operating system: Windows

Leave the connectivity method as Public endpoint and authentication method as Authenticate machines manually (since we are doing one machine, not bulk enrolling). Click Download and run script.

This downloads a PowerShell script (.ps1 file). Copy it to your Windows 11 machine and run it in an elevated PowerShell terminal. The script will:

1. Create the C:\Windows\AzureConnectedMachineAgent directory
2. Download and install the Azure Connected Machine Agent
3. Validate the MSI signature
4. Connect to Azure and prompt you to sign in via browser
5. Register the machine as an Azure Arc resource

The terminal output walks through each step with progress indicators. When you see INFO: Connected machine to Azure, the machine is registered. The output also gives you a direct link to the machine's overview page in the portal, something like:

https://portal.azure.com/#/resource/subscriptions/.../resourceGroups/sentinel-lab/providers/Microsoft.HybridCompute/machines/YOURPCNAME/overview

In the Azure Arc portal you should now see your Windows machine listed under Machines.

Onboarding Ubuntu via Azure Arc

Go back to Azure Arc, click Add a machine again, but this time set the Operating system to Linux. Download and run the script.

On Ubuntu, open a terminal and run:

cd Desktop
nano azurearc.sh
# paste the script content, save and exit
chmod +x azurearc.sh
./azurearc.sh

The script downloads the azcmagent-linux package, installs it, and connects the machine to Azure. During the process it will ask you to authenticate by going to https://login.microsoft.com/device and entering a code shown in the terminal. Once authenticated the connection progresses and you will see the same 20% to 100% progress indicators, ending with INFO: Connected machine to Azure.

You should now see both machines in Azure Arc under Machines.

Creating a Data Collection Rule for Windows

A Data Collection Rule (DCR) tells Azure Monitor what logs to collect from which machines and where to send them. Think of it as a routing rule: "collect Windows Security Event Logs from machine X and send them to Log Analytics Workspace Y".

In the Azure Portal, search for Monitor, go to Settings > Data Collection Rules, and click Create.

Basics tab:

• Rule Name: DCR-SENTINEL-LAB
• Subscription: Azure subscription 1
• Resource Group: sentinel-lab
• Region: East US
• Type of telemetry: Agent-based (Windows or Linux)
• Data Collection Endpoint: sentinel-dce

Resources tab:

This is where you attach the machines that this rule applies to. Click Add resources, expand the scope to find your sentinel-lab resource group, and select your Windows 11 machine (listed as Machine - Azure Arc). Click Apply.

Collect and deliver tab:

Click Add new data source. Set the data source type to Windows Event Logs. You will see checkboxes for Application, Security, and System event categories. For this lab, enable:

• Application: Critical, Error, Warning, Information, Verbose
• Security: Audit success, Audit failure
• System: Critical, Error, Warning, Information, Verbose

Then click Next: Destinations. Set the destination type to Log Analytics Workspaces, select your subscription, and pick sentinel-log. Click Apply, then Save.

Back on the main DCR form, click Review + create and then Create. The review page will show a summary:

• Rule Name: DCR-SENTINEL-LAB
• Resource: Your Windows machine (Machine - Azure Arc)
• Collect and deliver: Windows Event Logs to Log Analytics Workspaces (sentinel-log)

Once created, the DCR overview page shows it linked to 1 data source and 0 connected resources initially. It takes a few minutes for the Azure Monitor Agent to install on the machine and start shipping data.

Validating Windows Logs with KQL

KQL (Kusto Query Language) is the query language used to search logs in Sentinel and Log Analytics. It is a pipe-based language, meaning each step in a query feeds into the next one using |. It is not SQL, but it feels familiar once you get used to it.

To check if logs are flowing from the Windows machine, go to Microsoft Sentinel > Logs, click New Query, make sure you are in KQL mode, and run:

Heartbeat
| take 10

The Heartbeat table contains periodic check-ins from the Azure Monitor Agent. Every machine with AMA installed sends a heartbeat every minute. If you see rows with your machine name, IP, and OSType: Windows, the agent is installed and talking to Sentinel.

Wait 5 to 6 minutes after the DCR is created before running this. If nothing shows up, give it more time.

Creating a Data Collection Rule for Ubuntu

Now we repeat the same process for our Linux machine.

Go back to Monitor > Data Collection Rules and click Create again.

Basics tab:

• Rule Name: DCR-SENTINEL-LINUX
• Subscription: Azure subscription 1
• Resource Group: sentinel-lab
• Region: East US
• Type of telemetry: Agent-based (Windows or Linux)
• Data Collection Endpoint: sentinel-dce

Resources tab:

Add your Ubuntu machine this time (also listed as Machine - Azure Arc with OS type Linux).

Collect and deliver tab:

Click Add new data source. This time set the data source type to Linux Syslog.

You will see a list of syslog facilities (LOG_AUTH, LOG_AUTHPRIV, LOG_CRON, LOG_DAEMON, LOG_KERN, etc.). Enable the ones relevant for security monitoring, especially:

• LOG_AUTH (authentication logs, login attempts)
• LOG_AUTHPRIV (same as AUTH but for sensitive auth data)
• LOG_DAEMON (background service events)
• LOG_KERN (kernel messages)
• LOG_CRON (cron job logs)

Set the destination to your sentinel-log workspace. Save and create the rule. The review page will show DCR-SENTINEL-LINUX with Ubuntu as the resource and Linux Syslog going to the workspace.

Validating Linux Logs with KQL

Wait 5 to 6 minutes, then go back to Sentinel > Logs and run:

Heartbeat
| take 10

You should now see a second row with your Ubuntu machine showing OSType: Linux and Category: Azure Monitor Agent. If both machines appear in the Heartbeat results, you have successfully built the full log ingestion pipeline: machines > Azure Arc > AMA > DCE > DCR > Log Analytics Workspace > Sentinel.

Module 4: Threat Detection with Analytics Rules

Now the interesting part. We write detection rules that watch the incoming logs for suspicious patterns and generate incidents when they fire. We cover four attack scenarios.

What are Analytics Rules?

Analytics Rules are scheduled queries that Sentinel runs on a defined interval. You write a KQL query that describes "suspicious activity", set how often it runs, and tell Sentinel what to do when it finds a match (create an incident, send an alert). They are the core detection engine of Sentinel.

When a rule fires, it creates an alert. Alerts get grouped into incidents, which show up in the Incidents blade for analysts to investigate. An incident includes context: which accounts were involved, which machines, what the alert was about.

Sentinel uses MITRE ATT&CK to categorize rules. MITRE ATT&CK is a framework that catalogs real-world attacker techniques. When you map a rule to a MITRE tactic (like Brute Force or Execution), it helps analysts quickly understand what kind of attack is being detected.

Detection 1: Windows Brute Force (Failed RDP/Login Attempts)

Scenario: An attacker tries multiple wrong passwords on a Windows machine. Windows logs every failed login as Event ID 4625. We want to detect if more than 3 failed attempts happen from the same account on the same machine.

First, enable audit logging on Windows. Open PowerShell as admin and run:

auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable /failure:enable
auditpol /set /subcategory:"Special Logon" /success:enable /failure:enable

Verify it worked:

auditpol /get /subcategory:"Logon","Logoff","Special Logon"

You should see "Success and Failure" for all three.

Create the rule. Go to Microsoft Defender portal > Microsoft Sentinel > Configuration > Analytics. Click Create > Scheduled query rule.

• Name: Windows_Brute_Force
• Severity: Medium
• MITRE ATT&CK: Brute Force (under Credential Access)

In the rule query, enter:

Event
| where EventID == 4625
| extend Account = tostring(parse_json(EventData)["TargetUserName"])
| summarize FailedAttempts = count() by Account, Computer
| where FailedAttempts > 3

What this does:

• Looks at the Event table which contains Windows Event Log entries
• Filters for EventID 4625 (failed logon)
• Extracts the target username from the EventData JSON field
• Counts how many failures happened per account per machine
• Only returns accounts with more than 3 failures

Query scheduling: Run every 5 minutes, look up data from the last 5 minutes. Click through to Incident settings (keep incident creation enabled), skip Automated response, then Review + create.

Simulate the attack. On your Windows 11 machine, try logging in with the wrong password 3 or more times, then log in correctly. Wait at least 5 minutes.

Go to Defender portal > Investigation & Response > Incidents & Alerts > Incidents. You should see an incident for the failed logon attempts.

Detection 2: Suspicious PowerShell Execution

Scenario: An attacker runs a PowerShell command that downloads and executes a script from the internet, a common technique for malware delivery. Windows can log every PowerShell script block that executes (Event ID 4104) if Script Block Logging is enabled.

Enable Script Block Logging on Windows:

$regPath = "HKLM:\Software\Microsoft\Windows\PowerShell\1\PowerShellEngine\ScriptBlockLogging"

New-Item -Path "HKLM:\Software\Microsoft\Windows\PowerShell\1\PowerShellEngine" -Name "ScriptBlockLogging" -Force

New-ItemProperty -Path $regPath -Name "EnableScriptBlockLogging" -Value 1 -PropertyType DWord -Force

Get-ItemProperty -Path $regPath -Name "EnableScriptBlockLogging"

If the last command returns EnableScriptBlockLogging : 1, it is working. To confirm, run any command like Write-Output "Hello Script Block Logging" and then open Event Viewer. Navigate to Applications and Services Logs > Windows PowerShell > Operational and look for EventID 4104. You should see your command logged there.

Update the DCR to collect PowerShell logs.

The PowerShell Operational log is not collected by default because it is not one of the standard Application/Security/System logs. We need to add it manually.

Go to Azure Portal > Monitor > Data Collection Rules, click on DCR-SENTINEL-LAB, go to Data Sources, and click on the Windows Event Logs data source to edit it. Change the Event Log Selection Mode from Basic to Custom. In the XPath filter field, type:

Microsoft-Windows-PowerShell/Operational*

and click Add. You will see it appear in the list alongside the existing Application, System, and Security filters. Click Save.

This tells the AMA to also ship PowerShell Operational logs to the workspace.

Create the rule. In Analytics, click Create > Scheduled query rule.

• Name: Suspicious_PowerShell
• Severity: Medium
• MITRE ATT&CK: Command and Scripting Interpreter (under Execution)

Rule query:

Event
| where EventID == 4104
| where EventLog == "Microsoft-Windows-PowerShell/Operational"
| where EventData contains "Invoke-WebRequest"
    or EventData contains "IEX"
    or EventData contains "DownloadString"
| project TimeGenerated, Computer, EventID, EventData

What this does:

• Filters for EventID 4104 (Script Block logged)
• Confirms the log source is the PowerShell Operational channel
• Looks for strings that are commonly used in download-and-execute attacks: Invoke-WebRequest (downloads files), IEX (shorthand for Invoke-Expression, runs strings as code), DownloadString (downloads a string and executes it)
• Projects the relevant columns

Leave scheduling and incident settings as default. Review + create.

Simulate the attack. In an administrator PowerShell window on Windows 11, run:

Invoke-Expression 'Write-Host "Simulated-Invoke-WebRequest"'

This triggers Script Block Logging with a string that matches our rule. Wait 5 minutes and check Incidents in the Defender portal.

Detection 3: SSH Brute Force on Linux

Scenario: An attacker tries many wrong passwords against SSH on our Ubuntu server. SSH failures land in the auth syslog facility on Linux. We want to detect more than 5 failed SSH attempts in any 5-minute window.

Create the rule. In Analytics, click Create > Scheduled query rule.

• Name: SSH_Brute_Force
• Severity: High
• MITRE ATT&CK: Brute Force (under Credential Access)

Rule query:

Syslog
| where Facility == "auth"
| where ProcessName == "sshd"
| summarize FailedSSHAttempts = count() by Computer, bin(TimeGenerated, 5m)
| where FailedSSHAttempts > 5

What this does:

• Looks at the Syslog table which holds all Linux syslog entries
• Filters for the auth facility (authentication events) from the sshd process (SSH daemon)
• Groups results into 5-minute time buckets using bin()
• Flags any bucket where more than 5 failures happened

Query scheduling: Run every 5 minutes, look up from last 5 minutes. Create the rule.

Simulate the attack. From your main OS or the Windows machine, try to SSH into the Ubuntu machine with the wrong password at least 5 times. You can use PuTTY on Windows or just the terminal:

ssh wronguser@<ubuntu-ip>

Enter the wrong password each time. After 5+ failures, wait for the rule to run. Go to Investigation & Response > Incidents & Alerts > Alerts and you should see SSH brute force alerts appearing.

Detection 4: Suspicious Logins via Microsoft Entra ID

Scenario: The same Azure account signs in from two different countries within a short time window. This is sometimes called "impossible travel" and is a strong indicator of compromised credentials.

What is a Data Connector?

A Data Connector is a pre-built integration that connects a data source (like Microsoft Entra ID, Microsoft 365, AWS, firewalls) to Sentinel. It handles the authentication and configuration needed to pull logs from that source into your workspace. Without the data connector, Sentinel has no idea how to talk to Entra ID or pull sign-in logs from it.

Install the Microsoft Entra ID connector.

In the Defender portal, go to Microsoft Sentinel > Content Management > Content Hub. Search for Microsoft Entra ID, select it, and click Install. This installs the connector package.

After installation, go to Configuration > Data Connectors, find Microsoft Entra ID in the list, and click Open connector page.

Under Configuration, you will see checkboxes for different log types:

• Sign-In Logs (requires Entra ID P1 or P2 license - activate the free trial from this page)
• Audit Logs
• Non-Interactive User Sign-In Logs
• Service Principal Sign-In Logs
• Managed Identity Sign-In Logs
• Risky Users
• and more

Select all log types and click Apply Changes. For Sign-In Logs specifically, you will be prompted to activate a free trial for the required license. Do it.

Create the rule. In Analytics, click Create > Scheduled query rule.

• Name: Impossible_Location_Login
• Severity: High
• MITRE ATT&CK: Valid Accounts (under Initial Access or Credential Access) - Compromised Account

Rule query:

SigninLogs
| extend Country = tostring(LocationDetails.countryOrRegion)
| sort by TimeGenerated desc
| summarize count() by UserPrincipalName, Country, bin(TimeGenerated, 1h)
| where count_ > 1

What this does:

• Queries the SigninLogs table which comes from the Entra ID connector we just configured
• Extracts the country from the LocationDetails field
• Groups by user and country in 1-hour windows
• Flags users who logged in from more than one country in the same hour

Create the rule.

Simulate the attack. Connect to a VPN server in a different country and sign into the Azure portal or any Microsoft service with the same account you are using for this lab. Then disconnect and sign in again from your real location. After a few minutes, check the Incidents blade.

Module 5: Automation and Playbook

So far Sentinel detects threats and creates incidents. But a SOC analyst still has to log in and look at those incidents. For common, well-understood alerts, you can automate the response entirely. That is what playbooks are for.

What is a Playbook?

A Playbook in Sentinel is an automated workflow built on Azure Logic Apps. When an incident is created (or an alert fires), Sentinel can trigger the playbook automatically. The playbook then performs actions: send an email, post to Slack, open a ticket in ServiceNow, block an IP in a firewall, whatever you have configured.

Logic Apps is a no-code/low-code workflow automation service in Azure. It has hundreds of built-in connectors (Outlook, Teams, Jira, ServiceNow, etc.), so you can chain together actions visually without writing code.

Playbook trigger types you can choose from:

• Playbook with incident trigger - fires when a Sentinel incident is created. The most common choice for incident response.
• Playbook with alert trigger - fires when a specific alert is generated, before it becomes an incident.
• Playbook with entity trigger - fires when a specific entity (like a user account or IP) is involved in an incident.
• Blank playbook - starts empty, you build the whole thing yourself.

Step 1: Create the Playbook

In the Defender portal, go to Microsoft Sentinel > Configuration > Automation. Click Create > Logic App playbook.

You will see the playbook type options described above. Select Playbook with incident trigger.

You land on a deployment template form:

• Playbook Name: SOC_EMAIL_ALERT
• Subscription: Azure subscription 1
• Resource Group: sentinel-lab

Click Next and then Create. The playbook gets created and you will see a Connections page showing that it uses a managed identity to connect to Sentinel.

Step 2: Grant Permissions to the Playbook

After creating the playbook, you may see a warning that says something like "Connect with managed identity - grant permissions to the managed identity after deployment." This is because the Logic App needs permission to read incident data from your Sentinel workspace.

Go to Azure Portal > Resource Groups > sentinel-lab > Access Control (IAM).

Click Add > Add role assignment. Search for Log Analytics Contributor and select it. Click Next to go to the Members tab.

• Assign access to: Managed Identity
• Click Select members, change the identity type to Logic App, and find SOC_EMAIL_ALERT

Click Review + assign. This gives the playbook the ability to read incident and alert data from your workspace.

Step 3: Design the Workflow in Logic App Designer

Search for Logic Apps in the Azure Portal, find SOC_EMAIL_ALERT, and go to Development Tools > Logic App Designer.

You will see the canvas with a single trigger block at the top labeled Microsoft Sentinel incident.

Click the + button to add an action. Search for Alert - Get incident and select it. This action fetches the full incident details so you can include them in the email.

In the action parameters, use the dynamic values from the trigger:

• Subscription ID: select Incident Workspace Subscription ID from the dynamic content
• Resource Group: select Incident Workspace Resource Group Name
• Workspace ID: select Workspace ID
• Alert ID: select Alert System ID

The designer wraps this in a For each loop automatically, because one incident can contain multiple alerts.

Next, add another action inside the loop. Search for Send an email (V2) (this uses Outlook). Fill in:

• To: your email address

• Subject: New Incident: followed by the dynamic Incident Title field

• Body: Something like:

  copy

  Hi SOC Team,
  
  There is an alert for your attention:
  
  Alert Description: [Alert Description]
  Alert Severity: [Alert Severity]
  

  Use the dynamic content picker to insert Alert Description and Alert Severity.

Set Importance to High. Save the workflow.

Step 4: Connect the Playbook to an Analytics Rule

Now we wire the playbook to a rule so it fires automatically.

Go to Sentinel > Configuration > Analytics and edit one of the rules you created (for example, Windows_Brute_Force). Go to the Automated response tab. Click Add new and create an automation rule:

• Automation rule name: Email notification to SOC Team
• Trigger: When incident is created
• Condition: Analytic rule name contains Current rule
• Action: Run playbook > SOC_EMAIL_ALERT

Click Apply.

Step 5: Test the Playbook

Trigger the rule the same way you did during simulation. Enter wrong passwords a few times on the Windows machine, wait 5 minutes, and check your email. If everything is configured correctly you will get an email with the incident title, description, and severity, sent automatically the moment Sentinel creates the incident.

What We Built

By the end of this lab, we had a functioning SOC environment that:

• Collects Windows Event Logs and Linux Syslog from two on-premises VMs into a central Log Analytics Workspace
• Detects four distinct attack scenarios using custom KQL analytics rules mapped to MITRE ATT&CK
• Creates incidents automatically with full context for analyst investigation
• Sends automated email alerts to the SOC team the moment a new incident is created

The full pipeline looks like this:

On-prem VM (Windows/Ubuntu)
    |
Azure Arc (registers machine with Azure)
    |
Azure Monitor Agent (collects logs)
    |
Data Collection Endpoint (receives logs)
    |
Data Collection Rule (defines what to collect and where to send it)
    |
Log Analytics Workspace (stores all logs)
    |
Microsoft Sentinel (runs KQL rules on top of the workspace)
    |
Incidents blade (analyst investigation)
    |
Logic App Playbook (automated response, email alert)

Key Terms Cheatsheet

If you want to extend this lab further, the natural next steps are adding more data connectors (Microsoft Defender for Endpoint, Sysmon for deeper Windows telemetry), building workbooks for visual dashboards, and exploring Sentinel's built-in rule templates in the Content Hub which cover hundreds of known attack patterns out of the box.