When organizations use a hybrid identity with Entra ID, the standard playbook is to run AAD Connect, enable password hash synchronization, set up Conditional Access, and enforce MFA. Clean, logical, documented. The problem is that sequence leaves a specific class of accounts in a state that’s worse than having no cloud identity at all, and most organizations have many of them sitting in their tenant right now without knowing it.
The condition is known and simple. A user account exists in Active Directory, AAD Connect syncs it to Entra ID with password hash replication, but the user has never actually authenticated to any Entra ID, so they’ve never been prompted to register an MFA method.
From an Entra ID standpoint, the account remains fully valid, including under Conditional Access controls. A gap in registration enforcement leaves the account without any registered authenticator, so there is nothing to challenge. The password is sufficient, no second factor is configured, and an attacker who identifies this condition does not need to bypass MFA. They can simply perform the registration themselves and take control.
Why is a password still important, especially in the era of advanced methods? Because many human and non-human objects synced to the cloud with weak passwords, and the strong authentication method is waiting for someone to register from any location.
The state of the password attacks is very interesting with The 90-Day Siege: Inside a Global Campaign.
How the Dormant Account Gets Created Without Anyone Noticing
The moment is when this happens. AD Connect sync runs, accounts get provisioned in Entra ID, and licensing gets assigned. The IT team checks the boxes: sync is running, users are in the tenant, and Conditional Access policies are configured. What doesn’t get checked is which of those accounts have actually completed cloud authentication and MFA registration versus which ones are provisioned but untouched.
Users who work exclusively on-prem, against on-prem resources, on-prem file shares, and legacy applications have no reason to ever trigger a cloud login. They authenticate to their workstation via Kerberos. They never open a browser to portal.microsoft.com. They never get pushed through the registration flow that would have locked down their account with a second factor.
In hybrid environments undergoing transition, where a cloud-first strategy intersects with legacy infrastructure, it is common to observe a dangerously large portion of identities in a weak security posture. Synced accounts are integrated into Entra seamlessly, credentials remain valid, but multi-factor authentication is never registered.
Finance teams continue to rely on legacy ERP systems, manufacturing operators authenticate from shared endpoints, and long-tenured employees operate on habit without being re-onboarded to modern identity controls. The outcome is an expanded attack surface comprising fully authenticated identities operating without second-factor enforcement.
From an adversary perspective, this represents not background noise but a clear and scalable opportunity.
What the Attack Actually Looks Like
The attacker doesn’t need anything sophisticated. They get a password via a spray, a phishing attack, a credential dump from a breached database, or a straightforward purchase on a forum. They try it against Entra ID. It works.
Entra ID responds with an MFA challenge, but since the account has no registered method, it also presents the option to register a new one. The attacker registers their own authenticator app. From that moment, they have both the credential and the MFA factor. The account is fully theirs.
The legitimate user finds out one of two ways: they eventually try to log into a cloud service themselves and find their account in an unexpected state, or they get a notification email about new security info being registered, which frequently lands in a mailbox they don’t check because they’ve been working on-prem. In practice, this means the attacker can operate in that account for days or weeks without triggering any alarm that the user will actually see.
What makes this particularly clean from an attacker’s perspective is that the Entra sign-in log shows a successful authentication with MFA satisfied. No risk flags, no impossible travel if they used a residential proxy, no anomalous sign-in behavior that Identity Protection will score highly. The MFA registration event lands in the audit log under “Security info registration,” and unless someone has a specific detection rule watching for first-ever cloud authentication immediately followed by MFA registration from a new device, it reads like normal onboarding activity.
What could be the attack scenarios? Check the How Attackers Exploit This Gap section.
No Slack account needed.
The Detection Signal Is Narrow and Specific
The sequence that identifies this attack is not complicated, but catching it requires joining two log sources that most teams treat separately: the Entra sign-in log and the Entra audit log, specifically the “Authentication methods” audit category.
The pattern is: a first-ever successful cloud authentication for an account, followed within a short window (usually under ten minutes) by a security info registration event for that same account, originating from a device with no prior Entra registration history.
The signal that distinguishes this from a legitimate new-employee setup is the AD account age. A genuine new hire who has completed cloud onboarding has an AD account created recently, typically within days of the authentication event. A dormant synced account triggering this pattern has an AD account that is months or years old, with no prior cloud sign-in history. That mismatch, old account, first cloud login, immediate MFA registration, is the actual indicator.
Closing the Gap Requires More Than a Policy Change
The instinct is to add a Conditional Access policy that blocks authentication until MFA registration is complete. That logic is backward. The registration gap is the vulnerability: CA policy enforcement that depends on MFA being registered doesn’t help an account with no registered method, because the attacker is exploiting the registration moment itself.
The right intervention is pre-emptive. Before a synced account can be authenticated against Entra ID, MFA registration must be enforced via a controlled channel, either through a temporary access pass issued by IT or through a registration campaign that validates the user’s identity before providing a registration link. Microsoft’s Temporary Access Pass exists precisely for this scenario: it lets a user complete MFA registration through a time-limited, phishing-resistant credential that can be issued out-of-band, without relying on a password that may already be compromised.
The operational reality is that most organizations haven’t done this retroactively for their existing synced accounts. Running a query against your Entra ID user population to find accounts with no registered authentication methods, and cross-referencing them with accounts with no prior sign-in activity, gives you the actual exposure list. The number is usually uncomfortable.
The dormant synced account is not a configuration error or a design flaw in AAD Connect. It’s a predictable outcome of migrating identity infrastructure in stages across a workforce that doesn’t adopt cloud tools uniformly. The architecture created it, and the architecture needs a deliberate remediation pass to close it. Until that happens, every one of those accounts is one password away from being fully compromised, with MFA working exactly as designed.
The Hidden MFA Gap in Hybrid Active Directory
If your organization runs a hybrid Active Directory environment with Azure AD Connect syncing identities to Microsoft Entra ID, there is a dangerous security gap you need to be aware of. It sits at the intersection of on-premises password management and cloud MFA registration, and attackers are actively exploiting it.
This post walks through the technical details of hybrid identity sync, shows you exactly where the gap exists at the attribute level, demonstrates how attackers exploit it in four real-world scenarios, and provides the detection queries and mitigation controls to close it.
Hybrid Identity Sync
Most enterprise environments today operate in hybrid mode: user accounts reside in on-premises Active Directory, and Azure AD Connect synchronizes them with Microsoft Entra ID (formerly Azure AD) to enable access to cloud services. The most common sync method is Password Hash Sync (PHS), where a hashed representation of the on-prem password is pushed to Entra ID on a 30-minute delta cycle.
This sync handles a lot of identity state: user objects, group memberships, password hashes, account enabled/disabled status, and the password change flag. But here is the critical detail that creates the security gap:
What Syncs from On-Prem to Cloud
- User objects (UPN, display name, attributes)
- Group memberships
- Password hashes (PHS – hashed hash, not cleartext)
- Account enabled/disabled state (userAccountControl syncs to accountEnabled)
- Password change flag (pwdLastSet = 0 syncs to forceChangePasswordNextSignIn = true)
What Does NOT Sync
- MFA registration (Entra-only, no AD attribute exists)
- forceChangePasswordNextSignInWithMfa (Entra-only, set via Graph API)
- Conditional Access policies (cloud-only)
- Authentication methods (cloud-only)
This asymmetry is the root of the problem, on prem AD controls the password while the cloud controls MFA enforcement and there is no bridge between them.
TIP: AAD Connect syncs password hashes every 2 minutes on change, but the delta sync for other attributes runs every 30 minutes. If you disable an account in AD, the cloud account stays active for up to 30 minutes unless you force a sync with Start-ADSyncSyncCycle -PolicyType Delta. During an incident, those 30 minutes are an eternity.
Identifying Synced Users Without MFA
The first step in closing this gap is identifying which of your synced users have never registered for MFA. There are several methods, each suited to different operational contexts.
Method A: Microsoft Graph API
The most direct approach. This single API call returns every user who has not completed MFA registration:
GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails
?$filter=isMfaRegistered eq false and userType eq 'member'Method B: PowerShell (Microsoft Graph Module)
For bulk export and reporting, the PowerShell approach lets you pull the full registration details and export to CSV:
The script is located here: https://github.com/guardzcom/security-research-labs/tree/main/Research/M365/Dormant
INSIGHT: The Graph API userRegistrationDetails report requires Entra ID P1 license and can take up to 24 hours to populate after activation. If you need results immediately, query each user’s authentication/methods endpoint directly – it works on all license tiers and returns live data with zero delay.
Method C: Entra ID Portal
For a quick visual check:
- Entra ID -> Protection -> Authentication methods -> User registration details
- Filter: MFA capable = No
- Check for cross reference with Synced from on-premises
The Hybrid Identity Attribute Checklist
Managing a hybrid environment means managing attributes across two identity systems that don’t share the same data model. Some attributes sync, some don’t, and the gaps between them are where attackers operate. This checklist organizes every attribute that matters by impact level.
Tier 1: Authentication and Access Control
These are the attributes that directly control whether a user can authenticate. Breaking any of these breaks everything.
| Attribute | AD Value | Syncs To (Entra) | Why It Matters |
| userAccountControl | Bitmask (512, 514, etc.) | accountEnabled | Master kill switch – controls if user can auth anywhere |
| pwdLastSet | FILETIME or 0 | forceChangePasswordNextSignIn | 0 = must change password. Controls password expiry timing |
| Password hash (NT) | MD4 hash (internal) | PHS hash (PBKDF2) | The actual credential – syncs every 2 min on change |
| userPrincipalName | [email protected] | userPrincipalName | Login identifier – wrong UPN = can’t sign in |
| accountExpires | FILETIME or never | accountExpires | Hard cutoff date – account stops working after this |
Tier 2: Identity Anchor and Matching
These attributes maintain the link between on-prem and cloud. Breaking them doesn’t lock the user out – it disconnects their identity entirely.
| Attribute | AD Value | Syncs To (Entra) | Why It Matters |
| objectGUID | Binary GUID (auto) | Fallback anchor | Cannot be changed. First-time sync anchor if ConsistencyGuid empty |
| ms-DS-ConsistencyGuid | Binary (set by AAD Connect) | onPremisesImmutableId | Primary sync anchor – if broken, user delinks from cloud identity |
| sAMAccountName | Pre-Win2000 name | onPremisesSamAccountName | Legacy identifier – some apps still use this |
| objectSID | Security Identifier | onPremisesSecurityIdentifier | Used for Exchange hybrid, SharePoint claims |
Tier 3: Profile and Contact
These attributes populate the Global Address List, Teams profiles, and SharePoint. Incorrect values cause visible user-facing issues but don’t block authentication.
| Attribute | AD Value | Syncs To (Entra) | Why It Matters |
| displayName | Full name | displayName | Shows in GAL, Teams, SharePoint |
| Primary email | Routing address – wrong = email breaks | ||
| proxyAddresses | SMTP:, smtp: | proxyAddresses | All email aliases – Exchange hybrid depends on this |
| givenName / sn | First / Last name | givenName / surname | Profile display |
| department / title | Org info | department / jobTitle | Used in dynamic groups, CA policies |
| manager | department/title | manager | Org chart, approval workflows |
| telephoneNumber | Phone | businessPhones | MFA fallback (if phone auth enabled) |
Tier 4: Group and Authorization
Group memberships drive role-based access, Conditional Access policy targeting, license assignment, and application access. A wrong group membership can grant or revoke access to entire applications.
| Attribute | AD Value | Syncs To (Entra) | Why It Matters |
| memberOf | Group DNs | Group membership | Drives RBAC, CA policies, licensing, app access |
Tier 5: Cloud-Only Gaps (Does NOT Sync)
These are the attributes that exist only in Entra ID with no on-prem AD equivalent. This is where the security gap lies, but defenses against credential abuse exist only in the cloud.
| Entra Property | AD Equivalent | Gap |
| isMfaRegistered | None | MFA is cloud-only with no AD visibility |
| authenticationMethods | None | What MFA methods are enrolled and invisible to AD |
| forceChangePasswordNextSignInWithMfa | None | Can only be set via Graph API |
| Conditional Access policies | None | CA policies are cloud-only |
| signInActivity | lastLogonTimestamp (partial) | AD tracks on-prem logon, not cloud sign-in |
| riskLevel / riskState | None | Identity Protection is cloud-only |
To enumerate all enabled users with their sync anchors on the Domain Controller:
The script is located here: https://github.com/guardzcom/security-research-labs/tree/main/Research/M365/Dormant
The Identity Bridge with ms-DS-ConsistencyGuid
When investigating hybrid identity incidents, you will inevitably encounter the ms-DS-ConsistencyGuid attribute. This is the sync anchor that ties an on-prem AD object to its Entra ID counterpart. Understanding how to convert between its different representations is essential for forensic correlation.
ms-DS-ConsistencyGuid is an Active Directory attribute that serves as the Source Anchor — the
immutable identifier that permanently links an on-premises AD user object to its corresponding Entra
ID object. It is the single most critical attribute in hybrid identity because it defines “this AD
user IS this Entra ID user.”
Why does this matter for the MFA gap? The ms-DS-ConsistencyGuid is what enables the “synced but no MFA” problem. It creates the bridge that carries the password from AD to Entra, but there is no
equivalent bridge for MFA. The anchor syncs identity, the password hash syncs authentication, but MFA
registration lives entirely in the cloud with no backlink to AD.
How the Formats Relate
Take a sample ConsistencyGuid with hex value: D5 E2 D6 28 68 63 5A 4D B6 71 D5 2B 30 17 26 80
| Format | Value |
| Raw Hex | xxxxxxxxxxxx52B30172680 |
| GUID (Microsoft/Little-Endian) | xxxxxxxx-xxxx-xxxx-xxxx-d52b30172680 |
| GUID (Big-Endian) | xxxxxxxx-xxxxx-xxxx-xxxx-d52b30172680 |
| ImmutableId (Base64) | XXXXXXXXXXk22cdUrMBcmgA== |
A common point of confusion: Microsoft stores GUIDs in mixed-endian format. The first three groups are little-endian, the last two are big-endian. So, the raw hex D5E2D628 becomes the GUID 28D6E2D5 (bytes reversed). The ImmutableId in Entra ID is always the raw bytes Base64-encoded with no endian conversion applied.
Practical Lookup Commands
To find a user in Entra ID using the ImmutableId:
Get-MgUser -Filter “onPremisesImmutableId eq ‘xxxxxxxx2cdUrMBcmgA=='”
To find the corresponding on-prem AD object:
Get-ADUser -LDAPFilter “(msDS-ConsistencyGuid=\d5\e2\d6\28\68\63\5a\4d\b6\71\d5\2b\30\17\26\80)”
# Find all users who must change password at next logon
Get-ADUser -Filter {pwdLastSet -eq 0 -and Enabled -eq $true} -Properties pwdLastSet, userAccountControl |
Select-Object Name, SamAccountName,
@{N='pwdLastSet';E={$_.pwdLastSet}},
@{N='UAC';E={$_.userAccountControl}}Insight: UAC 512 is the “everything works” state. It means the account is enabled, the password hash flows from AD to Entra via PHS, and cloud authentication succeeds with that hash. Every defensive control (MFA,
CA, sign-in risk) sits after the PHS password validation step. If MFA isn’t registered, there’s nothing between “password correct” and “access granted” except the registration interrupt, which, as we showed, the attacker can complete themselves.
Entra ID
| Property | Graph API Field | Must Change Pwd | MFA Not Registered |
| Force password change | passwordProfile.forceChangePasswordNextSignIn | true | – |
| Force with MFA | passwordProfile.forceChangePasswordNextSignInWithMfa | – | true |
| MFA registered | isMfaRegistered | – | false |
| MFA capable | isMfaCapable | – | false |
| Methods registered | methodsRegistered | – | [] (empty) |
| Default MFA method | defaultMfaMethod | – | “none” |
| Account enabled | accountEnabled | true | – |
| On-prem sync | onPremisesSyncEnabled | true | – |
Querying the State via Graph API
Check the password profile:
GET https://graph.microsoft.com/v1.0/users/{userId}
?$select=displayName,userPrincipalName,accountEnabled,
passwordProfile,onPremisesSyncEnabled,
lastPasswordChangeDateTimeCheck MFA registration:
GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails
?$filter=userPrincipalName eq '[email protected]'Side-by-Side Comparison
| State | Active Directory | Entra ID |
| Must change password | pwdLastSet = 0 | passwordProfile.forceChangePasswordNextSignIn = true |
| Must change password with MFA | (no AD attribute) | passwordProfile.forceChangePasswordNextSignInWithMfa = true |
| MFA not registered | (no AD attribute) | isMfaRegistered = false |
| MFA not capable | (no AD attribute) | isMfaCapable = false |
| No methods enrolled | (no AD attribute) | methodsRegistered = [] |
| Default MFA method | (no AD attribute) | defaultMfaMethod = “none” |
| User enabled | userAccountControl = 512 | accountEnabled = true |
| User disabled | userAccountControl = 514 | accountEnabled = false |
| Sync anchor | ms-DS-ConsistencyGuid (binary) | onPremisesImmutableId (Base64) |
| Last password change | pwdLastSet (FILETIME) | lastPasswordChangeDateTime (ISO) |
INSIGHT: Many admins assume that setting forceChangePasswordNextSignIn = true also forces MFA registration. It does not. These are two independent flags. You must set forceChangePasswordNextSignInWithMfa separately via Graph API and even then, if no CA policy protects the registration flow, an attacker with the password can complete both steps themselves.
How Attackers Exploit This Gap
Now we get to the dangerous part. What happens when an attacker compromises the password of a user who is required to change their password and register MFA, but has not yet done so?
The answer depends on how the attacker authenticates and what Conditional Access policies are in place.
Scenario 1: Interactive Browser Login (Full Account Takeover)
This is the most common and most devastating scenario:
Scenario 1: Interactive Browser Login – Full Account Takeover
This is a full account takeover. The “must register MFA” interrupt, which was designed to improve security, actually becomes a self-service enrollment portal for the attacker. They get to register their own Authenticator app and set their own password. The legitimate user is completely locked out.
Scenario 2: Legacy Protocol / ROPC (Silent Access)
If legacy authentication protocols are not blocked:
Attacker -> ROPC / legacy auth -> token endpoint
If legacy auth is BLOCKED by CA policy:
-> Error 53003 (blocked by Conditional Access)
-> Attacker stopped
If legacy auth is ALLOWED (no CA blocking it):
-> ROPC flow SKIPS the MFA interrupt entirely
-> May skip the force-password-change too
-> Password-only access to mailbox (Exchange, etc.)
-> No MFA ever triggered
The ROPC (Resource Owner Password Credential) flow and other legacy protocols like IMAP, POP3, and SMTP AUTH bypass the interactive login flow entirely. If Conditional Access does not explicitly block these protocols, the attacker gets silent, password-only access to the mailbox without ever triggering an MFA prompt.
Scenario 3: AiTM Proxy
Adversary-in-the-Middle frameworks like Evilginx and EvilnoVNC proxy the legitimate login page:
Attacker -> AiTM proxy -> login.microsoftonline.com
Step 1: Credentials entered through proxy
-> Password validated
Step 2: MFA Registration Interrupt
-> Proxy forwards the registration page
-> Attacker registers their MFA through the proxy
Step 3: Password change
-> Attacker changes password through the proxy
Step 4: Proxy captures session token + refresh token
-> COMPLETE TAKEOVER + TOKEN THEFT
The AiTM proxy transparently forwards every page, including the MFA registration interrupt. The attacker completes the full flow while simultaneously capturing session tokens for persistent access, even if the password is later reset.
Scenario 4: Conditional Access Protects Registration (Best Case)
This is the only scenario where the attack is stopped:
Attacker -> spray -> login.microsoftonline.com
Step 1: Password validated
Step 2: MFA Registration Interrupt triggers
-> CA Policy: “MFA registration only from trusted locations/compliant devices.”
-> Error 53003 – blocked by CA
-> Attacker CANNOT register MFA from an untrusted network
-> Attacker stopped (but they confirmed the password works)
Sign-in log shows:
Error 50074 (MFA required) -> 53003 (CA blocked)
This CONFIRMS the password is compromised
The attacker is blocked from completing MFA registration, but note: they have still confirmed that the password is valid. Your sign-in logs will show this sequence, and it should be treated as a confirmed credential compromise requiring an immediate password reset.
Kill Chain Summary
Attack Kill Chain: Password Compromised + MFA Not Registered
TIP: In Scenario 1, the attacker completes MFA registration BEFORE the password change. This means the Entra audit log will show an MFA method registration event in which the old (compromised) password remains active. Hunt for Register security info audit events where the IP address does not match the user’s historical sign-in locations – that is your smoking gun.
Detection: Sign-In Log Error Codes
When investigating potential exploitation of this gap, these are the Entra ID sign-in error codes that tell the story:
| Error Code | Meaning | What It Tells You |
| 0 (followed by MFA registration) | Success + registration | Someone registered MFA – verify legitimacy |
| 50072 | MFA registration interrupt | User has no MFA, being asked to register |
| 50074 | MFA required | Password was correct, MFA challenge issued |
| 50055 | Password expired / must change | Force change flag triggered |
| 53003 | Blocked by Conditional Access | CA policy stopped the flow |
| 500121 | MFA denied / failed | MFA challenged but not completed |
Pay special attention to sequences where 50072 (registration interrupt) is followed by a successful 0 from an IP address or location that does not match the user’s normal patterns. That is a potential attacker completing MFA registration with a stolen password.
INSIGHT: Error code 50074 alone does NOT confirm password compromise. It also fires for every legitimate MFA login. The signal is 50074 from an IP that never appeared in the user’s history before, especially combined with 50072 (registration interrupt). Cross-reference the IP against the user’s baseline sign-in locations before declaring a credential compromise.
Closing Summary
Hybrid Active Directory is the backbone of enterprise identity for most organizations. Azure AD Connect bridges on-premises and cloud, syncing passwords, account state, and group memberships with remarkable reliability. But it was designed to extend identity, not to extend security policy. The result is an architectural blind spot: the credential travels from AD to Entra, but the controls that protect it – MFA, Conditional Access, risk-based authentication – exist only in the cloud with no feedback loop to the source.
This creates a class of users who are fully authenticated but completely unprotected: synced, enabled, password in the cloud, no MFA registered. Every one of them is a single password spray away from a full account takeover – not because the system is broken, but because the defense was never wired into the sync.
What MSP Should Do Right Now
| Priority | Action | Impact |
| Immediate | Run the MFA audit script from this post. Identify every synced user with isMfaRegistered = false. | Know your exposure |
| This week | Create a Conditional Access policy protecting MFA registration. Target “Register security information” and require a trusted location or compliant device. | Block attacker self-enrollment |
| This week | Block legacy authentication protocols (ROPC, IMAP, POP3, SMTP AUTH) via Conditional Access. | Close the silent mailbox access path |
| This month | Deploy Temporary Access Pass (TAP) for onboarding. Pre-provision MFA instead of relying on self-service registration. | Eliminate the registration interrupt as an attack vector |
| This quarter | Evaluate FIDO2 / passwordless authentication. | Remove the password from the equation entirely |
The Bottom Line
The MFA registration interrupt was designed to help users. In the hands of an attacker with a valid password, it becomes a self-service account takeover portal. The fix is not complex – a single Conditional Access policy protecting the registration flow changes the outcome from “full compromise” to “attacker blocked.” But you have to know the gap exists before you can close it.
Audit your synced users today. The ones without MFA are your most exposed accounts, and they are exactly the ones attackers are looking for.
More Articles
All scripts are located here https://github.com/guardzcom/security-research-labs/tree/main/Research/M365/Dormant
