On paper, Exchange Hybrid deployments make perfect sense: they let organizations run on-premises Exchange and Exchange Online side by side, migrating at their own pace. In practice, they create a tight coupling between two environments that should remain logically separate. That coupling, implemented through Azure AD Connect, has quietly become one of the most underestimated attack paths in hybrid Microsoft architectures.
What Azure AD Connect Actually Does Under the Hood
Azure AD Connect synchronizes identities from on-premises Active Directory to Entra ID (formerly Azure AD). To do its job, it relies on two high-privileged service accounts: an AD DS Connector account with replication rights on the local directory — equivalent to DCSync permissions — and a cloud-side account with write access to synchronized objects.
In an Exchange Hybrid configuration, the AD schema is extended to support mail-related attributes. The sync account gains additional permissions to manage those attributes, broadening its footprint further. The practical implication: an attacker who compromises the server running Azure AD Connect effectively controls both environments at once.
The Attack Path: From On-Prem Compromise to Tenant Escalation
Consider a realistic scenario. An attacker gains an initial foothold through a phishing email, compromises a workstation, then pivots to a poorly segmented file server. From there, they escalate to local admin on the Azure AD Connect server — frequently installed on a domain member, sometimes even on a secondary domain controller.
Extracting Sync Credentials
The publicly available tool AADInternals can extract the sync account credentials directly from Azure AD Connect's local database (the ADSync SQL database). The encrypted password for the cloud-side account is stored locally and can be decrypted using keys also stored on that same machine. No suspicious network traffic is required at this stage, which makes detection particularly difficult.
Escalating into the Entra ID Tenant
With those credentials, the attacker authenticates against Microsoft's synchronization API. The sync account holds enough permissions to reset passwords for non-admin cloud users and, in many configurations, to modify sensitive attributes such as onPremisesImmutableId. This allows linking a cloud account to an attacker-controlled on-premises identity. If any Global Administrator account is synced from the local AD rather than being cloud-only, the pivot becomes a direct path to the highest privilege level in the tenant.
Persistence and Lateral Movement in the Cloud
Once inside the tenant, the attacker can register an OAuth application, add credentials to an existing service principal, or promote an account to Global Admin. All of these actions generate entries in the Entra ID Audit logs — but only matter if someone is actually monitoring them. In environments without active security monitoring, this phase often goes undetected for weeks.
Why Exchange Hybrid Makes This Worse
Without Exchange Hybrid, Azure AD Connect can operate with a fairly minimal permission set. Once the Hybrid role enters the picture, Microsoft's own requirements call for additional write permissions on AD objects to synchronize mail attributes — including rights over security groups and entire organizational units.
The on-premises Exchange server itself also receives elevated permissions during hybrid role installation. The Exchange Trusted Subsystem group has historically held WriteDACL rights over broad swaths of the AD, making it a natural stepping stone for any attacker trying to reach Domain Admin — and from there, Azure AD Connect.
Recommended Hardening Measures
Microsoft does document mitigations for these risks, but they require deliberate implementation. None of them are enabled by default.
Isolate the Azure AD Connect Server
The AD Connect server should never be a domain controller. It should sit on a dedicated network segment with tightly controlled inbound flows — only what's necessary for LDAP and Kerberos toward domain controllers, plus outbound HTTPS to Microsoft endpoints. All administrative access should go through a jump server and be fully logged.
Use Group Managed Service Accounts
Recent versions of Azure AD Connect support group Managed Service Accounts (gMSA) for the AD DS Connector account. This removes manual password management entirely and makes credential extraction significantly harder. The option must be explicitly chosen during setup or migration — it doesn't apply retroactively to existing installations.
Keep Privileged Accounts Cloud-Only
Any account assigned a privileged Entra ID role — Global Admin, Privileged Role Administrator, and similar — must be a cloud-only account, never synced from on-premises AD. Microsoft states this clearly in its security guidance. In practice, it's one of the most commonly violated rules in organizations that migrated incrementally.
Clean Up Exchange Permissions in AD
Microsoft provides a PowerShell script (ReduceExchangePermissions.ps1) to remove the WriteDACL rights granted to Exchange Trusted Subsystem on non-mail AD objects. This cleanup should be tested thoroughly in a staging environment first — some hybrid mail flows may depend on permissions that get removed.
Monitor the Right Events
On-premises, DCSync-style replication events (Event ID 4662 with DS-Replication-Get-Changes-All) should trigger an immediate alert. On the cloud side, any unusual sign-in activity from the sync account, or any Global Admin role assignment, warrants a dedicated detection rule in Microsoft Sentinel or your cloud SIEM of choice.
What This Means for Your Security Posture
A hardened Exchange Hybrid deployment is entirely achievable — but it requires an explicit review of inherited permissions, network segmentation work that goes well beyond the installation documentation, and continuous monitoring of both control planes. The recurring mistake is treating cloud security and on-premises security as separate domains. In a hybrid deployment, they form a single security perimeter, with every blind spot that entails.
Frequently asked questions
Is Azure AD Connect inherently dangerous?
Not by design, but by nature: it bridges two environments with different trust levels. The risk comes from how it's deployed and protected, not from the product itself. A poorly isolated AD Connect server with excessive permissions and no monitoring does become a major attack vector.
Does migrating fully to Exchange Online eliminate this risk?
Only partially. Even after a full migration, the permissions granted to Exchange Trusted Subsystem and the sync account remain in place unless they are explicitly revoked. A cloud migration does not automatically clean up the on-premises AD.
What tools can detect exploitation of this attack path?
On-premises, Microsoft Defender for Identity detects DCSync attacks and anomalous behavior from the AD DS Connector account. On the cloud side, Microsoft Sentinel with Entra ID Audit and Sign-In Log connectors enables monitoring of sync account activity and unusual privilege escalations.
Can a small organization without a SOC secure a hybrid configuration?
Yes, with a minimal but targeted approach: isolate the AD Connect server, enable gMSA for service accounts, and ensure no Global Admin account is ever synced from on-premises AD. These three controls, properly applied, dramatically shrink the attack surface without requiring a dedicated security team.