Sentinel Automation Part 1: Enriching Sentinel Incidents with KQL Results

Automating incident response queries is one of the quick wins you can implement in Microsoft Sentinel. This allows you to automate incident enrichment and further investigations. The first blog of the Sentinel Automation Series will explain how you can quickly implement this in your environment. This is done based on automation rules and Playbooks (Logic Apps).



To show the value of automatically enriching incidents two examples are discussed in this section; Device Enrichment and the listing of inbound connections. These enrichment flows can provide analysts with additional details and context about the incident, without the need to go to another portal/tool/tab to find the results.

Both Playbooks mentioned in this section are available on GitHub and can be deployed to your tenant! Link: Sentinel Automation GitHub

The term Playbook and Logic App refer both to the usage of a Logic App. Microsoft likes to name it Playbooks in the Sentinel documentation, for this blog the naming convention will also be applicable (until the name is changed, which never happens with Microsoft products right?).

Device Information

This Playbook collects the DeviceName, OSPlatform, OSVersionInfo, PublicIP, DeviceType, JoinType and ExposureLevel for each device mentioned in the incident entities. This is done based on the data available in the DeviceInfo table. This helps analysts to get efficient insight into the device they are investigating.

Device Information Enrichment

KQL Query:

let HostName= "HostNameVariable";
| where DeviceName startswith HostName
| summarize arg_max(TimeGenerated, *) by DeviceId
| project DeviceName, OSPlatform, OSVersionInfo, PublicIP, DeviceType, JoinType, ExposureLevel

Inbound Connections

This automation flow collects the last 10 inbound connections to a device that is mentioned in the incident entities. These results are added as comments in the Sentinel incident. In this case, a strange pattern can be identified, since there are multiple inbound RDP connections within a short timeframe from different locations.

Inbound Connections Enrichment

KQL Query:

// Add the device you are investigating in the CompromisedDevice variable
let HostName= "HostNameVariable";
let SearchWindow = 10d; //Customizable h = hours, d = days
| where TimeGenerated > ago(SearchWindow)
| where DeviceName startswith HostName
// Only list accepted inbound connections
| where ActionType == "InboundConnectionAccepted"
| where RemoteIPType == "Public"
| extend GeoIPInfo = geo_info_from_ip_address(RemoteIP)
| extend country = tostring(parse_json(GeoIPInfo).country), state = tostring(parse_json(GeoIPInfo).state), city = tostring(parse_json(GeoIPInfo).city), latitude = tostring(parse_json(GeoIPInfo).latitude), longitude = tostring(parse_json(GeoIPInfo).longitude)
| project TimeGenerated, DeviceName, RemoteIP, LocalIP, LocalPort, country, state
| top 10 by TimeGenerated
Community Playbooks

There are multiple sources availabe where you can download Sentinel Playbooks:


There are two triggers to enrich Sentinel incidents; manual and automatic. If a Playbook is executed manually, the analyst investigates the incident and determines that more context/information is needed. This information can now be collected by clicking a button, whereas previously the analyst had to build (or copy) and run the query each time more information was needed.

This process can be further automated with automation rules, these are centrally managed automation flows in Sentinel. One of the actions automation rules can do is to execute a Playbook, this can be the same Playbook as mentioned in the manual steps. With this automatic trigger, the analysts are served with all the information when they open the Sentinel incident.

Automation Process


When enriching incidents with KQL queries the Playbook will look similar to the one seen below.

Automation Process

This flow consists of four steps:

  1. A Playbook Trigger which starts the Playbook Flow. This can be a Sentinel Incident, Entity or Alert (DOCS).
  2. Extracting the Entities, these are needed in the KQL query to filter on the devices, users, files, etc. that are mentioned in the trigger.
  3. For each entity run a KQL query, this is done using the Azure Monitor API. You can achieve the same results with the Microsoft Defender API, this allows you to query the data directly from Advanced Hunting.
  4. Add the query results as a comment to the Sentinel incident.

For more automation ideas have a look at my presentation slides from the Dutch Security Meetup.

Trigger Playbook

As already briefly discussed in the previous part there are different options to trigger the Playbook execution. For automation, you have one option, to use the Automation Rule as a trigger. The manual locations are shared below. While it makes sense, it is good to mention that you cannot execute a Playbook that has an alert trigger via the manual incident trigger option, only the manual alert trigger option can execute this playbook.

Entities The effectiveness of the Logic App relies on the Entities that are set when configuring Analytics/Custom Detection Rules. The more entities you configure, the more effective automation will be!

Manual Incident Trigger

Playbook Manual Incident Trigger

Manual Alert Trigger

Playbook Manual Alert Trigger

Manual Entity Trigger

Playbook Manual Entity Trigger

Create Automation Rule

Creating an automation rule in Sentinel is very easy.

  1. Navigate to the Automation section in the Sentinel menu.
  2. Create an Automation Rule. This includes defining which incidents the automation rule should trigger.
  3. Select the Playbook you want the automation rule to execute.

Automation Rule Creation

Next Blogs

This blog has introduced the Sentinel Automation topic. The next parts of this series will provide more information, examples and templates to further optimize your Sentinel experience.

Questions? Feel free to reach out to me on any of my socials.