TL;DR
Howler Cell (Cyderes) conducted an authorized red team against a mature enterprise Microsoft Entra ID tenant — 16,000 users, 82,000 devices, 78 Conditional Access policies. Starting from a single set of valid credentials that were explicitly blocked by CA policies (AADSTS53003), the team reached Global Administrator access through a five-step phantom device chain. No corporate endpoint was touched. No malware was deployed. The vulnerabilities are not bugs in a single component — they are trust chain gaps between four systems (Entra ID, Device Registration Service, Intune, and on-premises AD) that each assume another is performing validation.
The same Device Registration Service entry vector was operationalized at scale by Storm-2372, a suspected Russian state-aligned APT, across government, defense, healthcare, and energy targets throughout 2024–2025. This is not a theoretical research curiosity. It is a live attack path sold in commodity IAB markets today.
Background
The Promise of Conditional Access
Microsoft Entra ID (formerly Azure AD) Conditional Access is the cornerstone of modern Zero Trust identity architectures. It promises: if a user's credential is blocked, an untrusted location is detected, or a device is non-compliant, access is denied. Enterprise security teams invest significantly in building CA policy libraries — complex rule sets governing MFA requirements, compliant device posture, named location blocks, and risk-score thresholds.
The Howler Cell engagement examined whether a determined adversary could escape this gate entirely, starting from the most common initial access commodity available today: a valid credential purchased from an initial access broker for a few hundred dollars in cryptocurrency.
The Credential Market Reality
In 2026, buying valid enterprise credentials is a commodity transaction. Initial access broker listings on criminal markets routinely include: organization name, employee count, revenue range, MFA bypass notes, and access type. A standard user account for a mid-size enterprise trades for $150–$600 depending on privilege level and recency. An attacker who purchases a blocked credential faces an AADSTS53003 error — a door that appears locked but, as this research demonstrates, has multiple side entrances.
Technical Analysis: The Five-Step Kill Chain
Step 1 — The Blocked Front Door
The attacker authenticates with valid credentials via the standard token endpoint. CA policy fires immediately: AADSTS53003 — access blocked, policy requires compliant or Hybrid Azure AD joined device. The credential is valid. The path is wrong.
Most red teamers stop here. Advanced attackers — and Storm-2372 — do not.
Step 2 — The Open Side Door: Device Registration Service
Entra ID exposes multiple authentication flows, and Conditional Access policies must target each flow individually. The standard authentication path was blocked. The device code flow — which targets the Device Registration Service (DRS) endpoint rather than the standard /token endpoint — was not covered by enforcement-mode policies.
Two CA policies existed: CA032-001 (Block Device Code Flow) and CA027-001 (MFA for Device Registration). Both were present in the tenant. Both were in Report-Only mode. Report-Only policies generate audit logs. They do not block authentication.
A Report-Only CA policy is not a security control. It is an acknowledged gap with a timestamp.
Using the device code flow against the DRS endpoint, the attacker authenticated successfully and moved to device registration.
Step 3 — Phantom Device Registration
The DRS API validates the authentication token — not the hardware presenting it. A single roadtx command registered a phantom device with a signed Entra ID certificate and private key from a Linux laptop sitting outside the corporate perimeter.
No TPM. No hardware verification. No Secure Boot. No admin approval. No callback to verify the device exists.
MITRE ATT&CK mapping: T1098.005 — Account Manipulation: Device Registration.
The phantom device is now a recognized, trusted endpoint in the tenant's device registry. The certificate and private key belong to the attacker.
Step 4 — Primary Refresh Token Minting and CA Policy Bypass
With a registered phantom device and a valid device certificate, the attacker minted a Primary Refresh Token (PRT). The PRT is the crown jewel of Entra ID session persistence — it carries device claims that downstream token exchanges implicitly trust.
When the attacker exchanged the PRT for access tokens, Entra ID evaluated the session as device-authenticated. CA policies requiring a compliant or hybrid-joined device were bypassed entirely. The tenant now saw the attacker's session as originating from a trusted, enrolled endpoint.
This enabled full directory enumeration via Microsoft Graph API: users, groups, service principals, app registrations, and — critically — highly privileged role assignments.
Step 5 — Intune Compliance Achieved Without a Compliant Device
Some CA policies required not just device registration but Intune compliance. Howler Cell bypassed this with two observations:
1. Hybrid domain-join claim forgery: By declaring hybrid domain-join status, the phantom device bypassed Intune pre-registration requirements. Intune trusted the client's self-declared domain membership without verifying it against on-premises Active Directory.
2. Missing attestation treated as non-applicable: Intune's compliance evaluation logic treated missing health attestation responses — no TPM chip, no BitLocker, no Secure Boot, no AV — as "not applicable" rather than non-compliant. The device was marked compliant because it didn't fail any checks; it simply didn't report them.
A compliant phantom device enabled download of enterprise applications from Intune. A single .intunewin package contained a deployment script referencing an internal UNC path: \\INTSVR01\AdminPoint\setup.exe — exposing server naming conventions, administrative share structure, and internal network topology without a single packet sent to the production environment.
The Escalation Path to Global Administrator
Directory enumeration revealed the final structural failure: 255 on-premises Active Directory accounts held privileged directory roles in the cloud tenant, including two Global Administrators and a Privileged Role Administrator. These accounts were synced from on-premises AD via Entra ID Connect Sync.
The attack path to Global Administrator:
1. Compromise any of 255 on-premises AD accounts (via standard AD attack techniques: Kerberoasting, NTLM relay, AS-REP roasting, credential stuffing)
2. On-premises account → synced cloud role assignment → Global Administrator without any cloud-specific exploit
No cloud-native attack required. The on-premises AD attack surface is well-understood, and the gap between on-premises compromise and full cloud tenant takeover is a single sync cycle.
Why Storm-2372 Operationalized This at Scale
Storm-2372, a suspected Russian state-aligned threat actor tracked by Microsoft since August 2024, exploited the DRS device code flow gap across government, NGO, defense contractor, telecommunications, healthcare, and energy organizations spanning Europe, North America, Africa, and the Middle East. Their campaigns used phishing lures mimicking Microsoft Teams and other collaboration platforms to harvest device code authentication flows at industrial scale.
The Howler Cell research validates that Storm-2372's entry vector — DRS endpoint exploitation via unprotected device code flow — is not a sophisticated nation-state-only capability. It is reproducible with open-source tooling (roadtx), available credentials ($150–$600), and a Linux laptop from any internet connection.
The gap is architectural, not operational. Removing it requires policy changes, not incident response.
IOCs and Detection Indicators
Behavioral Indicators (Entra ID Sign-In Logs)
| Indicator | Log Field | Expected Pattern |
|---|---|---|
| Device code flow to DRS | AuthenticationProtocol | DeviceCodeFlow against Device Registration Service |
| Non-Windows device registering | DeviceOSType in registration logs | Linux/unknown OS in device registry |
| Missing TPM attestation claim | deviceDetail.isCompliant = true + no attestation events | Compliance without health attestation |
| Bulk directory enumeration post-registration | Microsoft Graph audit logs | High-volume /users, /groups, /servicePrincipals reads from new device |
| PRT exchange without prior compliant device posture | Entra sign-in tokenIssuerType = AzureAD with device claim but no Intune enrollment event | |
KQL Detection Queries (Microsoft Sentinel / Defender XDR)
Device code flow targeting DRS:
SigninLogs
| where AuthenticationProtocol == "deviceCode"
| where ResourceDisplayName has "Device Registration Service"
| where ResultType == 0 // successful
| summarize Count = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by UserPrincipalName, IPAddress, DeviceDetail
| where Count > 1New device registration with no TPM claims:
AuditLogs
| where OperationName == "Register device"
| where InitiatedBy.user.userPrincipalName != ""
| where AdditionalDetails has_not "TPM"
| project TimeGenerated, UserPrincipalName = InitiatedBy.user.userPrincipalName, DeviceId = TargetResources[0].idOn-premises synced Global Admins (inventory query):
IdentityInfo
| where AssignedRoles has "GlobalAdministrator"
| where OnPremisesDistinguishedName != ""
| project AccountUPN, AssignedRoles, OnPremisesDistinguishedNameLyrie Take
The Trust Chain Problem Is Systemic
The Howler Cell findings articulate something that deserves to be stated plainly: Conditional Access policies written in Report-Only mode are a compliance theater, not a security control. Organizations routinely leave policies in Report-Only for months or years because enforcement would "disrupt users." The disruption caused by a full tenant compromise is categorically different from the disruption caused by requiring MFA for device registration.
Entra ID's device trust model has a fundamental structural assumption: that the DRS API is protected by the same CA policy enforcement as standard authentication flows. It is not unless administrators explicitly configure it. The API validates tokens, not hardware. This is by design — it enables BYOD enrollment. The security implication is that without explicit CA controls on the DRS flow, any actor with valid credentials can register arbitrary devices and assert device-based claims.
This is the same gap Storm-2372 exploited. The same gap commodity IABs advertise around. The same gap sitting in most enterprise tenants with mature-looking CA policy libraries.
The NHI Parallel
The on-premises-synced Global Administrator finding maps directly to the broader Non-Human Identity (NHI) problem accelerating across 2026. Organizations are accumulating cloud identity assignments on credentials that were created, managed, and potentially compromised in on-premises AD environments predating their cloud tenants by decades. These are de facto NHIs — they authenticate without human presence, they carry cloud-tier privileges, and they are not managed through PIM lifecycle controls.
The attack surface of a modern enterprise is not the cloud perimeter. It is the identity trust chain that crosses it.
Defender Playbook: 12 Controls That Break This Kill Chain
The following controls are prioritized by kill-chain impact. Controls 1 and 2 alone would have broken the Howler Cell engagement before Step 3.
Tier 1: Kill the Entry Vector (Immediate)
Control 1 — Enforce CA032: Block Device Code Flow
Move the device code flow block CA policy from Report-Only to Enabled. This is the single highest-impact change. Before enabling, review sign-in logs for legitimate device code flow usage (kiosk devices, legacy TV apps, Azure CLI automation) and create exclusions for service principals requiring it. Timeline: 72 hours if sign-in log review is done first.
Control 2 — Enforce CA027: Require MFA for Device Registration
Require MFA when authenticating to the Device Registration Service endpoint. This forces an additional challenge even if device code flow is somehow permitted. Timeline: immediate.
Control 3 — Scope Device Registration to approved platforms only
Use device registration restrictions in Entra ID to limit registration to Windows, iOS, and Android. Reject Linux, ChromeOS, and unknown platforms unless specifically required. Use Intune Enrollment Restrictions policies to enforce this.
Tier 2: Harden the Device Trust Model
Control 4 — Require TPM 2.0 attestation as a prerequisite for PRT issuance
Configure Windows Health Attestation to require TPM 2.0. Without attestation, PRT requests from newly registered devices should fail. This blocks phantom devices that lack physical TPM chips.
Control 5 — Configure Intune compliance to treat missing attestation as non-compliant
In Intune Compliance Policies, set Require BitLocker, Require Secure Boot, and Require code integrity to Required. Set the action for non-compliance to Mark device non-compliant immediately (not after a grace period). The grace period is another bypass window.
Control 6 — Enable external Health Attestation validation
Do not rely on client-reported compliance. Configure Intune to use the Microsoft Health Attestation Service for independent validation of device health claims. This removes the self-reported compliance bypass.
Tier 3: Eliminate Lateral Escalation Paths
Control 7 — Audit and migrate synced privileged accounts
Run the KQL query above to enumerate all on-premises-synced accounts holding Entra ID privileged roles. Migrate Global Administrators, Privileged Role Administrators, and Security Administrators to cloud-only accounts. Remove privileged directory roles from synchronized accounts. This closes the on-premises-to-cloud escalation path entirely.
Control 8 — Enforce Privileged Identity Management (PIM) for all privileged roles
Move all privileged role assignments to PIM with time-bounded activation, MFA on activation, and approval workflows for Global Administrator and Privileged Role Administrator. Persistent privileged assignments should be zero.
Control 9 — Scope Microsoft Graph API access
Review and restrict user-level Graph API permissions. Standard users should not be able to enumerate the full directory. Use App Registration permission scoping and CA policies targeting the Microsoft Graph application to restrict bulk enumeration.
Tier 4: Detection and Response
Control 10 — Deploy the KQL detection queries
Implement the detection queries above in Microsoft Sentinel or Defender XDR. Alert on: device code flow to DRS, new device registration without TPM claims, bulk Graph API enumeration from recently registered devices, on-premises-synced accounts accessing cloud-privileged resources.
Control 11 — Establish a Device Registration Service monitoring baseline
The DRS endpoint is rarely a high-volume target under normal operations. Establish a baseline of device registrations per day and alert on deviations. New device registrations outside of corporate network ranges or outside business hours warrant immediate investigation.
Control 12 — Red-team your Report-Only policies quarterly
Treat every Report-Only CA policy as an unmitigated gap. Schedule quarterly reviews to either enforce them or formally document the business exception and compensating controls. A CA policy in Report-Only is not a control — it is an audit finding waiting to happen.
The CISO Conversation
The challenge with the Howler Cell findings is not that the vulnerabilities are obscure. It is that fixing them requires enforcement decisions that will break something. Enabling the device code flow block will disrupt Azure CLI users and service accounts that have been authenticating this way for years. Requiring MFA for device registration will surface devices and automation that lack it.
The choice is: accept short-term disruption to authentication workflows, or accept the risk of a full tenant compromise from a $300 IAB purchase. When framed that way, the decision is straightforward. The difficulty is that "short-term disruption" often translates to "someone files a ticket and the block gets paused indefinitely."
The Howler Cell engagement provides a concrete answer to the question "what's the worst case?" Showing a CISO the kill chain — from AADSTS53003 to Global Administrator, no malware, no endpoint, from a coffee shop — is the most effective way to move a Report-Only policy to Enabled.
Sources
1. Howler Cell / Cyderes: One Password, No Device, Full Tenant: Dismantling Azure AD Conditional Access Through Device Identity Abuse (2026) — https://www.cyderes.com/howler-cell/azure-ad-conditional-access-device-identity-abuse
2. CyberSecurityNews: Azure AD Conditional Access Bypassed Via Phantom Device Registration and PRT Abuse (May 2026) — https://cybersecuritynews.com/azure-ad-conditional-access-bypassed/
3. Microsoft Threat Intelligence: Storm-2372 Device Code Phishing Campaigns (2025) — https://www.microsoft.com/security/blog/
4. Cloud Security Alliance: Rethinking Non-Human Identity Security (April 2026) — https://cloudsecurityalliance.org/blog/2026/04/23/we-are-fixing-the-wrong-problem-in-non-human-identity-security
5. Cybersecurity Dive: Identity is the new perimeter as rapid NHI proliferation threatens visibility and control (May 2026) — https://www.cybersecuritydive.com/spons/identity-is-the-new-perimeter/819411/
6. MITRE ATT&CK: T1098.005 — Account Manipulation: Device Registration
Lyrie.ai Cyber Research Division — Senior Analyst Desk
Lyrie Verdict
Lyrie's autonomous defense layer flags this class of exposure the moment it surfaces — no signature update required.