Attaques NTLM Relay : Détection et Prévention

Les attaques par relais NTLM restent d'actualité car de nombreux environnements Active Directory autorisent encore au moins un chemin de relais exploitable : SMB non signé, gestion LDAP laxiste, exposition de l'inscription web AD CS, chemins de coercition, ou comportements hérités de résolution de noms qui poussent des machines à s'authentifier là où elles ne le devraient pas.

Qu'est-ce que le relais NTLM ?

Les attaques par relais NTLM sont des techniques d'attaque réseau dans lesquelles un attaquant capture un échange d'authentification NTLM provenant d'un système et le transfère en temps réel vers un autre service. L'attaquant n'a pas besoin de casser le hash du mot de passe pour cela. Le service cible accepte l'authentification relayée car l'échange challenge-réponse NTLM reste valide pour cette session.

En pratique, le relais NTLM devient un problème lorsque trois conditions sont réunies :

• une victime peut être contrainte ou incitée à s'authentifier via NTLM
• l'attaquant peut atteindre la victime et le service cible sur le réseau
• le service cible accepte encore NTLM d'une manière qui ne requiert pas la protection qui bloquerait le chemin de relais

C'est pourquoi le relais n'est pas un bug isolé. C'est la combinaison de l'usage de NTLM, de mécanismes de résolution de noms faibles ou de chemins de coercition, et de paramètres de service permissifs tels que le SMB non signé ou une gestion LDAP laxiste.

Comment ça fonctionne

NTLM est un protocole de type challenge-réponse :

1. le client envoie un message de négociation (negotiate)
2. le serveur envoie un challenge
3. le client renvoie un message d'authentification dérivé de ce challenge

Dans une attaque par relais, l'attaquant transfère ces messages entre la victime et le service cible. L'attaquant ne brise pas la cryptographie du protocole. Il exploite le fait que le service cible accepte de valider le contexte d'authentification relayé.

Les victimes sont couramment poussées à s'authentifier via des mécanismes de résolution de noms faibles comme LLMNR ou NBT-NS, ou via des chemins de coercition applicatifs et de service qui déclenchent une authentification sortante.

La documentation de Microsoft sur le durcissement SMB indique que la signature SMB aide à prévenir les attaques par relais, et que le fait d'exiger la signature entraîne le rejet des paquets non signés par les clients et les serveurs. C'est pourquoi la signature SMB est un contrôle contre les conséquences du relais SMB, et non un paramètre cosmétique.

Attaques par relais NTLM : chemins de relais courants et ce qui les bloque

Une revue utile doit donc séparer le transport du relais de son résultat. Bloquer le relais SMB ne supprime pas automatiquement les opportunités de relais LDAP ou AD CS.

Il est également utile de distinguer l'exposition des postes de travail de celle des serveurs. Un chemin de relais qui n'atteint que des hôtes membres à faible valeur reste un problème, mais la priorité de la réponse change immédiatement dès lors que le même chemin peut atteindre des contrôleurs de domaine, des serveurs de gestion, des services de certificats, ou des comptes de service fortement délégués.

Pourquoi réduire l'usage de NTLM ne se résume pas à une seule valeur de registre

Les restrictions NTLM, la signature SMB, la signature LDAP, l'EPA/channel binding, le durcissement de la résolution de noms et le durcissement des services de certificats traitent des aspects différents de l'attaque. Un tenant peut configurer une politique liée à NTLM tout en restant exposé au relais si un service cible accepte l'échange relayé.

Considérez cet ensemble de contrôles comme un dispositif en couches :

• réduire l'usage inutile de NTLM lorsque le chemin applicatif prend en charge Kerberos ou une authentification plus forte
• exiger la signature ou une protection équivalente sur les services qui acceptent encore NTLM
• supprimer les comportements de résolution de noms qui créent des opportunités faciles de capture d'authentification
• durcir les chemins AD CS et LDAP qui transforment un relais en escalade de domaine
• surveiller l'usage de NTLM afin que les exceptions restent visibles

La chaîne d'attaque

Étape 1 - Mettre en place l'infrastructure de relais

responder -I eth0 -rdw --no-HTTP-Server --no-SMB-Server
ntlmrelayx.py -tf targets.txt -smb2support -socks

Étape 2 - Capturer et transférer l'authentification

Lorsqu'un système victime tente de s'authentifier auprès d'un listener contrôlé par l'attaquant, ce dernier transfère l'échange NTLM vers la cible choisie.

# Exemple de sortie en cas de succès
# [*] Authenticating against smb://10.10.0.50 as CORP/jsmith SUCCEED

Étape 3 - Utiliser l'identité relayée là où elle compte

# Exemple de cible LDAP
ntlmrelayx.py -t ldap://dc01.corp.local --escalate-user attacker

# Exemple de cible SMB
ntlmrelayx.py -tf targets.txt -smb2support -c 'whoami'

# Exemple de chemin AD CS
ntlmrelayx.py -t http://ca.corp.local/certsrv/certfnsh.asp --adcs --template Machine

La session relayée n'a que le pouvoir que lui accordent la cible et l'identité relayée. La question de revue importante n'est pas de savoir si un outil peut émettre la requête. C'est de savoir si l'environnement expose encore une cible où cette requête se traduit par un privilège significatif.

Détection

Identifiants d'événements Windows

Microsoft documente l'événement 4776 comme une validation d'identifiants NTLM. Pour les comptes de domaine, le contrôleur de domaine fait autorité et peut afficher les tentatives de validation NTLM pour ces comptes. C'est utile, mais cela ne montre pas tous les détails du service de destination ; il faut donc le corréler avec les journaux de connexion et de service côté cible.

Indices de détection pratiques

• un même compte s'authentifie sur plusieurs hôtes dans une fenêtre de temps courte depuis une seule source
• une activité NTLM côté serveur apparaît depuis des postes de travail qui n'initient normalement pas ce type de trafic
• une authentification relayée est immédiatement suivie d'une modification de l'annuaire, d'une activité d'administration locale, ou d'un comportement d'inscription de certificat
• un compte machine s'authentifie sur un service inhabituel après un déclencheur ressemblant à une coercition
• une validation NTLM apparaît là où Kerberos devrait normalement être utilisé

Requête de détection SIEM (Elastic KQL)

event.code: '4624' AND
winlog.event_data.LogonType: '3' AND
winlog.event_data.AuthenticationPackageName: 'NTLM'

Cette requête n'est pas spécifique au relais en elle-même. Elle devient utile lorsqu'on l'enrichit avec le rôle de l'hôte, les chemins d'authentification attendus et un regroupement temporel.

Une meilleure détection grâce à la corrélation

Une détection de relais fiable nécessite généralement au moins deux de ces signaux :

• validation NTLM depuis un poste de travail ou un serveur inattendu
• connexion de type 3 côté cible utilisant NTLM
• accès à des services ou des named pipes pertinents pour la coercition
• action immédiate sur l'annuaire, l'administration locale, ou l'inscription de certificat après l'authentification
• hôte source dont on n'attend pas qu'il initie une authentification vers la cible

Cette corrélation est plus défendable qu'une alerte sur tout usage de NTLM. De nombreux environnements ont encore des dépendances légitimes à NTLM ; des alertes NTLM trop larges génèrent donc du bruit, sauf si l'équipe a déjà réduit son usage.

Remédiation

Gain rapide : exigez la signature SMB sur les systèmes qui acceptent encore le SMB non signé. Cela élimine le résultat de relais SMB le plus courant, mais ne remplace pas le durcissement des chemins LDAP et de certificats.

1. Exiger la signature SMB

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature

Set-SmbClientConfiguration -RequireSecuritySignature $true
Set-SmbServerConfiguration -RequireSecuritySignature $true

Passez en revue à la fois les serveurs et les clients. Un déploiement partiel laisse subsister des chemins exploitables par relais. Microsoft documente que l'exigence de signature SMB entraîne le rejet des paquets non signés par le client ou le serveur, ce qui est le comportement nécessaire pour stopper les conséquences du relais SMB.

2. Désactiver les mécanismes faibles de résolution de noms

# Paramètre GPO
# Computer Configuration > Administrative Templates > Network > DNS Client
# Turn off multicast name resolution = Enabled

La documentation de la stratégie DNS Client de Microsoft indique que l'activation de cette stratégie désactive LLMNR sur toutes les cartes réseau disponibles. Passez également en revue la résolution de noms NetBIOS héritée là où elle existe encore dans l'environnement.

3. Restreindre NTLM là où le contexte métier le permet

Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -Value 5

Ne déployez pas les restrictions NTLM à l'aveugle. Commencez par le mode audit et la découverte des dépendances. Restreignez ensuite par serveur, par compte et par chemin applicatif là où la dépendance métier est comprise.

4. Durcir les cibles d'annuaire et de certificats

Si les contrôleurs de domaine ou les services de certificats restent accessibles via des chemins NTLM propices au relais, la remédiation n'est pas terminée. Passez en revue :

• les exigences de signature LDAP sur les contrôleurs de domaine
• le channel binding LDAP et l'Extended Protection le cas échéant
• l'exposition de l'inscription web AD CS et des modèles de certificats
• si des serveurs à forte valeur acceptent encore NTLM alors que Kerberos ou des contrôles plus stricts devraient être utilisés à la place
• si les chemins d'inscription de certificats peuvent émettre des certificats utilisables pour l'authentification à des identités machine ou utilisateur relayées

5. Valider service par service, pas stratégie par stratégie

La question du relais est toujours concrète : cette authentification capturée ou obtenue par coercition peut-elle être relayée vers cette cible et produire ce résultat ? Validez indépendamment les chemins SMB, LDAP, AD CS et des serveurs de gestion. Un rapport GPO au vert ne suffit pas si une OU d'exception, un appareil hérité ou un point de terminaison de service de certificats reste exploitable par relais.

Valider après le durcissement

Le critère de réussite n'est pas « la GPO existe ». C'est que le service cible n'accepte plus le chemin de relais qui posait problème.

• retester des cibles SMB représentatives et confirmer qu'elles exigent la signature
• vérifier que le chemin victime qui générait auparavant du trafic LLMNR, NBT-NS ou d'autres trafics NTLM sortants ne produit plus le même résultat
• confirmer que les cibles d'annuaire et de certificats les plus critiques ne sont plus exploitables par relais depuis le même point d'ancrage
• examiner l'activité récente des événements 4624 et 4776 pour s'assurer que l'environnement fonctionne toujours pour les utilisateurs légitimes une fois le chemin abusif supprimé
• vérifier la configuration de signature SMB côté client et serveur depuis des postes de chaque OU majeure ou groupe de gestion d'appareils
• vérifier que l'exposition de l'inscription web AD CS et des modèles de certificats a été corrigée si elle faisait partie de la chaîne de relais

Cette validation doit être effectuée sur des systèmes représentatifs de la production, et non uniquement sur une machine de laboratoire qui n'a jamais fait partie du risque initial.

Comment EtcSec détecte cela

EtcSec corrèle les conditions qui rendent le relais exploitable en pratique : usage de NTLM, cibles propices au relais, et faiblesses de configuration voisines telles qu'un SMB faible, une exposition LDAP ou une inscription de certificats. C'est plus utile qu'un signalement isolé unique, car un même réseau peut contenir à la fois du trafic NTLM inoffensif et un petit nombre de chemins réellement exploitables.

Lectures connexes

• Sécurité des mots de passe Active Directory : les erreurs de configuration qui comptent
• Mauvaises configurations GPO : comment la stratégie de groupe devient un vecteur d'attaque
• Supervision de la sécurité Active Directory : les identifiants d'événements qui comptent
• Abus d'ACL et DCSync : les chemins silencieux vers Domain Admin
• Chemins d'attaque Active Directory vers Domain Admin
• Signature SMB désactivée : pourquoi elle permet toujours le relais NTLM

Références principales

• Durcissement de la sécurité SMB dans Windows Server et Windows Client
• Contrôler le comportement de la signature SMB
• 4776 : l'ordinateur a tenté de valider les informations d'identification d'un compte
• Auditer la validation des informations d'identification
• Stratégie ADMX DNS Client : désactiver la résolution de noms multicast
• Protéger le trafic SMB contre l'interception