NTLM Relay: rilevamento e prevenzione

Gli attacchi NTLM Relay restano rilevanti perché molti ambienti Active Directory consentono ancora almeno un percorso di relay sfruttabile: SMB non firmato, gestione debole di LDAP, esposizione dell'enrollment web di AD CS, percorsi di coercizione o comportamenti legacy di risoluzione dei nomi che inducono le macchine ad autenticarsi dove non dovrebbero.

Che cos'è l'NTLM Relay?

Gli attacchi NTLM Relay sono tecniche di attacco di rete in cui un attaccante cattura uno scambio di autenticazione NTLM da un sistema e lo inoltra in tempo reale a un altro servizio. Per farlo, l'attaccante non ha bisogno di craccare l'hash della password. Il servizio di destinazione accetta l'autenticazione inoltrata perché lo scambio challenge-response NTLM è ancora valido per quella sessione.

In pratica, l'NTLM relay diventa un problema quando si allineano tre condizioni:

una vittima può essere indotta o costretta ad autenticarsi tramite NTLM
l'attaccante può raggiungere sulla rete sia la vittima sia il servizio di destinazione
il servizio di destinazione accetta ancora NTLM in un modo che non richiede la protezione che bloccherebbe il percorso di relay

Per questo motivo il relay non è un singolo bug. È la combinazione tra l'uso di NTLM, percorsi di risoluzione dei nomi deboli o di coercizione, e impostazioni di servizio permissive come SMB non firmato o gestione debole di LDAP.

Come funziona

NTLM è un protocollo challenge-response:

il client invia un messaggio negotiate
il server invia una challenge
il client restituisce un messaggio authenticate derivato da quella challenge

In un attacco di relay, l'attaccante inoltra questi messaggi tra la vittima e il servizio di destinazione. L'attaccante non sta violando il protocollo dal punto di vista crittografico. L'attaccante sta sfruttando il fatto che il servizio di destinazione è disposto ad accettare il contesto di autenticazione inoltrato.

Le vittime vengono comunemente indotte ad autenticarsi attraverso percorsi di risoluzione dei nomi deboli come LLMNR o NBT-NS, oppure attraverso percorsi di coercizione di applicazioni e servizi che innescano un'autenticazione in uscita.

La documentazione Microsoft sull'hardening di SMB afferma che la firma SMB aiuta a prevenire gli attacchi di relay e che richiedere la firma fa sì che client e server rifiutino i pacchetti non firmati. Per questo la firma SMB è un controllo contro gli esiti del relay SMB, non un'impostazione cosmetica.

Attacchi NTLM Relay: percorsi di relay comuni e cosa li blocca

Percorso di relay	Cosa vuole ottenere l'attaccante	Blocco principale
Relay SMB	Amministratore locale o esecuzione di codice su un server membro	Firma SMB richiesta sulla destinazione
Relay LDAP	Modifiche alla directory quando l'identità inoltrata dispone di diritti sufficienti e il percorso di destinazione lo consente	Firma LDAP e hardening del percorso di directory
Relay dell'enrollment web di AD CS	Emissione di certificati utilizzabili in seguito per abusi di autenticazione	Rimozione o hardening del percorso di enrollment vulnerabile

Una revisione utile deve quindi separare il trasporto del relay dal suo esito. Bloccare il relay SMB non elimina automaticamente le opportunità di relay LDAP o AD CS.

Vale anche la pena distinguere l'esposizione delle workstation da quella dei server. Un percorso di relay che approda solo su host membri di basso valore resta comunque un problema, ma la priorità della risposta cambia immediatamente quando lo stesso percorso può raggiungere controller di dominio, server di gestione, servizi certificati o account di servizio con deleghe estese.

Perché ridurre l'uso di NTLM non equivale a impostare un singolo valore di registro

Le restrizioni su NTLM, la firma SMB, la firma LDAP, l'EPA/channel binding, l'hardening della risoluzione dei nomi e l'hardening dei servizi certificati affrontano parti diverse dell'attacco. Un tenant può impostare una singola policy relativa a NTLM e continuare comunque a esporre il relay se un servizio di destinazione accetta lo scambio inoltrato.

È bene considerare l'insieme dei controlli come stratificato:

ridurre l'uso non necessario di NTLM dove il percorso applicativo supporta Kerberos o un'autenticazione più forte
richiedere la firma o una protezione equivalente sui servizi che accettano ancora NTLM
eliminare i comportamenti di risoluzione dei nomi che creano facili opportunità di cattura dell'autenticazione
rafforzare i percorsi AD CS e LDAP che trasformano un relay in un'escalation di dominio
monitorare l'uso di NTLM affinché le eccezioni restino visibili

La catena d'attacco

Fase 1 - Predisporre l'infrastruttura di relay

responder -I eth0 -rdw --no-HTTP-Server --no-SMB-Server
ntlmrelayx.py -tf targets.txt -smb2support -socks

Fase 2 - Catturare e inoltrare l'autenticazione

Quando un sistema vittima tenta di autenticarsi verso un listener controllato dall'attaccante, quest'ultimo inoltra lo scambio NTLM verso la destinazione scelta.

# Esempio di output di successo
# [*] Autenticazione contro smb://10.10.0.50 come CORP/jsmith SUCCEED

Fase 3 - Utilizzare l'identità inoltrata dove conta davvero

# Esempio di destinazione LDAP
ntlmrelayx.py -t ldap://dc01.corp.local --escalate-user attacker

# Esempio di destinazione SMB
ntlmrelayx.py -tf targets.txt -smb2support -c 'whoami'

# Esempio di percorso AD CS
ntlmrelayx.py -t http://ca.corp.local/certsrv/certfnsh.asp --adcs --template Machine

La sessione inoltrata è potente solo quanto lo consentono la destinazione e l'identità inoltrata. La domanda importante da porsi in una revisione non è se uno strumento sia in grado di emettere la richiesta, ma se l'ambiente esponga ancora una destinazione in cui quella richiesta si traduce in un privilegio significativo.

Rilevamento

ID evento di Windows

ID evento	Origine	Cosa cercare
4624	Sistema di destinazione	Accessi di rete di tipo 3 provenienti da un host di origine insolito
4776	DC	Attività di convalida NTLM che non rientra nel percorso normale per l'account
4625	Sistema di destinazione	Accessi di rete falliti ripetuti in concomitanza con test di relay o inoltri falliti

Microsoft documenta l'evento 4776 come convalida delle credenziali NTLM. Per gli account di dominio, il controller di dominio è autoritativo e può mostrare i tentativi di convalida NTLM per tali account. Questo è utile, ma non mostra ogni dettaglio del servizio di destinazione, quindi va correlato con i log di accesso e di servizio lato destinazione.

Indizi pratici di rilevamento

lo stesso account si autentica su più host in una finestra temporale breve a partire da un'unica origine
attività NTLM lato server proveniente da workstation che normalmente non avviano quel traffico
l'autenticazione inoltrata è seguita immediatamente da modifiche alla directory, attività da amministratore locale o comportamenti di enrollment di certificati
un account macchina si autentica verso un servizio insolito dopo un trigger simile a una coercizione
la convalida NTLM compare dove normalmente dovrebbe essere utilizzato Kerberos

Query di rilevamento SIEM (Elastic KQL)

event.code: '4624' AND
winlog.event_data.LogonType: '3' AND
winlog.event_data.AuthenticationPackageName: 'NTLM'

Questa query da sola non è specifica per il relay. Diventa utile quando viene arricchita con il ruolo dell'host, i percorsi di autenticazione previsti e il clustering temporale.

Rilevamento migliore attraverso la correlazione

Un rilevamento affidabile del relay richiede solitamente almeno due dei seguenti segnali:

convalida NTLM da una workstation o un server inatteso
accesso di tipo 3 lato destinazione che utilizza NTLM
accesso a servizi o named pipe rilevanti ai fini della coercizione
azione immediata sulla directory, da amministratore locale o di enrollment di certificati subito dopo l'autenticazione
host di origine da cui non ci si aspetta l'avvio dell'autenticazione verso la destinazione

Questa correlazione è più difendibile rispetto a generare alert su ogni utilizzo di NTLM. Molti ambienti presentano ancora dipendenze legittime da NTLM, quindi alert generici su NTLM creano rumore a meno che il team non abbia già ridotto il suo utilizzo.

Rimedio

Vittoria rapida: richiedere la firma SMB sui sistemi che accettano ancora SMB non firmato. Questo elimina l'esito di relay SMB più comune, ma non sostituisce l'hardening dei percorsi LDAP e dei certificati.

1. Richiedere la firma SMB

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature

Set-SmbClientConfiguration -RequireSecuritySignature $true
Set-SmbServerConfiguration -RequireSecuritySignature $true

Verificare sia i server sia i client. Un rollout parziale lascia percorsi ancora sfruttabili per il relay. Microsoft documenta che richiedere la firma SMB fa sì che il client o il server rifiutino i pacchetti non firmati, il comportamento necessario per bloccare gli esiti del relay SMB.

2. Disabilitare i percorsi di risoluzione dei nomi deboli

# Impostazione GPO
# Configurazione computer > Modelli amministrativi > Rete > Client DNS
# Disattiva risoluzione dei nomi multicast = Abilitato

La documentazione delle policy Microsoft per il client DNS afferma che l'abilitazione della policy disattiva LLMNR su tutte le schede di rete disponibili. Rivedere anche la risoluzione dei nomi NetBIOS legacy laddove sia ancora presente nell'ambiente.

3. Limitare NTLM dove il contesto operativo lo consente

Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -Value 5

Non distribuire le restrizioni su NTLM alla cieca. Iniziare con la modalità di audit e la scoperta delle dipendenze. Quindi applicare le restrizioni per server, account e percorso applicativo laddove la dipendenza di business sia compresa.

4. Rafforzare le destinazioni di directory e certificati

Se i controller di dominio o i servizi certificati sono ancora raggiungibili attraverso percorsi NTLM favorevoli al relay, la remediation non è completa. Verificare:

i requisiti di firma LDAP sui controller di dominio
il channel binding LDAP e l'Extended Protection dove applicabile
l'esposizione dell'enrollment web di AD CS e dei template dei certificati
se i server ad alto valore accettano ancora NTLM laddove dovrebbero invece essere utilizzati Kerberos o controlli più forti
se i percorsi di enrollment dei certificati possono emettere certificati utilizzabili per l'autenticazione verso identità macchina o utente inoltrate

5. Convalidare servizio per servizio, non policy per policy

La domanda sul relay è sempre concreta: questa autenticazione catturata o forzata può essere inoltrata a questa destinazione e produrre questo esito? Convalidare in modo indipendente i percorsi SMB, LDAP, AD CS e dei server di gestione. Un report GPO tutto verde non basta se un'OU di eccezione, un'appliance legacy o un endpoint dei servizi certificati restano sfruttabili per il relay.

Convalida dopo l'hardening

La condizione di successo non è "la GPO esiste". È che il servizio di destinazione non accetti più il percorso di relay che contava davvero.

ritestare destinazioni SMB rappresentative e confermare che richiedano la firma
verificare che il percorso della vittima che in precedenza generava traffico LLMNR, NBT-NS o altro traffico NTLM in uscita non produca più lo stesso risultato
confermare che le destinazioni di directory e certificati più rilevanti non siano più sfruttabili per il relay dallo stesso punto d'appoggio
rivedere l'attività recente relativa a 4624 e 4776 per assicurarsi che l'ambiente continui a funzionare per gli utenti legittimi mentre il percorso abusivo è stato eliminato
rivedere la configurazione della firma SMB di client e server dagli endpoint di ogni OU principale o gruppo di gestione dei dispositivi
verificare che l'esposizione dell'enrollment web di AD CS e dei template dei certificati sia stata risolta, se faceva parte della catena di relay

Questa convalida va eseguita su sistemi rilevanti per la produzione, non solo su una macchina di laboratorio che non ha mai fatto parte del rischio originale.

Come EtcSec rileva questo attacco

EtcSec correla le condizioni che rendono praticabile il relay: l'uso di NTLM, destinazioni favorevoli al relay e debolezze di configurazione correlate, come SMB debole, LDAP o esposizione dell'enrollment dei certificati. Questo è più utile di un singolo alert isolato, perché la stessa rete può contenere sia traffico NTLM innocuo sia un piccolo numero di percorsi realmente sfruttabili.