Module 7 · Hybrid AD & ADFS Attack Surface

Last updated: April 29, 2026

Hybrid AD environments — on-prem AD synchronized with Entra ID via Entra Connect, possibly federated through ADFS — combine the attack surfaces of both. Attackers move between on-prem and cloud planes via the connection points: Entra Connect server, ADFS, seamless SSO computer object, password hash sync. This module covers the hybrid attack patterns and the controls that limit lateral pivot in 2026.

The hybrid identity architectures

1. Cloud-only — accounts native in Entra ID; no on-prem AD. Increasingly common for new orgs
2. Synchronized identity — Entra Connect syncs user objects + password hash to Entra ID. Single identity used both
3. Federated identity — sign-in delegated from Entra ID to on-prem ADFS; ADFS authenticates against AD
4. Pass-through authentication (PTA) — Entra ID forwards auth requests to lightweight agents on-prem that validate against AD

Each model has distinct compromise paths.

Entra Connect server — the crown jewel

The Entra Connect server has, by default:

• DCSync rights on all domain controllers (to read password hashes)
• Cloud admin equivalent in the synced tenant (via the configured Service Account for sync)
• Privileged service account stored in registry (DPAPI-encrypted)

Compromise of Entra Connect ≈ compromise of both AD and Entra ID. Treat as a Tier 0 asset:

• Dedicated Server OS, hardened
• Same-tier admin accounts only (don’t admin from a workstation)
• Application allowlisting
• Endpoint detection
• Audit logging
• Limited physical / network access

ADFS — the federation pivot

If using ADFS, additional concerns:

• Token-signing certificate — issued tokens prove authenticated identity to Entra ID. Steal it, you can forge tokens for any user (Golden SAML attack — used by SolarWinds attackers)
• ADFS server compromise — same as token-signing-cert compromise plus more
• DKM (Distributed Key Manager) key — encrypts the token-signing cert; stored in AD; admins can read

Defenses:

• Migrate from ADFS to native Entra ID auth where possible (Microsoft’s direction)
• If keeping ADFS: HSM-backed token-signing cert; dedicated Tier 0 ADFS servers
• Monitor for ADFS configuration changes, token-signing-cert export attempts

Password Hash Sync (PHS) attacks

PHS sends NTLM hash representations to Entra ID for cloud authentication. Implications:

• Compromise of Entra ID password store + cracking → on-prem credentials
• Reverse direction — compromise of Entra Connect’s MD4-of-NTLM material lets you replay against Entra ID
• Disabling PHS (PTA only) eliminates this vector but adds operational dependency on PTA agents

Seamless SSO — the legacy AZUREADSSOACC$ problem

Seamless SSO uses a computer account in AD called AZUREADSSOACC$ with a hardcoded password (initially). Pre-2024, you could:

1. Read the password (DCSync or other AD compromise)
2. Forge Kerberos service tickets for the SSO endpoint
3. Authenticate as any user to Entra ID without their credentials

Microsoft hardened this in 2024 (changed key derivation), but legacy tenants remain vulnerable until configuration is updated. Verify your tenant’s AZUREADSSOACC$ password rotation date.

Connect Sync Service Account

The service account Entra Connect uses to read AD has DCSync rights. Common attack: compromise the Sync Service Account → DCSync the entire domain. Mitigations:

• Use a Group-Managed Service Account (gMSA) instead of a static-password account
• Restrict the account’s logon to only the Entra Connect server
• Audit account use; alert on logon from anywhere except Entra Connect

Cross-plane lateral movement scenarios

On-prem → Cloud

1. Attacker compromises on-prem user’s workstation
2. Captures user’s primary refresh token (PRT) from memory
3. Replays PRT → cloud auth without password

Cloud → On-prem

1. Attacker compromises cloud admin via phishing
2. Pulls Entra Connect server config from Azure portal
3. Pivots to Entra Connect server via cached credentials or remote management
4. From Entra Connect: DCSync on-prem AD; full domain compromise

Cloud admin → on-prem via auto-provisioning

1. Cloud admin account compromise
2. Modify Entra Connect to write attacker-controlled attributes back to on-prem (write-back enabled for some scenarios)
3. Attacker manipulates on-prem objects via cloud control

Detection priorities

• Tier 0 logons — alert on any logon to Entra Connect, ADFS, DCs from a non-Tier-0 account
• Token signing cert export — Windows Event 4661 with handle to ADFS cert store
• ADFS configuration changes — relying party trust modifications, claim issuance rule changes
• Anomalous sign-ins to admin accounts — Identity Protection alerts
• DCSync events — Windows Event 4662 with replication GUIDs from accounts other than DCs and Entra Connect
• New Entra ID app registrations with high-privilege Graph permissions

The roadmap to reduce hybrid risk

1. Eliminate ADFS if possible; move to native Entra ID auth
2. Tier separation — Tier 0 (DCs, Entra Connect, ADFS) accessed only from Tier 0 admin workstations
3. Privileged Access Workstations (PAWs) for all admin work
4. Privileged Identity Management for all elevated cloud roles
5. Phishing-resistant MFA (FIDO2) on all admin accounts
6. Conditional Access requiring compliant device for admin sign-in
7. Continuous access evaluation — token revocation in seconds on risk events
8. Cloud-only admin accounts — admin accounts that don’t sync from on-prem

India-specific considerations

• RBI sectoral guidance for banking includes hybrid-identity risk in their cyber framework
• Data residency — Entra Connect agent location vs cloud tenant geography
• Skill availability — Indian market skews on-prem AD experience; Entra ID + hybrid expertise rarer

Where this leads

The AD track now extends from on-prem fundamentals (Modules 1-6) to hybrid attacks (Module 7). For purely-cloud Entra environments, also see the Azure track Module 1.