Cloud Security Wire
AWS Azure GCP RSS
Azure Misconfiguration high

Azure PIM Abuse: How Attackers Exploit Privileged Identity Management JIT Access in Entra ID

Azure Privileged Identity Management is designed to enforce just-in-time access for high-privilege roles. Misconfigured PIM policies create attack paths that allow persistent privilege escalation — often without triggering alerts.

By Cloud Security Wire · ·
#Azure#Entra ID#PIM#just-in-time access#privilege escalation#IAM#Azure AD#JIT access
High Severity

This issue has been assessed as high severity. Review affected configurations immediately.

What Is Azure PIM?

Azure Privileged Identity Management (PIM) is an Entra ID service that enforces just-in-time access to privileged roles. Rather than permanently assigning Global Administrator or Privileged Role Administrator rights, PIM allows users to hold eligible assignments — they must explicitly activate the role for a defined period (default 1 hour), optionally requiring MFA, a justification, and approval from a designated reviewer.

When correctly configured, PIM significantly reduces the window of exposure for high-value Azure roles. When misconfigured, it creates a false sense of security while leaving exploitable paths open.

Attack Paths Against PIM

1. Eligible Role Assignment Without Activation Requirements

The most common misconfiguration: an account is given an eligible assignment for Global Administrator (or similar) with no MFA requirement and no approval workflow at activation time.

An attacker who compromises such an account can activate the role themselves in seconds using the Azure Portal, the Az CLI, or the Graph API:

# Activate a PIM eligible role via Azure CLI
az rest --method POST \
  --url "https://management.azure.com/providers/Microsoft.Authorization/roleAssignmentScheduleRequests/<request-id>?api-version=2022-04-01" \
  --body '{
    "properties": {
      "principalId": "<compromised-user-object-id>",
      "roleDefinitionId": "/subscriptions/<sub-id>/providers/Microsoft.Authorization/roleDefinitions/<role-id>",
      "requestType": "SelfActivate",
      "justification": "Routine admin task"
    }
  }'

If the role activates without MFA or approval, the attacker has full tenant admin for the configured maximum duration — typically 8 hours by default.

2. Approval Bypass via Approver Account Compromise

PIM approval workflows are only as secure as the approver accounts. If an attacker compromises an approver’s credentials (via phishing, password spray, or credential stuffing), they can approve their own role activation from a second session:

  1. Compromise user A (eligible for Global Admin)
  2. Compromise user B (designated approver for Global Admin activations)
  3. From user A’s session: request role activation
  4. From user B’s session: approve the request
  5. User A now has Global Admin — no additional controls triggered

This requires two account compromises but is viable given how many organisations use small approval pools for privileged roles.

3. Permanent Active Assignment Discovery

Not all privileged assignments go through PIM. Active (permanent) assignments bypass the JIT workflow entirely. Attackers who perform thorough enumeration often find forgotten permanent assignments — service accounts, break-glass accounts, or legacy admin accounts that predate PIM adoption:

# List all active (permanent) privileged role assignments
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?\$expand=principal,roleDefinition" \
  | jq '.value[] | select(.directoryScopeId == "/") | {principal: .principal.displayName, role: .roleDefinition.displayName}'

Finding a permanent assignment for a service account with weak credentials gives direct privileged access outside PIM’s control.

4. PIM Role Setting Manipulation

Accounts with Privileged Role Administrator or Global Administrator rights can modify PIM role settings for other roles — reducing or removing approval requirements, extending maximum activation durations, or removing MFA requirements. An attacker with these rights can lower the security bar for all subsequent PIM activations in the tenant.

# Check current PIM policy for a role (e.g., Application Administrator)
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/policies/roleManagementPolicies?filter=scopeId eq '/' and scopeType eq 'DirectoryRole'"

5. Group-Based PIM Bypasses

Entra ID supports assigning PIM-controlled roles to security groups, with group membership itself being PIM-eligible. This creates a secondary path: an attacker doesn’t need to directly activate a privileged role if they can activate group membership that carries the same effective permissions.

Detection Queries

Sentinel KQL — PIM Role Activation Without MFA

AuditLogs
| where OperationName == "Add member to role completed (PIM activation)"
| extend 
    ActorUPN = tostring(InitiatedBy.user.userPrincipalName),
    TargetRole = tostring(TargetResources[0].displayName),
    AuthMethods = tostring(AdditionalDetails)
| where AuthMethods !has "mfa"
| project TimeGenerated, ActorUPN, TargetRole, Result, AdditionalDetails
| order by TimeGenerated desc

Sentinel KQL — High-Value Role Activations

AuditLogs
| where OperationName == "Add member to role completed (PIM activation)"
| extend
    ActorUPN = tostring(InitiatedBy.user.userPrincipalName),
    TargetRole = tostring(TargetResources[0].displayName)
| where TargetRole in (
    "Global Administrator",
    "Privileged Role Administrator",
    "Security Administrator",
    "Exchange Administrator",
    "SharePoint Administrator"
)
| project TimeGenerated, ActorUPN, TargetRole, Result, CorrelationId

Sentinel KQL — PIM Policy Modification

AuditLogs
| where OperationName in (
    "Update role setting in PIM",
    "Update policy in PIM"
)
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, Actor, OperationName, TargetResources, Result

Hardening PIM Configuration

Run this checklist against every high-value role in your tenant:

1. Require MFA on activation (all privileged roles)

Azure Portal → Entra ID → Privileged Identity Management → 
Azure AD Roles → [Role] → Settings → Require MFA on activation: ON

2. Require approval for tier-0 roles Enable approval workflows for: Global Administrator, Privileged Role Administrator, User Administrator, Application Administrator.

3. Enumerate permanent active assignments

# List permanent Global Admin assignments - should be near-zero in production
az ad group member list --group "Global Administrators" --query "[].userPrincipalName"

4. Restrict maximum activation duration Default 8 hours is excessive for most workflows. Set to 1–2 hours and require re-activation with justification.

5. Alert on PIM policy changes Any modification to PIM role settings is high severity and should trigger immediate SIEM alert — legitimate changes should be rare and change-managed.

6. Review approver pool size and security Approvers should be on hardware MFA (FIDO2 keys or passkeys). A single approver pool of two people phishable via email provides minimal protection.

Assessing Your Current PIM Posture

# Export all eligible role assignments for review
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/roleManagement/directory/roleEligibilityScheduleInstances?\$expand=principal,roleDefinition" \
  | jq '.value[] | {
      principal: .principal.displayName,
      role: .roleDefinition.displayName,
      startDateTime: .startDateTime,
      endDateTime: .endDateTime
    }'

Any account with an eligible assignment that you cannot explain and confirm is a valid security risk. Regular quarterly reviews of PIM eligible assignments — with documented business justification — should be a baseline control.

← All Analysis Subscribe via RSS