Fallback Kerberos RC4 Active Directory: come rilevarlo, perché continua a verificarsi e come rimuoverlo

Il fallback kerberos rc4 active directory descrive la situazione in cui un controller di dominio continua a emettere materiale Kerberos con RC4 perché il client, il servizio, le chiavi dell’account o la configurazione effettiva dei tipi di cifratura non permettono allo scambio di restare su AES. Questo continua a contare nel 2026 perché ticket di servizio basati su RC4 mantengono rilevante il lato di cracking offline di Kerberoasting, anche in domini che sulla carta sembrano già moderni.

Questo articolo non è una seconda guida su Kerberoasting. Non copre nemmeno l’angolo di Silver Ticket. È una guida di rilevamento e remediation per dimostrare dove RC4 viene ancora usato, perché il KDC continua a sceglierlo e come rimuovere questa dipendenza senza rompere l’autenticazione.

Fallback Kerberos RC4 Active Directory: che cosa significa

In pratica, il fallback Kerberos RC4 non è una singola impostazione. È il risultato del fatto che il KDC sceglie RC4 per un ticket o una chiave di sessione perché AES non è disponibile, non viene annunciato, non è ancora stato generato per l’account oppure è escluso dalla configurazione effettiva.

Microsoft ora lo dice chiaramente. Nella sua guidance Kerberos attuale, Microsoft afferma che RC4 è in fase di ritiro, che gli aggiornamenti Windows pubblicati l’8 novembre 2022 o dopo hanno cambiato il comportamento Kerberos predefinito per preferire AES-SHA1 per gli account in cui un tipo di cifratura non era stato impostato esplicitamente, e che RC4 continua ancora a comparire per gli account che non supportano AES-SHA1. Per questo il tema appartiene sia a un audit AD orientato all’evidenza sia a un piano di hardening AD orientato alle priorità.

Perché RC4 compare ancora in ambienti AD moderni

L’errore più comune è presumere che vedere RC4 in un ticket significhi sempre che esiste un solo GPO configurato male. La documentazione Microsoft attuale indica diverse cause radice, e non tutte si risolvono allo stesso modo.

Qui contano due punti Microsoft.

Primo, le modifiche Kerberos dell’8 novembre 2022 non hanno rimosso RC4 ovunque. Microsoft Support dice che quegli aggiornamenti hanno impostato AES come tipo di cifratura predefinito per le chiavi di sessione sugli account che non erano già marcati con un tipo di cifratura predefinito, mentre Microsoft Learn dice che RC4 continua a comparire per gli account che non supportano AES-SHA1.

Secondo, gli account computer e gli account utente o di servizio non si comportano allo stesso modo. Microsoft Support dice che i computer Windows impostano automaticamente msDS-SupportedEncryptionTypes per i propri account macchina in base alla policy Kerberos locale, ma che gli account utente, group Managed Service Accounts e altri account AD non ricevono automaticamente quel valore. Questa differenza è uno dei motivi principali per cui gli account di servizio continuano a emergere nelle indagini su RC4.

Come rilevare fallback Kerberos RC4

Nella maggior parte degli ambienti, il rilevamento inizia sui controller di dominio, non sull’host di servizio che alla fine riceve il ticket. Microsoft Learn dice che i dettagli sull’uso di Kerberos RC4 vengono registrati nei Security logs sui KDC in Windows Server 2019 e versioni successive, e che anche Windows Server 2016 ha ottenuto questa visibilità dopo la cumulative update di gennaio 2025.

Inizi con queste fonti di dati:

Se centralizza già la telemetria dei DC, questo deve stare accanto agli eventi Kerberos coperti in Monitoraggio Sicurezza AD: Event ID e SIEM, non in un report ad hoc separato.

Che cosa dice davvero Event ID 4769

Event ID 4769 è il punto più pratico per dimostrare fallback Kerberos RC4 perché Microsoft documenta sia il valore di cifratura del ticket sia i campi di contesto circostanti.

Due dettagli contano subito:

1. Microsoft documenta Ticket Encryption Type = 0x17 come RC4-HMAC, e 0x18 come RC4-HMAC-EXP.
2. Microsoft dice anche che, da Windows Vista e Windows Server 2008 in poi, i valori attesi di cifratura per i ticket di servizio sono 0x11 e 0x12, cioè algoritmi della famiglia AES.

Questo rende 4769 uno dei modi più puliti per dimostrare che RC4 viene ancora emesso.

Nota: non confonda Ticket Encryption Type = 0x17 in Event ID 4769 con msDS-SupportedEncryptionTypes = 0x18 o DefaultDomainSupportedEncTypes = 0x18. In Event 4769, 0x17 e 0x18 sono valori di ticket della famiglia RC4. Nel contesto del bitmask AD e KDC, 0x18 significa solo AES128 più AES256.

Questa distinzione conta perché è facile costruire la remediation sbagliata se si mescolano i valori degli eventi con i bitmask di AD.

Quando indaga 4769, lo usi insieme al contesto dell’account:

• Se Ticket Encryption Type appartiene alla famiglia RC4 e l’account di servizio non ha chiavi AES, la cronologia delle password è spesso la causa reale.
• Se il client o il target non annunciano AES, di solito è coinvolta la compatibilità di policy o di piattaforma.
• Se i campi dell’evento suggeriscono che un account supporta solo il comportamento predefinito, verifichi se quell’account ha realmente un valore msDS-SupportedEncryptionTypes grezzo in AD oppure se il KDC sta ripiegando sul valore predefinito del dominio.

Cause radice comuni dietro l’emissione di ticket RC4

Vecchi account senza chiavi AES rigenerate

Microsoft Learn dice che, se un account utente è stato creato prima che il supporto AES-SHA1 fosse aggiunto a Windows Kerberos e la password non è mai stata reimpostata dopo quel momento, all’account possono mancare chiavi AES-SHA1. Microsoft collega questo all’introduzione storica del supporto AES in Windows Server 2003 e dice esplicitamente che cambiare la password dell’account genera le chiavi mancanti.

Ecco perché la pulizia di RC4 è in parte un problema di ciclo di vita delle password e non solo un problema di policy di protocollo. Questo spiega anche perché il tema spesso si sovrappone ai problemi di igiene degli account di servizio descritti in Active Directory Password Security: Misconfigurations That Matter.

msDS-SupportedEncryptionTypes è assente, incompleto o interpretato male

Microsoft Support dice che, se un account non ha msDS-SupportedEncryptionTypes impostato, oppure è impostato a 0, i controller di dominio assumono un valore predefinito di 0x27 oppure usano il valore di registro DefaultDomainSupportedEncTypes. Microsoft Learn dice anche che il KDC usa il valore predefinito del dominio quando la macchina sorgente o di destinazione non ha un valore definito.

Questo significa che RC4 può ancora comparire senza che un amministratore abbia mai selezionato esplicitamente una casella RC4 sull’account stesso.

Usi i comandi di Microsoft per ispezionare che cosa è davvero configurato.

Get-ADObject -Filter "msDS-supportedEncryptionTypes -bor 0x7 -and -not msDS-supportedEncryptionTypes -bor 0x18"

Questa query proviene da Microsoft Support ed è pensata specificamente per trovare account in cui DES o RC4 sono abilitati esplicitamente ma AES no.

Per la revisione di un singolo oggetto, Microsoft Learn mostra questo schema:

$accountName = "<computer account name>"
$parameters = @{
     Filter     = "Name -eq '$($accountName)' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')"
     Properties = "msDS-SupportedEncryptionTypes"
}
Get-ADObject @parameters | FL "DistinguishedName","msDS-SupportedEncryptionTypes","Name","ObjectClass"

Dispositivi e servizi legacy che ancora non supportano AES

La documentazione Microsoft sulla policy Kerberos continua ad avvertire che l’impostazione Network security: Configure encryption types allowed for Kerberos può influire sulla compatibilità con computer client, servizi e applicazioni. La stessa guidance Microsoft Learn dice che l’ultima piattaforma Windows a non supportare AES-SHA1 è stata Windows Server 2003 e raccomanda la migrazione dei dispositivi che dipendono ancora da quel comportamento più vecchio.

È qui che fallback RC4 diventa un problema di engineering e non una semplice casella. Se disabilita RC4 prima di aver capito quali client e servizi ne hanno ancora bisogno, scambia un problema di sicurezza con un’interruzione di autenticazione.

Casi limite di integrazione Linux

Microsoft documenta ora uno scenario specifico di integrazione Linux in cui AD DS continua a emettere ticket cifrati con RC4. In quel caso, Event ID 4769 mostra Ticket Encryption Type: 0x17, e Microsoft dice che forzare msDS-SupportedEncryptionTypes a 24 (0x18) o modificare il GPO dei tipi di cifratura Kerberos non risolve il problema.

La ragione documentata è più stretta di dire “Linux causa RC4”. Microsoft dice che il problema si verifica perché l’attributo operatingSystemVersion viene interpretato in un modo che porta il KDC a trattare l’account come se i tipi di cifratura supportati non fossero popolati, spingendo quindi il KDC a usare invece tipi di cifratura assunti come supportati.

Questo è un caso limite utile perché dimostra che alcuni rilievi RC4 sono causati dalla semantica dei metadati di directory, non solo da una deriva evidente di policy.

Come rimediare alle dipendenze RC4 in modo sicuro

L’ordine di remediation più sicuro è progressivo.

Actionable next steps

Inizi confermando l’emissione RC4, raggruppando gli account coinvolti e trattando questa pulizia nello stesso flusso di un piano di hardening AD orientato alle priorità prima di qualsiasi irrigidimento globale.

1. Dimostrare dove RC4 viene emesso prima di cambiare i valori predefiniti

Non inizi disabilitando RC4 a livello di dominio. Inizi dimostrando dove RC4 viene ancora emesso in 4769 e a quale account o servizio corrisponde ogni evento. Se ha aggiornato i controller di dominio con gli aggiornamenti Windows del 13 gennaio 2026 o successivi, monitori anche gli eventi di audit Kdcsvc introdotti per il percorso di hardening dei ticket di servizio RC4.

2. Rigenerare le chiavi AES mancanti quando questa è la causa reale

Se un vecchio account utente o di servizio non ha chiavi AES, Microsoft dice che cambiare la password dell’account le genera. Questo deve avvenire prima di introdurre cambiamenti più ampi lato KDC. Per gli account di servizio con SPN, questo è anche il punto in cui il rischio si sovrappone a Kerberoasting: ticket basati su RC4 sono più facili da trasformare in cracking offline quando esistono anche password deboli o riutilizzate.

3. Separare configurazione AD grezza e comportamento effettivo del KDC

Controlli l’attributo msDS-SupportedEncryptionTypes grezzo e poi lo confronti con ciò che mostra l’evento. Se l’attributo è vuoto o vale 0, il KDC potrebbe usare DefaultDomainSupportedEncTypes al suo posto. Se un account macchina imposta il valore automaticamente dalla policy locale, corregga la policy del dispositivo. Se un account utente o di servizio ha bisogno di un valore esplicito, modifichi deliberatamente quell’account invece di cambiare prima il valore predefinito dell’intero dominio.

4. Rimuovere dipendenze legacy prima di irrigidire la policy Kerberos

Se il client, il servizio, l’appliance o lo stack non Windows non supportano davvero AES, la stessa guidance Microsoft è migrare o sostituire quando possibile. È anche per questo che la documentazione del GPO Kerberos continua ad avvertire sull’impatto di compatibilità. La pulizia di RC4 deve prima rimuovere le dipendenze legacy, non far finta che non esistano.

5. Usare Protected Users solo dove si adatta davvero

Microsoft documenta che Protected Users limita i suoi membri ad AES per Kerberos, smette di creare chiavi DES o RC4 e impedisce DES o RC4 nella preauthentication Kerberos. Questo rende il gruppo utile per account umani selezionati che possono già operare in modo pulito con AES.

Non è una leva universale di remediation RC4. Microsoft avverte esplicitamente di non aggiungere account di servizio o account computer a Protected Users. In altre parole, Protected Users è un controllo mirato per gli account utente giusti, non un sostituto della correzione di account di servizio, dispositivi o configurazione KDC.

6. Prepararsi ai cambiamenti predefiniti RC4 del 2026 con date esplicite

La guidance Microsoft sui ticket di servizio RC4 aggiunge una seconda timeline che conta operativamente:

• January 13, 2026: inizia la fase di rollout iniziale e vengono aggiunti eventi di audit per il comportamento RC4 predefinito a rischio.
• April 14, 2026: la fase di enforcement cambia il valore predefinito DefaultDomainSupportedEncTypes per le operazioni KDC in 0x18, cioè solo AES-SHA1, per gli account che non hanno un valore esplicito di msDS-SupportedEncryptionTypes.
• July 2026: Microsoft dice che il controllo temporaneo di rollback per questo comportamento viene rimosso e l’enforcement diventa il modo permanente.

Questa è la timeline Microsoft attuale. Se ha ancora bisogno di RC4 dopo il 14 aprile 2026, Microsoft dice che va abilitato esplicitamente nel bitmask msDS-SupportedEncryptionTypes dell’account di servizio invece di dipendere dal vecchio comportamento predefinito.

Validazione dopo il passaggio ad AES

Ha finito quando cambia l’evidenza, non quando il GPO sembra più pulito.

Valida il cambiamento in quest’ordine:

1. Confermare che i nuovi Event ID 4769 per i servizi remediation non mostrino più valori ticket della famiglia RC4.
2. Confermare che al loro posto compaiano i valori attesi della famiglia AES, tipicamente 0x11 o 0x12.
3. Confermare che l’account ora abbia chiavi AES se il reset della password era la correzione prevista.
4. Confermare che l’autenticazione del servizio continui a funzionare dopo reset della password, riavvio del servizio o modifica delle impostazioni dell’account.
5. Sui controller di dominio aggiornati per il percorso di hardening 2026, confermare che non esistano più avvisi o errori Kdcsvc 201-209 rilevanti per i percorsi remediation.
6. Testare esplicitamente l’interoperabilità non Windows. Microsoft dice che l’assenza di eventi di audit non garantisce che ogni dispositivo non Windows continui a funzionare dopo l’aggiornamento di enforcement del 14 aprile 2026.

Se vuole seguire questo nel tempo invece di trattarlo come una bonifica una tantum, lo integri in un workflow di audit ricorrente e lo mantenga nella stessa famiglia di controlli delle configurazioni di sicurezza errate di Active Directory più comuni che alimentano la deriva di identità.

Come EtcSec rileva fallback Kerberos RC4

EtcSec rileva fallback Kerberos RC4 correlando l’evidenza che Microsoft ora espone operativamente:

• emissione di ticket di servizio Kerberos della famiglia RC4
• account che dipendono ancora da impostazioni di cifratura predefinite o esplicite compatibili con RC4
• principal che non dispongono di chiavi AES utilizzabili dopo deriva dovuta all’età dell’account o alla cronologia delle password
• percorsi di account di servizio in cui fallback RC4 ed esposizione a ticket crackable si sovrappongono

Questo permette ai team di rimisurare dopo reset di password, cambi di impostazioni account, pulizia di servizi legacy e hardening KDC invece di trattare RC4 come un tema da verificare una sola volta.

Riferimenti primari

• Detect and remediate RC4 usage in Kerberos
• Event 4769: A Kerberos service ticket was requested
• KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966
• How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833
• Protected Users security group
• Preventing Kerberos change password that uses RC4 secret keys
• Linux accounts can't get AES-encrypted tickets in AD DS
• Network security: Configure encryption types allowed for Kerberos