Hunting Service Principal with Microsoft Sentinel

What’s going on inside the box? Is Service principal monitoring essential? If we rely on the SolarWinds event, this is necessary monitoring. The 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. Registering your application with Azure AD creates an identity configuration to integrate with Azure AD.

Application registration is the process of creating a representation of your application in Azure Active Directory (Azure AD). This allows your application to authenticate and access Azure resources on behalf of users or other applications.

When you register your application in Azure AD, you get an Application ID, also known as a Client ID, which is a unique identifier for your application. You can also configure other settings for your application, such as the redirect URI, permissions, and authentication options.

The application was registered – 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 lists and manage your home tenant’s application objects.

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.

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 can access resources in a tenant, a principal service object is created. A service principal is created automatically when you register an application 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.

a Service Principal is an identity used for authentication and authorization purposes by applications and services. It’s a security principle representing non-human entities such as an application, service, or automation tool in Azure Active Directory (Azure AD).

When you create a Service Principal, it’s assigned a unique identifier (application ID) and a secret (client secret or certificate) that it can use to authenticate with Azure AD and access Azure resources. The Service Principal also has a set of permissions (roles) assigned to it, determining what actions it can perform on Azure resources.

You can use Service Principals to authenticate and authorize applications and services to access Azure resources such as virtual machines, storage accounts, and databases. This allows you to control access to resources and enforce security policies.

The portal’s Enterprise applications blade is used to list and manage the service principles in a tenant.

Below is a main comparison between Service Principal and Application Registration.

The Real World

In the real world, Service Principal and Application Registration are commonly used in different scenarios to authenticate and authorize Azure applications. Here are some examples:

Service Principal:

• A developer can create a Service Principal for a custom application to access an Azure resource such as a storage account or database. The Service Principal can be assigned a specific role with the required permissions to access the resource.
• A DevOps engineer can use a Service Principal to authenticate with Azure and perform operations such as creating or updating Azure resources, deploying applications, or running automation scripts.
• An Azure Function can use a Service Principal to authenticate with Azure AD and access Azure resources such as storage or databases.
• An external monitoring tool can use a Service Principal to authenticate and retrieve metrics and logs from Azure resources.

Application Registration:

• A web application can use an Application Registration to authenticate users with Azure AD and access Azure resources on their behalf. The application can use OAuth 2.0 or OpenID Connect to authenticate the user and acquire an access token to access the Azure resources.
• A mobile application can use an Application Registration to authenticate users with Azure AD and access Azure resources such as APIs or storage.
• A custom API can use an Application Registration to authenticate callers with Azure AD and enforce authorization policies based on the caller’s identity and permissions.
• A single-page application can use an Application Registration to authenticate users with Azure AD and access Azure resources such as APIs or storage.

In summary, Service Principal and Application Registration are widely used in different scenarios in Azure for authentication and authorization. Service Principal is more suitable for service-to-service authentication and automation scenarios. At the same time, Application Registration is more suitable for user-facing applications that must authenticate and access Azure resources on behalf of users.

Hunting

Now. Go to your Azure AD 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 for 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 Side

Now that we know we’ve all the capabilities for service principals logs, we can monitor, track and detect suspicious activities and many other Microsoft Sentinel 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 must 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