Nel corso della storia di Active Directory, gli autori delle minacce hanno continuamente individuato nuovi modi per sfruttare le vulnerabilità del protocollo di autenticazione Kerberos. Per contribuire a ridurre i rischi associati al Kerberoasting, Microsoft renderà obsoleta la crittografia RC4 a partire da aprile 2026. Se non avete ancora individuato le applicazioni nel vostro ambiente che potrebbero subire interruzioni a causa di questa modifica, è ora di mettere questo compito in cima alla vostra lista delle cose da fare. Questo post spiega il processo e vi indica le risorse che possono esservi d'aiuto.
Perché Microsoft sta abbandonando la crittografia RC4?
Le tattiche, le tecniche e le procedure (TTP) che sfruttano Kerberos possono essere suddivise in tre categorie:
- Attacchi di tipo "roasting", come AS-REQ Roasting e Kerberoasting
- Abuso della delega, compresa la delega Kerberos senza restrizioni e la delega con restrizioni basata sulle risorse
- Abusi relativi ai biglietti, tra cui Golden Ticket, Silver Ticket, Diamond Ticket, Sapphire Ticket, Bronze Bit, Pass-the-Ticket e così via
Il kerberoasting è diventato una delle tecniche di attacco più diffuse. Negli ultimi anni, Microsoft ha introdotto misure di difesa contro gli attacchi di kerberoasting e sono stati pubblicati numerosi articoli sul kerberoasting e su come mitigarlo. In questo articolo non approfondiremo i meccanismi dell'attacco, ma, in linea di massima, ecco come funziona:
- Un utente malintenzionato richiede un ticket di servizio per un nome di entità di servizio (SPN) valido.
- Il Kerberos Key Distribution Center (KDC) emette il ticket di servizio utilizzando la crittografia RC4, un algoritmo meno sicuro rispetto all'AES-SHA1 (e quindi più facile da violare).
- L'autore dell'attacco mette questo ticket in modalità offline e utilizza un meccanismo di cracking con forza bruta per recuperare la password dell'account.
- L'autore dell'attacco utilizza l'account compromesso per spostarsi lateralmente e ottenere privilegi più elevati.
A causa del diffuso sfruttamento di RC4 nell'ambito degli attacchi di tipo "kerberoasting", Microsoft ha annunciato che questa crittografia sarà resa obsoleta: i controlli inizieranno a gennaio 2026, l'applicazione della misura con rollback manuale avverrà ad aprile 2026 e l'applicazione completa è prevista per luglio 2026.
Tuttavia, molte aziende continuano ad affidarsi ad applicazioni interne o di terze parti che non supportano tipi di crittografia più sicuri, come AES-128 e AES-256. Se la vostra organizzazione rientra in questa categoria, dovrete individuare gli account di tali applicazioni e configurare la crittografia AES per ciascuno di essi.
Quali applicazioni utilizzano RC4?
Allora, come si fa a sapere quali applicazioni utilizzano RC4 come tipo di crittografia Kerberos?
Sarà necessario eseguire un controllo del servizio di autenticazione Kerberos e delle operazioni relative ai ticket di servizio Kerberos per acquisire gli ID evento 4768 (eventi del servizio di autenticazione) e 4769 (operazioni relative ai ticket di servizio) nel registro eventi di sicurezza. (Microsoft ha introdotto gli ID evento aggiuntivi 201–209, noti anche come "KDC hardening", con le patch di gennaio 2026 nel registro eventi di sistema per supportare ulteriormente l'iniziativa di dismissione dell'RC4. Tuttavia, gli eventi 4768 e 4769 possono essere considerati gli eventi "principali", motivo per cui questo post si concentra sul monitoraggio di questi due eventi.)
Analizziamo questi eventi.
ID evento 4768
La figura 1 mostra un esempio di output relativo all'ID evento 4768.
È stato richiesto un ticket di autenticazione Kerberos (TGT).
Informazioni sull'account:
Nome account: jdoe
Nome del realm fornito: CHILD
ID utente: S-1-5-21-1873250772-3107742394-1596888999-1114
Tipi di crittografia supportati da MSDS: 0x27 (DES, RC4, AES-Sk)
Chiavi disponibili: AES-SHA1, RC4
Informazioni sul servizio:
Nome del servizio: krbtgt
ID servizio: S-1-5-21-1873250772-3107742394-1596888999-502
Tipi di crittografia supportati da MSDS: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Chiavi disponibili: AES-SHA1, RC4
Informazioni sul controller di dominio:
Tipi di crittografia supportati da MSDS: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Chiavi disponibili: AES-SHA1, RC4
Informazioni di rete:
Indirizzo client: ::ffff:10.1.1.250
Porta client: 53904
Etype pubblicizzati:
AES256-CTS-HMAC-SHA1-96
AES128-CTS-HMAC-SHA1-96
RC4-HMAC-NT
DES-CBC-MD5
Informazioni aggiuntive:
Opzioni ticket: 0x40810010
Codice risultato: 0x0
Tipo di crittografia del ticket: 0x12
Tipo di crittografia della sessione: 0x12
Tipo di pre-autenticazione: 2
Tipo di crittografia della pre-autenticazione: 0x12
--Il resto è stato omesso per brevità.--
Figura 1. Esempio di output dell'ID evento 4768
Questo esempio contiene diverse serie di informazioni rilevanti.
Informazioni sull'account
- Nome dell'account. L'entità che richiede il Ticket Granting Ticket (TGT)
- Nome del dominio specificato. Il dominio in cui risiede l'identità
- ID utente. Il nome descrittivo (o SID) dell'identità
- MSDS-SupportedEncryptionTypes. I tipi di crittografia che l'account può utilizzare
Informazioni sul servizio
- Nome del servizio. Il soggetto di servizio richiesto (in questo caso, krbtgt)
- ID servizio. Il nome descrittivo (o SID) dell'entità di servizio richiesta
- MSDS-SupportedEncryptionTypes. I tipi di crittografia che l'account di servizio può utilizzare
Informazioni sul controller di dominio (DC)
- MSDS-SupportedEncryptionTypes. I tipi di crittografia supportati dal DC
Informazioni aggiuntive
- Opzioni del ticket. 0x40810010 (trasferibile, rinnovabile, canonicalizzato, rinnovabile-ok), come illustrato nella Figura 2.
- Tipo di crittografia del ticket: 0x12 (AES256), come illustrato nella Figura 3.
- Tipo di crittografia della sessione. 0x12 (AES256), come illustrato nella Figura 3.
- Tipo di crittografia pre-autenticazione: 0x12 (AES256), come illustrato nella Figura 4.
ID evento 4769
La figura 5 mostra un esempio di output relativo all'ID evento 4769.
A Kerberos service ticket was requested.
Account Information:
Account Name: jdoe@CHILD.CONTOSO.COM
Account Domain: CHILD.CONTOSO.COM
Logon GUID: {5f752786-c7b3-fb33-0ce8-a54adeea22c3}
MSDS-SupportedEncryptionTypes: N/A
Available Keys: N/A
Service Information:
Service Name: CHILDMEMBER$
Service ID: S-1-5-21-1873250772-3107742394-1596888999-1105
MSDS-SupportedEncryptionTypes: 0x1C (RC4, AES128-SHA96, AES256-SHA96)
Available Keys: AES-SHA1, RC4
Domain Controller Information:
MSDS-SupportedEncryptionTypes: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Available Keys: AES-SHA1, RC4
Network Information:
Client Address: ::ffff:10.1.1.250
Client Port: 53905
Advertized Etypes:
AES256-CTS-HMAC-SHA1-96
AES128-CTS-HMAC-SHA1-96
RC4-HMAC-NT
Additional Information:
Ticket Options: 0x40810000
Ticket Encryption Type: 0x12
Session Encryption Type: 0x12
Failure Code: 0x0
Transited Services: -
--Remainder snipped brevity--
Figura 5. Esempio di output dell'ID evento 4769
Questo esempio contiene diverse serie di informazioni rilevanti.
Informazioni sul servizio
- Nome del servizio. L'SPN della richiesta di ticket di servizio (in questo caso, per host/childmember.child.contoso.com), come illustrato nella Figura 6.
sname-string: 2 voci
SNameString: host
SNameString: childmember.child.contoso.com
Figura 6. Estratto di una traccia Wireshark che mostra l'SPN della richiesta del ticket di servizio
- ID servizio. Il nome descrittivo (o SID) dell'entità di sicurezza che ha registrato l'SPN
- MSDS-SupportedEncryptionTypes. I tipi di crittografia che l'account di servizio può utilizzare
Informazioni su DC
- MSDS-SupportedEncryptionTypes. I tipi di crittografia supportati dal DC
Informazioni aggiuntive
- Opzioni biglietti. 0x40810000
- Tipo di crittografia del ticket. 0x12 (AES256)
- Tipo di crittografia della sessione. 0x12 (AES256)
Quando si utilizza RC4 per la crittografia, i risultati appaiono leggermente diversi rispetto a quelli degli esempi precedenti. La figura 7 mostra l'output dell'ID evento 4769 per un computer client che utilizza esclusivamente la crittografia RC4.
A Kerberos service ticket was requested.
Account Information:
Account Name: jdoe@CHILD.CONTOSO.COM
Account Domain: CHILD.CONTOSO.COM
Logon GUID: {df8a66a8-8c1d-061e-b216-f935b45eb88a}
MSDS-SupportedEncryptionTypes: N/A
Available Keys: N/A
Service Information:
Service Name: CHILDMEMBER$
Service ID: CHILD\CHILDMEMBER$
MSDS-SupportedEncryptionTypes: 0x4 (RC4)
Available Keys: AES-SHA1, RC4
Domain Controller Information:
MSDS-SupportedEncryptionTypes: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Available Keys: AES-SHA1, RC4
Network Information:
Client Address: ::ffff:10.1.1.250
Client Port: 51299
Advertized Etypes:
AES256-CTS-HMAC-SHA1-96
AES128-CTS-HMAC-SHA1-96
RC4-HMAC-NT
Additional Information:
Ticket Options: 0x40810000
Ticket Encryption Type: 0x17
Session Encryption Type: 0x17
Failure Code: 0x0
Transited Services: -
--Remainder snipped for brevity--
Figura 7. Messaggio relativo all'ID evento 4769 su un computer client che utilizza esclusivamente RC4
Le parti in grassetto evidenziano le differenze principali tra questo caso e gli esempi precedenti. Analizziamole nel dettaglio.
Informazioni sul servizio
- Nome del servizio: CHILDMEMBER$ (come nell'esempio precedente)
- ID servizio. Il nome descrittivo (o SID) dell'entità di servizio richiesta
- Tipi di crittografia supportati da MSDS. 0x4 (RC4)
Informazioni aggiuntive
- Opzioni biglietti. 0x40810000 (come nell'esempio precedente)
- Tipo di crittografia del ticket. 0x17 (RC4-HMAC)
- Tipo di crittografia della sessione. 0x17 (RC4-HMAC)
Come verificare la presenza di app che utilizzano RC4 nel proprio ambiente
Come mostra l'esempio precedente relativo all'RC4, per individuare la crittografia RC4 nel proprio ambiente è necessario esaminare i registri degli eventi (preferibilmente i registri SIEM) alla ricerca di richieste al servizio di autenticazione (AS-REQ) e relative risposte (AS-REP), nonché di richieste al servizio di concessione dei ticket (TGS-REQ) e relative risposte (TGS-REP), verificando che i tipi di crittografia dei ticket e delle sessioni siano 0x17.
Per aiutarti in questo compito, abbiamo creato alcune query di esempio sia per Microsoft Sentinel che per Splunk. Puoi utilizzare questi esempi come modelli per eseguire un audit del tuo ambiente.
A seconda di come è stata configurata l'inoltro degli eventi per Sentinel, sarà necessario interrogare DeviceEvents oppure WindowsEvent. Ad esempio, se si utilizza l'inoltro degli eventi di Windows per raccogliere i registri degli eventi e inoltrarli a Sentinel, sarà necessario interrogare WindowsEvent e cercare solo le istanze degli ID evento 4768 e 4769 che corrispondono a 0x17 nei campi "Tipo di crittografia del ticket" o "Tipo di crittografia della sessione".
È possibile utilizzare la seguente query per effettuare ricerche in Sentinel. Questa query è stata ampliata per includere altre colonne di dati.
WindowsEvent
| where EventID in ('4768', '4769')
| where TimeGenerated between (ago(60d) .. now())
| extend EventDataJson = parse_json(EventData)
| extend TargetUserName = EventDataJson.TargetUserName
| extend TargetDomainName = EventDataJson.TargetDomainName
| estendi IpAddress = EventDataJson.IpAddress
| estendi ServiceAvailableKeys = EventDataJson.ServiceAvailableKeys
| estendi ServiceName = EventDataJson.ServiceName
| estendi SessionKeyEncryption = EventDataJson.SessionKeyEncryptionType
| estendi TicketEncryption = EventDataJson.TicketEncryptionType
| estendi TicketOptions = EventDataJson.TicketOptions
| dove SessionKeyEncryption == '0x17' oppure
TicketEncryption == '0x17'
| proietta TimeGenerated, EventID, TargetUserName, TargetDomainName, IpAddress, ServiceName, TicketEncryption, SessionKeyEncryption, TicketOptions, ServiceAvailableKeys, EventDataJson
Ecco una breve sintesi della richiesta:
WindowsEvent
Come viene memorizzata la query in questa implementazione di Sentinel (nel tuo ambiente potrebbe trattarsi di DeviceEvents, come descritto in precedenza)
| where EventID in ('4768', '4769')
Ricerca degli ID evento 4768 e 4769
| where TimeGenerated between (ago(60d) .. now())
Risale a 60 giorni fa (puoi impostare il valore che preferisci)
| extend EventDataJson = parse_json(EventData)
Formatta la colonna EventData in formato JSON e analizza il JSON da utilizzare nel resto della query
| extend TargetUserName = EventDataJson.TargetUserName
Indica l'identità che richiede il ticket
| extend TargetDomainName = EventDataJson.TargetDomainName
Indica il dominio in cui risiede l'identità richiedente
| extend IpAddress = EventDataJson.IpAddress
Mostra l'indirizzo IP del client, se è indicato nell'evento
| extend ServiceAvailableKeys = EventDataJson.ServiceAvailableKeys
Indica le chiavi di crittografia disponibili per il servizio
| extend ServiceName = EventDataJson.ServiceName
Indica l'SPN a cui si riferisce la richiesta di ticket
| extend SessionKeyEncryption = EventDataJson.SessionKeyEncryptionType
Specifica il tipo di crittografia della chiave di sessione che il client (richiedente) utilizzerà per interagire con il titolare del ticket
| extend TicketEncryption = EventDataJson.TicketEncryptionType
Specifica il tipo di crittografia del TGT o del ticket di servizio
| extend TicketOptions = EventDataJson.TicketOptions
Fornisce ulteriori informazioni sulle opzioni relative ai ticket della richiesta, che potrebbero rivelarsi utili per identificare tipi di ticket quali ticket di segnalazione, ticket delegati, ticket inoltrati, ticket tramite proxy e così via
| where SessionKeyEncryption == '0x17' or
TicketEncryption == '0x17'
Cerca la crittografia della chiave di sessione o la crittografia del ticket che sia RC4-HMAC (0x17)
| project TimeGenerated, EventID, TargetUserName, TargetDomainName, IpAddress, ServiceName, TicketEncryption, SessionKeyEncryption, TicketOptions, ServiceAvailableKeys, EventDataJson
Indica i campi da visualizzare nei risultati
La figura 8 mostra un esempio dei risultati di questa query.
Per Splunk, questa stessa query avrebbe il seguente aspetto:
index="wineventlog" LogName="Security" EventCode IN ("4768", "4769") earliest=-60d@d latest=now
| search Session_Encryption_Type="0x17" or Ticket_Encryption_Type="0x17"
| tabella _time EventCode Account_Name Account_Domain Client_Address service_name Ticket_Encryption_Type Session_Encryption_Type Ticket_Options, _raw
Prima di utilizzare queste query nel proprio ambiente, assicurarsi che la funzione di controllo dei ticket di servizio sia abilitata. Se tale funzione non è abilitata, i DC non genereranno gli eventi pertinenti (ID evento 4768 e 4769 e ID evento 201–209, relativi al rafforzamento della sicurezza del KDC).
Il modo migliore per abilitare il controllo dei ticket di servizio è aggiornare una politica di gruppo esistente oppure aggiungerne una assegnata all'unità organizzativa (OU) del proprio DC. È necessario eseguire questa operazione per ogni dominio nella foresta AD. Il percorso per le impostazioni pertinenti è Configurazione computer > Impostazioni di Windows > Impostazioni di sicurezza > Configurazione avanzata dei criteri di controllo > Criteri di controllo > Accesso account. Abilitare le sottocategorie Controlla servizio di autenticazione Kerberos e Controlla operazioni dei ticket di servizio Kerberos sia per Successo che per Errore ( Figura 9).
Se non hai mai configurato una politica di controllo avanzata nei tuoi domini, assicurati di abilitare anche la politica «Controllo: forzare le impostazioni delle sottocategorie della politica di controllo (Windows Vista o versioni successive) per sovrascrivere le impostazioni delle categorie della politica di controllo» in «Configurazione del computer > Impostazioni di Windows > Impostazioni di sicurezza > Criteri locali > Opzioni di sicurezza». Questa politica viene solitamente impostata nello stesso Criterio di gruppo del «Controllo dei ticket di servizio».
Nota: se nei registri degli eventi di sicurezza dei tuoi DC non sono presenti eventi relativi al ticket di servizio 4769, non vedrai nemmeno gli avvisi relativi al rafforzamento della sicurezza del KDC (201–209) nel registro di sistema.
Suggerimento per la verifica: imposta temporaneamente un dispositivo in modo che supporti solo RC4 e richiedi un ticket di servizio da un account in cui il campo `msDS-SupportedEncryptionTypes` non contenga alcun valore. Se la funzione di controllo è configurata correttamente, dovresti visualizzare gli avvisi corrispondenti. Per ulteriori dettagli, consulta l'articolo di Microsoft Learn "Rilevare e correggere l'utilizzo di RC4 in Kerberos".
Una volta verificato che il monitoraggio Kerberos funzioni correttamente, inizia il vero lavoro: analizzare gli eventi ricevuti e risolvere i problemi relativi agli account o ai sistemi interessati.
La difficoltà principale nella rimozione di RC4 deriva dagli account di servizio legacy le cui password non vengono modificate da molti anni. Poiché RC4 in Active Directory è legato all'hash NT, qualsiasi account la cui password non sia mai stata reimpostata dopo l'introduzione di AES (ovvero dopo il rilascio di Windows Server 2008 e Windows Vista) potrebbe ancora disporre solo di chiavi compatibili con RC4.
È possibile risolvere il problema solo reimpostando due volte la password dell'account di servizio, costringendo così Active Directory a generare le chiavi AES necessarie. Tuttavia, è necessario anche sapere dove viene utilizzato tale account di servizio nel proprio ambiente; ad esempio, per avviare il servizio in questione su un determinato server membro o per eseguire un'attività pianificata.
Se si notano avvisi relativi al rafforzamento della sicurezza KDC (eventi 201–209 nel registro di sistema) accanto agli eventi 4768 o 4769, questo post su LinkedIn di Jerry Devore di Microsoft offre un'ottima panoramica su come correggere gli account e i sistemi interessati, dove msds-SET = msDS-SupportedEncryptionTypes (Tabella 1).
| Coppia di eventi | Cosa significa | Causa principale | Soluzione rapida |
|---|---|---|---|
| 201/203 | Client solo RC4 + msds-SET vuoto | Dispositivo legacy o keytab | Abilitare AES sul client OPPURE impostare msds-SET su 28 |
| 202/204 | L'account non dispone della chiave AES + msds-SET vuoto | Vecchia password | Reimposta la password dell'account (due volte) |
| 205 | Tipi di criteri di criteri predefiniti supportati attualmente in uso | È presente una sostituzione del registro | Se possibile, rimuovere l'override |
| 206/208 | Client solo RC4 + msds-SET solo AES | Incompatibilità del client | Aggiungi RC4 a msds-SET (valore 28) |
| 207/209 | L'account non dispone della chiave AES + AES msds-SET | La password non è stata reimpostata | Reimposta la password dell'account (due volte) |
In sintesi, per gli amministratori IT
- Verificate subito quali account e dispositivi sono ancora collegati a RC4.
- Aggiornare gli account di servizio a configurazioni compatibili con AES prima dell'applicazione completa della politica o della dismissione di RC4.
- Eliminare o adeguare i sistemi legacy che non supportano lo standard AES.
- Utilizzate i registri degli eventi in modo proattivo per individuare i dispositivi problematici prima che smettano di funzionare — cosa che accadrà dopo l'applicazione degli aggiornamenti di luglio 2026.
Hai bisogno di ulteriore assistenza?
L'abbandono di RC4 rappresenta un passo importante nella lotta contro il Kerberoasting, ma richiede un intervento tempestivo. Se avete domande in merito o avete bisogno di assistenza per la migrazione degli account della vostra applicazione, siamo a vostra disposizione.
