Attaque DCShadow : Contrôleur de Domaine Pirate

La technique d'attaque DCShadow contrôleur de domaine pirate (enregistrement d'un contrôleur de domaine pirate) — révélée publiquement par Benjamin Delpy et Vincent Le Toux (créateurs de Mimikatz) lors de BlueHat IL en janvier 2018 — permet à un attaquant disposant de droits suffisants d'enregistrer temporairement une machine compromise comme contrôleur de domaine et de pousser des modifications d'objets Active Directory vers le reste du domaine via le protocole de réplication normal, plutôt que via une API d'écriture standard. MITRE ATT&CK la catalogue sous T1207 — Rogue Domain Controller.

Cet article couvre le mécanisme, pourquoi il échappe à la journalisation qui détecte normalement les modifications AD privilégiées, ainsi que des étapes concrètes de détection et de remédiation. Pour la technique d'abus de réplication plus courante — lire des secrets plutôt qu'écrire des modifications — voir Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin et Supervision Sécurité AD : Événements Clés pour la base d'audit de réplication plus large que cette technique est conçue pour contourner.

L'Attaque DCShadow Contrôleur de Domaine Pirate Expliquée

Chaque contrôleur de domaine d'Active Directory est représenté dans l'annuaire lui-même : un objet server et un objet nTDSDSA enfant sous le contexte de nommage Configuration (CN=Sites), la même classe d'objets créée à chaque promotion d'un vrai DC. DCShadow abuse du fait que tout principal détenant les droits de réplication appropriés peut créer cette même paire d'objets sur une machine qui n'est pas réellement un contrôleur de domaine — puis utiliser le protocole RPC légitime Directory Replication Service (DRS) pour faire en sorte que le reste du domaine tire des « modifications » depuis cette machine comme s'il s'agissait d'un pair de confiance.

⚠️

⚠️ Avertissement : parce que la modification arrive via réplication plutôt que via des écritures LDAP ou le journal Security local d'un DC, DCShadow ne génère pas les événements sur lesquels les équipes sécurité s'appuient normalement pour détecter une altération AD privilégiée — pas de 4738 (compte utilisateur modifié), pas de 5136 (objet du service d'annuaire modifié) lié à la modification elle-même.

DCShadow est distinct de DCSync. DCSync (DS-Replication-Get-Changes) abuse des droits de réplication pour lire des secrets — le plus souvent pour dumper des hashes de mots de passe depuis la perspective d'un DC légitime. DCShadow abuse d'un ensemble différent, mais adjacent, de droits de réplication pour écrire — il fabrique une source de réplication pirate et injecte des modifications dans l'annuaire. Les deux techniques sont souvent confondues car elles partagent la même famille de protocole sous-jacente (MS-DRSR) et la même question d'audit « qui détient des droits proches de DCSync », mais ce sont des primitives d'attaque distinctes avec des surfaces de détection distinctes.

Comment ça Fonctionne

Étape 1 — Acquérir les Droits

Selon une recherche indépendante sur les permissions minimales publiée par Lab of a Penetration Tester en avril 2018, DCShadow n'exige pas strictement une appartenance Domain Admin ou Enterprise Admin — c'est le chemin le plus courant, mais la technique peut aussi fonctionner avec un ensemble plus restreint de droits accordés directement sur l'objet domaine : les droits étendus DS-Install-Replica ({9923a32a-3607-11d2-b9be-0000f87a36b2}, selon la référence ADSchema de Microsoft), DS-Replication-Manage-Topology, et DS-Replication-Synchronize ({1131f6ab-9c07-11d1-f79f-00c04fc2dcd2}, selon la référence ADSchema de Microsoft) — plus suffisamment de WriteProperty sur l'objet ordinateur de la machine attaquante elle-même (voir Surface d'attaque des objets ordinateur Active Directory pour la classe de risque plus large) pour définir ses Service Principal Names. C'est pourquoi le catalogue d'EtcSec suit qui détient les droits Server Trust Account comme un constat distinct et critique : c'est la précondition qui rend possible l'enregistrement d'un DC pirate en premier lieu, indépendamment du fait que ce compte soit aussi Domain Admin.

Étape 2 — Enregistrer le DC Pirate

Via le module lsadump::dcshadow, Mimikatz (exécuté avec les privilèges SYSTEM sur la machine attaquante) définit deux Service Principal Names sur le compte ordinateur compromis, puis crée les objets server et nTDSDSA dans la partition Configuration. Selon la stratégie de détection DET0276 de MITRE, les SPN utilisés sont le SPN Global Catalog (GC/<hostname>/<domain>) et le SPN de l'interface Directory Replication Service (E3514235-4B06-11D1-AB04-00C04FC2DCD2/<guid>/<domain>) — les mêmes classes de SPN que porte un DC légitime, ce qui est précisément ce qui permet à la machine de se faire passer pour un DC à des fins de réplication.

Étape 3 — Pousser la Modification

Une fois le DC pirate enregistré et les SPN en place, une seconde commande lsadump::dcshadow /push déclenche un événement de réplication sortant : la modification d'objet ou d'attribut fabriquée (une réécriture d'ACL, une appartenance à un groupe, un msDS-KeyCredentialLink, un attribut de schéma — DCShadow peut cibler pratiquement n'importe quelle donnée AD accessible en écriture) est répliquée depuis la machine de l'attaquant vers un vrai DC via IDL_DRSReplicaAdd/GetNCChanges, exactement comme si elle provenait d'un DC pair.

Étape 4 — Se Désenregistrer et Disparaître

L'attaquant supprime les objets server et nTDSDSA pirates, restaure les SPN d'origine, et la machine redevient apparemment un simple ordinateur joint au domaine ordinaire. La modification malveillante, elle, a déjà été répliquée sur tous les vrais DC du domaine et persiste dans l'annuaire.

Détection

Les étapes d'enregistrement et de désenregistrement constituent la fenêtre détectable — la modification poussée elle-même, une fois répliquée, ressemble à n'importe quel autre attribut d'annuaire.

Indicateur	Event ID	Source	Description
Contexte de nommage source de réplique établi	4928	DC — sous-catégorie « Audit Detailed Directory Service Replication »	Selon la référence d'événements de Microsoft, se déclenche lorsqu'un DC commence à traiter une source comme partenaire de réplication. Sur un DC légitime, cela correspond aux promotions connues ; un Source DRA inattendu est le signal à surveiller.
Contexte de nommage source de réplique supprimé	4929	DC — même sous-catégorie	Selon la référence d'événements de Microsoft, se déclenche lors du désenregistrement — l'étape de nettoyage de DCShadow. Une paire 4928/4929 rapprochée, provenant d'un hôte qui n'est pas un DC connu, est un signal fort.
Compte ordinateur modifié	4742	DC — « Audit Computer Account Management »	Selon la référence d'événements de Microsoft, se déclenche lorsque les SPN de la machine attaquante sont définis. Recoupez le Subject (le compte effectuant la modification) avec votre liste connue de détenteurs Domain Admin / Server Trust Account.
Création d'objet nTDSDSA / server dans le NC Configuration	—	Directory Service Changes (5137), nécessite une SACL sur `CN=Sites,CN=Configuration`	Active Directory n'audite pas la partition Configuration par défaut. Une SACL sur le conteneur Sites est nécessaire avant que ce signal n'existe — cela correspond directement à la corrélation « objets nTDSDSA/server inattendus » recommandée par MITRE DET0276.
Utilisation inattendue de SPN DRS	—	Corrélation authentification Kerberos / SIEM	Selon MITRE DET0276, une authentification Kerberos utilisant les classes de SPN `GC/` ou `E3514235-4B06-11D1-AB04-00C04FC2DCD2` depuis un hôte hors de la liste des DC connus.

💡

💡 Conseil : aucun des signaux de la partition Configuration ci-dessus n'est capturé par défaut. Si votre seule visibilité sur la réplication est la politique d'audit par défaut du NC du domaine, vous ne verrez pas un enregistrement de DC pirate DCShadow. C'est précisément la faille que la technique est conçue pour exploiter — l'outillage sourcé (analyse de SentinelOne) recommande de traiter la paire 4928/4929 et les SACL du NC Configuration comme la base, pas comme un ajout optionnel.

Remédiation

1. Auditer Qui Détient les Droits Server Trust Account et Réplication-Écriture

La précondition d'une attaque DCShadow est un principal détenant DS-Install-Replica, DS-Replication-Manage-Topology, et DS-Replication-Synchronize sur l'objet domaine — ou des droits plus larges permettant de définir les SPN d'un compte ordinateur. Énumérez cela de la même façon que vous auditeriez les comptes capables de DCSync, mais pour les droits étendus côté écriture :

# Enumérer les principals non-standard avec des droits étendus de réplication sur l'objet domaine
$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"
$acl.Access |
  Where-Object { $_.ActiveDirectoryRights -match "ExtendedRight" } |
  Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Recoupez chaque résultat avec votre appartenance attendue Domain Admin / Enterprise Admin — tout le reste est un droit non documenté à investiguer.

2. Activer l'Audit de la Partition Configuration

Les modifications du NC Configuration ne sont pas auditées par défaut. Appliquez une SACL sur CN=Sites,CN=Configuration,DC=<domain> (et idéalement sur la racine du NC Configuration) afin que la création/suppression d'objets nTDSDSA et server génère des événements Directory Service Changes (5136/5137), et activez la sous-catégorie « Audit Detailed Directory Service Replication » à l'échelle du domaine afin que 4928/4929 soient capturés.

3. Minimiser et Cloisonner les Accès Privilégiés

💡

💡 Quick Win : traitez « qui peut s'enregistrer comme DC » comme une question Tier 0, pas seulement comme « qui est Domain Admin ».

Suivez un modèle d'administration cloisonné — voir Durcissement Active Directory : quoi verrouiller d'abord et comment le valider — afin que les comptes capables de détenir des droits de réplication-écriture soient le même petit ensemble surveillé que vous traitez déjà comme Tier 0, sans appartenance permanente au-delà de ce qui est activement nécessaire. C'est la même discipline qui empêche la dérive des accès privilégiés plus largement.

4. Alerter sur la Paire 4928/4929 Corrélée aux DC Connus

Construisez une règle de détection qui signale tout 4928 (et son 4929 associé) dont le Source DRA ne correspond pas à votre inventaire maintenu de contrôleurs de domaine légitimes. Comme une fenêtre d'enregistrement DCShadow est généralement brève, le forwarding de logs quasi temps réel compte ici plus que pour la plupart des détections AD — une revue par lot quotidienne s'exécutera généralement après que le DC pirate se soit déjà désenregistré.

Comment EtcSec Détecte Cela

Le catalogue de vulnérabilités AD d'EtcSec signale cette exposition via deux vérifications : DCSHADOW_EVIDENCE, qui recherche des preuves directes qu'un enregistrement de DC pirate DCShadow a eu lieu, et SERVER_TRUST_ACCOUNT_RIGHT, qui signale les comptes et groupes détenant les droits permettant de définir un server trust account — la précondition qui rend la technique viable, que le compte soit aussi Domain Admin ou non. Les environnements qui ont déjà revu leurs comptes capables de DCSync devraient traiter ceci comme l'audit compagnon : les droits de réplication en lecture et en écriture sont généralement accordés par les mêmes erreurs de délégation, mais rarement revus ensemble.

ℹ️

ℹ️ Note : EtcSec vérifie automatiquement les preuves DCShadow et les droits Server Trust Account lors de chaque audit AD. Lancez un audit gratuit pour vérifier si votre environnement porte cette exposition.

Attaque DCShadow Contrôleur de Domaine Pirate : Comment Elle Contourne l'Audit des Modifications AD