Last reviewed:
How SOC teams can detect Azure privilege escalation across Microsoft Entra ID and Azure Resource Manager without turning every administrator action into a high-severity alert.
Azure privilege escalation detection is not one rule. It is a set of reviewable paths where an identity gains more reach than it had before. The path may start in Microsoft Entra ID, move through Privileged Identity Management, then land in Azure Resource Manager as a subscription-scope role assignment. A useful guide for analysts keeps those stages separate so each alert can name the source that proved it.
Start with four paths. First, a user, group, service principal or managed identity receives a broad Azure RBAC role. Second, an identity changes the membership or eligibility of a privileged group. Third, an application or service principal gains credentials, consent or ownership that lets it act with higher privilege. Fourth, a privileged identity performs a control-plane change shortly after an unusual sign-in or risk event.
Do not make the detection plan depend on job titles such as administrator. Azure privilege is scope-specific. Owner on a production subscription is different from Reader on a test resource group. Global Administrator in Entra ID is different from a custom Azure role that can write role assignments. The rule note should name the scope, the role operation and the identity type under review.
Microsoft Entra audit logs record directory changes: group membership, application consent, service-principal update, authentication-method change and Privileged Identity Management activity. Azure Activity Log records Azure Resource Manager operations such as Microsoft.Authorization/roleAssignments/write and Microsoft.Authorization/roleDefinitions/write. A privilege escalation case often needs both. The coverage entry should still say which field came from which source.
For Azure Activity Log review, preserve OperationNameValue, ActivityStatusValue, Caller, Claims_d, Authorization_d, ResourceId, SubscriptionId, CorrelationId and TimeGenerated. For Entra audit review, preserve activityDateTime, activityDisplayName, initiatedBy, targetResources, modifiedProperties, result, resultReason and correlationId where available. Those fields make the difference between a useful alert and a vague privilege-change notification.
Privileged Identity Management adds another lane. Eligible activation, permanent assignment, approval change and role setting changes should be visible to the SOC if the organisation relies on PIM as a control. The useful detection is rarely 'PIM event happened'. It is a PIM event outside the expected path, such as permanent assignment for a production subscription, activation without ticket context or approval policy change before a sensitive role assignment.
A defendable Azure privilege escalation programme starts with families of behaviour, not with every possible operation name. Broad-scope role assignment is one family. Custom role definition with Microsoft.Authorization permissions is another. Privileged group membership change is another. Service-principal credential or owner change belongs in the same review queue when that app has privileged Azure access.
Each family needs an allowlist before it goes live. Record the deployment pipeline that creates expected assignments, the named break-glass process, the identity governance workflow and the subscriptions where temporary assignments are normal. Without that context the SOC will either drown in normal administration or suppress the rule so heavily that it misses real escalation.
Treat failed attempts as correlation evidence, not as proof of escalation. Repeated denied role-assignment attempts by a newly created service principal are worth review, especially after a risky sign-in or consent grant. A single failed management operation during a legitimate deployment is not the same finding. The coverage label should reflect that difference.
Azure privilege escalation usually maps to T1098 Account Manipulation and T1098.003 Additional Cloud Roles when the evidence shows role or access expansion. It may also support T1078.004 Valid Accounts: Cloud Accounts when a valid identity performs the escalation path. The mapping is strongest when the alert includes the identity, the prior privilege, the new privilege and the Azure or Entra source that proves the change.
Do not mark a technique as covered because an operation name appears in a query. A roleAssignments/write event is direct detection evidence only when the rule can decide why the assignment is suspicious. A broad assignment to a new service principal, outside the deployment pipeline, is much stronger than a routine managed identity assignment created by infrastructure code.
Use evidence labels. Direct detection evidence means the rule can alert on the privilege change with tenant context. Correlation context means the event needs another signal, such as risky sign-in, new credential or suspicious consent. Posture context means the finding exposes a weak control, such as no PIM requirement for Owner, rather than detecting active escalation.
def azure_privilege_evidence_kind(event):
if event.operation == 'Microsoft.Authorization/roleAssignments/write' and event.scope_is_broad:
if event.assignee_is_new or event.role_allows_role_assignment:
return 'direct-detection:T1098.003'
if event.entra_activity in {'Add member to role', 'Add eligible member to role'}:
if event.target_role_is_privileged and not event.has_change_ticket:
return 'direct-detection:T1098'
if event.service_principal_credential_added and event.app_has_privileged_scope:
return 'correlation-context:application-escalation'
if event.pim_setting_weakened:
return 'posture-context:pim-control-gap'
return 'needs-review'
Privilege alerts often fail during review because the SIEM result hides the field that matters. Keep the original role id, display name, assignee id, assignee type, target scope, caller, source IP where available and correlation id in the analyst view. For Entra audit events, keep modifiedProperties rather than flattening the change into a generic before-and-after string with no source field names.
Microsoft Sentinel, Splunk, Elastic, OpenSearch and Google SecOps can all represent the same Azure event differently. The guide should not pretend that one query proves coverage everywhere. For each SIEM, record the source connector, table or index, parser version, required fields, retention period and tenant or subscription coverage. If a field is optional or nested, write that into the test case.
CloudSigma belongs in the CVE and advisory-to-Sigma lane. This guide is about Azure behaviour coverage, so the public copy should point teams towards their own Azure Activity, Entra audit, Entra sign-in and PIM evidence. A detection is production-ready when the SOC can replay a known benign change, a test escalation and a blocked attempt, then explain why each result landed in a different queue.
Review these detections after every identity governance change, new landing-zone rollout, management-group redesign, PIM policy change or incident involving Azure credentials. Privilege coverage goes stale when the tenant adds new automation identities, changes deployment tooling or grants administrators temporary routes that never reach the SOC backlog.
A quarterly review should ask which privileged roles can be assigned without alerting, which privileged groups are missing audit coverage, which service principals can add credentials without owner review and which high-severity alerts still depend on posture evidence only. Those questions turn the guide into a backlog rather than a static list of KQL snippets.
DCV records the technique mapping and evidence class beside each Azure source so reviewers can see whether coverage is direct detection, correlation context or posture context. That distinction matters. It lets a SOC improve a real gap without overstating what the current telemetry proves.