{
	"id": "2bbbe843-b51c-40e5-8b16-64f08a00d8b6",
	"created_at": "2026-04-06T00:18:45.527338Z",
	"updated_at": "2026-04-10T13:12:32.943086Z",
	"deleted_at": null,
	"sha1_hash": "ff881befb1dd78e1cd727767bac25c90667ae52b",
	"title": "Détecter DCShadow, impossible ?",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1138185,
	"plain_text": "Détecter DCShadow, impossible ?\r\nArchived: 2026-04-05 18:49:33 UTC\r\nBonjour à tous,\r\nJe vous propose aujourd'hui un article sur l'attaque présentée par Vincent Le Toux (@mysmartlogon) et Benjamin\r\nDelpy (@gentilkiwi) durant la conférence de sécurité BluehatIL 2018 qui a eu lieu les 23 et 24 janvier.\r\nLeur présentation s'intitulait Active Directory: What can make your million dollar SIEM go blind?\r\nEn effet, l'intérêt pour un attaquant d'utiliser DCSHadow est de ne laisser aucune tracer de ses modifications\r\npuisque celles-ci sont effectuées sur une machine compromise par l'attaquant. Ainsi aucun log de modification AD\r\nn'est remonté.\r\nVous pouvez retrouver la vidéo et les slides de la présentation sur le site officiel sur\r\nDCShadow https://www.dcshadow.com/.\r\nUn peu d'histoire\r\nLa première évocation par Vincent et Benjamin de ce qui allait devenir DCShadow remonte à l'été 2017.\r\nFaisant de la réponse à incident sur Active Directory depuis quelques années le tweet de Vincent m'a forcémment\r\ninterpelé. La possibilité qu'un attaquant puisse altérer les métadonnées de réplication a toujours été une de nos\r\ncraintes sur le forensic AD.\r\nJ'ai pourtant évoqué en répondant à ses tweets une autre méthode, non forensic mais plus de blue team, les cookies\r\nde réplication AD.\r\nhttps://adds-security.blogspot.fr/2018/02/detecter-dcshadow-impossible.html\r\nPage 1 of 10\n\nLes cookies de réplication AD sont assez méconnus mais utilisés par les équipes de réponse à incident AD lors des\r\nremédiations/reconstructions d'environnement Active Directory compromis.\r\nIls permettent notamment de limiter l'interruption de service lors de la remédiation contrairement aux précédentes\r\nméthodologies.\r\nC'est un sujet assez peu documenté mais on peut en trouver une trace dans la présentation de l'ANSSI sur TV5\r\nMonde du SSTIC 2017 Retour technique de l'incident de TV5Monde.\r\nCookie de réplication AD\r\nUn cookie de réplication est un fichier généré par l'utilisation d'une extension de serveur LDAP, le contrôle\r\nDirSync. Il faut d'abord initialiser le cookie pour pouvoir avoir les modifications depuis la dernière utilisation du\r\ncookie.\r\nVous retrouverez dedans une page dédiée au contrôle DirSync. \r\nPour utiliser ce contrôle, il ya plusieurs possibilités.\r\nLa plus simple pour tester rapidement, c'est d'utiliser Repadmin avec le switch /showchanges (visible avec l'aide\r\nen mode expert de repadmin /experthelp).\r\nC'est ce que je vais utiliser dans cet article.\r\nCa marche très bien avec du powershell :\r\nhttps://adds-security.blogspot.fr/2018/02/detecter-dcshadow-impossible.html\r\nPage 2 of 10\n\nJe ne vais pas m'étender c'est relativement simple à utiliser. Revenons maintenant sur l'attaque DCShadow.\r\nDétection de l'utilisation de DCShadow\r\nDétecter l'utilisation de DCShadow peut paraître assez trivial. En effet, pour être utilisé, DCShadow doit au\r\npréalable effectuer des modifications sur des objets Active Directory. En journalisant la modification de ces objets,\r\non peut détecter facilement l'utilisation de DCShadow.\r\nIl suffit pour cela de configurer correctement la politique d'audit (audit réplication détaillée et modifications AD)\r\net de configurer quelques SACL (écriture de l'attribut servicePrincipalName des objets Computer ).\r\nIl ya toutefois un gros bémol à cette technique. L'attaquant en capacité d'utiliser DCShadow dispose de privilèges\r\nélevés sur l'Active Directory. Rien ne l'empêche de modifier temporairement la politique d'audit sur le contrôleur\r\nde domaine qui sera ciblé par DCShadow pour la réactiver par la suite.  \r\nCa nous laisse donc la détection par le réseau qui est beaucoup moins trivial à mettre en place ou les cookies de\r\nréplication.\r\nhttps://adds-security.blogspot.fr/2018/02/detecter-dcshadow-impossible.html\r\nPage 3 of 10\n\nIl est intéressant d'ailleurs de comparer ce que remonte la journalisation AD avec ce que remonte le cookie de\r\nréplication.\r\nJ'effectue une modification avec DCShadow.\r\nVoici ce que j'ai dans le log:\r\nOn peut voir l'ajout puis la suppression du SPN de catalogue global (GC/).\r\nVoici ce qu'on a avec le cookie de réplication:\r\nhttps://adds-security.blogspot.fr/2018/02/detecter-dcshadow-impossible.html\r\nPage 4 of 10\n\nAvec le cookie de réplication, on a la valeur finale du SPN, avec le GUID du service DRS mais pas le GC qui a\r\nété supprimé.\r\nCe qui est intéressant c'est que la journalisation ne log pas l'ajout du SPN du service DRS (GUID E35...). \r\nOn peut donc déjà détecter l'utilisation de DCShadow sans utiliser la journalisation ni la capture réseau.\r\nComme je l'ai déjà dit, l'intérêt de DCShadow est de ne pas laisser de trace sur les modifications en elles-même.\r\nC'est bien de détecter que DCShadow a été utilisé mais ne pas savoir ce qui a été modifié rend la remédiation\r\nimposible.\r\nOn va voir qu'il y a plusieurs cas en fonction de comment on utilise DCShadow.\r\nMais avant de voir tout ça nous allons faire un très court rappel sur ce qui déclenche une réplication entre les\r\ncontrôleurs de domaine car ça a énormément d'importance pour la suite.\r\nRéplication AD et USN\r\nLa réplication AD se base sur le numéro USN (Update Sequence Number).\r\nPour faire très simple, le DC qui demande les réplications à son partenaire demande les modifications effectuées\r\ndepuis le dernier USN qu'il connait.\r\nAutrement dit, ton dernier USN que je connais est X, envoie-moi les attributs qui ont un numéro USN supérieur.\r\nPour plus d'informations, vous pouvez vous réferrez à cet article du technet : Tracking updates\r\nComme je l'ai dit l'USN a beaucoup d'importance pour la suite.\r\nDétection des modifications opérées via DCShadow\r\nJe n'ai pas pu tester tous les cas possibles en quelques heures mais voici déjà un bon aperçu.\r\nModification d'un attribut existant sur le DC où a eu lieu la dernière modification de l'attribut\r\navec les switchs de DCShadow par défaut\r\nLe premier cas que l'on va voir est l'utilisation de DCShadow telle qu'elle a été faite au début de l'article.\r\nSi l'on regarde les métadonnées de l'objet nous avons ceci :\r\nhttps://adds-security.blogspot.fr/2018/02/detecter-dcshadow-impossible.html\r\nPage 5 of 10\n\nOn peut voir que la valeur du numéro USN de l'attribut Description est 42, nombre assez remarquable.\r\nEn regardant le code source, on trouve rapidement que c'est une valeur hardcodée et qu'il ya une branche\r\nconditionnelle (switch qu'on verra plus tard).\r\nCe qui m'a étonné quand j'ai joué la première fois avec DCShadow, c'était que cette modification n'était pas\r\ndétectée par le cookie de réplication.\r\nMon premier réflexe a été de me dire qu'il sera catché par le cookie sur mon second DC lors de la réplication, mais\r\nje n'avais rien non plus et surtout l'attribut n'était pas modifié sur le second DC.\r\nJe vérifie les réplications et il n'y a pas de problème.\r\nJe compare ensuite les métadonnées de réplication.\r\nhttps://adds-security.blogspot.fr/2018/02/detecter-dcshadow-impossible.html\r\nPage 6 of 10\n\nEt là on peut voir une différence entre les 2.\r\nMa modification effectuée avec DCShadow n'a donc pas été repliquée sur les autres contrôleurs de domaine.\r\nLa raison est simple, la valeur d'USN étant 42, la modification n'est pas répliquée.\r\nOn voit tout de suite un intérêt du point de vue DFIR.\r\nPremièrement, 42 est un marquant fort dans les métadonnées de réplication (mais peut-être modifié dans le code\r\npar l'attaquant).\r\nDeuxièmement, les modifications n'ayant pas été repliquées, la remédiation des modifications est très simple, il\r\nsuffit de reconstruire le DC (après avoir réglé le problème de privilège bien évidemment).\r\nDans ce cas, on ne se sert pas du cookie de réplication puisqu'il n'y a pas réplication mais on peut retrouver les\r\nmodifications via les métadonnées (ou comparer les données entre le DC sur lequel DCShadow a été utilisé et un\r\nautre DC).\r\nL'intérêt pour l'attaquant est bien évidemment de ne pas utiliser DCShadow dans ce sens. Puisque si on détecte\r\nl'utilisation de DCShadow sur ce contrôleur de domaine on retrouvera rapidement les modifications qu'il a\r\neffectuées.\r\nOn va donc utiliser l'autre branche conditionnelle du code qui est un switch permettant de spécifier le numéro\r\nUSN.\r\nModification d'un attribut existant sur le DC où a eu lieu la dernière modification de l'attribut en\r\nutilisant le switch replOriginatingUsn de DCShadow\r\nhttps://adds-security.blogspot.fr/2018/02/detecter-dcshadow-impossible.html\r\nPage 7 of 10\n\nCette fois, nous allons spécifier la valeur du numéro USN.\r\nOn recommence cette fois en utilisant le switch /replOriginatingUsn avec un numéro USN permettant la\r\nréplication.\r\nOn vérifie les réplications.\r\nhttps://adds-security.blogspot.fr/2018/02/detecter-dcshadow-impossible.html\r\nPage 8 of 10\n\nEt là, on voit que la modification de l'attribut Description a bien été répliquée.\r\nD'un point de vue DFIR c'est la merde, les modifications ont été répliquées et je n'ai plus le marquant du numéro\r\nUSN.\r\nBonne chance pour remédier ...\r\nMais cette fois, si on regarde le cookie de réplication:\r\nOn voit bien la modification avec la valeur de l'attribut modifié.\r\nIl est assez facile de retrouver les modifications opérées avec DCShadow puisqu'elles vont suivre la modification\r\ndu SPN.\r\nAutre marquant\r\nJe me suis demandé si l'utilisation de DCShadow pouvait provoquer un USN Rollback.\r\nEn réflechissant, ça ne peut pas être le cas mais en regardant la valeur de Up-to-dateness Vector j'ai eu la surprise\r\nde voir ceci.\r\nA creuser mais ça pourrait être un marquant de l'utilisation de DCShadow si on\r\nn'a pas déployé de moyen de détection. \r\nConclusion\r\nOn peut donc désormais répondre à la question de cet article, est-ce vraiment impossible de détecter DCShadow ?\r\nhttps://adds-security.blogspot.fr/2018/02/detecter-dcshadow-impossible.html\r\nPage 9 of 10\n\nIl faut bien séparer utilisation de DCShadow et modifications opérées par DCShadow.\r\nDans les 2 cas on a pu voir qu'il était possible de les détecter (Bien que je n'ai pas pu tester tous les cas possibles).\r\nCette détection s'avère tout de même très difficile.\r\nClairement si vous n'êtes pas en capacité d'empêcher l'attaquant de récupérer les privilèges nécessaires à\r\nl'utilisation de DCShadow, il est peu probable que vous soyez en capacité de déployer une détection basée sur les\r\ncookies de réplication.\r\nSource: https://adds-security.blogspot.fr/2018/02/detecter-dcshadow-impossible.html\r\nhttps://adds-security.blogspot.fr/2018/02/detecter-dcshadow-impossible.html\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "FR",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://adds-security.blogspot.fr/2018/02/detecter-dcshadow-impossible.html"
	],
	"report_names": [
		"detecter-dcshadow-impossible.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434725,
	"ts_updated_at": 1775826752,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ff881befb1dd78e1cd727767bac25c90667ae52b.pdf",
		"text": "https://archive.orkl.eu/ff881befb1dd78e1cd727767bac25c90667ae52b.txt",
		"img": "https://archive.orkl.eu/ff881befb1dd78e1cd727767bac25c90667ae52b.jpg"
	}
}