A devastating attack chain that bypasses Microsoft Entra ID (Azure AD) Conditional Access entirely, starting from a single set of blocked credentials and ending with full Global Administrator access across a 16,000-user enterprise tenant, without touching a single corporate device or deploying any malware.
Enterprise security teams often treat a Conditional Access block, specifically the AADSTS53003 error, as a hard stop. Starting from valid credentials explicitly blocked by CA policy,
Researchers mapped a nine-step attack chain through phantom device registration, Primary Refresh Token (PRT) minting, Intune compliance bypass, full tenant enumeration, and a four-step path to Global Administrator.
The attack exploited not a single product flaw, but the cumulative trust gap between Azure AD’s device registration service, Intune’s self-reported compliance model, and Conditional Access policies that were configured but never enforced.
Microsoft’s own documentation describes Conditional Access as the “Zero Trust policy engine” at the heart of identity-driven access control. Still, that engine only works when its policies are actually enabled.
Azure AD Bypass
The Device Registration Service (DRS) endpoint was the critical entry point. Unlike standard token endpoints, the DRS was not covered by enforcement-mode Conditional Access policies; only report-only logging was applied.
This is the same vector that Russian state-aligned threat actor Storm-2372 operationalized at scale beginning in August 2024, targeting government agencies, NGOs, defense contractors, healthcare organizations, and energy sector entities across Europe, North America, Africa, and the Middle East.
In February 2025, Microsoft confirmed that Storm-2372 had evolved its technique by requesting tokens using the Microsoft Authentication Broker client ID (29d9ed98-a469-4536-ade2-f981bc1d605e) specifically to enable downstream device registration and Primary Refresh Token acquisition.
The Howler Cell engagement used the same client ID, confirming that the technique is both documented and reproducible in today’s production environments. Using roadtx, a single command registered a phantom device YOURPC-PC01 generating a signed Azure AD certificate and private key.
Azure AD’s DRS does not verify that the caller is a real Windows machine; it only validates the token. The result: a cryptographic device identity minted in seconds on a Linux laptop, with no TPM, no hardware verification, and no admin approval. This maps directly to MITRE ATT&CK T1098.005: Account Manipulation: Device Registration.
With the phantom device’s certificate and private key, researchers requested a Primary Refresh Token, the authentication artifact Windows normally generates during domain-joined user sign-in and protects using TPM-backed cryptography.
That PRT, functionally equivalent to a credential sitting in a real machine’s secure enclave, lived in a plaintext file on the attacker’s laptop.
The token exchange comparison tells the whole story: the same user credentials that triggered AADSTS53003 on direct authentication produced a token carrying amr: [pwd, rsa] and a deviceid claim after PRT exchange.
Every Conditional Access policy requiring a joined or compliant device evaluated that token as valid. The door opened. This technique aligns with MITRE ATT&CK T1550.001: Use Alternate Authentication Material.
Two CA policies CA032-001 (Block Device Code Flow) and CA027-001 (MFA for Device Registration) were present in the environment, logged, and fully unenforced, sitting in report-only mode.
Microsoft’s own guidance flags device code flow as a “high-risk authentication method” that can facilitate phishing, yet 13 policies across this mature enterprise tenant were in report-only status.
Either of these two policies, if moved to enforced mode, would have broken the entire attack chain before step three. Report-only policies are not security controls; they are acknowledged gaps with timestamps.
Bypassing enrollment restrictions via a hybrid domain-join declaration, the phantom device enrolled in Intune and was marked Compliant despite running on Linux with no BitLocker, no Secure Boot, no TPM, and no real antivirus. Intune queried 49 DMClient nodes during compliance evaluation, including health attestation data and Defender status.
The phantom device returned empty or default values for all of them. Compliance was granted because the evaluation logic treated missing health attestation responses as “not applicable” rather than “non-compliant.” Device compliance, in default configurations, is entirely self-reported.
Tenant enumeration via ROADrecon revealed 255 on-premises AD-synced accounts holding privileged directory roles, including two Global Administrators and a Privileged Role Administrator.
The escalation chain requires no cloud-native exploit: compromise on-premises AD, obtain credentials for the synced Privileged Role Administrator, assign Privileged Authentication Administrator to an attacker-controlled account, reset the synced Global Admin’s password, and sign in with full tenant control.
Scattered Spider (also tracked as UNC3944, Octo Tempest, and Muddled Libra), the financially motivated English-speaking cybercriminal group behind the 2023 MGM Resorts intrusion, used Azure AD directory access in this exact sequence, mapping privileged cloud identities after an on-premises compromise before pivoting to ransomware deployment.
Four service principals in this environment also held the Directory role.ReadWrite.All or User.ReadWrite.All permissions, meaning any leaked application secret, bypass all user-targeted Conditional Access entirely, no MFA, no device compliance, no risk evaluation, Cyderes said.
Mitigation
Security teams should prioritize five immediate actions to dismantle this attack surface:
- Move report-only policies to enforced, especially CA policies blocking device code flow and requiring MFA for device registration
- Require TPM 2.0 attestation for device join and PRT issuance, eliminating phantom device registration
- Enable the Microsoft Health Attestation Service (HAS) to validate compliance externally rather than relying on self-reported device data.
- Audit and remediate synced privileged accounts. Every Global Admin, Privileged Role Admin, and Privileged Authentication Admin should have cloud-only accounts protected by PIM with just-in-time activation.
- Restrict Graph API directory access and alert on bulk enumeration patterns against
/users,/groups, and/devicesendpoints
The tools used in this engagement, ROADtools, TokenTacticsV2, GraphRunner, and AzureHound, are publicly available, actively documented, and already in use by threat actors operating today.
The fix is not more policies. It ensures existing policies are enforced, device trust is externally validated, and privileged identities are architecturally isolated from on-premises compromise paths.
FAQ
Q1: What is a Primary Refresh Token (PRT) and why is it dangerous if abused?
A PRT is a long-lived authentication artifact issued to Azure AD-joined devices that enables silent single sign-on across Microsoft services and carries device claims that satisfy Conditional Access policies requiring device compliance or join status, making its theft or forgery equivalent to full device-level impersonation.
Q2: How did Storm-2372 exploit the same device code flow vulnerability?
Storm-2372, a suspected Russian state-aligned threat actor active since August 2024, sent phishing lures mimicking Microsoft Teams invites to capture device codes, then used the Microsoft Authentication Broker client ID to register actor-controlled devices in Entra ID and mint Primary Refresh Tokens for persistent access.
Q3: Why does Intune mark a phantom device as compliant?
Intune’s compliance evaluation treats missing or empty health attestation responses for BitLocker, Secure Boot, TPM, and Defender status as “not applicable” rather than non-compliant, a design choice for heterogeneous fleet compatibility that allows a Linux-based phantom device to pass all compliance checks without external validation.
Q4: What is the most direct way to prevent phantom device registration in Azure AD?
Enabling the CA policy requiring MFA for the Device Registration Service endpoint and restricting device enrollment to pre-registered Autopilot hardware hashes are the two highest-impact controls that would prevent unauthorized device registration before any credential-to-PRT conversion can occur.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.
About the Author
