SPN Dupliqué Active Directory, Abus WriteSPN, Downgrade Kerberos : au cœur de CVE-2026-25177 (KerberLoss)

SPN dupliqué Active Directory, abus WriteSPN, downgrade Kerberos — trois problèmes que la plupart des équipes AD suivent sur trois tickets distincts se sont télescopés en un seul le 10 mars 2026, quand Microsoft a publié le correctif de CVE-2026-25177. Le chercheur Semperis Shai Laron, qui l'a signalée, l'a baptisée KerberLoss. En résumé : un principal faiblement privilégié détenant le droit d'écrire un attribut sur un seul objet pouvait casser Kerberos pour n'importe quel service mappé sur HOST dans la forêt — et, avec un second tour de la même astuce, faire basculer silencieusement les clients de n'importe quel service vers NTLM.

Ce qui fait de ceci un problème de détection plutôt qu'un problème de patch, c'est la technique de contournement. Le SPN dupliqué qui casse le service n'est pas un doublon octet pour octet. Il n'entre en collision qu'au niveau de la couche Kerberos. Tous les outils que votre runbook mobilise — setspn -X, l'index d'unicité à l'échelle de la forêt, l'événement Directory Services déclenché quand un doublon est bloqué — comparent des chaînes de caractères par égalité, et c'est précisément cette égalité que l'attaquant contourne.

Qu'est-ce qu'un SPN dupliqué dans Active Directory

Un Service Principal Name est la chaîne qu'un client Kerberos utilise pour demander au KDC un ticket pour une instance de service spécifique — cifs/fileserver.corp.local, http/intranet, MSSQLSvc/db01:1433. Il réside dans l'attribut multivalué servicePrincipalName du compte utilisateur ou ordinateur sous lequel s'exécute le service. Quand un client veut communiquer avec un service, il construit le SPN, demande un ticket de service au KDC, et le KDC chiffre ce ticket avec la clé à long terme du compte détenant le SPN — la même clé dont la compromission permet la forge de Silver Ticket.

Cette conception ne fonctionne que si l'association entre SPN et compte est une fonction. Microsoft l'indique explicitement : « Sauf si un service utilise le compte ordinateur et le SPN HOST, les SPN doivent être uniques dans la forêt AD DS. Dans un environnement multi-forêt, le SPN doit être unique sur l'ensemble des forêts associées » et « Un SPN ne peut être associé qu'à un seul compte » (Kerberos Generates KDC_ERR_S_PRINCIPAL_UNKNOWN or KDC_ERR_PRINCIPAL_NOT_UNIQUE Error).

Quand deux comptes revendiquent le même SPN, le KDC n'a aucun moyen de choisir une clé. La référence Microsoft sur les événements Kerberos documente un code d'échec dédié à cette situation, 0x8 KDC_ERR_PRINCIPAL_NOT_UNIQUE, décrit comme « Plusieurs entrées de principal dans la base KDC… Cette erreur se produit lorsque des noms de principal en double existent. Des noms de principal uniques sont essentiels pour garantir l'authentification mutuelle. »

Il y a une deuxième couche à prendre en compte ici. Les comptes ordinateur reçoivent automatiquement un SPN HOST, et une liste documentée de classes de service s'y replie par défaut. La référence setspn de Microsoft les énumère — cifs, http, www, wins, spooler, rpcss, dns, netlogon et une quarantaine d'autres — et énonce clairement la règle de préséance : « Ces SPN sont reconnus pour les comptes ordinateur si l'ordinateur possède un SPN host. Sauf s'ils sont explicitement placés sur des objets, un SPN host peut se substituer à n'importe lequel des SPN mentionnés. » L'équivalence elle-même est exprimée dans l'attribut sPNMappings (CN=SPN-Mappings, ID d'attribut 1.2.840.113556.1.4.1347) de l'objet NTDS Service, que Microsoft décrit comme contenant « une liste de noms de principal de service (SPN) montrant l'équivalence entre types de SPN. »

Semperis résume la conséquence en une phrase : « L'algorithme de recherche de SPN cherche toujours d'abord un SPN explicite. Il ne cherche l'alias mappé du SPN que si aucun SPN explicite n'est trouvé. »

Un SPN explicite, où qu'il se trouve dans la forêt, prime sur un mappage HOST. C'est là le levier.

SPN Dupliqué Active Directory, Abus WriteSPN, Downgrade Kerberos : comment fonctionne KerberLoss

Depuis Windows Server 2012 R2, les contrôleurs de domaine refusent de créer un doublon. La référence Microsoft SPN and UPN uniqueness documente le déroulement : le DC interroge l'index servicePrincipalName à l'échelle de la forêt — sur un Global Catalog, ou localement si le DC est lui-même un GC — et « Si le nombre d'entrées retournées != 0 -> l'écriture échoue. » L'appelant reçoit l'erreur étendue 8647 / 0x21C7 ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST (les UPN reçoivent 8648 / 0x21C8), et le DC écrit l'événement ID 2974, source ActiveDirectory_DomainService, dans le journal Directory Services — un événement qui nomme la valeur bloquée et liste jusqu'à dix objets la détenant déjà.

La même référence indique que cette vérification s'exécute aussi lorsqu'un SPN est régénéré plutôt qu'écrit directement. Modifier dNSHostName, sAMAccountName, msDS-AdditionalDnsHostName, msDS-AdditionalSamAccountName, serverReferenceBL ou userAccountControl amène AD à supprimer les anciens SPN et à en construire de nouveaux, et « Si l'une des nouvelles valeurs de SPN est un doublon, nous faisons échouer la modification. »

Semperis date l'ensemble actuel des trois vérifications — unicité UPN, unicité SPN et unicité de l'alias SPN — du correctif de 2021 de Microsoft pour CVE-2021-42282. C'est la vérification de l'alias que KerberLoss met en échec.

C'est un contrôle solide. Il compare des chaînes de caractères.

La recherche de Semperis s'est attaquée à la comparaison elle-même. En testant 385 caractères Unicode invisibles, Laron a constaté que seuls 106 étaient filtrables via des requêtes LDAP standard ; le reste est soit traité comme un espace, soit, selon les mots de Semperis, « complètement ignoré par le DC. » En insérant l'un de ces caractères dans une chaîne SPN, l'index d'unicité ne voit plus de correspondance — « en utilisant un caractère invisible et non filtrable inséré dans la chaîne, NotAdmin parvient à ajouter le SPN en conflit. »

La FAQ de l'avis Microsoft pour CVE-2026-25177 décrit la même chaîne d'événements et son résultat :

Le MSRC l'a évaluée à CVSS 3.1 base 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, temporelle 7.7), sévérité Important, classée CWE-641 (Improper Restriction of Names for Files and Other Resources), avec pour titre Active Directory Domain Services Elevation of Privilege Vulnerability. Ni le MSRC ni Semperis ne documentent ce que le changement de code de mars fait réellement en interne — considérez le correctif comme opaque et vérifiez-le par numéro de build du DC, pas par comportement.

Le droit sur lequel tout repose est banal. Sur les objets ordinateur, il s'agit de l'écriture validée que Microsoft appelle « Validated write to service principal name » (CN=Validated-SPN, Rights-GUID f3a64788-5306-11d1-a9c5-0000f80367c1), délégable dans ADUC et explicitement mentionnée dans la documentation setspn : « Vous pouvez également déléguer ce droit en attribuant l'autorisation Validated write to service principal name à l'utilisateur ou au groupe souhaité. » Sur n'importe quel objet, GenericAll, GenericWrite, ou WriteProperty sur servicePrincipalName produit le même effet. C'est la même classe de point d'appui par écriture d'attribut qui alimente les Shadow Credentials via msDS-KeyCredentialLink — et, selon Semperis, WriteSPN « sur n'importe quel compte ordinateur ou utilisateur de la forêt » suffisait.

La chaîne d'attaque

Étape 1 — Obtenir un objet accessible en écriture

L'attaquant a besoin d'un accès en écriture à servicePrincipalName sur un compte. Cela peut être un droit délégué au helpdesk, un groupe de service desk obsolète, une délégation d'OU trop large — ou un objet ordinateur que l'attaquant a créé lui-même, puisque ms-DS-MachineAccountQuota permet par défaut à tout utilisateur du domaine de joindre dix ordinateurs et que le créateur obtient les droits d'écriture sur ce qu'il a créé.

Étape 2 — Identifier une cible mappée sur HOST

La cible est n'importe quel service qui repose sur le SPN HOST automatique plutôt que sur un SPN explicite — partages de fichiers (cifs), IIS (http/www), impression (spooler), et le reste de la liste documentée. Ce sont précisément les services qui n'ont aucun SPN explicite pour défendre leur revendication.

Lister les SPN enregistrés d'une cible — si cifs/SERVERB est absent, le service repose sur le mappage HOST et peut être préempté :

setspn -L SERVERB

Étape 3 — Planter le SPN en collision

L'attaquant écrit cifs/SERVERB sur son propre objet contrôlé, avec un point de code invisible intégré de sorte que l'index à l'échelle de la forêt voit une chaîne différente. La vérification d'unicité passe. Aucune erreur 8647 n'est retournée. Aucun événement 2974 n'est écrit, car du point de vue du DC, rien n'a été bloqué.

Étape 4 — Le service casse, bruyamment

Les clients demandent désormais cifs/SERVERB, et le KDC trouve un SPN explicite qui prime sur le mappage HOST de SERVERB. Il émet un ticket — scellé avec la clé du compte de l'attaquant. SERVERB ne peut pas le déchiffrer et le rejette avec 0x29 KRB_AP_ERR_MODIFIED, documenté par Microsoft comme « les données d'authentification ont été chiffrées avec la mauvaise clé pour le serveur visé. »

Notez ce qui ne s'est pas produit. Du point de vue du KDC, la requête a réussi : un ticket a été demandé, un ticket a été émis. Il n'y a aucun échec Kerberos à partir duquel se replier, et donc aucun repli vers NTLM — juste un service qui a cessé de fonctionner. Semperis rapporte que les utilisateurs voient s'afficher « The specified network name is no longer available. », « The target account name is incorrect. » ou « Cannot find path 'path' because it does not exist. », et l'accès est restauré dès que le SPN malveillant est retiré.

Étape 5 — La même écriture, un résultat plus discret : NTLM

Le downgrade est un usage différent du même droit. Au lieu de préempter un mappage HOST, l'attaquant duplique un SPN qui existe déjà explicitement. Le KDC trouve alors deux comptes le détenant, ne peut pas choisir de clé, et — dans les tests de Semperis — retourne KDC_ERR_S_PRINCIPAL_UNKNOWN. C'est un véritable échec Kerberos, exactement ce dont un client Windows a besoin pour basculer.

C'est la variante à surveiller. Selon Semperis, elle fonctionne contre n'importe quel service de la forêt, mappé sur HOST ou non, et « du point de vue de l'utilisateur, l'accès normal semble maintenu. » Personne n'ouvre de ticket. Pendant ce temps, tout ce qui est construit sur l'hypothèse que Kerberos est le chemin d'authentification — chaque défense anti-relais ignorée parce que « nous sommes Kerberos uniquement » — repose désormais sur les contrôles anti-relais NTLM à la place. Là où NTLM a été désactivé, le même doublon produit une panne plutôt qu'un downgrade.

Étape 6 — Ou : détourner la délégation de quelqu'un d'autre

Semperis démontre un troisième usage, le SPN-jacking, adapté de l'article original d'Elad Shamir. Un attaquant qui a compromis un compte configuré pour la délégation contrainte, et qui détient WriteSPN sur un compte qu'il contrôle, plante le SPN du service intermédiaire sur ce compte et exécute le flux S4U complet — récupérant un ticket scellé avec sa propre clé. La version de Shamir nécessitait aussi WriteSPN sur le compte détenant le SPN cible, pour le retirer d'abord ; KerberLoss supprime cette exigence. Si votre environnement utilise encore les schémas de délégation couverts dans les attaques par délégation Kerberos, c'est le chemin à examiner en premier.

Détection

Partons d'un constat inconfortable : les événements qui signalent normalement un SPN dupliqué sont précisément ceux que cette technique est conçue pour éviter.

C'est l'événement 5136 qui permet de capter ceci. Microsoft documente qu'il se génère « à chaque fois qu'un objet Active Directory est modifié », et il porte exactement les champs dont vous avez besoin : ObjectDN, ObjectClass, AttributeLDAPDisplayName, AttributeValue, OperationType (%%14674 valeur ajoutée, %%14675 valeur supprimée) et le SubjectUserSid/SubjectUserName de l'auteur de l'écriture.

Deux prérequis, tous deux faciles à rater. La sous-catégorie Audit Directory Service Changes doit être activée, et l'objet a besoin d'une SACL correspondante : « Pour générer cet événement, l'objet modifié doit avoir une entrée appropriée dans la SACL : l'audit de l'action 'Write' pour les attributs spécifiques. » Sans la SACL, la sous-catégorie seule ne produit rien.

Toute écriture de SPN, avec l'identité du principal qui l'a effectuée :

$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 : écritures de SPN par des principaux non-Tier-0.
-- Les champs d'attribut de 5136 ne sont PAS mappés aux colonnes SecurityEvent
-- (voir la référence de table) — il faut les extraire du XML brut d'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"               // Valeur ajoutée
| where SubjectUserName !in ("svc_scom$", "svc_sccm$")
| project TimeGenerated, Computer, SubjectUserName, ObjectDN, SpnValue
| order by TimeGenerated desc

Traquer directement le caractère invisible

C'est la vérification qui ne dépend pas de la capture de l'écriture. Tout SPN contenant un point de code hors de l'ASCII imprimable est anormal — les SPN légitimes sont des noms d'hôte, des classes de service, des ports et des noms d'instance.

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 ' '
        }
      }
    }
  }

Exécutez quand même la recherche de doublons au niveau binaire — elle attrape la mauvaise configuration ordinaire et l'attaquant peu sophistiqué :

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

Activer la télémétrie TGS que vous n'avez probablement pas

La référence Microsoft sur l'événement 4769 indique que certains échecs « ne sont rapportés que si vous définissez la valeur de la clé de registre KdcExtraLogLevel », avec 0x01 : Audit SPN unknown errors. La référence de registre du KDC documente la valeur par défaut à 2 — ce qui signifie que le bit 0x1 est désactivé, et que les échecs KDC_ERR_S_PRINCIPAL_UNKNOWN ne sont pas écrits dans le journal Security sur un DC par défaut. L'échec précis que produit un SPN dupliqué est, par défaut, invisible.

Sur chaque DC, conservez la journalisation PKINIT par défaut (0x2) et ajoutez l'audit SPN-unknown (0x1) — ce qui donne 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'

Attendez-vous à du volume, et établissez une base de référence pendant une semaine avant d'alerter. Microsoft avertit que les échecs 0x20 (tickets expirés) sont un bruit de fond habituel ; les échecs SPN-unknown sont plus rares mais pas nuls dans une forêt saine.

Remédiation

1. Patchez les contrôleurs de domaine. Le correctif est livré dans la mise à jour de sécurité de mars 2026 — le rollup mensuel pour Server 2012 et 2012 R2. Le MSRC liste ceci par SKU de serveur :

Là où le MSRC liste deux paquets pour un SKU — Server 2022 et Server 2025 — le second est le paquet hotpatch (KB5078737 et KB5078736), qui ne s'applique qu'aux installations avec hotpatch activé. Confirmez lequel s'applique à votre build exact avant de déployer. La vulnérabilité est corrigée sur le DC, pas sur les serveurs membres — une flotte entièrement patchée avec un seul DC non patché continue de traiter les écritures via le chemin non patché.

2. Découvrez qui peut écrire des SPN. C'est le droit dont toute l'attaque a besoin, et dans la plupart des forêts personne ne l'a jamais recensé. La requête ci-dessous rapporte les principaux non administratifs détenant Validated-SPN, une écriture directe sur l'attribut servicePrincipalName, ou une écriture générique sur n'importe quel objet ordinateur.

$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 }
    }
}

Supprimez ce qui n'est pas justifié. Portez une attention particulière aux délégations accordées à des groupes larges (Authenticated Users, Domain Users, groupes de helpdesk hérités) et aux principaux qui détiennent des droits sur des objets ordinateur Tier 0.

3. Réduisez le vivier d'objets contrôlables par un attaquant. Réglez ms-DS-MachineAccountQuota sur 0 et accordez la jonction de machines via un groupe délégué à la place. Cela ne corrige pas CVE-2026-25177, mais cela supprime le moyen le plus simple pour un utilisateur ordinaire d'obtenir un objet qu'il contrôle entièrement.

4. Faites en sorte que le downgrade n'aboutisse nulle part. Que Kerberos échoue est un problème de résilience ; que Kerberos échoue vers NTLM est un problème de sécurité. Exigez la signature SMB, imposez la signature LDAP et le channel binding, et commencez à restreindre NTLM là où vous le pouvez — le chemin d'audit est couvert dans les attaques NTLM relay, et le problème jumeau de downgrade de chiffrement dans le fallback Kerberos RC4.

5. Instrumentez, puis vérifiez. Activez Audit Directory Service Changes, ajoutez une SACL auditant les écritures sur servicePrincipalName sur vos OU d'ordinateurs et de comptes de service, réglez KdcExtraLogLevel sur 3, et planifiez le balayage des SPN non-ASCII ci-dessus comme tâche récurrente. Puis confirmez que le pipeline fonctionne de bout en bout en écrivant un SPN inoffensif sur un objet de test et en vérifiant que le 5136 arrive bien dans votre SIEM — une politique d'audit qui ne produit aucun événement est indiscernable d'une forêt qui ne subit aucune attaque.

6. Examinez la faille voisine. La même recherche Semperis a révélé CVE-2026-27912 (ResetNightmare), un problème lié à userPrincipalName et au changement de mot de passe Kerberos, corrigé le 14 avril 2026. Si vous n'appliquez que maintenant le correctif de mars, vous n'appliquez aussi que maintenant celui d'avril. Les deux sont documentés dans l'article de Semperis.

Comment EtcSec détecte ceci

L'audit Active Directory d'EtcSec s'aligne directement sur les préconditions dont cette attaque a besoin, afin que vous puissiez répondre à la question « sommes-nous exposés » sans avoir à écrire vous-même les requêtes ci-dessus.

WRITESPN_ABUSE recense les principaux détenant un accès en écriture à servicePrincipalName — le droit unique que CVE-2026-25177 transforme en déni de service à l'échelle de la forêt. DUPLICATE_SPN et COMPUTER_DUPLICATE_SPN font remonter les valeurs de SPN revendiquées par plus d'un objet, les doublons octet pour octet qui cassent Kerberos, qu'un attaquant les ait placés là ou qu'une migration l'ait fait. COMPUTER_WITH_SPNS inventorie quels objets ordinateur portent des SPN explicites, ce qui permet de distinguer un service qui défend son propre nom d'un service qui dépend du mappage HOST et peut donc être préempté. DELEGATION_UNKNOWN_TARGET signale les configurations de délégation contrainte pointant vers des SPN qui ne se résolvent pas proprement — la condition dont a besoin le SPN-jacking.

Ensemble, ces quatre vérifications reconstituent la surface d'attaque : qui peut écrire, ce qui est déjà en collision, quels services dépendent de HOST, et où la délégation pointe là où elle ne devrait pas. Pour la revue plus large dans laquelle ceci s'inscrit, voir comment auditer la sécurité Active Directory, et pour le problème classique d'exposition des SPN, détection et prévention du Kerberoasting.

Sources

• Microsoft Security Response Center — CVE-2026-25177, Active Directory Domain Services Elevation of Privilege Vulnerability (CVSS 3.1 8.8, CWE-641, publié le 10 mars 2026)
• Semperis — Identity Crisis: Novel Vulnerabilities Leading to Kerberos Downgrade, DoS, and Full Domain Takeover, Shai Laron, 5 août 2026
• Microsoft Learn — SPN and UPN uniqueness (événement 2974, erreurs 8647/8648)
• Microsoft Learn — Kerberos Generates KDC_ERR_S_PRINCIPAL_UNKNOWN or KDC_ERR_PRINCIPAL_NOT_UNIQUE Error
• Microsoft Learn — setspn (classes de service mappées sur HOST, -X, -F, délégation 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 (table des codes d'échec)
• Microsoft Learn — Registry entries about Kerberos protocol and KDC (KdcExtraLogLevel, valeur par défaut 2)
• Microsoft Learn — Azure Monitor Logs reference: SecurityEvent (liste des colonnes derrière la requête Sentinel)
• Semperis — SPN-jacking: An Edge Case in WriteSPN Abuse, Elad Shamir