Building Automation Rules with your Sentinel Instance in PowerShell

Today, we explore creating custom Automation Rules in Microsoft Sentinel to help us auto-close low value incidents. This is a temporary measure, as the best way to quiet these types of Sentinel Incidents is to remove the alert from being generated at source.

As an organization, you might have implemented Microsoft Defender for Office 365 to protect your email environment. Defender for Office 365 helps protect your organization from advanced threats by scanning email messages for spam, phishing, malware, and other malicious content. If you haven’t looked at this option in the last year, I would encourage you to try a POC with some trial licenses and check out how great it performs! …back to our original purpose here…

In some cases, you might want to block email messages from specific domains to prevent spam or phishing attacks. However, even with such measures in place, there could still be some email messages that make it through to your environment. To address this, you can use Microsoft Sentinel to monitor your Defender for Office 365 alerts and create automation rules to take action when specific conditions are met.

In this article, I will explain how to use PowerShell to write a Sentinel automation rule that closes incidents from Defender for Office 365 when the alert is for email from a blocked domain. The use case being that our SOC team does not need to know about this and it can be handled by the Email Security team; spoofing is an evolving challenge, so we will “auto-close” our incident. Again, ideally we would not receive this alert, but there are times that we need the alert generated for other teams and we are caught in the crossfire of alerting at the SOC.

Prerequisites

• A Microsoft Sentinel account.
• Defender for Office 365 alerts configured in Sentinel.
• The Az.SecurityInsights PowerShell module installed on your computer.
• Azure Active Directory (AD) authentication credentials for your Sentinel account.

Step 1:
Connect to Sentinel using PowerShell Before you can create an automation rule in Sentinel, you need to connect to your Sentinel account using PowerShell. To do this, run the following command in PowerShell:

Connect-AzAccount

You will be prompted to enter your Azure AD credentials to authenticate. Fully MFA compliant for anyone wondering!

Step 2:
Retrieve the alert from Defender for Office 365 Next, you need to retrieve the alert from Defender for Office 365 that triggered the incident. To do this, use the Get-AzSecurityAlert cmdlet. In this case, we want to retrieve the alert for email from a blocked domain. You can use the following KQL query:

let BlockedDomains = dynamic(["blockeddomain1.com", "blockeddomain2.com"]);
SecurityAlert
| where ProviderName == "Office365"
| where AlertName == "SuspiciousInboundBlockedSenderDomain"
| where AlertType == "SecurityIncident"
| where ExtendedProperties contains "BlockedSenderDomain" and (BlockedDomains contains tolower(ExtendedProperties["BlockedSenderDomain"]) or BlockedDomains contains toupper(ExtendedProperties["BlockedSenderDomain"]))

This query retrieves the security alert for email from a blocked domain and filters out the alerts that are not security incidents. The BlockedDomains variable is an array that contains the list of blocked domains that you want to monitor.

To retrieve the alert, use the following PowerShell command:

$alert = Get-AzSecurityAlert -WorkspaceName "" -ResourceGroupName "" -Query ""

Above, replace <WorkspaceName> and <ResourceGroupName> with the appropriate values for your environment, and <Query> with the KQL query that you created earlier.

Step 3:
Close the incident Once you have retrieved the alert, you can use the Set-AzSecurityIncident cmdlet to close the incident associated with the alert. Use the following PowerShell command:

Set-AzSecurityIncident -WorkspaceName "" -ResourceGroupName "" -Id $alert.incidentId -Status "Closed" -CloseReason "Alert for email from blocked domain"

In the command above, replace <WorkspaceName> and <ResourceGroupName> with the appropriate values for your environment. The -Id parameter specifies the incident ID associated with the alert, which is stored in the $alert variable. The -Status parameter sets the incident status to “Closed”, and the -CloseReason parameter specifies the reason for closing the incident.

Step 4:
Schedule the automation rule Finally, you can schedule the automation rule to run periodically using the New-AzSentinelScheduledAlertRule cmdlet. Use the following PowerShell command:

New-AzSentinelScheduledAlertRule -Name "CloseIncidentForBlockedDomain" -Description "Close the incident for email from a blocked domain" -Query "<KQLQuery>" -Severity "Informational" -Interval "PT5M" -Enabled $true

Here, replace <KQLQuery> with the KQL query that you created earlier. The -Interval parameter specifies the interval at which the rule should run, which is set to 5 minutes in this example.

Conclusion

By using PowerShell to write a Microsoft Sentinel automation rule, you can automatically close incidents from Defender for Office 365 when the alert is for email from a blocked domain. This helps you quickly respond to potential security threats and protect your organization from malicious content without getting bogged down with informational incidents.