Les configurations Exchange Hybrid sont séduisantes sur le papier : elles permettent une coexistence progressive entre l'infrastructure messagerie on-premise et Exchange Online, sans migration forcée. En pratique, elles introduisent un couplage fort entre deux environnements qui devraient rester logiquement séparés. Ce couplage, matérialisé par Azure AD Connect, est devenu l'un des chemins d'attaque les plus sous-estimés dans les architectures hybrides.
Ce que fait vraiment Azure AD Connect
Azure AD Connect synchronise les identités depuis l'Active Directory local vers Entra ID (anciennement Azure AD). Pour fonctionner, il utilise deux comptes de service aux privilèges élevés : un compte AD DS Connector avec des droits de réplication sur l'annuaire local (équivalents à ceux de DCSync), et un compte synchronisé dans le tenant cloud avec des permissions sur les objets synchronisés.
Dans une configuration Hybrid Exchange, le schéma AD est étendu pour inclure des attributs de messagerie. Le compte de synchronisation reçoit des droits supplémentaires pour gérer ces attributs, ce qui élargit encore sa surface d'action. Concrètement, un attaquant qui prend le contrôle du serveur hébergeant Azure AD Connect obtient les clés des deux royaumes.
Le scénario d'attaque : de la compromission on-prem à l'élévation tenant
Imaginons un scénario type. Un attaquant compromet initialement un poste utilisateur via phishing, puis pivote vers un serveur de fichiers mal segmenté. À partir de là, il obtient des privilèges locaux sur le serveur Azure AD Connect, souvent installé sur un membre du domaine voire sur un contrôleur de domaine secondaire.
Extraction des credentials de synchronisation
L'outil AADInternals, publiquement disponible, permet d'extraire les credentials du compte de synchronisation directement depuis la base de données locale d'Azure AD Connect (fichier ADSync). Ces credentials incluent le mot de passe chiffré du compte cloud, déchiffrable avec les clés stockées localement. Aucune interaction réseau suspecte n'est nécessaire à ce stade.
Élévation vers le tenant Entra ID
Avec ces credentials, l'attaquant s'authentifie auprès de l'API de synchronisation Microsoft. Le compte de synchronisation dispose de permissions suffisantes pour réinitialiser les mots de passe d'utilisateurs cloud non-administrateurs, mais aussi, dans certaines configurations, pour modifier des attributs sensibles comme onPremisesImmutableId, ce qui permet de lier un compte cloud à une identité locale contrôlée. Si un compte administrateur global n'est pas exclu de la synchronisation, le pivot devient une élévation directe vers les droits les plus élevés du tenant.
Persistance et mouvement latéral cloud
Une fois dans le tenant, l'attaquant peut enregistrer une application OAuth, créer des credentials sur un service principal existant, ou ajouter un compte Global Admin. Ces actions laissent des traces dans les logs Entra ID Audit, mais seulement si quelqu'un les surveille activement. Dans la plupart des environnements sans SOC dédié, cette phase passe inaperçue pendant des semaines.
Pourquoi les configurations Exchange Hybrid amplifient ce risque
Sans Exchange Hybrid, Azure AD Connect peut être configuré avec un compte de synchronisation aux droits minimalistes. Dès qu'Exchange Hybrid entre en jeu, Microsoft requiert des permissions supplémentaires sur l'annuaire AD pour synchroniser les attributs de messagerie, notamment des droits en écriture sur des groupes de sécurité et des unités organisationnelles entières.
Par ailleurs, le serveur Exchange on-premise reçoit lui-même des permissions étendues sur l'annuaire lors de l'installation du rôle hybride. L'objet Exchange Trusted Subsystem dispose historiquement de droits WriteDACL sur de nombreux objets AD, ce qui en fait une cible de choix pour tout attaquant cherchant à escalader vers Domain Admin — et donc, par rebond, vers Azure AD Connect.
Mesures de cloisonnement recommandées
Microsoft documente plusieurs pratiques pour réduire la surface d'exposition, mais elles nécessitent une mise en œuvre volontaire. Elles ne sont pas actives par défaut.
Isoler le serveur Azure AD Connect
Le serveur AD Connect ne doit jamais être un contrôleur de domaine. Il doit résider sur un segment réseau dédié, avec des flux entrants limités aux seuls protocoles nécessaires (LDAP, Kerberos vers les DCs, HTTPS sortant vers Microsoft). L'accès administratif doit passer par un jump server et être tracé dans un SIEM.
Activer le mode Staged Rollout et les comptes de service gMSA
Depuis les versions récentes d'Azure AD Connect, il est possible d'utiliser un compte de service géré de groupe (gMSA) pour le connecteur AD DS, ce qui élimine la gestion manuelle des mots de passe et rend l'extraction beaucoup plus difficile. Cette option doit être activée explicitement lors de la configuration ou de la mise à jour.
Exclure les comptes privilegiés de la synchronisation
Tout compte membre d'un rôle Entra ID privilegié (Global Admin, Privileged Role Administrator, etc.) doit être un compte cloud-only, jamais synchronisé depuis l'AD local. Microsoft le recommande explicitement dans ses guides de sécurité. En pratique, cette règle est fréquemment violée dans les environnements migrés progressivement.
Réduire les permissions Exchange on-premise
Microsoft fournit un script PowerShell (ReduceExchangePermissions.ps1) pour retirer les droits WriteDACL accordés à Exchange Trusted Subsystem sur des objets AD non-messagerie. Ce nettoyage doit être planifié et testé en environnement de pré-production, car il peut affecter certaines fonctionnalités hybrides.
Surveiller les événements critiques
Côté on-premise, les événements de réplication DCSync (ID 4662 avec droit DS-Replication-Get-Changes-All) doivent déclencher une alerte immédiate. Côté cloud, les connexions inhabituelles du compte de synchronisation et toute modification de rôle Global Admin méritent une règle de détection dédiée dans Microsoft Sentinel ou votre SIEM cloud.
Ce que cela implique pour votre posture de sécurité
Un environnement Exchange Hybrid correctement durci est atteignable, mais il demande une revue explicite des permissions héritées, un travail de cloisonnement réseau qui va au-delà de la documentation d'installation, et une surveillance continue des deux plans de contrôle. L'erreur classique est de traiter la sécurité cloud et la sécurité on-premise comme deux sujets distincts. Dans un déploiement hybride, elles forment un seul périmètre — avec tous les angles morts que cela implique.
Questions fréquentes
Azure AD Connect est-il dangereux par conception ?
Pas par conception, mais par nature : il est un pont entre deux environnements de confiance différente. Le risque vient de la façon dont il est déployé et protégé, pas du produit lui-même. Un serveur AD Connect mal isolé, avec des droits excessifs et sans surveillance, devient effectivement un vecteur d'attaque majeur.
Est-ce que désactiver Exchange Hybrid supprime ce risque ?
Partiellement. Même après une migration complète vers Exchange Online, les permissions accordées à Exchange Trusted Subsystem et au compte de synchronisation restent en place si elles ne sont pas explicitement révoquées. Une migration cloud ne nettoie pas automatiquement l'annuaire AD local.
Quels outils permettent de détecter une exploitation de ce vecteur ?
Côté on-premise, Microsoft Defender for Identity détecte les attaques DCSync et les comportements anormaux du compte AD DS Connector. Côté cloud, Microsoft Sentinel avec les connecteurs Entra ID Audit et Sign-In Logs permet de surveiller les actions du compte de synchronisation et les élévations de privilèges inhabituelles.
Une petite entreprise sans SOC peut-elle sécuriser une configuration hybride ?
Oui, mais avec une approche minimaliste : isoler physiquement le serveur AD Connect, activer les gMSA, et s'assurer qu'aucun compte administrateur global n'est synchronisé depuis l'AD local. Ces trois mesures, appliquées correctement, réduisent drastiquement la surface d'attaque sans nécessiter d'équipe dédiée.