Hybrid Identity Attack Surface: Where On-Prem AD and Entra ID Create Unexpected Risk

I was on a call with a Fortune 500 IR team when the question came out of left field: "How did they get into our Microsoft 365 environment when everything's in Azure and we don't even use on-prem Exchange anymore?"

The answer came fast: the Entra Connect sync server. The attacker had compromised that server months earlier and used the access it gave them into both environments to establish persistence, then waited.

Hybrid identity deployments create attack surfaces that don't exist in cloud-only Entra ID environments. Every sync connection, every authentication bridge, is a potential path for attackers to move between on-premises Active Directory and Entra ID.

I've seen this pattern repeatedly. Organizations deploy hybrid identity with good intentions - seamless SSO, shared password policies, gradual migration - but rarely assess the attack surface those connections create. This post is about that surface and how to defend it.

What Hybrid Identity Actually Means

Let's be clear about the components:

• Password Hash Sync (PHS): a hash of the on-prem password hash syncs to Entra ID, so cloud auth can validate the same password.
• Pass-through Authentication (PTA): authentication is validated by an on-prem agent against a domain controller.
• Federation with ADFS: on-prem AD Federation Services handles authentication and issues tokens.
• Directory synchronization: user, group, and contact objects sync between on-prem AD and Entra ID.

Each creates different security implications. The more bridges you run, the more paths there are between the two environments.

The Synchronization Attacks

Password Hash Sync Risks

The single most important fact about PHS, and the one most often missed: the on-prem connector account the sync engine uses to read password data has directory replication rights. Under express-settings deployments this account (named MSOL_ followed by a random string) is granted Replicating Directory Changes and Replicating Directory Changes All - the same rights that make DCSync possible - so it can pull password hashes for the whole domain.

That means the Entra Connect server is a Tier 0 asset. Anyone who compromises it can recover that connector account and DCSync your entire on-prem domain. This is the biggest real risk in a PHS deployment, and it's an on-prem domain compromise, not just a cloud one. Treat the Connect server exactly like a domain controller.

Beyond that, PHS creates a couple of secondary vectors:

1. Compromised sync identity: the sync engine authenticates to Entra ID using an account that holds the Directory Synchronization Accounts role - not Global Admin. (Global Admin is used only during initial setup and configuration, not for ongoing sync.) That role is still powerful and worth protecting, but be precise about what it is: it governs synchronization, and it is not a general-purpose cloud admin account.
2. Password spray on synced accounts: with a list of synced email addresses, an attacker can test passwords against both on-prem and cloud, since the same credential validates in both.

Pass-through Authentication Pitfalls

PTA looks simpler than PHS, but the agent server is a high-value target for a specific reason:

1. Cleartext password exposure: validation happens on the agent, so a compromised PTA agent server can observe the cleartext passwords passing through it during authentication.
2. Skeleton-key style bypass: an attacker with control of the agent can tamper with the validation logic so that it accepts any password for any account - a persistent authentication backdoor.
3. What the agent actually stores: the PTA agent stores a certificate used to register and authenticate itself to Entra ID - not a cache of user credentials. The danger isn't a credential store to steal; it's that whoever controls the running agent controls authentication for everyone who uses it.

Federation with ADFS

Federation is the most dangerous when misconfigured:

1. Token signing key compromise: with the ADFS token-signing key, an attacker can forge SAML tokens and authenticate as anyone (the "Golden SAML" problem).
2. Relay attacks: ADFS endpoints can be targeted, especially where TLS terminates at a load balancer before ADFS.
3. Trust exploitation: a compromised federation trust can be used to establish long-lived access.

The mistake I see most: organizations harden the ADFS farm and forget the Web Application Proxy servers in front of it. Those are often less hardened and become the entry point.

Authentication Bridge Vulnerabilities

The Seamless SSO Trap

Seamless SSO is meant to make on-prem-backed sign-in smoother. It works by creating a computer account in on-prem AD called AZUREADSSOACC$, whose Kerberos key is shared with Entra ID.

That shared key is the risk. Whoever obtains it can forge Kerberos service tickets that Entra ID will accept, and thereby sign in to Entra ID as any synced user. Be precise about what that does and doesn't mean:

1. It's an authentication forgery, not a password reset. Holding the key lets an attacker impersonate synced users at sign-in. It does not let them reset user passwords.
2. Conditional Access and MFA still apply. Forging the first factor doesn't bypass a second factor - a Conditional Access policy requiring MFA will still challenge the sign-in. This is one more reason MFA via Conditional Access is not optional in hybrid.

The AZUREADSSOACC$ key does not roll on its own. Because it functions like a long-lived shared secret, roll it regularly - and immediately if you suspect the on-prem environment was compromised - the same way you'd rotate KRBTGT.

The Delta Sync Window

Directory sync runs on a schedule (every 30 minutes by default). That cadence creates timing gaps worth understanding:

1. Stale disable state: if an account is disabled on-prem but the sync hasn't run yet, there can be a window where cloud authentication still succeeds.
2. Object manipulation: an attacker who can influence what syncs and when may be able to arrange for a backdoor object to persist while legitimate changes lag.

The window isn't large, but it's real, and it argues for alerting on sync failures and unexpected sync delays rather than treating them as routine IT noise.

The Identity Synchronization Attack Path

Here's the pattern I've seen more than once:

1. Initial access: attacker compromises a domain-joined workstation via phishing or exploit.
2. Lateral movement to the sync server: using credentials from the initial compromise, they reach the Entra Connect server - often under-secured because it's treated as "just a sync server."
3. Credential access: on that server they recover the on-prem connector account (the MSOL_ account) and the Entra-side sync identity.
4. On-prem domain compromise: the connector account's replication rights let them DCSync the domain - full on-prem credential theft, including KRBTGT. This alone is a domain-wide compromise.
5. Cloud reach and persistence: the Directory Synchronization Accounts identity lets them tamper with synchronization; combined with on-prem control they work to establish durable access across both environments, and may disable sync to slow detection.

The key insight: hybrid identity turns a single point of compromise into a two-domain compromise. Once you own the sync server, you have a route into both environments - and the on-prem DCSync path is the fastest way to Tier 0.

Detection Gaps I Consistently Find

Organizations often have solid detection for on-prem AD and separate detection for Entra ID, but the seam between them is where attackers live.

Missing Cross-Domain Correlation

• Password/credential events on the sync server not correlated with Entra ID sign-in and change events.
• Authentication anomalies in Entra ID that should trigger checks on the on-prem side.
• Sync failures not investigated as potential attack indicators - I've seen sync disabled for weeks before anyone noticed.

Weak Sync Infrastructure Protection

• The Connect server not treated as Tier 0, despite the connector account's replication rights making it equivalent to a domain controller.
• No monitoring on sync identity activity, on either the on-prem or Entra side.
• Credentials or administrative access shared between the sync server and general IT management.

Inconsistent Authentication Policies

• On-prem MFA required but cloud access not enforcing it.
• Different password policies between environments.
• Missing session controls for hybrid-authenticated users.

Mitigation Priorities

Priority 1: Secure the Sync Infrastructure as Tier 0

• Treat the Entra Connect server as a domain controller. Dedicated hardware or VMs, isolated from other workloads, administered only from privileged access workstations.
• Do not weaken or "clean up" Connect's default permissions. The connector account needs the rights it has; the answer is to protect the server that holds it, not to try to strip rights the product depends on.
• Network segmentation - the sync server should talk only to domain controllers and the required Microsoft endpoints.

Priority 2: Monitor the Bridges

• Sync server access - alert on any logon to the Connect server, especially interactive ones.
• Sync health - alert on unexpected sync failures or delays.
• Authentication bridges - log all PTA agent and ADFS/WAP access.

Priority 3: Enforce Consistent Controls

• Conditional Access for all users, regardless of authentication method.
• MFA enforced at the Entra ID level, not just on-prem - this is what still stands between a forged first factor (e.g. via Seamless SSO key theft) and a successful sign-in.
• Regular access reviews for hybrid identity configurations.

Priority 4: Keep Privileged Roles Out of the Sync Path

• Privileged Entra roles should be held by cloud-only accounts, never by synced accounts. If your Global Admins and other privileged cloud roles are synced from on-prem, then an on-prem compromise (which the sync server makes very reachable) becomes a cloud admin compromise. Cloud-only privileged accounts break that chain.
• Roll the AZUREADSSOACC$ key on a schedule and after any suspected on-prem compromise.

Priority 5: Test Your Assumptions

• Breach simulation: verify whether compromising the sync server actually yields on-prem DCSync and cloud access in your environment.
• Authentication path mapping: document every bridge and confirm it's necessary.
• Fallback testing: what happens to authentication if the sync or agent servers go down?

The Bottom Line

Hybrid identity is often deployed as a transitional state, but many organizations stay hybrid indefinitely without reassessing the attack surface they've created.

The critical question isn't "Do we need hybrid identity?" It's "What attack paths have we created by maintaining these bridges - and which of our servers are secretly Tier 0 because of them?"

If you're in hybrid, audit your authentication bridges. Document what syncs, how it syncs, and what would happen if each component were compromised. Then assume attackers have found those bridges, and design your detection and response around that assumption.