ADReplicationInspector : Détection des Attaques AD

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.

Configuration avancee et tuning d'ADReplicationInspector

Le deploiement initial d'ADReplicationInspector avec ses parametres par defaut fournit une couverture de detection immediate mais le plein potentiel de l'outil est atteint apres un travail de tuning adapte a l'environnement Active Directory specifique de l'organisation. La premiere etape consiste a etablir une baseline du trafic de replication normal sur un minimum de deux semaines couvrant les cycles habituels d'activite — jours ouvrables, week-ends, periodes de forte charge comme les campagnes de mise a jour mensuelles. Cette baseline permet de calibrer les seuils d'alerte pour distinguer les anomalies reelles des variations normales lies aux specificites de l'environnement.

La configuration des exclusions est un aspect critique du tuning pour maintenir un rapport signal/bruit acceptable. Dans les grands environnements AD avec des centaines de controleurs de domaine et des milliers de comptes de service, certains patterns d'acces a la replication peuvent ressembler superficiellement a des attaques DCSync mais correspondre en realite a des processus legitimes — sauvegardes AD, synchronisation d'IDaaS, agents de monitoring de l'etat de la replication. Les exclusions doivent etre documentees avec leur justification et revues periodiquement pour s'assurer qu'elles restent valides et n'ont pas ete detournees par un attaquant pour masquer ses activites.

L'integration avec les comptes privileges existants de l'organisation est une configuration importante pour la qualite de la detection. ADReplicationInspector peut etre configure avec la liste des comptes qui ont legitimement droit aux permissions de replication AD — comptes de sauvegarde, agents de monitoring, comptes de synchronisation IDM — pour ne alerter que sur les acces provenant de comptes non repertories dans cette liste blanche. Cette liste blanche doit etre maintenue a jour et faire l'objet d'une revue trimestrielle en coordination avec les equipes en charge de la gestion des identites et acces privilegies.

ADReplicationInspector dans une strategie de detection Active Directory complete

ADReplicationInspector s'inscrit dans un ecosysteme de detection Active Directory qui doit couvrir plusieurs vecteurs d'attaque complementaires. Les attaques contre AD les plus sophistiquees combinent generalement plusieurs techniques : reconnaissance initiale par enumeration LDAP, mouvement lateral par Pass-the-Ticket ou Kerberoasting, persistance par creation de Golden Tickets ou de Backdoor Accounts, et acces aux secrets via DCSync ou dump de la base NTDS. Aucun outil seul ne couvre l'ensemble de ces vecteurs, et ADReplicationInspector doit etre combine avec d'autres capacites de detection pour offrir une couverture complete.

La correlation des alertes ADReplicationInspector avec d'autres sources de telemetrie AD est ce qui permet de detecter des attaques avancees que la detection unitaire manquerait. Un acces DCSync isole peut etre difficile a distinguer d'une operation de sauvegarde si l'on ne dispose pas du contexte. Mais combine avec une serie d'authentifications Kerberos anormales sur les memes plages horaires, des acces LDAP inhabituels aux attributs sensibles des comptes privilegies et une connexion RDP vers un controleur de domaine depuis un poste utilisateur standard, le tableau d'ensemble revele clairement une sequence d'attaque coherente que chaque signal isolement n'aurait pas pu identifier.

La contribution a la communaute de detection AD est un aspect important de l'utilisation professionnelle d'outils comme ADReplicationInspector. Les equipes qui decouvrent de nouvelles techniques d'attaque ou de contournement des detecteurs existants sont encouragees a partager leurs recherches via des publications, des presentations en conference (SSTIC, HITB, BlueHat) ou des contributions directes aux projets open source. Cette culture de partage dans la communaute defensive AD accelere l'amelioration collective des capacites de detection face a des adversaires qui partagent eux-memes leurs techniques via des forums specialises et des repositories d'outils offensifs accessibles publiquement.

L'evaluation reguliere de l'efficacite d'ADReplicationInspector dans le contexte evolutif des attaques Active Directory necessite des exercices de red team specifiques AD planifies au moins annuellement. Ces exercices simulent les techniques d'attaque les plus recentes contre AD — DCSync, DCShadow, Golden Ticket, Silver Ticket, Kerberoasting de comptes privilegies, delegation Kerberos non contrainte — pour verifier que les detecteurs en place identifient correctement ces techniques et que les alertes generees sont traitees dans des delais acceptables par les analystes SOC. Les lacunes identifiees lors de ces exercices alimentent directement les ameliorations de la configuration d'ADReplicationInspector et les ajouts de regles de detection complementaires dans le SIEM, creant une boucle d'amelioration continue fondee sur des tests en conditions realistes.

La veille sur les nouvelles techniques d'attaque contre la replication AD est une activite continue indispensable pour maintenir la pertinence des detecteurs dans le temps. La communaute de securite offensive publie regulierement de nouvelles variantes et ameliorations des techniques d'attaque contre AD — contournement des detections existantes, nouvelles facon d'abuser des permissions de replication, exploitation de fonctionnalites AD peu documentees. Les ressources de reference incluent les publications de chercheurs comme Dirk-jan Mollema, Will Schroeder et Charlie Clark sur les fonctionnalites avancees d'AD, les presentations des conferences specialisees comme BlueHat, et les mises a jour des frameworks offensifs comme BloodHound, Impacket et PowerSploit qui implementent ces techniques sous forme d'outils utilisables par les red teams et les attaquants qui testent legitimement ou exploitent malicieusement les environnements Active Directory en entreprise et dans les competitions CTF. Rester informe de ces evolutions permanentes est la condition necessaire pour que les detecteurs implementes dans ADReplicationInspector restent pertinents et efficaces face a un paysage de techniques d'attaque AD qui ne cesse de s'enrichir et de se sophistiquer annee apres annee.

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.