Contrôles étendus LDAP puissants : Anti-remédiation et reconnaissance invisible dans AD

Démontré dans un laboratoire à deux DC cloud.lab (Windows Server 2022, niveau fonctionnel de forêt 2016). Contexte de laboratoire et de recherche autorisée uniquement.

Constat 1 - FORCE_UPDATE : Résolution des conflits de réplication gagnants à partir d’une seule écriture LDAP

L'idée en langage clair

Si vous maîtrisez déjà la réplication AD, passez à la suite. Sinon, voici une analogie.

Imaginez une entreprise avec deux armoires de classement identiques dans deux bureaux différents. Ce sont les deux contrôleurs de domaine (DC). Pour rester synchronisés, chaque modification apportée à l’un est copiée sur l’autre. Cette copie est la réplication.

Que se passe-t-il si deux personnes modifient le même fichier en même temps dans des bureaux différents, avant que la copie ne soit synchronisée ? Les armoires ne sont pas d'accord, et AD a besoin d'une règle pour déterminer qui gagne :

1. Celui qui a le numéro de version le plus élevé gagne. Chaque champ se souvient du nombre de fois où il a été modifié et ce nombre est sa "version."
2. Ce n’est que si les versions sont à égalité que AD regarde qui a édité le plus récemment (horodatage).
3. Si cela fait également égalité, le départage se fait par l’ID de l’armoire.

L’astuce : normalement, si vous “modifiez” un champ en réécrivant la valeur exacte qu’il avait déjà, AD hausse les épaules, dit “rien n’a changé,” et la version reste la même. FORCE_UPDATE est un indicateur qui dit “compte cela comme un vrai changement quand même.” Vous pouvez donc écrire Bob sur un champ qui dit déjà Bob six fois, et la version monte à 6 même si la valeur n’a jamais changé.

Ainsi, un attaquant effectue une modification malveillante sur un champ qu'il peut modifier, le frappe plusieurs fois avec FORCE_UPDATE pour faire monter la version à 6, puis attend. Lorsqu'un défenseur le corrige sur le autre cabinet (n'importe quel autre DC), c'est une nouvelle modification, plus tard, mais le premier changement là-bas, donc la version est 1. Les cabinets se synchronisent, AD compare 6 contre 1, et 6 gagne : la valeur de l'attaquant revient et la correction du défenseur disparaît silencieusement. L'attaquant a forcé un changement qui bat un changement plus récent et légitime.

Deux mises en garde honnêtes : cela ne fonctionne que sur les champs que vous pouviez déjà modifier (c'est de la persistance, pas une escalade), et ce n'est pas invisible. Cela laisse un champ dont la version a sauté sans changement de valeur. La partie vraiment nouvelle est le “prix d'entrée” : la célèbre attaque DCShadow fait le même mouvement « ma version gagne » mais nécessite des pouvoirs quasi divins de domaine (prétendant être un DC) ; ceci nécessite une écriture ordinaire et la permission sur un champ.

Contexte : Comment AD décide qui gagne

Active Directory est multi-maître, ce qui signifie que chaque DC modifiable accepte les changements qui se répliquent vers l'extérieur. Deux DC peuvent être invités à modifier le même attribut du même objet avant que la réplication ne réconcilie. Pour un conflit par attribut l'ordre de départage est :

1. Version - un compteur par attribut incrémenté à chaque écriture d'origine.
2. Horodatage - utilisé uniquement si les versions sont identiques.
3. Server (DSA) GUID - utilisé uniquement si la version et sont à égalité sur le timestamp.

Ces métadonnées sont par attribut, visibles via repadmin /showobjmeta ou msDS-replAttributeMetaData. La propriété cruciale : une version inférieure perd toujours face à une version supérieure, peu importe à quel point elle est plus récente. Et une MODIFY qui écrit la valeur existante d'un attribut est normalement une opération nulle (AD ne met pas à jour la version). Vous ne pouvez normalement pas augmenter la version en réécrivant la même valeur.

Le contrôle : LDAP_SERVER_FORCE_UPDATE (1.2.840.113556.1.4.1974)

FORCE_UPDATE est un contrôle documenté et bénin par cadrage : selon MS-ADTS, il indique au DC de traiter la modification même lorsqu'elle serait autrement une opération sans effet (« mettre à jour même si les nouvelles données sont identiques »). La bibliothèque Java ldaptive fournit un ForceUpdateControl faisant exactement cela, sans cadrage d'attaque. L'effet secondaire important : parce que l'écriture forcée compte comme une écriture d'origine réelle, elle incrémente la version par attribut sans changement de valeur. C'est le pont. Le tampon de version est conventionnellement considéré comme inaccessible par un client LDAP (c'est pourquoi DCShadow le manipule via le protocole de réplication en tant que DC malveillant) ; FORCE_UPDATE le rend accessible depuis une MODIFICATION LDAP.

La technique

1. Choisissez un attribut cible que le principal peut déjà écrire (un WriteProperty ACE).
2. Définissez la valeur malveillante sur DC-A.
3. Gonflez la version : envoyez N MODIFY supplémentaires avec la même valeur, chacun avec FORCE_UPDATE, chacun augmentant la version sans changement visible.
4. Attendez : Un défenseur corrige la valeur, naturellement sur n'importe quel DC auquel il est connecté (DC-B). Sa seule correction incrémente la version de un (à actuel+1). Tant que l'attaquant a gonflé au-dessus de cela, l'attaquant a toujours un rang supérieur. (En laboratoire, le défenseur est arrivé à la version 1 uniquement parce que l'attribut n'était pas défini auparavant ; en général, l'attaquant doit simplement dépasser la version de la correction, ce qui est gratuit.)
5. Convergence : AD compare les versions ; la version gonflée de l'attaquant l'emporte sur la correction ultérieure mais inférieure du défenseur. La valeur de l'attaquant l'emporte sur les deux DC.

Le défenseur voit que son changement « ne tient pas » : il le corrige, cela semble corrigé, et quelques minutes plus tard, cela revient en arrière.

Modèle de privilège vs DCShadow : La partie nouvelle

L'idée non évidente : LDAP peut atteindre le tampon de version par attribut. FORCE_UPDATE casse discrètement l'hypothèse "vous devez parler le protocole de réplication en tant que DC" depuis la surface client.

Démonstration (laboratoire à deux DC)

Attaquant = svc-research, un utilisateur de domaine simple délégué seulement WP;description (pas de droits de réplication). Les actions de l'attaquant s'exécutent sous sa propre liaison NTLM ; le contexte administrateur est utilisé uniquement pour l'orchestration du laboratoire (délégation, pause/reprise de la réplication, simulation du défenseur).

      Step 1 — low-priv writer bumps the version:
  baseline:                      description  version 1
  attacker no-op FORCE_UPDATE -> description  version 2   (no value change)

Step 2 — stage and win the conflict (replication paused):
  DC01:  description='ATTACKER-OWNED'            version 6  @ 19:58:34  (attacker, FORCE_UPDATE x3)
  DC-02: description='defender-remediation-LATER' version 1 @ 19:58:36  (defender, LATER, lower version)
  => CONVERGED: DC01 = DC-02 = 'ATTACKER-OWNED'   (defender's later fix reverted)
      

L'ingrédient offensif entier est un MODIFY avec le contrôle attaché :

      var m = new ModifyRequest(dn, DirectoryAttributeOperation.Replace, "description", value);
m.Controls.Add(new DirectoryControl("1.2.840.113556.1.4.1974", null, true, true)); // FORCE_UPDATE, critical
connection.SendRequest(m);   // same-value write now bumps the per-attribute version
      

Impact, portée et limites

Un primitif anti-remédiation / persistance : rendre une valeur d'attaquant tenace contre le nettoyage pour tout attribut que l'attaquant peut déjà écrire, par exemple msDS-AllowedToActOnBehalfOfOtherIdentity (porte dérobée RBCD), servicePrincipalName (réaffirmer une cible Kerberoast), scriptPath / gPLink (point d'ancrage persistant).

• Limite de portée (testée) : linked attributs (member / memberOf) ne sont pas affectés. Ils se répliquent via Linked-Value Replication avec des métadonnées par valeur ; une réinsertion FORCE_UPDATE sans effet d'un membre existant réussit mais n'incrémente pas la version de la valeur du lien. Ainsi, l'appartenance au groupe ne peut pas être fixée de cette manière, seulement les attributs non liés à valeur unique et multiple.
• Nécessite un accès en écriture existant (pas une escalade), et le défenseur doit corriger sur un DC différent (ou pré-convergence) pour que le conflit existe.
• Pas furtif : cela laisse un saut de version anormal sans changement de valeur, et une valeur qui “revient” après la remédiation (harmj0y, Hunting With AD Replication Metadata, 2017).

Nouveauté : Une revue multi-sweep de l'état de l'art ainsi qu'une recherche authentifiée de code natif GitHub (~1 000+ résultats OID) n'ont trouvé aucune publication de ce primitif spécifique. Presque tous les résultats sont inertes (en-têtes SDK, liaisons de langage, dissectors, dumps CTF supportedControl). Les plus proches voisins sont DCShadow (même effet, DA/EA via un DC malveillant), LDAPAngel/RIFM (un outil de récupération de forêt qui envoie FORCE_UPDATE, mais de manière non critique pour son but opérationnel FSMO/GC, pas pour gonfler les versions), le ForceUpdateControl bénin de ldaptive, et la course au niveau objet "Conflicting Objects" de Tenable. Aucun d'eux n'utilise cette technique. L'absence de preuve n'est pas une preuve, mais la victoire par conflit / l'application anti-remédiation semble non publiée.

Constat 2 - OBJECT_SECURITY DirSync : Énumération d’Active Directory sans trace de journal

L'idée en langage clair

Un utilisateur régulier peut déjà consulter la plupart des éléments dans Active Directory : noms, appartenances à des groupes, même les listes de permissions (ACL) sur les objets qu'il peut lire. Normalement, ces consultations peuvent être enregistrées par le journal des requêtes du DC. DirSync est une fonctionnalité de synchronisation destinée à des outils comme Entra Connect pour récupérer les modifications. Une de ses options, OBJECT_SECURITY, permet à un utilisateur ordinaire de l'exécuter pour lire tout ce qu'il est déjà autorisé à lire dans Active Directory avec ses permissions, mais parce qu'elle utilise la réplication au lieu du chemin normal de recherche, le DC n'enregistre rien. Ce sont les mêmes données qu'un utilisateur pourrait déjà collecter, mais sans trace. Cette méthode fournit également un "signet" (cookie) pour revenir plus tard uniquement sur ce qui a changé dans AD.

Le mécanisme

DirSync (LDAP_SERVER_DIRSYNC_OID, .841) a deux modes :

• flags=0 utilise la sémantique complète de réplication et requiert le droit de réplication Get-Changes. C’est le chemin privilégié, adjacent à DCSync, et il est journalisé via l’Événement 4662.
• OBJECT_SECURITY (drapeau 0x1) est le chemin non privilégié documenté pour les appelants ordinaires : il nécessite aucun droit de réplication et aucun changement de permission, seulement Domain Users, et limite les résultats aux données que l’appelant peut déjà lire. (C’est le chemin que Simon Décosse, simondotsh, a documenté en 2022. Ma contribution est la conséquence validée de la détection.)

Parce que OBJECT_SECURITY exerce no Get-Changes right, il ne génère no Event 4662 ; et parce que DirSync utilise le replication code path rather than the search path, il ne génère no Event 1644. Il se situe entièrement entre les deux sources de journaux hôtes.

Le cookie DirSync qu'il renvoie vous permet également de vous reconnecter plus tard et de récupérer uniquement les changements depuis la dernière fois, ce qui en fait également un moniteur de changements à faible bruit.

Pourquoi c'est une opportunité sournoise

C'est une véritable opportunité pour la phase de reconnaissance / énumération :

• Pas d'accès spécial : Tout compte de domaine compromis fonctionne. Il n'y a pas de droit de réplication à demander, aucun changement de schema/searchFlags, rien qui semble suspect en soi.
• Aucune empreinte : Collecte en masse des objets et des adhésions avec un journal sans coût, plus une synchronisation delta intégrée pour une surveillance continue.

C'est furtif, pas un nouvel accès. Cela ne donne pas à un attaquant des données qu'il ne pourrait pas lire autrement. Cela se limite à l'accès en lecture effectif, renvoyant exactement ce qu'une recherche LDAP ordinaire renverrait. Crucialement, cela ne contourne pas la porte des attributs confidentiels (searchFlags 0x80) : un attribut confidentiel est renvoyé seulement si l'appelant a réellement le droit de le lire (détient le droit CONTROL_ACCESS). Ce contournement appartient à l'autre mode DirSync, flags=0, qui utilise la sémantique de réplication pour divulguer des attributs confidentiels à toute personne ayant le droit Get-Changes (le sujet du post compagnon sur les angles morts de détection). OBJECT_SECURITY ne peut pas non plus lire les secrets (ce n'est pas DCSync, donc pas de matériel de mot de passe). Ce qui change est purement l'évasion : un balayage SD_FLAGS ordinaire laisserait des enregistrements d'événement 1644 partout où la journalisation des requêtes LDAP est activée ; la version DirSync OBJECT_SECURITY n'en laisse aucun dans aucun journal. La valeur pour un attaquant est une collection à faible bruit qui déjoue la télémétrie de recherche LDAP sur laquelle les défenseurs comptent, ce qui explique pourquoi il vaut la peine de la connaître même si elle n'accorde aucun nouveau privilège.

Détection et défense

Les deux constats partagent un thème : l'idée de détection évidente ne fonctionne pas, et les journaux hôtes sont plus aveugles que ce que les défenseurs supposent. Tout ce qui suit a été validé en exécutant les techniques en laboratoire.

FORCE_UPDATE (Constat 1)

• Principal - chasse aux métadonnées de réplication : Instantané msDS-replAttributeMetaData (ou repadmin /showobjmeta) pour les attributs sensibles et alerte lorsque la version par attribut augmente alors que le hachage de la valeur reste inchangé. En laboratoire, cela a clairement signalé l'attaque (description version 28 → 29, valeur inchangée). Un deuxième symptôme : une valeur qui réapparaît après la remédiation.
• L'événement 1644 ne le voit pas : FORCE_UPDATE utilise un MODIFY ; l'événement 1644 enregistre uniquement des recherches, donc la modification ne produit aucun événement 1644. Ainsi, une règle basée sur l'.1974 OID dans les journaux de requêtes ne se déclenche jamais. La détection sur le réseau nécessite PCAP/ETW, et le contrôle requiert un signed bind (un simple/Basic bind est rejeté), limitant la visibilité cleartext-389.
• Renforcement : Minimisez WriteProperty sur les attributs sensibles (le prérequis complet) ; corrigez sur le même DC (lorsque possible) et vérifiez la version ensuite.

OBJECT_SECURITY DirSync (Constat 2)

• Les journaux de l'hôte ne le verront pas : Pas de 4662 (pas de droit Get-Changes) et pas de 1644 (chemin de réplication), donc il n'y a pas de règle d'événement à écrire ; c'est la zone aveugle.
• Ce qui fonctionne réellement est limité : La capture réaliste est network / ETW capture du contrôle DirSync sur le réseau (sous réserve de LDAPS) plus l'établissement d'une base de référence de l'utilisation de DirSync et l'alerte à partir de toute source non synchronisée. Un SACL read-canary n'est pas une sauvegarde fiable ici : lors des tests, un ACE d'audit ReadProperty n'a pas déclenché l'événement 4662 pour une lecture ordinaire de l'attribut. L'audit de lecture de l'hôte AD est peu fiable, et la lecture du chemin de réplication de DirSync ne change pas cela. (Les canaris SACL sont fiables contre la mise à jour FORCE_UPDATE write et contre les droits de réplication DirSync/DCSync, mais pas contre cette lecture furtive.)
• Surveillez aussi l’angle ADWS : Les cmdlets PowerShell AD (Get-ADUser et consorts) ne parlent pas LDAP directement. Ils passent par Active Directory Web Services (ADWS, TCP 9389), qui relaie la requête localement au DC. Ainsi, l’Événement 1644 enregistre le client comme 127.0.0.1 (le DC lui-même), pas la véritable adresse de l’opérateur.
  • Pourquoi c'est important : Chaque règle 1644 doit exclure 127.0.0.1. Parce que les recherches internes du DC génèrent un bruit de loopback constant, cette même exclusion supprime également toute activité qu'un attaquant relaie via ADWS. Seule la visibilité réseau/ETW voit la source réelle.

Canaris SACL : ce qu’ils sont et où ils aident

Plusieurs recommandations ci-dessus s'appuient sur les canaris SACL, parlons-en. Le descripteur de sécurité de chaque objet AD contient deux listes de contrôle d'accès :

• DACL : décide qui peut faire quoi (autorisations)
• SACL : (System ACL) décide ce qui est audité

Un ACE d'audit SACL indique « lorsque cet objet ou attribut est accédé, émettre l'événement de sécurité Windows Event 4662 ». Un canary est un piège délibérément placé de type « honeytoken » sur un objet de grande valeur que l'activité légitime touche rarement, donc tout accès le déclenche. Parce qu'il est évalué au niveau de l'accès à l'objet (et non au niveau du contrôle ou du journal), il se déclenche quelle que soit la commande LDAP ou le transport utilisé.

Pour déployer :

• Activez Audit Directory Service Access (Succès) et ajoutez un ACE d'audit pour l'accès qui vous importe sur vos joyaux de la couronne (par exemple, l'attribut RBCD msDS-AllowedToActOnBehalfOfOtherIdentity, membre du groupe privilégié member, AdminSDHolder).

Le piège : fort pour les écritures, faible pour les lectures (validé).

Ces deux constatations échouent à différentes défenses, donc le canari aide de manière inégale :

• FORCE_UPDATE est un write : un SACL write-canary sur l'attribut cible qui déclenche de manière fiable l'événement 4662 lors de la modification malveillante et la recherche des métadonnées de réplication le détecte quoi qu'il en soit. (Un audit SACL sur un contrôle de access right détecte également de manière fiable les droits de réplication DirSync/DCSync via le Get-Changes 4662.)
• OBJECT_SECURITY DirSync est une lecture : L'audit de lecture de l'hôte AD n'est pas fiable. Dans mes tests, un ACE d'audit ReadProperty n'a pas généré l'événement 4662 même pour une lecture ordinaire de l'attribut. Ainsi, un canari SACL ne détecte pas de manière fiable cette lecture furtive. Cela dépend plutôt de la capture réseau/ETW et de la mise en base de référence de DirSync.

La version brute : les audit canaries sont votre meilleur piège pour le côté écriture et l'abus des droits de réplication, mais la discrète lecture nécessite des yeux sur le câble.

Outils

J'ai créé deux outils de preuve de concept pour Red Team et Blue Team afin d'explorer et de défendre les contrôles étendus LDAP : LDAP Extended Controls Toolkit.

Ce que fait chaque outil

red/ — ldapctl (offensif)

Trois sous-commandes, chacune mettant en œuvre une technique validée de contrôle étendu. Les indicateurs complets, privilèges et formats de sortie se trouvent dans red/README.md.

bleu/ — AdLdapDefense (défensif)

Un module PowerShell comprenant cinq fonctions exportées couvrant quatre capacités de détection/renforcement. Les paramètres et un exemple de sortie se trouvent dans blue/README.md. Nécessite PowerShell 5.1+ et RSAT (ActiveDirectory), à exécuter depuis une station d'administration pouvant atteindre le DC.

Références

• MS-ADTS, LDAP_SERVER_FORCE_UPDATE_OID. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/3c5e87db-4728-4f29-b164-01dd7d7391ea
• MS-ADTS / MS-DRSR. Résolution des conflits de réplication (version → horodatage → DSA GUID); DirSync (LDAP_SERVER_DIRSYNC_OID) et sémantique de réplication
• DCShadow, Delpy & Le Toux, BlueHat IL 2018. https://www.dcshadow.com/
• harmj0y, Chasse avec les métadonnées de réplication d'Active Directory (2017). https://blog.harmj0y.net/defense/hunting-with-active-directory-replication-metadata/
• simondotsh, Comprendre et abuser de DirSync (2022). https://simondotsh.com/infosec/2022/07/11/dirsync.html
• Tenable, Utilisation d’objets conflictuels dans Active Directory pour obtenir des privilèges (2024). https://medium.com/tenable-techblog/using-conflicting-objects-in-active-directory-to-gain-privileges-243ef6a27928