Tracking privilege escalation in Azure AD

What “privilege escalation” looks like in Entra ID

In Entra ID, privilege is not just “Global Admin.” It’s any capability that can:

• Change authentication controls (MFA, Conditional Access, authentication methods).
• Assign or activate privileged roles.
• Grant application permissions (especially Microsoft Graph / Exchange / SharePoint / Intune scopes).
• Manage identities (create users, reset passwords, change group memberships).
• Modify trust boundaries (cross-tenant settings, federation settings, identity providers).

Common escalation paths to track

• Role assignment or activation: A user becomes eligible/active for a privileged directory role.
• Privileged group membership: A user is added to a group that is assigned a role (or a role-assignable group).
• OAuth / consent abuse: An app is granted high-impact permissions via admin consent.
• Conditional Access weakening: An exclusion is added (user, group, location, device), or a policy is disabled.
• Credential-based escalation: Auth methods are added/changed, password reset happens, or MFA is re-registered.
• Break-glass misuse: Emergency accounts are used outside incident windows.

Start with a “privilege surface map” (what you must monitor)

Tracking escalation works best when you define your privilege surface first—otherwise you drown in logs. Build a simple map with these layers:

Layer 1: Tier-0 identities (who can change identity controls)

• Global Administrator
• Privileged Role Administrator
• Security Administrator / Conditional Access Administrator
• Authentication Administrator / Privileged Authentication Administrator
• Cloud Application Administrator / Application Administrator

Layer 2: Privileged groups (who can become Tier-0)

• Role-assignable groups
• Groups used for admin access (e.g., “M365 Admins”, “Intune Admins”, “Security Ops”) that are mapped to roles
• Groups excluded from Conditional Access policies

Layer 3: Privileged apps (what can impersonate users or act as admins)

• Enterprise apps with high-impact Graph permissions (Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, etc.)
• Apps with Exchange/SharePoint admin scopes
• Apps using certificate credentials or long-lived secrets

If you want a stronger foundation for role design and scope boundaries, review: Role-based access control in Microsoft Entra and How access management works in Azure AD.

Logs you need to track privilege escalation (and what each proves)

A solid investigation requires logs that answer three questions: What changed? Who changed it? From where/how?

1) Audit logs (the “what changed” source)

Audit logs are your primary record of administrative actions: role assignments, group membership changes, app consent changes, policy updates, and directory object modifications. Export and centralize them, because portal-only retention is not enough for real investigations.

Practical guide: How to export Entra ID logs efficiently.

2) Sign-in logs (the “who/where/how did they authenticate” source)

Use sign-in logs to correlate suspicious changes with risky sign-ins, unusual IPs, impossible travel, unfamiliar devices, and sign-in method anomalies. For escalation investigations, you want to see what preceded the change.

3) PIM (Privileged Identity Management) logs (the “how did privilege become active” source)

If you use PIM, privilege escalation often appears as: “User activated role” or “User made eligible for role”. PIM gives you the strongest timeline evidence: approval, justification, MFA requirement, and activation window.

If you’re rolling out PIM (or tuning it), see: Azure Privileged Identity Management (PIM) – An overview.

4) Identity Governance signals (the “should they have had this access” source)

Access reviews, entitlement management, and governance workflows help you prove whether a privilege state was expected or not. Even if escalation is “authorized,” governance tells you whether it was appropriate.

Background reading: Identity governance in Azure AD.

5) SIEM / Sentinel / Log Analytics (the “continuous detection and correlation” source)

You can investigate in the portal, but you can’t run a real detection program there. Centralize logs and build correlation rules: “role assignment + risky sign-in + CA policy change within 30 minutes” should never be invisible.

The minimum viable detections for privilege escalation

If you only implement a handful of detections, implement these first. They give the highest signal-to-noise ratio.

Detection A: New privileged role assignment

• Trigger: A directory role assignment is created (permanent), or eligibility is granted.
• Why it matters: This is direct privilege elevation, often the end goal.
• Enrichment: Was it done by a break-glass account? From an unusual IP? Outside a change window?

Detection B: Privileged role activation (PIM)

• Trigger: Role activation occurs for Tier-0 roles (Global Admin, Privileged Role Admin, Conditional Access Admin, etc.).
• Why it matters: “Temporary admin” is still admin—track it like production access.
• Enrichment: Was approval required? Was justification present? Was MFA satisfied?

Detection C: Changes to Conditional Access policies

• Trigger: Policy disabled, exclusions added, grant controls weakened, session controls changed.
• Why it matters: Attackers often “make it easy to stay in” by weakening controls.
• Enrichment: Was the editor recently elevated? Was the change followed by a role assignment?

Detection D: Admin consent to high-impact application permissions

• Trigger: Admin consent granted for broad directory or mail scopes.
• Why it matters: Apps can become a stealthy persistence mechanism with huge reach.
• Enrichment: New app registration? New credential added? Consent granted by whom?

Detection E: Authentication method / credential changes on privileged accounts

• Trigger: MFA reset, new auth method added, password reset, SSPR events for admin accounts.
• Why it matters: Many takeovers start by taking over the ability to authenticate.
• Enrichment: Was it self-initiated? Helpdesk-initiated? From a new device?

Investigation playbook: proving an escalation incident end-to-end

When you suspect escalation, your job is to build a timeline that stands up to scrutiny: what happened, who did it, and what access changed because of it.

Step 1: Identify the “privilege event” you’re investigating

• Role assignment created (permanent or eligible)
• PIM activation happened
• Conditional Access weakened
• Admin consent granted
• Group membership changed for a privileged group

Step 2: Pull the audit event details

• Initiated by: user/service principal
• Target: user/group/app/policy
• Operation: Add member / Add role assignment / Update policy
• Result: success/failure
• Additional details: IP, app used, correlation IDs (if available)

Step 3: Correlate the initiator’s sign-in activity

• Was the sign-in risky or flagged by Identity Protection?
• Was it from a new country/ASN/IP range?
• Was it via legacy auth or unusual client?
• Did it happen immediately after a password/MFA reset?

Step 4: Expand the blast radius

Privilege escalation investigations fail when teams stop at “we saw a role assignment.” You need to determine what that new access enabled:

• What roles does the user now have (active and eligible)?
• What groups are they now in (especially role-assignable groups)?
• Did they create new users, add credentials to apps, or change policies after being elevated?
• Did they grant consent to applications or add federation/identity provider changes?

Step 5: Look for persistence

• New service principals with broad permissions
• New app secrets/certificates added
• Additional Global Admins created
• Break-glass accounts used or modified
• CA exclusions added for a stealth admin group

Step 6: Containment (without destroying evidence)

Containment is its own discipline, but for tracking purposes:

• Export relevant logs immediately (audit + sign-ins + PIM events).
• Record current role assignments and group memberships (before changes).
• Disable or block the suspected principal (user/app) using your incident process.
• Rotate secrets/certs for suspicious apps and review consent grants.

Sentinel-style KQL patterns (starter set)

The exact tables depend on your connector and workspace configuration, but these patterns illustrate what you should be searching for. Adapt field names to your environment.

Role assignment changes

// Find role assignment / directory role changes
AuditLogs
| where OperationName has_any ("Add member to role", "Add eligible member to role", "Add member to directory role")
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, Result, AdditionalDetails
| order by TimeGenerated desc

Conditional Access policy changes

// Detect Conditional Access policy modifications
AuditLogs
| where OperationName has_any ("Update conditional access policy", "Add conditional access policy", "Delete conditional access policy")
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, Result, AdditionalDetails
| order by TimeGenerated desc

Admin consent events

// Look for admin consent / permission grant events
AuditLogs
| where OperationName has_any ("Consent to application", "Add delegated permission grant", "Add app role assignment grant")
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, Result, AdditionalDetails
| order by TimeGenerated desc

Privileged sign-ins from unusual locations (correlation hint)

// Privileged users sign-ins from unfamiliar locations
SigninLogs
| where UserPrincipalName in~ ("admin1@contoso.com","admin2@contoso.com")  // replace with your privileged list
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, ClientAppUsed, ResultType, RiskLevelDuringSignIn
| order by TimeGenerated desc

Hardening your tracking (so escalation attempts are louder)

Tracking gets dramatically easier when you force privileged actions through controlled paths. These controls don’t just prevent escalation—they make malicious escalation stand out.

Make privilege time-bound and reviewable

• Use PIM for privileged roles: eligible by default, activated only when needed.
• Require MFA for activation and require justification (and approval for Tier-0 roles).
• Limit activation duration (e.g., 1–4 hours) and block “permanent active” patterns.

Protect identity controls behind stronger rules

• Strong Conditional Access for admin portals and admin actions.
• Restrict admin actions to compliant devices or privileged workstations.
• Use named locations carefully; avoid broad “trusted IP” bypasses.

Reduce your “consent attack surface”

• Restrict who can grant admin consent.
• Review enterprise apps regularly, especially high-privilege Graph scopes.
• Monitor credential additions (new secrets/certs) for service principals.

Build an escalation “change window” culture

• Require tickets/change IDs in PIM justifications (even if lightweight).
• Alert on privileged changes outside business hours or outside approved windows.
• Alert on “chain patterns” (e.g., CA policy weakened then role assigned).

Operational checklist

Weekly

• Review recent privileged role assignments and PIM activations.
• Review Conditional Access policy changes and exclusions.
• Review new enterprise apps and new admin consent grants.

Monthly

• Run access reviews for privileged roles and role-assignable groups.
• Review break-glass account usage (it should be near-zero).
• Audit high-impact app permissions and remove what’s unnecessary.

Quarterly

• Validate your “privileged identity inventory” (users, groups, apps).
• Test your detection rules with controlled simulations (tabletop + technical).
• Confirm log retention and that exports are complete and queryable.

Common pitfalls (and how to avoid them)

• “We only monitor Global Admin.” Attackers often use other roles to reach Global Admin indirectly (CA admin, app admin, auth admin).
• “We have logs in the portal.” Portal retention and UI-only workflows aren’t enough for investigations; centralize logs.
• “PIM exists, so we’re safe.” PIM without alerting and review still allows stealthy, repeated activations.
• “Apps are less risky than users.” A highly-permissioned service principal can be a persistent admin with fewer human signals.
• “Exclusions are temporary.” Exclusions often become permanent backdoors; track them as privileged changes.

Related reading on Windows-Active-Directory.com

• How to export Entra ID logs efficiently
• Azure Privileged Identity Management (PIM) – An overview
• Role-based access control in Microsoft Entra
• Identity governance in Azure AD
• How access management works in Azure AD