Microsoft RAMP s’arrête à la limite de votre autorité de certification

Microsoft a corrigé CVE-2026-54121 le 14 juillet. Les chercheurs H0j3n et Aniq Fakhrul ont publié un proof of concept fonctionnel 10 jours plus tard, nommé Certighost. Si vos serveurs AD CS ont reçu la mise à jour cumulative de juillet, vous êtes protégé. S’ils sont toujours sur les versions de juin, vous êtes exposé au code d’exploitation public.

L’attaque elle-même est courte. Un utilisateur standard du domaine sans droits administrateur manipule des attributs sur un compte machine qu’il contrôle, déclenche une logique de secours défectueuse dans l’autorité de certification et reçoit un certificat signé qui s’authentifie en tant que contrôleur de domaine via PKINIT. À partir de là, DCSync permet d’obtenir le hash krbtgt et la capacité de forger des Golden Tickets à travers la forêt. Cela nécessite une Enterprise CA intégrée à Active Directory et la capacité de créer ou contrôler un compte ordinateur, ce que le quota par défaut de 10 comptes machine accorde à chaque utilisateur du domaine.

Le compte qui a lancé la chaîne n'a jamais détenu de privilèges élevés à aucun moment. C'est le détail qui compte ici, car la feuille de route de Microsoft pour privileged access est construite autour d'un modèle de menace que cette attaque contourne.

Les trois groupes d'initiative de RAMP

Le Plan de Modernisation Rapide vous invite à séparer et gérer les comptes privilégiés, améliorer l’expérience des identifiants pour leurs détenteurs et déployer des postes de travail administratifs. En dessous se trouvent les détails sur lesquels la plupart des équipes de sécurité travaillent actuellement : Privileged Identity Management (PIM), comptes d’accès d’urgence, catégorisation des rôles Microsoft Entra par impact, MFA et accès sans mot de passe pour les administrateurs, blocage de l’authentification héritée et Privileged Access Workstations.

La plupart de cela concerne Microsoft Entra ID. Ce que RAMP demande sur site se résume à des comptes administrateurs séparés, des postes de travail dédiés pour les utilisateurs, et des mots de passe administrateurs locaux uniques. Certighost est un défaut dans AD CS. Aucun de ces trois éléments ne le touche.

RAMP ne contient aucune initiative d’autorité de certification. Microsoft l’a délibérément défini ainsi, et les directives le confirment, en s’appuyant sur un document distinct de déploiement de Privileged Access Management. RAMP répond à la question de savoir qui détient un accès élevé dans votre environnement. La manière dont votre CA décide quelle identité lier à un certificat est une autre question.

Certighost ne sera pas le dernier

L'intégrité de l'émission des certificats est une catégorie qui continue de produire. La plupart des méthodes connues sont les techniques d'attaque ESC documentées depuis "Certified Pre-Owned", où un modèle ou un drapeau CA permet à un utilisateur sans privilèges de demander un certificat pour une identité qu'il ne possède pas. Certighost est une forme différente. La configuration du modèle est sans importance. Le défaut se trouve dans la logique de gestion des demandes de l'autorité de certification, dans la manière dont elle a résolu quel objet d'annuaire la demande concernait réellement.

Cette distinction est importante pour la manière dont vous agissez. Un audit de modèle de certificat, qui est le conseil standard, n’aurait pas détecté celui-ci.

Ce que les clients comprennent mal à ce sujet

La plupart des clients considèrent AD CS comme pris en charge parce que quelqu’un en est responsable. L’autorité de certification est rattachée à une équipe PKI ou infrastructure, l’équipe d’identité suppose que cela signifie que c’est géré, et une autre ligne hiérarchique est perçue comme un contrôle. Lorsque je demande s’ils ont audité leurs configurations selon l’un des chemins ESC, la réponse est généralement qu’ils n’en avaient pas connaissance.

Les équipes qui en sont responsables sont évaluées sur la disponibilité. L’émission réussit, les renouvellements ne périment pas, l’authentification ne se casse pas, la CA est saine selon toutes les métriques dont elles sont responsables. Elle reste saine pour toutes lorsqu’un utilisateur standard inscrit un certificat pour un compte auquel il n’a aucun droit, ce qui explique pourquoi personne ne le remarque.

La gouvernance n'a rien à quoi s'attacher

Les contrôles de RAMP s'activent autour d'un compte privilégié. Certighost ne le touche jamais tant que la CA elle-même n'a pas émis le certificat qui le crée.

Il n’y a pas de compte intermédiaire que PIM puisse contrôler ni d’authentification admin que MFA puisse défier. L’escalade et la récompense se produisent en une seule transaction dans le traitement de la demande de l’autorité de certification, et le compte de départ de l’adversaire reste exactement là où il était, au même niveau que tout autre utilisateur standard du domaine. Le quota de comptes machines qui rend possible l’étape de préparation n’est pas non plus une initiative RAMP.

RAMP pointe vers Microsoft Defender for Identity (MDI), et MDI offre une couverture réelle des certificats. Les évaluations de posture examinent les modèles et les paramètres CA pour les chemins d'escalade connus, et les contrôles qui regardent la CA elle-même nécessitent un capteur MDI sur le serveur AD CS. Il existe également une détection nommée pour cette technique qui se déclenche selon le modèle de requête.

Les deux méritent d’être utilisés. Aucun ne refuse la demande d’inscription. Une évaluation de posture est un rapport de configuration que vous lisez régulièrement, et une détection est une alerte qui arrive pendant que la transaction se termine.

Ainsi, une équipe de sécurité peut terminer RAMP de bout en bout, bien le faire, exécuter MDI en parallèle, et ne toujours pas avoir de contrôle qui évalue et refuse une demande de certificat. La gouvernance de Privileged Access Management et l'intégrité de l'autorité de certification sont des problèmes distincts. RAMP en résout un, et je dirais que considérer un déploiement terminé comme une couverture pour les deux est la lecture erronée la plus courante de l'objectif de cette feuille de route.

Si quelqu’un me dit qu’il a terminé son travail sur RAMP, ma première question est de savoir qui possède l’autorité de certification. S’ils doivent le découvrir, c’est la réponse. RAMP est la bonne feuille de route et la terminer signifie que leurs comptes privilégiés sont gouvernés, ce qui est un vrai progrès et pas rien. Cela ne dit rien sur le système qui peut créer un de ces comptes à partir d’une demande de certificat d’un utilisateur standard. Surveiller ce système est le minimum. Ce que je voudrais ensuite, c’est quelque chose qui puisse refuser la demande.

Blocage de la demande d'inscription

Netwrix Threat Prevention (NTP) et Netwrix Threat Manager (NTM) interviennent des deux côtés. Côté surveillance, NTM couvre les mêmes domaines que RAMP via Defender for Identity, détectant les abus d’AD CS et les schémas d’abus de certificats en temps réel.

Le volet prévention est ce qui les distingue. NTP évalue les demandes d’inscription par rapport aux schémas connus d’abus d’AD CS, y compris les techniques ESC1 à ESC7, et les bloque avant qu’un certificat n’existe, plutôt que de générer un enregistrement indiquant qu’un certificat a été délivré. Une évaluation de posture vous indique qu’un modèle est erroné et une détection vous indique qu’une demande semblait incorrecte, mais l’application est la seule des trois qui met fin à la transaction.

Faites RAMP, puis consultez votre autorité de certification

Suivez RAMP. Le travail qu'il demande vaut la peine d'être fait. Patchez vos serveurs AD CS et réglez le quota des comptes machines à zéro pendant que vous y êtes.

Ensuite, consultez votre autorité de certification, car RAMP ne vous y conduira pas. Auditez les modèles, puis posez la question plus difficile en dessous : lorsqu’un compte standard soumet une demande d’inscription affirmant une identité à laquelle il n’a pas droit, qu’est-ce qui dans votre environnement évalue cette demande, et quelque chose l’arrête-t-il ou se contente-t-il de l’enregistrer ?