Bloccare il NTLM in uscita sui controller di dominio Tier 0: attacchi di coercizione e relay fermati a livello di GPO

Che cosa significa «NTLM in uscita» per un controller di dominio

Questa guida spiega come bloccare il NTLM in uscita sui controller di dominio Tier 0: le catene di coercizione e relay come PetitPotam e le tecniche che ne sono seguite dipendono interamente dal fatto che quella autenticazione in uscita esista in partenza — negatela, e non resta loro nulla da ritrasmettere. I controller di dominio autenticano con Kerberos quasi tutto ciò che fanno tra loro e verso gli altri servizi integrati in Active Directory, ma NTLM continua a esistere al di sotto come ripiego e, per impostazione predefinita, qualsiasi sistema Windows si autentica volentieri verso l'esterno tramite NTLM presso qualunque server glielo chieda.

L'ANSSI, l'agenzia nazionale francese per la cibersicurezza, documenta direttamente questo schema nella sua guida all'amministrazione di Active Directory. L'autenticazione NTLMv2 è un accesso di rete — distinto dagli accessi interattivi che lasciano in memoria hash riutilizzabili — e la sua risposta alla sfida può essere intercettata al volo e ritrasmessa a un secondo bersaglio senza che l'attaccante venga mai a conoscenza del segreto sottostante: prende in prestito i diritti di accesso della vittima invece di rubarne la password (ANSSI-PA-099, §4.15.2). Quando il sistema sottoposto a coercizione è un controller di dominio, i diritti di accesso ritrasmessi sono quelli del Tier 0.

Come gli attacchi di coercizione e relay abusano del NTLM in uscita

Il membro meglio documentato di questa famiglia è PetitPotam. L'avviso del CERT/CC dedicato alla tecnica spiega che essa abusa del protocollo remoto del file system con crittografia (EFSRPC): una chiamata a EfsRpcOpenFileRaw induce il sistema bersaglio a «usare NTLM per autenticarsi presso l'host specificato all'interno del percorso», e un attaccante può puntare quel percorso verso un'infrastruttura che controlla — innescando un tentativo di autenticazione NTLM dall'account computer dello stesso controller di dominio, senza alcuna credenziale necessaria per avviare la catena (CERT/CC VU#405600).

Quell'autenticazione NTLM catturata è pericolosa solo perché da qualche altra parte viene accettata. Il CERT/CC espone in tre passaggi la catena completa contro i Servizi certificati Active Directory (AD CS):

Passaggio 1 — Coercizione

L'attaccante chiama EfsRpcOpenFileRaw (o un metodo RPC equivalente con lo stesso comportamento che innesca l'autenticazione) contro il controller di dominio, puntandolo verso un'infrastruttura sotto il proprio controllo. L'account computer del DC apre un'autenticazione NTLM in uscita — si tratta di un accesso di rete, precisa la guida dell'ANSSI, e non del tipo interattivo che lascia hash riutilizzabili in memoria.

Passaggio 2 — Relay

L'attaccante cattura la risposta alla sfida NTLMv2 — l'hash «Net-NTLMv2» — e la ritrasmette immediatamente, senza modificarla, all'endpoint HTTP di registrazione web di AD CS prima che scada.

Passaggio 3 — Conversione

AD CS rilascia un certificato per l'account computer del controller di dominio. Il CERT/CC osserva che quel certificato «può essere usato per ottenere un Ticket Granting Ticket», il che basta a compromettere l'intero dominio — senza che sia mai stato necessario violare una password o un hash.

Ogni passaggio di quella catena dipende dalla riuscita del passaggio 1: il controller di dominio deve essere disposto a inviare autenticazione NTLM verso l'esterno in partenza. Togliete questo, e i passaggi 2 e 3 non hanno più nulla su cui lavorare.

La correzione di Microsoft, tracciata come CVE-2021-36942 («Windows LSA Spoofing Vulnerability»), ha chiuso soltanto la versione non autenticata della chiamata EfsRpcOpenFileRaw. Non ha chiuso lo schema sottostante — un sistema Tier 0 può ancora essere spinto a un'autenticazione NTLM in uscita attraverso altre interfacce RPC che si comportano allo stesso modo, ed è questo il motivo per cui le indicazioni di mitigazione della stessa Microsoft per questa famiglia di attacchi vanno oltre una singola patch. L'articolo KB5005413 raccomanda di abilitare la protezione estesa per l'autenticazione sugli endpoint AD CS e, come opzione più forte a livello di protocollo, di «disabilitare l'autenticazione NTLM sul controller di dominio Windows» puramente e semplicemente (Microsoft KB5005413). Quella seconda opzione è esattamente ciò che la raccomandazione R73 dell'ANSSI traduce in un unico parametro di Criteri di gruppo.

Bloccare il NTLM in uscita sui controller di dominio Tier 0 (ANSSI R73)

La raccomandazione R73 dell'ANSSI è diretta: «le autenticazioni NTLM in uscita da tutti i sistemi del Tier 0 devono essere bloccate», applicata tramite un unico parametro di Criteri di gruppo. Il percorso della GPO, ripreso dalla guida, è:

Computer Configuration\Windows Settings\Security Settings\Local Policies\
Security Options\Network Security: Restrict NTLM: Outgoing NTLM traffic
to remote servers → Deny all

La documentazione di riferimento di Microsoft per questo parametro conferma gli stessi tre stati — Allow all (nessuna restrizione), Audit all (registra ogni tentativo di NTLM in uscita senza bloccarlo) e Deny all (il dispositivo «non può autenticare alcuna identità presso un server remoto usando l'autenticazione NTLM») — e precisa che il parametro è Not Configured per impostazione predefinita su ogni controller di dominio e su ogni server membro (Microsoft Learn — Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers). Lasciato non configurato, offre alla famiglia coercizione-e-relay esattamente il percorso in uscita di cui ha bisogno.

L'ANSSI è esplicita: Audit all non basta per R73 — la raccomandazione prescrive il blocco, non la registrazione. La modalità audit è il passo preliminare alla distribuzione: lasciatela attiva abbastanza a lungo da confermare che non esiste traffico NTLM in uscita legittimo dal Tier 0 (normalmente non dovrebbe essercene, poiché il traffico da DC a DC e da DC ai servizi AD supporta Kerberos in modo nativo), poi passate a Deny all. La guida aggiunge una riserva operativa da prendere sul serio: bloccare il NTLM in uscita presuppone che i sistemi del Tier 0 raggiungano gli altri servizi AD tramite FQDN anziché tramite indirizzo IP grezzo, poiché Kerberos dipende dalla risoluzione dei nomi per selezionare il ticket di servizio corretto — una configurazione errata che la fase di audit farà emergere prima che provochi un'interruzione.

Il controllo complementare: limitare ciò che il Tier 0 invia verso il basso (ANSSI R82/R83)

Bloccare il NTLM in uscita chiude il versante dell'autenticazione di rete dell'esposizione del Tier 0. La posizione di riferimento dell'ANSSI è che le postazioni di amministrazione del Tier 0 non dovrebbero avere alcuna connettività verso il basso in partenza — dedicate fisicamente, con traffico in uscita consentito soltanto verso risorse del Tier 0 (R80). R82 e R83 si applicano specificamente quando un'organizzazione adotta invece la seconda architettura alternativa dell'ANSSI: la condivisione dell'accesso remoto del Tier 0 verso ambienti a minore affidabilità, come ripiego transitorio in attesa di una segregazione completa. All'interno di quel modello, R82 limita quali metodi di connessione remota sono consentiti in uscita dal Tier 0 verso zone a minore affidabilità — RPC/MMC, PowerShell WinRM con la sua autenticazione di rete Kerberos-o-NTLM predefinita, oppure RDP nativo, sia in modalità RestrictedAdmin sia con un account circoscritto al tier di destinazione. R83 va oltre: l'account usato per una sessione interattiva su quella destinazione a minore affidabilità deve appartenere alla zona di affidabilità della destinazione stessa, mai a una credenziale Tier 0 o Tier 1, così che un sistema di tier inferiore compromesso non finisca mai per detenere segreti Tier 0 riutilizzabili. Per la trattazione completa delle restrizioni di accesso circoscritte per tier, si veda Criteri di autenticazione e silo di Active Directory per il Tier 0.

Rilevare il NTLM in uscita prima e dopo il blocco

Entrambi gli Event ID sono confermati direttamente nell'ANSSI-PA-099 §4.15.2.1, e la documentazione di riferimento di Microsoft per questo parametro di criterio rimanda allo stesso percorso di registro operativo. Due aspetti da tenere sotto osservazione una volta che il blocco è attivo:

• Qualsiasi raffica di Event ID 4001 dopo la distribuzione merita un'indagine — o è stata tralasciata una dipendenza legittima durante la fase di audit, oppure qualcosa sta tentando attivamente di provocare un'autenticazione in uscita e viene fermato.
• Gli Event ID 8001 durante la fase di audit sono la vostra mappa delle dipendenze. Ogni coppia origine/destinazione che elencano è qualcosa da risolvere — correggetela, esentatela o migratela a Kerberos — prima di passare a Deny all.

La copertura di rilevamento correlata — le difese contro il relay LDAP e SMB, che contano indipendentemente dal fatto che il NTLM in uscita sia bloccato o meno — è trattata in Il binding di canale LDAP sui controller di dominio e La firma SMB e il relay NTLM.

Remediation

1. Confermate prima il perimetro del Tier 0. R73 funziona solo se la vostra OU Tier 0 contiene effettivamente ogni controller di dominio e ogni server sensibile del Tier 0 — verificatelo a fronte del vostro modello di amministrazione a tier prima di collegare qualsiasi GPO.
2. Distribuite Audit all su una GPO collegata alla OU del Tier 0. Lasciatela attiva abbastanza a lungo da coprire il ciclo delle patch, i lavori di backup e qualsiasi attività amministrativa mensile o trimestrale — le finestre di audit troppo brevi mancano le dipendenze ricorrenti.
3. Esaminate le voci di Event ID 8001 e risolvete ognuna di quelle legittime: portate l'origine su Kerberos (di solito una correzione DNS/SPN), aggiungetela all'elenco delle eccezioni dei server NTLM se davvero non può abbandonare NTLM, oppure ritirate la dipendenza.
4. Portate la stessa GPO su Deny all. Sorvegliate l'Event ID 4001 nei giorni successivi — qualsiasi elemento inatteso è o una dipendenza tralasciata o un tentativo di coercizione attivo.
5. Estendete a R74+ una volta che il Tier 0 è pulito: collegate una GPO equivalente alla radice del dominio per il resto dell'ambiente, con eccezioni filtrate tramite WMI là dove NTLM non può ancora essere davvero eliminato.
6. Aggiungete R82/R83 per gli amministratori Tier 0 che devono connettersi verso il basso — limitate il metodo di connessione remota ed esigete un account del tier di destinazione, come da sezione precedente, così che questo controllo e il blocco a livello di rete coprano entrambe le direzioni del rischio.
7. Combinate con l'irrobustimento sul lato relay. Il blocco del NTLM in uscita rimuove la sorgente delle autenticazioni ritrasmesse dal Tier 0, ma qualsiasi sistema del SI che accetti ancora bersagli di relay NTLM non firmati o non protetti (LDAP senza binding di canale, SMB senza firma, registrazione web AD CS senza protezione estesa) resta sfruttabile contro vittime al di fuori del Tier 0. Trattate questa GPO come uno strato, non come l'intera difesa.

Come EtcSec rileva questo problema

L'audit di Active Directory di EtcSec cerca esattamente questa lacuna di configurazione. ANSSI_R73_NTLM_OUTBOUND_TIER0 segnala l'assenza di qualsiasi parametro di GPO che imposti RestrictSendingNTLMTraffic su Deny all sull'insieme dei sistemi del Tier 0 — la sola modalità audit è correttamente considerata come non conforme al controllo. ANSSI_R74_NTLM_OUTBOUND_DOMAIN traccia separatamente se quello stesso criterio di blocco sia stato esteso a una GPO collegata alla radice del dominio. ANSSI_R82_R83_ADMIN_ARCHITECTURE segnala i sistemi del Tier 0 privi delle salvaguardie di architettura amministrativa richieste da R82 e R83, e NTLM_RELAY_OPPORTUNITY segnala l'esposizione al relay più ampia nell'ambiente ogni volta che NTLM resta raggiungibile senza le protezioni compensative descritte sopra.