Le groupe Emperador vient de revendiquer le vol de certificats PKI internes chez AB InBev. Ce n'est pas une surprise — c'est l'aboutissement logique d'une tendance que j'observe depuis trois ans chez mes clients : la PKI interne est le maillon le plus sous-protégé de l'infrastructure, et les attaquants l'ont parfaitement compris.

La PKI interne : une infrastructure critique que personne ne surveille vraiment

Posez la question à un RSSI : avez-vous un inventaire complet de vos certificats internes ? La réponse honnête, dans 80 % des cas, sera non. Pas par incompétence — par manque de priorité. La PKI fonctionne silencieusement en arrière-plan, les certificats s'auto-renouvellent quand l'automatisation est en place, et personne ne pense à surveiller ce qui semble marcher tout seul.

Pourtant, derrière cette façade de tranquillité, la PKI interne orchestre une partie critique de la confiance dans votre SI. Elle émet les certificats utilisés pour l'authentification machine sur les postes Windows via autoenrollment AD CS, pour le chiffrement TLS des communications entre serveurs internes, pour la signature de code applicatif interne, pour les accès VPN client-to-site et site-to-site, pour les connexions 802.1X sur le réseau câblé et Wi-Fi, et pour le chiffrement des emails S/MIME. La PKI est la colonne vertébrale de confiance de votre infrastructure. Si un attaquant la compromet, il peut usurper n'importe quelle identité dans votre SI.

Selon le rapport Ponemon Institute Global PKI Trends 2026, 53 % des organisations n'ont pas d'inventaire complet de leurs certificats, 41 % ont subi au moins un incident de sécurité lié à des certificats dans les deux dernières années, et le délai moyen de détection d'un incident impliquant la PKI dépasse 40 jours. Quarante jours pendant lesquels un attaquant peut opérer sous le couvert d'une identité certifiée légitime, indétectable par la majorité des outils de surveillance réseau.

La configuration typique que je rencontre en mission : une CA racine qui tourne sur une VM standard (parfois la même VM depuis 8 ou 10 ans), deux ou trois CA intermédiaires sur des serveurs Windows déployés à l'époque et jamais vraiment révisés depuis, des templates de certificats hérités de configurations par défaut, une procédure de révocation théoriquement documentée mais jamais testée en conditions réelles, et aucune alerte en temps réel sur l'émission de nouveaux certificats. C'est une posture qui invite au désastre.

Le problème structurel est que la PKI relève souvent d'une équipe d'infrastructure qui n'est ni la DSI (trop opérationnelle), ni la SSI (trop technique), ni les développeurs. Elle tombe dans l'angle mort organisationnel, sans propriétaire clairement désigné, sans budget de maintien en condition de sécurité, et sans KPI de suivi. Résultat : elle vieillit en silence, accumulant une dette technique et sécuritaire que personne ne veut — ou n'ose — quantifier.

Ce que les attaquants font vraiment avec des certificats volés

Il y a un malentendu courant sur la valeur des certificats pour un attaquant. Beaucoup pensent certificat volé égal utilisé pour signer du malware. C'est vrai, mais c'est la partie visible de l'iceberg. Le spectre d'exploitation est beaucoup plus large, et c'est ce qui explique pourquoi des groupes comme Emperador ciblent spécifiquement les assets PKI plutôt que de se contenter des données métier classiques.

Certificats de code signing. Un certificat de signature de code émis par votre CA interne permet de signer des exécutables qui seront acceptés sans alerte par toutes les solutions de sécurité configurées pour faire confiance à votre PKI interne. Les outils de whitelisting applicatif — AppLocker, WDAC sur Windows, solutions EDR modernes — vérifient la signature, pas l'origine de l'opération de signature. Un malware signé avec un certificat de code signing interne valide passe les contrôles comme n'importe quelle application légitime de votre DSI. C'est exactement ce vecteur qu'ont utilisé les opérateurs de la campagne ShadowPad documentée en 2025 pour distribuer des implants dans des environnements industriels asiatiques.

Certificats de CA intermédiaire. Si l'attaquant obtient la clé privée d'une CA intermédiaire — pas seulement un certificat feuille — il peut générer lui-même des certificats valides pour n'importe quel nom d'hôte interne. Il peut déployer un faux serveur avec un certificat HTTPS parfaitement valide aux yeux de tous vos navigateurs et agents internes. C'est la base d'une attaque man-in-the-middle indétectable par les contrôles TLS standards, applicable aussi bien aux APIs internes qu'aux portails d'administration.

Certificats d'authentification machine. Les certificats délivrés pour l'authentification machine — template Computer dans AD CS — permettent de s'authentifier sur le réseau comme si l'on était un poste légitime du domaine. Certaines configurations de VPN et de 802.1X vérifient uniquement le certificat machine, sans MFA supplémentaire. Avec un certificat machine valide, l'accès au réseau interne depuis n'importe quelle machine externe devient trivial. C'est un vecteur de persistance à très long terme : le certificat est valide jusqu'à son expiration, souvent 1 à 3 ans.

Certificats S/MIME d'utilisateurs à privilèges. Si des certificats de signature d'email appartenant à des cadres dirigeants ou à des membres du département financier figurent dans le lot exfiltré, ils deviennent des vecteurs de fraude documentaire à fort impact. Un email signé numériquement avec le certificat S/MIME du CFO a une crédibilité quasi absolue dans les échanges internes. Des demandes de virement frauduleuses signées numériquement sont extraordinairement difficiles à détecter pour les équipes financières non formées à ce risque spécifique.

Cartographie de l'infrastructure. Même sans les clés privées, les certificats révèlent les noms d'hôtes internes, les adresses IP, les serveurs sensibles (base de données, serveurs d'authentification, infrastructure critique) et l'architecture réseau. C'est un plan détaillé de votre SI livré sans effort de reconnaissance supplémentaire — le type d'information que des attaquants passent habituellement des semaines à collecter via du scanning réseau ou du phishing d'administrateurs.

Un attaquant sophistiqué ne cherche pas nécessairement à exploiter immédiatement les certificats volés. Il peut les stocker, les revendre à d'autres acteurs, ou les utiliser des mois plus tard dans une attaque de plus grande ampleur. La durée de vie étendue des certificats internes — souvent 2 à 5 ans dans les configurations héritées — leur confère une valeur durable sur le marché de l'outillage offensif.

Comment les APT et ransomwares compromettent une PKI

La bonne nouvelle : compromettre une PKI bien configurée est difficile. La mauvaise : la plupart des PKI d'entreprise ne sont pas bien configurées.

Le vecteur le plus fréquent que je rencontre n'est pas une CVE exotique sur le logiciel de CA — c'est la compromission du serveur CA lui-même via des vecteurs d'attaque basiques. Un serveur CA Windows non patché depuis 18 mois parce que ça marche, on touche pas est une cible rêvée. Un accès admin à la CA via des identifiants partagés entre plusieurs personnes complique la détection et la réponse à incident. Des sauvegardes de la CA stockées sur un partage réseau accessible depuis plusieurs serveurs applicatifs, avec les clés privées exportables en clair, sont un coffre-fort dont la porte est ouverte.

Le second vecteur majeur, documenté par les chercheurs de SpecterOps dans leur travail fondateur Certified Pre-Owned (2021, élargi depuis à plus de 13 techniques ESC), concerne les mauvaises configurations des templates de certificats dans AD CS (Active Directory Certificate Services). Les techniques les plus exploitées en 2026 restent ESC1 — template autorisant l'utilisateur à spécifier le Subject Alternative Name, permettant à n'importe quel utilisateur du domaine d'obtenir un certificat au nom d'un admin — ESC3 (agent enrollment permettant d'obtenir des certificats au nom d'autres utilisateurs) et ESC8 (relay NTLM vers l'interface web d'inscription AD CS). Ces techniques n'exploitent pas une CVE : elles abusent de fonctionnalités légitimes mal configurées. Elles sont présentes dans la grande majorité des environnements AD CS que j'audite.

Un troisième vecteur, moins documenté mais croissant, concerne les intégrations PKI avec des pipelines CI/CD et des orchestrateurs cloud. Vault PKI de HashiCorp est de plus en plus déployé pour émettre des certificats à courte durée de vie dans les environnements Kubernetes — c'est une bonne pratique en théorie. En pratique, les roles Vault PKI sont souvent trop permissifs (un rôle wildcard pour tout le domaine interne au lieu de rôles granulaires par service), et les tokens d'accès Vault sont stockés en clair dans des secrets Kubernetes non chiffrés au repos. La CVE-2026-110720 sur Consul-k8s, publiée hier, illustre exactement ce type de risque dans l'écosystème HashiCorp.

Enfin, les attaques de supply chain ciblant les HSM et les outils d'administration PKI — EJBCA, Microsoft ADCS Web Enrollment, Venafi TLS Protect — sont en augmentation. Ces outils sont des cibles à haute valeur ajoutée car leur compromission donne accès direct aux opérations cryptographiques les plus sensibles de l'organisation, sans nécessiter de compromission directe du serveur CA.

Ce que je vois chez mes clients : anatomie d'une PKI typique en 2026

Après plusieurs années d'audits techniques incluant des revues PKI dans des organisations allant de la PME industrielle à l'entreprise du CAC 40, j'ai identifié des patterns récurrents. Ce n'est pas une critique des équipes en place — c'est le reflet d'une dette technique accumulée dans un domaine qui souffre d'un manque chronique de ressources et de sensibilisation.

La CA racine est en ligne. La bonne pratique universelle dit que la CA racine doit être offline — mise hors tension et déconnectée du réseau, sortie uniquement pour émettre des certificats de CA intermédiaires, une opération qui devrait survenir une fois tous les 5 à 10 ans. En pratique, je trouve des CA racines qui tournent en continu sur des VMs vCenter, parfois accessibles depuis le même VLAN que les serveurs applicatifs. Une CA racine en ligne est une CA racine attaquable.

Les clés privées sont exportables. Windows AD CS propose une option d'archivage des clés privées (key archival) qui stocke une copie chiffrée de chaque clé privée sur le serveur CA. Dans de nombreux environnements, cette option est activée sur tous les templates par défaut, y compris les templates serveur où elle n'a aucun sens opérationnel. Résultat : la CA dispose d'une archive de toutes les clés privées jamais émises. Compromettez la CA, vous avez toutes les clés.

Les templates héritent des permissions Authenticated Users. Par défaut, de nombreux templates AD CS accordent l'enrollment à Authenticated Users — c'est-à-dire n'importe quel compte du domaine. Combiné avec ESC1 (Subject Alternative Name fournisseur), n'importe quel utilisateur authentifié peut obtenir un certificat pour n'importe quel nom, y compris le compte Administrator du domaine. J'ai reproduit ce vecteur d'escalade de privilèges dans des dizaines d'environnements d'audit sans exception notable.

Les points de distribution CRL sont en panne. La révocation n'a de valeur que si les clients peuvent vérifier les CRL et les réponses OCSP. Dans de nombreux environnements, les URLs de distribution CRL pointent vers des serveurs qui ont changé d'adresse IP, des partages réseau inaccessibles depuis l'extérieur, ou des services web arrêtés. Les clients reviennent silencieusement en soft-fail et acceptent les certificats sans vérifier leur révocation. Révoquer un certificat compromis n'a alors aucun effet pratique.

Aucune surveillance de l'émission. Qui est alerté quand un nouveau certificat est émis depuis votre CA ? Dans la grande majorité des environnements : personne. Les Event ID Windows 4886 et 4887 ne sont pas centralisés dans le SIEM. L'émission anormale d'un certificat par un attaquant ayant exploité ESC1 passe totalement inaperçue pendant des jours, des semaines ou des mois.

Ce qui fonctionne vraiment pour sécuriser une PKI d'entreprise

Les mesures qui font vraiment la différence ne nécessitent pas de budget exorbitant. Elles nécessitent de la rigueur et de la discipline opérationnelle.

L'inventaire en continu. Vous ne pouvez pas protéger ce que vous ne connaissez pas. Un inventaire PKI complet doit couvrir toutes les CA (racines, intermédiaires, émetteurs), tous les certificats en circulation avec propriétaire, date d'expiration, usage et emplacement de stockage, et les outils qui y accèdent. Des solutions comme Venafi TLS Protect ou Keyfactor Command automatisent cet inventaire. L'important est la continuité : l'inventaire doit être mis à jour en temps réel, pas une fois par an lors d'un audit.

La CA racine offline avec procédure testée. La CA racine doit être stockée hors ligne — physiquement dans un coffre, sur un support chiffré, avec une procédure de mise en service documentée et testée au moins une fois par an. Testée est le mot clé. La clé privée de la CA racine doit idéalement être protégée par un HSM physique (nShield de Thales, Luna de SafeNet, ou équivalent).

L'audit régulier des templates AD CS. Un audit des configurations AD CS devrait être inclus dans tout test d'intrusion interne. Les outils Certify (SpecterOps), certipy (ly4k) ou PSPKIAudit permettent d'identifier rapidement les configurations ESC1 à ESC13 dans un environnement AD CS. Ces audits devraient être réalisés au minimum annuellement, et après chaque modification de la configuration PKI ou de l'Active Directory.

La surveillance de l'émission en temps réel. Les Event ID 4886 (demande de certificat reçue) et 4887 (certificat émis) doivent être collectés et envoyés au SIEM. Des règles de détection doivent alerter sur l'émission d'un certificat pour un compte admin, l'émission en dehors des plages horaires habituelles, l'émission depuis une machine autre que les systèmes d'administration PKI autorisés, et les demandes avec des Subject Alternative Names inhabituels.

La réduction des durées de vie. Les certificats à longue durée de vie sont des risques permanents. La tendance va vers des certificats à très courte durée de vie (SLDC — Short-Lived Digital Certificates) : 90 jours pour les serveurs, 24 heures pour les workloads Kubernetes. Cette approche force l'automatisation du renouvellement via le protocole ACME ou cert-manager, et réduit la fenêtre d'exploitation d'un certificat compromis. Si vous ne pouvez pas encore automatiser, visez un an maximum pour les certificats serveur.

Le test régulier de la révocation. La révocation ne vaut rien si elle ne fonctionne pas. Planifiez des tests trimestriels : émettez un certificat de test, révoquez-le, vérifiez que les clients détectent la révocation via OCSP et CRL depuis les segments réseau pertinents. Activez le stapling OCSP sur vos serveurs web. Documentez les résultats et les actions correctives.

Mon avis d'expert

La compromission PKI est le scénario que les équipes de sécurité redoutent le plus — et que le moins préparent. C'est rationnel à court terme : les incidents PKI sont rares, peu spectaculaires, et difficiles à justifier dans un budget sécurité face à des menaces plus visibles comme le phishing ou le ransomware classique. Mais quand ça arrive, c'est catastrophique : révocation et re-émission en masse, redémarrage de services qui refusent les nouveaux certificats, et une fenêtre d'incertitude pendant laquelle vous ne savez pas quels systèmes faire confiance.

Ce que montre l'incident AB InBev, c'est que les ransomwares modernes ne cherchent plus seulement à chiffrer et extorquer — ils cartographient et exfiltrent les actifs d'identité pour créer plusieurs vecteurs de monétisation. Dans ce contexte, la PKI doit être traitée comme une infrastructure de niveau 0, au même titre que l'Active Directory et les hyperviseurs. Les équipes qui n'ont pas encore fait ce travail feraient bien de changer de priorité — pas dans six mois, maintenant.

Par où commencer si votre PKI n'a jamais été auditée

Si vous ne savez pas par où commencer, voici la séquence que je recommande aux clients qui n'ont jamais fait d'audit PKI formel :

Étape 1 — Inventaire express (1 semaine). Utilisez certutil sur Windows (certutil -store My, certutil -ca.cert) pour cartographier vos CA et vos certificats critiques. Identifiez la CA racine et ses intermédiaires, leurs localisations physiques ou virtuelles, et qui a accès à quoi. C'est souvent la première fois que l'organisation a une vue complète de sa PKI.

Étape 2 — Audit des templates AD CS (2 jours). Si vous utilisez AD CS, lancez Certify ou certipy en mode audit — pas d'exploitation, seulement de l'énumération — pour identifier les templates vulnérables. Cherchez spécifiquement ESC1 : CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT combiné avec Authenticated Users dans les permissions d'enrollment. C'est la configuration la plus répandue et la plus exploitable.

Étape 3 — Test de révocation (1 jour). Testez concrètement que vos points de distribution CRL sont accessibles depuis les segments réseau pertinents. Depuis un poste client standard et depuis un serveur en DMZ, essayez d'accéder aux URLs CRL de vos CA. Si c'est inaccessible, votre révocation ne fonctionne pas — peu importe ce que dit votre documentation.

Étape 4 — Vérification offline de la CA racine (1 jour). Vérifiez que votre CA racine est bien hors ligne et que la procédure de mise en service existe, est à jour et a été testée. Si elle tourne sur une VM allumée en permanence, c'est votre première priorité de correction.

Étape 5 — Activation de la surveillance (1 semaine). Configurez la collecte des Event IDs PKI dans votre SIEM et créez une règle d'alerte basique sur l'émission de certificats en dehors de vos templates standards ou en dehors des heures ouvrées. Ce n'est pas parfait, mais c'est infiniment mieux que rien.

Ces cinq étapes constituent un diagnostic de départ, pas un programme complet. Mais dans la grande majorité des organisations, elles révèlent au minimum deux ou trois points critiques à corriger immédiatement — et justifient un programme de remédiation PKI plus structuré.

Conclusion

L'incident AB InBev est un signal supplémentaire dans une tendance claire : la PKI interne est passée du statut d'infrastructure boring mais critique à celui de cible explicite des APT et des ransomwares sophistiqués. Les attaquants ont compris la valeur des certificats internes avant que beaucoup d'équipes de sécurité ne l'aient intégré dans leur modèle de menace.

Traiter sa PKI comme une infrastructure de niveau 0 n'est plus optionnel. Cela signifie un inventaire continu, une surveillance de l'émission, des audits réguliers des configurations, et des exercices de révocation testés en conditions réelles. Ce n'est pas glamour, mais c'est ce qui fait la différence quand un attaquant cherche à se fondre dans vos communications internes avec une identité certifiée valide.

Besoin d'un regard expert sur votre sécurité ?

Discutons de votre contexte spécifique et de l'état de votre PKI interne.

Prendre contact