Jake Hildreth Consultant principal en sécurité

Dans le cadre de mes récentes recherches, j’ai parcouru sans trop m’y attarder les documents de conception de l’infrastructure à clé publique (PKI) de Microsoft ainsi que les RFC associées (en particulier la RFC 4556), dans le but de trouver une méthode fiable permettant d’élever les privilèges d’un utilisateur standard disposant de faibles privilèges vers n’importe quel compte arbitraire, sans risque de mauvaise configuration. (Oui, c’est ainsi que je passe mon temps libre. Ces questions sont importantes pour moi et pour mes collègues lorsque nous élaborons des plans de préparation aux cybermenaces.)

Malheureusement, bien que j’aie fouillé dans des domaines similaires, je n’ai pas trouvé la faille « Certighost » dans la documentation, alors qu’il s’agit d’une vulnérabilité connue des services de certificats Active Directory (AD CS).

En réalité, je n’ai trouvé aucune méthode d’élévation de privilèges.

J'ai toutefois découvert une méthode de persistance post-exploitation reposant sur une erreur de configuration qui, bien qu'elle ne soit pas aussi spectaculaire que Certighost, est presque aussi inquiétante.

  • Cela ne nécessite pas d'accéder à la clé privée d'une autorité de certification (une condition préalable à une attaque de type « Golden Certificate » ou « Golden Ticket »).
  • Cela va à l'encontre des recommandations généralement admises concernant la récupération de l'accès aux comptes piratés.
  • Contrairement à Certighost, cette faille ne fera pas l'objet d'un correctif, car elle repose sur une configuration documentée par Microsoft et destinée aux tests et au dépannage.

Si vous êtes chargé de prévenir et de gérer les violations de sécurité liées aux systèmes d'identité au sein de votre environnement, vous avez tout intérêt à garder cet élément à l'œil.

Aujourd'hui, je vais vous présenter les « certificats zombies » : des certificats d'authentification qu'on ne peut pas supprimer !

« Qui est-ce ? » Le processus d'authentification PKINIT

Dans un environnement Active Directory (AD) classique, la combinaison nom d'utilisateur + mot de passe, bien connue, constitue le principal moyen d'authentification. Votre nom d'utilisateur correspond à une déclaration d'identité ; votre mot de passe permet de vérifier cette déclaration.

Mais AD prend également en charge l'utilisation de certificats à clé publique comme moyen d'authentification, souvent sous la forme de cartes à puce. Ce processus d'authentification basé sur des certificats est appelé « Cryptographie à clé publique pour l'authentification initiale », également connu sous le nom de PKINIT. L'implémentation de PKINIT par Microsoft est décrite en détail dans la spécification MS-PKCA, mais en résumé, au lieu de chiffrer les tickets d'authentification (AS-REP/AS-REQ) avec votre mot de passe, vous utilisez une clé privée, que vous contrôlez, pour chiffrer ces tickets.

En parcourant la section 6.3.3 de la RFC 5280, j’ai trouvé la définition, donnée par l’algorithme, de ce qui se passe lorsqu’un vérificateur ne parvient pas à déterminer le statut de révocation :

Une fois ces listes de révocation (CRL) traitées, si le statut de révocation n'a toujours pas été déterminé, renvoyez alors le statut de certificat « UNDETERMINED ».

« Je vous connais ? » PKINIT dans Active Directory

Lorsque vous tentez de vous authentifier auprès d'Active Directory (AD) à l'aide d'un certificat via PKINIT, vous interagissez avec un contrôleur de domaine (DC) faisant office de centre de distribution de clés Kerberos (KDC). Au cours du processus PKINIT, le KDC vérifie si le certificat que vous utilisez est actuellement valide pour l'authentification.

Le KDC vérifie plusieurs attributs du certificat avant de confirmer « oui, je te connais », notamment (mais sans s'y limiter) :

  • Émetteur : le KDC doit faire confiance à l'autorité de certification (CA) qui a émis le certificat. Si le KDC ne fait pas confiance à l'émetteur du certificat, vous ne pourrez pas y accéder.
  • Utilisation prévue : les certificats contiennent des informations expliquant comment ils peuvent être utilisés (plus d'informations à ce sujet ci-dessous). Si vous essayez de vous authentifier avec un certificat destiné à la signature de code, vous n'y arriverez pas.
  • Période de validité : si vous essayez de vous authentifier aujourd’hui avec un certificat qui ne sera valable qu’à partir de 20X6, vous n’y arriverez pas. Et si vous essayez de vous authentifier aujourd’hui avec un certificat qui a expiré en 1666, vous n’y arriverez pas non plus.
  • Statut de révocation : un émetteur peut révoquer un certificat en l'ajoutant à une liste de révocation de certificats (CRL). Si vous essayez d'utiliser un certificat figurant sur une CRL, il y a fort à parier — vous l'avez deviné — que vous n'y arriverez pas.

Mais ce dernier point est un peu délicat…

Que se passe-t-il si la liste CRL n'est pas disponible ? En effet, les listes CRL sont généralement publiées sous forme d'URL HTTP sur des serveurs web, et ceux-ci ne fonctionnent presque jamais sans interruption.

Comme nous l'avons déjà vu, les RFC sont clairs sur ce point. Lorsqu'une CRL n'est pas disponible, le KDC doit attribuer le statut de révocation « UNDETERMINED » au certificat. Ce qui n'apparaît pas clairement dans les RFC ni dans la documentation Microsoft, c'est la signification de « UNDETERMINED » dans le contexte du processus PKINIT.


Affronter l'inconnu

Lors de la mise en place des détections ESC16 pour Serrurier et Serrurier 2 (des outils communautaires open source disponibles sur GitHub), j'ai découvert le DisableExtensionList paramètres des autorités de certification (CA) des Services de certificats AD (AD CS). Extensions Il s'agit de brèves informations ajoutées à un certificat qui précisent à quoi celui-ci sert et comment il peut et doit être utilisé.

Sur un serveur d'autorité de certification AD CS, le DisableExtensionList Ce paramètre sert à empêcher empêche l'ajout d'extensions spécifiques aux certificats émis par une autorité de certification. En règle générale, cette liste reste vide, mais des extensions peuvent y être ajoutées (et donc supprimées des certificats émis) à des fins de test, pour améliorer la compatibilité, renforcer la sécurité, etc.

L'une des extensions généralement ajoutées à un certificat est l'extension « CRL Distribution Point » (CDP), également appelée OID 2.5.29.31. L'extension CDP indique à un KDC (ou à toute autre entité chargée de la vérification) où trouver précisément l'état de révocation d'un certificat.

Question : Que se passe-t-il si j'ajoute l'extension CDP au DisableExtensionList? Une autorité de certification AD CS délivrerait-elle un certificat sans l'extension CDP ?

Réponse : En fait, oui ! Quand l'OID 2.5.29.31 existe dans le DisableExtensionList, tous les certificats délivrés par l'autorité de certification ne comportent pas l'extension CDP, car Figure 1 montre.

Figure 1 : Un certificat type et un certificat ne comportant pas l'extension CDP

Passons maintenant à la question la plus importante : est-ce que je pourrais utiliser un certificat sans extension CDP pour exécuter correctement PKINIT ?

Malheureusement, non.

Au cours du processus PKINIT, le KDC tente de vérifier l'état de révocation du certificat présenté. Sans l'extension CDP, le KDC ne sait pas où vérifier l'état du certificat. Il répond alors par KDC_REVOCATION_UNKNOWN, et la demande d'authentification est rejetée. Le certificat n'est plus valide… pour l'instant.

Ce comportement de « fermeture en cas de défaillance » correspond à la configuration par défaut d'AD, mais il n'est pas immuable.


Ignorer l'inconnu

En approfondissant la question, je me suis rendu compte que Microsoft avait déjà anticipé le problème de l'inaccessibilité de la liste CRL et créé une valeur de registre pour y remédier : UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors. Comme le nom de la valeur l'indique, lorsque UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors est défini sur 1, les listes CRL mises en cache sont utilisées pour vérifier l'état de révocation (c'est mieux que rien !) et les erreurs de révocation inconnue sont ignorées.

Je me suis alors demandé : si cette valeur de registre est définie et que je parviens à provoquer une erreur inconnue, est-ce que PKINIT réussirait ?

Cher lecteur, c'est à la fois avec une grande tristesse et un immense enthousiasme que je t'annonce que la réponse est un OUI retentissant .

Une simple modification d'une valeur du registre suffit à faire passer l'ensemble du processus PKINIT du mode « fail-closed » au mode « fail-open ».

Figure 2 : Êtes-vous un « bon cert » ou un « mauvais cert » ?

Ce comportement me dérange profondément. Mais il est aussi tout à fait logique. D'après la documentation de divers éditeurs (dont Microsoft), cette valeur de registre peut être utilisée pour assouplir les contrôles de sécurité dans des situations telles que les tests et le dépannage.

Il n'est pas destiné à être utilisé de manière permanente. En effet, il indique au KDC de laisser la porte déverrouillée pour tout ce qui ne peut pas prouver qu'il est bel et bien inactif.


Cacher l'inconnu

Il existe un effet secondaire intéressant et inattendu lié à un certificat dépourvu d'extension CDP : il peut être révoqué et ajouté à la liste CRL d'une autorité de certification comme n'importe quel autre certificat, mais son inclusion dans cette liste n'a pratiquement aucune signification.

Considérez la CRL comme un cimetière et chaque entrée de révocation comme une pierre tombale. Le certificat « zombie » possède une pierre tombale sur laquelle figure son nom, mais comme le certificat ne comporte aucune indication pour se rendre au cimetière, personne ne va jamais vérifier.

On dirait qu'il est mort, mais ce n'est pas le cas. C'est un certificat zombie !

Cela pose un véritable problème lors d'une intervention en cas d'incident. Il arrive parfois, au cours d'une telle intervention, qu'il soit nécessaire de réinitialiser ou de révoquer tous les identifiants associés à un compte compromis, y compris les mots de passe et tous les certificats d'authentification.

Que se passe-t-il lorsqu'il est impossible de révoquer un certificat d'authentification ?


Mettre en place les éléments nécessaires à une persistance discrète

À ce stade de mes recherches, j'avais observé plusieurs comportements différents :

  1. Il est possible de créer des certificats d'authentification sans extension CDP.
  2. Il est impossible de vérifier le statut de révocation d'un certificat ne comportant pas d'extension CDP.
  3. Sans extension CDP, un certificat peut apparaître comme révoqué aux yeux de l'autorité de certification et de ses administrateurs, mais cette apparence n'a aucune valeur si le statut de révocation ne peut pas être vérifié.
  4. Si un vérificateur ne parvient pas à consulter le statut de révocation d'un certificat (pour quelque raison que ce soit), le statut de ce certificat est « inconnu », et non « révoqué » ou « valide ».
  5. Par défaut, l'implémentation de PKINIT par Microsoft rejette les certificats dont le statut de révocation est inconnu.
  6. Le comportement par défaut « fermeture en cas de défaillance » peut être remplacé par « ouverture en cas de défaillance » en modifiant une seule valeur du registre.

Toutes les pièces étaient là. Il fallait juste que j'arrête d'essayer de les faire marcher.

J'ai passé beaucoup trop de temps à essayer d'assembler ces éléments comportementaux pour former une chaîne complète d'escalade de privilèges, mais j'ai fini par abandonner. Cela me semblait tout simplement impossible. Sans accès administratif à l'hôte ou au service de l'autorité de certification, il est impossible de modifier DisableExtensionList. Modification du UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors La modification d'une valeur de registre sur les contrôleurs de domaine nécessite généralement d'appartenir au groupe BUILTIN\Administrators (BA) du domaine. Aucune de ces deux opérations n'est possible sans autorisations et privilèges préalables.

Mais et si j'arrêtais de me concentrer sur les ESC (techniques d'escalade) pour commencer plutôt à réfléchir aux PERSIST (techniques de persistance) ?

Dans le livre blanc de SpecterOps intitulé « Certified Pre-Owned » (2021) , les auteurs ont répertorié plusieurs options de persistance au niveau du domaine, de l’utilisateur et de la machine, basées sur AD CS. La persistance n’est pas aussi spectaculaire que l’escalade des privilèges et est rarement mise en avant lors d’un test d’intrusion classique. Pourtant, les attaquants ont recours à la persistance pour retrouver l’accès à un environnement qu’ils ont déjà compromis.

C'est un point important à prendre en compte !


Pour résumer : comment les pirates mettent en place des « certificats zombies »

Lorsque j’ai changé ma façon de penser, passant de « Il faut que je trouve un nouvel ESC ! » à « PERSIST fait peur lui aussi ! », j’ai soudain vu les choses plus clairement, et franchement, cela m’a un peu effrayé. Imaginez qu’un pirate informatique procède comme suit :

  1. Ils obtiennent un accès hautement privilégié à votre environnement Active Directory : BA, administrateurs de domaine (DA) ou administrateurs d'entreprise (EA). (Cette étape est volontairement très vague. Faites avec !)
  2. L'attaquant vérifie qu'une infrastructure à clé publique (PKI) AD CS existe dans la forêt et prend en charge PKINIT en vérifiant la présence d'une ou plusieurs autorités de certification (CA) dans la forêt. NtAuthCertificates objet.
  3. À l'aide de RemoteRegistry ou d'une modification directe du registre, le pirate configure le UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors valeur à 1 sur un ou plusieurs centres de données.
  4. Ils ajoutent l'OID 2.5.29.31 à un CA DisableExtensionList, soit via certutil.exe ou une modification directe du registre de l'hôte de l'autorité de certification.
  5. L'attaquant demande un certificat d'authentification pour un utilisateur qu'il contrôle — probablement le compte BA/DA/EA qu'il utilise actuellement.
  6. Ils confirment que le « Zombie Certificate » fonctionne avec PKINIT.

Dans un environnement classique, les phases de reconnaissance, de modification du registre, de demande de certificat et de validation PKINIT de cette attaque peuvent être automatisées à l'aide de scripts et exécutées en quelques secondes, car bon nombre de ces éléments sont bien connus ou extrêmement faciles à identifier à l'aide des binaires intégrés et des fichiers .NET indésirables présents sur tout ordinateur Windows moderne.

À moins de croiser les événements provenant de plusieurs flux pour les regrouper en un seul ensemble d'indicateurs, vous ne vous rendrez tout simplement pas compte que cette attaque est en cours.

Imaginons toutefois que nos vaillants défenseurs remarquent cette intrusion et prennent rapidement des mesures pour la contenir. Ils :

  • Mettre fin à toutes les sessions de connexion actives associées au compte compromis
  • Réinitialiser le mot de passe Active Directory du compte compromis
  • Révoquer les certificats d'authentification du compte compromis
  • Je m'occupe d'autres choses… Je ne fais pas partie de l'équipe Relations investisseurs de Semperis, je m'en remets donc à leur expérience…

Malgré ces mesures, l'attaquant peut utiliser le « certificat zombie » qu'il a demandé à l'étape 6 ci-dessus pour effectuer une opération PKINIT et récupérer l'accès au compte qu'il contrôlait auparavant.

Comment ? Parce que le statut de révocation du certificat est inconnu et que le pirate a modifié le processus PKINIT pour qu'il opte par défaut pour l'autorisation (« fail-open ») lorsque ce statut est inconnu.


Et ça devient encore plus effrayant : la réanimation des zombies

La réponse en matière de sécurité informatique que j'ai décrite ci-dessus était volontairement incomplète : le compte compromis aurait dû être désactivé et entièrement remplacé par un nouveau compte. Mais dans le feu de l'action, certaines mesures correctives peuvent passer à la trappe.

Le confinement incomplet, ça existe vraiment !

Cependant, un pirate plus avisé aurait pu apporter quelques modifications à sa méthode afin de rendre son accès encore plus durable. Au lieu d'utiliser un modèle préexistant pour demander un certificat d'authentification pour le compte qu'il a compromis, le pirate aurait pu :

  • Créer un nouveau modèle incluant la configuration incorrecte de l'ESC1
  • Utilisez le modèle ESC1 pour demander un certificat incluant le SAN d'un autre compte privilégié

Or, si l'utilisateur initialement compromis est désactivé ou supprimé, le pirate conserverait tout de même le contrôle du compte privilégié inclus dans le SAN.

Ce zombie a un deuxième cœur. Si vous tuez l'hôte, il continue d'avancer sous une autre identité.

Remarque : il existe plusieurs autres méthodes malveillantes permettant de rendre cette attaque encore plus furtive, mais je ne peux en aucun cas les détailler ici en toute bonne conscience.


Comment détecter les certificats « zombies »

Comment savoir si vous êtes confrontés à une invasion de zombies ? Commencez par les cerveaux.

Le « cerveau » d'un certificat zombie, c'est le UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors valeur du registre. Vérifiez chaque contrôleur de domaine de votre forêt et toutes les forêts de confiance. Le chemin d'accès complet au registre est le suivant :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc\UseCachedCRLOnly AndIgnoreRevocationUnknownErrors

Si un DC a cette valeur définie sur 1, considérez cela comme un signe avéré d'altération jusqu'à preuve du contraire. Procédez comme suit :

  • Vérifiez les certificats d'authentification délivrés aux utilisateurs privilégiés, même s'ils semblent avoir été révoqués.
  • Rechercher tous les certificats d'authentification qui incluent le SAN d'un utilisateur privilégié, quel que soit l'état d'activation ou de désactivation du demandeur.
  • Vérifiez chaque CA DisableExtensionList en exécutant la commande suivante : certutil -config <CA-HOST-FQDN\CAName> -getreg policy\DisableExtensionList

Si vous voyez le résultat suivant, cela signifie qu'un élément a changé alors qu'il n'aurait pas dû :

Figure 3 : L'agresseur se trouve à l'intérieur de la maison

Comment tuer le zombie

La valeur du registre est le véritable coup fatal. Un certificat « zombie » n'est dangereux que tant qu'au moins un contrôleur de domaine accepte un statut de révocation inconnu. Il faut donc commencer par supprimer cette condition.

  1. Sur chaque DC concerné, supprimez UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors et redémarrez le centre de distribution de clés Kerberos. Cela rétablit immédiatement le comportement « fail-closed ». PKINIT rejettera tout certificat dont le statut de révocation ne peut être confirmé.
  2. Supprimer l'OID 2.5.29.31 d’après les informations fournies par l’Autorité de contrôle DisableExtensionList. Les nouveaux certificats comporteront à nouveau l'extension CDP.
    Un point essentiel : Les certificats déjà émis sans extension CDP ne peuvent en aucun cas être révoqués, quel que soit le contenu de la liste CRL de l'autorité de certification. L'entrée de révocation existe bel et bien, mais aucun vérificateur ne la trouvera jamais, car le certificat ne contient aucun pointeur vers la liste CRL. Ces certificats ne présentent aucun risque une fois le registre corrigé, mais ils doivent être identifiés et remplacés.
  3. Identifiez tous les certificats émis au cours de la période où DisableExtensionList contenaient l'OID CDP. Révocuez-les tous. Ils sont déjà inopérants une fois la valeur du registre corrigée, mais une révocation explicite permet de boucler la boucle et de créer une piste d'audit.
  4. Imposer le réenregistrage de tous les comptes concernés, en particulier ceux disposant de privilèges. Émettre de nouveaux certificats comportant une extension CDP valide.

Prévenir la prochaine épidémie

Il ne suffit pas de tuer le zombie actif. Il faut aussi empêcher le suivant d'agir.

  • Surveillez le registre de chaque contrôleur de domaine auquel vous faites confiance. Alerte en cas de modification de UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors dans tous les centres de données. Toute valeur autre que absent ou 0 devrait donner lieu à une enquête immédiate.
  • Auditer DisableExtensionList selon un calendrier. Il devrait être vide sur chaque autorité de certification (CA) de votre forêt. Vous pouvez vérifier directement le chemin d'accès au registre ou l'interroger via certutil: certutil -config <CA-HOST-FQDN\CAName> -getreg policy\DisableExtensionList
    Conseil de pro : Les Plateforme Semperis Lightning peut surveiller le registre à votre place !
  • Utilisez Locksmith 2. Les outils Locksmith et Locksmith 2 permettent tous deux de détecter une configuration incorrecte du paramètre DisableExtensionList. Exécutez-les régulièrement dans le cadre de vos contrôles d'intégrité AD CS.

Pour qu'une épidémie de « certificats zombies » se produise, deux conditions doivent être réunies simultanément :

  • Une autorité de certification délivrant des certificats sans extension CDP
  • Au moins un DC présentant une défaillance de type « open » dont le statut de révocation est inconnu

Si vous éliminez l'une ou l'autre de ces conditions, l'attaque échoue. Si vous éliminez les deux, votre infrastructure PKI sera bien plus sûre.


Attendez-vous à ce que les zombies reviennent… et soyez prêts

Les « certificats zombies » ne constituent pas un cas théorique marginal. Ils reposent entièrement sur une fonctionnalité Microsoft documentée et intentionnelle.

Aucun CVE ne permettra de résoudre ce problème. Aucun correctif n'est prévu. L'attaque fonctionne parce que les administrateurs doivent parfois assouplir les contrôles de révocation — et les pirates peuvent exploiter cette même souplesse.

La bonne nouvelle, c’est que les conditions préalables sont nombreuses. Un attaquant doit disposer d’un accès hautement privilégié pour que tout cela soit possible, ce qui signifie qu’une bonne gestion des privilèges est d’une grande utilité. La mauvaise nouvelle, c’est qu’une fois ces conditions réunies, l’attaque est rapide, automatisable et échappe à la plupart des procédures standard de réponse aux incidents.

Si vous utilisez AD CS dans votre environnement, vérifiez la valeur du registre et le DisableExtensionList sur tous les CA aujourd'hui. Si vous constatez la présence inattendue de l'un ou l'autre, cela signifie qu'il y a un problème qui mérite d'être examiné. Si vous constatez la présence des deux à la fois, il se peut qu'un zombie erre déjà dans votre forêt.

Si vous avez besoin d'aide pour éliminer les « certificats zombies », contactez Semperis. Nos experts en gestion des incidents sont confrontés à ce genre de situations au quotidien, et nous sommes là pour vous aider.

Clause de non-responsabilité

Ce contenu est fourni à des fins éducatives et informatives uniquement. Il vise à promouvoir la prise de conscience et la remédiation responsable des vulnérabilités de sécurité qui peuvent exister sur les systèmes que vous possédez ou que vous êtes autorisé à tester. L'utilisation non autorisée de ces informations à des fins malveillantes, d'exploitation ou d'accès illégal est strictement interdite. Semperis n'approuve ni ne tolère aucune activité illégale et décline toute responsabilité découlant d'une mauvaise utilisation du matériel. En outre, la Semperis ne garantit pas l'exactitude ou l'exhaustivité du contenu et n'assume aucune responsabilité pour les dommages résultant de son utilisation.


En savoir plus sur la prévention et l'élimination des éléments persistants dans Active Directory et Entra ID