L'AC que vous avez éteinte.

Vous avez bâti une vraie PKI. Je veux le dire en premier, parce que c'est assez rare pour valoir la peine d'être dit.

Quelque part vers 2019, quelqu'un a fini par avoir le budget pis l'a fait comme du monde. Racine hors ligne, gardée éteinte dans un coffre. Une AC émettrice subordonnée en dessous. Modèles révisés. Inscription automatique bien ciblée. C'est l'architecture que tous les consultants dessinent sur un tableau blanc pis que presque personne ne réussit à faire financer, pis vous, vous l'avez fait financer.

Ce que vous avez remplacé, c'était une AC racine d'entreprise unique, installée sur un contrôleur de domaine en 2016 par un contractuel qui ne répond plus à ses courriels. Vous avez migré. Vous avez roulé l'assistant de suppression, le rôle est parti proprement, le serveur a été éteint, pis éventuellement quelqu'un a effacé la VM. Le billet de changement dit décommissionné, pis le billet de changement n'a pas tort.

Voici ce que j'ai fait un mardi après-midi avec un compte d'utilisateur de domaine pis aucun droit particulier :

certutil -viewstore "ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=example?cACertificate?base?objectclass=certificationAuthority"

Deux certificats sont revenus. Un des deux, c'est votre AC émettrice actuelle, ce qui est correct. L'autre, c'est une AC qui n'existe plus depuis 2019.

Je n'avais pas besoin d'être administrateur pour lire ça. La partition de configuration est lisible par tous les utilisateurs authentifiés de votre forêt, et c'est voulu, parce que les clients ont besoin de trouver ça. Moi aussi.

Comprenez bien ce qu'est cet objet-là. NTAuthCertificates, c'est la liste des AC auxquelles vos contrôleurs de domaine acceptent une authentification par certificat. Ce n'est pas un registre historique. Ce n'est pas un inventaire. C'est une liste d'autorisation vivante, votre AC morte est encore dessus, pis elle y est depuis sept ans.

Elle est aussi encore dans le conteneur Certification Authorities juste à côté, ce qui est la raison pour laquelle elle s'est retrouvée dans le magasin des racines de confiance de chaque machine que vous possédez, pis elle y est encore. Les deux objets devaient être effacés à la main. Ni l'un ni l'autre ne l'a été.

Ça, c'est la moitié de ce qu'il me faut. L'autre moitié, c'est la clé.

La clé n'est jamais partie

Vous ne l'avez pas jetée. Personne ne la jette. La jeter, ça a l'air irresponsable, alors à la place il y a une sauvegarde, la sauvegarde est à une place raisonnable, pis c'est pire.

Dans votre cas c'est un dossier sur un partage réseau qui s'appelle PKI Migration 2019, que l'équipe infrastructure a créé, utilisé six semaines, pis jamais retouché. Il contient l'exportation qu'un ingénieur consciencieux a faite avant de rouler l'assistant de suppression, exactement comme le guide le lui disait, parce qu'on ne désinstalle pas une AC sans faire une sauvegarde avant. C'est un fichier p12. À côté, il y a le guide. Le guide contient le mot de passe, parce que où d'autre est-ce qu'on le mettrait.

Si ça n'avait pas été là, j'aurais regardé vos jeux de sauvegarde, parce qu'un serveur d'AC décommissionné reste habituellement en rétention longtemps après que la VM soit disparue, pis une restauration d'état système me donne la même matière. J'ai des opinions sur les sauvegardes comme copie la plus molle de tout ce que vous possédez, pis je les ai déjà écrites.

Le point, c'est qu'une clé privée, ça ne se décommissionne pas. Ça se copie.

Ce que j'en fais

Rien qui touche à votre infrastructure.

Je ne soumets pas de requête. Pas de CSR, pas de modèle, pas de droit d'inscription, pas d'approbation, pas d'AC à qui parler, pis rien sur votre réseau qui observe une seule partie de ça. Je prends le vieux certificat d'AC pis sa clé, pis je signe un certificat moi-même, hors ligne, sur du matériel que vous n'avez jamais vu.

Comme c'est moi qui l'écris, c'est moi qui décide ce qu'il y a dedans.

Sujet : le compte que je veux. Il n'y a pas de modèle qui contraint le sujet, parce qu'il n'y a pas de modèle. Il n'y a pas de permission d'inscription, parce qu'il n'y a pas d'inscription.

Utilisation étendue de la clé : authentification client.

L'extension SID, l'OID 1.3.6.1.4.1.311.25.2, contenant le vrai objectSid d'un vrai administrateur de domaine. Je sais que vous avez serré ça. Votre KDC est en application intégrale depuis février 2025 pis il a raison de l'être. L'application intégrale demande si le certificat porte le SID du compte. Celui-là le porte. Je l'ai tapé. Je suis l'autorité de certification, pis une autorité de certification, c'est une affaire qui affirme une identité, pis personne ne vérifie les affirmations d'une AC à qui vous avez déjà dit à vos contrôleurs de domaine de faire confiance.

Point de distribution de CRL : aucun. Il n'y a plus d'AC pour publier une CRL, alors je ne donne pas au validateur une place où regarder. C'est aussi pour ça que la révocation n'est pas votre réponse ici. Le certificat a un numéro de série que j'ai inventé, il n'a jamais été dans une base de données d'AC, pis il n'y a plus de base de données d'AC. Vous ne pouvez pas révoquer une ligne qui n'existe pas.

Validité : je choisis les dates. Je lui en ai donné cinq ans, ce qui est plus que ce dont j'ai besoin, pis je vais revenir là-dessus.

Ensuite je m'authentifie. PKINIT, certificat forgé, TGT Kerberos pour un administrateur de domaine. Votre contrôleur de domaine bâtit la chaîne, trouve l'émetteur dans NTAuth, trouve une correspondance forte, pis émet le ticket. Chaque vérification a passé. Le contrôleur de domaine avait raison à chaque étape.

Événement 4768. Mardi après-midi. Émetteur du certificat : une AC décommissionnée avant que du personnel actuel soit embauché.

Personne ne regarde le champ de l'émetteur. Il n'y a rien dans votre SIEM qui saurait faire la différence.

Avant de partir. Triez vos événements 4768 par émetteur de certificat pis trouvez ceux qui ne viennent pas d'une AC que vous opérez aujourd'hui. Il y en aura un petit nombre pis ils seront tous à moi. Un d'entre eux a un sujet que j'ai rempli moi-même.

Ça dit Hiro.

Hiro out.

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

Il n'y a pas de numéro ESC sur celle-là non plus. Aucune mauvaise configuration de modèle, pas de relais, aucun droit d'inscription vulnérable, aucune AC non corrigée. Il n'y avait pas d'AC du tout. Chaque composant s'est comporté exactement comme prévu, pis la conception dit qu'un certificat signé par une clé présente dans NTAuthCertificates est une déclaration d'identité valide. La défaillance, c'est qu'une décision de confiance prise en 2016 n'a jamais été retirée en 2019.

C'est DPERSIST1 dans Certified Pre-Owned, de Will Schroeder et Lee Christensen chez SpecterOps, juin 2021. L'outillage, c'est ForgeCert de GhostPack, pis les commandes ca -backup et forge de Certipy, qui traînent un drapeau -sid depuis un bout précisément pour que les certificats forgés satisfassent la correspondance forte. SpecterOps modélise ça dans BloodHound comme l'arête GoldenCert. Rien de neuf pis rien de subtil. Ce qui est neuf, c'est qu'un paquet d'organisations ont passé 2022 à 2025 à durcir la correspondance de certificats, avec raison, pis rien de ce travail-là ne touche à ceci, parce que cette attaque respecte toutes les règles que vous avez appliquées.

Trois nuances honnêtes.

Premièrement, c'est de la persistance et de l'élévation, pas de l'accès initial. Quelqu'un doit atteindre la matière de la clé une fois. Si votre vieille sauvegarde d'AC est vraiment disparue avec toutes ses copies, l'histoire s'arrête avant de commencer, pis si la clé a déjà vécu dans un TPM ou un HSM, elle s'arrête là aussi, très probablement. Un KSP logiciel sur une AC de 2016 installée par un contractuel, c'est le cas que je continue de trouver.

Deuxièmement, la fenêtre n'est pas infinie. Le certificat forgé doit chaîner, pis le certificat de l'AC retirée a sa propre expiration. Une fois cette date passée, la chaîne échoue sur la validité pis les certificats forgés arrêtent de fonctionner tout seuls. C'est un vrai filet, pis c'est aussi la raison de faire ça maintenant plutôt que l'an prochain, parce que la plupart des gens n'ont aucune idée de cette date-là.

Troisièmement, je ne peux pas vous donner de chiffre sur la fréquence à laquelle une AC décommissionnée reste dans NTAuth. J'en trouve régulièrement en évaluation, pis tous ceux qui font ce travail-là aussi, mais c'est une impression de praticien, pas une statistique que je peux citer.

Trois choses à vérifier cette semaine

Un : lisez votre magasin NTAuth pis attribuez chaque certificat qui s'y trouve. À partir de n'importe quelle machine jointe au domaine, certutil -viewstore "ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=votre,DC=foret?cACertificate?base?objectclass=certificationAuthority", ou l'onglet NTAuthCertificates sous Gérer les conteneurs AD dans la console PKI d'entreprise. Chaque certificat là-dedans doit correspondre à une AC que vous opérez aujourd'hui pis dont vous pouvez nommer le responsable. Pendant que vous y êtes, notez le notAfter de chacun, parce que cette date-là, c'est la limite extérieure de votre exposition si la clé correspondante a déjà été copiée. La suppression, c'est certutil -viewdelstore sur le même chemin avec des droits d'administrateur d'entreprise, pis c'est exactement aussi perturbateur que ça en a l'air si vous enlevez le mauvais, alors confirmez d'abord ce qui s'authentifie avec. La documentation de décommissionnement de Microsoft couvre le reste des objets qui traînent : AIA, CDP, Certification Authorities pis Enrollment Services.

Deux : allez trouver chaque copie de clé privée d'AC que vous avez déjà faite. Dossiers de migration, guides de décommissionnement, fichiers p12 et pfx sur des partages, sauvegardes d'état système de serveurs d'AC retirés, images et instantanés de VM gardés en rétention, pis l'exportation de reprise après sinistre que quelqu'un a faite en 2018 pis mise à une place sensée. Ensuite trouvez où sont les mots de passe, qui sont habituellement dans le même document qui explique comment utiliser le fichier. Une clé d'AC protégée par un TPM ou un HSM ne peut pas sortir de cette façon-là, pis c'est la correction durable pour les AC que vous opérez aujourd'hui. Pour les AC que vous avez retirées, la seule question, c'est combien de copies existent pis qui peut les atteindre.

Trois : faites du champ de l'émetteur quelque chose que vous regardez pour vrai. Chaque ouverture de session par certificat légitime dans votre environnement correspond à une émission sur une AC que vous opérez. Activez l'audit de l'AC pour que l'émission soit enregistrée tout court, c'est l'AuditFilter sur chaque AC plus la stratégie d'audit Accès aux objets sur le serveur, pis vous obtenez les 4886 et 4887. Ensuite alertez sur l'écart : un événement 4768 dont l'information de certificat pointe vers un émetteur qui n'est pas une de vos AC en opération, ou une ouverture de session par certificat sans émission correspondante nulle part. Dans un environnement en santé, cette alerte-là ne se déclenche jamais, ce qui la rend pas chère à opérer pis bruyante quand ça compte.

Décommissionner une autorité de certification, c'est deux jobs séparées. Éteindre le service, pis retirer la confiance. Juste la première a un assistant, pis la deuxième, c'est celle qui vous protégeait.

Vous avez éteint la machine. Personne ne l'a dit à la forêt.