Kerberos Armoring (FAST): Active Directory Flexible Authentication Secure Tunneling è disattivato di default

Kerberos Armoring, FAST, Active Directory Flexible Authentication Secure Tunneling

Kerberos armoring, FAST, Active Directory Flexible Authentication Secure Tunneling — Microsoft accumula tutti questi nomi su un'unica funzionalità, e in un dominio predefinito quella funzionalità è disattivata. Entrambe le impostazioni di Group Policy che la attivano arrivano impostate su Non configurata, quindi lo scambio di autenticazione che trasporta materiale derivato dalla password attraversa la rete senza alcun canale protetto attorno ad esso, anche se ogni versione supportata di Windows Server è in grado di applicare l'armoring a questo scambio fin da Windows Server 2012.

FAST è definito nella RFC 6113, A Generalized Framework for Kerberos Pre-Authentication. IANA registra il suo tipo di dati di pre-autenticazione PA-FX-FAST come padata type 136, insieme a PA-FX-COOKIE (133), PA-FX-ERROR (137) e PA-ENCRYPTED-CHALLENGE (138). La descrizione che Microsoft stessa dà dell'implementazione Windows è breve e precisa: «Flexible Authentication Secure Tunneling (FAST) fornisce un canale protetto tra il client Kerberos e il KDC. FAST è implementato come Kerberos armoring in Windows Server 2012, ed è disponibile solo per gli scambi authentication service (AS) e ticket-granting service (TGS).»

Microsoft elenca tre vantaggi per i sistemi joinati al dominio, e il primo è la ragione per cui esiste questo articolo:

• Protezione dagli attacchi a dizionario offline. «Il Kerberos armoring protegge i dati di pre-autenticazione dell'utente, che sono vulnerabili agli attacchi a dizionario offline quando vengono generati a partire da una password.»
• Errori Kerberos autenticati. L'armoring «protegge le autenticazioni Kerberos dell'utente dallo spoofing degli errori Kerberos del KDC, che può causare un downgrade a NTLM o a una crittografia più debole.»
• Compound authentication, l'estensione di identità del dispositivo usata da Dynamic Access Control.

Fonte: What's New in Kerberos Authentication, Microsoft Learn.

Come funziona il Kerberos armoring

FAST avvolge la richiesta reale all'interno di uno scambio esterno cifrato con una armor key. La RFC 6113 afferma chiaramente, nelle definizioni ASN.1 sia della richiesta armored sia della risposta armored, che «la chiave di cifratura è la armor key». Un osservatore sulla rete vede l'involucro armored, non i dati di pre-autenticazione al suo interno.

Quali scambi sono effettivamente protetti da armoring

La provenienza della armor key è il punto in cui molti si confondono. Microsoft: «Il Kerberos armoring utilizza un ticket-granting ticket (TGT) del dispositivo per proteggere gli scambi authentication service con il KDC, quindi lo scambio authentication service del computer non è protetto da armoring. Il TGT dell'utente viene utilizzato per proteggere i suoi scambi TGS con il KDC.»

Leggetelo due volte, perché definisce il confine del controllo:

L'autenticazione iniziale della macchina stessa non può essere protetta da armoring, perché la armor key è proprio ciò che sta cercando di ottenere. Ogni logon utente successivo su quella macchina può esserlo.

La RFC 6113 è esplicita sull'attacco che elimina: «Il padata di pre-autenticazione Kerberos FAST definito in questa sezione fornisce uno strumento per ridurre significativamente la vulnerabilità agli attacchi a dizionario offline. Se combinato con l'encrypted challenge, FAST richiede a un attaccante di condurre con successo un attacco man-in-the-middle per poter osservare il testo cifrato.»

Perché la pre-autenticazione non protetta è raccoglibile

Senza FAST, il flusso di pre-autenticazione standard di Windows è PA-ENC-TIMESTAMP — pre-authentication type 2, che Microsoft documenta come «un tipo normale per l'autenticazione standard basata su password». Il client dimostra di conoscere la password cifrando un timestamp con una chiave derivata da quella password, e il KDC restituisce un AS-REP la cui parte cifrata è protetta dalla stessa chiave derivata dalla password.

Entrambe le metà sono testo cifrato derivato dalla password, e la RFC 6113 ne descrive direttamente la conseguenza: «Un attaccante può richiedere un AS-REP e provare varie password per vedere se riesce a decifrare il ticket risultante.»

L'analisi del Kerberos armoring di Trimarc Security (pubblicata a luglio 2024) sottolinea lo stesso punto sul piano economico: «Il processo di tentare di crackare una password con uno di questi metodi è completamente offline, il che significa che un attaccante può impiegare tutto il tempo necessario.»

Ed è qui che i consigli di remediation abituali si fermano a metà strada. Le correzioni standard per l'AS-REP roasting e il Kerberoasting — password più lunghe, i group managed service account, la rimozione del fallback RC4 — rendono tutte il cracking più difficile. Nessuna di esse impedisce che il materiale venga raccolto. FAST attacca invece la fase di raccolta, collocando lo scambio all'interno di un canale che chi raccoglie i dati non può leggere.

Ciò che l'armoring modifica in modo strutturale è la posizione del collector non autenticato. Quando il KDC è configurato per rifiutare i messaggi Kerberos non protetti (unarmored), un AS-REQ prodotto da uno strumento privo del TGT del dispositivo non può essere armored, e viene quindi rifiutato prima che venga restituito qualsiasi AS-REP. Questo comportamento discende direttamente dall'opzione documentata «Fail unarmored authentication requests» descritta più avanti.

Le impostazioni di Group Policy disattivate di default

Tre impostazioni governano questo comportamento, distribuite su due nodi degli Administrative Templates. Tutte e tre sono Non configurate di default.

I percorsi di registro, i nomi descrittivi e le descrizioni citate provengono dai riferimenti Policy CSP ADMX_kdc e Kerberos.

Le quattro opzioni del KDC

L'impostazione KDC ha quattro opzioni, e le differenze non sono cosmetiche:

Due conseguenze meritano di essere scritte su un post-it prima che chiunque tocchi la OU Domain Controllers:

🚨 Pericolo: l'avviso che Microsoft stessa riporta sulla policy KDC — «Quando è impostata l'opzione "Fail unarmored authentication requests", i computer client che non supportano il Kerberos armoring non riusciranno ad autenticarsi presso il domain controller.» Qualsiasi client Kerberos incapace di fare armoring — appliance, host non Windows, sistemi embedded, tutto ciò che è precedente a Windows 8 / Windows Server 2012 — smette di autenticarsi. Fate l'inventario prima di applicare l'enforcement, non dopo.

La seconda: le due opzioni rigide non fanno silenziosamente nulla al di sotto del domain functional level Windows Server 2012. Microsoft afferma che entrambe le opzioni «causano guasti intermittenti di autenticazione o di controllo degli accessi se nel dominio sono presenti domain controller che non eseguono Windows Server 2012. Pertanto nessuna di queste due opzioni avrà effetto finché il dominio non è impostato al functional level Windows Server 2012. Fino ad allora, i domain controller che eseguono Windows Server 2012 si comporteranno come se fosse configurata l'opzione Supported.» Un dominio ancora fermo al functional level 2008 R2 può configurare «Fail unarmored» e ottenere invece il comportamento di Supported: armoring offerto ai client che lo richiedono, senza alcun enforcement.

Rilevamento

Lo stato dell'armoring è misurabile da tre angolazioni indipendenti: la configurazione, la telemetria di autenticazione in tempo reale e gli eventi di stato del KDC.

Indicatori che rivelano lo stato dell'armoring

La tabella dei pre-authentication type e le indicazioni di monitoraggio provengono dal riferimento Microsoft per 4768(S, F) A Kerberos authentication ticket (TGT) was requested, che raccomanda di generare un alert quando il «Value non è 138 mentre il Kerberos Armoring è abilitato per tutte le comunicazioni Kerberos nell'organizzazione». Gli eventi 33 e 34 e i performance counter di FAST sono documentati in What's New in Kerberos Authentication.

Verificare se le policy sono configurate

Cominciate dallo stato della configurazione. Eseguite su un domain controller:

# Le opzioni di enforcement richiedono il domain functional level Windows Server 2012 o superiore
Get-ADDomain | Select-Object DNSRoot, DomainMode

# Lato KDC: se non viene restituito nulla, la policy è Not Configured
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\KDC\Parameters' `
                 -Name EnableCbacAndArmor -ErrorAction SilentlyContinue

Poi il lato client, su una workstation o un member server:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters' `
                 -Name EnableCbacAndArmor, RequireFast -ErrorAction SilentlyContinue

Misurare quanti logon sono effettivamente protetti da armoring

La configurazione racconta solo l'intento. Per misurare cosa accade realmente, raggruppate le richieste TGT live per pre-authentication type su un domain controller:

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4768 } -MaxEvents 5000 |
    ForEach-Object {
        $x = [xml]$_.ToXml()
        [pscustomobject]@{
            PreAuthType = ($x.Event.EventData.Data |
                Where-Object { $_.GetAttribute('Name') -eq 'PreAuthType' }).'#text'
        }
    } |
    Group-Object PreAuthType |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

Selezionare il campo tramite il suo attributo Name piuttosto che tramite l'indice posizionale è importante: Microsoft ha rilasciato una versione aggiornata dell'Event 4768 con campi aggiuntivi nel cumulative update di gennaio 2025 per Windows Server 2016 e versioni successive, quindi le posizioni dei campi differiscono tra le versioni dell'evento.

Per estrarre direttamente solo le richieste non protette (unarmored):

Get-WinEvent -LogName Security -MaxEvents 50 -FilterXPath @"
*[System[EventID=4768] and EventData[Data[@Name='PreAuthType'] != '138']]
"@

Instradate lo stesso flusso di eventi 4768 verso qualunque strumento già utilizziate per il monitoraggio degli eventi di Active Directory. Il rapporto tra il type 138 e tutto il resto è l'unico numero che vi dice quanto sia effettivamente progredito un rollout.

Remediation

Il rollout graduale

Effettuate il rollout in questo ordine. Le indicazioni di Trimarc sono inequivocabili riguardo alla sequenza: «Assicuratevi che il Kerberos Armoring sia abilitato prima sui client… Questa modifica deve essere applicata a tutti i client prima di essere configurata sui Domain Controller.»

1. Verificate il domain functional level. Get-ADDomain | Select-Object DomainMode deve riportare Windows Server 2012 o superiore prima che le opzioni di enforcement facciano alcunché. Se siete ancora al di sotto, questo diventa prima di tutto un progetto di aggiornamento del functional level.

2. Abilitate la policy client su tutti i client. Computer Configuration > Policies > Administrative Templates > System > Kerberos > Kerberos client support for claims, compound authentication and Kerberos armoring → Enabled. Collegatela alle OU delle workstation e dei member server, non solo a un gruppo pilota. Verificate che la policy sia stata effettivamente applicata — una GPO malformata o con uno scoping errato è la ragione più comune per cui un rollout si blocca silenziosamente:

gpupdate /force
gpresult /h C:\Temp\kerberos-armoring.html

3. Impostate la policy KDC su Supported sulla OU Domain Controllers. Computer Configuration > Policies > Administrative Templates > System > KDC > KDC support for claims, compound authentication and Kerberos armoring → Enabled, opzione Supported. Se in seguito un domain controller registra l'System event 33, la risoluzione documentata da Microsoft è eseguire gpupdate /force su un domain controller.

4. Misurate prima di applicare l'enforcement. Osservate i performance counter KDC AS Requests with FAST e KDC armored TGS Requests e la distribuzione dei pre-authentication type nell'Event 4768. Ogni principal che mostra ancora il type 2 è un client che si romperà sotto l'enforcement.

5. Fate l'inventario dei client incapaci di armoring. Il supporto all'armoring inizia con i client Windows 8 e Windows Server 2012. Appliance, host Linux e UNIX, dispositivi di rete e stack Kerberos legacy richiedono ciascuno una decisione esplicita: aggiornare, esentare tramite lo scoping delle OU, oppure accettare che l'enforcement li escluda.

6. Solo a quel punto applicate l'enforcement. Sul lato KDC, passate a Fail unarmored authentication requests. Sul lato client, abilitate Fail authentication requests when Kerberos armoring is not available. Fatelo un passo alla volta, con un piano di rollback, e mai entrambi nella stessa finestra di change.

Capacità e costo prima di applicare l'enforcement

Distribuite un numero sufficiente di domain controller capaci di armoring per sostenere il carico prima di applicare l'enforcement. Il riferimento ADMX_kdc avvisa che un «numero insufficiente di domain controller che supportano questa policy causa guasti di autenticazione ogni volta che sono richiesti Dynamic Access Control o Kerberos armoring.»

Infine, mettete a budget il costo. Microsoft è chiara, nello stesso riferimento, sul fatto che «il Kerberos armoring cifra completamente i messaggi Kerberos e firma gli errori Kerberos, il che comporta un aumento del tempo di elaborazione, ma non modifica la dimensione del service ticket.» Il problema qui non è la crescita dei ticket; è la CPU dei DC.

Come EtcSec rileva questo problema

Il catalogo delle vulnerabilità di EtcSec registra questo controllo come due check separati, perché la metà client e la metà KDC falliscono in modo indipendente e un dominio può facilmente avere l'una senza l'altra:

• KERBEROS_ARMORING_DC_DISABLED — Kerberos Armoring (FAST) Not Enforced on DCs
• KERBEROS_ARMORING_CLIENT_DISABLED — Kerberos Armoring (FAST) Not Required on Clients
• ANSSI_R27_KERBEROS_PREAUTH_NOT_FAST — la versione in chiave di compliance dello stesso controllo

Questi check sono correlati alle voci della superficie di attacco che effettivamente mitigano — ASREP_ROASTING_RISK, KERBEROASTING_RISK e KERBEROS_RC4_FALLBACK — cosicché un report mostra sia gli account esposti al cracking offline sia se il controllo a livello di protocollo che limita la raccolta dei dati è attivo. Questo abbinamento è il punto centrale: un audit che segnala account soggetti a roasting senza riportare lo stato dell'armoring descrive solo metà del problema. Se state conducendo una revisione più ampia, questo controllo si inserisce naturalmente nel resto di un audit di sicurezza di Active Directory.