Le contrôleur de domaine comme pivot de mouvement latéral

Concept

Un contrôleur de domaine (DC) est le cœur névralgique d’un environnement Active Directory. Il héberge la base ntds.dit, le service KDC Kerberos, le rôle de serveur DNS, les partages SYSVOL et NETLOGON, et applique les stratégies de groupe (GPO).

Lorsqu’un attaquant compromet un DC (par exemple via DCSync, compromission d’identifiants Tier 0, ou vulnérabilité de type Zerologon / NoPac), il cesse de le considérer comme une simple base de données : il le transforme en nœud de distribution offensif (Lateral Movement Hub) :

Canal de connectivité garanti : les DC disposent par conception de flux réseau ouverts vers l’intégralité des serveurs et postes clients du parc (SMB 445, WMI/RPC 135, WinRM 5985/5986, DNS 53).
Autorité de sécurité universelle : le compte de machine du DC (DC$) et les comptes administratifs du domaine ont le droit d’ouvrir des sessions administratives sur tous les systèmes membres.
Moyens de diffusion de masse intégrés : les mécanismes d’administration centralisée (GPOs, scripts de démarrage, réplication SYSVOL, WMI multi-hôtes) permettent d’exécuter du code simultanément sur tout le parc.

Pourquoi c’est important en DFIR

Identifier si un DC a servi de pivot réoriente complètement la chronologie et la portée de l’enquête :

Confusion entre « compromis » et « utilisé pour propager » : un DC peut avoir été compromis à 02h00 sans modification de fichiers locaux, puis utilisé à 04h00 pour exécuter un script PowerShell propageant un ransomware sur 500 serveurs via SMB/WMI. L’enquêteur doit analyser les connexions sortantes du DC.
Rôle des partages SYSVOL et NETLOGON : les attaquants utilisent fréquemment ces partages répliqués pour héberger leurs binaires ou scripts malveillants. Comme chaque machine lit régulièrement SYSVOL pour appliquer les GPOs, le binaire est téléchargé de façon totalement légitime par les clients.
Artefacts d’exécution distants : les outils offensifs exécutés depuis le DC (ex: PsExec, Invoke-TheHash, scripts wmiexec personnalisés) laissent des traces de processus sortants spécifiques dans le journal Security et dans la mémoire vive du DC.

Comment ça fonctionne

Topologie du DC utilisé comme hub d’attaque

                            ┌─────────────────────────────────┐
                            │    Contrôleur de Domaine (DC)   │
                            │      (Compromis par l'attaquant) │
                            └────────────────┬────────────────┘
                                             │
             ┌───────────────────────────────┼───────────────────────────────┐
             │ 1. SMB / RPC (Port 445/135)   │ 2. SYSVOL / GPO               │ 3. WinRM (Port 5985)
             ▼                               ▼                               ▼
┌─────────────────────────┐     ┌─────────────────────────┐     ┌─────────────────────────┐
│     Serveur SQL         │     │     Parc de Postes      │     │    Serveur Web DMZ      │
│ (PsExec / wmiexec)      │     │ (Script de démarrage)   │     │ (Invoke-Command)        │
└─────────────────────────┘     └─────────────────────────┘     └─────────────────────────┘

Rebond direct via SMB/RPC (push) : l’attaquant lance depuis le DC un outil de déploiement qui se connecte en boucle sur le port 445 de chaque machine du parc en utilisant le compte Domain Admins.
Rebond passif via GPO / SYSVOL (pull) : l’attaquant modifie une GPO existante ou crée une GPO malveillante liée à l’OU racine du domaine. Les clients contactent le DC lors de leur rafraîchissement périodique (toutes les 90 minutes ou au démarrage) et exécutent la charge utile.
Rebond via PowerShell Remoting (WinRM) : l’attaquant exécute Invoke-Command -ComputerName (Get-ADComputer -Filter *) -ScriptBlock { ... } directement depuis la session du DC.

Ce qui est possible

Déployer un payload sur 100% des machines en quelques minutes : les flux réseau entre DC et machines de domaine étant systématiquement autorisés par les pare-feux, aucune segmentation réseau interne ne bloque ces mouvements sortants.
Utiliser les outils administratifs natifs (LOLBins) : l’attaquant utilise psexec.exe, wmic.exe, powershell.exe ou cscript.exe déjà installés sur le DC pour masquer ses actions sous une apparence d’administration légitime.
Exploiter les sessions administratives ouvertes sur le DC : si d’autres administrateurs sont connectés en RDP ou en console sur le DC, l’attaquant peut injecter du code dans leurs processus ou voler leurs jetons d’accès.

Ce qui n’est pas possible

Masquer complètement les traces de connexions sortantes : le pare-feu Windows du DC, la table de connexions réseau actives (Netstat) et les logs EDR/Sysmon conservent les traces des sockets sortants vers les ports 445, 135 ou 5985 des clients.
Exécuter du code sur les machines éteintes OU déconnectées : si les machines sont hors tension, les connexions directes SMB/RPC échouent et génèrent des erreurs de timeout réseau caractéristiques.
Modifier les fichiers SYSVOL sans laisser de traces de réplication : toute modification de GPO ou de script dans SYSVOL déclenche la réplication DFSR (Distributed File System Replication) vers tous les autres contrôleurs de domaine de la forêt.

Confusions fréquentes en DFIR

Confusion fréquente	Réalité forensique vérifiable
« Les DC ne se connectent jamais aux postes clients. »	En fonctionnement normal, les DC reçoivent des connexions entrantes des clients. Des connexions sortantes massives depuis un DC vers des ports 445 OU 5985 des postes clients sont une anomalie critique.
« Si le DC est compromis, le ransomware s’est exécuté en premier sur le DC. »	Souvent, les attaquants chiffrent le DC en tout dernier lieu, après avoir ordonné le chiffrement de tous les serveurs et postes pour éviter de bloquer l’infrastructure trop tôt.
« L’analyse du DC suffit pour comprendre toute l’attaque. »	Le DC ne conserve pas les logs d’exécution locale des clients. La confirmation de l’impact exige d’analyser les endpoints ciblés.

Exemple concret d’investigation

Dans une crise majeure impliquant le ransomware LockBit :

Les analystes découvrent que 1 200 postes ont été chiffrés en 45 minutes.
L’analyse du journal de sécurité du contrôleur de domaine DC01 révèle :
- À 03h12 UTC : exécution de powershell.exe sous le compte CORP\da_admin.
- Ligne de commande Sysmon Event 1 : powershell.exe -ExecutionPolicy Bypass -File C:\ProgramData\deploy.ps1.
- Le script contenait une boucle lisant les adresses IP du domaine et exécutant net use \\<IP>\C$ suivi du lancement d’un service distant via WMI (wmic /node:<IP> process call create "C:\Windows\Temp\locker.exe").
À 03h58 UTC : une fois la boucle terminée, le processus de chiffrement local a été déclenché sur DC01.
Constat DFIR : le DC a servi de tour de contrôle pour l’orchestration du déploiement avant son propre suicide informatique.

Artefacts et traces forensiques

Journaux de sécurité et Sysmon sur le contrôleur de domaine :
- Sysmon event ID 3 (network connection) : connexions réseau sortantes depuis le DC avec DestinationPort: 445 ou 5985 ciblant des stations de travail.
- Sysmon event ID 1 / event 4688 (process creation) : lancement de scripts de déploiement, wmic.exe, psexec.exe, paexec.exe.
- Event ID 4624 (logon type 2 / 10) : connexion interactive ou RDP initiale de l’attaquant sur le DC.
Journaux de sécurité sur les machines cibles :
- Event ID 4624 (logon type 3) : connexion réseau SMB où IpAddress correspond à l’adresse IP du DC !
- Event ID 7045 : installation d’un service distant initié depuis l’adresse IP du DC.

Méthodes d’investigation

Auditer les connexions réseau sortantes du DC : Analyser les flux réseau issus de l’adresse IP du DC vers le sous-réseau des utilisateurs et des serveurs applicatifs.
Examiner les répertoires partagés SYSVOL et NETLOGON : Vérifier les dates de dernière modification des scripts .bat, .vbs, .ps1 et des exécutables dans \\domain\SYSVOL\domain\scripts.
Rechercher les processus sortants suspects sur le DC : Traquer les processus parents cmd.exe ou powershell.exe ayant initié des connexions RPC/SMB distantes.

Outils d’investigation

Chainsaw / hayabusa : Détection des connexions d’administration de masse et des LOLBins exécutés depuis des serveurs de domaine.

PowerShell / Get-WinEvent :

# Identifier les connexions réseau Type 3 reçues depuis un DC
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} |
  Where-Object { $_.Properties[7].Value -eq 3 -and $_.Properties[18].Value -eq '10.0.1.10' } | # IP du DC
  Select-Object TimeCreated, @{N='User';E={$_.Properties[5].Value}}, @{N='Workstation';E={$_.Properties[11].Value}}

Points clés à retenir

Le contrôleur de domaine est couramment utilisé comme pivot de diffusion massive.
Les connexions sortantes massives d’un DC vers des ports 445/WMI/WinRM de postes clients constituent une anomalie forensique majeure.
Les attaquants exploitent les partages SYSVOL et les GPOs pour automatiser l’exécution de code sur l’ensemble du parc.