Lukas Beran
Lukas Beran

Welcome to my blog! If you're looking for tutorials, hints or tips for IT, you're right here. You will find mostly articles on Microsoft products and technologies - operating systems, servers, virtualization, networks, management, but also the cloud. Sometimes I add some other interesting things.

March 2021
MTWTFSS
1234567
891011121314
15161718192021
22232425262728
293031 

Categories


Monitoring of sensitive Azure AD accounts with Azure Sentinel

Lukas BeranLukas Beran

Azure Sentinel is a cloud SIEM and SOAR. It is therefore used for the supervision of a customer environment, from which it collects logs, which it then evaluates.

Different types of identities generally have different sensitivities in relation to the risk of abuse. The most sensitive identities, such as admin accounts or emergency (break-glass) accounts, should have extra security and monitoring. In this case, monitoring would serve to inform the security team in the organization of suspicious activities on these highly sensitive accounts.

In this article, we’ll look at how to monitor user accounts and service principals in Azure AD using Azure Sentinel. For monitoring to work, you need to have Azure Sentinel deployed and an active data connector for Azure AD. For monitoring, we will use account pairing specifically for a public IP address that will be enabled to use that account. And if access to the account is detected from another IP address, then Sentinel will automatically create an incident.

Monitor user accounts with Azure Sentinel

Monitoring of user accounts in Azure AD using Sentinel consists of two parts. The first part is to define which accounts are sensitive and what public IP addresses are allowed for those accounts. The second part is the creation of the analytics rule itself, which will take care of detection and reporting.

Of course, we could do the definition of sensitive accounts directly in the analytics rule, but this is not optimal, because if we edit the accounts or IP addresses, we would have to edit the entire analytics rule. Therefore, it is better to use some “external database”, in this case Watchlist.

Watchlist is a list that is used for exactly that purpose because it contains name-value records. In addition, it is an external list maintained directly in Sentinel workspace and cached for optimal speed.

Create a watchlist with user definition and IP addresses

Watchlist is defined using a csv file. So we will create a csv file that will contain two columns – User and IPAddress. The User column will then contain records of each sensitive account defined as Object ID in Azure AD (UserId). Each user record will have an IP address or address range enabled (in CIDR format) in the IPAddress column. For example, the file will look like this

We upload this file to Watchlists in Azure Sentinel and set it up as SensitiveUsersIPs. Using this alias, we will then refer to the watchlist in the analytics rule.

Creation of a detection analytics rule

The analytics rule will take care of the detection itself. Therefore, it will run a KQL query that will crawl records from the Azure AD logs to see if any of the sensitive users are using an IP address other than that defined in the watchlist.

The KQL query will look like this

Now we can create the analytics rule. Be sure to create entity mapping so that UserId maps correctly to the user and IP address correctly to the IP address for further analysis and entity enrichment.

The entire analytics rule will then have this specification in YAML format.

You can also find the analytics rule in YAML format on my GitHub.

Monitor service principals with Azure Sentinel

Monitoring service principals is in principle exactly the same as monitoring user accounts and consists again of two parts. The first part is the definition of which service principals are sensitive and what public IP addresses are allowed. The second part is the creation of the analytics rule, which will take care of detection and reporting.

Create a watchlist with a definition of service principals and IP addresses

Watchlist is defined using a csv file. So we will create a csv file that will contain two columns – ServicePrincipalId and IPAddress. The ServicePrincipalId column will then contain records of each service principals defined as Object ID in Azure AD (ServicePrincipalId). Each record will be assigned an IP address or address range (in CIDR format) in the IPAddress column. For example

We upload this file to Watchlists in Azure Sentinel and set it up as SensitiveServicePrincipalsIPs.

Creation of a detection analytical rule

The analytics rule will take care of the detection. Therefore, it will run a KQL query that will crawl Azure AD log records to see if any of the service principals are using an IP address other than that defined in the watchlist.

The KQL query itself will look like this

Now we can create the analytics rule. Be sure to create entity mapping so that the IP address is correctly assigned to the IP address for further analysis and entity enrichment.

The entire analytics rule will then have this specification in YAML format.

You can also find this analytics rule in YAML format on my GitHub.

My primary focus is the security of identities, devices and data in the cloud using Microsoft services, technologies and tools.

Comments 0
There are currently no comments.