L'attaque LDAP relay est l'une des chaînes d'exploitation les plus redoutables d'un environnement Active Directory. Elle ne repose sur aucune CVE, ne nécessite pas de mot de passe en clair, et peut se dérouler en quelques minutes depuis une machine non privilégiée sur le réseau local. Pourtant, deux paramètres de configuration correctement positionnés la rendent totalement inopérante. Voici la mécanique complète, du premier paquet jusqu'au shell.
L'amorce : pourquoi LLMNR et NBT-NS créent une fenêtre d'attaque
Quand une machine Windows tente de résoudre un nom d'hôte qui n'existe pas dans le DNS, elle bascule automatiquement sur des protocoles de résolution locale : d'abord LLMNR (Link-Local Multicast Name Resolution), ensuite NBT-NS (NetBIOS Name Service). Ces requêtes sont diffusées sur l'ensemble du segment réseau — n'importe qui peut y répondre.
Un attaquant positionné sur le même VLAN répond à ces broadcasts en se faisant passer pour la ressource demandée. La victime lui envoie alors ses identifiants NTLMv2 pour s'authentifier. Ces identifiants ne sont pas un mot de passe en clair, mais un challenge-response signé. Ils ne peuvent pas être réutilisés directement… sauf si on les relaie immédiatement vers un autre service qui, lui, les accepte.
Du relais NTLMv2 à la session LDAP authentifiée
C'est là qu'entre en jeu le relay proprement dit. Des outils comme ntlmrelayx interceptent le challenge-response NTLMv2 capturé et le retransmettent en temps réel vers le contrôleur de domaine, sur le port 389 (LDAP) ou 636 (LDAPS). Si le contrôleur de domaine n'exige pas de signature LDAP, il accepte la session comme légitime — sans que l'attaquant ait jamais eu connaissance du mot de passe.
À cet instant, l'attaquant dispose d'une session LDAP authentifiée avec les droits de la victime. Si cette victime est un simple utilisateur du domaine, les dégâts sont déjà significatifs : consultation de l'annuaire, énumération des groupes et des ACL. Mais si les droits le permettent, on passe à l'étape suivante.
L'escalade : création d'un compte et ajout au groupe Admins du domaine
Avec une session LDAP active, il est possible d'effectuer des opérations d'écriture sur l'annuaire, sous réserve que le compte relaié dispose des permissions suffisantes. Dans un scénario type, ntlmrelayx peut être configuré pour ouvrir un shell LDAP interactif — une interface en ligne de commande qui permet d'exécuter des requêtes LDAP arbitraires.
Depuis ce shell, les opérations suivantes s'enchaînent naturellement :
- Création d'un nouvel objet utilisateur dans l'annuaire via une requête
addLDAP. - Définition d'un mot de passe sur ce compte (attribut
unicodePwd). - Ajout de ce compte au groupe Domain Admins via une modification de l'attribut
memberdu groupe.
En moins de deux minutes après la capture du premier challenge NTLMv2, un compte avec des droits d'administrateur du domaine existe dans l'annuaire. L'attaquant peut ensuite s'y connecter directement — via WinRM, RDP, ou psexec — sans avoir jamais craqué un seul hash.
Ce type de scénario est régulièrement simulé dans les labs de Red Team Active Directory pour mesurer concrètement la vitesse d'escalade possible dans un environnement non durci.
Pourquoi la signature LDAP neutralise le relais
La signature LDAP (LDAP signing) force le contrôleur de domaine à exiger que chaque paquet LDAP soit cryptographiquement signé par le client. Or, dans un relais NTLM, l'attaquant n'a jamais accès à la clé de session qui permettrait de signer ces paquets — il ne connaît pas le mot de passe de la victime. Le contrôleur de domaine rejette donc la connexion avant même qu'une session soit établie.
La configuration se fait via la stratégie de groupe : Domain controller: LDAP server signing requirements doit être positionné à Require signing. Ce paramètre est désactivé par défaut dans la plupart des environnements Windows Server, y compris les versions récentes, tant que la GPO n'a pas été explicitement configurée.
Le rôle complémentaire du channel binding
Le channel binding LDAP (EPA — Extended Protection for Authentication) ajoute une couche supplémentaire spécifique aux connexions sur TLS, c'est-à-dire LDAPS. Il lie l'authentification NTLM au canal TLS sous-jacent en incluant dans le token d'authentification un identifiant cryptographique du certificat TLS présenté par le serveur. Si un attaquant intercepte et relaie cette authentification, le token qu'il présente au serveur référence un canal TLS différent — la vérification échoue.
Sans channel binding, même une connexion LDAPS peut être vulnérable au relais si l'attaquant peut créer son propre tunnel TLS vers le contrôleur de domaine et y relayer le token capturé. Le channel binding ferme précisément cette fenêtre.
Ces deux contrôles sont complémentaires : la signature LDAP protège le port 389 en clair, le channel binding protège le port 636 chiffré. Il faut les deux pour couvrir l'ensemble de la surface.
Ce que ça change concrètement pour une équipe de sécurité
Activer la signature LDAP et le channel binding est une opération de quelques minutes sur la GPO du domaine. Mais avant de basculer en mode Require, il est prudent de passer par un audit des clients LDAP legacy qui pourraient ne pas supporter ces mécanismes — certaines applications métier ou équipements réseau anciens communiquent encore en LDAP simple sans signature.
Une bonne pratique consiste à commencer par le mode Negotiate signing en observant les journaux, puis à basculer en Require une fois que l'inventaire des clients est propre. Pour les équipes souhaitant évaluer leur exposition réelle avant toute modification, un diagnostic de maturité cyber permet d'identifier rapidement les vecteurs d'attaque prioritaires dans l'environnement Active Directory.
Enfin, désactiver LLMNR et NBT-NS via GPO supprime la source même du problème : sans broadcast de résolution non-DNS, l'attaquant n'a plus de challenge NTLMv2 à capturer. C'est le contrôle le plus simple, et souvent le plus négligé.
Questions fréquentes
Est-ce qu'un simple utilisateur du domaine peut suffire à réaliser une attaque LDAP relay ?
Oui, dans de nombreux environnements. Dès lors qu'un compte utilisateur standard dispose de droits d'écriture sur certains objets de l'annuaire — ce qui arrive fréquemment par accumulation de délégations ou de mauvaises configurations ACL — une session LDAP relayée avec ce compte peut suffire à créer ou modifier des objets sensibles.
La signature LDAP casse-t-elle des applications existantes ?
Elle peut affecter les applications qui utilisent des connexions LDAP sans signature, notamment certains logiciels RH, ERP ou équipements réseau anciens. C'est pourquoi Microsoft recommande de commencer par le mode Negotiate signing et d'analyser les logs d'erreurs avant de forcer le mode Require.
Quelle est la différence entre LDAP signing et LDAP channel binding ?
La signature LDAP protège les connexions sur le port 389 (non chiffré) en exigeant une signature cryptographique des paquets. Le channel binding lie l'authentification au canal TLS du port 636, empêchant le relais même sur une connexion chiffrée. Les deux mécanismes sont nécessaires pour couvrir l'ensemble du vecteur.
Désactiver LLMNR suffit-il à stopper ce vecteur d'attaque ?
C'est le contrôle le plus efficace en amont, car il supprime la source des credentials NTLMv2 capturés. Mais il faut aussi désactiver NBT-NS pour couvrir l'ensemble du vecteur de résolution broadcast. La signature LDAP reste néanmoins indispensable pour neutraliser d'autres formes de relais NTLM qui n'exploitent pas LLMNR.