Durante gli audit interni, la stessa constatazione ritorna regolarmente: una rete in cui tutto sembra in ordine lato IPv4, firewall in posizione, VLAN segmentate, patch applicate. Eppure una sola postazione di lavoro può bastare a far cadere l’intero dominio in meno di un’ora. Tra le porte d’ingresso più discrete in questo scenario, una riguarda un protocollo che quasi nessuno sorveglia: IPv6, attivo per impostazione predefinita su Windows e lasciato senza configurazione. Questo articolo descrive l’attacco mitm6 passo dopo passo, con il contesto che spiega perché resti così efficace anni dopo la sua pubblicazione.
IPv6: il protocollo che nessuno configura
A partire da Windows Vista, IPv6 è attivo per impostazione predefinita su tutte le postazioni e su tutti i server. Meglio (o peggio, a seconda del punto di vista): lo stack di rete di Windows preferisce IPv6 a IPv4. Questa preferenza non ha nulla di arbitrario, deriva dalla RFC 6724 che definisce l’ordine di selezione degli indirizzi. In concreto, quando una macchina si avvia o rinnova la propria configurazione, diffonde richieste per scoprire un router e un server di indirizzamento: messaggi Router Solicitation e richieste DHCPv6. Nella quasi totalità delle reti aziendali nessuno risponde, perché nessun servizio IPv6 è mai stato implementato. La postazione resta quindi in attesa, senza gateway né server DNS IPv6, fino al giorno in cui un attaccante decide molto volentieri di fornirglieli.
Come promemoria, un server DNS traduce i nomi leggibili (come fichiers.entreprise.local) in indirizzi di rete. Chi controlla il DNS di una macchina controlla in gran parte ciò che essa contatta, e può quindi indirizzarla verso server di sua scelta.
Questa situazione, un protocollo acceso ma mai amministrato, crea esattamente il vuoto che un intruso viene a colmare. La ricerca all’origine dell’attacco, pubblicata dal ricercatore Dirk-jan Mollema, ha dimostrato che bastava rispondere educatamente a queste richieste per inserire una macchina malevola nel cuore degli scambi.
mitm6: spacciarsi per il DNS
Lo strumento mitm6 ascolta il segmento di rete e risponde a queste richieste rimaste orfane. Assegna alla postazione Windows un indirizzo IPv6 e, soprattutto, si annuncia come server DNS IPv6 della macchina tramite una risposta DHCPv6. Poiché Windows privilegia IPv6, la postazione cambia subito configurazione: da quel momento invia le proprie richieste di risoluzione dei nomi all’attaccante invece che al DNS legittimo del dominio.
mitm6 -d entreprise.localL’opzione -d limita l’avvelenamento al dominio bersaglio, per restare discreti ed evitare di perturbare tutta la rete. Da lì in poi l’attaccante risponde alle risoluzioni con i propri indirizzi e intercetta le autenticazioni automatiche che Windows emette di continuo verso i server interni, senza la minima azione da parte dell’utente.
WPAD: il complice che innesca l’autenticazione
Resta da provocare un’autenticazione sfruttabile. È qui che entra in gioco WPAD (Web Proxy Auto-Discovery), un meccanismo con cui i browser e numerosi componenti Windows cercano automaticamente un file di configurazione del proxy sulla rete. mitm6 risponde alla richiesta per wpad, presenta un falso file di configurazione e la postazione tenta allora di autenticarsi presso il proxy malevolo. Windows invia spontaneamente l’identità dell’utente connesso, sotto forma di un’autenticazione NTLM, senza mai chiedere conferma.
In parole semplici: l’utente non clicca su nulla e non digita alcuna password. La sua postazione offre da sé la sua identità al primo server che la richiede educatamente.
Il relay NTLM: dall’ascolto alla presa di controllo
Intercettare il DNS e raccogliere un’autenticazione non basta ancora. Il secondo tassello, il più decisivo, è il relay dell’autenticazione NTLM, realizzato con ntlmrelayx, uno strumento della suite Impacket. Il principio è elegante e temibile: invece di tentare di craccare una password, l’attaccante inoltra l’autenticazione ricevuta, così com’è, verso un servizio dell’Active Directory, tipicamente il LDAP di un domain controller. Questo replay è però possibile solo se il servizio bersaglio non impone la firma dei propri scambi: senza firma LDAP (o SMB), nulla lega l’autenticazione al server legittimo e l’attaccante può riutilizzarla altrove. Un prossimo articolo sarà dedicato a questi meccanismi di firma e al modo in cui bloccano il relay NTLM.
ntlmrelayx.py -6 -t ldaps://dc.entreprise.local -wh attaquant-wpad --delegate-accessIn parole semplici: la macchina bersaglio crede di parlare con un server legittimo, ma in realtà parla con l’attaccante, che riutilizza immediatamente quell’identità presso la directory, con tutti i diritti che la accompagnano.
A seconda dei privilegi dell’identità inoltrata, l’impatto cresce:
- leggere l’intera directory Active Directory, compresa la mappatura dei gruppi e degli amministratori;
- creare un nuovo account macchina o utente interamente controllato dall’attaccante;
- configurare una delega di diritti (tramite l’attributo msDS-AllowedToActOnBehalfOfOtherIdentity) che consente di impersonare altri account, a volte fino all’amministratore del dominio.
Il tutto senza sfruttare alcuna vulnerabilità software: solo funzioni native di Windows sviate dal loro uso previsto. Nessuna patch di sicurezza «ripara» questo comportamento, perché si tratta di un funzionamento previsto del protocollo.
Come si svolge l’attacco durante un audit interno
Condotto nel corso di un audit interno, questo attacco IPv6 si svolge quasi sempre allo stesso modo. Una macchina viene collegata a una presa di rete di un open space, spesso una sala riunioni accessibile. mitm6 si avvia e, in pochi minuti, le prime postazioni in fase di avvio o di riattivazione cambiano il proprio DNS. ntlmrelayx raccoglie le autenticazioni in ingresso e le inoltra verso un domain controller. Se anche una sola di queste autenticazioni appartiene a un account con diritti di scrittura sulla directory, la partita è chiusa: c’è quanto basta per creare un account, impostare una delega e, passo dopo passo, risalire fino ai diritti di amministrazione del dominio. Il tutto resta passivo dal punto di vista dell’utente, che continua a lavorare senza notare nulla.
L’impatto sul business è all’altezza: la compromissione di un domain controller significa il controllo degli accessi di tutta l’organizzazione, la possibilità di leggere le condivisioni di file, di distribuire un ransomware su larga scala o di esfiltrare dati. Una presa di rete mal segmentata in una hall d’ingresso diventa allora il punto di partenza di un incidente grave.
Rilevare l’attacco sulla rete
Questi scambi lasciano tracce caratteristiche: una postazione che improvvisamente inizia a distribuire configurazioni IPv6, Router Advertisement inattesi, la comparsa di un server DHCPv6 là dove non ce n’è mai stato uno, un flusso di autenticazioni inoltrate verso i domain controller. La BOX Oxyscan monitora questi segnali direttamente sulla rete e segnala la comparsa di un server DHCPv6 o DNS IPv6 illegittimo, un forte indizio che un attacco di tipo mitm6 è in corso. Implementata in modo continuativo, consente di identificare, sull’intero parco, le macchine esposte a questo tipo di intercettazione. Rilevare presto questa fase di preparazione significa interrompere l’attacco prima del primo relay riuscito.
Sulla rete, questi messaggi sono visibili in una cattura: non appena lo strumento entra in azione, i Router Advertisement e le Neighbor Solicitation ICMPv6 si moltiplicano.
Correggere la falla: neutralizzare IPv6 senza disattivarlo
La prima reazione, spegnere puramente e semplicemente IPv6, raramente è quella giusta. Microsoft sconsiglia questa disattivazione totale, perché Windows è testato con IPv6 attivo e alcuni componenti (Exchange, cluster di failover) possono comportarsi male senza di esso. L’obiettivo non è quindi eliminare IPv6, ma impedire a una postazione di accettare una configurazione IPv6 distribuita da uno sconosciuto.
La misura più pulita consiste nel bloccare, tramite Windows Firewall distribuito via GPO su tutto il dominio, i due tasselli di cui l’attacco ha bisogno: le risposte DHCPv6 e i Router Advertisement. Tre regole predefinite passano a Blocca:
- (In ingresso) Core Networking, Dynamic Host Configuration Protocol for IPv6 (DHCPV6-In), porta UDP 546;
- (In ingresso) Core Networking, Router Advertisement (ICMPv6-In), ICMPv6 tipo 134;
- (In uscita) Core Networking, Dynamic Host Configuration Protocol for IPv6 (DHCPV6-Out).
Questa configurazione neutralizza l’attacco pur conservando gli indirizzi IPv6 link-local, quindi non ha effetti collaterali sui componenti Windows.
Lato rete, le funzioni RA Guard e DHCPv6 Guard completano il quadro sugli switch: bloccano al bordo i Router Advertisement e le risposte DHCPv6 emessi da una porta non autorizzata, e proteggono anche le macchine Linux e macOS che l’hardening di Windows non copre. Su questi sistemi, i Router Advertisement possono essere rifiutati anche localmente (per esempio
sysctl net.ipv6.conf.all.accept_ra=0su Linux).
Una variante consiste nel dare priorità a IPv4 rispetto a IPv6, il che toglie alla configurazione distribuita dall’attaccante la priorità su quella legittima. Anche questa impostazione si distribuisce via GPO, tramite una preferenza di registro:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
DisabledComponents = 0x20 (DWORD 32 bits)Solo come ultima risorsa, se una policy interna impone la disattivazione completa di IPv6, la si realizza tramite PowerShell su ogni macchina. La stessa famiglia di comandi permette peraltro di verificare lo stato del protocollo sulle schede di rete:
Disable-NetAdapterBinding -Name "*" -ComponentID ms_tcpip6
Questo metodo copre tuttavia solo le schede di rete esistenti e non si distribuisce nativamente via GPO, a differenza dei due precedenti. Infine, qualunque sia l’opzione scelta, la firma SMB, la firma LDAP e il channel binding LDAP restano indispensabili: anche se una postazione cadesse nella trappola, queste protezioni impediscono il riutilizzo dell’autenticazione intercettata, e quindi il relay che costituisce tutto l’interesse dell’attacco.
Conclusione
mitm6 illustra un principio che si verifica a ogni missione: una funzionalità attiva per impostazione predefinita e mai configurata resta una superficie d’attacco a tutti gli effetti. IPv6 non è pericoloso di per sé, lo è il suo abbandono. Poche misure mirate chiudono la breccia senza compromettere l’esistente, e la maggior parte è raccomandata da tempo dall’ANSSI nelle sue guide di hardening dell’Active Directory.
Consigli: disattivare IPv6 sulle postazioni solo se non viene utilizzato (e in modo pulito, tramite criteri di gruppo, piuttosto che con un intervento improvvisato), attivare il DHCPv6 Guard e il RA Guard sugli switch per bloccare gli annunci malevoli, imporre la firma LDAP e il channel binding (Extended Protection for Authentication) sui domain controller per rendere inefficace qualsiasi relay, e segmentare le prese di rete accessibili al pubblico.
Per approfondire
- Consulenza e accompagnamento in cybersecurity Oxydian, per implementare le contromisure (RA Guard, DHCPv6 Guard, firme SMB e LDAP) senza compromettere l’esistente.
- L’articolo dedicato al Kerberoasting, in cui il cracking offline prende di mira gli account di servizio dell’Active Directory.
- MITRE ATT&CK, tecnica T1557 (Adversary-in-the-Middle), il riferimento che classifica e documenta gli attacchi di intercettazione e relay.
- ANSSI, guide alla messa in sicurezza di Active Directory e all’hardening di Windows.
- Progetto mitm6 di Dirk-jan Mollema, la ricerca e lo strumento all’origine della tecnica.
- Suite Impacket (ntlmrelayx), il toolkit open source utilizzato per il relay NTLM.
- Microsoft Learn, attivare la firma LDAP sui domain controller.
