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. È 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 in Active Directory: che cosa significa

In pratica, il fallback Kerberos RC4 non è un'unica impostazione. È il risultato della scelta del KDC di usare RC4 per un ticket o una chiave di sessione perché AES non è disponibile, non è annunciato, non è ancora stato generato per l'account oppure è escluso dalla configurazione effettiva.

Microsoft ora lo dichiara apertamente. Nella sua guidance Kerberos attuale, Microsoft afferma che RC4 è in fase di dismissione, che gli aggiornamenti Windows rilasciati l'8 novembre 2022 o successivamente 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 rimane ancora in uso per gli account che non supportano AES-SHA1. Per questo motivo, l'argomento appartiene sia a un audit AD orientato all'evidenza sia a un piano di hardening AD orientato alle priorità.

Perché RC4 appare ancora negli ambienti AD moderni

L'errore più comune è presumere che vedere RC4 in un ticket significhi sempre una singola GPO sbagliata. La documentazione attuale di Microsoft indica diverse cause radice differenti, e non si rimediano tutte allo stesso modo.

Qui contano due aspetti evidenziati da Microsoft.

Primo, le modifiche Kerberos dell'8 novembre 2022 non hanno eliminato RC4 ovunque. Microsoft Support afferma che questi aggiornamenti hanno impostato AES come tipo di cifratura predefinito per le chiavi di sessione sugli account che non erano già contrassegnati con un tipo di cifratura predefinito, mentre Microsoft Learn afferma che RC4 compare ancora per gli account che non supportano AES-SHA1.

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

Come rilevare il fallback Kerberos RC4

Nella maggior parte degli ambienti, il rilevamento inizia sui controller di dominio, non sull'host del servizio che alla fine riceve il ticket. Microsoft Learn afferma che i dettagli sull'uso di RC4 in Kerberos vengono registrati nei log di sicurezza dei KDC per Windows Server 2019 e versioni successive, e che anche Windows Server 2016 ha ottenuto visibilità sull'uso di RC4 in questi eventi dopo l'aggiornamento cumulativo di gennaio 2025.

Partire da queste fonti di dati:

Se si centralizzano già i dati di telemetria dei DC, questo va collocato accanto agli eventi Kerberos trattati in Monitoraggio della sicurezza di Active Directory: gli Event ID che contano, non in un report ad hoc separato.

Cosa dice davvero l'Event ID 4769

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

Due dettagli contano immediatamente:

1. Microsoft documenta Ticket Encryption Type = 0x17 come RC4-HMAC, e 0x18 come RC4-HMAC-EXP.
2. Microsoft afferma inoltre che, a partire da Windows Vista e Windows Server 2008, i valori di cifratura attesi per il ticket di servizio sono 0x11 e 0x12, che sono algoritmi della famiglia AES.

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

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

Quando si indaga sul 4769, va usato insieme al contesto dell'account circostante:

• Se Ticket Encryption Type è della famiglia RC4 e l'account di servizio non ha chiavi AES, il problema reale è spesso lo storico delle password.
• Se il client o il target non annuncia AES, di solito è coinvolta la compatibilità di policy o piattaforma.
• Se i campi dell'evento suggeriscono che un account supporta solo il comportamento predefinito, verificare se l'account ha effettivamente un valore msDS-SupportedEncryptionTypes grezzo in AD oppure se il KDC sta ricadendo sul valore predefinito del dominio.

Cause radice comuni dietro l'emissione di ticket RC4

Account obsoleti senza chiavi AES rigenerate

Microsoft Learn afferma 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 l'introduzione del supporto, l'account può risultare privo delle chiavi AES-SHA1, e che modificare la password dell'account genera le chiavi mancanti.

Un'avvertenza sulle date, perché le pagine Microsoft sono in disaccordo tra loro. La pagina di remediation RC4 afferma che il supporto AES-SHA1 in Windows Kerberos "è stato aggiunto in Windows Server 2003", eppure la stessa pagina definisce anche Windows Server 2003 come l'ultima versione di Windows che non supportava AES-SHA1. Gli altri riferimenti Microsoft sono coerenti con la seconda lettura: la documentazione sulla policy Kerberos elenca AES128_HMAC_SHA1 e AES256_HMAC_SHA1 come "Non supportati in Windows 2000 Server, Windows XP o Windows Server 2003", e la documentazione dell'Event ID 4769 elenca 0x11 e 0x12 come "Supportati a partire da Windows Server 2008 e Windows Vista". Considerare Windows Vista e Windows Server 2008 come il punto in cui AES-SHA1 è diventato disponibile, e Windows Server 2003 come l'ultima piattaforma Windows priva di questo supporto.

Questo è il motivo per cui la pulizia di RC4 è in parte un problema di ciclo di vita delle password e non solo un problema di policy di protocollo. Spiega anche perché il problema spesso si sovrappone ai problemi di igiene degli account di servizio descritti in Sicurezza delle password in Active Directory: gli errori che contano.

msDS-SupportedEncryptionTypes assente, incompleto o interpretato male

Microsoft Support afferma che se un account non ha msDS-SupportedEncryptionTypes impostato, oppure è impostato a 0, i controller di dominio presumono un valore predefinito di 0x27 oppure usano l'impostazione del registro DefaultDomainSupportedEncTypes. Microsoft Learn afferma inoltre che il KDC usa il valore predefinito del dominio quando la macchina di origine o di destinazione non ha un valore definito.

Questo significa che RC4 può comparire anche senza che un amministratore abbia mai spuntato esplicitamente una casella RC4 sull'account stesso.

Usare i comandi ufficiali Microsoft per ispezionare cosa è effettivamente 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 non lo è.

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 "potrebbe influire sulla compatibilità con computer client o servizi e applicazioni". Separatamente — e questo proviene dalla guidance Microsoft di rilevamento e remediation di RC4, non dalla pagina della policy — Microsoft afferma che l'ultima versione di Windows che non supportava AES-SHA1 era Windows Server 2003, e invita a migrare verso una versione di Windows che supporti AES-SHA1.

È qui che il fallback RC4 diventa un problema di ingegneria invece che una casella da spuntare. Se si disabilita RC4 prima di aver capito quali client e servizi ne hanno ancora bisogno, si scambia un problema di sicurezza con un'interruzione dell'autenticazione.

Casi limite con integrazione Linux

Microsoft ora documenta uno scenario specifico con integrazione Linux in cui AD DS emette ancora ticket cifrati con RC4. In questo caso, l'Event ID 4769 mostra Ticket Encryption Type: 0x17, e Microsoft afferma che forzare msDS-SupportedEncryptionTypes a 24 (0x18) oppure attivare o disattivare la GPO del tipo di cifratura Kerberos non risolve il problema.

La ragione documentata è più circoscritta di "Linux causa RC4". Microsoft afferma che il problema si verifica perché l'attributo operatingSystemVersion viene interpretato in un modo che fa sì che il KDC tratti l'account come se i tipi di cifratura supportati non fossero popolati, inducendo il KDC a usare tipi di cifratura supportati presunti.

Le correzioni documentate da Microsoft sono altrettanto circoscritte: rimuovere l'attributo operatingSystemVersion, impostarne il valore in modo che il primo carattere non sia una cifra, oppure passare a una versione di sistema conforme alla specifica.

Questo è un caso limite che vale la pena conoscere perché dimostra che alcuni riscontri su RC4 sono causati dalla semantica dei metadati della directory, non solo da un evidente scostamento della policy.

Come rimediare alle dipendenze RC4 in modo sicuro

L'ordine di remediation più sicuro è progressivo.

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

Non iniziare disabilitando RC4 a livello di dominio. Iniziare dimostrando dove RC4 viene ancora emesso nel 4769 e a quale account o servizio corrisponde ciascun evento. Sui controller di dominio aggiornati con gli aggiornamenti Windows del 13 gennaio 2026 o successivi, monitorare anche gli eventi di audit Kdcsvc introdotti per il percorso di hardening dei ticket di servizio RC4.

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

Se un vecchio account utente o servizio è privo di chiavi AES, Microsoft afferma che modificare la password dell'account le genera. Questo dovrebbe avvenire prima di apportare modifiche più ampie lato KDC. Per gli account di servizio con SPN, questo è anche il punto in cui il rischio si sovrappone al Kerberoasting: i ticket basati su RC4 sono più facili da trasformare in lavoro di cracking offline quando sono presenti anche password deboli o riutilizzate.

3. Separare la configurazione AD grezza dal comportamento effettivo del KDC

Verificare l'attributo grezzo msDS-SupportedEncryptionTypes, poi confrontarlo con ciò che mostra l'evento. Se l'attributo è vuoto o 0, il KDC potrebbe usare DefaultDomainSupportedEncTypes al suo posto. Se un account macchina imposta il valore automaticamente in base alla policy locale, correggere la policy del dispositivo. Se un account utente o servizio necessita di un valore esplicito, modificare quell'account in modo deliberato invece di modificare per primo l'intero valore predefinito del dominio.

4. Rimuovere le dipendenze legacy prima di irrigidire la policy Kerberos

Se il client, il servizio, l'appliance o lo stack non Windows non supporta effettivamente AES, la guidance ufficiale Microsoft è di migrarlo o sostituirlo ove possibile. Questo è anche il motivo per cui la documentazione della GPO Kerberos continua ad avvertire sull'impatto sulla compatibilità. La pulizia di RC4 dovrebbe rimuovere prima le dipendenze legacy, non fingere che non esistano.

5. Usare Protected Users solo dove è davvero appropriato

Microsoft documenta che Protected Users limita i membri all'uso di AES per Kerberos, impedisce la creazione di chiavi DES o RC4 e previene DES o RC4 nella preautenticazione Kerberos. Questo rende il gruppo utile per account umani selezionati che possono già operare correttamente su AES.

Non è una leva di remediation RC4 universale. Microsoft avverte esplicitamente di non aggiungere mai a Protected Users account per servizi e computer. In altre parole, Protected Users è un controllo mirato per gli account utente giusti, non un sostituto della correzione della configurazione degli account di servizio, dei dispositivi o del KDC — lo stesso problema di ambito trattato in Account privilegiati in Active Directory: Protected Users, delega e lacune negli account di servizio.

6. Tenere conto delle modifiche predefinite RC4 del 2026, già rilasciate

La guidance Microsoft sui ticket di servizio RC4 aggiunge una seconda timeline rilevante dal punto di vista operativo. Tutte e tre le sue fasi sono ormai passate, quindi non si tratta più di un lavoro preparatorio: è lo stato che occorre presumere sui controller di dominio aggiornati:

• 13 gennaio 2026: è stata rilasciata la fase iniziale di deployment, che avvisa dell'enforcement in arrivo e aggiunge eventi di audit per il comportamento predefinito RC4 a rischio.
• 14 aprile 2026: la fase di enforcement ha cambiato il valore predefinito di DefaultDomainSupportedEncTypes per le operazioni del KDC a 0x18, ovvero solo AES-SHA1, per gli account privi di un valore msDS-SupportedEncryptionTypes esplicito. In questa fase l'enforcement poteva ancora essere ripristinato manualmente.
• Luglio 2026: gli aggiornamenti Windows rilasciati a partire da luglio 2026 hanno rimosso il supporto per la sottochiave di registro RC4DefaultDisablementPhase, quindi il controllo di rollback manuale non esiste più e l'enforcement è la modalità permanente.

Se oggi si ha ancora bisogno di RC4, Microsoft indica di configurarlo esplicitamente nell'attributo msDS-SupportedEncryptionTypes dell'account di servizio invece di affidarsi al vecchio comportamento predefinito, perché il valore predefinito del dominio non lo fornisce più.

Convalida dopo il passaggio ad AES

Il lavoro è concluso quando cambiano le evidenze, non quando la GPO appare più pulita.

Convalidare la modifica in quest'ordine:

1. Confermare che le nuove voci dell'Event ID 4769 per i servizi corretti non mostrino più valori di ticket della famiglia RC4.
2. Confermare che compaiano invece i valori di ticket attesi della famiglia AES, tipicamente 0x11 o 0x12.
3. Confermare che l'account abbia ora chiavi AES, se la correzione prevista era un reset della password.
4. Confermare che l'autenticazione del servizio continui a funzionare dopo reset delle password, riavvii del servizio o modifiche alle impostazioni dell'account.
5. Sui controller di dominio aggiornati per il percorso di hardening 2026, confermare che non vi siano avvisi o errori Kdcsvc 201-209 rilevanti per i percorsi corretti.
6. Testare esplicitamente l'interoperabilità non Windows. Microsoft afferma che l'assenza di eventi di audit non garantisce che tutti i dispositivi non Windows accetteranno con successo l'autenticazione Kerberos dopo l'aggiornamento di aprile 2026.

Se si vuole monitorare questo aspetto nel tempo invece di trattarlo come una pulizia una tantum, integrarlo in un workflow di audit ricorrente e mantenerlo nella stessa famiglia di controlli delle più ampie configurazioni di sicurezza errate di Active Directory che alimentano la deriva delle identità.

Come EtcSec rileva il fallback Kerberos RC4

EtcSec rileva il fallback Kerberos RC4 correlando le evidenze che Microsoft ora espone a livello operativo:

• emissione di ticket della famiglia RC4 nella telemetria dei ticket di servizio Kerberos
• account che dipendono ancora da impostazioni di cifratura predefinite o esplicitamente compatibili con RC4
• principal privi di chiavi AES utilizzabili a causa dell'età dell'account o dello storico delle password
• percorsi di account di servizio in cui il fallback RC4 e l'esposizione a ticket craccabili si sovrappongono

Questo permette ai team di rimisurare dopo reset delle password, modifiche alle impostazioni dell'account, pulizia dei servizi legacy e hardening del KDC, invece di trattare RC4 come una voce di revisione una tantum.

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
• CVE-2026-20833 in the NVD
• 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