Cet \u00e9t\u00e9, l’\u00e9quipe de cirosec a publi\u00e9 la premi\u00e8re partie d’une \u00e9tude sur le contournement des d\u00e9tections de Microsoft Defender for Identity en 2026<\/a>. L’alerte DCSync y figure: sa logique repose sur la r\u00e9solution NNR (Network Name Resolution), qui permet au capteur de savoir si la machine source est un contr\u00f4leur de domaine, et des r\u00e9ponses NNR falsifi\u00e9es suffisent \u00e0 la tromper. En avril, Trellix rappelait de son c\u00f4t\u00e9 dans un billet sur la d\u00e9tection r\u00e9seau<\/a> qu’une requ\u00eate DsGetNCChanges est une fonction tout \u00e0 fait l\u00e9gitime du protocole, et qu’elle ne devient suspecte que lorsqu’elle part d’une machine qui n’est pas un contr\u00f4leur de domaine.<\/p>\n Si l’alerte d’un produit peut \u00eatre contourn\u00e9e, il reste le protocole lui-m\u00eame et le journal de s\u00e9curit\u00e9 du contr\u00f4leur de domaine, et c’est l\u00e0 que nous allons regarder.<\/p>\n Les contr\u00f4leurs de domaine se r\u00e9pliquent entre eux gr\u00e2ce au protocole [MS-DRSR]<\/a>, port\u00e9 par l’interface RPC drsuapi (UUID e3514235-4b06-11d1-ab04-00c04fc2dcd2, version 4.0). Le contr\u00f4leur de destination tire les modifications du contr\u00f4leur source en appelant la m\u00e9thode IDL_DRSGetNCChanges (opnum 3)<\/a>. Rien n’oblige l’appelant \u00e0 \u00eatre un contr\u00f4leur de domaine: n’importe quel client qui parle DRSUAPI et dispose des bons droits peut demander la r\u00e9plication d’un objet, attributs secrets compris. C’est cela, DCSync, r\u00e9f\u00e9renc\u00e9 par MITRE sous T1003.006<\/a>, et utilis\u00e9 par des groupes comme LAPSUS$, Storm-0501 ou Mustang Panda. L’attaquant n’ex\u00e9cute aucun code sur le contr\u00f4leur, ne touche ni \u00e0 NTDS.dit ni \u00e0 LSASS: il demande poliment.<\/p>\n Les droits en question sont des droits de contr\u00f4le d’acc\u00e8s \u00e9tendus, pos\u00e9s sur la t\u00eate du contexte de nommage, ici l’objet DC=test,DC=local. Le Threat Hunter Playbook<\/a> en donne la liste avec leurs GUID:<\/p>\n Le premier suffit pour r\u00e9pliquer les attributs ordinaires, et de nombreux outils de synchronisation en ont besoin. Le second<\/a> autorise la r\u00e9plication des donn\u00e9es secr\u00e8tes du domaine: unicodePwd, ntPwdHistory, supplementalCredentials (les cl\u00e9s Kerberos AES), etc\u2026 C’est la combinaison des deux qui rend DCSync possible. Par d\u00e9faut, seuls les groupes Administrateurs, Contr\u00f4leurs de domaine et Contr\u00f4leurs de domaine d’entreprise les d\u00e9tiennent, et Admins du domaine en h\u00e9rite au travers d’Administrateurs. Il faut y ajouter les comptes \u00e0 qui un projet les a donn\u00e9s, \u00e0 commencer par le compte de connecteur MSOL_ d’Entra Connect, qui en a besoin pour Password Hash Sync comme nous l’avions vu dans l’article sur Password Hash Sync et Seamless SSO<\/a>.<\/p>\n Attention: un compte qui a GenericAll ou WriteDacl sur la racine du domaine, ou une entr\u00e9e \u00ab Tous les droits \u00e9tendus \u00bb (ObjectType vide), peut s’accorder lui-m\u00eame ces droits. Il faut donc aussi le compter parmi les comptes capables de DCSync.<\/p>\n Pour dresser l’inventaire, ce petit script lit l’ACL de la racine du domaine et ne garde que les entr\u00e9es concern\u00e9es:<\/p>\n Nom du domaine: test.local (TESTLOCAL)<\/p>\n Contr\u00f4leurs de domaine: dc01.test.local (192.168.0.101) et dc02.test.local (192.168.0.102)<\/p>\n Serveur membre: srv01.test.local (192.168.0.110)<\/p>\n Compte de test: svc.audit@test.local, objet cibl\u00e9: utilisateur.test<\/p>\n Pour reproduire l’appel sans compte d’administration, nous d\u00e9l\u00e9guons les deux droits au compte svc.audit, puis nous activons l’audit des acc\u00e8s au service d’annuaire sur les contr\u00f4leurs (une GPO sur l’OU Domain Controllers est pr\u00e9f\u00e9rable \u00e0 auditpol en production):<\/p>\n La capture se fait sur dc01, avec Wireshark ou nativement avec netsh trace comme d\u00e9crit dans l’article Outils d’analyse r\u00e9seau<\/a>. Pour d\u00e9chiffrer le trafic de svc.audit, nous g\u00e9n\u00e9rons un keytab avec ktpass, comme dans l’article sur les ent\u00eates WWW-Authenticate<\/a>:<\/p>\n Attention, sans \/mapuser: avec cette option, ktpass modifie le compte dans l’annuaire. Ici nous voulons seulement calculer les cl\u00e9s \u00e0 partir du mot de passe.<\/p>\n Commen\u00e7ons par une r\u00e9plication tout \u00e0 fait normale. Sur dc01, nous for\u00e7ons une r\u00e9plication entrante depuis dc02:<\/p>\n Avec le filtre d’affichage \u00ab drsuapi \u00bb, la s\u00e9quence est toujours la m\u00eame: r\u00e9solution du port dynamique via l’Endpoint Mapper (tcp\/135), bind sur l’interface DRSUAPI, DsBind (opnum 0), puis DsGetNCChanges (opnum 3). Le contenu, lui, n’est pas lisible:<\/p>\n La r\u00e9plication utilise le niveau d’authentification Packet privacy (6): seul le stub est chiffr\u00e9. L’en-t\u00eate DCE\/RPC, avec l’opnum, reste en clair, de m\u00eame que les adresses IP.<\/p>\n -> Sans aucune cl\u00e9, un capteur r\u00e9seau sait donc qui appelle GetNCChanges et sur quel contr\u00f4leur. C’est sur ce signal que s’appuient les sondes NDR.<\/p>\n Passons \u00e0 srv01. Apr\u00e8s un \u00ab klist purge \u00bb pour que la capture contienne l’AS-REQ, nous lan\u00e7ons sous l’identit\u00e9 de svc.audit un outil d’audit de mots de passe qui impl\u00e9mente le client DRSUAPI (le module DSInternals de Michael Grafnetter, con\u00e7u pour l’audit de la qualit\u00e9 des mots de passe), en ne demandant que l’objet utilisateur.test. Le sch\u00e9ma ci dessous reprend les \u00e9changes observ\u00e9s c\u00f4t\u00e9 dc01, avec en bas la r\u00e9plication l\u00e9gitime de dc02 pour comparaison.<\/p>\n\n
Import-Module ActiveDirectory\n$droits = @{\n '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' = 'DS-Replication-Get-Changes'\n '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2' = 'DS-Replication-Get-Changes-All'\n '89e95b76-444d-4c62-991a-0facbeda640c' = 'DS-Replication-Get-Changes-In-Filtered-Set'\n '00000000-0000-0000-0000-000000000000' = 'Tous les droits etendus'\n}\n(Get-Acl \"AD:\\DC=test,DC=local\").Access |\n Where-Object { $droits.ContainsKey($_.ObjectType.ToString()) -and\n $_.ActiveDirectoryRights -match 'ExtendedRight|GenericAll' } |\n Select-Object IdentityReference, AccessControlType,\n @{n='Droit';e={$droits[$_.ObjectType.ToString()]}}<\/code><\/pre>\nPr\u00e9sentation de la maquette<\/h2>\n
dsacls \"DC=test,DC=local\" \/G \"TESTLOCAL\\svc.audit:CA;Replicating Directory Changes\"\ndsacls \"DC=test,DC=local\" \/G \"TESTLOCAL\\svc.audit:CA;Replicating Directory Changes All\"\n\nauditpol \/set \/subcategory:\"Directory Service Access\" \/success:enable<\/code><\/pre>\nktpass \/out svc.audit.keytab \/princ svc.audit@TEST.LOCAL \/pass * \/ptype KRB5_NT_PRINCIPAL \/crypto All<\/code><\/pre>\nGetNCChanges sur le r\u00e9seau<\/h2>\n
repadmin \/replicate dc01.test.local dc02.test.local DC=test,DC=local<\/code><\/pre>\nDCE\/RPC Request, Fragment: Single, FragLen: 1172, Call: 3, Ctx: 0\n Opnum: 3\n Auth Info: SPNEGO, Packet privacy, AuthContextId(0)\n Auth type: SPNEGO (9)\n Auth level: Packet privacy (6)\n Encrypted stub data: 8f3a61c2e07d...\nDRSUAPI\n Operation: DsGetNCChanges (3)<\/code><\/pre>\n