• Sicurezza, Sistemi Operativi
• 28 Gennaio 2026

Ci sono cambiamenti che arrivano con un annuncio ufficiale, una roadmap ben evidenziata, una slide rossa che dice breaking change. Poi ci sono quelli che arrivano come una variazione di tono: nessuno se ne accorge subito, ma dopo un po’ l’aria è diversa.

L’aggiornamento di Windows di gennaio 2026 è uno di questi.

Nessun servizio cade, nessuna autenticazione che smette di funzionare. Eppure, nel cuore dei Domain Controller, qualcosa smette di essere concesso per abitudine.

Microsoft ha avviato il ritiro progressivo di RC4 da Kerberos introducendo meccanismi che rendono osservabile un comportamento fino a oggi implicito.

RC4 e Kerberos: una scelta operativa, non teorica

RC4 è rimasto a lungo all’interno di Kerberos non per motivi crittografici, ma per ragioni operative. È compatibile. Non impone requisiti particolari sulle password. Tollera applicazioni legacy e configurazioni incoerenti.

In fase di negoziazione Kerberos, la scelta dell’algoritmo di cifratura non è astratta. Dipende da:

• capacità del client;
  
• policy del KDC;
  
• impostazioni dell’account di servizio.
  

Per anni RC4 ha rappresentato la soluzione che evitava problemi. Quando qualcosa non supportava AES, RC4 garantiva comunque l’emissione del ticket. Questo comportamento ha permesso a molte infrastrutture di funzionare senza interventi correttivi, ma ha introdotto una dipendenza strutturale tra crittografia, password e debito tecnico.

Quando la crittografia diventa superficie di attacco

Per anni, le debolezze di RC4 sono state considerate teoriche. Poi hanno smesso di esserlo. Nel contesto Kerberos, RC4 espone una dinamica molto precisa: i ticket di servizio possono essere richiesti legittimamente da un utente autenticato, intercettati e portati offline.

Da quel momento in poi, il dominio non vede più nulla. Non c’è rumore. Non c’è allarme. C’è solo un hash cifrato con un algoritmo che non è stato progettato per resistere a questo tipo di attacco.

Qui entra in gioco la realtà degli ambienti enterprise:

• service account con privilegi elevati;
  
• password che non scadono;
  
• policy nate in un’altra epoca;
  
• account che nessuno osa toccare.
  

L’uso di RC4 riduce drasticamente il costo computazionale e operativo degli attacchi offline. Ed è per questo che Microsoft non parla di modernizzazione. Parla di riduzione del rischio strutturale.

RC4: struttura interna e modello operativo

Per capire perché RC4 è problematico in Kerberos, è necessario osservare il suo funzionamento interno. RC4 è uno stream cipher simmetrico. Genera un flusso di byte pseudocasuali (keystream) che viene combinato con il plaintext tramite operazione XOR.

L’algoritmo mantiene uno stato interno di 256 byte, rappresentato come una permutazione dei valori da 0 a 255. Tutte le proprietà di sicurezza dipendono esclusivamente da:

• come questo stato viene inizializzato;
  
• come viene aggiornato nel tempo.
  

Non esistono round, blocchi o trasformazioni non lineari complesse. RC4 è completamente deterministico.

Lo stato iniziale è un array S di lunghezza 256:

Questa struttura ordinata viene modificata una sola volta tramite il Key Scheduling Algorithm (KSA).

Il KSA incorpora la chiave nello stato interno. La chiave viene trattata come un array di byte K, di lunghezza variabile. L’algoritmo percorre l’intero array S, aggiornando un indice j e scambiando elementi.

Al termine della KSA:

• lo stato iniziale ordinato non viene distrutto, ma rimescolato;
  
• la distribuzione dei valori non è uniforme;
  
• rimangono correlazioni legate alla chiave e alla posizione degli indici.
  

Queste proprietà vengono ereditate dalla fase successiva.

Dopo la KSA, RC4 entra nella fase di generazione del keystream.

Lo Pseudo-Random Generation Algorithm(PRGA) aggiorna continuamente lo stato e produce un byte per iterazione.

while generating:

Ogni iterazione:

• modifica lo stato S,
  
• produce un byte di keystream,
  
• dipende interamente dallo stato precedente.
  

Figura 1 – Stato interno di RC4 e flusso di generazione del keystream

Il keystream generato dalla PRGA viene combinato con il plaintext tramite XOR:

ciphertext = plaintext XOR keystream

La decifratura utilizza la stessa operazione:

plaintext = ciphertext XOR keystream

Il keystream prodotto da RC4 presenta bias statistici documentati, in particolare:

• i primi byte non sono distribuiti uniformemente;
  
• alcuni valori compaiono con probabilità maggiore;
  
• esistono correlazioni tra output e stato interno.
  

Queste proprietà non sono occasionali ma il risultato diretto della combinazione KSA + PRGA. Per questo motivo, molte implementazioni storiche scartavano i primi byte del keystream (“RC4-drop-n”). Kerberos non adotta questa mitigazione.

RC4-HMAC in Kerberos

In Kerberos, RC4 viene utilizzato nella variante RC4-HMAC.

La chiave RC4 non è casuale. È derivata direttamente dalla password dell’account tramite funzione di hashing. Conseguenze operative:

• la sicurezza del cifrario dipende dalla password;
  
• la stessa chiave viene usata ripetutamente;
  
• ogni ticket cifrato rappresenta un nuovo campione crittografico.
  

Il contenuto del ticket Kerberos è altamente strutturato:

• header noti;
  
• campi a lunghezza fissa;
  
• valori prevedibili.
  

Questo introduce condizioni di known plaintext, che riducono ulteriormente l’entropia effettiva del ciphertext.

Kerberos emette ticket in modo continuo:

• per ogni servizio,
  
• per ogni richiesta,
  
• per ogni rinnovo.
  

Con RC4:

• la chiave rimane invariata finché la password non cambia;
  
• il keystream deriva sempre dallo stesso stato iniziale;
  
• i ciphertext possono essere raccolti e analizzati offline.
  

L’accumulo di ticket RC4 consente analisi statistiche su larga scala. Il costo computazionale dell’attacco cresce linearmente con il numero di campioni disponibili.

Questo implica osservare la propria infrastruttura dal punto di vista di un attaccante.

Differenze operative rispetto ad AES

AES utilizza:

• cifratura a blocchi,
  
• key schedule indipendente,
  
• modalità operative che spezzano correlazioni.
  

In AES:

• il plaintext strutturato non produce pattern riutilizzabili;
  
• l’uso ripetuto non degrada le proprietà statistiche;
  
• il costo degli attacchi offline aumenta in modo significativo.
  

Il passaggio da RC4 ad AES in Kerberos modifica direttamente:

• la fattibilità del cracking offline;
  
• la convenienza degli attacchi a dizionario;
  
• l’impatto delle password deboli.
  

Quindi
RC4 rimane compatibile con ambienti legacy perché:

• non impone requisiti sulle password;
  
• non richiede modifiche applicative;
  
• tollera configurazioni incoerenti.
  

Queste stesse caratteristiche lo rendono inadatto a:

• ambienti ad alta esposizione;
  
• domini con service account storici;
  
• infrastrutture soggette ad attacchi post-compromissione.
  

Il ritiro progressivo di RC4 da Kerberos elimina una dipendenza strutturale tra:

• qualità delle password;
  
• resistenza crittografica;
  
• sicurezza complessiva del dominio.
  

Kerberos e negoziazione crittografica

È un protocollo estremamente rigoroso che funziona solo perché tutti rispettano le regole. Quando un client chiede un ticket:

1. presenta un elenco di algoritmi supportati;
   
2. il KDC confronta quell’elenco con le policy del dominio;
   
3. tiene conto delle impostazioni dell’account di servizio;
   
4. sceglie l’algoritmo migliore comune.
   

Per anni, RC4 è stato il compromesso che chiudeva la negoziazione senza domande.

Con gli update del 2026, questa dinamica cambia:

• AES diventa il riferimento;
  
• RC4 non è più il paracadute automatico.
  

Questo non rompe Kerberos. Lo rende più coerente con il suo modello di sicurezza.

Nell’articolo AD-ventures in offensive security – Parte 4/9 – Kerberoasting – ICT Power ho già affrontato questi aspetti anche dal punto di vista offensivo.

Gennaio 2026

L’aggiornamento di gennaio 2026 non cambia il comportamento del sistema in modo evidente. Cambia la sua capacità di raccontare cosa sta succedendo. I Domain Controller iniziano a produrre eventi di audit Kerberos più dettagliati. Eventi che indicano chiaramente:

• che tipo di cifratura è stata richiesta;
  
• quale account è coinvolto;
  
• quale ticket è stato emesso.
  

Questo è un passaggio sottile ma fondamentale. Fino a ieri, RC4 era spesso un’ipotesi. Da gennaio 2026, diventa un dato. Non “forse c’è qualcosa che lo usa”. Ma “questo servizio lo usa, adesso”. Dal punto di vista operativo, significa che la responsabilità cambia mano. Non è più il sistema a decidere cosa tollerare. È l’amministratore a dover scegliere cosa ignorare.

Aprile 2026

Aprile sarà il momento in cui le cose iniziano a sembrare strane. Non tutto smetterà di funzionare. Anzi, sembrarà funzionare quasi tutto. Ma emergeranno comportamenti difficili da interpretare:

• servizi che falliscono solo dopo il riavvio;
  
• autenticazioni che dipendono dal client;
  
• errori che compaiono solo in determinate fasce orarie.
  

Il motivo è semplice: non tutte le richieste Kerberos seguono lo stesso percorso, e non tutte incontrano le stesse configurazioni. RC4, fino a quel momento, mascherava molte incoerenze. Quando smetterà di farlo, le incoerenze saranno visibili. Ed è qui che molti scoprono di non conoscere davvero la propria superficie di autenticazione.

Luglio 2026

A luglio, Microsoft rimuoverà le stampelle. RC4 non sarà disabilitato globalmente, ma non verrà più usato se non esplicitamente richiesto.

Questo è il punto di svolta culturale. Se un account usa ancora RC4:

• qualcuno lo ha configurato così;
  
• qualcuno ne conosce l’esistenza;
  
• qualcuno ne ha accettato il rischio.
  

Il vero lavoro non è tecnico, è archeologico

Dal punto di vista tecnico, la soluzione è chiara:

• individuare gli account coinvolti;
  
• verificare il supporto ad AES;
  
• aggiornare password e configurazioni.
  

Dal punto di vista reale, il lavoro è molto più complesso.

Significa fare archeologia:

• capire perché un account esiste;
  
• ricostruire dipendenze mai documentate;
  
• distinguere ciò che è critico da ciò che è solo sopravvissuto.
  

RC4 vive quasi sempre in zone d’ombra:

• applicazioni installate “temporaneamente”;
  
• integrazioni con sistemi esterni;
  
• servizi che nessuno osa spegnere.
  

Non perché siano indispensabili ma perché nessuno vuole essere quello che rompe tutto.

Perché questo cambiamento conta più di quanto sembri

Questo non è solo un articolo su RC4. È anche un articolo su come trattiamo le identità. Per anni, questa è stata vista come un prerequisito, non come un asset. Qualcosa che “deve funzionare”, ma che raramente viene ripensato. Microsoft sta dicendo una cosa molto semplice: l’identità è infrastruttura critica. E l’infrastruttura non può basarsi su indulgenze accumulate nel tempo.

Kerberos continua a fare quello che ha sempre fatto. Semplicemente, ha smesso di proteggere le cattive abitudini. RC4 non se ne va perché è vecchio. Se ne va perché ha fatto il suo tempo in un mondo che è cambiato. E quando un sistema smette di essere indulgente, non è per punire. È per costringere chi lo usa a sapere davvero come funziona. Perché, in sicurezza, ciò che non conosci non è neutro. È solo un rischio che aspetta il momento giusto per presentarsi.

Conclusioni

RC4 non è stato rimosso da Kerberos perché obsoleto. È stato rimosso perché incompatibile con il modo in cui Kerberos viene realmente utilizzato negli ambienti moderni.

Uno stream cipher con stato riutilizzato, bias statistici noti e chiavi derivate da password statiche non può sostenere:

• emissione continua di ticket;
  
• accumulo di ciphertext;
  
• attacchi offline su larga scala.
  

Il cambiamento introdotto da Microsoft nel 2026 non è una forzatura. È l’allineamento tra modello crittografico e modello operativo. Gli eventi di audit introdotti a gennaio non servono solo a “vedere chi usa RC4”. Servono a mostrare quante volte lo stesso segreto viene riutilizzato e quanto valore produce per un attaccante.

Questo è il punto chiave: non si tratta di disabilitare un algoritmo, ma di rimuovere una dipendenza strutturale tra password, crittografia e sicurezza dell’identità. Kerberos continua a funzionare come sempre. Semplicemente, non copre più ciò che per anni è stato lasciato irrisolto.

Stay tuned.