SPN Duplicato Active Directory, Abuso WriteSPN, Downgrade Kerberos: Dentro CVE-2026-25177 (KerberLoss)

SPN duplicato Active Directory, abuso WriteSPN, downgrade Kerberos — tre problemi che la maggior parte dei team AD tiene su tre ticket separati sono confluiti in uno solo il 10 March 2026, quando Microsoft ha rilasciato la correzione per CVE-2026-25177. Il ricercatore Semperis Shai Laron, che l'ha segnalata, l'ha chiamata KerberLoss. In breve: un principal a basso privilegio con il diritto di scrivere un attributo su un oggetto poteva interrompere Kerberos per qualsiasi servizio mappato su HOST nell'intera foresta — e, con un secondo giro dello stesso trucco, spingere silenziosamente i client di qualsiasi servizio verso NTLM.

Ciò che rende questo un problema di rilevamento piuttosto che di patching è la tecnica di bypass. L'SPN duplicato che interrompe il servizio non è un duplicato byte per byte. Collide soltanto a livello Kerberos. Ogni strumento a cui il tuo runbook fa ricorso — setspn -X, l'indice di unicità a livello di foresta, l'evento Directory Services che si attiva quando un duplicato viene bloccato — confronta le stringhe per uguaglianza, ed è esattamente l'uguaglianza che l'attaccante aggira.

Cos'è un SPN Duplicato in Active Directory

Un Service Principal Name è la stringa che un client Kerberos usa per chiedere al KDC un ticket per una specifica istanza di servizio — cifs/fileserver.corp.local, http/intranet, MSSQLSvc/db01:1433. Risiede nell'attributo multi-valore servicePrincipalName dell'account utente o computer con cui il servizio viene eseguito. Quando un client vuole comunicare con un servizio, costruisce l'SPN, chiede al KDC un ticket di servizio, e il KDC cifra quel ticket con la chiave a lungo termine dell'account che detiene l'SPN — la stessa chiave la cui compromissione consente la contraffazione di un Silver Ticket.

Questo schema funziona solo se la mappatura da SPN ad account è una funzione. Microsoft lo afferma esplicitamente: "A meno che un servizio non utilizzi l'account computer e l'SPN HOST, gli SPN devono essere univoci nella foresta AD DS. In un ambiente multi-foresta, l'SPN deve essere univoco in tutte le foreste associate" e "Un SPN può essere associato a un solo account" (Kerberos Generates KDC_ERR_S_PRINCIPAL_UNKNOWN or KDC_ERR_PRINCIPAL_NOT_UNIQUE Error).

Quando due account rivendicano lo stesso SPN, il KDC non ha alcun criterio per scegliere una chiave. Il riferimento agli eventi Kerberos di Microsoft documenta un codice di errore dedicato per questa condizione, 0x8 KDC_ERR_PRINCIPAL_NOT_UNIQUE, descritto come "Più voci principal nel database KDC… Questo errore si verifica se esistono nomi principal duplicati. Nomi principal univoci sono fondamentali per garantire l'autenticazione reciproca."

C'è un secondo livello che conta qui. Gli account computer ricevono automaticamente un SPN HOST, e un elenco documentato di classi di servizio vi ricade come fallback. Il riferimento setspn di Microsoft le elenca — cifs, http, www, wins, spooler, rpcss, dns, netlogon e circa quaranta altre — e afferma chiaramente la regola di precedenza: "Questi SPN sono riconosciuti per gli account computer se il computer ha un SPN host. A meno che non siano esplicitamente collocati sugli oggetti, un SPN host può sostituire uno qualsiasi degli SPN menzionati." L'equivalenza stessa è espressa nell'attributo sPNMappings (CN=SPN-Mappings, ID attributo 1.2.840.113556.1.4.1347) sull'oggetto NTDS Service, che Microsoft descrive come contenente "un elenco di nomi principal di servizio (SPN) per mostrare l'equivalenza dei tipi di SPN."

Semperis ha condensato la conseguenza in una frase: "L'algoritmo di ricerca SPN cerca sempre prima un SPN esplicito. L'algoritmo cerca l'alias mappato dell'SPN solo se non viene trovato un SPN esplicito."

Un SPN esplicito, ovunque nella foresta, prevale su una mappatura HOST. Questa è la leva.

SPN Duplicato Active Directory, Abuso WriteSPN, Downgrade Kerberos: Come Funziona KerberLoss

Dai tempi di Windows Server 2012 R2, i domain controller rifiutano di creare un duplicato. Il riferimento Microsoft SPN and UPN uniqueness documenta il flusso: il DC interroga l'indice servicePrincipalName a livello di foresta — su un Global Catalog, o localmente se il DC stesso è un GC — e "If entries returned != 0 -> write fails." Il chiamante riceve l'errore esteso 8647 / 0x21C7 ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST (per gli UPN è 8648 / 0x21C8), e il DC scrive l'evento ID 2974, origine ActiveDirectory_DomainService, nel log Directory Services — un evento che indica il valore bloccato e elenca fino a dieci oggetti che già lo detengono.

Lo stesso riferimento nota che questo controllo viene eseguito anche quando un SPN viene rigenerato anziché scritto direttamente. Modificare dNSHostName, sAMAccountName, msDS-AdditionalDnsHostName, msDS-AdditionalSamAccountName, serverReferenceBL o userAccountControl fa sì che AD elimini i vecchi SPN e ne costruisca di nuovi, e "se uno qualsiasi dei nuovi valori SPN è un duplicato, la modifica fallisce."

Semperis fa risalire l'attuale set di tre controlli — unicità UPN, unicità SPN e unicità alias SPN — alla patch Microsoft del 2021 per CVE-2021-42282. Il controllo sull'alias è quello che KerberLoss di fatto elude.

È un controllo solido. Confronta stringhe.

La ricerca di Semperis ha attaccato proprio il confronto stesso. Testando 385 caratteri Unicode invisibili, Laron ha scoperto che solo 106 erano filtrabili tramite query LDAP standard; il resto viene trattato come spazio bianco oppure, nelle parole di Semperis, "completamente ignorato dal DC." Inserendo uno di questi in una stringa SPN, l'indice di unicità non rileva più una corrispondenza — "utilizzando un carattere invisibile e non filtrabile e inserendolo nella stringa, NotAdmin riesce ad aggiungere l'SPN in conflitto."

Le FAQ dell'advisory di Microsoft per CVE-2026-25177 descrivono la stessa catena e il suo esito:

MSRC l'ha valutata CVSS 3.1 base 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, temporale 7.7), gravità Important, classificata CWE-641 (Improper Restriction of Names for Files and Other Resources), con titolo Active Directory Domain Services Elevation of Privilege Vulnerability. Né MSRC né Semperis documentano cosa faccia internamente, nella pratica, la modifica al codice di March 2026 — è opportuno trattare la correzione come opaca e verificarla tramite il numero di build del DC, non tramite il comportamento osservato.

Il permesso su cui poggia tutto il meccanismo è tutt'altro che eccezionale. Sugli oggetti computer è la scrittura convalidata che Microsoft chiama "Validated write to service principal name" (CN=Validated-SPN, Rights-GUID f3a64788-5306-11d1-a9c5-0000f80367c1), delegabile in ADUC ed esplicitamente menzionata nella documentazione setspn: "È inoltre possibile delegare il permesso assegnando il permesso Validated write to service principal name all'utente o al gruppo desiderato." Su qualsiasi oggetto, GenericAll, GenericWrite, o WriteProperty su servicePrincipalName svolgono lo stesso compito. È la stessa classe di appiglio basato sulla scrittura di attributi che alimenta le Shadow Credentials tramite msDS-KeyCredentialLink — e, secondo Semperis, WriteSPN "su qualsiasi account computer o utente nella foresta" era sufficiente.

La Catena d'Attacco

Passo 1 — Ottenere un Oggetto Scrivibile

L'attaccante ha bisogno di accesso in scrittura a servicePrincipalName su un account. Può trattarsi di un diritto helpdesk delegato, di un gruppo service-desk obsoleto, di una delega OU troppo ampia — oppure di un oggetto computer creato dall'attaccante stesso, dato che ms-DS-MachineAccountQuota consente per impostazione predefinita a qualsiasi utente di dominio di unire dieci computer e il creatore ottiene diritti di scrittura su ciò che ha creato.

Passo 2 — Identificare un Target Mappato su HOST

Il target è qualsiasi servizio che si affida all'SPN HOST automatico anziché a uno esplicito — condivisioni file (cifs), IIS (http/www), stampa (spooler), e il resto dell'elenco documentato. Sono esattamente i servizi che non hanno un SPN esplicito a difendere la propria rivendicazione.

Elenca gli SPN registrati di un target — se cifs/SERVERB è assente, il servizio si appoggia alla mappatura HOST e può essere anticipato:

setspn -L SERVERB

Passo 3 — Piazzare l'SPN in Collisione

L'attaccante scrive cifs/SERVERB sul proprio oggetto controllato, con un code point invisibile incorporato in modo che l'indice a livello di foresta veda una stringa diversa. Il controllo di unicità passa. Non viene restituito alcun errore 8647. Non viene scritto alcun evento 2974, perché dal punto di vista del DC non è stato bloccato nulla.

Passo 4 — Il Servizio si Interrompe, Rumorosamente

I client ora richiedono cifs/SERVERB, e il KDC trova un SPN esplicito che prevale sulla mappatura HOST di SERVERB. Emette un ticket — sigillato con la chiave dell'account dell'attaccante. SERVERB non riesce a decifrarlo e lo rifiuta con 0x29 KRB_AP_ERR_MODIFIED, documentato da Microsoft come "I dati di autenticazione sono stati cifrati con la chiave sbagliata per il server di destinazione."

Nota cosa non è successo. Dal punto di vista del KDC la richiesta è andata a buon fine: è stato chiesto un ticket, è stato emesso un ticket. Non c'è alcun fallimento Kerberos da cui ripiegare, e quindi nessun fallback NTLM — solo un servizio che ha smesso di funzionare. Semperis riporta utenti che vedono messaggi come "Il nome di rete specificato non è più disponibile.", "Il nome dell'account di destinazione non è corretto." oppure "Impossibile trovare il percorso 'percorso' perché non esiste.", con l'accesso ripristinato nel momento in cui l'SPN malevolo viene rimosso.

Passo 5 — La Stessa Scrittura, un Esito più Silenzioso: NTLM

Il downgrade è un uso diverso dello stesso permesso. Invece di anticipare una mappatura HOST, l'attaccante duplica un SPN che esiste già in modo esplicito. Ora il KDC trova due account che lo detengono, non può scegliere una chiave e — nei test di Semperis — restituisce KDC_ERR_S_PRINCIPAL_UNKNOWN. Si tratta di un vero fallimento Kerberos, esattamente ciò di cui un client Windows ha bisogno per ripiegare su NTLM.

Questa è la variante di cui preoccuparsi davvero. Secondo Semperis funziona contro qualsiasi servizio nella foresta, mappato su HOST o no, e "Dal punto di vista dell'utente, l'accesso normale sembra apparentemente mantenuto." Nessuno apre un ticket di supporto. Nel frattempo tutto ciò che è costruito sul presupposto che Kerberos sia il percorso di autenticazione — ogni difesa anti-relay saltata perché "siamo Kerberos-only" — finisce per poggiare invece sui controlli anti-relay NTLM. Dove NTLM è stato disabilitato, lo stesso duplicato produce un'interruzione del servizio anziché un downgrade.

Passo 6 — Oppure: Dirottare la Delega di Qualcun Altro

Semperis dimostra un terzo utilizzo, l'SPN-jacking, adattato dall'analisi originale di Elad Shamir. Un attaccante che ha compromesso un account configurato per la delega vincolata, e detiene WriteSPN su un account che controlla, piazza l'SPN del servizio intermedio su quell'account ed esegue l'intero flusso S4U — ottenendo un ticket sigillato con la propria chiave. La versione di Shamir richiedeva anche WriteSPN sull'account che deteneva l'SPN target, per rimuoverlo prima; KerberLoss elimina questo requisito. Se il tuo ambiente esegue ancora i pattern di delega trattati in Attacchi di delega Kerberos, quello è il percorso da rivedere per primo.

Rilevamento

Si parte da un fatto scomodo: gli eventi che normalmente segnalano un SPN duplicato sono proprio quelli che questa tecnica è costruita per evitare.

L'evento 5136 è dove questo viene catturato. Microsoft lo documenta come generato "ogni volta che un oggetto Active Directory viene modificato", e porta esattamente i campi necessari: ObjectDN, ObjectClass, AttributeLDAPDisplayName, AttributeValue, OperationType (%%14674 Value Added, %%14675 Value Deleted) e SubjectUserSid/SubjectUserName di chi ha effettuato la scrittura.

Due prerequisiti, entrambi facili da sbagliare. La sottocategoria Audit Directory Service Changes deve essere abilitata, e l'oggetto ha bisogno di una SACL corrispondente: "Per generare questo evento, l'oggetto modificato deve avere una voce appropriata nella SACL: l'auditing dell'azione 'Write' per attributi specifici." Senza la SACL, la sola sottocategoria non produce nulla.

Ogni scrittura SPN, con l'identità del principal che l'ha effettuata:

$xpath = "*[System[EventID=5136]] and *[EventData[Data[@Name='AttributeLDAPDisplayName']='servicePrincipalName']]"
Get-WinEvent -LogName Security -FilterXPath $xpath -MaxEvents 500 |
  ForEach-Object {
    $x = [xml]$_.ToXml()
    [pscustomobject]@{
      Time      = $_.TimeCreated
      Actor     = ($x.Event.EventData.Data | Where-Object Name -eq 'SubjectUserName').'#text'
      Target    = ($x.Event.EventData.Data | Where-Object Name -eq 'ObjectDN').'#text'
      Operation = ($x.Event.EventData.Data | Where-Object Name -eq 'OperationType').'#text'
      Value     = ($x.Event.EventData.Data | Where-Object Name -eq 'AttributeValue').'#text'
    }
  }

-- Microsoft Sentinel: scritture SPN da principal non Tier-0.
-- I campi attributo dell'evento 5136 NON sono mappati sulle colonne SecurityEvent
-- (verifica il riferimento della tabella) — estraili dall'XML grezzo di EventData.
SecurityEvent
| where EventID == 5136
| extend Attribute = extract(@'Name="AttributeLDAPDisplayName">([^<]*)<', 1, EventData),
         SpnValue  = extract(@'Name="AttributeValue">([^<]*)<', 1, EventData),
         ObjectDN  = extract(@'Name="ObjectDN">([^<]*)<', 1, EventData),
         Operation = extract(@'Name="OperationType">%%(\d+)<', 1, EventData)
| where Attribute =~ "servicePrincipalName"
| where Operation == "14674"               // Value Added
| where SubjectUserName !in ("svc_scom$", "svc_sccm$")
| project TimeGenerated, Computer, SubjectUserName, ObjectDN, SpnValue
| order by TimeGenerated desc

Cercare Direttamente il Carattere Invisibile

Questo è il controllo che non dipende dal catturare la scrittura. Qualsiasi SPN che contenga un code point al di fuori dell'ASCII stampabile è anomalo — gli SPN legittimi sono hostname, classi di servizio, porte e nomi di istanza.

Get-ADObject -LDAPFilter '(servicePrincipalName=*)' -Properties servicePrincipalName -ResultPageSize 500 |
  ForEach-Object {
    $dn = $_.DistinguishedName
    foreach ($spn in $_.servicePrincipalName) {
      if ($spn -notmatch '^[\x20-\x7E]+$') {
        [pscustomobject]@{
          DistinguishedName = $dn
          SPN               = $spn
          CodePoints        = ($spn.ToCharArray() | ForEach-Object { '{0:X4}' -f [int]$_ }) -join ' '
        }
      }
    }
  }

Esegui comunque la ricerca dei duplicati a livello di byte — cattura le configurazioni errate ordinarie e l'attaccante poco sofisticato:

setspn -X -F -P
setspn -T * -T contoso -X

Attivare la Telemetria TGS che Probabilmente non Hai

Il riferimento Microsoft per l'evento 4769 afferma che alcuni fallimenti "vengono segnalati solo se si imposta il valore della chiave di registro KdcExtraLogLevel", con 0x01: Audit SPN unknown errors. Il riferimento al registro del KDC documenta il valore predefinito come 2 — il che significa che il bit 0x1 è disattivato, e i fallimenti KDC_ERR_S_PRINCIPAL_UNKNOWN non vengono scritti nel log Security su un DC predefinito. Il fallimento esatto prodotto da un SPN duplicato è, per impostazione predefinita, invisibile.

Su ogni DC, mantieni la registrazione PKINIT predefinita (0x2) e aggiungi l'auditing SPN-unknown (0x1) — cioè 3:

$k = 'HKLM:\SYSTEM\CurrentControlSet\Services\Kdc'
New-Item -Path $k -Force | Out-Null
Set-ItemProperty -Path $k -Name 'KdcExtraLogLevel' -Value 3 -Type DWord
Get-ItemProperty -Path $k -Name 'KdcExtraLogLevel'

Aspettati un volume elevato, e fai un baseline per una settimana prima di attivare gli alert. Microsoft avverte che i fallimenti 0x20 (ticket scaduti) sono rumore di fondo ordinario; i fallimenti SPN-unknown sono più rari ma non pari a zero in una foresta sana.

Rimedio

1. Applica la patch ai domain controller. La correzione è inclusa nell'aggiornamento di sicurezza di March 2026 — il rollup mensile su Server 2012 e 2012 R2. MSRC elenca quanto segue per ogni SKU di server:

Dove MSRC elenca due pacchetti per uno SKU — Server 2022 e Server 2025 — il secondo è il pacchetto hotpatch (KB5078737 e KB5078736), che si applica solo alle installazioni abilitate per hotpatch. Verifica quale si applica alla tua build esatta prima del deployment. La vulnerabilità è corretta sul DC, non sui server membri — una flotta completamente patchata con un solo DC non patchato elabora comunque le scritture attraverso il percorso non corretto.

2. Scopri chi può scrivere SPN. Questo è il permesso di cui l'intero attacco ha bisogno, e nella maggior parte delle foreste nessuno l'ha mai enumerato. La query sottostante riporta i principal non amministrativi che detengono Validated-SPN, scrittura diretta sull'attributo servicePrincipalName, o scrittura generica su qualsiasi oggetto computer.

$validatedSpn = [guid]'f3a64788-5306-11d1-a9c5-0000f80367c1'
$schemaNC     = (Get-ADRootDSE).schemaNamingContext
$spnAttrGuid  = [guid](Get-ADObject -SearchBase $schemaNC `
                  -LDAPFilter '(lDAPDisplayName=servicePrincipalName)' `
                  -Properties schemaIDGUID).schemaIDGUID

Get-ADComputer -Filter * -ResultPageSize 500 | ForEach-Object {
  $dn = $_.DistinguishedName
  (Get-Acl "AD:$dn").Access |
    Where-Object {
      $_.AccessControlType -eq 'Allow' -and
      ($_.ObjectType -eq $validatedSpn -or $_.ObjectType -eq $spnAttrGuid -or
       $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite')
    } |
    Where-Object { $_.IdentityReference -notmatch 'SYSTEM|Domain Admins|Enterprise Admins|Administrators' } |
    ForEach-Object {
      [pscustomobject]@{ Object = $dn; Principal = $_.IdentityReference; Rights = $_.ActiveDirectoryRights }
    }
}

Rimuovi ciò che non è giustificato. Presta particolare attenzione alle deleghe concesse a gruppi ampi (Authenticated Users, Domain Users, gruppi helpdesk legacy) e ai principal che detengono diritti su oggetti computer Tier 0.

3. Riduci il pool di oggetti controllabili dall'attaccante. Imposta ms-DS-MachineAccountQuota a 0 e concedi invece il join delle macchine tramite un gruppo delegato. Questo non corregge CVE-2026-25177, ma elimina il modo più semplice con cui un utente ordinario può ottenere un oggetto che controlla interamente.

4. Fai in modo che il downgrade non approdi da nessuna parte. Kerberos che fallisce è un problema di resilienza; Kerberos che fallisce verso NTLM è un problema di sicurezza. Richiedi la firma SMB, applica la firma LDAP e il channel binding, e inizia a limitare NTLM dove puoi — il percorso di audit è trattato in Attacchi NTLM relay, e il problema gemello del downgrade di cifratura in Fallback Kerberos RC4.

5. Strumenta, poi verifica. Abilita Audit Directory Service Changes, aggiungi una SACL che sottoponga ad audit le scritture su servicePrincipalName nelle tue OU di computer e account di servizio, imposta KdcExtraLogLevel a 3, e pianifica come job ricorrente la scansione degli SPN non-ASCII descritta sopra. Poi conferma che la pipeline funzioni end-to-end scrivendo un SPN benigno su un oggetto di test e verificando che l'evento 5136 raggiunga il tuo SIEM — una policy di audit che non produce eventi appare identica a una foresta priva di attacchi.

6. Rivedi la falla correlata. La stessa ricerca Semperis ha divulgato CVE-2026-27912 (ResetNightmare), un problema relativo a userPrincipalName e al Kerberos Change Password, corretto il 14 April 2026. Se stai applicando solo ora la patch di marzo, stai applicando solo ora anche quella di aprile. Entrambe sono documentate nell'analisi di Semperis.

Come EtcSec Rileva Questo Problema

L'audit Active Directory di EtcSec mappa direttamente le precondizioni di cui questo attacco ha bisogno, così puoi rispondere a "siamo esposti?" senza dover scrivere tu stesso le query viste sopra.

WRITESPN_ABUSE enumera i principal che detengono accesso in scrittura a servicePrincipalName — l'unico permesso che CVE-2026-25177 trasforma in una negazione di servizio a livello di foresta. DUPLICATE_SPN e COMPUTER_DUPLICATE_SPN fanno emergere i valori SPN rivendicati da più di un oggetto, i duplicati byte-identici che interrompono Kerberos, che siano stati piazzati da un attaccante o da una migrazione. COMPUTER_WITH_SPNS inventaria quali oggetti computer portano SPN espliciti, il che permette di distinguere un servizio che difende il proprio nome da uno che dipende dalla mappatura HOST e che quindi può essere anticipato. DELEGATION_UNKNOWN_TARGET segnala le configurazioni di delega vincolata che puntano a SPN che non si risolvono correttamente — la condizione di cui l'SPN-jacking ha bisogno.

Insieme, questi quattro controlli ricostruiscono la superficie di attacco: chi può scrivere, cosa è già in collisione, quali servizi dipendono da HOST, e dove la delega sta puntando dove non dovrebbe. Per la revisione più ampia in cui questo si inserisce, vedi come auditare la sicurezza di Active Directory, e per il classico problema di esposizione SPN, Rilevamento e prevenzione del Kerberoasting.

Fonti

• Microsoft Security Response Center — CVE-2026-25177, Active Directory Domain Services Elevation of Privilege Vulnerability (CVSS 3.1 8.8, CWE-641, rilasciata il 10 March 2026)
• Semperis — Identity Crisis: Novel Vulnerabilities Leading to Kerberos Downgrade, DoS, and Full Domain Takeover, Shai Laron, 5 August 2026
• Microsoft Learn — SPN and UPN uniqueness (event 2974, errori 8647/8648)
• Microsoft Learn — Kerberos Generates KDC_ERR_S_PRINCIPAL_UNKNOWN or KDC_ERR_PRINCIPAL_NOT_UNIQUE Error
• Microsoft Learn — setspn (classi di servizio mappate su HOST, -X, -F, delega Validated-SPN)
• Microsoft Learn — Validated-SPN validated write (Rights-GUID f3a64788-5306-11d1-a9c5-0000f80367c1)
• Microsoft Learn — SPN-Mappings attribute
• Microsoft Learn — 5136(S) A directory service object was modified
• Microsoft Learn — 4769(S, F) A Kerberos service ticket was requested (tabella dei codici di fallimento)
• Microsoft Learn — Registry entries about Kerberos protocol and KDC (KdcExtraLogLevel, valore predefinito 2)
• Microsoft Learn — Azure Monitor Logs reference: SecurityEvent (elenco colonne dietro la query Sentinel)
• Semperis — SPN-jacking: An Edge Case in WriteSPN Abuse, Elad Shamir