Qu'est-ce que le NTLM Relay ?
Le NTLM relay est l'une des techniques d'attaque réseau les plus fiables dans les environnements Active Directory. Il exploite le mécanisme challenge-réponse de l'authentification NTLM pour capturer les tentatives d'authentification des victimes et les relayer — en temps réel — vers d'autres services, en s'authentifiant en tant que la victime sans jamais cracker son mot de passe.
L'attaque ne nécessite qu'un accès réseau au segment cible. Aucun credential, aucun compte de domaine, aucun exploit. Dans de nombreux réseaux internes, elle peut être exécutée en quelques minutes après l'obtention d'un accès initial.
La cause racine combine trois facteurs : NTLM est encore largement utilisé malgré son ancienneté, la signature SMB est désactivée sur la plupart des postes de travail, et les protocoles legacy comme LLMNR et NBT-NS permettent aux attaquants d'intercepter les tentatives d'authentification en répondant aux requêtes broadcast.
Comment ca Fonctionne
NTLM utilise un challenge-réponse en trois messages :
- Le client envoie un message NEGOTIATE
- Le serveur envoie un CHALLENGE (un nonce aléatoire)
- Le client envoie AUTHENTICATE (hash NTLM appliqué au nonce)
Dans une attaque de relay, l'attaquant se positionne entre le client et le serveur, transmettant ces messages vers un service cible. Le service cible croit authentifier un utilisateur légitime.
Les victimes sont coercées à envoyer des authentifications via le poisoning LLMNR/NBT-NS (résolution de noms par broadcast) ou la coercition par print spooler (SpoolSample).
La Chaine d'Attaque
Etape 1 - Mettre en Place l'Infrastructure de Relay
# Responder — empoisonner LLMNR/NBT-NS
responder -I eth0 -rdw --no-HTTP-Server --no-SMB-Server
# ntlmrelayx — relayer vers la liste de cibles
ntlmrelayx.py -tf cibles.txt -smb2support -socks
Etape 2 - Capturer et Relayer l'Authentification
# Sortie quand le relay réussit :
# [*] Authenticating against smb://10.10.0.50 as CORP/jmartin SUCCEED
Etape 3 - Exploiter vers les Cibles de Haute Valeur
# Relay vers LDAP — escalader l'attaquant vers Domain Admins
ntlmrelayx.py -t ldap://dc01.corp.local --escalate-user attaquant
# Relay vers l'inscription web ADCS (ESC8)
ntlmrelayx.py -t http://ca.corp.local/certsrv/certfnsh.asp --adcs --template Machine
Etape 4 - Escalade vers le Domaine
Le relay LDAP vers un DC escalade directement vers Domain Admin. Le relay ADCS donne un certificat machine utilisable pour l'authentification Kerberos.
Détection
Event IDs Windows
| Event ID | Source | Ce qu'il faut surveiller |
|---|---|---|
| 4624 (Type 3) | Machine cible | Connexion réseau depuis une IP source inattendue |
| 4776 | DC | Validation credential NTLM — surveiller NTLMv1 |
| 4625 | Cible | Échec de connexion depuis des relays ratés |
Requete SIEM (Elastic KQL)
event.code: "4624" AND
winlog.event_data.LogonType: "3" AND
winlog.event_data.AuthenticationPackageName: "NTLM" AND
NOT winlog.event_data.WorkstationName: (winlog.event_data.TargetServerName OR "*DC*")
💡 Conseil : Le NTLM relay laisse un pattern distinct : même compte s'authentifiant sur plusieurs machines dans une courte fenêtre depuis une IP source inhabituelle.
Remédiation
💡 Action Rapide : Activez la signature SMB sur tous les postes de travail via GPO. Ce seul changement rend le relay SMB impossible.
1. Activer la Signature SMB
# Via GPO : Options de Sécurité
# "Serveur réseau Microsoft : Communications signées numériquement (toujours)" = Activé
# "Client réseau Microsoft : Communications signées numériquement (toujours)" = Activé
# Vérifier
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters" -Name RequireSecuritySignature
# Doit retourner 1
2. Désactiver LLMNR et NBT-NS
# Désactiver LLMNR via GPO :
# Configuration Ordinateur > Modèles Admin > Réseau > Client DNS
# "Désactiver la résolution de noms multicast" = Activé
# Désactiver NetBIOS sur TCP/IP
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_*" `
-Name NetbiosOptions -Value 2
3. Imposer NTLMv2 Uniquement
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel -Value 5
4. Activer la Signature LDAP sur les DCs
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" `
-Name "LDAPServerIntegrity" -Value 2
Comment EtcSec Détecte Cela
NTLMV1_ALLOWED identifie les domaines où NTLMv1 est encore autorisé — la version NTLM la plus faible, la plus facile à relayer et à cracker.
WDIGEST_ENABLED signale le cache de credentials en clair qui aggrave l'impact de tout vol de credentials basé sur le relay.
Les vérifications réseau évaluent également la configuration de signature SMB, les exigences de signature LDAP et les politiques de restriction NTLM.
ℹ️ Note : EtcSec audite la sécurité de l'authentification réseau lors de chaque scan AD. Lancez un audit gratuit pour identifier l'exposition aux attaques NTLM relay.
Articles connexes : Attaques ADCS | Sécurité Mots de Passe AD
Priorites de Revue
Attaques NTLM Relay : Détourner l'Authentification Sans Cracker de Mots de Passe doit etre traite comme une exposition reelle dans votre environnement Active Directory, pas comme un simple parametre isole. La premiere etape consiste a definir le vrai perimetre de revue : quels groupes privilegies, comptes de service, ACL, liens GPO, trusts, delegations, templates de certificats et postes d'administration sont concernes, quelles dependances metier existent, quels privileges sont exposes et quelles exceptions d'urgence ont ete ajoutees avec le temps. Ce cadrage evite une remediation superficielle, car le symptome technique est souvent plus petit que le rayon d'impact operationnel. En documentant le chemin complet entre configuration, privilege et usage reel, l'equipe peut prioriser des changements qui reduisent le risque sans bloquer l'activite.
Controles Adjacents a Revoir
Quand un attaquant arrive dans votre environnement Active Directory, il ne s'arrete presque jamais au premier point faible. Autour de Attaques NTLM Relay : Détourner l'Authentification Sans Cracker de Mots de Passe, il cherche en general a enchainer avec comptes privilegies obsoletes, imbrication dangereuse de groupes, delegations excessives, politiques de mot de passe faibles et abus d'ACL heritees. Cela signifie que la defense doit revoir non seulement la faiblesse principale, mais aussi toutes les dependances qui transforment un acces initial en persistance ou en escalation. Verifiez quelles identites, quels roles, quelles permissions et quelles hypotheses de confiance peuvent etre reutilises. Si le correctif ferme un seul objet mais laisse intactes les voies adjacentes, le risque reel change peu. Une revue des chaines d'abus est donc indispensable pour obtenir un resultat durable.
Preuves et telemetry a collecter
Une bonne reponse a Attaques NTLM Relay : Détourner l'Authentification Sans Cracker de Mots de Passe repose sur des preuves que l'ingenierie et la detection peuvent relire ensemble. Collectez Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, changements SYSVOL et activite des certificats, comparez les changements recents avec les fenetres de maintenance attendues et isolez les comptes ou objets qui ont change de comportement sans justification claire. Ces elements doivent permettre de repondre a trois questions simples : quand l'exposition est apparue, qui peut encore l'utiliser, et si des variantes similaires existent ailleurs dans votre environnement Active Directory. La collecte de preuves aide aussi a distinguer une dette technique ancienne d'un usage actif. Cette distinction est essentielle pour choisir le bon niveau d'urgence et la bonne sequence de remediation.
Faiblesses voisines a revoir
Tres peu d'environnements contiennent Attaques NTLM Relay : Détourner l'Authentification Sans Cracker de Mots de Passe seul. Dans la pratique, la meme zone du tenant ou de l'annuaire contient souvent aussi comptes privilegies obsoletes, imbrication dangereuse de groupes, delegations excessives, politiques de mot de passe faibles et abus d'ACL heritees, et ce sont ces faiblesses voisines qui determinent si l'exposition reste limitee ou devient critique. Revoyez les owners communs, les permissions heritees, les exceptions dupliquees et les raccourcis administratifs qui n'ont jamais ete retires. Verifiez si la meme logique de contournement a ete approuvee a plusieurs endroits, car cela revele souvent une faille de processus plus qu'un bug unique. Cette revue elargie donne une meilleure chance d'eliminer le chemin d'attaque complet.
Ordre de remediation recommande
Pour Attaques NTLM Relay : Détourner l'Authentification Sans Cracker de Mots de Passe, l'ordre de remediation doit privilegier la reduction de risque avant la perfection. Commencez par fermer les chemins qui augmentent le plus vite le privilege, puis verrouillez les objets ou identites a plus forte valeur, et ensuite seulement traitez les ecarts de hygiene secondaires. Utilisez tiering, nettoyage des delegations, revue ACL, hygiene des comptes de service, revue des permissions GPO et durcissement ADCS comme ensemble de controles cible. Chaque changement doit avoir un owner, une note de rollback et une etape de validation. Cette discipline evite que les programmes de correction s'arretent apres le premier gain technique. Si une refonte complete n'est pas possible tout de suite, formalisez des controles intermediaires et planifiez le travail structurel dans le prochain revue hebdomadaire des privileges et validation mensuelle des controles.
Validation apres chaque changement
Apres toute modification liee a Attaques NTLM Relay : Détourner l'Authentification Sans Cracker de Mots de Passe, validez le resultat sous deux angles : administration legitime et chemin d'attaque. Confirmez que les utilisateurs et systemes attendus continuent de fonctionner, puis prouvez que la voie dangereuse ne donne plus le meme levier. Rejouez la collecte sur Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, changements SYSVOL et activite des certificats, relisez les approbations et verifiez qu'aucun objet voisin ne conserve une voie de contournement. La validation doit aussi inclure une definition ecrite du succes, afin que tout le monde sache ce qui constitue une fermeture acceptable. Dans les equipes matures, un correctif n'est accepte que lorsque le chemin risque est ferme et que l'etat final correspond vraiment a l'objectif de durcissement.
Lectures Connexes
Pour traiter ce sujet correctement, reliez-le a Mots de Passe AD : Erreurs de Configuration Critiques, Mauvaises Configurations GPO : Vecteur d'Attaque AD, Supervision Sécurité AD : Événements Clés, Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin et Chemins d'Attaque AD : Mauvaises Configurations en Chaîne. Cet ensemble montre comment les memes erreurs d'identite, de privileges et de configuration se combinent dans une revue reelle au lieu d'apparaitre comme des constats isoles.
- Mots de Passe AD : Erreurs de Configuration Critiques
- Mauvaises Configurations GPO : Vecteur d'Attaque AD
- Supervision Sécurité AD : Événements Clés
- Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin
- Chemins d'Attaque AD : Mauvaises Configurations en Chaîne
Ces liens internes gardent la remediation centree sur le chemin d'attaque complet et pas seulement sur un controle pris separement.
Validation Operationnelle
Avant de clore la revue, rejouez les controles qui ont revele le risque et confirmez que le chemin d'abus n'existe plus du point de vue d'un attaquant. Verifiez les identites, privileges, exceptions, dependances et preuves de remediations en production plutot que de vous limiter a la documentation. Cette validation finale transforme une correction ponctuelle en reduction de risque durable.
Questions a Trancher Avant la Validation Finale
Avant qu'une equipe considere un sujet identite comme vraiment traite, elle devrait pouvoir repondre a quelques questions simples avec des preuves concretes. Quel compte, quel groupe ou quel systeme reste aujourd'hui le chemin d'exception le plus sensible ? Quelle dependance operationnelle a empeche une remediation plus complete, et qui a accepte ce risque de facon explicite ? Quel controle compensatoire, quelle regle de supervision ou quelle frequence de revue couvre desormais l'exposition residuelle en production ? Ces questions comptent parce qu'une faiblesse d'identite revient souvent lorsque la note de remediaton est plus forte que la realite d'exploitation. Si l'organisation ne peut pas expliquer clairement le proprietaire, la dependance metier et la prochaine date de revue, le controle n'est generalement pas aussi stable qu'il en a l'air.
Preuves a Conserver pour la Revue Suivante
Les equipes les plus solides conservent juste assez de preuves pour rendre la revue suivante plus rapide et plus fiable. Cela inclut en general le proprietaire actuel de l'actif concerne, le changement de configuration exact qui a reduit le risque, la liste des exceptions encore acceptees et la preuve technique montrant que le nouvel etat est bien applique en production. Cette discipline est utile parce que les problemes d'identite et de privilege ne sont presque jamais des decouvertes uniques. Ils reviennent plutot via le turnover administrateur, la derive applicative ou des dependances historiques mal comprises au premier passage. En documentant a la fois la correction et la raison pour laquelle elle a ete acceptee, les equipes reduisent le risque de refaire la meme analyse a chaque cycle ou de reintroduire la meme faiblesse en corrigeant un autre sujet operationnel.
