Module 9 · Hybrid AD — On-Prem Meets Cloud

Last updated: April 29, 2026

Most enterprise AD environments in 2026 are hybrid — on-premises AD synced with Microsoft Entra ID (formerly Azure AD) via Entra Connect. This gives users single-identity access to both M365 and on-prem resources. It also creates cross-cloud compromise paths that didn’t exist in pure on-prem AD. This module covers why hybrid AD attack surface is larger than the sum of its parts.

Why hybrid AD is risky

Two directory services, one identity. Entra Connect (formerly Azure AD Connect) synchronizes users, groups, passwords (hashed), and sometimes device objects. The sync creates trust relationships between on-prem and cloud that didn’t exist before.

Key paths:

• On-prem compromise → Entra Connect server → cloud identity compromise
• Cloud admin compromise → Azure AD Sync Service → on-prem AD write
• Password Hash Sync (PHS) puts on-prem NT hashes in the cloud
• Pass-Through Authentication (PTA) agents extend cloud auth to on-prem
• Seamless SSO uses a hardcoded AD computer account — attack vector

The Entra Connect server — crown jewel

The server running Entra Connect has, by default:

• DCSync rights on all domain controllers (to read password hashes for sync)
• Cloud admin equivalent in the synced tenant (for sync operations)
• Privileged service account whose credentials are in a config file
• Azure AD tenant connection using application secrets

Compromise of Entra Connect = compromise of both environments. Treat it as Tier 0.

# Extract Entra Connect sync account credentials
# From Entra Connect server (admin access needed):
mimikatz # lsadump::dcsync /user:MSOL_
# MSOL_ account has sync service DCSync rights

# Or extract from config file
# C:\Program Files\Microsoft Azure AD Sync\Data\
# Contains encrypted sync credentials; decrypt with DPAPI

# AADInternals (PowerShell) toolkit for Entra attacks
Install-Module AADInternals
Get-AADIntSyncCredentials   # From Entra Connect server
Set-AADIntUserPassword      # Change any user's password in cloud
Get-AADIntADSyncEncryptionKeyInfo

Password Hash Sync (PHS) attacks

PHS computes a hash-of-hash of the user’s NT hash and syncs it to Entra ID. Cloud authentication uses this material.

Attack vectors:

• Cloud-side compromise: if attacker gets the synced hashes from Entra (via misconfigured app with Directory.Read.All or similar), can offline-crack to recover NT hashes → on-prem compromise.
• On-prem side: compromise of Entra Connect = access to sync material = ability to replay to Entra for any user.

Pass-Through Authentication (PTA) agents

PTA forwards cloud authentication requests to on-prem AD. Agents on internal servers validate passwords.

Attack: Compromise PTA agent → intercept authentication attempts → log passwords of all cloud-authenticating users. Classic credential harvesting vector when organizations use PTA.

Seamless SSO — the AZUREADSSOACC$ problem

Seamless SSO (desktop single-sign-on to Entra) creates an AD computer account called AZUREADSSOACC$. Before 2024 hardening, this account had a hardcoded password. Attackers with DCSync extracted the password, then forged silver-ticket-style Kerberos tickets to impersonate any user to Entra endpoints.

# Extract AZUREADSSOACC$ hash (requires DCSync)
mimikatz # lsadump::dcsync /user:AZUREADSSOACC$

# Forge Kerberos ticket for SSO endpoint impersonating any user
mimikatz # kerberos::golden /user:Administrator /sid:S-1-5-21-... \
    /domain:corp.local /rc4:ACCOUNT_HASH /service:HTTP \
    /target:autologon.microsoftazuread-sso.com /ptt

# Now authenticated to Entra as Administrator
# Microsoft rotated key generation 2024; legacy tenants may still be vulnerable

ADFS — Golden SAML

Organizations using ADFS (Active Directory Federation Services) for federated cloud access have an additional target: the ADFS token-signing certificate. Compromise this cert, forge SAML tokens, authenticate as any user to any federated service.

# SolarWinds attackers used Golden SAML to access M365
# 1. Compromise ADFS server
# 2. Extract token-signing certificate + DKM key
# 3. Forge SAML token claiming any user identity
# 4. Submit to M365; authenticated

# AADInternals function
Get-AADIntADFSSigningCertificate   # Extract from ADFS server
New-AADIntSAMLToken               # Forge token

The SolarWinds campaign used Golden SAML to persist cloud access even after on-prem remediation. Defence: HSM-backed token-signing cert + migrate away from ADFS to native Entra auth.

Cross-plane lateral movement scenarios

On-prem → Cloud

1. Phishing → user endpoint compromise
2. Infostealer captures Primary Refresh Token (PRT) from browser/OS
3. Attacker replays PRT to Entra → cloud authenticated as user, bypassing MFA
4. From cloud: register attacker’s device, install OAuth app, read mail, etc.

Cloud → On-prem

1. Phishing or consent-grant compromise of Global Admin
2. Modify or create OAuth app with high-privilege delegated permissions
3. Access Entra Connect server via cached credentials or RDP
4. From Entra Connect: DCSync on-prem AD → krbtgt → Golden Ticket → full on-prem compromise

Golden Ticket + SIDHistory across Entra

Advanced: forge Golden Ticket with SIDHistory including cloud-only group SIDs → token valid both on-prem and in cloud contexts.

Real-world incidents

• SolarWinds / Solorigate (2020-2021): Classic hybrid attack. Initial compromise via supply chain; lateral movement; Golden SAML to maintain cloud access; on-prem + cloud persistent presence.
• Nobelium / Midnight Blizzard ongoing (2021-2025): Target hybrid AD environments for nation-state operations. PRT theft + Entra persistence.
• Storm-0501 (2024-2025): Ransomware operator specifically targeting hybrid environments. Documented playbook: compromise on-prem → extract Entra Connect creds → cloud account creation → ransomware both environments.

What we find

• Entra Connect server not hardened as Tier 0 (accessible from workstation admins)
• ADFS still in use (migration path unclear)
• AZUREADSSOACC$ password not rotated (pre-2024 vulnerability)
• Legacy authentication not blocked via Conditional Access
• Admin accounts synced from on-prem (should be cloud-only)
• No break-glass cloud-only admin accounts
• PIM not enabled for privileged roles
• Conditional Access missing MFA for admin or specific user groups
• Service principals with high Graph API permissions (Directory.Read.All, etc.)
• Application consent policies allowing user-consent to any app (consent-phishing risk)

Defenses

1. Tier 0 Entra Connect + ADFS servers. Dedicated infrastructure, dedicated admin accounts, PAW-only access.
2. Cloud-only admin accounts for Entra tenant administration (not synced from on-prem).
3. FIDO2 phishing-resistant MFA on all admin accounts.
4. PIM (Privileged Identity Management) for time-bound activation of admin roles.
5. Conditional Access: block legacy auth, require compliant device for admin, sign-in risk policy.
6. Continuous Access Evaluation (CAE): revoke tokens in seconds on risk events.
7. Migrate away from ADFS to native Entra auth where possible.
8. Rotate AZUREADSSOACC$ password (if applicable).
9. Monitor sign-in risk events, admin role changes, new SP creations.
10. Disable user consent to unverified/high-risk apps.

Mindset takeaway

Hybrid AD combines the attack surfaces of on-prem AD and Entra ID — and adds new ones at the sync layer. The Entra Connect server is as valuable as a domain controller. The ADFS server is as valuable as the krbtgt account. Protect them accordingly.

For pentesters: hybrid engagement requires both skill sets. BloodHound for on-prem; ROADtools, AADInternals for cloud. Bridge via Entra Connect or federation trust. For defenders: the migration to cloud-only identity (where possible) eliminates entire classes of hybrid attacks. For those stuck with hybrid, the Tier 0 boundary must include both Entra Connect and ADFS.