Azure Sentinel: automating your Use Cases with PowerShell and the #AzSentinel module
Over the past few weeks we’ve seen immense interest in Azure Sentinel. Companies, big and small, are looking at Azure Sentinel for multiple reasons, for instance: burned out for running their own complex SIEM infrastructures, the easy integration with Azure and Office 365 data that Sentinel provides, etc.
We’ve been fortunate to assist these customers with proof of concepts, pilots, trials or even the first pre-production environments. Based on this work we’ve built up quite a bit of field experience and it’s time we start contributing back :-)
Say hello to our open-source PowerShell module called AzSentinel.
AzSentinel module
In the past days our team at Wortell Enterprise Security has created a PowerShell module called AzSentinel. The goal is to provide programmatic access to Azure Sentinel. One of the first things we wanted to get done is to work with Azure Sentinel ‘rules’.
Rules in Azure Sentinel created the basic logic on which Incidents get created. Currently the only way to add, change or delete rules is through the Azure portal. As we’re running a cloud Security Operations Center at Wortell with many customers connected, doing this manually is no option for us.
Use Cases
The other benefit of having automation is that we can keep the Azure Sentinel instances of our SOC customers synced to our ‘golden repo’. We’ve defined Use Cases for various situations and are pushing them almost real-time to our customers so that their coverage increases when we find new attack vectors.
This is also why we built support for defining the alert rules in YAML. You can add multiple rule definitions in one configuration file as part of your use case. Here’s an example:
PRO TIP: Are you looking for sample KQL queries to use in your rules and use cases? We’ve converted a couple of popular Sigma rules and published some of our own KQL queries in this repo: https://github.com/wortell/KQL
Working with the module
The module itself requires PowerShell Core 6 or above, the Az module to be installed, and the powershell-yaml module because we’ll be working with YAML files as input. Other than that you just need an Azure Sentinel instance ;-)
In this example we’ll be adding two rules to Azure Sentinel on detecting BlueKeep, the RDP vulnerability I wrote about in an earlier blog.
· Blog: https://security.wortell.nl/timeline/protect-yourself-against-bluekeep-using-azure-sentinel-and-microsoft-defender-atp/tech· KQL query: https://github.com/wortell/KQL/blob/master/KQL_win_rdp_bluekeep_poc_scanner.txt
Here’s the end result:
Open Source
Last but not least, we’re providing the module under the MIT license. This basically means you can use it for whatever you like as long as you mention us and keep providing the work under MIT as well. And ofcourse: if you work with Azure Sentinel as well, you’re invited to help with the project.
Here’s the link to the GitHub repo: https://github.com/wortell/AZSentinel
Happy hunting!
— Maarten Goet, MVP & RD
