Crisi d'identità: nuove vulnerabilità che causano il downgrade di Kerberos, attacchi DoS e il controllo totale del dominio

Active Directory (AD) rimane il fiore all’occhiello dell’infrastruttura aziendale e, per gli autori delle minacce, l’obiettivo principale è chiaro: ottenere i privilegi di amministratore di dominio. Questo livello di privilegi garantisce di fatto il pieno controllo sull’ambiente aziendale. La protezione delle identità riveste quindi un ruolo fondamentale nella sicurezza aziendale e le organizzazioni investono notevoli sforzi per impedire agli autori delle minacce di accedere alle credenziali degli amministratori.

Ma cosa succederebbe se gli hacker potessero semplicemente confondere i controller di dominio (DC), indurli a identificarli come qualcun altro?

Qualche tempo fa ho partecipato a una conferenza tenuta da Yossi Sassi sulle tecniche di persistenza in Active Directory. Sassi ha illustrato un concetto che non conoscevo: la possibilità di aggiungere caratteri Unicode “invisibili” agli attributi degli oggetti. Ha presentato questa funzionalità come una tecnica di persistenza che consente di creare utenti che sembrano avere lo stesso nome di altri utenti legittimi già esistenti. Questa tecnica può creare confusione nei team di sicurezza e IT e ritardare notevolmente le indagini.

L'argomento ha suscitato la mia curiosità. Mi sono chiesto:

• Active Directory accetta altri caratteri “invisibili”?
• Come si potrebbe individuare in modo efficace l'uso improprio di questi caratteri?
• I caratteri nascosti hanno altri utilizzi, oltre alla persistenza?

Questo articolo illustra in dettaglio la mia ricerca su tali questioni, che ha portato alla scoperta di due nuove vulnerabilità di escalation dei privilegi in Active Directory: KerberLoss (CVE-2026-25177) e ResetNightmare (CVE-2026-27912). Ciascuna vulnerabilità adotta un approccio unico per causare confusione di identità sui DC, con conseguenze diverse. La seconda (e più grave) vulnerabilità consente a un utente con privilegi limitati di ottenere istantaneamente i privilegi di amministratore di dominio.

Ricerca preliminare: Unicode e Active Directory

Le mie domande mi hanno condotto in un interessante labirinto riguardante l’Unicode e l’elaborazione LDAP lato server. Ho iniziato cercando sul web i caratteri Unicode che possono risultare invisibili e compilando un elenco. Ero particolarmente interessato ai caratteri che risultano invisibili all’interno dei nomi degli oggetti, poiché mi sembrava il modo più interessante per sfruttare questa tecnica a fini illeciti.

Per iniziare i miei test, ho creato un account utente di esempio denominato UniqueUser. Come previsto, non è stato possibile creare un altro account utente con lo stesso nome (Figura 1).

Ma utilizzando un carattere “invisibile”, sono riuscito a creare un account utente apparentemente identico (Figura 2).

La Figura 2 mostra che la console di PowerShell analizza l'account risultante come se contenesse uno spazio anomalo (prima di “ser”). Tuttavia, osservando i due account all'interno degli strumenti grafici di gestione di AD, essi appaiono identici (Figura 3).

Utilizzando questo metodo di base, ho scorruto il mio elenco di caratteri Unicode, creando account utente con ciascuno di essi. Come mostra la Figura 4, alcuni caratteri sono stati interpretati in modo strano, e sicuramente non invisibile, in AD.

Dopo averli eliminati, mi è rimasta una directory simile a quella mostrata nella Figura 5.

Inoltre, sebbene il mio script abbia tralasciato alcuni caratteri perché il DC non li accettava, ne ha tralasciati altri perché il DC interpretava il nome utente come già esistente. (Col senno di poi, questo era un segnale premonitore.) Per testare il maggior numero possibile di questi caratteri senza essere limitato dai vincoli di unicità, ho creato anche altri nomi utente (Figura 6), ciascuno dei quali rappresentava un carattere invisibile unico nascosto tra due trattini (“–”).

A questo punto, ero convinto che il mio elenco di 385 caratteri invisibili rispondesse alla mia prima domanda di ricerca. Ora era giunto il momento di affrontare la sfida dell’individuazione.

Un approccio di rilevamento diverso

Nel suo intervento originale, Sassi ha presentato uno strumento che può essere utilizzato per individuare caratteri Unicode nascosti negli oggetti AD. Mi interessava capire come funzionasse quello strumento. Lo script adotta un approccio semplice:

• Crea un dizionario composto da 29 caratteri “invisibili”.
• Recupera tutte le proprietà di tutti gli oggetti presenti nel dominio.
• Eseguire un ciclo su ciascun attributo.
  • Converti l'attributo in un array di caratteri.
  • Recupera il valore esadecimale di ciascun carattere e confronta tale valore con quello presente nel dizionario.

Si tratta di un approccio completo. Tuttavia, tendo a privilegiare i sistemi di rilevamento in grado di funzionare in modo sistematico ed efficiente negli ambienti di produzione, quindi mi sono chiesto se il filtraggio potesse essere effettuato all’interno delle stesse richieste LDAP (cioè lato server) anziché elaborare ogni singolo carattere lato client.

Per scoprirlo, ho prima eseguito un semplice test per verificare se il DC fosse in grado di elaborare questi caratteri “così come sono”. Ho convertito un carattere (0x200B) nella sua forma "invisibile" come stringa, quindi l'ha copiata e incollata in PowerShell (Figura 7).

Fin qui tutto bene! Incollando il carattere direttamente in un filtro LDAP ho ottenuto solo l'oggetto previsto. Tuttavia, quando ho iniziato a sperimentare con caratteri diversi, mi sono imbattuto in alcune situazioni più strane.

Ho fatto lo stesso test, ma questa volta ho usato il carattere 0x200C, che è un altro carattere invisibile. Poiché questo carattere non ha superato i test di unicità dell'utente, non avevo un utente di nome Unique{0x200C}User nella mia directory in quel momento. Tuttavia, la mia query ha comunque restituito un risultato (Figura 8).

Chi ha un occhio attento potrebbe notare che questa volta il risultato non presenta quella strana spaziatura che avevo notato quando avevo visualizzato questi caratteri sulla console. Dopo aver verificato l'utente restituito tramite l'identificatore di sicurezza (SID), ho confermato che si trattava del nome utente senza caratteri aggiuntivi. Il carattere Unicode presente nel filtro è stato ignorato, sia da PowerShell che dal DC.

Se la mia teoria fosse corretta, allora modificando la query per cercare qualsiasi oggetto con il 0x200C Il carattere dovrebbe restituire tutti gli oggetti presenti nella directory. Questa volta ho convertito il valore Unicode all'interno della console per rendere il tutto più leggibile (Figura 9).

A questo punto, il comportamento del server LDAP non era coerente: alcuni caratteri venivano valutati, mentre altri venivano ignorati. Nel tentativo di escludere che la stringa di filtro fosse all’origine del problema, ho trovato la RFC 4515, che recita:

La rappresentazione stringa di un filtro di ricerca LDAP è una stringa di caratteri Unicode codificati in UTF-8

L'RFC fornisce anche alcuni esempi. Questo mi ha fatto sperare che sia possibile convertire e interrogare qualsiasi carattere Unicode, indipendentemente dalla sua stampabilità. Sulla base dell'RFC, ho creato la seguente funzione per ricevere un valore esadecimale Unicode (ad esempio, 0x200B) e restituisce la stringa compatibile con il filtro LDAP (Figura 10).

Ho verificato che la mia funzione eseguisse correttamente la conversione utilizzando il valore 0x200B, che ero riuscito a filtrare con successo nei miei test precedenti (Figura 11).

Dopo aver verificato questo, ho proceduto a testare i caratteri che mi davano problemi (Figura 12).

Purtroppo, nemmeno seguire le indicazioni dell'RFC ha funzionato. Utilizzando questo metodo per cercare i miei 385 caratteri invisibili con LDAP, ho individuato tre categorie distinte di caratteri:

• Caratteri filtrabili: solo 106 su 385
• Caratteri considerati come spazi bianchi: sebbene non siano visibili nell'interfaccia grafica, il comando char restituisce tutti i nomi degli oggetti contenenti spazi (ad es. “Domain Admins”, “Print Operators”)
• Caratteri completamente ignorati dal DC: char restituisce tutti gli oggetti

Ormai ero troppo preso dalla questione. Dovevo scoprire se c’era un modo per filtrare quei caratteri. Mentre riflettevo su cosa si potesse modificare (oltre alla stringa di filtro stessa), mi sono chiesto se uno dei Controlli estesi LDAP potrebbe essere d'aiuto. Esaminando le diverse opzioni, l'unica che ha attirato la mia attenzione è stata LDAP_SERVER_SORT_OID. Anche se la descrizione del controllo menziona solo l'ordine di ordinamento, La documentazione AD lo ribadisce più volte che la presenza del controllo influisce anche sul comportamento del confronto tra stringhe Unicode.

Per verificarlo, ho creato una funzione che mi ha permesso di aggiungere comodamente il LDAP_SERVER_SORT_OID controllo e per eseguire query LDAP con qualsiasi “OID della regola di ordinamento” da me scelto. Ho quindi ricreato uno scenario che mi era capitato su un Forum Microsoft. Ho creato due utenti:

• Shai
• Shäi II

Si noti la differenza tra “a” (Unicode 0x0061) e “ä” (Unicode 0x00E4).

Ho verificato la differenza tra l'esecuzione di una query LDAP senza il controllo esteso (che per impostazione predefinita utilizza l'inglese americano) e l'esecuzione della stessa query con il controllo e una regola di ordinamento “svedese”. Il secondo approccio ha effettivamente modificato il risultato restituito, non solo l'ordine di ordinamento (Figura 13).

Questo comportamento si è verificato anche quando ho utilizzato il mio Convert-UnicodeToLdapUtf8 funzione per convertire “ä” nel suo valore con escape UTF-8 (Figura 14).

Speravo che forse uno di questi OID delle regole di ordinamento potesse “filtrare l’infiltrabile” per quanto riguardava il mio elenco di caratteri invisibili.

Ho scritto uno script che esamina una per una tutte le regole di ordinamento e, per ciascuna di esse, verifica tutti i caratteri non filtrabili. Sono giunto alla conclusione che nessuna regola di ordinamento fa sì che il DC “rilevi” alcuno dei caratteri problematici.

Qui si è concluso il mio percorso di analisi dei caratteri LDAP invisibili dal punto di vista del rilevamento, lasciandomi con un problema irrisolto: esistono caratteri Unicode che il server LDAP di Active Directory ignora completamente.

Tuttavia, questo problema di rilevamento offriva un’interessante possibilità offensiva.

Cambiare ruolo

Per ricapitolare brevemente:

• Alcuni caratteri Unicode non vengono analizzati correttamente da Active Directory e risultano quindi invisibili.
• Alcuni di questi caratteri non possono essere filtrati da LDAP, il che significa che, quando si effettua un filtro per un valore “normale”, potrebbero essere restituiti valori contenenti tali caratteri.

In sostanza, c'è un potenziale per ignorare i vincoli di unicità per qualsiasi attributo basato su Unicode. Nei miei primi test con SamAccountNamee cnHo notato che Active Directory impedisce la creazione di oggetti duplicati che contengono caratteri non filtrabili (giustamente). Tuttavia, ciò non valeva per tutti gli attributi.

Nel 2021, Microsoft ha rilasciato una patch per una vulnerabilità identificata come CVE-2021-42282. La patch ha introdotto tre nuovi controlli di verifica dell'unicità:

• Unicità del nome principale dell'utente (UPN)
• Unicità del nome del principale di servizio (SPN)
• Unicità degli alias SPN

Ciascuno di questi valori deve essere unico in tutta la foresta, e tutti e tre i controlli vengono applicati per impostazione predefinita a livello di foresta dSHeuristics attributo. Qualsiasi utente con privilegi inferiori a quelli di amministratore di dominio riceverà un “errore di unicità” quando tenterà di impostare un valore che violi tali controlli di verifica dell’unicità.

Tuttavia, come vedrete nelle sezioni seguenti, i caratteri non filtrabili possono consentire agli utenti con privilegi limitati di aggirare questi controlli di verifica. Questa è la prima vulnerabilità che ho scoperto. A causa delle sue molteplici ripercussioni, l’ho denominata KerberLoss; Microsoft le ha assegnato il codice CVE-2026-25177.

KerberLoss: A partire dagli SPN

Per comprendere l'impatto di questa vulnerabilità, è necessario innanzitutto comprendere appieno il concetto di Service Principal Name (SPN).

Cosa sono i nomi dei soggetti di servizio?

Gli SPN sono un concetto di Active Directory spesso frainteso. Uno SPN è il modo in cui Kerberos identifica le istanze di servizio. Nel contesto di Active Directory, un servizio è qualsiasi risorsa a cui un utente accede e che solitamente richiede l’autenticazione. Tra gli esempi figurano le condivisioni di file SMB (cifs), le connessioni Desktop remoto (TERMSRV), LDAP e HTTP… tutti esempi delle cosiddette classi di servizio .

I servizi della stessa classe possono essere eseguiti su host diversi e un singolo host può fornire servizi di diverse classi. Pertanto, un SPN deve includere queste due componenti, con la seguente struttura di base:

<service class>/<host>

Nota: gli SPN possono includere anche due componenti aggiuntivi facoltativi, che esulano dall'ambito del presente documento.

I concetti di base sopra elencati sono piuttosto noti. Tuttavia, vorrei sottolineare alcuni punti importanti:

• Nel mondo di Active Directory e Kerberos, un servizio è gestito da una qualche forma di identità. Può trattarsi di un account computer, di un account utente o di un account di servizio gestito, ma dietro al servizio deve esserci sempre un’identità. Ciò è dovuto ai principi crittografici su cui si basa Kerberos. I ticket di servizio vengono crittografati utilizzando il segreto appartenente al “servizio di destinazione” (ovvero, la sua identità).
• L'oggetto che rappresenta ogni identità in Active Directory presenta un attributo denominato servicePrincipalName, che serve a gestire un elenco degli SPN dell'identità.
• Quando viene richiesto un ticket di servizio Kerberos, il Key Distribution Center (KDC) utilizza l'SPN contenuto nella richiesta per identificare il servizio di destinazione. In questo contesto, il servizio di destinazione è l'identità che detiene l'SPN pertinente.
• Infine, i ticket Kerberos contengono una parte in chiaro e una parte crittografata. L'SPN si trova nella parte in chiaro del ticket. Poiché l'SPN non è crittografato, è possibile modificarlo nei ticket e trasferirli tra diversi servizi della stessa identità. Ciò che conta è quale chiave sia stata utilizzata per crittografare il ticket.

Cosa sono gli alias SPN?

Se avete mai gestito un dominio Active Directory, avrete probabilmente notato che ogni computer dispone di alcuni SPN predefiniti, tra cui quelli con il HOST classe di servizio (HOST/computer). Per chi non li conoscesse, questi SPN possono risultare piuttosto complicati da capire.

La partizione di configurazione di Active Directory contiene un attributo denominato sPNMappings. Questo attributo consente la mappatura degli SPN ai cosiddetti Alias SPN. Per impostazione predefinita, questo attributo contiene un unico valore, che associa il HOST alias per i seguenti servizi:

alerter, appmgmt, cisvc, clipsrv, browser, dhcp, dnscache, replicator, eventlog, eventsystem, policyagent, oakley, dmserver, dns, mcsvc, fax, msiserver, ias, messenger, netlogon, netman, netdde, netddedsm, nmagent, plugplay, protectedstorage, rasman, rpclocator, rpc, rpcss, remoteaccess, rsvp, samss, scardsvr, scesrv, seclogon, scm, dcom, cifs, spooler, snmp, schedule, tapisrv, trksvr, trkwks, ups, time, wins, www, http, w3svc, iisadmin, msdtc

Una volta aggiunto al dominio, ogni account computer di Active Directory riceve un HOST classe SPN. Quando gli utenti tentano di accedere a un servizio associato a HOST (ad esempio, cifs, http), il KDC crittografa il ticket di servizio con la chiave associata all'account corrispondente HOST SPN.

Un caso limite interessante

La verifica dell'unicità degli alias SPN, di cui si è parlato in precedenza, impedisce la creazione di SPN mappati in conflitto. Ad esempio, se nella foresta è presente un computer denominato Server, che presenta il HOST/Server SPN, assegnazione del cifs/Server La connessione SPN verso un altro server verrà bloccata, anche se il cifs/Server SPN non esiste in modo esplicito.

Ho già accennato al fatto che la vulnerabilità individuata è in grado di aggirare questo controllo di unicità. Ma la cosa interessante è che l’algoritmo di ricerca degli SPN cerca sempre prima uno SPN esplicito. L’algoritmo cerca l’alias mappato dello SPN solo se non viene trovato uno SPN esplicito.

Con questa (piuttosto lunga) introduzione agli SPN, ora disponete delle conoscenze necessarie per comprendere come tale vulnerabilità possa essere sfruttata a fini malevoli.

Dimostrare l'impatto

Vi illustrerò diversi scenari. A tal fine, utilizzerò un ambiente semplice, composto da tre server membri del dominio:

• ServerA
• ServerB
• ServerC

L'autore dell'attacco sta operando come utente senza privilegi denominato NotAdmin.

Scenario n. 1: Attacco denial-of-service ai servizi mappati su HOST

Per il nostro primo scenario, supponiamo che ServerB ospita un'importante condivisione di file SMB. Gli utenti che accedono alla condivisione richiedono ticket di servizio per cifs/SERVERB. Poiché ServerB ha il HOST/SERVERB Per impostazione predefinita, il DC identifica l'SPN come l'account che detiene la chiave di crittografia pertinente per il servizio di destinazione. Se NotAdmin dispone dell'autorizzazione WriteSPN su ServerC, non possono aggiungere il cifs/SERVERB SPN, poiché la verifica dell'unicità dell'alias SPN impedisce questa azione (Figura 15).

Tuttavia, utilizzando un carattere invisibile e non filtrabile e inserendolo nella stringa, NotAdmin riesce ad aggiungere l'SPN in conflitto (Figura 16).

Come ci si poteva aspettare, il carattere non è del tutto invisibile nella console di PowerShell. Tuttavia, risulta invisibile quando si visualizza dsa.msc (Figura 17).

E, cosa ancora più importante, quando qualcuno effettua una query LDAP per il cifs/SERVERB SPN, ServerC è l'oggetto che viene restituito (Figura 18).

In questo scenario, a causa della precedenza esplicita degli SPN che ho spiegato in precedenza, quando un utente qualsiasi all’interno del dominio tenta di accedere a ServerB tramite SMB, il KDC crittograferà il ticket con ServerCla chiave di. Quando l'utente cerca di utilizzare questo biglietto, ServerB non è possibile decriptarlo, con conseguente KRB_AP_ERR_MODIFIED errore. All'utente medio, ciò potrebbe apparire come una serie di messaggi diversi e ambigui:

• Il nome di rete specificato non è più disponibile.
• Il nome dell'account di destinazione non è corretto.
• Impossibile trovare il percorso “path” perché non esiste.

La rimozione dello SPN falso ripristina immediatamente l'accesso normale (Figura 19).

Disporre dell'autorizzazione WriteSPN su qualsiasi un computer o un account utente nella foresta ha consentito l'esecuzione di un attacco denial-of-service (DoS) su qualsiasi HOST- servizio mappato nella foresta, utilizzando caratteri non filtrabili. Figura 20 illustra questo scenario.

Scenario n. 2: SPN-jacking

Un’altra opportunità interessante riguarda gli attacchi di delega vincolata Kerberos, poiché la delega vincolata classica viene configurata utilizzando gli SPN. Per dimostrarlo, ho modificato uno scenario tratto dal blog di Elad Shamir sull’SPN-jacking.

Nota: questo scenario presuppone la comprensione degli attacchi di delega Kerberos (ovvero “l’attacco S4U completo”). Una spiegazione del concetto di delega Kerberos esula dall’ambito del presente documento.

Nel suo post, Shamir ha illustrato il seguente scenario, in cui un malintenzionato con diritti di amministratore su ServerA vuole ottenere l'accesso come amministratore a ServerC. ServerA è configurato per la delega con restrizioni a cifs/ServerB, e l'autore dell'attacco dispone dei diritti WriteSPN su ServerB e ServerC (Figura 21).

Shamir ha suggerito di gestire la verifica dell'unicità degli alias SPN sfruttando WriteSPN su entrambi ServerB e ServerC, rimuovendo temporaneamente il HOST/SERVERB SPN da ServerB, e solo allora aggiungendo cifs/SERVERB a ServerC. A questo punto, l'autore dell'attacco può eseguire l'attacco S4U completo utilizzando ServerAl'account di … per ottenere un ticket di assistenza per un utente con privilegi per ServerC, prima di annullare le modifiche.

Utilizzando KerberLoss, in combinazione con la precedenza SPN esplicita, un aggressore può eliminare la necessità di WriteSPN verso il servizio intermedio. Per dimostrarlo, ho configurato il mio ambiente di laboratorio come illustrato nella Figura 22.

Come nell'esempio precedente relativo agli attacchi DoS, l'autore dell'attacco può utilizzare caratteri non filtrabili per causare ServerC il cifs/SERVERB SPN, aggirando il controllo di unicità e creando una situazione in cui i biglietti per cifs/SERVERB sarà crittografato con ServerCla chiave di (Figura 23).

A questo punto, l'autore dell'attacco può eseguire l'intero flusso di attacco S4U per ottenere un ticket con privilegi per cifs/SERVERB (Figura 24).

Sono riuscito a ottenere un ticket di assistenza per un utente amministratore. Ora verificherò se il ticket è stato crittografato correttamente con ServerCè la chiave. Poiché l'SPN si trova nella parte non crittografata del ticket, posso modificarlo in cifs/ServerC e accedere al server. L'accesso funzionerà solo se il ticket è crittografato con ServerCè la chiave, non ServerB’s (Figura 25).

Scenario n. 3: Riduzione del livello di autenticazione

Ora conosciamo l'impatto della creazione di SPN mappati in conflitto. Ma che dire degli SPN espliciti duplicati? Ricordiamo la nostra capacità di attacco DoS tramite mappatura HOST.

In presenza di alias SPN in conflitto, quando viene richiesto un ticket di servizio, viene individuato un SPN e viene creato un ticket di servizio. Dal punto di vista del DC, Kerberos ha funzionato; l’effetto DoS si verifica perché la risorsa stessa non è possibile decriptare il ticket, con conseguente KRB_AP_ERR_MODIFIED errore. Tuttavia, se creiamo un duplicato esatto di un SPN, il risultato è diverso.

In presenza di duplicati espliciti di SPN, quando viene richiesto un ticket di servizio, il DC individua due account a cui è associato l'SPN. In questo caso, il DC non può “scegliere” quale chiave va utilizzata per il biglietto e quindi restituisce un KDC_ERR_S_PRINCIPAL_UNKNOWN errore. Questa volta, il DC restituisce l'errore, indicando che l'autenticazione Kerberos non è andata a buon fine e costringendo il client a ricorrere all'autenticazione NTLM.

Ciò significa che, disponendo dell'autorizzazione WriteSPN su qualsiasi computer o account utente della foresta, oltre a poter causare un DoS completo su qualsiasi servizio mappato su HOST nella foresta, si potrebbe costringere qualsiasi servizio della foresta, mappato su HOST o meno, a utilizzare esclusivamente NTLM (a meno che non sia disabilitato, il che comporterebbe un DoS).

Dal punto di vista dell'utente, l'accesso sembra rimanere invariato (Figura 26, Figura 27).

La figura 28 illustra questo scenario.

ResetNightmare: E gli UPN?

Alla ricerca di un metodo diretto per l'escalation dei privilegi, mi sono concentrato sugli User Principal Names (UPN). Considerando che la verifica dell'unicità degli UPN è controllata dallo stesso meccanismo utilizzato per la verifica dell'unicità degli SPN, ho correttamente ipotizzato che potesse essere aggirata allo stesso modo (Figura 29).

La verifica dell’unicità è stata corretta insieme a una serie di altre vulnerabilità scoperte da Andrew Bartlett, in particolare l’attacco Dollar Ticket/noPac (CVE-2021-42287 + CVE-2021-42278), che consentiva a qualsiasi utente di ottenere istantaneamente i privilegi di amministratore di dominio. Poiché l’attacco sfruttava una confusione nella denominazione dei DC, speravo che KerberLoss potesse aprire la strada al ripristino di questa vulnerabilità o alla scoperta di una simile. Per questa e tutte le altre mie idee, dovevo capire se, e in tal caso come, Kerberos utilizzasse gli UPN.

Tipi di nomi Kerberos

In Kerberos, un identificatore di entità è costituito da un Realm e un PrincipalName. A PrincipalName è strutturato come segue:

PrincipalName   ::= SEQUENCE {
	   name-type       [0] Int32,
	   name-string     [1] SEQUENCE OF KerberosString
}

Il name-string Il campo specifica il nome come stringa Kerberos. Tuttavia, il name-string di per sé non è sufficiente per identificare un mandante. Il name-type Il campo specifica il tipo del nome, il che, in parole povere, significa quale attributo Si esamina innanzitutto questo campo per individuare il soggetto principale. Il protocollo Kerberos ([RFC4120], sezione 6.2) definisce diversi valori possibili per questo campo.

Active Directory utilizza solitamente il NT-PRINCIPAL tipo di nome utilizzato per identificare i client Kerberos, e corrisponde all'account SamAccountName. Quando si inviano richieste di Ticket Granting Ticket (TGT) Kerberos, è anche possibile utilizzare il NT-ENTERPRISE nome del tipo, che individua gli account in base al loro UserPrincipalName (UPN). Il nome effettivo del cliente nel ticket generato potrebbe essere SamAccountName (NT-PRINCIPAL) o l'UPN (NT-ENTERPRISE), e questo di solito è gestito dal Name-canonicalize bandiera.

Fortunatamente, strumenti Kerberos di uso comune come Rubeus e Impacket hanno già implementato la possibilità di specificare quale tipo di nome debba essere utilizzato nella richiesta TGT, quindi sono riuscito a richiedere i ticket con il NT-ENTERPRISE nome-tipo.

Tuttavia, quando ho provato a richiedere dei ticket utilizzando il mio UPN duplicato, il DC ha comunque tentato di autenticarmi come utente privilegiato, generando un errore di “pre-autenticazione fallita” (Figura 30).

Questo metodo ha funzionato per rimuovere l'UPN di DemoAdmin1 , ma richiederebbe il possesso dei permessi di scrittura sull'oggetto di destinazione, il che non è realistico ai fini dell'escalation dei privilegi (Figura 31).

Poco dopo, ho trovato una soluzione a questo problema: invece di aggirare la verifica dell'unicità dell'UPN utilizzando caratteri non filtrabili, posso semplicemente impostare il mio UPN su SamAccountName del mio obiettivo. Ciò è consentito, poiché le stringhe non sono identiche (Figura 32).

Ora, la richiesta di un ticket per DemoAdmin1 utilizzando la password di UPNUser non andrà a buon fine, come previsto. Tuttavia, modificando il tipo di nome in NT-ENTERPRISE, posso ottenere un biglietto intestato a DemoAdmin1 (Figura 33).

Questo metodo mi ha sostanzialmente permesso di ottenere un ticket con il nome di qualsiasi utente desiderassi. Sfruttandolo, ho cercato di individuare un’altra vulnerabilità di tipo “confusion”, ricorrendo a una serie di metodi, tra cui:

• Da AS-REQ standard a TGS-REQ
• Flusso dell'attacco "Dollar Ticket" modificato
• S4U2: Autolesionismo
• Abuso di Kerberos tramite U2U
• Attacco DoS all'accesso utente, come menzionato da Andrew Bartlett
• Attiva la modalità hard/soft match SyncJacking
• Priorità degli UPN tra domini

Tuttavia, tutti i miei tentativi di sfruttare gli UPN per ottenere un'escalation dei privilegi sono falliti. A seconda del metodo e dello strumento specifici utilizzati, continuavo a ricevere errori oppure un ticket indirizzato all'utente corretto, privo di privilegi. Ho approfondito questo comportamento per capirne il motivo.

La patch CVE-2021-42287

Come accennato in precedenza, la vulnerabilità "Dollar Ticket" causava una confusione nei nomi, simile a quella che stavo cercando di ottenere in questo caso. Microsoft ha risolto la vulnerabilità aggiungendo due importanti funzionalità a Kerberos:

• I TGT restituiti includeranno sempre un certificato di attributi privilegiati (PAC), anche se il client ha richiesto un ticket senza PAC.
• Il PAC nei TGT ora include un campo denominato PAC_REQUESTOR_SID, che contiene il SID del client che ha richiesto il ticket.

Questo PAC_REQUESTOR_SID valore deve per poi essere convalidato durante il TGS Exchange, rendendo così inefficace il vecchio vettore di attacco, in cui l'autore dell'attacco cancellava l'account che aveva richiesto il TGT, facendo credere al DC che il TGT appartenesse invece al DC con un nome simile.

Questa (eccellente) patch ha avuto l'effetto collaterale, un po' fastidioso, di invalidare tutti i miei tentativi di escalation dei privilegi tramite la tecnica della "UPN confusion". Il PAC ora conteneva sempre il mio SID originale e il DC ignorava completamente il nome del client presente nel mio ticket, basandosi esclusivamente sul SID come fonte di riferimento del ticket.

Proprio quando stavo per rinunciare all'escalation dei privilegi tramite gli UPN, ho deciso di dare un'ultima occhiata alla mia lista di idee relative agli abusi, verificando se ciascuna di esse potesse funzionare. È stato allora che mi sono imbattuto in qualcosa di interessante.

Una svolta: (ab)uso del protocollo Kerberos per la modifica della password

Per impostazione predefinita, ogni utente di Active Directory può modificare la propria password. Un metodo per farlo consiste nell’utilizzare il protocollo Kerberos Change Password and Set Password di Microsoft, che specifica come vengono eseguite le modifiche delle password tramite Kerberos. Il protocollo è estremamente semplice (l’RFC è lungo solo 7 pagine) e contiene un unico messaggio di richiesta e un unico messaggio di risposta.

Microsoft utilizza i termini “modifica password” e “imposta password” per distinguere, rispettivamente, il caso in cui un utente modifichi la propria password e quello in cui un amministratore imposti la password per un utente.

Il protocollo riceve i messaggi sulla porta 464 (kpasswd), con la struttura della richiesta illustrata nella Figura 34.

Le due parti principali di questo messaggio sono il messaggio KRB-PRIV e la struttura AP-REQ.

Il messaggio KRB-PRIV è essenzialmente solo un modo per inviare dati crittografati. Consente inoltre di includere dati personalizzati. Il protocollo sfrutta questa caratteristica, inserendo il valore della nuova password all’interno di questa struttura (Figura 35).

L'aspetto più interessante è la struttura AP-REQ. Questa struttura contiene un ticket e un autenticatore, che attesta il possesso legittimo del ticket, poiché è crittografato utilizzando la propria chiave di sessione (Figura 36).

Nella maggior parte dei casi, con Kerberos, una richiesta TGS_REQ/TGS_REP genera un ticket di servizio (e la corrispondente chiave di sessione). Questa risposta viene quindi utilizzata per costruire il messaggio AP_REQ, che viene inviato al servizio per dimostrare il possesso del ticket.

Nel caso del protocollo di modifica della password Kerberos, il ticket nella struttura AP-REQ deve avere come ambito il kadmin/changepw SPN. Tuttavia, si tratta di un SPN di proprietà dell'account krbtgt, e sappiamo che l'unica cosa che conta è la chiave di crittografia, quindi un biglietto per kadmin/changepw è semplicemente un TGT con l'SPN (sname) modificato.

Ciò significa che per modificare la password di un utente ci basta il suo TGT. Significa inoltre che la procedura che un utente deve seguire per modificare la propria password utilizzando Kerberos è quella illustrata nella Figura 37.

La cosa interessante è che questo flusso passa direttamente da un TGT-REQ a un AP-REQ, senza un TGS-REQ in mezzo. Ricordate la patch che abbiamo esaminato in precedenza: Il TGS-REQ è il luogo in cui il PAC_REQUESTOR_SID avviene la convalida.

Considerando che potevo già richiedere un TGT con qualsiasi nome utente (utilizzando il NT-ENTERPRISE nome tipo), se il PAC_REQUESTOR_SID Se la correzione non fosse stata implementata in questo caso, il protocollo potrebbe risultare potenzialmente vulnerabile.

Mettendo insieme tutte le conoscenze acquisite dai miei test precedenti, mi sono messo all’opera per fare un tentativo. Tenendo presente che, per impostazione predefinita, ogni utente in Active Directory dispone dei permessi necessari per modificare la propria password, la mia strategia di attacco era la seguente:

1. Un malintenzionato è riuscito a ottenere l'accesso a un utente denominato UPNUser, che non dispone di autorizzazioni speciali se non quella di modificare il proprio valore UPN.
2. L'autore dell'attacco imposta l'UPN dell'utente su SamAccountName dell'account in questione; ad esempio, DemoAdmin1.
   Questa operazione non richiede di aggirare i controlli di verifica dell'unicità dell'UPN. DemoAdmin1L'UPN effettivo dovrebbe essere DemoAdmin1@demo.lab, quindi impostando UPNUserl’UPN di… a semplicemente DemoAdmin1 è consentito (Figura 38).

3. L'autore dell'attacco richiede un TGT per kadmin/changepw specificando DemoAdmin1 come nome utente, NT-ENTERPRISE come tipo di nome, e Password dell'utente UPN.
4. Il DC restituisce un TGT_REP contenente un TGT per UPNUser (come indicato da PAC_REQUESTOR_SID nel PAC), ma con il nome utente DemoAdmin1(NT_ENTERPRISE), come Figura 39 spettacoli.

5. L'utilizzo di questo ticket per inviare una richiesta di modifica della password reimposterà la password di UPNUser. Per elevare i propri privilegi, l'autore dell'attacco modifica o cancella il valore UPN di UPNUser, in modo che nessun utente abbia più l'UPN indicato sul ticket.
6. Se si tenta di utilizzare questo ticket per una richiesta TGS_REQ dopo la modifica dell'UPN, si verificherà un KDC_ERR_TGT_REVOKED errore, dovuto al PAC_REQUESTOR_SID patch, che impedisce l'usurpazione d'identità. Tuttavia, utilizzando questo ticket per creare la richiesta di modifica della password, la modifica della password va a buon fine.
7. A questo punto, l'autore dell'attacco può richiedere un nuovo TGT per DemoAdmin1, senza specificando il NT-ENTERPRISE nome tipo. La richiesta ora funziona e il tipo di nome del ticket è NT-PRINCIPAL, a indicare che il biglietto appartiene al vero (SamAccountName) DemoAdmin1 utente (Figura 40).

Operazione riuscita! È bastato poter creare un UPN per compromettere il dominio.

Ho denominato questa vulnerabilità "ResetNightmare"; le è stato assegnato il codice CVE-2026-27912. La vulnerabilità consente a un malintenzionato, che disponga di autorizzazioni di scrittura generiche su qualsiasi oggetto utente o computer nel dominio oppure che sia in grado di creare oggetti utente o computer nel dominio (esclusa la quota MachineAccountQuota), di assumere il controllo completo del dominio.

La figura 41 illustra il flusso di exploit di ResetNightmare.

L'unico altro requisito è che la password dell'utente di destinazione sia stata in uso da un periodo di tempo sufficiente. Tuttavia, la durata minima predefinita della password in Active Directory è di 1 giorno, quindi è altamente probabile che la password dell'utente di destinazione soddisfi tale requisito.

Come bonus (grazie ad Andrea Pierini), questa vulnerabilità può anche essere combinata con la tecnica delle “Shadow Credentials”, consentendo un percorso di attacco più furtivo sfruttando account informatici con diritti di scrittura.

Ho inoltre creato uno strumento open source per la comunità, ResetNightmare, che implementa l’intero flusso di attacco di ResetNightmare, compresi diversi parametri per personalizzarne l’esecuzione. Lo strumento è scritto in PowerShell e utilizza Rubeus.exe e il modulo ActiveDirectory di PowerShell (Figura 42). Lo strumento è disponibile su GitHub.

Rilevamento e difesa contro KerberLoss e ResetNightmare

I clienti di Semperis Directory Services Protector (DSP) possono utilizzare i seguenti nuovi indicatori di sicurezza per individuare diverse configurazioni errate menzionate in questo articolo:

• La verifica dell'unicità dell'UPN o dell'SPN è disabilitata
• Oggetti contenenti caratteri Unicode nascosti
• Oggetti sospetti duplicati che utilizzano caratteri Unicode nascosti
• Entità principale non privilegiata in grado di impostare un nome di entità di servizio
• Entità principale non privilegiata in grado di impostare un nome di entità utente

Inoltre, i clienti di DSP possono individuare modifiche anomale agli SPN e agli UPN attraverso due indicatori di compromissione (IoC):

• È stato aggiunto un nome principale di servizio (Service Principal Name) in conflitto (CVE-2026-25177)
• È stato aggiunto un nome principale utente (User Principal Name) che corrisponde al nome dell'account SAM di un altro account (CVE-2026-27912)

In assenza di DSP, il modo migliore per rilevare l'uso improprio di entrambe le tecniche consiste nel configurare le SACL per monitorare le modifiche agli oggetti di Active Directory. Una volta configurate le SACL, è possibile utilizzare l'ID evento 5136 del registro di sicurezza (“È stato modificato un oggetto del servizio di directory”) sui DC per rilevare le modifiche che comportano l'impatto della vulnerabilità.

Per KerberLoss, la voce con ID evento 5136 indicherà l'aggiunta di un ServicePrincipalName in conflitto con uno già esistente (Figura 43).

Per ResetNightmare, la voce con ID evento 5136 indicherà l'aggiunta di un UserPrincipalName corrispondente a un SamAccountName (Figura 44).

La migliore misura preventiva contro queste vulnerabilità consiste nell'applicare le patch a tutti i DC. Microsoft ha rilasciato le patch per KerberLoss (CVE-2026-25177) a marzo 2026 e per ResetNightmare (CVE-2026-27912) ad aprile 2026.

Oltre all'applicazione delle patch, le organizzazioni dovrebbero attenersi al principio del privilegio minimo e monitorare eventuali aggiunte anomale di autorizzazioni non predefinite. Autorizzazioni più restrittive possono rendere più difficile lo sfruttamento di queste vulnerabilità.

Tempistica di divulgazione

• 26 novembre 2025: viene scoperta la vulnerabilità KerberLoss e segnalata all’MSRC.
• 17 dicembre 2025: ResetNightmare viene individuato e segnalato all'MSRC.
• 9 gennaio 2026: MSRC conferma che ResetNightmare funziona come segnalato.
• 17 gennaio 2026: l'MSRC conferma che KerberLoss funziona come riportato.
• 10 marzo 2026: Microsoft rilascia una patch per KerberLoss (CVE-2026-25177) nel corso del "Patch Tuesday", classificandola come una vulnerabilità "Importante" relativa all'elevazione dei privilegi.
• 14 aprile 2026: Microsoft rilascia una patch per ResetNightmare (CVE-2026-27912), classificata come vulnerabilità "Importante" relativa all'elevazione dei privilegi.

Ringraziamenti

Un ringraziamento speciale va ai seguenti ricercatori, che hanno fornito un grande stimolo a diverse parti di questa ricerca:

• Yossi Sassi (@Yossi_Sassi)
• Andrew Bartlett
• Elad Shamir (@elad_shamir)
• Charlie Clark (@exploitph)
• Will Schroeder (@harmj0y)
• Andrea Pierini (@decoder_it)
• Benjamin Delpy (@gentilkiwi)

Altre risorse

• Biblioteca di ricerca sulla sicurezza dell'identità di Semperis
• Catalogo delle minacce all'identità di Semperis

Esclusione di responsabilità

Questo contenuto è fornito solo a scopo educativo e informativo. Il suo scopo è quello di promuovere la consapevolezza e la correzione responsabile delle vulnerabilità di sicurezza che possono esistere sui sistemi di cui si è proprietari o che si è autorizzati a testare. È severamente vietato l'uso non autorizzato di queste informazioni per scopi malevoli, sfruttamento o accesso illegale. Semperis non approva né condona alcuna attività illegale e declina ogni responsabilità derivante dall'uso improprio del materiale. Inoltre, Semperis non garantisce l'accuratezza o la completezza dei contenuti e non si assume alcuna responsabilità per eventuali danni derivanti dal loro utilizzo.