Escalade de privilèges Exchange WriteDacl domaine Active Directory : comment une installation vieille de dix ans distribue encore des droits Domain Admin

Qu'est-ce que l'escalade de privilèges Exchange WriteDacl domaine Active Directory

Les mauvaises configurations d'escalade de privilèges Exchange WriteDacl domaine Active Directory comptent parmi les défauts les plus lourds de conséquences qui restent intacts dans les environnements ayant installé Exchange Server on-premise à un moment ou un autre au cours de la dernière décennie. Lorsqu'Exchange Server 2013, 2016 ou 2019 est configuré avec le modèle de permissions partagées par défaut de Microsoft, le groupe de sécurité Exchange Windows Permissions se voit accorder le droit WriteDacl — le droit de modifier la liste de contrôle d'accès discrétionnaire (DACL) — directement sur l'objet domaine à la racine d'Active Directory. Cette seule entrée de contrôle d'accès (ACE), à quelques maillons d'une chaîne courte, suffit à donner à un attaquant un accès équivalent à Domain Admin sur l'ensemble de la forêt, et pas seulement sur l'organisation Exchange.

Le groupe Exchange Trusted Subsystem — l'identité de service que chaque serveur Exchange utilise pour agir dans AD au nom des utilisateurs finaux via le modèle RBAC (Role Based Access Control) d'Exchange — est lui-même imbriqué par défaut dans Exchange Windows Permissions (Microsoft Learn, « Split permissions in Exchange Server »). Quiconque peut ajouter un compte à Exchange Trusted Subsystem, ou compromet purement et simplement un serveur Exchange, hérite du droit WriteDacl sur l'objet domaine.

Pourquoi ce n'est pas « juste » le CVE-2019-1166

Il ne s'agit pas d'un CVE unique corrigeable par un patch : la documentation Microsoft sur les permissions partagées elle-même présente ce comportement comme un défaut architectural du modèle de permissions partagées, pas comme une vulnérabilité avec une version correctrice. Cette distinction compte, car le texte de certains catalogues sur ce constat est parfois recoupé à tort avec le CVE-2019-1166 — un CVE bien réel, mais qui couvre un contournement NTLM Message Integrity Check (MIC) sans rapport (« Drop the MIC 2 », découvert par la Preempt Research Team et corrigé par Microsoft lors du Patch Tuesday d'octobre 2019, selon l'avis de Praetorian). Ce correctif, et son jumeau de juin 2019 le CVE-2019-1040, ont renforcé les défenses NTLM relay en général ; aucun des deux n'a touché à l'ACE WriteDacl qu'Exchange laisse sur l'objet domaine. Les organisations qui ont installé les deux sans jamais adopter les permissions partagées restent exposées aujourd'hui, et un contrôleur de domaine entièrement patché ne dit rien sur la présence ou non de cette ACE — voir notre analyse plus large de l'abus d'ACL et des chemins DCSync vers Domain Admin pour comprendre comment ces octrois d'accès s'accumulent avec d'autres mauvaises configurations Active Directory.

Comment ça fonctionne : d'Exchange Windows Permissions à DCSync

La chaîne de privilèges par défaut

La chaîne qui mène d'une identité Exchange sur-privilégiée (ou simplement compromise) à la compromission complète du domaine est courte :

1. Exchange Windows Permissions détient une ACE WriteDacl sur l'objet domaine.
2. Exchange Trusted Subsystem est membre d'Exchange Windows Permissions par défaut.
3. Les membres du groupe de rôle RBAC Organization Management peuvent modifier l'appartenance des autres groupes de sécurité Exchange, y compris Exchange Trusted Subsystem (ADSecurity.org, « Mitigating Exchange Permission Paths to Domain Admins in Active Directory » ; Trimarc Security).
4. Quiconque se trouve dans cette chaîne — ou compromet directement le compte machine d'un serveur Exchange — peut utiliser le droit WriteDacl pour écrire une nouvelle ACE sur l'objet domaine accordant DS-Replication-Get-Changes et DS-Replication-Get-Changes-All, les deux droits étendus dont dépend DCSync.
5. À partir de là, une requête de réplication récupère tous les hachages de mots de passe du domaine, y compris celui de krbtgt. C'est le même abus des droits de réplication que nous couvrons dans notre guide d'audit des permissions ACL, DPAPI, tombstone et schéma — Exchange n'est que la source la plus courante de cet octroi, pas la seule.

# Énumération en lecture seule : Exchange Windows Permissions (ou un groupe imbriqué)
# détient-il toujours WriteDacl sur l'objet domaine ?
dsacls "DC=corp,DC=local" | Select-String "Exchange Windows Permissions|WRITE DAC"

L'amplification PrivExchange de 2019

En janvier 2019, le chercheur Dirk-jan Mollema a montré que ce défaut ne nécessitait même pas un pied dans un groupe Exchange existant. La fonctionnalité PushSubscription d'Exchange pouvait être détournée pour forcer le compte machine d'un serveur Exchange à s'authentifier, en HTTP, auprès d'un point de terminaison contrôlé par l'attaquant. Comme NTLM sur HTTP n'active pas par défaut le flag de signature obligatoire, cette authentification pouvait être relayée vers LDAP et combinée au droit WriteDacl du serveur pour accorder à l'attaquant des privilèges DCSync — déclenchable par n'importe quel utilisateur disposant d'une boîte aux lettres (dirkjanm.io, « Abusing Exchange: one API call away from Domain Admin »). Les mises à jour cumulatives Exchange de février 2019 de Microsoft ont traité ce problème sur deux fronts : KB4490060 a modifié le contrat d'authentification des Push Notifications d'Exchange Web Services pour que les abonnements ne diffusent plus d'identifiants pouvant être détournés vers une authentification sortante, et KB4490059 a documenté comment réduire les permissions Active Directory par défaut d'Exchange à l'avenir — mais ni ce correctif, ni les correctifs ultérieurs du contournement NTLM MIC, ne suppriment une ACE déjà écrite sur un objet domaine des années plus tôt.

Une variante courante en conditions réelles aggrave encore le problème : les organisations qui ont migré leurs boîtes aux lettres vers Exchange Online conservent fréquemment un serveur Exchange on-premise uniquement pour la gestion des attributs AD, car les recommandations hybrides de Microsoft ont longtemps déconseillé de retirer complètement le dernier serveur on-premise. Ce serveur conservé, et les groupes AD qui se trouvent derrière lui, continuent de porter le même octroi WriteDacl indéfiniment — c'est exactement ainsi qu'une installation vieille de dix ans finit par distribuer des droits Domain Admin dans un environnement où plus personne ne considère Exchange comme « dans le périmètre », longtemps après que les boîtes aux lettres elles-mêmes ont migré vers le cloud.

Détection

L'audit Directory Service Access et Directory Service Changes n'est pas activé par défaut sur les contrôleurs de domaine, et même lorsqu'il l'est, l'Event ID 4662 ne se déclenche que pour les objets qui portent une SACL correspondante. Ces deux lacunes doivent être comblées avant qu'aucun des indicateurs suivants n'apparaisse réellement dans vos journaux (Altered Security, « A primer on DCSync attack and detection »). Notre guide de supervision Active Directory sur les Event ID qui comptent détaille en profondeur les prérequis de politique d'audit pour tous ces indicateurs.

Détection par journaux

Énumération proactive

Comme l'ACE elle-même peut avoir plusieurs années et rester silencieuse — elle ne génère pas d'événement nouveau simplement parce qu'elle existe — la surveillance des journaux doit être associée à une énumération proactive périodique : dsacls ou Get-Acl "AD:\<domain DN>" sur l'objet domaine, ou une collecte BloodHound spécifiquement vérifiée pour un edge WriteDacl atterrissant sur le nœud domaine. Traitez cela comme vous traiteriez la dérive des accès privilégiés : un audit ponctuel prouve seulement que l'ACE n'était pas là le jour du contrôle, pas qu'elle reste absente par la suite.

Remédiation

Mesures compensatoires immédiates

1. Énumérer. Exécutez dsacls ou Get-Acl sur l'objet domaine et vérifiez si Exchange Windows Permissions / Exchange Trusted Subsystem détient WriteDACL ; recoupez avec une collecte BloodHound pour le même edge.
2. Réduire le rayon d'impact immédiat si une migration complète vers les permissions partagées n'est pas encore réalisable : retirez Exchange Trusted Subsystem d'Exchange Windows Permissions, et exigez un processus contrôlé et journalisé pour tout ajout futur à Organization Management, Exchange Windows Permissions, ou Exchange Trusted Subsystem (Trimarc Security).

Le correctif permanent

3. Adopter le modèle de permissions partagées de Microsoft. Le split RBAC est le réglage par défaut recommandé par Microsoft ; le split Active Directory offre une séparation complète entre l'administration Exchange et l'administration AD. Les deux nécessitent de relancer le Setup avec /PrepareAD /ActiveDirectorySplitPermissions:true, plus /PrepareAllDomains (ou un /PrepareDomain par domaine) dans les forêts multi-domaines (Microsoft Learn, « Split permissions in Exchange Server »). C'est ce qui retire réellement les ACE Exchange Windows Permissions de l'objet domaine — pas un correctif de sécurité Windows ou Exchange.
4. Décommissionner proprement. Si Exchange a déjà été migré hors site ou retiré, confirmez que l'ACE de l'objet domaine a été supprimée dans le cadre de ce processus. Le déprovisionnement d'Exchange ne retire pas automatiquement et rétroactivement un octroi WriteDacl antérieur — c'est exactement ainsi qu'une installation vieille de dix ans continue de distribuer des droits Domain Admin longtemps après l'arrêt du dernier serveur Exchange.
5. Vérifier. Relancez l'énumération de l'étape 1 après la remédiation et confirmez que les droits DS-Replication-Get-Changes(-All) sur l'objet domaine sont limités aux contrôleurs de domaine et aux comptes de réplication explicitement autorisés. Intégrez ce contrôle dans un workflow d'audit récurrent plutôt qu'un nettoyage ponctuel, car la réactivation des permissions partagées ou le fait de rajouter Exchange Trusted Subsystem à Exchange Windows Permissions restaure silencieusement l'ACE, sans aucun signal d'alerte évident.

Comment EtcSec détecte cela

L'audit Active Directory d'EtcSec signale directement ce schéma via le contrôle Exchange Privilege Escalation Risk (EXCHANGE_PRIV_ESC_PATH), qui inspecte l'ACL de l'objet domaine à la recherche de l'octroi WriteDacl d'Exchange Windows Permissions et retrace l'imbrication des groupes jusqu'à cette source. Il est corrélé avec les contrôles plus larges ACL WriteDACL (ACL_WRITEDACL) et DS-Replication-Get-Changes Rights (DCSync) (ACL_DS_REPLICATION_GET_CHANGES), ainsi qu'avec le rollup général DCSync Capable (DCSYNC_CAPABLE), de sorte qu'un chemin d'attaque complet d'Exchange vers DCSync apparaît comme un seul constat priorisé au lieu de quatre entrées ACL déconnectées, qu'il provienne d'un serveur Exchange actif ou d'un reliquat vieux de dix ans que personne n'a pensé à décommissionner.