Detect and Respond with Microsoft Sentinel

Build a full SOC analyst workflow with KQL, incident investigation, and automation.

Introduction

30 Second Summary

Every organization faces cyber attacks. Security operations teams need to detect suspicious activity, investigate what happened, and respond before damage spreads.

In this project, you will build a complete SOC analyst workflow in Microsoft Sentinel. You'll hunt for threats using KQL queries, create a custom detection rule, investigate a multi-stage incident, and automate response with a playbook.

What You'll Build

A full security operations workflow in Microsoft Sentinel, covering threat hunting, detection engineering, incident investigation, and automated incident response.

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

  • A deployed Microsoft Sentinel Training Lab with realistic attack data from 6 security products.
  • Custom KQL hunting queries and a scheduled analytics rule with MITRE ATT&CK mapping and entity mapping.
  • A working automation rule paired with a Logic Apps playbook that automatically responds to high-severity incidents.
  • Secret Mission: Conduct a hypothesis-driven threat hunt using the MITRE ATT&CK matrix and promote your findings to a new detection rule.

Are there any prerequisites?

You need an Azure subscription with an Owner or Contributor role. A free Azure account with $200 credit works perfectly for this project.

The project uses the Microsoft Sentinel free trial, which covers up to 10 GB/day of log ingestion for 31 days.

Deploy the Microsoft Sentinel Training Lab

Before you can hunt for threats or investigate incidents, you need a working Microsoft Sentinel environment with realistic security data flowing into it.

Setting up data connectors and simulating attacks manually can take hours. Instead, you'll deploy Microsoft's official Training Lab, which pre-loads realistic attack telemetry from six security products into a fully configured Sentinel workspace in about 30 minutes.

In this step, get ready to:
  • Deploy the Microsoft Sentinel Training Lab ARM template from GitHub.
  • Wait for the deployment to finish ingesting data from 6 security products.
  • Verify that incidents appear in the Microsoft Defender portal.
Navigate to the Training Lab and start the deployment

The Microsoft Sentinel Training Lab is an open-source ARM template hosted in the official Azure/Azure-Sentinel GitHub repository. Clicking a single button deploys an entire Sentinel workspace with pre-recorded security data.

  • Open the Microsoft Sentinel Training Lab repository page in your browser:
  • https://github.com/Azure/Azure-Sentinel/tree/master/Tools/Microsoft-Sentinel-Training-Lab
  • Scroll down to the README and click the Deploy to Azure button.
  • Sign in with the Azure account that has Owner or Contributor access on your subscription.
  • On the custom deployment page, select your Subscription from the dropdown.
  • Under Resource group, click Create new.
  • Enter rg-sentinel-training as the resource group name, then click OK.
  • Select a Region close to your location (e.g., East US, West Europe).
  • Click Review + create, then click Create to start the deployment.

What does the ARM template deploy?

The template creates a Log Analytics workspace and enables Microsoft Sentinel on top of it. It then uses automation to ingest pre-recorded CSV data from the GitHub repository and deploy detection rules via the Microsoft Graph API.

By the time it finishes, you'll have a fully populated SIEM workspace with realistic attack data and correlated incidents ready to investigate.

Deployment fails immediately?

Confirm you have Owner or Contributor access on the subscription. If you only have Reader access, the template cannot create resources.

If you see a quota or region error, try selecting a different Azure region. Some regions restrict new workspace creation on free-trial subscriptions.

Help me troubleshoot my Training Lab deployment failure.

Wait for the deployment to complete

The Training Lab deployment takes approximately 30 minutes. During this time, the template ingests pre-recorded data from six security products and deploys 22 custom detection rules that generate correlated incidents.

  • Stay on the deployment page in the Azure portal. You'll see a progress indicator showing the deployment status.
  • Wait until the status changes to Your deployment is complete.

What data sources are being ingested?

The template ingests pre-recorded telemetry from six security products:

  • CrowdStrike (endpoint detections).
  • Palo Alto Networks (firewall logs).
  • Okta (identity events).
  • AWS CloudTrail (cloud activity).
  • GCP Audit Logs (cloud infrastructure abuse).
  • MailGuard365 (email security).

The 22 detection rules automatically correlate these events into multi-stage incidents mapped to MITRE ATT&CK tactics. This gives you a realistic SOC environment to practice in.

Use the wait time wisely

While the deployment runs, read through the Training Lab's README on GitHub. It outlines the exercises available and gives you context for the attack scenarios you'll investigate later.

Verify the deployment in the Defender portal

Once the deployment completes, you need to confirm that your Sentinel workspace is connected to the Microsoft Defender portal and that incidents have been generated from the ingested data.

  • Open a new browser tab and navigate to https://security.microsoft.com.
  • Sign in with the same Azure account you used for the deployment.
  • In the left navigation menu, expand Investigation & response.
  • Click Incidents & alerts, then select Incidents.
  • Confirm that you see incidents in the queue. You should see multi-stage incidents with alerts from multiple data sources.

What should I see?

The Incidents page shows a queue of correlated security incidents. Each incident combines alerts from multiple detection rules across the six data sources. You should see incidents with multiple alerts attached, covering different MITRE ATT&CK tactics like Initial Access, Credential Access, and Lateral Movement.

No incidents showing up?

The detection rules need a few minutes after data ingestion to fire and generate incidents. If the deployment finished less than 15 minutes ago, wait and refresh the page.

If your Sentinel workspace doesn't appear connected in the Defender portal, navigate to Microsoft Sentinel in the left navigation and confirm your workspace is listed and onboarded.

Help me connect my Sentinel workspace to the Defender portal.

Your Sentinel environment is fully deployed with realistic attack data. Next up, you'll use KQL to hunt for threats hidden in this data.

Hunt for Threats with KQL

Your Sentinel workspace is live with realistic attack data from six security products. Now it's time to do what SOC analysts do best: hunt for threats.

In this step, you'll write KQL (Kusto Query Language) queries to sift through security events and surface suspicious activity. You'll start with a simple failed-login query, build a brute-force detector, and finish with a cross-source correlation that ties identity failures to network scanning.

In this step, get ready to:
  • Write a basic KQL query to find failed login attempts across the ingested data.
  • Build an advanced brute-force detection query with configurable thresholds.
  • Correlate identity failures with network scanning events across data sources.
Navigate to Advanced Hunting and write a basic query

Before you can hunt, you need to find the query editor. The Defender portal's Advanced Hunting page gives you a KQL editor, a schema browser showing all available tables, and IntelliSense suggestions as you type.

  • In the Microsoft Defender portal (security.microsoft.com), expand Hunting in the left navigation bar.
  • Select Advanced hunting.
  • Look at the schema browser on the left side of the query editor. Expand a few tables (like SecurityEvent) to see their columns.
  • Paste the following query into the query editor to find failed login attempts across the last 7 days:
// Basic failed login detection
SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4625
| summarize FailureCount = count() by Account, IpAddress, Computer
| order by FailureCount desc
  • Click Run query to execute the query.

What does this query do?

KQL queries start with a table name and pipe (|) each operation to the next.

  • SecurityEvent is the table containing Windows security events from the Training Lab's ingested data.
  • EventID == 4625 filters to failed logon events only.
  • summarize ... by Account, IpAddress, Computer groups the failures and counts how many occurred per account and IP address.
  • order by FailureCount desc sorts results so the most-targeted accounts appear first.

You should see a results table listing accounts that experienced failed logins, along with the source IP addresses and how many failures each pair had.

Query returning no results?

  • Confirm your Sentinel workspace is connected to the Defender portal. The schema browser should show SecurityEvent as an available table.
  • Make sure the Training Lab deployment finished successfully. If it is still deploying, data may not be ingested yet.
  • Check that you selected the correct workspace if you have multiple workspaces connected.

Help me troubleshoot why my Advanced Hunting query returns no results from the Sentinel Training Lab data.

Build a brute-force detection query

A single failed login is normal. Five or more from the same IP address within 24 hours is suspicious. You'll now write a production-quality hunting query that uses configurable thresholds to flag potential brute-force activity.

  • Clear the query editor and paste this brute-force detection query:
// Brute Force Detection - Multiple Failed Logins from Single IP
let failedLoginThreshold = 5;
let timeWindow = 24h;
SecurityEvent
| where TimeGenerated > ago(timeWindow)
| where EventID == 4625
| summarize FailureCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by Account, IpAddress, Computer
| where FailureCount > failedLoginThreshold
| project FirstSeen, LastSeen, Account, IpAddress, Computer, FailureCount
| order by FailureCount desc
  • Click Run query to execute it.

What does this query do?

  • let failedLoginThreshold = 5 and let timeWindow = 24h define configurable variables. You can adjust these thresholds without rewriting the query logic.
  • summarize groups by account and IP, counting total failures and recording the first and last timestamps.
  • The second where clause after summarize filters out noise by keeping only accounts that exceed the threshold.
  • project selects only the columns a SOC analyst needs to see for triage.
  • Save this query by clicking the Save query drop-down button above the editor.
  • Select Save as.
  • Enter Brute Force Detection as the query name.
  • Choose the My queries folder, then click Save.

Your results should show accounts that had more than 5 failed logins from the same IP within 24 hours, with timestamps showing the attack window.

Seeing zero results after running?

  • Try lowering the failedLoginThreshold to 2 temporarily to confirm data exists. If results appear, the threshold is higher than the simulated attack data.
  • Try widening timeWindow to 7d to check if failures are spread over a longer period.

Help me figure out why my brute-force detection KQL query returns no results from the Sentinel Training Lab.

Correlate identity failures with network scanning

Real attackers don't stop at failed logins. After brute-forcing credentials, they typically scan the network for open ports. By joining identity events with firewall logs, you can spot this pattern and link the two phases of an attack to the same IP address.

  • Open a new query tab by clicking New query at the top of the Advanced Hunting page.
  • Paste this cross-source correlation query:
// Cross-source correlation: Identity failures followed by network scanning
let identityFailures = 
    SecurityEvent
    | where TimeGenerated > ago(7d)
    | where EventID == 4625
    | summarize FailCount = count() by IpAddress, bin(TimeGenerated, 1h)
    | where FailCount > 3;
identityFailures
| join kind=inner (
    CommonSecurityLog
    | where TimeGenerated > ago(7d)
    | where DeviceVendor == "Palo Alto Networks"
    | where Activity has "port" or Activity has "scan"
    | summarize ScanEvents = count() by SourceIP, bin(TimeGenerated, 1h)
) on $left.IpAddress == $right.SourceIP
| project TimeGenerated, IpAddress, FailCount, ScanEvents
| order by TimeGenerated desc
  • Click Run query to execute it.

What does this query do?

This query joins two completely different data sources to find a multi-stage attack pattern.

  • The let identityFailures block builds a temporary table of IP addresses that had more than 3 failed logins per hour.
  • The CommonSecurityLog table contains Palo Alto Networks firewall logs ingested by the Training Lab.
  • join kind=inner matches IP addresses that appear in BOTH tables within the same hour. Only IPs that failed authentication AND performed scanning will appear in results.
  • bin(TimeGenerated, 1h) groups events into hourly buckets so the join finds activity that happened in the same time window.
  • Save this query by clicking the Save query drop-down, then Save as.
  • Enter Cross Source Correlation as the name.
  • Choose the My queries folder and click Save.

If results appear, you've found IP addresses that failed authentication and then scanned the network. This is a classic attacker pattern that crosses two data sources.

Why cross-source correlation matters

Most individual alerts are noisy. A failed login alone is not a threat. A port scan alone is not a threat. But a failed login followed by a port scan from the same IP within the same hour is a strong indicator of malicious intent.

This ability to correlate across sources is what separates Microsoft Sentinel from basic log aggregation tools. It's also a key differentiator in security interviews.

Join returning empty results?

  • Verify the CommonSecurityLog table exists in your schema browser. If it doesn't appear, the Palo Alto Networks data connector may not have ingested yet.
  • Try running just the identityFailures portion (everything above the second identityFailures line) to confirm identity data exists. Then run just the CommonSecurityLog portion separately to confirm firewall data exists.
  • If both return data but the join doesn't, the simulated attack IPs may not overlap. Try changing kind=inner to kind=leftouter temporarily to see all identity failures regardless of matching scan events.

Help me debug my cross-source correlation KQL query that joins SecurityEvent with CommonSecurityLog.

✔️ Awesome, I've got everything!

Great. Confirm both queries are saved in your My queries folder. You'll use the brute-force detection query again in the next step.

ⓧ I'd like to double check the full code

Here is the complete brute-force detection query:

// Brute Force Detection - Multiple Failed Logins from Single IP
let failedLoginThreshold = 5;
let timeWindow = 24h;
SecurityEvent
| where TimeGenerated > ago(timeWindow)
| where EventID == 4625
| summarize FailureCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by Account, IpAddress, Computer
| where FailureCount > failedLoginThreshold
| project FirstSeen, LastSeen, Account, IpAddress, Computer, FailureCount
| order by FailureCount desc

And here is the complete cross-source correlation query:

// Cross-source correlation: Identity failures followed by network scanning
let identityFailures = 
    SecurityEvent
    | where TimeGenerated > ago(7d)
    | where EventID == 4625
    | summarize FailCount = count() by IpAddress, bin(TimeGenerated, 1h)
    | where FailCount > 3;
identityFailures
| join kind=inner (
    CommonSecurityLog
    | where TimeGenerated > ago(7d)
    | where DeviceVendor == "Palo Alto Networks"
    | where Activity has "port" or Activity has "scan"
    | summarize ScanEvents = count() by SourceIP, bin(TimeGenerated, 1h)
) on $left.IpAddress == $right.SourceIP
| project TimeGenerated, IpAddress, FailCount, ScanEvents
| order by TimeGenerated desc

You now have two saved hunting queries that surface real attack signals from noisy security data. Next up, you'll turn your brute-force query into a scheduled analytics rule that automatically generates incidents whenever it detects suspicious activity.

Create a Custom Scheduled Analytics Rule

You now have hunting queries that surface suspicious activity from the Training Lab's data. The next challenge is turning those queries into automated detections that fire continuously without manual effort.

In this step, you'll take your brute-force detection query and package it as a scheduled analytics rule. This rule will run your KQL on a schedule, compare results against a threshold, and automatically generate incidents when suspicious activity is detected.

In this step, get ready to:
  • Create a scheduled analytics rule with MITRE ATT&CK mapping.
  • Configure query scheduling, alert thresholds, and entity mapping.
  • Verify that the rule generates incidents with populated entities.
Create a new scheduled query rule

A scheduled analytics rule runs your KQL query on a repeating interval and generates alerts whenever results cross a defined threshold. You'll configure general information first, including the rule's name, severity, and MITRE ATT&CK tactic mapping.

  • In the Defender portal, expand Microsoft Sentinel in the left navigation menu.
  • Expand Configuration and select Analytics.
  • Select +Create at the top of the page, then select Scheduled query rule from the dropdown.
  • In the Name field, enter Brute Force - Multiple Failed Logins from Single IP.
  • Set the Severity dropdown to Medium.
  • Under MITRE ATT&CK, select the tactic Credential Access and the technique T1110 - Brute Force.
  • Select Next: Set rule logic to proceed to the query configuration.

What is a MITRE ATT&CK mapping?

MITRE ATT&CK is a knowledge base of adversary tactics and techniques observed in real-world attacks. Mapping your detection rule to a specific technique (like T1110 for brute force) categorizes the alert in the broader attack lifecycle.

This helps SOC analysts quickly understand what stage of an attack chain the alert represents and prioritize their response accordingly.

Configure the rule logic and scheduling

The rule logic page is where you paste your detection query, set how frequently it runs, and define entity mappings that enrich the resulting incidents with clickable entity information.

  • In the Rule query window, paste your brute-force detection query:
// Brute Force Detection - Multiple Failed Logins from Single IP
let failedLoginThreshold = 5;
let timeWindow = 24h;
SecurityEvent
| where TimeGenerated > ago(timeWindow)
| where EventID == 4625
| summarize FailureCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by Account, IpAddress, Computer
| where FailureCount > failedLoginThreshold
| project FirstSeen, LastSeen, Account, IpAddress, Computer, FailureCount
| order by FailureCount desc

What does this query detect?

This query searches the SecurityEvent table for Event ID 4625 (failed logon attempts). It groups failures by account and IP address, then flags any combination that exceeds 5 failures within 24 hours.

When this rule runs on a schedule, any results above the threshold automatically generate an incident for investigation.

  • Scroll down to the Query scheduling section.
  • Set Run query every to 5 minutes.
  • Set Lookup data from the last to 1 hour.
  • In the Alert threshold section, set Generate alert when number of query results to Is greater than with the value 0.

Why a 5-minute interval with a 1-hour lookback?

The lookback period must be longer than or equal to the query interval. A 5-minute interval with a 1-hour lookback means the rule checks every 5 minutes for brute-force patterns across the last hour of data.

Setting the threshold to 0 means any result returned by the query triggers an alert. Since the query itself already filters for accounts with more than 5 failures, a threshold of 0 ensures every flagged account generates an incident.

Now configure entity mapping to connect query results with Sentinel's entity model.

  • In the Alert enhancement section, expand Entity mapping.
  • Select Add new entity.
  • In the Entity dropdown, select Account.
  • In the Identifier dropdown, select Name. In the Value dropdown, select Account.
  • Select Add new entity again.
  • In the Entity dropdown, select IP.
  • In the Identifier dropdown, select Address. In the Value dropdown, select IpAddress.
  • Select Next: Review and create to proceed to the final review.

What does entity mapping do?

Entity mapping connects fields in your query output to Sentinel's built-in entity types (accounts, IPs, hosts, URLs, etc.). When an incident is created, these entities become clickable links that let you pivot into investigation graphs, timelines, and related alerts.

Without entity mapping, your incidents would contain raw data without the enrichment needed for efficient investigation.

Enable the rule and verify incident generation

With the query, scheduling, and entity mapping configured, you can now create and enable the rule. Sentinel will immediately begin running your query on the defined schedule.

  • On the Review and create page, confirm that validation has passed.
  • Select Create to save and enable the rule.
  • Wait 5-10 minutes for the rule to execute its first run against the Training Lab data.
  • Navigate to Investigation & response in the Defender portal left navigation, then select Incidents & alerts and choose Incidents.
  • Look for a new incident with the title matching your rule name.
  • Select the incident to open its details.
  • Verify that the Entities pane shows both Account and IP entities populated from your entity mapping.

Don't see a new incident after 10 minutes?

Return to the Analytics page and confirm your rule appears in the Active rules tab with status Enabled. If the rule shows as disabled or has a validation error, select it and choose Edit to review the query for syntax errors.

Also check that the lookback period covers a time range with data in your Training Lab workspace. The pre-ingested data has specific time ranges, so a 1-hour lookback against current time may not capture the historical data. If needed, increase the lookback period to 24h temporarily to validate.

help me debug why my analytics rule isn't generating incidents

Your detection rule is now live and generating incidents automatically. Next up, you'll investigate one of the multi-stage incidents from the Training Lab to practice the full SOC investigation workflow.

Investigate a Multi-Stage Incident

Your custom analytics rule is now actively detecting brute-force activity and generating incidents. Detection is only the first half of a SOC analyst's job.

The real value of a SIEM comes when you investigate an incident and trace the full attack chain. In this step, you'll open one of the Training Lab's pre-generated multi-stage incidents and walk through the complete investigation workflow: reviewing the timeline, exploring entity relationships in the investigation graph, and documenting your findings with tasks for remediation.

In this step, get ready to:
  • Review a multi-stage incident timeline, severity, and MITRE ATT&CK tactics.
  • Use the investigation graph to trace entity relationships across the attack chain.
  • Document investigation findings and assign remediation tasks.
Open and review a multi-stage incident

The Training Lab's 22 detection rules have already correlated alerts from multiple data sources into multi-stage incidents. Each incident tells a story of an attacker moving through several phases of a compromise.

  • In the Microsoft Defender portal, expand Incidents & alerts in the left navigation.
  • Click Incidents.
  • Look for a multi-stage incident with a High severity that shows multiple alerts from different data sources.
  • Click the incident name to open its full details page.

You should see the incident details page with the incident timeline in the center, showing a chronological sequence of alerts and events.

  • Review the Incident timeline widget to understand the sequence of alerts.
  • Note the severity level and the MITRE ATT&CK tactics listed in the incident details panel on the left.
  • Check the Entities widget to see which users, IP addresses, and hosts are involved.

What is the incident timeline?

The incident timeline is a chronological diary of all alerts and bookmarks that are relevant to the investigation. It shows events in the order they occurred, helping you reconstruct the attacker's activity step by step.

Each alert in the timeline maps to a specific MITRE ATT&CK tactic (like Initial Access, Credential Access, or Lateral Movement). Together, these tactics tell you the full story of what the attacker tried to do.

Don't see any incidents?

Make sure the Training Lab deployment completed successfully (it takes about 30 minutes). Check that your Sentinel workspace is connected in the Defender portal. If the incident queue appears empty, check the time filter at the top of the page and expand it to cover the last 30 days.

help me find my Training Lab incidents in the Defender portal

Explore entity relationships using the investigation graph

The investigation graph is a visual tool that maps relationships between entities (users, IPs, hosts) and the alerts connected to them. It lets you trace how an attacker moved from one resource to another.

  • In the left-hand panel of the incident details page, click Investigate to open the investigation graph.
  • You should see a visual map of entities (represented as nodes) connected by lines showing their relationships to alerts and other entities.
  • Click on an entity node (such as a user account or IP address) to open the Entities pane and review information about that entity.
  • Hover over entities to reveal exploration queries designed by security experts for that entity type.
  • Select an exploration query (such as Related alerts) to expand the graph and see additional connected entities.
  • Use the parallel timeline at the bottom of the graph to see when events occurred relative to each other.

What does the investigation graph show?

The investigation graph displays entity relationships extracted from raw data across multiple data sources. It helps you understand the scope of a breach, identify the root cause, and trace how an attacker moved laterally through your environment.

Built-in exploration queries let you expand your investigation without writing KQL. For example, selecting Related alerts on an IP address shows you every alert that IP triggered across all connected data sources.

  • Return to the incident details page by closing the investigation graph.
  • Review the Top insights widget on the right side of the incident details page.

What are Top insights?

The Top insights widget shows machine-learning-generated findings about the entities in your incident. It compares entity behavior to historical patterns and peer activity, automatically surfacing the most important anomalies for your investigation.

  • As you trace the attack chain, note down the sequence: which tactic came first (Initial Access), what the attacker did next (Credential Access, Lateral Movement), and what their final objective was.
Document findings and assign remediation tasks

A real SOC workflow does not end with investigation. You need to document what you found, take ownership of the incident, and create a clear handoff for remediation. This is how security teams coordinate response across shifts and roles.

  • Return to the incident details page (if not already there).
  • Scroll to the comments section at the bottom of the details panel.
  • Add a comment documenting your investigation findings. For example: describe the attack chain you traced, the entities involved, and the MITRE ATT&CK tactics you identified.
  • In the Status drop-down, change the incident status from New to Active.
  • In the Owner drop-down, assign the incident to yourself.

Why change the status and assign ownership?

Setting an incident to Active signals to other analysts that someone is actively investigating it. Assigning ownership creates accountability and prevents duplicate work across a SOC team.

In a real SOC, unassigned incidents sit in the queue until someone triages them. Taking ownership is the first step in the response workflow.

  • Open the incident's full details page by clicking View full details if you are still in the summary pane.
  • Click Tasks from the top banner to open the Incident tasks panel.
  • Click + Add task.
  • Enter Block malicious IP as the task title and click Save.
  • Click + Add task again and enter Reset compromised credentials as the title. Click Save.
  • Add one more task with the title Review firewall rules and click Save.

You should now see all three tasks listed in the Incident tasks panel. Each task appears with your name under "Created by" and a colored band on the left border.

What are incident tasks?

Incident tasks are a checklist of remediation actions attached to an incident. They help SOC teams coordinate response by documenting what needs to happen next. Tasks can be created manually (as you just did) or automatically by automation rules and playbooks.

In an interview, being able to explain this triage-investigate-remediate workflow shows you understand how real security operations centers function.

Can't find the Tasks option?

Make sure you are on the full incident details page, not just the summary pane. The Tasks option appears in the top banner of the full details page. You need the Microsoft Sentinel Responder role to add and edit tasks.

help me find where to add incident tasks in Microsoft Sentinel

You have just completed a full investigation cycle: triaging an incident, tracing the attack chain through the investigation graph, documenting your findings, and assigning remediation tasks. Next up, you'll automate this response workflow so high-severity incidents trigger notifications automatically.

Automate Incident Response with a Playbook

In Step 4, you investigated a multi-stage incident manually. You triaged the alerts, traced the attack chain, and documented remediation tasks.

Manual investigation works for individual incidents, but a real SOC handles hundreds of alerts daily. Automation bridges the gap between detection and response. In this step, you'll build an automation rule that watches for high-severity incidents and triggers a Logic Apps playbook to send immediate email notification.

In this step, get ready to:
  • Create an automation rule that triggers on high-severity incidents.
  • Build a Logic Apps playbook that sends email notifications with incident details.
  • Connect the automation rule to the playbook and verify end-to-end execution.
Create a Logic Apps playbook

Before you can wire up an automation rule to run a playbook, the playbook itself needs to exist. You'll create a Logic App on the Consumption plan that listens for Microsoft Sentinel incidents and sends an email with the details.

  • Switch to the Azure portal (portal.azure.com).
  • In the search bar at the top, type Logic App and select Logic Apps from the results.
  • Click + Add.
  • Under Plan, select Consumption.
  • Select your subscription and choose rg-sentinel-training as the resource group.
  • Give your Logic App a name (for example, Sentinel-HighSev-Notification).
  • Choose a region that matches your resource group.
  • Click Review + Create, then click Create.
  • Wait for the deployment to complete, then click Go to resource.

The Logic App designer opens automatically. Now you'll configure the trigger and the email action.

  • In the Logic App designer, search for Microsoft Sentinel in the trigger search box.
  • Select the trigger called When a Microsoft Sentinel incident is created.
  • If prompted to create a connection, sign in with your Azure credentials and select your subscription and workspace.

What is this trigger?

The When a Microsoft Sentinel incident is created trigger fires whenever a new incident appears in your Sentinel workspace. It passes the full incident object (title, severity, description, entities, and alerts) into the Logic App as dynamic content you can use in subsequent actions.

  • Below the trigger, click + New step.
  • Search for Office 365 Outlook and select the Send an email (V2) action.
  • Sign in with an Office 365 account when prompted to create the connection.
  • In the To field, enter your email address.
  • In the Subject field, use the dynamic content picker to insert the incident Title and Severity fields. For example: [High] Brute Force Detected.
  • In the Body field, add the incident Description and Incident link dynamic fields so the email includes a direct link back to the incident.
  • Click Save in the top-left corner of the designer.

Why separate automation rules from playbooks?

Automation rules are the decision layer. They define when to act (trigger, conditions). Playbooks are the response mechanism. They define what to do (send email, block IP, open ticket).

This separation means you can reuse the same playbook across multiple automation rules, or swap out playbooks without rebuilding your trigger logic. In interviews, this distinction between orchestration and execution is commonly tested.

Don't see the Microsoft Sentinel trigger?

Make sure you're searching under the Shared connectors tab in the designer, not Built-in. The Microsoft Sentinel connector is a shared (Microsoft-managed) connector.

If the connector still doesn't appear, confirm your Logic App is on the Consumption plan. Standard plan workflows require manual setup and don't support Sentinel playbook templates.

Help me find the Microsoft Sentinel trigger in my Logic App designer.

Create an automation rule in Microsoft Sentinel

With the playbook ready, you'll now create an automation rule that watches for high-severity incidents and runs your Logic App whenever one appears.

  • Return to the Microsoft Defender portal (security.microsoft.com).
  • In the left navigation, expand Microsoft Sentinel, then select Configuration, then Automation.
  • Click + Create and choose Automation rule.
  • In the Automation rule name field, enter a descriptive name (for example, Notify on High Severity Incidents).
  • From the Trigger dropdown, select When incident is created.
  • Under Conditions, add a condition where Incident severity equals High.
  • Under Actions, select Run playbook from the dropdown.
  • In the second dropdown that appears, select the Logic App you just created (Sentinel-HighSev-Notification).

What if the playbook appears grayed out?

Microsoft Sentinel needs explicit permissions to run playbooks in your resource group. If the playbook appears unavailable, click the Manage playbook permissions link in the automation rule panel.

In the Manage permissions panel, check the box next to rg-sentinel-training and click Apply. This grants the Microsoft Sentinel Automation Contributor role on that resource group.

  • Leave Rule expiration set to Indefinite.
  • Click Apply to save and enable the automation rule.

Your automation rule is now active. Every time a high-severity incident is created, Sentinel will automatically run your Logic App playbook.

Automation rule won't save?

Confirm you have the Microsoft Sentinel Contributor role on your workspace. This role is required to attach playbooks to automation rules.

Also check that you selected an incident-triggered playbook. Automation rules using the incident trigger can only run playbooks that start with the incident trigger.

Help me troubleshoot why my automation rule won't save in Microsoft Sentinel.

Verify the automation rule and playbook execution

The Training Lab's 22 detection rules continuously generate incidents, including high-severity ones. You'll verify that your automation pipeline is working by checking the Logic App's run history.

  • Return to the Azure portal and navigate to your Logic App (Sentinel-HighSev-Notification).
  • In the left menu, click Overview.
  • Scroll down to the Run history section.
  • Look for a run with Status showing Succeeded. This confirms the automation rule triggered your playbook and the email was sent.
  • Click on a succeeded run to expand it and see the trigger data (incident title, severity) and the email action output.

What if no runs appear yet?

The Training Lab's detection rules fire on pre-ingested data, so high-severity incidents may already exist from the initial deployment. If your automation rule was created after those incidents fired, you may need to wait for the next scheduled rule evaluation cycle (typically 5 minutes) to generate a new incident that triggers your rule.

You can also check the Incidents page in the Defender portal to confirm high-severity incidents exist. If they do but no run appears, verify the playbook permissions are granted correctly.

  • Check your inbox for the notification email. It should contain the incident title, severity, description, and a link back to the incident in the Defender portal.

Run shows Failed status?

Click the failed run to see which step errored. Common issues include:

  • The Office 365 Outlook connection expired or needs re-authentication. Click the failed action and re-authorize.
  • The Sentinel connection lost authorization. Re-authenticate the Microsoft Sentinel connector in the designer.
  • The Logic App's managed identity lacks permissions on the Sentinel workspace. Grant the Automation Contributor role on rg-sentinel-training.

Help me debug my failed Logic App run for Microsoft Sentinel incident notification.

Secret mission

Conduct a Hypothesis-Driven Threat Hunt and Promote to Detection

Real SOC teams don't just react to alerts. They proactively hunt for threats that existing rules might miss. In this secret mission, you'll use the MITRE ATT&CK matrix to find detection gaps, write a custom hunting query to fill one, and promote your findings to a live analytics rule.

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. This project uses Azure cloud resources that are covered by the 31-day Microsoft Sentinel free trial (up to 10 GB/day of ingestion), but may incur costs after the trial ends.

Cost warning

Your Microsoft Sentinel workspace, Log Analytics workspace, and Logic App are all running in Azure. After the 31-day free trial expires, you will be charged for data ingestion and Sentinel analysis.

If you are not actively using this lab, choose Pause or Delete below to avoid unexpected charges.

Resources you used:

  • Azure Resource Group rg-sentinel-training (contains your Log Analytics workspace, Microsoft Sentinel, and Logic App).

Keep everything running

No action needed. Choose this if you are still actively building or want to continue practicing KQL queries and investigating incidents in the Training Lab.

  • Monitor your usage by navigating to Cost Management + Billing in the Azure portal.
  • Confirm your ingestion stays within the 10 GB/day free trial limit.
  • The Training Lab's pre-ingested data is static, so no new data is being actively added. Your main cost risk comes from the free trial expiring, not from data volume.

Pause - I'll come back to this later

The Training Lab's pre-ingested data is static and will not generate additional ingestion costs after the initial deployment. You cannot pause Microsoft Sentinel itself, but you can disable your analytics rules and automation rule to reduce any processing activity.

  • In the Microsoft Defender portal, navigate to Microsoft Sentinel > Analytics.
  • Select your custom analytics rules and disable them.
  • Navigate to Automation > Automation Rules and disable your automation rule.
  • Monitor your Azure billing to confirm no unexpected charges appear after the 31-day trial period.

Delete - I don't want to use this again

Remove all project resources and stop all charges by deleting the entire resource group. This is permanent and cannot be undone.

  • In the Azure portal, search for Resource groups in the top search bar.
  • Select rg-sentinel-training from the list.
  • Click Delete resource group at the top of the page.
  • Type the resource group name rg-sentinel-training to confirm deletion, then click Delete.
  • Wait for the deletion to complete. This removes your Log Analytics workspace, Microsoft Sentinel instance, Logic App, and all associated data.

Nice Work!

Nice Work!

You've just completed a full SOC analyst workflow in Microsoft Sentinel.

From threat hunting with KQL to automated incident response with Logic Apps, you now have concrete, hands-on experience to discuss in interviews about security operations.

You've learned how to:

  • Write KQL hunting queries that detect brute-force attacks and correlate events across multiple data sources like identity logs and firewall events.
  • Create a custom scheduled analytics rule with MITRE ATT&CK mapping and entity mapping that automatically generates enriched security incidents.
  • Build automated incident response using automation rules paired with a Logic Apps playbook that triggers notifications for high-severity incidents.
  • Conduct a hypothesis-driven threat hunt using the MITRE ATT&CK matrix to identify coverage gaps and promote findings to a new detection rule.

You can now speak to the end-to-end detection lifecycle, from hunting through automation, and reference specific KQL patterns, MITRE techniques, and Sentinel capabilities.

Ready to quiz yourself?