Azure Entra ID Attack Paths — From Guest User to Global Admin

Why Entra ID Is the Crown Jewel

Microsoft Entra ID sits at the centre of every Microsoft 365 and Azure deployment. Control an account with the right roles, or abuse sufficient application permissions, and an attacker can read all email in the tenant, exfiltrate SharePoint data, pivot to Azure subscriptions, and maintain persistence through service principals that survive password resets and MFA changes. Entra ID attack paths are disproportionately impactful compared to equivalent on-premises Active Directory compromises — cloud identity misconfigurations frequently provide direct access to data, not just infrastructure.

Attack Path 1: OAuth Consent Phishing

What it is: An attacker registers a malicious app in any Entra ID tenant, then sends users a phishing link that requests OAuth consent. If the user (or an admin) consents, the app receives long-lived tokens — often with permissions to read email, access files, or act as the user without any password.

Why it works: User consent is enabled by default for low-privilege permission scopes. Users see a Microsoft-branded consent prompt and assume it’s legitimate.

Misconfiguration: User consent settings set to allow users to consent to apps from any publisher, or to all permissions.

Remediation:

Entra Admin Centre → Enterprise applications → Consent and permissions
→ User consent settings → "Allow user consent for apps from verified publishers, for selected permissions only"

Or via Graph API:

# Check current consent policy
az rest --method GET \
  --uri "https://graph.microsoft.com/v1.0/policies/authorizationPolicy" \
  --query "defaultUserRolePermissions.permissionGrantPoliciesAssigned"

Set to ManagePermissionGrantsForSelf.microsoft-user-default-low or more restrictive.

Detection:

• AuditLogs in Sentinel — ActivityDisplayName == "Consent to application" by non-admin users
• Monitor for new service principals created in the tenant from external publishers
• Alert on consent grants for high-risk permissions: Mail.Read, Files.ReadWrite.All, User.ReadBasic.All at scale

Attack Path 2: Privileged Role Assignments via App Roles

What it is: Overly permissive app role assignments give service principals (applications) rights equivalent to privileged users. An attacker who compromises the application’s client secret or certificate inherits those rights without triggering user-based controls (no MFA, no conditional access).

Dangerous app roles:

• RoleManagement.ReadWrite.Directory — can assign any directory role, including Global Admin
• AppRoleAssignment.ReadWrite.All — can grant any app role to any principal
• Directory.ReadWrite.All — broad directory write access

Misconfiguration: Applications granted these roles without time-limiting, JIT approval, or regular review.

Remediation:

# Audit service principals with high-privilege app roles
az ad app list --all --query "[].{AppId:appId, DisplayName:displayName}" | \
  xargs -I{} az ad sp list --filter "appId eq '{}'"
# Or use Graph to enumerate app role assignments:
GET https://graph.microsoft.com/v1.0/servicePrincipals/{id}/appRoleAssignments

Replace broad app roles with more specific scopes where possible. Use managed identities over client secrets — they can’t be exfiltrated.

Detection in Sentinel:

AuditLogs
| where OperationName == "Add app role assignment to service principal"
| extend RoleName = tostring(TargetResources[0].modifiedProperties[0].newValue)
| where RoleName has_any ("RoleManagement", "AppRoleAssignment", "Directory.ReadWrite")
| project TimeGenerated, InitiatedBy, RoleName, TargetResources

Attack Path 3: Guest Account Enumeration and Lateral Movement

What it is: External guest accounts in Entra ID can enumerate other users, groups, and applications by default. Combined with a compromised guest account (from a supply chain partner or shared password), this provides an internal reconnaissance capability.

What guests can do by default:

• Read all user display names, UPNs, and object IDs
• Read all group names and memberships
• Read all registered application names and IDs

Misconfiguration: Guest user access set to the default “Guest users have the same access as members (most permissive)” or “Guest users have limited access to properties and memberships of directory objects.”

Remediation:

Entra Admin Centre → External Identities → External collaboration settings
→ Guest user access: "Guest user access is restricted to properties and memberships of their own directory objects (most restrictive)"

Combine with Entra ID B2B cross-tenant access policies to restrict inbound guest permissions at a tenant level.

Attack Path 4: PRT (Primary Refresh Token) Theft

What it is: On Entra ID-joined devices, the Primary Refresh Token allows seamless SSO. If an attacker achieves code execution on an enrolled device, they can extract the PRT using tools like AADInternals and use it to generate access tokens for any application without triggering MFA.

Why it’s impactful: PRT-based tokens satisfy MFA requirements — the device registration itself satisfies the MFA claim. Conditional access policies requiring MFA are bypassed.

Detection:

• Monitor for token refresh activity from unusual IP addresses or new device registrations
• Enable Entra ID token protection (preview) — binds tokens to specific devices
• Alert on SignInLogs where DeviceDetail.trustType == "Azure AD joined" but IPAddress doesn’t match the expected corporate range

Attack Path 5: Conditional Access Policy Gaps

A common configuration mistake: conditional access policies that require MFA for sign-ins but exclude service accounts, break-glass accounts, or specific legacy authentication protocols.

Common gaps to audit:

• Legacy authentication (SMTP, IMAP, POP3, basic auth) exempted from MFA policies
• Break-glass accounts with no CA policy coverage
• Named locations too broadly defined, creating bypasses
• What if tool never used to validate effective policy

Audit command:

# List conditional access policies and their exclusions
az rest --method GET \
  --uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" \
  --query "value[].{Name:displayName, State:state, Exclusions:conditions.users.excludeUsers}"

Priority Hardening Checklist

1. Restrict user consent to verified publishers only
2. Review all app role assignments — remove RoleManagement.ReadWrite.Directory and AppRoleAssignment.ReadWrite.All from non-essential apps
3. Enable Privileged Identity Management (PIM) for all privileged roles — no permanent Global Admin assignments
4. Set guest access to most restrictive
5. Block legacy authentication via conditional access
6. Enable sign-in risk and user risk policies
7. Deploy Entra ID Identity Protection with automatic remediation for high-risk sign-ins