Définition

Le protocole NTLM est un ancien protocole d’authentification utilisé par les machines Windows utilisé pour s’authentifier au niveau d’un domaine ou au niveau du réseau. C’est un protocole de type Challenge / Response donc il permet de s’authentifier auprés d’un serveur sans jamais que le mot de passe ne transite sur le réseau.

Ce protocole est trés utilisé par les entreprises conjointement avec le protocole Kereberos. Seul les entreprises avec une bonne maturité cyber ne l’utilise plus car ce n’est pas simple de s’en passer.

Principe de fonctionnement

Lorsqu’un client veut s’authentifier auprés d’un serveur en utilisant ce protocole, le serveur va envoyer un challenge au client et ce dernier va essayer de le résoudre en utilisant le hash de son mot de passe. Une fois le challenge résolu, le client va envoyer la réponse au challenge et le serveur va effectuer la même opération et comparer le résultat du client avec le sien. Si le résultat est le même, cela signifie que le client possède le secret avec lequel il fallait résoudre le challenge et donc qu’il est bien celui qu’il prétend être.

Le protocole NTLM est encapsuler de plusieurs protocoles comme SMB, LDAP ou HTTP par exemple. Ansi, c’est protocole peuvent utiliser NTLM pour authentifier un client. Cela est possible grâce à la solution SSIP (Security Support Provider Interface) qui est une interface mis à disposition par Microsoft qui permet de réutiliser le protocole NTLM sans avoir à la reconstruire de 0.

L’attaque NTLM Relay

L’attaque NTLM Relay est une attaque de type Man-in-The-Middle, c’est à dire que l’attaquant va se positionner entre le client et le serveur et se faire passer pour le client auprés du serveur et inversement.

Pour ce faire, plusieurs méthode sont possibles et la méthode que l’on va aborder ici est une méthode utilisant les protocoles de résolution de type multi cast.

Protocole de résolution multicast/broadcast

Les équipements Windows utilisent différents protocoles pour la résolution de nom de domaine. Les plus utilisés sont les suivants :

DNS (Domain Name System)
LLMNR (Link Local Multicast Name Resolution)
NBT-NS (Netbios Name Service)
mDNS (Multicast DNS)

Celui qui est utilisé en priorité est le DNS mais dans le cas ou celui ci ne permet pas de résoudre le nom de domaine recherché, les 3 autres sont utilisés dans le cas où ils sont activés. Le problème c’est que ces protocoles sont de type broadcast c’est à dire qu’ils vont envoyer leur demande de résolution à tous le réseau local en espérant que quelqu’un y réponde. Ainsi, un attaquant peut répondre de manière illégitime à ces requêtes et exiger une authentification auprès des client.

Une fois cette demande d’authentification récupéré, l’attaquant peut la relayer auprés d’un serveur pour usurper l’identité du client. Ce processus est bien expliqué dans le schéma ci-dessous :

Pour que cette attaque fonctionne, il est important de préciser que la signature ne doit pas être forcer sur les protocoles pour les serverus cibles. En effet, si la signature est forcée alors l’attaquant ne pourra pas relayer les requêtes

En pratique

Pour réaliser cet attaque, il faut utiliser 4 outils, responder, nxc, ntlmrelayx et proxychains.

On commence par lancer responder qui va nous permettre d’écouter les reqêtes LLMNR, NBT-NS et mDNS:

1	responder -dvw -I eth0

-d pour lancer un seveur dhcp
– v pour la verbose
-w pour lancer un serveur wpad
PS : Il ne faut pas oublier de desactiver le seveur SMB, HTTP et LDAP dans la configuration qui se trouve dans : /etc/responder/responder.conf

Ensuite, on récupére la liste des serveurs qui n’exigent pas la signature pour le protocole SMB avec cette commande :

1	nxc smb --gen-relay-list smb_targets.txt 10.10.10.0/24

Puis, on utilise ntlmrelayx qui va nous permettre de relayer les requêtes des clients et des serveurs sur le réseau avec cette commande :

1	impacket-ntlmrelayx -socks -smb2support -tf smb_targets.txt

-socks : pour stocker les sessions dans un socks
-smb2support : support de la version 2 de SMB
-tf liste des machines n’exigeant pas la signature

Par défaut, ntlmrelayx ouvre un sock sur le port 1080, il faut donc modifier la configuration de proxychains qui se trouve dans le fichier /etc/proxychains4.conf

Par la suite, lorsque des tentatives d’authentification sont relayés, on peut récupérer des socks :