La fine di Kerberos RC4: cosa significa la scadenza Microsoft di luglio 2026 per il SSO mobile

Lukas Schönbächler · Luglio 2026 · 7 minuti di lettura

A giugno abbiamo analizzato il piano di Microsoft per disattivare NTLM e le sue conseguenze per le flotte mobili. NTLM non è però l’unica autenticazione legacy che Microsoft sta smantellando nel 2026. L’altra, la cifratura RC4 all’interno di Kerberos stesso, ha appena raggiunto il punto di non ritorno: con l’aggiornamento cumulativo di luglio 2026 l’ultima via di fuga viene rimossa in modo definitivo. Ecco cosa è cambiato, perché conta per il Kerberoasting e dove può interrompere senza preavviso il single sign-on mobile.

Cosa è cambiato il 14 luglio 2026

Si tratta della fase finale di un percorso avviato da Microsoft a gennaio 2026 in risposta a CVE-2026-20833 e documentato in KB5073381:

• 13 gennaio 2026 (Fase 1): i domain controller iniziano a registrare eventi di audit (eventi Kdcsvc da 201 a 209 nel registro System) ogni volta che un ticket dipende da RC4. Viene introdotto il valore di registro RC4DefaultDisablementPhase sotto HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters, così gli amministratori possono attivare l’enforcement in anticipo.
• 14 aprile 2026 (Fase 2): la suite di cifratura predefinita del dominio passa a solo AES-SHA1 (0x18). Gli account senza tipi di cifratura impostati esplicitamente smettono di ricevere ticket RC4. Ciò che si rompeva poteva ancora essere riportato in modalità audit tramite il valore di registro.
• 14 luglio 2026 (Fase 3): il valore di rollback viene rimosso e non viene più letto. L’enforcement è permanente.

Il team di ingegneria AskDS di Microsoft lo ha detto senza giri di parole: «Con l’installazione degli aggiornamenti cumulativi Windows di luglio 2026 il comportamento sarà identico a quello di aprile 2026, ma non sarà più possibile tornare alla modalità di audit». RC4 ora funziona solo per gli account in cui è impostato esplicitamente in msDS-SupportedEncryptionTypes, un’eccezione per singolo account che Microsoft stessa sconsiglia.

Figura 1: la rimozione di RC4 in tre fasi. Dal 14 luglio 2026 non esiste più alcun ritorno a RC4 a livello di dominio.

Perché RC4 doveva morire: il Kerberoasting

L’attacco che ha condannato RC4 è il Kerberoasting. Qualsiasi utente di dominio autenticato, senza privilegi elevati, può richiedere un ticket di servizio Kerberos per qualunque account con un service principal name (SPN). Quel ticket è cifrato con la chiave dell’account di servizio e la richiesta non genera alcun allarme. L’attaccante porta il ticket offline e ne estrae la password a forza bruta.

È il cifrario a decidere se l’attacco è praticabile. Un ticket RC4-HMAC è cifrato con una chiave derivata direttamente dall’hash NT della password dell’account, che le comuni GPU attaccano a velocità enormi; le password moderatamente complesse cadono in poche ore. Le chiavi AES sono derivate tramite PBKDF2 con migliaia di iterazioni e un salt, il che rallenta lo stesso attacco di ordini di grandezza. Un account di servizio con solo materiale RC4 può essere craccato offline con tutta calma, e gli account di servizio hanno spesso accessi molto ampi.

C’è anche un aspetto di conformità: NIST SP 800-131A ha vietato RC4 già nel 2016, PCI-DSS 4.0 richiede piani di remediation documentati per i cifrari deboli e nel 2026 gli assicuratori cyber hanno iniziato a chiedere della configurazione crittografica di Kerberos nei questionari di rinnovo.

Due rimozioni, un unico copione

Se lo schema vi sembra familiare, è normale. La rimozione di RC4 segue lo stesso copione in tre atti della rimozione di NTLM: prima gli eventi di audit, poi il cambio dei valori predefiniti, infine l’eliminazione della via di fuga. RC4 ha solo percorso l’intero ciclo in sei mesi. Consideratela la prova generale di come sarà l’enforcement di NTLM.

	Rimozione NTLM	Rimozione RC4 da Kerberos
Fase di audit	Eventi 4020 / 4022 / 4032 (Win 11 24H2, Server 2025)	Eventi Kdcsvc da 201 a 209 (gennaio 2026)
Cambio del default	BlockNTLMv1SSO su Enforce, ottobre 2026 (KB5066470)	Default solo AES (0x18), 14 aprile 2026
Via di fuga	Riattivazione via Group Policy (fino alla prossima LTSC)	Chiave di registro RC4DefaultDisablementPhase
Punto di non ritorno	Prossima LTSC di Windows Server (prevista per il 2027)	14 luglio 2026: chiave rimossa
Vittime tipiche	Dispositivi mobili, client workgroup e legacy	Account di servizio, stampanti, appliance, app di terze parti
Rilevamento	Eventi 8003 / 4022 sui server applicativi	Evento 4769 con tipo di cifratura del ticket 0x17
Rimedio per i flussi mobili	Certificati PKINIT tramite il vostro MDM	Materiale AES sugli account dietro le vostre app

Cosa significa per il SSO Kerberos mobile

Un flusso Kerberos mobile ha due metà. Nella prima il dispositivo ottiene un ticket-granting ticket (TGT) per l’utente. Questa metà è a posto. Hypergate Authenticator negozia AES per impostazione predefinita, quindi per questa scadenza non serve alcun aggiornamento dell’app, nessuna modifica alla configurazione gestita e niente da preparare sul dispositivo. Unica eccezione: se in passato avete forzato cifrari legacy con una configurazione Kerberos personalizzata, rimuovete quell’override durante questa pulizia. Poi, per ogni applicazione interna aperta dall’utente, il dispositivo richiede un ticket di servizio per lo SPN di quell’app, e quel ticket è cifrato con la chiave dell’account di servizio.

È nella seconda metà che il 14 luglio colpisce. Se l’account dietro la vostra intranet, il vostro SharePoint on-premises o un’API line-of-business dispone solo di materiale RC4, il KDC non può più emettere un ticket per quell’account. L’app restituisce 401 in loop. L’esperienza utente è identica a un blocco NTLM, ed è proprio per questo che la diagnosi è facile da sbagliare: i team che hanno appena migrato il mobile da NTLM a Kerberos sospetteranno della migrazione, quando il vero colpevole è un account AD la cui password è stata impostata l’ultima volta nel 2009.

Una distinzione restringe parecchio il campo di ricerca. Gli SPN registrati su account computer di solito non danno problemi: gli account macchina ruotano la password ogni 30 giorni e hanno generato chiavi AES molto tempo fa. L’esposizione si concentra sugli account di servizio di tipo utente, quelli tipicamente dietro SAP, applicazioni web legacy o un application pool IIS configurato una volta e mai più toccato. Le loro chiavi si rinnovano solo al cambio della password, e per alcuni di questi account non è mai successo.

Figura 2: il dispositivo ottiene il proprio TGT AES senza problemi. La rottura avviene un passo dopo, quando il ticket di servizio per lo SPN di un’app dipende da un account di servizio che non ha mai ricevuto chiavi AES.

Trovate le vostre dipendenze da RC4

Due punti di osservazione vi dicono a che punto siete. Sui domain controller il registro eventi System contiene gli eventi Kdcsvc di KB5073381: 201 e 202 sono gli avvisi di audit, mentre 203, 204, 208 e 209 indicano che un ticket è stato effettivamente rifiutato. Nel registro Security, l’evento 4769 con tipo di cifratura del ticket 0x17 identifica ogni ticket di servizio ancora emesso con RC4 (AES256 compare come 0x12).

Sul lato directory, elencate ogni account che porta uno SPN e verificatene i tipi di cifratura:

# Tutti gli account di servizio (con SPN) e i loro tipi di cifratura Kerberos
Get-ADUser -Filter 'ServicePrincipalName -like "*"' `
    -Properties ServicePrincipalName, msDS-SupportedEncryptionTypes |
    Select-Object Name,
        @{N='EncTypes';E={'0x{0:X}' -f [int]$_.'msDS-SupportedEncryptionTypes'}},
        @{N='SPNs';E={$_.ServicePrincipalName -join ', '}}

Come leggere i valori: 0x18 significa solo AES, che è il nuovo default e il punto in cui volete arrivare. 0x4 significa solo RC4, che ha smesso di funzionare il 14 luglio. 0x0 (mai impostato) ora ricade su AES, ma serve solo se l’account ha davvero chiavi AES; gli account la cui password precede il passaggio del dominio al livello funzionale di Windows Server 2008 non le hanno mai generate. 0x24 è il fallback di interoperabilità documentato (RC4 con chiavi di sessione AES) e va considerato una soluzione temporanea.

Il rimedio: chiavi AES, non eccezioni

Per ogni account emerso dall’audit il rimedio è lo stesso e richiede pochi minuti:

1. Reimpostate la password dell’account. Un reset della password genera materiale crittografico nuovo, incluse le chiavi AES mancanti. Per la maggior parte degli account il rimedio finisce qui.
2. Impostate msDS-SupportedEncryptionTypes su 0x18 sugli account di servizio critici, così la configurazione è esplicita e non ereditata da un default.
3. Verificate dal lato mobile. Aprite le app protette da Kerberos usate dalla vostra flotta e confermate che gli eventi 4769 mostrino ora il tipo di cifratura 0x12 per i loro SPN.
4. Dove il servizio è vostro, valutate un gMSA. I Group Managed Service Account ruotano automaticamente password casuali di 240 caratteri, hanno chiavi AES per progettazione e non lasciano alcuna password scelta da una persona da craccare.

Ciò che non dovete fare è disseminare eccezioni RC4 per singolo account. Ogni eccezione ricrea esattamente il bersaglio esposto al Kerberoasting che tutto questo lavoro elimina, e le indicazioni di Microsoft sono esplicite: la via delle eccezioni è un’ultima risorsa per le appliance legacy, non una strategia di migrazione.

Dove vi lascia tutto questo

La direzione è a senso unico: RC4 ha perso il rollback a luglio, NTLMv1 viene bloccato a ottobre (KB5066470) e l’NTLM di rete si spegnerà con la prossima LTSC di Windows Server. Ogni passo porta nello stesso punto, cioè Kerberos con AES e, sempre più spesso, certificati al posto delle password. Per le flotte mobili la buona notizia è che una configurazione basata su PKINIT parla già AES da un capo all’altro, quindi il lavoro rimanente è igiene di Active Directory sugli account dietro le vostre app. Verificate ora i tipi di cifratura negli eventi 4769 e reimpostate i ritardatari: la prossima scadenza sui protocolli legacy passerà senza che nessuno se ne accorga.

---