Monitor Service Principal with Microsoft Sentinel
What’s going on inside the box? Is the Service Principal monitoring is part of your security monitoring? If we rely on many security incidents, the Service Principle must be monitored. The following post will guide how to Monitor Service Principal with Microsoft Sentinel.
There are a few ways to monitor Service Principal access and changes. This post will provide helpful information about the service principal and how to monitor with Microsoft Sentinel.
In general, we can distinguish between three types of AAD-integrated applications:
- Authored by Microsoft
- Authored by 3rd parties
- Written by users in our organization
Application registration is an application that must be registered with an Azure AD tenant. When you register your application with Azure AD, you create an identity configuration to integrate with Azure AD.
The application was registered as an Azure AD application is defined by its only application object, which resides in the Azure AD tenant. An application object is used as a template or blueprint to create one or more service principal objects.
A service principal is created in every tenant where the application is used. Like a class in object-oriented programming, the application object has static properties applied to all the developed service principles.
The application object describes three aspects of an application: how the Service can issue tokens to access the application, resources that the application might need to access, and the application’s actions.
The App registrations blade in the Azure portal is used to list and manage the application objects in your home tenant.
A service principal is a local representation, or application instance, of a global application object in a single tenant or directory. A service principal is a concrete instance created from the application object and inherits specific properties from that object.
A service principal is created in each tenant where the application is used and references the globally unique app object. The principal service object defines what the app can do in the specific tenant, access the app, and resources.
When an application is permitted to access resources in a tenant, a principal service object is created. A service principal is created automatically when you register an application when using the portal. You can also create principal service objects in a tenant using Azure PowerShell, Azure CLI, Microsoft Graph, the Azure portal, and other tools.
The portal’s Enterprise applications blade is used to list and manage the service principles in a tenant.
The Real World
Now. Go to your #AzureAD portal and take a look at your applications. How many applications do you have there? In a utopian world, you maintain an inventory of all these applications with an asset management database to know who the application is, what it is used for, and what API permissions are granted.
If you look at the Azure AD Sign-ins logs, you should view a report with Service principal sign-ins with all access and information such as time, status, IP address, etc.
The Enterprise applications blade is used to list and manage the service principles in a tenant. You can see the service principal’s permissions, user consented permissions, which users have done that consent, sign-in information, etc.
Most organizations are using non-interactive sign-ins, and there are some missing security controls for managed identities or service principles compared to user accounts because:
- No restriction of access by conditions
- Limited options of alternate authentication methods
- Every Service or scenario doesn’t support managed Identities in Azure.
- No sign-in log events to audit the authentication requests.
What changes? Recently Microsoft has allowed you to work with the AADServicePrincipalSignInLogs. You can enable and configure Azure Active Directory Logs for a service principal and work with log management.
Microsoft Sentinel
Now that we know we’ve all the capabilities for service principals logs, we can monitor, track and detect suspicious activities and many other #MicrosoftSentinel actions.
Configure Azure AD
On Azure AD diagnostic settings, we need to enable and configure the collection of the following data:
- NonInteractiveUserSignInLogs
- ServicePrincipalSignInLogs
- ManagedIdentitySignInLogs
Once the diagnostic logs are configured, we can check how it looks on the Microsoft Sentinel data schema. The new Data schema of the new sign-in logs
Even if there is no further documentation, the new sign-in logs’ data schema has already been documented in the Azure Monitor Logs reference.
- NonInteracticeUserSignInLogs > AADNonInteractiveUserSignInLogs
- ServicePrincipalSignInLogs > AADServicePrincipalSignInLogs
- ManagedIdentitySignInLogs > AADManagedIdentitySignInLogs
TIP: The name of the collection in the diagnostic settings and the table’s name are not equal.
Then we can run a quick and simple query to know what we’ve inside the AADManagedIdentitySignInLogs. From Microsoft Sentinel, run the following query.
AADManagedIdentitySignInLogs| where ServicePrincipalName == “CL2” //VM or App| project TimeGenerated, Category, ResultType, CorrelationId, ServicePrincipalId, ResourceDisplayName, IPAddress, LocationDetails
Besides, I can run the query to find all Azure Activity logs related to a specific service principal with the following query:
AzureActivity | where Caller == “ae5673a4-8a82-XXXX-9b80-XXXXX” //Put your service principal here
| project TimeGenerated, Type, CorrelationId, OperationNameValue, ActivityStatusValue, Caller, CallerIpAddress, ResourceProviderValue
TIP: All Service Principal sign-ins are located in the “AADManagedIdentitySignInLogs” table.
We need to identify if someone access or touches a specific app with a particular ServicePrincipalName. The following query will return all the service principal sign-in information that does not originate from a known IP address.
AADServicePrincipalSignInLogs| where ServicePrincipalName == “YourApp”| extend countryOrRegion_ = tostring(parse_json(LocationDetails).countryOrRegion)| extend state_ = tostring(parse_json(LocationDetails).state)| extend city_ = tostring(parse_json(LocationDetails).city)| project TimeGenerated, ServicePrincipalName, countryOrRegion_, state_, city_, IPAddress| extend AccountCustomEntity = ServicePrincipalName| extend IPCustomEntity = IPAddress
