The cloud may be modern, but the trust it inherits often lives on-premises.
Executive TL;DR
Hybrid identity lets organisations manage on-premises and cloud access through one connected identity architecture. That convenience comes at a cost: the two environments may no longer act as separate security boundaries.
An attacker who compromises the synchronisation, federation, or authentication systems linking Active Directory to Microsoft Entra ID may:
- Turn local administrative access into cloud access.
- Impersonate synchronised users without touching their cloud accounts directly.
- Abuse trusted authentication assertions or connector credentials.
- Establish cloud persistence that survives an on-premises password reset.
- Move between environments while each security team sees only part of the attack.
The real question is not whether hybrid identity is inherently insecure. It’s whether your organisation has tested how much authority its on-premises identity infrastructure holds over the cloud.
The Dangerous Assumption: The Cloud Is a Separate Security Boundary
Moving applications and data into the cloud doesn’t separate them from on-premises risk.
In a hybrid identity environment, Microsoft Entra ID trusts Active Directory to handle key identity decisions. Microsoft identifies federation and account synchronisation as the two primary paths from an on-premises compromise to cloud administrative access.
That changes what the security boundary actually means.
The cloud brings stronger authentication, richer telemetry, and more adaptive access controls. But those controls only work if the identity decisions feeding them can be trusted. When Entra ID accepts a decision from an on-premises system, its strength depends on that system’s integrity.
The most consequential hybrid identity attack, then, may never touch the cloud at all. It starts by compromising what the cloud already trusts.
The Identity Bridge Is Also an Authority Bridge
Microsoft Entra hybrid identity commonly relies on three authentication models:
| Authentication model | What the cloud trusts | Principal attack surface |
| Password Hash Synchronisation | Password data synchronised through Entra Connect | Synchronisation host, connector accounts, and object authority |
| Pass-Through Authentication | On-premises agents validating cloud sign-ins | Agent host, service process, and authentication flow |
| Active Directory Federation Services | On-premises infrastructure issuing signed assertions | Federation servers, configuration databases, and signing keys |
MITRE classifies attacks on these systems under Hybrid Identity: T1556.007. The technique covers modifying authentication agents, changing federation settings, and tampering with token-signing configurations.
These architectures work differently, but they share one trait: each concentrates identity authority in the systems connecting the two environments.
In hybrid identity, authority does not always come from the role displayed next to an account. It can come from the relationship that account, system, or credential controls.
An attacker therefore doesn’t need to compromise hundreds of cloud accounts. Compromising the system that manages or authenticates them can be far more effective.
Compromising the Synchronisation Layer
The Sync Server as an Identity Control Plane
Teams often treat the Entra Connect server as supporting infrastructure. To an attacker, it functions as an identity control plane.
The server touches privileged accounts in both Active Directory and Entra ID. Publicly available research tooling makes the risk concrete. Nestori Syynimaa’s AADInternals toolkit lets an attacker with host access extract stored connector credentials and certificate-based authentication material. Those credentials can carry serious authority on both sides of the hybrid environment.
This isn’t only a lab scenario.
The MERCURY and DEV-1084 Wake-Up Call
Microsoft documented a destructive campaign involving MERCURY and DEV-1084. The attackers accessed an Azure AD Connect system. They used AADInternals to extract the plaintext credentials of its on-premises and cloud connector accounts. A legacy connector account still held Global Administrator privileges. Within hours, the attackers used that privileged cloud access to delete server farms, virtual machines, storage accounts, and virtual networks. They also added credentials to an OAuth application and read cloud mailboxes.
The incident shows the real danger of inherited privilege.
The synchronisation server wasn’t simply transferring directory information. Its credentials opened a route from the local environment into cloud administration, leading to data access, application permissions, and destructive operations.
Treat Entra Connect systems as control-plane assets, not ordinary application servers.
When the Attacker Controls Authentication
Strong authentication only works if the systems performing and attesting to it stay trustworthy.
Pass-Through Authentication
Pass-Through Authentication sends cloud sign-in attempts to an on-premises agent, which checks the credentials against Active Directory.
MITRE notes that an attacker who compromises the agent host can inject malicious code into its authentication process. That code can capture credentials or manipulate the result. An attacker can also register an unauthorized Pass-Through Authentication agent after a cloud admin compromise. That creates another route for credential collection and impersonation.
In that scenario, the attacker doesn’t defeat the user’s password. They interfere with the system deciding whether the password is valid.
Active Directory Federation Services
Federation places even more authority in the on-premises identity provider.
AD FS signs SAML assertions with a token-signing certificate. The cloud verifies the signature and trusts the claims inside the assertion. The SAML standard itself recognizes that security depends on more than the assertion format. It also depends on protocol implementation, communications, key protection, and how systems consume the assertions.
If someone steals the token-signing private key, they can forge assertions that appear to come from the trusted federation service. Depending on the federation configuration, those assertions may impersonate users and even claim that multifactor authentication already occurred.
NSA has warned that attackers with privileged on-premises access can manipulate federated authentication to reach protected cloud resources.
Google’s threat intelligence team demonstrated something notable. Attackers could pull AD FS token-signing material through the federation replication mechanism, under specific privilege conditions. The technique cut the need for direct execution on the primary federation server, making traditional host-focused monitoring less complete.
Here’s the distinction that matters: the attacker isn’t presenting a stolen password anymore. They’re presenting authentication evidence the system was configured to trust.
Seamless Single Sign-On
Seamless Single Sign-On creates another trust link between Active Directory and Entra ID, this time through Kerberos.
CyberArk’s Golden SAML research and AADInternals’ work on Seamless SSO make one thing clear. Compromised key material can forge tickets for synchronised identities. But precision matters here: Seamless SSO replaces only the password step of authentication. On its own, it doesn’t neutralize every cloud-side multifactor authentication requirement.
Golden SAML and Seamless SSO share similar trust mechanics, but they don’t have the same effect on multifactor authentication. The original report missed that nuance. This version corrects it.
Federation Risk Is Not Only Historical
It’s tempting to dismiss federation attacks as a legacy problem tied to older architectures.
That conclusion would be wrong.
On July 14, 2026, CISA added CVE-2026-56155 to its Known Exploited Vulnerabilities Catalog. The flaw affects access control in Active Directory Federation Services.
One vulnerability doesn’t mean every federation environment is exposed. But it does prove that the systems responsible for authenticating users and protecting federation secrets remain valuable targets.
Organisations still running AD FS need answers beyond “are the servers patched.” They should know:
- Who can administer the federation farm.
- Who can access its configuration and cryptographic material.
- Which applications trust its assertions.
- Whether signing-key use and federation changes are monitored.
- How quickly the organisation can revoke and rebuild trust during an incident.
When Directory Synchronisation Becomes Account Takeover
Hybrid identity also depends on rules that decide whether an on-premises object and a cloud object represent the same identity.
Historically, those rules included soft matching through attributes like user principal names or proxy addresses. They also included hard matching through persistent object identifiers. Security research has shown that attackers with enough Active Directory write access can abuse these relationships. They can bind an attacker-controlled on-premises identity to an existing cloud account. Dirk-Jan Mollema’s research first demonstrated this technique.
Modern platform changes have closed several of these paths. That doesn’t remove the need to check older tenants, legacy matching behaviour, or role eligibility. Synchronisation scope and migration-era exceptions still deserve a look.
This matters most when synchronised accounts hold cloud privileges. Microsoft recommends that on-premises accounts never hold administrative privileges in Microsoft 365. Privileged cloud administration should run through isolated, cloud-native accounts instead.
The same principle applies to indirect privilege. An account can look harmless on paper while still holding the power to modify another identity, group, connector, application, or synchronisation rule that ultimately controls cloud access.
This is the hybrid version of a shadow administrator: the visible role may look limited, while the relationships around it create far greater effective authority.
Cloud Persistence Can Outlive the On-Premises Compromise
Moving from Active Directory into Entra ID is only the first half of the problem.
Once attackers gain cloud privileges, they can build persistence several ways. Application credentials, service principals, certificates, consent grants, authentication methods, and active sessions all work. Many of these mechanisms stay usable even after the organisation changes the password that started it all.
In the MERCURY and DEV-1084 incident, attackers added certificates and permissions to an existing OAuth app. They did this right after gaining cloud admin privileges. From there, the application could authenticate and reach cloud resources on its own — independent of the original stolen credential.
That creates a remediation trap.
An organisation might rebuild the compromised server, rotate the connector password, and remove the attacker from Active Directory. Yet a cloud application credential, token, or delegated permission can stay intact the whole time.
This connects closely to token theft and trusted sessions. Changing the original password doesn’t automatically kill every form of authority it once granted. It’s also why persistence after remediation is often an identity problem, not simply a malware problem.
Why Hybrid Identity Remediation Fails
Teams often remediate hybrid identity incidents as either an Active Directory problem or a cloud problem.
That split is operationally convenient. It’s also technically incomplete.
1. Passwords get rotated, but trust material does not
Connector credentials, token-signing certificates, Seamless SSO keys, service-principal certificates, OAuth grants, and active sessions may all need separate action.
2. Teams clean the cloud before containing the sync path
If the compromised on-premises environment remains authoritative, an attacker may continue synchronising changes or regain cloud access through the same path.
3. Privileged synchronised accounts stay active
A synchronised administrator keeps a direct link between cloud privilege and the security of the on-premises account.
4. Teams investigate telemetry in isolation
A directory change, a federation event, a cloud sign-in — each can look legitimate on its own. So can an application-credential addition or a mailbox operation.
MITRE’s hybrid identity detection guidance calls for correlating six signals: agent tampering, connector changes, federation modifications, signing-certificate updates, authentication anomalies, and cloud activity.
5. Sync gets restored before anyone understands the attack path
Containment for a compromised Active Directory environment includes several steps. Block synchronisation accounts, disable synchronised administrators, address Seamless SSO, and restrict workload identities. Do all of that before reconnecting the environments. Microsoft’s incident-response guidance backs this sequencing.
What Security Leaders Should Validate
Hybrid identity security should start with five priorities.
1. Map every trust path
Document which systems and identities can influence authentication, synchronisation, privilege, and recovery across Active Directory and Entra ID. Include synchronisation services, authentication agents, federation servers, Seamless SSO configurations, Exchange hybrid relationships, workload identities, privileged groups, and emergency access accounts.
2. Identify effective privilege, not only assigned roles
Determine which accounts, groups, connectors, applications, synchronisation rules, and administrative systems can indirectly influence privileged cloud identities.
A role assignment shows visible privilege. It does not necessarily show the full authority an identity can exercise through the relationships around it.
3. Isolate privileged cloud administration
Use dedicated cloud-native administrative identities with phishing-resistant authentication. Don’t let synchronised accounts, nested groups, or on-premises administrative software control privileged cloud roles. Microsoft Learn recommends this same separation.
4. Validate cross-environment detection
Confirm that directory replication, object changes, synchronisation activity, authentication agents, federation configuration, cloud sign-ins, application credentials, consent changes, token use, and resource access can be correlated into a complete attack sequence.
5. Test hybrid identity containment
Validate whether the organisation can separate the environments, block synchronised administrators, revoke sessions, rotate identity keys, restrict workload identities, maintain emergency administration, and recover without immediately restoring a compromised path.
Architecture reviews can document whether these controls exist. They can’t confirm whether an attacker can bypass them.
The Question Is Not Whether the Connection Works
Teams usually judge hybrid identity projects by operational outcomes:
- Can users reach the applications they need?
- Are accounts syncing correctly?
- Does single sign-on work?
- Can administrators manage identities consistently?
Those questions confirm functionality. They don’t confirm resilience.
An offensive assessment should test whether:
- Control of Active Directory can convert into Entra ID privilege.
- Connector, federation, or Seamless SSO material can be extracted.
- Synchronised objects can influence privileged cloud identities.
- Attackers can alter authentication agents or federation settings without detection.
- Application credentials or sessions stay usable after a password rotation.
- Security teams can reconstruct the full cross-environment attack path.
- The organisation can isolate the cloud before an attacker builds durable persistence.
Hybrid identity is not just an integration between two directories. It’s a chain of delegated authority.
Until someone tests that chain from an attacker’s perspective, the organisation only knows how it was designed to work. It doesn’t know how the system behaves once one side is compromised.
At wizlynx group, our offensive security assessments and adversary simulations help organisations test that chain directly. We check whether identity trust can turn into lateral movement, cloud privilege, or persistent access. We also test whether existing controls can detect and contain that transition.
Frequently Asked Questions (FAQs)
What is a hybrid identity attack?
A hybrid identity attack abuses the synchronisation, authentication, or federation relationships connecting on-premises identity to the cloud. It targets that trusted bridge instead of attacking the cloud account directly. MITRE ATT&CK catalogues this as Hybrid Identity (T1556.007).
Can multifactor authentication stop hybrid identity attacks?
MFA substantially reduces credential-based risk. But it may not stop an attack where the adversary controls the authentication agent or federation issuer. The same applies to a trusted assertion, application credential, or existing session. NSA has warned that the outcome depends on the attack path and where the authentication decision actually gets made.
Should Entra Connect be treated as a highly privileged asset?
Yes. It touches privileged identities and directory operations across both Active Directory and Entra ID. Microsoft’s own incident data confirms that compromising the host or its authentication material puts both environments at risk.
Is Active Directory Federation Services still a material risk?
Yes. Organisations still running AD FS hand substantial authentication authority to on-premises infrastructure and token-signing material. CISA added an AD FS vulnerability to its Known Exploited Vulnerabilities Catalog in July 2026. That reinforces the need for continued hardening and validation.
Which hybrid authentication model is the safest?
There is no universal answer — it depends on architecture and operational needs. That said, reducing live dependency on on-premises authentication helps. So does isolating privileged cloud identities. Together, they limit the damage from an Active Directory compromise. Microsoft recommends cloud-native administrative accounts and cloud authentication wherever feasible.
Talk to our team about validating your hybrid identity attack surface.
Co-Author Jack Yip is a Consultant at wizlynx group, specializing in Active Directory security, red teaming, and purple teaming. His work focuses on identity attack paths and adversary emulation, including Active Directory attack paths, identity security, and detection validation, with a growing focus on cloud security.
wizlynx group is a CREST-accredited offensive security company headquartered in Switzerland, operating across Europe, North America, Latin America, and Asia. wizlynx group specializes in penetration testing, red teaming, adversary simulation, social engineering, and advanced security assessments for enterprise clients.