Hybrid Identity Under Attack: Securing the Bridge Between On-Prem AD and Entra ID

Most organizations think of their on-premises Active Directory and Entra ID (formerly Azure AD) as two separate security domains. They are not. The moment you deployed Entra Connect, you created a single security boundary that spans both environments. A compromise of that boundary means a compromise of both. That server running Microsoft Entra Connect — the one sitting in a rack somewhere, probably with limited monitoring and no Tier 0 treatment — is now one of the most privileged machines in your entire organization. Attackers know this. Most security teams do not.

The threat is not theoretical. In September 2024, Microsoft reported that the Storm-0501 ransomware group specifically targeted Entra Connect servers to extract Directory Synchronization Account credentials. Using those credentials, they authenticated to Microsoft Graph and reset passwords for hybrid accounts across the tenant — gaining persistent cloud access without touching a domain controller directly. This is the playbook your adversaries are reading. Here is what you need to know to stop them.

The Architecture: What Entra Connect Actually Does

Entra Connect (formerly Azure AD Connect) synchronizes identities from on-premises Active Directory to Entra ID. It runs as a service on a Windows server you manage, and it operates using two privileged service accounts that most administrators do not fully understand:

• The MSOL_ account — Created automatically during installation, named MSOL_ followed by a random 12-character alphanumeric string. This account exists in your on-premises Active Directory and holds Replicating Directory Changes All and Replicating Directory Changes permissions on the domain. Those are DCSync-equivalent permissions. Any process that can authenticate as this account can extract every password hash in your domain.
• The cloud connector account — Named Sync_ followed by the server name, this account exists in Entra ID and has the Directory Synchronization Accounts role, giving it the ability to write attributes and reset passwords for synced users in the tenant.

The Entra Connect server stores the credentials for both accounts in a local SQL database (ADSync database). On a default installation, this database is LocalDB or SQL Server Express, and the credentials are encrypted using DPAPI tied to the service account. An attacker with local administrator access to the Entra Connect server can extract those credentials in cleartext using tools like adconnectdump or AADInternals' Get-AADIntSyncCredentials.

To find the MSOL_ account in your environment:

Get-ADUser -LDAPFilter "(description=*configured to synchronise to tenant*)" `
  -Properties description | Select-Object Name, SamAccountName

That account should have no interactive logon rights, no group memberships beyond what Entra Connect requires, and its activity should be generating alerts every time it authenticates.

Three Authentication Modes, Three Attack Surfaces

Entra Connect supports three synchronization methods for user authentication, and each carries distinct risks.

Password Hash Synchronization (PHS)

PHS is the most common deployment mode. Every 2 minutes, Entra Connect extracts NTLM hashes from on-premises AD, derives a second-generation hash, and synchronizes it to Entra ID. The practical implication: your cloud tenant holds a derivative of every on-premises password hash. If the tenant is compromised — or if the sync account is compromised — an attacker can reset cloud passwords to gain access to cloud resources, even without touching on-prem systems.

PHS also means that every password change on-prem propagates to the cloud within minutes. This is generally positive for security (password resets during incidents propagate quickly), but it also means weak on-prem passwords become weak cloud passwords automatically. Password protection policies must be enforced at both layers.

Pass-Through Authentication (PTA)

PTA routes authentication requests through one or more lightweight agents installed on on-premises servers. When a user logs into Entra ID, the request is queued in an Azure Service Bus, picked up by a PTA agent, validated against on-prem AD, and the result returned to the cloud. No password hashes are stored in the cloud — authentication happens on-prem in real time.

The attack surface here is the PTA agent itself. In 2019, security researcher Dr. Nestori Syynimaa documented PTASpy, a technique where an attacker injects a malicious DLL into the PTA agent process (AzureADConnectAuthenticationAgent) to intercept and log all credentials passing through it — and to accept any password as valid for any user. The result: the compromised PTA agent becomes a credential harvester and a universal password bypass for every synced account in the tenant.

AADInternals implements this as Install-AADIntPTASpy. The attacker needs local administrator access to a server running the PTA agent. Once installed, all passwords are accepted and harvested to a local CSV file. The MITRE ATT&CK technique is T1556.007 (Modify Authentication Process: Hybrid Identity). Detection requires monitoring for discrepancies between Entra ID sign-in events and on-prem AD authentication events — if a cloud sign-in succeeded but no corresponding AD event exists, a PTA agent may be compromised.

A 2026 vulnerability disclosed by Cymulate researchers revealed an additional PTA weakness in multi-domain tenants: authentication requests are randomly distributed among all PTA agents regardless of which on-premises domain the user belongs to. An attacker with a compromised PTA agent from Domain A can intercept authentication requests for Domain B users, manipulate the credential validation response, and gain unauthorized access.

Seamless SSO and the AZUREADSSOACC$ Account

Seamless SSO allows users on domain-joined machines to authenticate to Entra ID without entering credentials, using Kerberos tickets. This is implemented through a hidden computer account called AZUREADSSOACC$ in on-prem AD. Entra ID knows the password (Kerberos key) for this account, and it validates Kerberos service tickets generated against it.

The attack: obtain the NTLM hash of AZUREADSSOACC$ (available via DCSync with the MSOL_ account), then use AADInternals to forge Kerberos tickets for any synced user — including Global Administrators synced from on-prem. That forged ticket authenticates to Entra ID and returns a valid access token.

# Using AADInternals to forge a Kerberos ticket for a synced Global Admin
$kerberosTicket = New-AADIntKerberosTicket `
  -SidString "<on-prem user SID>" `
  -Hash "<AZUREADSSOACC$ NTLM hash>"

# Exchange for an Entra ID access token
$token = Get-AADIntAccessTokenForAADGraph `
  -KerberosTicket $kerberosTicket `
  -Domain "yourtenant.onmicrosoft.com"

The Seamless SSO Kerberos key should be rotated regularly. Microsoft recommends rotating it every 30 days. Most organizations have never rotated it since deployment.

The Syncjacking Attack: A Newer Threat Vector

Research published in 2025 by Semperis documented a technique called syncjacking that exploits Entra Connect's attribute matching mechanism. The attack leverages the mS-DS-ConsistencyGuid attribute, which Entra Connect uses to match on-prem accounts to their cloud counterparts.

The steps: identify a high-privilege synced user, copy their mS-DS-ConsistencyGuid to a newly created on-prem account controlled by the attacker, delete the original user, then force a synchronization cycle. Entra Connect now associates the attacker's on-prem account with the cloud identity — including all Entra ID role assignments and group memberships — but the attacker controls the password.

This attack requires write access to on-premises AD (not necessarily Domain Admin), which makes it relevant not just for post-compromise persistence but for lateral escalation scenarios. Conditional Access and MFA on the cloud side can limit the impact, but the underlying mechanism remains dangerous in environments where cloud role assignments follow from on-prem group memberships automatically.

AADInternals: The Adversary's Toolkit

AADInternals, developed by Dr. Nestori Syynimaa, is the most comprehensive offensive toolkit for hybrid Azure AD environments. It is publicly available and now flagged as malicious by most endpoint protection platforms — which means red teams use obfuscated versions, and sophisticated threat actors have operationalized it. Its capabilities include:

• Extracting MSOL_ and Sync_ account credentials from the ADSync database
• Installing PTASpy to harvest credentials and bypass authentication
• Converting domains to federated domains to create Golden SAML backdoors
• Forging Kerberos tickets using the AZUREADSSOACC$ hash
• Disabling MFA for individual users
• Registering rogue devices to Entra ID
• Exfiltrating OneDrive and SharePoint content using a compromised token

If AADInternals execution is detected by your EDR, treat it as a Tier 0 incident. The mere presence of the tool on the Entra Connect server or any domain controller is a critical indicator of compromise.

Hardening the Entra Connect Server

The first and most important step is treating the Entra Connect server as a Tier 0 asset — equivalent to a domain controller. Most organizations do not. Here is the baseline hardening posture:

Server Isolation

• Dedicate a physical or virtual machine solely to Entra Connect. No other workloads.
• Join the server to the domain but restrict it with a dedicated OU with GPO blocking interactive logons from non-Tier-0 accounts.
• No domain admins should use this server for anything other than Entra Connect administration.
• Network-isolate: inbound access from admin jump hosts only, outbound limited to Entra Connect required endpoints (documented by Microsoft at aka.ms/aadconnectportal).
• Enable Windows Credential Guard and LSA Protection (RunAsPPL) to prevent credential extraction from LSASS.

Restrict MSOL_ Account Permissions

The MSOL_ account requires the following AD permissions and nothing more:

• Replicating Directory Changes (on the domain)
• Replicating Directory Changes All (on the domain)
• Read permissions on specific OUs containing synced objects
• Password reset permission on synced user objects (if password writeback is enabled)

Audit the MSOL_ account's effective permissions quarterly. Remove any group memberships. Block interactive and remote logon. Create an alert in your SIEM for any logon event from this account that does not originate from the Entra Connect server.

Rotate Seamless SSO Kerberos Keys

Rotate the AZUREADSSOACC$ Kerberos key on a regular schedule. Use the Entra Connect wizard or PowerShell:

# Import the Entra Connect module and rotate Seamless SSO keys
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AzureADSSO.psd1"
New-AzureADSSOAuthenticationContext
Update-AzureADSSOForest -OnPremCredentials $cred

After rotation, existing Kerberos tickets forged against the old key become invalid. Schedule this monthly via a change management ticket so it is never skipped.

Staging Mode for Disaster Recovery

Run a second Entra Connect server in staging mode (read-only). It processes sync cycles but exports nothing to the cloud or on-prem AD. If the primary server is compromised or fails, you can promote the staging server and restore sync operations without downtime — and without the attacker having access to your only sync server.

Monitor Sync Operations

Entra Connect writes detailed health data to the Entra portal (Entra ID > Monitoring > Connect Health). Create alerts for:

• Sync latency exceeding 30 minutes (may indicate service disruption or tampered sync)
• Unexpected object deletions during sync cycles
• Changes to sync rules (visible in the Synchronization Rules Editor)
• Any modification to the MSOL_ account's permissions in AD
• Sign-in events from the Sync_ cloud account (these should only come from Azure infrastructure, not external IP addresses)

Detection and Monitoring

Defending hybrid identity requires correlating on-prem and cloud logs together. No single log source gives you the full picture.

• Entra ID Sign-in Logs: Monitor for sign-ins where the authentication method is PTA and cross-correlate with on-prem AD security event logs. A successful PTA authentication with no corresponding on-prem authentication event (Event ID 4624/4625) is a strong indicator of a compromised PTA agent.
• Entra Connect Health: Enable Entra Connect Health in the Entra portal. It requires an Entra ID P1 or P2 license per synced user but provides alerting on sync failures, latency, and agent health.
• On-prem Event IDs: Monitor Event ID 4662 on domain controllers for MSOL_ account replication operations. An unusual spike in replication requests from the MSOL_ account, or replication requests from a non-Entra Connect source, indicates DCSync activity.
• Entra Audit Logs: Alert on any password reset performed by the Sync_ account. This is the Storm-0501 TTPs in practice — using the cloud connector account to reset passwords of high-privilege hybrid users.

The Migration Path: Moving Toward Cloud-Only

The most effective long-term mitigation for hybrid identity risk is eliminating hybrid identity. For organizations on a maturity journey, the path looks like this:

1. Identify cloud-only candidates: New hires, cloud-only roles, and accounts that do not need on-prem resource access are strong candidates for cloud-native Entra ID accounts with no on-prem sync dependency.
2. Move privileged accounts to cloud-only: Global Administrators and other high-privilege Entra ID roles should never be synced from on-prem. Create dedicated cloud-only accounts for cloud administration. This eliminates the entire syncjacking and SSO abuse attack chain for your most critical identities.
3. Evaluate Entra Cloud Sync: For organizations that need to continue syncing but want to reduce the footprint of the full Entra Connect server, Entra Cloud Sync uses a lightweight provisioning agent and a cloud-based sync engine. It does not support all Entra Connect features (notably, password writeback and device writeback are limited), but for organizations running simple sync scenarios, it dramatically reduces the attack surface.

Hybrid identity is a necessary bridge for most organizations operating in a mixed on-prem and cloud environment. But it is a bridge that must be guarded. The Entra Connect server, the MSOL_ account, the PTA agents, and the AZUREADSSOACC$ computer account are all Tier 0 assets whether your security program treats them that way or not. Your adversaries already know which side of that bridge is most accessible. Make sure you are watching the same door.