ResetNightmare CVE-2026-27912, Kerberos Cambio Password, Active Directory: scrivere il proprio userPrincipalName basta per reimpostare un Domain Admin

Cos'è ResetNightmare CVE-2026-27912 Kerberos Cambio Password Active Directory

ResetNightmare CVE-2026-27912 Kerberos Cambio Password Active Directory: questa stringa indica un'unica falla, ed è il percorso più breve in un dominio tra l'accesso in scrittura su un account sacrificabile e una password di Domain Admin reimpostata. L'attaccante non viene mai a conoscenza della vecchia password della vittima, non fa mai relay di una credenziale e non craca mai un hash. Si limita a impostare una nuova password su un account su cui non gli è mai stato delegato alcun diritto.

La falla è stata scoperta dal ricercatore di Semperis Shai Laron e pubblicata nella ricerca Identity Crisis dell'azienda, insieme a una seconda vulnerabilità distinta che la stessa ricerca chiama KerberLoss (CVE-2026-25177). La descrizione del National Vulnerability Database è scarna: «Improper authorization in Windows Kerberos allows an authorized attacker to elevate privileges over an adjacent network.»

Quella frase nasconde la parte interessante. La «autorizzazione impropria» non è un controllo ACL mancante su un oggetto. È un controllo di identità che esiste, che funziona correttamente, e che semplicemente non viene mai raggiunto, perché il protocollo abusato prende una scorciatoia che salta esattamente il passaggio in cui vive quel controllo.

Come funziona, e perché conta l'assenza del TGS-REQ

Kerberos non ha un unico modo di nominare un principal, e Active Directory ne usa abitualmente due. NT-PRINCIPAL nomina un account tramite il suo sAMAccountName. NT-ENTERPRISE lo nomina tramite il suo userPrincipalName, l'UPN. Un client può inserire entrambe le forme in una AS-REQ, e il KDC la risolve in un account ed emette un ticket.

Gli attacchi che abusano di quell'ambiguità non sono nuovi. Nel novembre 2021 la catena noPac, CVE-2021-42278 e CVE-2021-42287, permetteva a un attaccante di rinominare un account che controllava affinché un ticket emesso per un'identità potesse essere riscattato come un'altra. La correzione Microsoft per CVE-2021-42287, KB5008380, rilasciata il 9 novembre 2021, ha aggiunto «nuove informazioni sul richiedente originale nei PAC dei Ticket-Granting Ticket (TGT) Kerberos», il buffer PAC Requestor. Il KDC lo usa, nelle parole stesse di Microsoft, quando «genera un ticket di servizio Kerberos», per verificare che «l'account che ha richiesto il TGT sia lo stesso account referenziato nel ticket di servizio».

Leggetelo con attenzione, perché ResetNightmare vive esattamente nella lacuna che questo lascia. Il SID PAC Requestor viene convalidato quando viene generato un ticket di servizio, durante lo scambio TGS-REQ.

Il protocollo Kerberos di cambio password non ha un TGS-REQ.

Definito nella RFC 3244 e servito sulla porta 464, kpasswd, il flusso di cambio password è deliberatamente breve. Un client ottiene un TGT, poi va direttamente a una AP-REQ contro il servizio di cambio password. Non c'è alcuno scambio intermedio di tipo ticket-granting, perché il client non sta richiedendo l'accesso a un servizio nel senso abituale del termine. Sta presentando la prova della propria identità per cambiare una password. Semperis descrive il flusso come diretto dalla richiesta del TGT a una AP-REQ, «senza un TGS-REQ nel mezzo».

Saltate il TGS-REQ, e con esso saltate la convalida del PAC Requestor. Nient'altro su quel percorso ri-deriva il SID del richiedente a partire dal ticket. Così, un TGT emesso perché un nome NT-ENTERPRISE si risolveva, in quel momento, nell'oggetto dell'attaccante, viene accettato da kpasswd come autorità sull'account a cui quel nome si risolve ora.

Il risultato si aggrava nel modo in cui si aggravano sempre i binding di identità rotti. L'attaccante imposta una password che conosce, su un account che non possiede, e ogni successivo accesso come quell'account è del tutto legittimo. Da confrontare con le shadow credentials, dove l'attaccante aggiunge una chiave anziché una password: stesso risultato, attributo diverso, ed entrambe smentiscono l'ipotesi secondo cui «l'attaccante deve comunque craccare qualcosa», su cui riposa ancora buona parte della modellazione dei percorsi di attacco Active Directory. Le due tecniche si combinano anche: Semperis attribuisce ad Andrea Pierini l'osservazione secondo cui ResetNightmare «può anche essere combinato con la tecnica Shadow Credentials, permettendo un percorso di attacco più furtivo abusando di account computer scrivibili».

La catena di attacco

Semperis pubblica la catena passo per passo. Il perno è lo stesso che faceva funzionare noPac: il nome portato dal ticket viene risolto due volte, e l'attaccante ne cambia la risoluzione nel mezzo. L'ordine seguente non è cosmetico: l'UPN deve essere rimosso prima del cambio password, non dopo, altrimenti l'attaccante reimposta solo la propria password.

Passo 1 — Puntare l'UPN di un account controllato verso la vittima

L'attaccante scrive lo sAMAccountName della vittima nel userPrincipalName di un account che già controlla, o che ha appena creato.

Set-ADUser -Identity 'controlledUser' -UserPrincipalName 'da-admin'

Passo 2 — Richiedere un TGT per kadmin/changepw tramite nome enterprise

L'attaccante richiede un TGT con ambito sullo SPN kadmin/changepw, usando il tipo di nome NT-ENTERPRISE, fornendo il nome utente della vittima e la password dell'account controllato. Quello SPN appartiene a krbtgt, quindi, come dice Semperis, «un ticket per kadmin/changepw non è altro che un TGT con lo SPN (sname) cambiato». Il KDC risolve il nome enterprise tramite l'UPN appena scritto, trova l'oggetto dell'attaccante, e restituisce un ticket che porta il nome della vittima ma il SID dell'attaccante in PAC_REQUESTOR_SID.

Passo 3 — Ritirare l'UPN, prima di toccare la password

Questo è il passo la cui posizione decide se la catena effettivamente scala. L'attaccante ora cambia o cancella l'UPN dell'account controllato, «senza lasciare alcun utente con l'UPN che compare sul ticket». Eseguire il cambio password mentre l'UPN è ancora in posizione, e il nome enterprise si risolve ancora nell'oggetto dell'attaccante stesso: Semperis è esplicito nel dire che farlo «reimposterà la password di UPNUser» e nulla più.

Passo 4 — Guidare il protocollo di cambio password

Il TGT già emesso viene usato per costruire una richiesta di cambio password tramite Kerberos, direttamente verso una AP-REQ sulla porta 464. Non viene emessa alcuna TGS-REQ, quindi il SID PAC Requestor non viene mai verificato, e la nuova password finisce sulla vittima reale. Semperis registra il contrasto con precisione: riutilizzare quello stesso ticket in una TGS-REQ dopo il cambio di UPN «risulterà in un errore KDC_ERR_TGT_REVOKED, a causa della patch PAC_REQUESTOR_SID, bloccando l'impersonificazione. Tuttavia, usando questo ticket per costruire la richiesta di cambio password, il cambio password funziona.»

Passo 5 — Autenticarsi come la vittima

Viene richiesto un nuovo TGT per il vero account vittima, usando la password che l'attaccante ha appena impostato e senza il tipo di nome NT-ENTERPRISE. Ritorna con il tipo di nome NT-PRINCIPAL, che è la prova che il ticket appartiene al vero titolare dello sAMAccountName. Da qui, l'attaccante possiede un'identità normale e pienamente valida.

Il proof of concept pubblico racchiude tutto questo in un'unica funzione PowerShell. Richiede il modulo ActiveDirectory e una copia di Rubeus, e il suo utilizzo pubblicato è un'unica chiamata:

Invoke-ResetNightmare -TargetAccount "victim" -TargetNewPassword "NewP@ssw0rd!" -UPNUser "controlledUser" -UPNUserPassword "ControlledP@ss!"

Chi può davvero eseguire questo attacco, e chi no

È qui che buona parte della copertura mediatica secondaria esagera la falla, quindi vale la pena citare direttamente la ricerca. Semperis afferma che la vulnerabilità «consente una completa presa di controllo del dominio da parte di un attaccante che dispone di permessi Generic Write su qualsiasi oggetto utente o computer del dominio, o che può creare oggetti utente o computer nel dominio (escludendo MachineAccountQuota)».

Due clausole di questa frase meritano enfasi, perché insieme fissano la vera soglia:

• Generic Write su qualsiasi oggetto utente o computer. Non sulla vittima. L'attaccante ha bisogno di accesso in scrittura su un oggetto che può puntare verso la vittima, il che nella maggior parte dei domini è una concessione molto più comune dell'accesso in scrittura su un account Tier 0.
• Escludendo MachineAccountQuota. Questo è il limite che separa ResetNightmare da noPac. La capacità predefinita di un utente autenticato di unire dieci macchine al dominio non è sufficiente qui, quindi «qualsiasi utente del dominio per impostazione predefinita» è il riassunto sbagliato di questo CVE.

Le stesse FAQ di Microsoft fissano l'altra metà della soglia, il vettore di attacco adiacente (AV:A): lo sfruttamento «richiede che l'attaccante si trovi nello stesso dominio Active Directory ristretto del sistema target». Al momento della pubblicazione, MSRC aveva anche classificato la falla come non divulgata pubblicamente, non sfruttata, e «Exploitation Less Likely» — una valutazione fatta nell'aprile 2026, prima che esistessero la pubblicazione e il proof of concept.

Esiste un'ulteriore precondizione. Semperis nota che «l'unico altro requisito è che la password dell'utente target deve essere sufficientemente datata», e osserva che l'età minima predefinita della password nella Default Domain Policy è di 1 giorno, quindi un vero account admin soddisferà quasi sempre questa condizione.

Rilevamento

L'indicatore principale citato dalla ricerca è l'Event ID 5136, «un oggetto del servizio di directory è stato modificato», filtrato sulle aggiunte di un userPrincipalName che corrisponde allo sAMAccountName di un account esistente. È una firma precisa e a basso rumore: in un dominio sano, un prefisso UPN non dovrebbe praticamente mai collidere con il nome di logon di un oggetto diverso.

Sul fronte password, aspettatevi 4723 piuttosto che 4724. Semperis separa direttamente le due operazioni del protocollo, notando che Microsoft usa i termini «change password» e «set password» «per differenziare tra un utente che cambia la propria password e un amministratore che imposta la password di un utente». ResetNightmare guida l'operazione di cambio — che è anche il motivo per cui l'età minima della password del target è una precondizione — quindi il domain controller registra il 4723, «è stato effettuato un tentativo di cambio della password di un account». L'evento 4724 copre il percorso di reset che segue un amministratore o un account helpdesk delegato. Vale la pena monitorarlo per sé stesso, ma non è l'artefatto lasciato da questo CVE.

La stessa collisione può essere cercata retrospettivamente nello stato della directory, cosa che vale la pena fare una volta anche se l'auditing era disattivato:

# Ogni prefisso UPN che collide con lo sAMAccountName di un oggetto diverso
$sam = @{}
Get-ADObject -LDAPFilter '(|(objectClass=user)(objectClass=computer))' -Properties sAMAccountName |
    ForEach-Object { if ($_.sAMAccountName) { $sam[$_.sAMAccountName] = $_.DistinguishedName } }

Get-ADUser -Filter 'userPrincipalName -like "*"' -Properties userPrincipalName |
    Where-Object {
        $prefix = ($_.UserPrincipalName -split '@')[0]
        $sam.ContainsKey($prefix) -and $sam[$prefix] -ne $_.DistinguishedName
    } | Select-Object SamAccountName, UserPrincipalName, DistinguishedName

Rimedio

1. Dimostrate la patch, non datela per scontata. Semperis è esplicito: «la migliore prevenzione per queste vulnerabilità è patchare tutti i DC». Un singolo DC non patchato, o offline da tempo, mantiene il dominio sfruttabile, quindi enumerate i numeri di build invece di fidarvi di una dashboard di conformità.

Get-ADDomainController -Filter * | Select-Object HostName, OperatingSystem,
    @{n='Build';e={ (Get-CimInstance Win32_OperatingSystem -ComputerName $_.HostName).Version }}

2. Rimuovete la delega di reset password al di fuori del Tier 0. La seconda raccomandazione della ricerca è che «le organizzazioni dovrebbero attenersi al principio del privilegio minimo e monitorare aggiunte anomale di permessi non predefiniti». Il diritto da controllare è il diritto esteso User-Force-Change-Password, documentato da Microsoft con il nome visualizzato «Reset Password» e il Rights-GUID 00299570-246d-11d0-a768-00aa006e0529.

$resetPwd = [guid]'00299570-246d-11d0-a768-00aa006e0529'
Get-ADUser -Filter * -SearchBase (Get-ADDomain).DistinguishedName | ForEach-Object {
    $dn = $_.DistinguishedName
    (Get-Acl "AD:$dn").Access |
        Where-Object { $_.ObjectType -eq $resetPwd -and $_.AccessControlType -eq 'Allow' } |
        Select-Object @{n='Target';e={$dn}}, IdentityReference, ActiveDirectoryRights
}

3. Limitate chi può creare account. Poiché l'attacco funziona per un attaccante in grado di creare oggetti utente o computer al di fuori del MachineAccountQuota, rivedete i diritti Create Child delegati sulle OU. Una delega concessa anni fa per un helpdesk o uno strumento di deployment è il riscontro tipico qui, ed è la stessa classe di concessione obsoleta trattata nell'audit delle ACE pericolose e dei SID orfani.

4. Attivate l'auditing che rende visibile il passo 1 della catena. Abilitate Audit Directory Service Changes e configurate le SACL affinché le scritture di userPrincipalName su oggetti utente e computer generino il 5136.

5. Non date nulla per scontato sulla finestra di esposizione. La patch è di aprile 2026 e la PoC è ora pubblica. Se un DC è rimasto indietro, trattate i cambi password privilegiati in quell'intervallo come sospetti: rivedete gli eventi 4723 sui target Tier 0, insieme ai 4724 per il percorso di reset delegato, e confermate che ciascuno corrisponda a un vero ticket helpdesk. La checklist di igiene più ampia sull'audit della sicurezza di Active Directory e la revisione Tier 0 su account privilegiati, Protected Users e delega si applicano entrambe direttamente.

Semperis non indica alcuna mitigazione oltre al patching e al privilegio minimo, e questo limite merita di essere dichiarato con chiarezza. L'appartenenza a Protected Users in particolare non dovrebbe essere considerata un blocco per questo attacco: le protezioni che Microsoft documenta per quel gruppo bloccano NTLM, vietano DES e RC4 nella pre-autenticazione Kerberos, vietano la delega vincolata e non vincolata e limitano la durata del TGT, e nessuna di queste è ciò che fallisce qui. La falla sta nel modo in cui il KDC associa un'identità durante lo scambio di cambio password, il che spiega anche perché le misure di hardening mirate al furto di ticket, come la pulizia della delega Kerberos o la rotazione della password krbtgt, sono utili per altre ragioni ma irrilevanti per il CVE-2026-27912.

Come EtcSec rileva questo attacco

ResetNightmare è un problema che si risolve una volta per tutte con la patch, ma il suo prerequisito è un problema di permessi che sopravvive a qualsiasi singolo CVE. EtcSec audita esattamente questa superficie.

ACL_USER_FORCE_CHANGE_PASSWORD e ACL_FORCECHANGEPASSWORD enumerano ogni principal che detiene il diritto esteso Reset Password, e ACL_GENERICALL fa emergere le concessioni di scrittura generica che permettono a un attaccante di riscrivere per primo lo userPrincipalName di un altro oggetto.

Per i team che lavorano su una baseline di conformità, ANSSI_R12_1_FORCE_PWD_RESET_PRIVS segnala lo User-Force-Change-Password concesso al di fuori degli account di sistema, e ANSSI_R12_2_USER_RESTRICTIONS_PRIVS fa lo stesso per User-Account-Restrictions. Entrambi rispondono alla domanda «chi può agire su questo account» che il CVE-2026-27912 trasforma in compromissione del dominio. Domain controller più datati alzano ulteriormente la posta, il che spiega perché la fine del supporto di Windows Server 2016 conta qui.

Fonti

• MSRC — CVE-2026-27912, Windows Kerberos Elevation of Privilege Vulnerability
• NVD — CVE-2026-27912
• Semperis — Identity Crisis: novel vulnerabilities leading to Kerberos downgrade, DoS and full domain takeover
• Semperis-Community/ResetNightmare (proof of concept)
• Microsoft — KB5008380 authentication updates (CVE-2021-42287)
• Microsoft — User-Force-Change-Password extended right
• Microsoft — Event 4723, an attempt was made to change an account's password
• Microsoft — Event 4724, an attempt was made to reset an account's password
• Microsoft — Protected Users security group
• Microsoft — Minimum password age