ADReplicationInspector : détection des attaques de réplication Active Directory

ADReplicationInspector est un outil Python open source que je publie sur le portfolio github de Ayi Nedjimi pour surveiller en continu les opérations de réplication Active Directory. Le projet collecte les événements DSReplicaSync, DRSUAPI et les traces Sysmon générés par les contrôleurs de domaine, puis applique une couche d'analyse comportementale pour distinguer une réplication légitime initiée par un DC partenaire d'une exfiltration de hachés via DCSync, d'un branchement frauduleux de DC fantôme via DCShadow ou d'un usage anormal d'un Golden Ticket Kerberos. L'objectif est de fournir aux équipes SOC et aux Tier 0 administrators une détection précoce, lisible et corrélée des techniques d'attaque AD les plus critiques, sans dépendre d'un EDR propriétaire ni d'une licence Microsoft Defender for Identity. L'outil expose ses détections sous forme d'événements normalisés ECS, prêts à être ingérés dans Wazuh, Elastic SIEM, Splunk ou un Sentinel hybride.

Pourquoi un outil dédié à la réplication Active Directory

La réplication est le cœur battant d'Active Directory. Sans elle, plus de propagation des mots de passe, plus de mise à jour des stratégies de groupe, plus de cohérence du SYSVOL entre sites. Cette criticité explique pourquoi les attaquants ciblent la couche réplication : en se faisant passer pour un contrôleur de domaine légitime via le protocole DRSUAPI, ils peuvent extraire la totalité des hachés NTLM stockés dans la base NTDS.dit, y compris le compte krbtgt qui sert à signer les tickets Kerberos.

Les techniques DCSync et DCShadow, popularisées par Mimikatz et par les frameworks offensifs modernes type Impacket, exploitent précisément les routines de réplication exposées par tout DC. Une fois krbtgt compromis, l'attaquant forge des Golden Tickets indétectables par les contrôles d'authentification traditionnels. La fenêtre de détection sur ce type d'incident se compte en minutes, pas en jours. ADReplicationInspector est conçu pour fermer cette fenêtre.

À quoi sert ADReplicationInspector

L'outil répond à quatre besoins opérationnels qu'aucun produit gratuit n'adresse simultanément. D'abord, il consolide les sources de télémétrie Active Directory dispersées entre les journaux Sécurité, le canal Directory Service, le canal DFS Replication et les événements Sysmon. Ensuite, il applique une logique métier qui sait, par exemple, qu'une réplication entre deux DC du même site est légitime mais qu'un appel DRSGetNCChanges initié depuis un poste utilisateur est par définition suspect. Troisièmement, il génère des alertes enrichies en contexte : utilisateur émetteur, machine cible, partition de naming context, technique MITRE ATT&CK associée. Enfin, il publie ces alertes au format Common Information Model pour que les SIEM existants n'aient pas à apprendre un nouveau schéma.

Architecture interne et pipeline de détection

ADReplicationInspector suit une architecture en quatre étages, chacun implémenté dans un module Python isolé. Le premier étage est la couche de collecte. Elle s'appuie sur la bibliothèque pywinrm pour interroger les contrôleurs de domaine en pull, ou sur un agent WEC quand l'organisation dispose déjà d'un collecteur d'événements Windows. Les canaux suivis sont Security, Directory Service, DFS Replication et Microsoft-Windows-Sysmon/Operational.

Le deuxième étage est le normalisateur ECS. Chaque évènement Windows brut est traduit dans la nomenclature Elastic Common Schema avec les champs event.category, event.action, event.outcome, source.user.name et destination.host.hostname. Cette étape supprime le verbiage inutile et homogénéise les payloads entre Sysmon et Event Log natif.

Le troisième étage est le moteur de règles. Il regroupe une trentaine de patrons écrits en YAML qui couvrent les principales techniques de la matrice MITRE ATT&CK appliquée à Active Directory : T1003.006 OS Credential Dumping DCSync, T1207 Rogue Domain Controller DCShadow, T1558.001 Golden Ticket, T1484.001 Domain Trust Modification et T1098.007 Account Manipulation Additional Domain Controller. Les règles utilisent une syntaxe Sigma simplifiée pour faciliter la contribution communautaire.

Le quatrième étage est le publisher. Il pousse les alertes finalisées vers une destination configurable : webhook HTTP, Kafka, Elastic Bulk API, Splunk HEC, Wazuh active response. Chaque alerte contient le hash sha256 de l'évènement source pour permettre la réconciliation après coup.

Détections couvertes en détail

La détection DCSync repose sur l'évènement Security 4662 contenant l'accès à l'objet Naming Context avec les droits DS-Replication-Get-Changes ou DS-Replication-Get-Changes-All. L'outil rejette les corrélations émises par des comptes machine DC connus et lève une alerte critique quand le SID source appartient à un compte utilisateur, à un compte de service ou à un poste de travail.

La détection DCShadow combine deux signaux : l'apparition d'un nouvel objet nTDSDSA dans le conteneur Sites and Services et l'observation d'un Inter-Site-Topology checksum incohérent. Les attaquants utilisent souvent une session RPC ouverte depuis un poste compromis, ce qui se traduit par des événements Sysmon 3 vers le port 135 puis vers des ports dynamiques au-delà de 49152.

La détection Golden Ticket s'appuie sur l'analyse des tickets Kerberos visibles via les événements 4769 et 4624. Un Golden Ticket forgé hors ligne contient souvent un PAC mal calibré, une durée de vie de dix ans et un encryption type légacy RC4-HMAC. La règle combine ces trois indicateurs pour limiter les faux positifs.

L'outil suit également les modifications de la stratégie d'audit, les ajouts au groupe Enterprise Admins, les changements de la propriété AdminSDHolder et les écritures sur le SPN du compte krbtgt. Ces signaux ne sont pas en eux-mêmes des attaques mais participent à un faisceau d'indices essentiel pour les chasseurs de menaces avancés.

Cas d'usage opérationnels

Une banque de taille intermédiaire a déployé ADReplicationInspector sur six contrôleurs de domaine pour surveiller un environnement multi-sites en complément de Wazuh. L'équipe SOC a remplacé une règle native qui produisait trop de bruit par les détections enrichies de l'outil et constaté une diminution de 80 pour cent des alertes faibles tout en gardant les vraies détections DCSync issues d'un test red team interne.

Un cabinet d'audit l'utilise lors de ses missions d'évaluation Active Directory comme baseline de visibilité. En une journée, l'auditeur déploie l'outil, observe les flux de réplication réels et identifie immédiatement les zones d'ombre : comptes machine non rattachés à un DC connu, comptes de service avec droits DS-Replication-Get-Changes, anomalies sur AdminSDHolder.

Une équipe purple team s'appuie sur l'outil pour valider la couverture de détection après chaque exercice d'attaque simulé via Atomic Red Team ou Caldera. Les patrons YAML servent de référence : si une technique est exécutée mais ne déclenche aucune règle, l'écart est documenté et corrigé en sprint suivant.

Un MSSP intègre ADReplicationInspector comme couche complémentaire dans son offre managée Active Directory. L'outil tourne dans un conteneur isolé sur le SOC central, ingère les événements multi-clients via un bus Kafka et publie les alertes dans un Sentinel multi-tenant.

Enfin, un CERT gouvernemental utilise l'outil sur les forêts qu'il assiste lors d'incidents majeurs. La capacité à fonctionner en mode pull sans agent installe est un avantage décisif quand la confiance dans les binaires du SI compromis n'est plus garantie.

Installation rapide

Le projet est testé sur Python 3.11 et Windows Server 2019 et plus récent. La procédure ci-dessous décrit un déploiement collector sur une machine Linux Debian 12 séparée du domaine, qui interroge les DC via WinRM TLS.

git clone https://exemple.local/adreplicationinspector.git
cd adreplicationinspector
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
cp config.example.yml config.yml
nano config.yml  # renseigner les DC, le compte de lecture, la sortie SIEM
python3 -m adri.run --config config.yml --once

Pour un service systemd en production, un fichier unit prêt à l'emploi est inclus dans le dépôt. Le compte de service utilisé doit appartenir au groupe Event Log Readers et disposer du droit Read sur les attributs de schéma de réplication. Aucun privilège Domain Admin n'est requis.

Intégration SIEM et alerting

Trois intégrations sont prêtes à l'emploi. La première vise Wazuh : l'outil publie ses alertes sous forme de décodeurs JSON consommés par le decoder natif json, ce qui permet d'écrire des règles Wazuh standard de niveau 12 à 14 selon la criticité de la technique. La deuxième cible Elastic Security : les documents sont indexés dans logs-windows.adreplication-default avec un mapping ECS strict, compatible avec les règles de détection préfabriquées de la stack Elastic.

La troisième intégration concerne Splunk via HTTP Event Collector. Un fichier d'index source-type prêt à l'emploi est livré pour faciliter le mapping. Pour Microsoft Sentinel, un pipeline Logstash exemple est documenté : il ingère les alertes ADReplicationInspector dans une table custom et offre des KQL queries prêtes pour l'analyste.

Comparaison avec les solutions natives Microsoft

Microsoft Defender for Identity, anciennement Azure ATP, couvre une partie significative des détections de réplication mais reste payant et lié à un abonnement Microsoft 365 E5 ou un add-on dédié. La couverture DCShadow notamment requiert l'installation d'un capteur sur chaque DC et la collecte centralisée passe par le cloud Microsoft, ce qui pose parfois des questions de souveraineté ou de confidentialité.

ADReplicationInspector ne prétend pas remplacer Defender for Identity dans sa totalité : il ne couvre pas les comportements comportementaux Kerberos très avancés ni la corrélation avec les signaux d'identité Entra ID. En revanche, il offre une couche de détection open source, auditable et déployable en quelques minutes sur un environnement on-premise. Il s'inscrit donc en complément d'une solution payante existante ou en alternative pour les organisations sans budget EDR identité.

Limites et roadmap

L'outil hérite des limites du logging Windows. Si l'audit avancé de Directory Service Changes n'est pas activé, certaines détections perdent en finesse. Une checklist de hardening du logging est fournie dans le README pour activer les sous-catégories d'audit requises. De même, la collecte par WinRM impose une latence d'environ trente secondes par défaut. Pour les environnements demandant une détection en temps réel, l'usage d'un collecteur WEC est recommandé.

La feuille de route inclut quatre axes principaux. Premier axe, ajout d'un module d'analyse Kerberos PAC permettant de détecter les anomalies de claims dans les tickets, en s'appuyant sur la nouvelle version du PAC Validation côté Windows Server 2022. Deuxième axe, support natif de la collecte via OpenTelemetry pour s'intégrer aux pipelines d'observabilité modernes. Troisième axe, ajout de détections Entra Connect Sync pour couvrir les attaques hybrides AD on-premise et cloud. Quatrième axe, publication d'un dashboard Grafana prêt à brancher sur la sortie Loki ou Elastic.

L'outil reste un projet personnel maintenu sur le temps disponible. Les contributions communautaires sont encouragées via pull request, en suivant les guidelines documentées dans le dépôt.

FAQ

ADReplicationInspector remplace-t-il un EDR sur les contrôleurs de domaine ?

Non. L'outil se concentre exclusivement sur la couche réplication et les techniques d'attaque qui en dérivent. Il ne couvre ni la détection comportementale processus, ni l'analyse mémoire, ni la prévention en temps réel. Il est conçu pour compléter un EDR, pas pour le remplacer. Sur un DC bien protégé, ADReplicationInspector apporte la spécialisation que les EDR généralistes négligent souvent sur les protocoles AD profonds.

Quels privilèges Active Directory faut-il pour exécuter l'outil ?

Aucun privilège élevé. Un compte standard appartenant au groupe Event Log Readers suffit pour lire les journaux Security et Directory Service. Si la collecte passe par WinRM, le compte doit être autorisé sur l'endpoint Microsoft.PowerShell. Le principe du moindre privilège est strictement respecté : l'outil ne modifie rien dans Active Directory, il ne fait que lire.

Pourquoi détecter DCShadow est-il plus difficile que DCSync ?

Parce que DCShadow s'appuie sur l'écriture d'un objet nTDSDSA transitoire dans Sites and Services puis sur une routine RPC légitime de réplication. Les événements correspondants sont par défaut moins audités que les accès DRSUAPI. ADReplicationInspector combine plusieurs signaux faibles pour reconstituer la chaîne d'attaque, là où une règle isolée passerait à côté.

Comment ADReplicationInspector se comporte-t-il avec un Read-Only Domain Controller ?

Les RODC sont supportés. Les règles d'analyse savent qu'un RODC ne réplique que des sous-ensembles d'attributs et adaptent les seuils en conséquence. Une alerte est levée si un RODC tente une opération DRSGetNCChanges en mode complet, ce qui constitue un signal d'intrusion fort.

Pour aller plus loin

Le code source complet ainsi que la documentation technique sont publiés sur le portfolio /github du compte Ayi Nedjimi, aux côtés des autres outils open source du projet. Pour approfondir la défense Active Directory, consultez le guide de sécurisation Active Directory 2025, le panorama top 10 attaques Active Directory, l'analyse exploitation Kerberos sur Active Directory et l'article RBCD, attaque et défense. Pour la corrélation côté SIEM, l'article déploiement Wazuh SIEM/XDR open source apporte une perspective opérationnelle complémentaire.