Le relais NTLM est l'une des attaques les plus redoutables sur les environnements Active Directory. Elle n'exploite pas une vulnérabilité logicielle au sens strict : elle tire parti de deux lacunes de configuration que l'on retrouve dans la majorité des domaines Windows déployés sans durcissement explicite. L'absence de signature SMB et l'absence de signature LDAP, combinées à une technique de poisoning réseau, suffisent à compromettre l'intégralité d'un domaine. Voici comment cette chaîne fonctionne et, surtout, comment la briser.
Comprendre la surface d'attaque : SMB et LDAP sans signature
Par défaut, Windows ne requiert pas la signature SMB sur les sessions établies entre postes de travail. Les contrôleurs de domaine l'activent en lecture pour les sessions entrantes, mais rien n'oblige les clients à la vérifier. Résultat : un tiers peut s'intercaler dans la session, rejouer les échanges d'authentification NTLM vers une cible différente et obtenir accès à des ressources sans jamais connaître le mot de passe.
Le cas LDAP est encore plus problématique. Le protocole LDAP sur port 389 n'exige ni chiffrement ni signature par défaut dans la plupart des configurations héritées. LDAP signing et LDAP channel binding sont deux contrôles distincts que Windows Server n'applique pas de façon contraignante sans intervention de l'administrateur. C'est précisément cette fenêtre que les attaquants exploitent pour écrire dans l'annuaire.
La chaîne d'attaque : du poisoning réseau à DA
Étape 1 — Empoisonnement réseau avec LLMNR/NBT-NS
Tout commence par une réponse forgée. Lorsqu'un poste tente de résoudre un nom qui n'existe pas dans le DNS, il diffuse une requête LLMNR ou NBT-NS sur le réseau local. Un attaquant positionné sur le même segment répond en se faisant passer pour la cible demandée. Le poste victime envoie alors ses credentials NTLM à l'attaquant. L'outil Responder est typiquement utilisé dans ce scénario.
Étape 2 — Relais vers SMB ou LDAP
L'attaquant ne cherche pas à casser le hash : il le relaie en temps réel. Si la cible du relais est un serveur SMB sans signature requise, il obtient un accès au système de fichiers. Mais le scénario le plus dangereux vise le contrôleur de domaine via LDAP. Avec ntlmrelayx (impacket), l'attaquant peut relayer l'authentification NTLM d'un compte machine ou d'un compte utilisateur vers le DC et, si ce compte dispose de permissions suffisantes, écrire dans l'annuaire.
Étape 3 — Escalade vers Domain Admin
Une fois un accès LDAP obtenu sur le DC, plusieurs vecteurs deviennent accessibles. L'attaquant peut ajouter un ordinateur au domaine via l'attribut ms-DS-MachineAccountQuota (souvent fixé à 10 par défaut), puis exploiter une délégation contrainte ou un ACE abusable. Alternativement, si le compte relayé a le droit DCSync ou appartient à un groupe d'administration délégué, l'escalade est immédiate. La technique Resource-Based Constrained Delegation (RBCD) est aujourd'hui l'un des chemins les plus courants pour passer de l'accès LDAP à DA sans aucun code d'exploitation.
GPO pour forcer la signature SMB : configuration précise
Deux paramètres distincts gouvernent la signature SMB : l'un côté serveur, l'autre côté client. Il faut les deux pour être réellement protégé.
- Côté serveur (DC et serveurs membres) :
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network server: Digitally sign communications (always)— valeur : Enabled. - Côté client : même chemin, paramètre
Microsoft network client: Digitally sign communications (always)— valeur : Enabled. - Pour les contrôleurs de domaine spécifiquement, appliquer cette GPO via l'OU Domain Controllers avec une priorité haute garantit qu'aucun DC ne reçoit de connexion SMB non signée.
Le risque de compatibilité applicative est réel mais limité. Les imprimantes réseau anciennes et certains NAS basés sur Samba versions antérieures à 3.x peuvent ne pas supporter SMB signing. Un audit préalable des équipements réseau non-Windows est indispensable avant déploiement en production. Une approche progressive consiste à activer d'abord le paramètre required uniquement sur les DC, puis à l'étendre progressivement aux serveurs membres après inventaire.
GPO pour forcer la signature LDAP et le channel binding
La signature LDAP se configure via une clé de registre poussée par GPO, distincte de la configuration SMB.
- LDAP signing (serveur) :
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: LDAP server signing requirements— valeur : Require signing. Cette GPO ne s'applique qu'aux DC. - LDAP channel binding : ce paramètre se configure via la clé de registre
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding, avec la valeur DWORD 2 pour forcer le binding. Microsoft propose un CSP (Configuration Service Provider) ou une préférence de registre GPO pour déployer cette valeur. - Côté client LDAP :
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LDAP client signing requirements— valeur : Require signing.
Le principal point de friction applicative ici concerne les applications qui effectuent des requêtes LDAP via des connexions anonymes ou des liaisons simples (simple bind). Les annuaires exposés à des ERP ou des solutions RH tierces nécessitent une validation préalable. Pour ces cas, LDAPS (port 636) avec un certificat valide reste l'alternative propre, et il est préférable de migrer vers LDAPS plutôt que de laisser des exceptions ouvertes sur le port 389.
Pour aller plus loin dans l'évaluation de ces configurations sur votre infrastructure, les labs Active Directory du catalogue CyberAct permettent de reproduire ces scénarios de relais en environnement contrôlé et de valider l'efficacité des GPO déployées.
Ce que ces deux GPO ne couvrent pas
Activer SMB signing et LDAP signing ne désactive pas NTLM. Un attaquant qui capture un hash via Responder peut encore tenter une attaque par force brute hors ligne. La désactivation de LLMNR et NBT-NS via GPO (Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution à Enabled, et désactivation de NetBIOS sur TCP/IP via DHCP ou script WMI) supprime le vecteur d'empoisonnement initial. Ces deux actions combinées forment le socle minimal d'un durcissement AD sérieux.
Si vous souhaitez évaluer l'exposition réelle de votre domaine avant de déployer ces contrôles, un diagnostic de maturité cyber permet d'identifier rapidement les chemins d'attaque prioritaires dans votre environnement.
Questions fréquentes
Est-ce que forcer SMB signing va ralentir les transferts de fichiers ?
L'impact sur les performances est mesurable mais généralement faible sur des infrastructures modernes. Sur des serveurs de fichiers très sollicités avec des clients anciens (Windows 7, vieux NAS), une légère hausse de latence est possible. Dans la grande majorité des environnements d'entreprise actuels, l'impact est négligeable et le gain en sécurité justifie largement la démarche.
Peut-on bloquer le relais NTLM sans activer le signing ?
Partiellement. Désactiver LLMNR et NBT-NS supprime le principal vecteur de capture initiale, ce qui rend le relais beaucoup plus difficile. Mais tant que NTLM reste actif et que SMB/LDAP signing ne sont pas requis, un attaquant disposant d'un autre moyen de capture (ARP spoofing, IPv6 DHCP rogue) peut toujours tenter un relais. Le signing reste le contrôle le plus fiable.
LDAP signing et LDAPS, c'est la même chose ?
Non. LDAP signing authentifie et protège l'intégrité des messages sur le port 389 via Kerberos ou NTLM. LDAPS chiffre l'intégralité de la session sur le port 636 via TLS. Les deux sont complémentaires : LDAPS protège la confidentialité, LDAP signing protège contre la manipulation et le relais. L'idéal est de migrer vers LDAPS pour les applications tierces et d'exiger le signing pour toutes les connexions internes.
Quel est le risque si on applique ces GPO sans inventaire préalable ?
Des applications legacy qui effectuent des liaisons LDAP simples ou des connexions SMB non signées peuvent cesser de fonctionner immédiatement. Le risque le plus courant concerne les scanners multifonctions, les applications de monitoring réseau anciennes et certains ERP. Un mode audit (valeur Negotiate signing avant Require signing) permet de détecter les clients non conformes via les journaux d'événements Windows avant bascule définitive.