Deploy a Security Operations Lab

Deploy a cloud SIEM, write KQL detection rules, and investigate incidents.

Introduction

30 Second Summary

Every day, security teams sift through thousands of alerts to find the real threats hiding in their organization's data. The tools they use to do this are called SIEMs, and knowing how to operate one is a core skill for anyone entering cybersecurity.

In this project, you will deploy a complete Security Operations Center training environment using Microsoft Sentinel, investigate realistic attack data from six simulated security products, and create your own custom detection rule.

What You'll Build

A fully operational Microsoft Sentinel workspace populated with realistic multi-source attack telemetry, custom detection rules, and correlated security incidents for hands-on investigation.

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

  • A Microsoft Sentinel workspace deployed in Azure with pre-recorded telemetry from six simulated security products including CrowdStrike, Palo Alto Networks, and Okta.
  • A custom KQL detection rule that generates alerts based on suspicious patterns you identify in the ingested data.
  • A completed incident investigation using the MITRE ATT&CK framework to trace a correlated multi-stage attack chain from initial access to impact.
  • Secret Mission: An automation rule that enriches incidents with threat intelligence data and auto-assigns severity based on attack tactics.

Are there any prerequisites?

No prior security or Azure experience is needed. This guide includes full setup instructions for every tool you'll use, starting from a free Azure account.

Set Up Your Azure Account

Microsoft Sentinel runs entirely in Azure. To deploy your SOC lab, you need an active Azure subscription with the right permissions to create resources.

In this step, you'll sign in to Azure, confirm you have the correct role on your subscription, and open Cloud Shell. Cloud Shell is a browser-based terminal built into the Azure portal that comes with the tools you need pre-installed.

In this step, get ready to:
  • Create or sign in to a free Azure account.
  • Verify your subscription permissions.
  • Open Azure Cloud Shell in PowerShell mode.
Create or sign in to your Azure account

You need an active Azure subscription to deploy Microsoft Sentinel. If you already have one, you can sign in and skip ahead to the next substep.

  • Open your browser and navigate to the Azure sign-up page:
  • https://azure.microsoft.com/pricing/purchase-options/azure-account
  • Click Start free if you are creating a new account, or click Sign in if you already have an Azure account.
  • Follow the prompts to complete sign-up or sign-in. New accounts require a Microsoft account, a phone number for verification, and a credit card (you will not be charged during the free trial).
  • Once signed in, you should land on the Azure portal home page at portal.azure.com.

What is Azure?

Azure is Microsoft's cloud computing platform. It provides hundreds of services for building, deploying, and managing applications. Microsoft Sentinel is one of those services, focused specifically on security operations.

Can't create an account?

If you see an error about an existing Microsoft account, try signing in instead of creating a new account. If your credit card is declined, try a different card or contact your bank.

Help me troubleshoot my Azure account creation

Verify your subscription role

Microsoft Sentinel requires Owner or Contributor permissions on your Azure subscription to create resources. Let's confirm you have the right access before proceeding.

  • In the Azure portal, click the search bar at the top of the page.
  • Type Subscriptions and select Subscriptions from the results.
  • Click on your subscription name to open it.
  • In the left sidebar, click Access control (IAM).
  • Click the Check access tab.
  • Click the View my access button.
  • Confirm that your role is listed as Owner or Contributor.

What is Access control (IAM)?

IAM stands for Identity and Access Management. This page shows who has what permissions on your Azure resources. The Owner role gives full access to create, modify, and delete resources. The Contributor role does the same but cannot manage access for other users.

If you just created a free Azure account, you are automatically the Owner of the subscription that comes with it.

Don't see Owner or Contributor?

If you created your Azure account moments ago, wait a minute and refresh the page. New accounts are automatically assigned the Owner role. If you are using an organization's subscription, contact your IT administrator to request Contributor access.

Help me get the right permissions on my Azure subscription

Open Azure Cloud Shell

Azure Cloud Shell is a browser-based terminal built into the Azure portal. It comes pre-installed with the Azure CLI, PowerShell modules, and other tools you'll need for deployment commands.

  • Look at the top navigation bar of the Azure portal (the dark bar at the very top).
  • Click the >_ icon (Cloud Shell) in the top navigation bar.
  • If this is your first time opening Cloud Shell, you will be prompted to select your storage options. Select No storage account required for the fastest setup (ephemeral session). Alternatively, you can create a storage account to persist files across sessions.
  • When prompted to choose an environment, select PowerShell.
  • Wait a few seconds for the terminal to initialize. You should see a prompt similar to PS /home/yourname> or PS Azure:\>.

Why PowerShell instead of Bash?

Cloud Shell offers both Bash and PowerShell. The Microsoft Sentinel Training Lab deployment uses Azure CLI commands that work in both environments. PowerShell is the default for Azure management and integrates with Azure PowerShell modules for more advanced operations later.

Cloud Shell not opening?

Make sure you are clicking the >_ icon in the top navigation bar, not in the left sidebar menu. If Cloud Shell still does not launch, try clearing your browser cache and refreshing the page.

Help me troubleshoot Azure Cloud Shell not launching

Your Azure environment is ready. Next up, you'll create a Log Analytics workspace and enable Microsoft Sentinel on it.

Create a Log Analytics Workspace and Enable Microsoft Sentinel

Before Microsoft Sentinel can detect threats, it needs a place to store and query log data. That place is a Log Analytics workspace.

In this step, you will create a Log Analytics workspace, enable Microsoft Sentinel on top of it, and then access your workspace through the Microsoft Defender portal where all security operations happen.

In this step, get ready to:
  • Create a Log Analytics workspace inside a new resource group.
  • Enable Microsoft Sentinel on the workspace.
  • Access the Defender portal and verify Microsoft Sentinel appears.
Create the workspace and resource group

A Log Analytics workspace is a dedicated data environment that collects, stores, and lets you query security logs. You will bundle it inside a resource group, which acts as a container for related Azure resources.

  • In the Azure portal search bar at the top, type Microsoft Sentinel and select Microsoft Sentinel from the results.
  • Click Create.
  • Click Create a new workspace.
  • Under Subscription, select your active Azure subscription.
  • Under Resource group, click Create new.
  • Enter sentinel-training-lab-rg as the resource group name, then click OK.
  • In the Name field, enter sentinel-training-ws.
  • Select a Region closest to you.
  • Click Review + Create, then click Create.
  • Wait for the notification that says your deployment is complete.

What is a Log Analytics workspace?

A Log Analytics workspace is the data engine behind Microsoft Sentinel. It collects and indexes security logs from across your environment so you can query them using KQL (Kusto Query Language).

Think of the workspace as the database and Microsoft Sentinel as the intelligence layer that sits on top of it, turning raw logs into alerts and incidents.

Why a dedicated resource group?

Microsoft recommends a dedicated resource group for your Sentinel workspace. This keeps all Sentinel-related resources (the workspace, playbooks, and workbooks) grouped together for simpler permissions and easier cleanup.

Enable Microsoft Sentinel on the workspace

The workspace is now live, but it is just a blank data store. Enabling Microsoft Sentinel adds the SIEM intelligence layer: detection rules, incident management, threat hunting, and automation.

  • After the workspace deployment completes, click Go to resource on the deployment notification, or navigate back to Microsoft Sentinel using the Azure portal search bar.
  • If you navigated back, click Create again.
  • Select your sentinel-training-ws workspace from the list.
  • Click Add.
  • Wait for the deployment to complete. You will see a notification confirming Microsoft Sentinel has been added to your workspace.

What is a SIEM?

SIEM stands for Security Information and Event Management. It is a platform that collects security data from many sources, correlates events into meaningful patterns, and raises alerts when something looks suspicious.

Microsoft Sentinel is Microsoft's cloud-native SIEM. It uses the Log Analytics workspace you just created as its data foundation.

Don't see your workspace in the list?

Make sure you are looking under the correct subscription. If you have multiple subscriptions, use the Subscription filter at the top of the workspace selection page.

Also confirm the workspace deployment completed successfully before trying to add Sentinel.

Why isn't my workspace appearing when I try to add Microsoft Sentinel?

Access the Microsoft Defender portal

Microsoft Sentinel is moving exclusively to the Microsoft Defender portal. As a new Sentinel customer with Owner permissions, your workspace is automatically onboarded to the Defender portal when you enable Sentinel.

  • Open a new browser tab and navigate to https://security.microsoft.com.
  • Sign in with the same Microsoft account you used for the Azure portal.
  • If this is your first time accessing the Defender portal, you will see a provisioning message. Wait a few minutes for the process to complete.
  • Once provisioned, look at the left navigation pane. You should see Microsoft Sentinel listed as a section.

Why the Defender portal instead of the Azure portal?

After March 31, 2027, Microsoft Sentinel will no longer be supported in the Azure portal. It will be available exclusively in the Defender portal. By working in the Defender portal from the start, you are learning the platform that SOC analysts use in production.

Sentinel not showing in the Defender portal?

If Microsoft Sentinel does not appear in the left navigation after a few minutes, you may need to manually connect the workspace.

  • In the Defender portal, navigate to System then Settings then Microsoft Sentinel then Connect a workspace.
  • Select your sentinel-training-ws workspace and click Next.
  • Select it as the Primary workspace, then click Connect.

Help me connect my Microsoft Sentinel workspace to the Defender portal.

Your SOC foundation is in place. Next up, you will deploy the Microsoft Sentinel Training Lab to fill your workspace with realistic attack data from six simulated security products.

Deploy the Microsoft Sentinel Training Lab

Your workspace is ready, but it has no security data to investigate. A real SOC receives thousands of alerts from firewalls, endpoints, identity providers, and cloud platforms every day.

Instead of setting up real infrastructure and waiting for attacks, you'll deploy the official Microsoft Sentinel Training Lab. This ARM template ingests pre-recorded telemetry from six simulated security products into your workspace, giving you a realistic multi-source environment in minutes.

In this step, get ready to:
  • Create a User-Assigned Managed Identity for detection rule deployment.
  • Grant the identity Microsoft Graph permissions.
  • Deploy the Training Lab and ingest telemetry from 6 data sources.
Create a User-Assigned Managed Identity

The Training Lab deploys custom detection rules to Microsoft Defender XDR via the Microsoft Graph Security API. For this to work, the deployment needs an identity with the right permissions.

A User-Assigned Managed Identity (UAMI) is an Azure resource that acts like a service account. You create it once and attach it to any resource that needs to authenticate to Azure services without storing credentials.

  • In your Azure Cloud Shell (PowerShell) session from earlier, create the UAMI by running this command:
az identity create --resource-group sentinel-training-lab-rg --name SentinelDetectionRulesIdentity

What does this command do?

This creates a managed identity named SentinelDetectionRulesIdentity inside your sentinel-training-lab-rg resource group. The identity will later authenticate to the Microsoft Graph API on behalf of the Training Lab deployment.

  • Look at the JSON output. Find the id field. It looks like this:
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/SentinelDetectionRulesIdentity
  • Copy this full resource ID and save it somewhere (a text file or sticky note). You will need it during deployment.

Seeing a 'resource group not found' error?

Make sure the resource group name matches exactly: sentinel-training-lab-rg. Names are case-sensitive. If you used a different name in Step 2, substitute it here.

Help me troubleshoot this Azure identity creation error.

Grant the UAMI the Microsoft Graph permission

The identity exists, but it has no permissions yet. You need to grant it the CustomDetection.ReadWrite.All application permission so it can create detection rules in Microsoft Defender XDR.

  • Get the UAMI's object ID by running this command in Cloud Shell:
$miObjectId = (az identity show --resource-group sentinel-training-lab-rg --name SentinelDetectionRulesIdentity --query principalId -o tsv)
  • Get the Microsoft Graph service principal ID by running:
$graphSpId = (az ad sp show --id "00000003-0000-0000-c000-000000000000" --query id -o tsv)
  • Build the permission assignment body by running:
$body = @{principalId=$miObjectId; resourceId=$graphSpId; appRoleId="e0fd9c8d-a12e-4cc9-9827-20c8c3cd6fb8"} | ConvertTo-Json -Compress
  • Assign the permission by running:
az rest --method POST --uri "https://graph.microsoft.com/v1.0/servicePrincipals/$graphSpId/appRoleAssignedTo" --headers "Content-Type=application/json" --body $body

What do these commands do?

  • The first command retrieves the UAMI's principal ID (its unique object identifier in Azure AD).
  • The second command finds the Microsoft Graph service principal using its well-known application ID.
  • The third and fourth commands build and submit a request to assign the CustomDetection.ReadWrite.All role to your UAMI.
  • You should see a JSON response with a status field. This confirms the permission was granted successfully.

Getting a 'forbidden' or 'insufficient privileges' error?

You need Owner or Global Administrator permissions on your Azure AD tenant to assign application permissions. If you are on a restricted subscription, ask your administrator to run the permission-grant commands for you.

Help me fix this permissions error when granting Microsoft Graph CustomDetection.ReadWrite.All to my managed identity.

Deploy the Training Lab from the Azure-Sentinel GitHub repository

The UAMI is ready. Now you will launch the Training Lab's ARM template, which ingests pre-recorded telemetry from six security products and deploys 22 custom detection rules into your workspace.

  • Open the Training Lab deployment page by navigating to this URL in a new browser tab:
https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2FAzure-Sentinel%2Fmaster%2FTools%2FMicrosoft-Sentinel-Training-Lab%2FPackage%2FmainTemplate.json

What is this link?

This is the "Deploy to Azure" link from the official Azure/Azure-Sentinel GitHub repository under Tools/Microsoft-Sentinel-Training-Lab. It opens the Azure portal's custom template deployment page with the Training Lab's ARM template pre-loaded.

  • On the deployment form, select your subscription from the **Subscription** dropdown.
  • Select sentinel-training-lab-rg from the **Resource Group** dropdown.
  • Select your workspace (sentinel-training-ws) from the **Workspace** dropdown.
  • Make sure the **Region** matches the region of your existing workspace.
  • In the **Detection Rules Identity Resource Id** field, paste the full UAMI resource ID you copied earlier.
  • Click **Review + create**, then **Create**.

What is the detectionRulesIdentityResourceId parameter?

This parameter tells the ARM template which managed identity to use when calling the Microsoft Graph Security API to create detection rules. Without it, the 22 custom detection rules would not be deployed.

The deployment takes approximately 30 minutes. During this time, the template ingests pre-recorded telemetry from six data sources into your workspace.

What data sources are being ingested?

  • CrowdStrike (endpoint detection and response).
  • Palo Alto Networks (firewall logs).
  • Okta (identity and authentication events).
  • AWS CloudTrail (cloud API activity).
  • GCP Audit Logs (Google Cloud activity).
  • MailGuard365 (email security).

This simulates a real SOC environment where security data flows in from multiple vendors and platforms.

  • Wait for the deployment to complete. You can monitor progress by clicking **Go to resource group** from the deployment notification, then checking the **Deployments** section.
  • Once the deployment shows a green checkmark with status **Succeeded**, navigate to the Microsoft Defender portal at https://security.microsoft.com.
  • In the left navigation pane, select **Microsoft Sentinel**. You should see ingested data on the overview page and recent incidents generated by the 22 custom detection rules.

Deployment failed or stuck?

If the deployment fails, click the failed deployment to see the error details. The most common issues are region mismatches (workspace region must match the deployment region) and missing RBAC permissions (you need Contributor or Owner on the resource group).

If the deployment is running beyond 30 minutes, this is usually normal. Azure ARM template deployments can vary. Wait up to 45 minutes before troubleshooting.

Help me troubleshoot my failed Microsoft Sentinel Training Lab deployment.

Your workspace is now loaded with realistic attack data from six simulated security products, and 22 detection rules are already generating incidents. Next up, you'll explore this data using KQL queries and write your own custom detection rule.

Explore Your Data with Advanced Hunting

Your workspace is now loaded with realistic security telemetry from six different products. The next question is: what does this data actually look like?

In this step, you will query the ingested data using KQL (Kusto Query Language) in the Defender portal's Advanced Hunting interface. You will explore tables from each data source, hunt for suspicious patterns, and turn one of those patterns into your own custom detection rule.

In this step, get ready to:
  • Explore the available data tables across all six ingested sources.
  • Write KQL queries to find suspicious CrowdStrike process executions and Okta failed authentications.
  • Create your own custom detection rule based on a pattern you discover.
Discover your data tables in Advanced Hunting

Advanced Hunting is the KQL query interface inside the Defender portal. It lets you search across all data ingested into your Microsoft Sentinel workspace in real time.

  • Return to the Microsoft Defender portal at https://security.microsoft.com.
  • In the left navigation pane, expand Microsoft Sentinel, then select Advanced Hunting.
  • Click the Schema tab on the left side of the query editor to see all available tables.
  • Scroll through the tables panel. You should see tables from each of your six data sources listed.

Run a quick discovery query to confirm data is present across all tables. Paste the following into the query editor and click Run query:

search *
| summarize count() by $table
| sort by count_ desc

What does this query do?

  • search * scans across every table in the workspace.
  • summarize count() by $table groups the results by table name and counts the rows in each.
  • sort by count_ desc orders the results so the tables with the most data appear first.

You should see tables like CommonSecurityLog, AWSCloudTrail, CrowdStrikeDetections, OktaV2_CL, GCPAuditLogs, and MailGuard365_Threats_CL in the results.

Not seeing any results?

The Training Lab deployment takes approximately 30 minutes to fully ingest data. If you deployed the lab recently and see empty results, wait a few more minutes and re-run the query.

Also confirm you are in the correct workspace. Check that your sentinel-training-ws workspace is selected in the workspace picker at the top of the Advanced Hunting page.

Still stuck? Help me troubleshoot why my Advanced Hunting query returns no results.

Write KQL queries to hunt for suspicious activity

Now that you can see data is flowing, you will write targeted queries using core KQL operators: where, project, summarize, and sort by.

  • Clear the query editor, then paste the following query to find high-severity CrowdStrike process executions:
// Find critical CrowdStrike detections with process details
CrowdStrikeDetections
| where TimeGenerated > ago(4h)
| where SeverityName in ("High", "Critical")
| project TimeGenerated, Name, SeverityName, Tactic, Technique
| sort by TimeGenerated desc
  • Click Run query to execute it.

What does this query do?

  • CrowdStrikeDetections targets the table containing endpoint detection data from CrowdStrike.
  • where TimeGenerated > ago(4h) filters to events from the last 4 hours of ingested data.
  • where SeverityName in ("High", "Critical") narrows results to only the most serious detections.
  • project selects only the columns you want to see, reducing clutter.
  • sort by TimeGenerated desc shows the newest events first.

You should see rows listing detection names, severity levels, and MITRE ATT&CK tactics associated with each event.

  • Now query the Okta identity data to find failed authentication attempts. Clear the editor and paste:
// Find failed Okta authentication events
OktaV2_CL
| where TimeGenerated > ago(4h)
| where outcome_result_s == "FAILURE"
| summarize FailedAttempts = count() by actor_alternateId_s
| sort by FailedAttempts desc
  • Click Run query to see the results.

What does this query do?

  • OktaV2_CL is the custom table holding Okta identity events (account takeover attempts, MFA manipulation).
  • where outcome_result_s == "FAILURE" filters to only authentication failures.
  • summarize ... count() by actor_alternateId_s aggregates the failures by user identity, showing which accounts have the most failed logins.
  • A high count of failures for a single account could indicate a brute-force attack or credential stuffing attempt.

You should see a table of user identities ranked by the number of failed authentication attempts.

Adjust the time window if needed

The Training Lab ingests pre-recorded data with specific timestamps. If your queries return no results with ago(4h), try expanding the window to ago(30d) to capture all ingested telemetry.

Create your first custom detection rule

You have just identified suspicious patterns in your data. The next step is to turn one of those patterns into a rule that automatically generates alerts when it fires.

  • In the Advanced Hunting query editor, paste the following query that detects devices with CrowdStrike alerts spanning multiple MITRE ATT&CK tactics:
// Detect devices with alerts across 3+ MITRE ATT&CK tactics
CrowdStrikeDetections
| where TimeGenerated > ago(4h)
| where SeverityName in ("High", "Critical")
| extend CSHostname = tostring(Device.hostname)
| summarize TacticCount = dcount(Tactic), Tactics = make_set(Tactic) by CSHostname
| where TacticCount >= 3
  • Click Run query to verify the query returns results.
  • After the results appear, click the Create detection rule button above the results table.

What does this query detect?

This query identifies endpoints where CrowdStrike has flagged high-severity alerts across three or more different MITRE ATT&CK tactics. A single device appearing in multiple tactics (for example, Initial Access, Lateral Movement, and Exfiltration) is a strong indicator of a multi-stage compromise in progress.

  • In the rule creation form, fill in the following details:
  • In the Name field, enter a descriptive name for your rule (for example, Multi-Tactic Compromise on Single Device).
  • Set Severity to High.
  • Under Frequency, select how often the rule should run (for example, every 4 hours).
  • Leave the MITRE ATT&CK mapping as auto-detected.
  • Click Create to save the rule.

What is a custom detection rule?

A custom detection rule is a scheduled KQL query that runs automatically at the frequency you set. When the query returns results, it generates alerts in Microsoft Defender XDR. These alerts can then be grouped into incidents for investigation.

This is how SOC teams codify their hunting discoveries into repeatable, automated detections.

  • Navigate to Hunting in the left pane, then select Custom detection rules.
  • Find your new rule in the list and click Run to execute it immediately.
  • Check Triggered alerts to verify the rule fires against the lab data.

Rule not triggering any alerts?

If the rule shows no triggered alerts, expand your time window in the query from ago(4h) to ago(30d). The Training Lab data may have been ingested with timestamps outside a 4-hour window.

Also verify the threshold. If you set TacticCount >= 3 and the lab data only has 2 tactics per device, lower the threshold to TacticCount >= 2 temporarily.

Need more help? Help me troubleshoot why my custom detection rule is not triggering alerts.

You now have hands-on experience querying security telemetry with KQL and turning suspicious patterns into automated detection rules. Next, you will investigate the multi-stage incidents these rules generate using the MITRE ATT&CK framework.

Investigate a Multi-Stage Security Incident

In the previous step, you explored your security data with KQL and created a custom detection rule that fires on suspicious patterns.

Now it's time to think like a SOC analyst. The Training Lab's 22 detection rules have been correlating alerts behind the scenes, grouping related suspicious activity into multi-stage incidents.

You'll investigate one of these correlated incidents from start to finish. That means tracing an attack chain, mapping it to the MITRE ATT&CK framework, and closing the investigation with a professional classification.

In this step, get ready to:
  • Select and review a multi-stage incident in the Defender portal.
  • Explore the MITRE ATT&CK coverage map to visualize detection tactics.
  • Document the attack chain and close the incident with a classification.
Select and review a multi-stage incident

Security incidents in Microsoft Sentinel aren't single alerts in isolation. They're correlated groups of alerts that together tell the story of an attack.

  • In the Microsoft Defender portal (https://security.microsoft.com), click Incidents in the left navigation pane.
  • You should see a list of incidents generated by the Training Lab's 22 detection rules.
  • Look for an incident with multiple correlated alerts. These are labelled with names following the pattern "Lab Stage # - Name (Source)".
  • Click on an incident that shows multiple alerts or entities to open it.

Once you've opened the incident, you'll see a detailed view with several tabs to explore.

  • Review the incident timeline to see the sequence of alerts in chronological order.
  • Check the affected entities (users, devices, IP addresses) involved in the incident.
  • Examine the correlated alerts to understand how individual detections connect into a single attack story.

What is a multi-stage incident?

A multi-stage incident represents an attack that spans multiple phases. For example, an attacker might start with a phishing email (initial access), then steal credentials (credential access), move to other systems (lateral movement), and finally exfiltrate data (exfiltration).

Microsoft Sentinel correlates these individual alerts into one incident so you can see the full picture instead of chasing isolated signals.

Don't see any incidents?

The Training Lab deployment takes approximately 30 minutes to fully ingest data and generate incidents. If you deployed the lab recently, wait a few more minutes and refresh the Incidents page.

Also confirm you're in the correct workspace by checking that sentinel-training-ws is selected under Microsoft Sentinel in the Defender portal navigation.

Help me troubleshoot why I don't see incidents in Microsoft Sentinel

Explore the MITRE ATT&CK coverage map

The MITRE ATT&CK framework is a knowledge base of adversary tactics and techniques observed in real-world attacks. Microsoft Sentinel maps your detection rules to this framework so you can visualize which attack stages you can actually detect.

  • In the Defender portal left navigation, click Microsoft Sentinel.
  • Look for the MITRE ATT&CK option and click it to open the matrix view.
  • The matrix displays tactics as columns (e.g., Initial Access, Execution, Persistence) and techniques as rows within each tactic.
  • Cells that are highlighted or shaded indicate techniques your active detection rules cover.

The Training Lab's detection rules cover 10 MITRE ATT&CK tactics. Take a moment to scan the matrix and notice which tactics have the most coverage and which have gaps.

Why does coverage matter?

In a real SOC, gaps in your MITRE ATT&CK coverage represent blind spots. If you have strong detection for Initial Access but nothing for Lateral Movement, an attacker who gets past your perimeter can move freely without triggering alerts.

Security teams use this matrix to prioritize which detection rules to build next.

  • Return to your open incident and note which MITRE ATT&CK tactics are mapped to its alerts.
  • This tells you which stages of the attack chain the adversary executed.
Document the attack chain and close the incident

The final step in any investigation is documenting what happened and closing the incident with a formal classification. This creates an audit trail and helps your team learn from each investigation.

  • Return to your open incident in the Incidents view.
  • Based on the timeline and correlated alerts, identify three parts of the attack chain:
  • Initial access vector - how did the attacker get in? (e.g., phishing email, compromised credentials, exposed service).
  • Lateral movement - how did the attacker spread? (e.g., credential reuse, remote execution on other hosts).
  • Impact - what was the attacker's goal? (e.g., data exfiltration, privilege escalation, persistence).

What if I can't identify all three stages?

Not every incident covers all three stages neatly. Some incidents may focus on just initial access and credential theft. Document what you can observe from the evidence available.

Now close the incident with your findings.

  • In the incident details, look for the option to change the incident status.
  • Set the status to Closed.
  • Select a classification:
  • True Positive - the incident represents a real attack (use this for the Training Lab data since it simulates real attacks).
  • False Positive - the detection fired but there was no real threat.
  • Benign Positive - a real activity was detected but it is authorized or expected.
  • Add investigation notes summarizing the attack chain you documented (initial access vector, lateral movement method, and impact).
  • Click Apply or Save to close the incident.

Why classify incidents?

Classifications feed back into your detection engineering process. If a rule produces too many False Positives, you know to tune it. If it catches real attacks (True Positives), you know it's working.

Investigation notes also help the next analyst who might review the same type of incident.

Can't find the close or classify option?

The classification options appear when you change the incident status to Closed. Look for a Status dropdown or an Actions menu on the incident detail page.

Help me find how to close and classify an incident in Microsoft Defender

Secret mission

Automate Incident Enrichment with Threat Intelligence

You've built a working SOC lab and investigated incidents manually. But real Security Operations Centers don't wait for an analyst to notice a critical technique. They automate. In this secret mission, you'll connect a threat intelligence feed, correlate indicators of compromise against your telemetry, and build an automation rule that auto-elevates incidents involving credential-based attacks.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Your Microsoft Sentinel workspace is covered by the 31-day free trial (10 GB/day ingestion free), so there are no costs during that window.

Cost warning

After your 31-day free trial ends, Microsoft Sentinel charges approximately $4.30/GB/day (East US) on the Pay-As-You-Go tier. Your lab data is only ~10 MB, but the workspace itself remains billable once the trial expires.

If you do not plan to use the lab after the trial period, delete the resource group to avoid any charges.

Resources you used:

  • Resource group sentinel-training-lab-rg (contains all lab resources).
  • Log Analytics workspace sentinel-training-ws with Microsoft Sentinel enabled.
  • User-Assigned Managed Identity SentinelDetectionRulesIdentity.
  • Azure Automation account deployed by the Training Lab.
  • MDTI data connector and ThreatIntelIndicators data.
  • Custom detection rule and automation rule you created.

Keep everything running

No action needed. Choose this if you are still actively exploring the lab exercises or plan to return within your 31-day free trial window.

  • Your lab data is static (~10 MB) and well within the free tier limit.
  • No processes are running that consume compute. The workspace only costs money after the trial ends.
  • Set a calendar reminder for day 30 to decide whether to keep or delete.

Pause - I'll come back to this later

There is no true "pause" for a Log Analytics workspace. The workspace exists or it does not. However, you can reduce exposure by disabling data connectors so no new data is ingested.

  • In the Defender portal, navigate to Microsoft Sentinel, then select Data connectors.
  • Disconnect any active connectors (including the MDTI connector) to stop new ingestion.
  • Your existing lab data and detection rules remain intact for when you return.
  • Remember to delete the resource group before your 31-day trial expires if you do not plan to continue.

Delete - I don't want to use this again

Remove all project resources and start fresh. Deleting the resource group removes everything inside it: the workspace, Sentinel, the UAMI, the Automation account, detection rules, and automation rules.

  • Open Azure Cloud Shell from the Azure portal (click the >_ icon in the top navigation bar).
  • Delete the resource group by running this command:
az group delete --name sentinel-training-lab-rg --yes --no-wait
  • The --no-wait flag returns control immediately. Deletion continues in the background and takes a few minutes.
  • Verify the group is gone by navigating to Resource groups in the Azure portal. You should no longer see sentinel-training-lab-rg in the list.

What about my Azure account?

Deleting the resource group removes all project resources but keeps your Azure account active. You can continue using Azure for other projects at no charge as long as you stay within free-tier limits.

If you want to fully cancel your Azure subscription, search for Subscriptions in the Azure portal, select your subscription, and look for the cancellation option in the subscription details.

Nice Work!

Nice Work!

You've just deployed and operated a professional Security Operations Center! You built a complete Microsoft Sentinel environment with realistic attack data, wrote detection rules, and investigated multi-stage incidents the same way a SOC analyst would on the job.

You've learned how to:

  • Deployed a Microsoft Sentinel workspace with realistic multi-source attack telemetry from six simulated security products.
  • Created a custom KQL detection rule that generates alerts based on suspicious patterns you discovered in the data.
  • Investigated a correlated multi-stage incident using the MITRE ATT&CK framework and closed it with a classification and root cause analysis.
  • Built an automation rule that enriches incidents with threat intelligence data and auto-assigns severity based on MITRE ATT&CK tactics.

Ready to quiz yourself?