Entra ID Attack Techniques: How Attackers Compromise Microsoft Cloud Identity

Common Entra ID attack techniques include tenant reconnaissance, password spraying, token theft, device code and consent phishing, Conditional Access and MFA bypass, role and application abuse, dynamic group escalation, and hybrid pivots to on-premises Active Directory. Most of them abuse identity features rather than software bugs. Pwned Labs teaches these attacks hands-on in live Microsoft cloud tenants, through Academy labs and the Microsoft Cloud Attack and Defense bootcamp that leads to the MCRTP certification.

Identity is the front door to the Microsoft cloud, and Entra ID (formerly Azure Active Directory) is the identity system that guards it. It authenticates users, issues tokens, governs access to Azure and Microsoft 365, and bridges on-premises Active Directory to the cloud. That makes it one of the highest-value targets an attacker can reach, and one of the most misunderstood and easily misconfigured. This guide covers how attackers actually compromise Entra ID, the specific techniques that recur in real engagements, how MFA gets bypassed in practice, how a compromised identity reaches Azure resources, and how defenders detect malicious activity, contain and evict them.

What is Entra ID and why attackers target it

Entra ID is Microsoft's cloud identity and access management service. Every sign-in to Microsoft 365, every Azure resource permission, and much of the hybrid identity in a modern enterprise runs through it. If you compromise an identity with privileged roles in Entra ID, you are not just attacking one server, but the control plane for the entire tenant.

The critical shift from traditional on-premises Active Directory is that Entra ID is internet-facing by design. There is no traditional network perimeter to breach first. An attacker with a managed identity token gained from an internet-facing web application, credentials from phishing, or accidentally committed service principal credentials is already inside the identity layer. This is why identity, not the network, is the real perimeter in the cloud. Pwned Labs teaches Entra ID attacks from that starting point, in live Microsoft cloud tenants, from unauthenticated enumeration through to tenant takeover.

The Entra ID and Azure attack surface at a glance

Almost every high-impact attack on a Microsoft cloud tenant is a chain of identity steps: get a foothold as some identity, work out what it can do, escalate to a stronger one, and use it to reach data or take the tenant. The network is mostly irrelevant to this, because the services are reached over authenticated APIs rather than from inside a perimeter, so the attack surface follows the chain and each stage abuses a different part of the identity fabric. The Pwned Labs MCRTP curriculum follows the same chain, from Entra ID enumeration through consent and token attacks to lateral movement between Microsoft 365 and Azure resources.

Common Entra ID attack techniques

The following techniques commonly appear in real assessments of Microsoft cloud tenants. Most abuse legitimate identity features rather than software vulnerabilities. Pwned Labs teaches several of them as standalone Academy labs, including Abuse Dynamic Groups in Entra ID for Privilege Escalation and Leverage Device Code Phishing for Initial Access.

Reconnaissance and user enumeration

Before authenticating, attackers enumerate a tenant: discovering the tenant's federation and authentication settings, identifying the email address format and validating which email addresses exist. Much of this is possible unauthenticated, using the same endpoints legitimate clients use.

A tenant's OpenID Connect metadata and user-realm discovery endpoints reveal a great deal of information even before anyone authenticates, including whether the tenant uses managed authentication or federation, which shapes the rest of the attack. Tooling such as AADInternals are able to automate much of this unauthenticated reconnaissance.

Password spraying and token theft

Rather than brute forcing one account and risk locking it out, attackers spray one or a small number of passwords across many accounts to stay under lockout thresholds. Increasingly, the higher-value move is stealing credentials and ESTS cookies directly, through adversary-in-the-middle phishing. The gained cookies have already satisfied MFA, and allow a threat actor to register a device in Entra ID and enroll it in Intune.

Once they have a foothold, threat actors can perform token abuse to move seamlessly between different related applications, such as Teams, Outlook and SharePoint. Refresh tokens are long-lived and can be exchanged for fresh access tokens to different resources, giving an attacker both persistence and lateral movement across the Microsoft cloud. Open-source tooling such as ROADtools Token eXchange (roadtx), TokenTactic and AADInternals can automate this process.

Enumerating and bypassing Conditional Access

Conditional Access Policies are the rules that decide when multi-factor authentication and other controls are required, and they are only as strong as their exclusions. Attackers enumerate the gaps from an external perspective using tools such as findmeaccess: gaps that can arise from an excluded user, a trusted or overlooked device platform, a legacy authentication protocol that skips modern controls, an excluded application. Once a hole is found, a token obtained through that path sidesteps the MFA requirement entirely. Tools like ROADrecon can be used from an internal perspective to dump a tenant's Conditional Access policies for offline analysis, using the deprecated (but still functional) Azure AD Graph. Many of the conditional access gaps in the environment will then be easy to identify.

Device code and consent phishing

Device code phishing abuses the legitimate device authorization flow to trick a user into authorizing the attacker's session. Consent phishing goes further: the victim grants a malicious application OAuth permissions to their data, and the attacker retains access through that application even after a password reset. Because Microsoft now restricts default user consent to verified publishers and a set of low-risk permissions, the high-impact version of this attack usually targets an administrator, whose consent can approve the sensitive Graph permissions an attacker actually wants. Tenants that still allow broad user consent remain exposed at the user level.

Abusing application and service principal permissions

Applications and their service principals are identities too, and they are often over-permissioned and poorly monitored. An attacker who compromises an application secret or certificate, or who can add credentials to an existing service principal, gains a persistent, non-human identity with whatever permissions that application holds. These identities are also commonly not subject to MFA requirements.

Once inside Microsoft 365, attackers use post-exploitation frameworks such as GraphRunner or custom tooling to enumerate and pillage data across mailboxes, SharePoint, and Teams through the Graph API, all under a legitimate-looking application identity.

Role and privilege escalation

Highly privileged roles such as Global Administrator, Privileged Role Administrator, and Application Administrator are frequent escalation targets. Certain roles allow the holders to grant themselves or others additional access, add credentials to privileged applications, or manipulate group membership to inherit rights, turning a moderate foothold into tenant control. A common example of this is users assigned the Application Administrator or Cloud Application Administrator being able to create credentials for a service principal that is assigned the Global Administrator role.

Abusing dynamic groups and administrative units

Dynamic group membership is driven by user attributes. If an attacker can edit an attribute that they control, they can satisfy the rule for a privileged group and inherit its access automatically. Misconfigured Dynamic group-based access is a quiet but effective escalation path.

A common variant is infiltrating a dynamic group through a guest invitation: if the group's membership rule depends on a specific attribute (such as admin being in the email address), an attacker can invite a guest user named dev-admin-mbt@outlook.com to the tenant, who will automatically be a member of the dynamic group and inherit its access.

Hybrid identity and pivoting to the cloud

In hybrid environments, on-premises Active Directory syncs to Entra ID. Compromising the sync account, Seamless SSO, seed identities, or federation trust can turn an on-premises foothold into cloud tenant access. The reverse pivot from cloud into on-premises is equally valuable to an attacker, and sometimes it is possible to move back and forth between them, increasing access with each turn.

How the two directories are joined matters. Microsoft Entra Connect can sync with Password Hash Synchronization, Pass-through Authentication, or Federation, and each creates different attack surface, from the privileged synchronization service account to the federation trust that can be abused to forge tokens. Knowing which model a tenant uses tells an attacker how to pivot in either direction between on-premises and the cloud.

How can attackers bypass MFA in Entra ID?

Multi-factor authentication in Entra ID is bypassed far more often than it is broken. The common routes take the token instead of the password or find the edge of the policy that was supposed to enforce the second factor. Adversary-in-the-middle phishing proxies the real sign-in page, lets the user complete MFA, and steals the resulting session cookie, which already satisfies the policy. Device code phishing abuses the OAuth device authorization flow: the attacker starts the flow and persuades the target to approve the code, and the tokens are returned to the attacker with MFA satisfied by the victim. Consent phishing avoids the user's credentials entirely by getting an application the attacker controls granted permissions in the tenant, a foothold that survives both a password reset and an MFA re-registration. Stolen refresh tokens extend any of these, because they can be exchanged for new access tokens to Microsoft Graph, SharePoint, and Teams without re-triggering MFA.

The policy layer has edges of its own. Conditional Access is a set of rules, and rules have exclusions: break-glass and service accounts excluded from MFA, applications left out of the policy, legacy authentication protocols that never prompt for a second factor, and controls assumed to be on but never enforced for a given user population. Finding those edges is how an attacker uses an identity the policy was supposed to constrain. A tool such as FindMeAccess automates this, checking a given account against many combinations of resource, client ID, and user agent to find the combination that returns a token without a second factor. Even phishing-resistant methods have implementation surface, as the Pass-the-Passkey research described below showed. The defensive answer is phishing-resistant, device-bound authentication for every privileged identity, Conditional Access with as few exclusions as possible and a regular review of each one, legacy authentication blocked outright, and alerting on device-code sign-ins and anomalous token use. Pwned Labs teaches the adversary-in-the-middle route in its Bypass Azure MFA with Evilginx lab and the device code route in its Leverage Device Code Phishing for Initial Access lab.

From Entra ID into Azure resources: managed identities and AI applications

Identity is also how an attacker reaches what the tenant protects. Workload identities, the managed identities assigned to Azure resources, hand a token to whatever runs on the resource, so a compromised virtual machine, function, container, or web application can act as that identity and read Key Vault secrets, storage accounts, and whatever else the role reaches. Service principals with exposed credentials give the same result by a different route. Azure-hosted AI applications belong on this map too: an assistant built on Azure OpenAI or Azure AI Foundry can be driven by prompt injection, and because it usually runs with a managed identity, a successful injection pivots from the assistant into the Azure resources that identity can reach. Pwned Labs covers that path in depth in its guide to attacking AI workloads in the cloud. In each case the fix is the same: give every workload the narrowest identity its job allows, and treat a token obtained from a workload as a full compromise of whatever that identity can reach.

A practical methodology for testing Entra ID

This is also the sequence the Pwned Labs MCRTP certification assesses: inside a live Azure and Microsoft 365 tenant, candidates enumerate Entra ID, find a foothold, escalate, and move laterally to reach the objective.

1. Enumerate the tenant. Map users, groups, roles, applications and authentication settings from an external and low-privileged position.
2. Gain a foothold. Through token theft, consent or device-code phishing, sprayed credentials, or a leaked application secret.
3. Enumerate as the identity. Determine the roles, group memberships, and application permissions available to the compromised identity.
4. Escalate. Chain role permissions, application credential abuse, and group manipulation. Attack-path mapping tools such as BloodHound Community Edition make these chains visible, including well-worn paths like Application Administrator to Global Administrator.
5. Test the controls and follow the chain into resources. Probe Conditional Access and MFA for exclusions and gaps that let a constrained identity through, then request managed identity tokens from any workload reached, read the secrets and data they expose, and test the Entra Connect path to and from on-premises.
6. Establish persistence and demonstrate impact. Add application credentials, review what defenders record in the sign-in and audit logs, and achieve the objective across Azure and Microsoft 365.
   
   

Recent Entra ID developments in 2026

Entra ID tradecraft moves quickly, and the last two years brought several developments worth folding into any assessment.

CVE-2026-69836, a maximum-severity Entra ID flaw. In August 2026 Microsoft disclosed CVE-2026-69836, a CVSS 10.0 remote code execution issue caused by deserialization of untrusted data. It needed no authentication and no user interaction. Microsoft fixed it server-side, so customers had nothing to patch, but the case is a useful reminder that a provider-remediated flaw still belongs in our threat model. We cannot patch it and we cannot test the fix, so the response is detection and assurance: confirm our monitoring would surface anomalous Entra activity, and record the risk even when the vendor owns the remediation.

Pass-the-Passkey. SpecterOps research presented at Black Hat USA 2026 showed that phishing-resistant authentication can still be undermined by implementation gaps rather than by breaking the cryptography. Windows 11 logged complete WebAuthn assertion responses to an event log, and Entra ID did not fully enforce anti-replay controls such as challenge uniqueness, session binding, and signature-counter verification. Together these could let a captured assertion be replayed to impersonate a user. Microsoft's July 2026 Windows updates (CVE-2026-34348) make the logged assertions unusable for replay, and Microsoft says it has applied mitigations on the Entra side without publishing their details. The lesson for us is that passkeys reduce phishing risk but do not remove the need to watch how assertions are stored and validated.

CISA advisory AA26-237A. In its A Tale of Two SOCs advisory, CISA described two red team assessments that both reached full domain compromise and pivoted into cloud resources through Entra ID and Active Directory Certificate Services. One organization detected the activity and the other did not, using the same tooling. The difference was how the telemetry was tuned and correlated, which is the same detection-engineering gap these attacks rely on. The Pwned Labs MCRTE bootcamp covers this hybrid route, including AD CS abuse and the Entra Connect paths in both directions.

Mandatory MFA on the Azure control plane. Microsoft has made multi-factor authentication mandatory for the Azure management surface in phases. Sign-ins to the Azure portal, the Microsoft Entra admin center, and the Intune admin center were enforced across all tenants through early 2025, and from October 2025 enforcement extended to the Azure Resource Manager layer, which covers Azure CLI, Azure PowerShell, the Azure mobile app, and Infrastructure as Code tooling. Read-only operations and workload identities such as managed identities and service principals are not in scope. For an attacker this closes the easy path of using a stolen password at the portal, and it is part of why token theft and the device code and consent routes above matter more than password compromise, since those carry the second factor with them. It also means a test should confirm the enforcement is actually applied for every administrative account, because the rollout is tenant-by-tenant and exclusions still leave gaps.

Azure CLI and Azure PowerShell removed from the Family of Client IDs. Family refresh tokens let a token issued to one first-party Microsoft client be exchanged for tokens to any other client in the same family, which historically let a refresh token captured from Azure CLI or Azure PowerShell be traded for access to unrelated services such as Microsoft Teams or Microsoft Graph. In February 2026 Microsoft removed Azure CLI and Azure PowerShell from the Family of Client IDs, so a refresh token from those tools can no longer request tokens for unrelated services and the exchange now fails with AADSTS70000. The management tooling and the productivity applications no longer share one token family. This narrows what a stolen administrative token reaches, but it does not remove token abuse: tokens for the resource they were issued for still work, other first-party clients remain in the family, and the technique is only reduced in scope, not closed.

How defenders protect Entra ID

• Enforce phishing-resistant multi-factor authentication and Conditional Access, and treat token theft as a real threat, not just password compromise.
• Inventory and monitor applications and service principals, and alert on new credentials added to privileged applications.
• Apply least privilege to directory roles, use Privileged Identity Management for just-in-time elevation, and review Global Administrator assignments.
• Watch the Entra ID sign-in and audit logs for consent grants, device-code sign-ins, and role changes, and test the tenant adversarially to see which paths actually reach admin.
  
  

The controls map onto the chain, and the strongest ones cut it early. The Pwned Labs Microsoft Cloud Attack and Defense bootcamp teaches these attack chains together with the detections that catch them, and the MCRTP certification it leads to suits defenders who build detections as well as red teamers.

How do I learn Azure and Entra ID attack techniques hands-on?

You cannot learn identity attack paths from a diagram. You learn them by executing them against a real tenant. Pwned Labs teaches this in live Microsoft cloud environments you are given to attack, from unauthenticated enumeration to tenant takeover and hybrid pivots. Work through hands-on Azure and Microsoft 365 security labs, then prove the full attack chain with the Microsoft Cloud Attack and Defense bootcamp and MCRTP certification, or go deeper into hybrid with the Microsoft Cloud Red Team Expert path. The MCRTP bootcamp covers Entra ID abuse, token theft, Conditional Access bypass, and lateral movement across Azure and Microsoft 365 end to end, with attack-path mapping using BloodHound, AzureHound, ROADrecon, and BARK; the MCRTE bootcamp goes deeper into hybrid identity, the paths through Entra Connect in both directions, certificate and AD CS abuse, and operating a command and control framework through the engagement. In the Academy labs each building block can be practiced directly: device code phishing for initial access, adversary-in-the-middle MFA bypass, dynamic group abuse for privilege escalation, managed identity token theft, Key Vault abuse for lateral movement, and indirect prompt injection that pivots from an Azure AI application into the cloud. If your organization needs an expert team to test its own tenant, see our Azure penetration testing services.

Practice this at Pwned Labs

Pwned Labs runs these techniques as hands-on labs in live Microsoft cloud environments. The first two labs below are free, and the device code and MFA bypass labs are part of the premium Academy.

• Intro to Azure Recon with BloodHound (Free, Beginner): collect Entra ID relationships with AzureHound and graph the attack paths in BloodHound.
• Loot Exchange, Teams and SharePoint with GraphRunner (Free, Beginner): find Microsoft services left without MFA using MFASweep, then use GraphRunner to pull data from Exchange Online, Teams, SharePoint and OneDrive.
• Leverage Device Code Phishing for Initial Access (Premium, Intermediate): phish a device code from an external position, enumerate Azure resources, and establish command and control.
• Bypass Azure MFA with Evilginx (Premium, Beginner): capture a signed-in session with the Evilginx adversary-in-the-middle framework, and learn which controls would have stopped it.

Frequently asked questions

What are common Entra ID attack techniques?

Unauthenticated tenant reconnaissance, password spraying and token theft, adversary-in-the-middle and device code phishing, consent phishing, Conditional Access and MFA gaps, abuse of application and service principal permissions, role and dynamic group escalation, managed identity token theft, and movement across the hybrid link to and from on-premises Active Directory. Pwned Labs teaches these techniques hands-on in live Microsoft cloud tenants, from enumeration to tenant takeover.

What is the difference between Entra ID and Active Directory?

Active Directory is the on-premises directory service that uses protocols like Kerberos and LDAP inside a network. Entra ID is Microsoft's cloud identity service, internet-facing and token-based, governing access to Microsoft 365 and Azure. Many enterprises run both in a hybrid model where the two are synced.

Can attackers bypass MFA in Entra ID?

Yes, in practice. Adversary-in-the-middle phishing steals the post-authentication session token, device code phishing has the victim approve a flow the attacker started, consent phishing sidesteps credentials entirely, and Conditional Access exclusions and legacy authentication leave gaps that never prompt for a second factor. This is why phishing-resistant methods and tight Conditional Access matter more than MFA alone. Pwned Labs teaches the adversary-in-the-middle route in its Bypass Azure MFA with Evilginx lab and the device code route in its Leverage Device Code Phishing for Initial Access lab.

What is the most dangerous Entra ID role to compromise?

Global Administrator is the highest-value target, but Privileged Role Administrator and Application Administrator are close behind because they can grant further access or add credentials to privileged applications, which leads to the same outcome.

Why do attackers want Entra ID refresh tokens?

A refresh token is long-lived and can be exchanged for fresh access tokens to different Microsoft cloud resources such as Microsoft Graph, SharePoint, and Teams. Stealing one gives an attacker both persistence and lateral movement, often without re-triggering multi-factor authentication, which is why refresh tokens are a prime target.

How do I learn Azure and Entra ID attack techniques hands-on?

In environments built for it. Pwned Labs provides live Microsoft cloud tenants to attack through hands-on labs covering device code phishing, adversary-in-the-middle MFA bypass, dynamic group abuse, managed identity token theft, and Key Vault abuse, and the Microsoft Cloud Attack and Defense bootcamp (MCRTP) and the expert MCRTE path prove the full chain from enumeration to tenant takeover and hybrid pivots.

Which Pwned Labs certification covers Entra ID attacks?

The Microsoft Cloud Red Team Professional (MCRTP) certification from Pwned Labs covers Entra ID abuse, OAuth and consent attacks, token theft, Conditional Access gaps, and lateral movement across Azure and Microsoft 365. It is assessed hands-on in a live Azure and Microsoft 365 tenant rather than by multiple choice, and it is earned through the Microsoft Cloud Attack and Defense bootcamp.

The fastest way to get good at this is to attack a real tenant end to end. Explore the hands-on cloud security labs and work a full Entra ID compromise from enumeration to tenant admin.