Vous l'avez fait. Vous l'avez vraiment fait.

Je veux être clair sur mon niveau d'irritation. Pendant des années j'avais un truc fiable. Trouver un modèle qui me laissait nommer mon propre sujet, taper le UPN d'un admin de domaine dans la requête, m'inscrire, PKINIT, rentrer chez nous. Votre contrôleur de domaine lisait le nom sur le certificat et le croyait, parce que le KDC était en mode compatibilité, et « mode compatibilité » c'est une façon polie de dire qu'on me croit sur parole.

Ensuite Microsoft a sorti KB5014754 le 10 mai 2022. Ça a commencé à mettre une extension SID dans les certificats émis, l'OID 1.3.6.1.4.1.311.25.2, pour que le certificat porte l'identifiant réel du compte au lieu d'un nom que n'importe qui peut taper. Ça journalisait l'événement 39 chaque fois qu'un certificat s'authentifiait sans. Vos DC se sont plaints pendant deux ans et demi. Le 11 février 2025, le KDC est passé en application intégrale par défaut. Le 9 septembre 2025, la clé de registre que vous utilisiez pour rouvrir la porte a cessé d'être honorée.

Donc le truc du nom tapé à la main est mort. Félicitations. Sincèrement.

Sauf que relisez la règle. L'application intégrale ne dit pas que le certificat doit porter un SID. Elle dit que la correspondance doit être forte. Et il y a deux façons d'être fort. Le certificat porte l'extension SID, ce qui est implicite, ou le compte porte une entrée forte dans altSecurityIdentities, ce qui est explicite.

Le chemin explicite doit exister. Les AC tierces n'inscrivent aucune extension SID Microsoft nulle part. Bien des cartes à puce de fournisseurs non plus. Le connecteur Intune non plus, jusqu'à ce que vous l'activiez. Et la remédiation officielle de Microsoft pour tous ces cas-là, c'est la même : écrire une correspondance forte dans altSecurityIdentities sur le compte. Ce n'est pas une faille. C'est le correctif sanctionné, publié, documenté et correct.

C'est aussi un attribut d'annuaire sur un objet utilisateur, protégé par une ACL que personne n'a relue quand la confiance a déménagé.

Je suis sur votre réseau depuis que le help desk est enfin passé réparer le portable de Suzie Q. Ça fait un bout. Je suis patient, pis j'aime mieux être plate que me faire pogner.

Voici ce que le groupe help desk possède. Écriture de toutes les propriétés sur l'OU qui contient les comptes d'employés et les comptes de service. Quelqu'un a délégué ça en 2016 pour un outil libre-service décommissionné en 2019. L'outil est parti. L'ACE, non.

Les admins de domaine, je peux pas y toucher, pis je vous l'accorde. Ces comptes-là sont protégés par AdminSDHolder et l'ACL se fait réappliquer à l'heure, que ça fasse mon affaire ou non. Correct. J'en ai pas besoin.

L'OU contient svc-backup. Pas protégé, parce qu'il n'est dans aucun groupe protégé. Administrateur local sur la plupart de vos serveurs de fichiers et d'applications, parce que c'est comme ça que l'agent a été installé en 2018 et que personne n'y est retourné depuis. Si vous voulez savoir ce que je pense de vos comptes de service de sauvegarde, j'ai déjà écrit là-dessus.

Alors je m'inscris pour un certificat. En mon propre nom, comme un utilisateur quelconque, sur le modèle User ordinaire. Requête standard, aucun jeu sur le sujet, rien qui lève un drapeau. L'AC émet et intègre gentiment mon propre SID, ce qui est exactement correct et exactement sans importance, parce que je ne vais prétendre être personne.

Je prends l'empreinte SHA1 de la clé publique de mon certificat et j'écris une seule valeur sur svc-backup :

X509:<SHA1-PUKEY>ef9375785421d3ad286d8bdeb166f0f697266992

C'est X509SHA1PublicKey. C'est sur la liste des correspondances fortes de Microsoft elle-même, avec X509IssuerSerialNumber et X509SKI. Le KDC ne discutera pas.

Ensuite je m'authentifie avec mon propre certificat. Le DC cherche une correspondance forte. Il en trouve une. Concordance exacte sur l'empreinte de la clé publique. L'authentification passe et j'ai un TGT Kerberos pour svc-backup.

Pas d'événement 39, parce que la correspondance n'était pas faible. Pas d'événement 41, parce que je n'ai jamais revendiqué un SID qui ne concordait pas. Juste un 4768 bien propre qui dit que votre compte de service de sauvegarde s'est authentifié par certificat, un mardi, ce qu'il fait tous les mardis.

J'efface la valeur de l'attribut une vingtaine de minutes plus tard. La seule trace de son passage, c'est un événement de modification d'annuaire, le 5136, qui exige une SACL sur cette OU et la sous-catégorie « Modifications du service d'annuaire » activée. J'ai vérifié. Vous n'avez ni l'un ni l'autre.

Avant de partir, j'ajoute une valeur sur mon propre compte. Elle est faible, elle ne correspond à rien, pis elle n'authentifiera jamais quoi que ce soit :

X509:<S>CN=Hiro

Juste pour que vous sachiez où regarder.

Hiro out.

Si vous êtes du côté défense, voici ce qui vient de se passer, sans détour.

Rien dans cette chaîne n'était un exploit. Aucune mauvaise configuration de modèle, pas d'ESC1, pas de relais, pas de maliciel. Le certificat était ordinaire. L'AC s'est comportée correctement. Le KDC s'est comporté correctement, et même exactement comme il a été durci. La seule chose qui a bougé, c'est une chaîne de caractères dans un attribut sur un compte, écrite par un compte qui avait le droit de l'écrire.

C'est ESC14, l'abus de correspondance explicite de certificat, documenté par Jonas Bülow Knudsen chez SpecterOps en février 2024. La variante ci-dessus est celle de l'écriture directe, la seule qui fonctionne encore sous application intégrale. Les autres variantes dépendent de correspondances faibles et du drapeau CT_FLAG_NO_SECURITY_EXTENSION (0x00080000) activé sur un modèle, et l'application intégrale les a fermées. Celle-ci, non, parce qu'il n'y a rien à fermer. La correspondance explicite forte est une fonctionnalité supportée que le KDC est censé honorer.

Deux nuances honnêtes. Premièrement, c'est de l'élévation de privilèges, pas de l'accès initial. Hiro a besoin d'un pied dans la place avec droit d'écriture avant que quoi que ce soit commence. Deuxièmement, je ne peux pas vous donner de chiffre sur la proportion d'environnements qui traînent une délégation « écriture de toutes les propriétés » périmée sur une OU d'utilisateurs. J'en vois souvent en évaluation, et tous ceux qui font ce métier aussi, mais c'est une impression de praticien, pas une statistique que je peux citer.

Ce qui rend le sujet pertinent, c'est le calendrier. Entre la date d'application de février 2025 et l'échéance de registre de septembre 2025, beaucoup d'organisations ont écrit des entrées altSecurityIdentities en lot pour garder fonctionnels des certificats tiers et des certificats de fournisseurs. Dans bien des environnements, une nouvelle valeur sur cet attribut est maintenant parfaitement banale, et il n'existe aucune ligne de base de ce qui est normal.

Trois choses à vérifier cette semaine

Un : qui peut écrire altSecurityIdentities. Ce n'est pas seulement une ACE explicite sur l'attribut. L'écriture sur le jeu de propriétés Public-Information le couvre, tout comme GenericWrite, GenericAll, WriteDACL et WriteOwner sur l'objet. Le groupe Opérateurs de comptes le couvre sur tous les utilisateurs non protégés du domaine. SpecterOps a publié Get-WriteAltSecIDACEs.ps1 pour exactement cette énumération. Exécutez-le, puis remontez chaque délégation d'OU trouvée et demandez qui l'a demandée et si la raison tient encore. Les délégations périmées d'outils décommissionnés sont le cas courant.

Deux : quelles correspondances existent déjà, et lesquelles sont faibles. Énumérez toutes les valeurs altSecurityIdentities peuplées dans l'annuaire. Tout ce qui utilise X509IssuerSubject, X509SubjectOnly ou X509RFC822 est sur la liste faible de Microsoft et devrait être remplacé par X509IssuerSerialNumber, X509SKI ou X509SHA1PublicKey. Sous application intégrale, les faibles n'authentifient plus personne de toute façon : si une entrée faible existe et que personne ne s'est plaint, c'est du poids mort au mieux. Ensuite, prenez les entrées fortes et rattachez chacune d'elles à un processus documenté. Une entrée forte que vous ne pouvez pas expliquer est un incident, pas un item de ménage.

Trois : est-ce que vous verriez l'écriture, tout simplement. L'audit des modifications d'annuaire sur cet attribut n'est pas activé par défaut. Il faut la sous-catégorie d'audit « Modifications du service d'annuaire » activée, une SACL sur les conteneurs qui hébergent les comptes d'utilisateurs et de service, et ensuite il faut que l'événement 5136 contenant altSecurityIdentities aboutisse quelque part où une personne ou une règle le lit vraiment. Dans un environnement sain, le volume est proche de zéro, ce qui en fait une des alertes à fort signal les moins chères disponibles. Pendant que vous y êtes, confirmez que vos DC sont bel et bien à jour au-delà des mises à jour du 9 septembre 2025 et que rien n'essaie encore de remettre StrongCertificateBindingEnforcement à 1, parce qu'un DC qui n'a jamais pris ces mises à jour est un autre problème, plus vieux.

La correspondance forte de certificat était le bon changement et elle a fermé un vrai trou. Ce qu'elle a fait aussi, c'est déplacer l'énoncé faisant autorité sur l'identité derrière un certificat, du certificat vers l'annuaire. Le certificat est signé. L'attribut, non. Quiconque peut écrire cet attribut décide maintenant qui votre KDC croit, et la plupart des organisations n'ont jamais audité cette liste, parce qu'avant février 2025 ça n'avait presque pas d'importance.

La première étape, c'est de savoir qui est dessus.

Il existe une image inversée de ce problème, où l'attribut est correct et c'est le certificat lui-même qui change de mains. Celui-là survit à votre réponse à incident.