#UYBHYS26

Entra Connect est le composant chargé de synchroniser les identités entre Active Directory sur site et Microsoft Entra ID. Pour garantir cette synchronisation, trois comptes essentiels coexistent dans chaque déploiement : le compte du connecteur ADDS (MSOL), qui dispose de droits de réplication d'annuaire (DCSync) ; le compte du connecteur Entra, qui dispose de droits au sein d'Entra ID ; et le compte de service ADSync, chargé de chiffrer les informations d'identification stockées dans la base de données. En raison de ses privilèges combinés — DCSync sur site et synchronisation dans le cloud —, ce serveur doit être traité comme un actif de Tier 0, au même titre qu'un contrôleur de domaine. Dans la pratique, ce n'est pas toujours le cas, ce qui en fait une cible de choix.

Partie 1 — État de l'art : trois époques, trois mécanismes

Époque 1 — Registre (pre-v1.4) : la clé exposée
Dans les premières versions d'Azure AD Connect, le keyset de chiffrement protégeant les credentials dans la base ADSync.mdf était stocké directement dans le registre Windows : HKLM\Software\Microsoft\Ad Sync\Shared[keysetid]. Ce keyset était déchiffrable par tout administrateur local via DPAPI System. Les outils azuread_decrypt_msol.ps1 (XPN) et Get-AADIntSyncCredentials (AADInternals) exploitaient ce vecteur de façon triviale, rendant l'extraction en deux commandes.

Époque 2 — Credential Vault DPAPI avec VSA (v1.4+) : le changement
Microsoft a migré le keyset dans le Credential Vault du compte virtuel NT SERVICE\ADSync. Ce changement a initialement mis en échec les outils existants. La chaîne de déchiffrement a été reconstituée par Dirk-jan Mollema (avec l'aide de Benjamin Delpy/Mimikatz) : déchiffrer le masterkey DPAPI d'un Virtual Service Account (VSA) nécessite une combinaison de la DPAPI userkey + SID du compte virtuel — un corner case spécifique qui a nécessité des modifications dans Mimikatz et impacket. L'outil adconnectdump automatise cette chaîne en passant uniquement par des appels RPC réseau.

Époque 3 — gMSA comme compte de service (2021+) : le nouveau vecteur
Depuis la version 1.1.443.0, le service ADSync peut tourner sous un Group Managed Service Account (gMSA). Le keyset reste dans le Credential Vault, mais lié à l'identité du gMSA. La masterkey DPAPI est désormais dérivée du password du gMSA, géré automatiquement par le Key Distribution Service (KDS) du domaine avec rotation périodique. Cette chaîne de déchiffrement est fondamentalement différente de l'époque VSA et les outils publics actuels ne la couvrent pas nativement.

Évolution parallèle — Authentification cloud (2024-2025)
Indépendamment du compte de service ADSync, Microsoft a également remplacé l'authentification par password du compte connector cloud (Sync_xxx) par une authentification par certificat applicatif. Cela ferme l'extraction directe des credentials cloud via AADInternals, mais ouvre de nouveaux vecteurs : ADSyncCertDump (Dirk-jan), abus de l'API addKey (Daniel Heinsen / SpecterOps, juin 2025).
Il est à noter que Microsoft a considérablement réduit les droits de ce compte sur la partie EntraID

Partie 2 — Extraction des credentials MSOL avec contexte gMSA : démonstration
Cette partie constitue le cœur du talk. Nous présenterons la chaîne complète d'extraction dans le contexte gMSA, en mettant en évidence les points de friction et les adaptations nécessaires par rapport à l'époque VSA. Les points abordés seront les suivant :

Prérequis et reconnaissance :
• Identification du gMSA utilisé comme compte de service ADSync (Get-ADServiceAccount, services.msc)
• Énumération du groupe PrincipalsAllowedToRetrieveManagedPassword et des serveurs membres
• Localisation de la base ADSync.mdf et du Credential Vault du gMSA

Chaîne d'extraction depuis un accès administrateur local(technique peu documenté ni automatisé de nos jours, demo time incluse) :
• Vecteur 1 — Impersonation du process ADSync (vol de token gMSA → accès direct au vault sans connaître le password)
• Vecteur 2 — Extraction du password courant du gMSA via msDS-ManagedPassword depuis AD (si droits suffisants) puis déchiffrement de la masterkey DPAPI
• Vecteur 3 — Utilisation des DPAPI System Keys pour contourner la dépendance au password gMSA (via machine context)
• Extraction et déchiffrement de la base ADSync.mdf → récupération du credential MSOL en clair

Post-ex :
• DCSync via le compte MSOL
• Pivot vers l'infrastructure Entra ID selon la configuration de l'environnement

Partie 3 — Vue d'ensemble des autres vecteurs sur un serveur Entra Connect compromis
• Syncjacking : manipulation de mS-DS-ConsistencyGuid pour hijacker un compte cloud synchronisé
• Interception du Password Hash Sync (PHS) : injection dans le processus de synchronisation des hashes
• Abus du Seamless SSO (AZUREADSSOACC$) : forger des tickets Kerberos valides vers Entra ID
• Extraction de certificat Connector (ADSyncCertDump) pour persistence cloud

Partie 4 — Défense et détection
• Traitement du serveur Entra Connect comme actif Tier 0 : isolation réseau, LAPS, Credential Guard, etc.
• Surveillance des accès au Credential Vault, à la base ADSync.mdf et au Credential Store du gMSA
• Détection des sign-ins interactifs anormaux du compte MSOL
• Durcissement du groupe PrincipalsAllowedToRetrieveManagedPassword du gMSA
• Recommandations sur le choix VSA vs gMSA et leurs implications respectives sur la posture de sécurité
• Monitoring des sign-ins du compte Connector cloud