DigiCert piégé par un .scr : 60 certificats EV révoqués

Ce qui s'est passé

DigiCert, l'une des plus grandes autorités de certification au monde, a publié le 4 mai 2026 un post-mortem détaillé d'une intrusion ciblée sur son support client survenue entre début et mi-avril. Le 2 avril 2026, un acteur malveillant a contacté le service support via un canal de chat basé sur Salesforce. Sous couvert d'un client réclamant assistance, il a envoyé à plusieurs reprises un fichier ZIP présenté comme une capture d'écran. À l'intérieur, un exécutable .scr (screensaver Windows) déguisé. Les défenses de poste basées sur CrowdStrike ont bloqué quatre tentatives consécutives. La cinquième est passée.

Le fichier exécuté a compromis la machine d'un analyste support. La détection a fonctionné en partie : le poste a été isolé le 3 avril 2026, soit moins de 24 heures après l'infection. Mais une seconde machine, compromise le 4 avril, est restée invisible aux outils de détection pendant dix jours. La cause documentée par DigiCert et reprise par Help Net Security et Risky Business : un capteur CrowdStrike Falcon en défaillance silencieuse sur ce poste précis. Le sensor n'envoyait plus de télémétrie au cloud, et l'absence de heartbeat n'a pas été qualifiée à temps comme une anomalie. La compromission n'a été découverte que le 14 avril.

Pendant cette fenêtre de dix jours, l'attaquant a utilisé les comptes des analystes pour pivoter dans le portail support interne de DigiCert. Il a exploité une fonctionnalité légitime mais sensible : la consultation des codes d'initialisation (init codes) des commandes de certificats EV Code Signing approuvées mais non encore livrées. Avec ces codes, il pouvait finaliser la délivrance des certificats sans repasser par la validation client. Les certificats émis ont été utilisés pour signer numériquement des binaires malveillants, leur conférant la confiance technique des grands éditeurs.

Entre le 14 et le 17 avril 2026, DigiCert a procédé à la révocation de 60 certificats EV Code Signing : 27 explicitement liés à l'attaquant, 16 découverts ultérieurement pendant l'enquête forensique, et 33 révoqués par précaution faute de pouvoir établir avec certitude qu'ils n'avaient pas été touchés. Les certificats compromis avaient été émis sous les noms de Lenovo, Kingston Technology, Shuttle Inc. et Palit Microsystems, quatre marques tech à forte légitimité dont les produits sont déployés massivement dans les parcs entreprises. L'usurpation visait précisément à exploiter la confiance Microsoft SmartScreen et Windows Defender accordée à ces éditeurs.

Le payload qui circulait sous ces signatures a été identifié comme appartenant à la famille Zhong Stealer. Les chercheurs de plusieurs équipes, dont GBHackers et CyberInsider, ont attribué la campagne à GoldenEyeDog (APT-Q-27), un groupe e-crime chinois aux liens documentés avec d'autres opérations de vol d'identifiants. Zhong Stealer cible classiquement les portefeuilles crypto, les sessions navigateur, les bases d'identifiants Edge et Chrome, et tente d'escalader vers des accès cloud lorsque possible. L'ajout d'une signature EV au binaire élève dramatiquement son taux de succès : le SmartScreen ne déclenche pas d'avertissement, et plusieurs antivirus accordent une bienveillance accrue aux exécutables signés.

Le post-mortem comporte un autre élément troublant : Microsoft Defender a, dans la phase d'enquête, par erreur signalé certains certificats racines DigiCert eux-mêmes comme malveillants. Cet incident, séparé mais concomitant, a généré une vague de faux positifs sur des chaînes de certification légitimes pendant plusieurs heures, perturbant des intégrations TLS et des signatures de pilotes en production. Les équipes Microsoft ont publié un correctif via Defender update, mais l'épisode illustre la fragilité opérationnelle des écosystèmes de confiance numérique quand un incident bouscule leur calibrage.

Côté DigiCert, plusieurs durcissements ont été annoncés. Les analystes support ne peuvent plus exécuter de fichier reçu en chat Salesforce sans sandbox, et le format .scr a été ajouté à la liste des extensions bloquées au niveau passerelle. La fonctionnalité d'accès aux init codes a été segmentée : un second contrôle exige désormais une validation du client final via un canal hors-bande avant que tout code puisse être consulté. Enfin, la supervision des sensors EDR a été renforcée pour traiter l'absence de heartbeat comme une alerte de criticité haute, et non plus comme un événement à corréler en passif.

Cet incident est l'un des rares cas publics où une autorité de certification de grade EV reconnaît avoir vu ses processus délivrer frauduleusement des certificats à un acteur malveillant. Le précédent comparable était DigiNotar en 2011, dont la chute avait conduit à la disparition de l'autorité. DigiCert prend les devants en publiant un post-mortem extrêmement détaillé, démarche saluée par la communauté mais qui ne suffira pas à éteindre la question : combien d'autres CA dépendent encore d'analystes support comme dernière barrière ?

Pourquoi c'est important

Cet incident touche directement la racine de la confiance numérique. Un certificat EV Code Signing est censé garantir qu'un binaire vient bien de l'éditeur affiché. C'est sur cette signature que reposent SmartScreen, les listes de pilotes acceptés par Windows et la majorité des règles de allow-listing en entreprise. Quand un attaquant peut faire signer un Zhong Stealer comme s'il venait de Lenovo, l'ensemble du modèle s'effondre temporairement. Les RSSI doivent considérer qu'une signature EV n'est plus, à elle seule, une garantie suffisante : elle doit être croisée avec l'origine de téléchargement, le hash du binaire, et idéalement avec une attestation reproductible de la chaîne de build.

Le mode opératoire mérite aussi attention. L'attaque ne reposait pas sur une vulnérabilité technique nouvelle. Elle a combiné trois éléments : une ingénierie sociale persistante, un fichier .scr qui exploite la confiance résiduelle des analystes support, et une dépendance organisationnelle excessive à un EDR mal supervisé. Aucun de ces vecteurs n'est inédit, mais leur combinaison reste dévastatrice. Toute organisation qui dispose d'un service support manipulant des données sensibles devrait revoir son périmètre : qui peut exécuter quoi, quels formats de pièces jointes sont acceptés, et comment l'absence de signal d'un EDR est détectée. L'angle mort des sensors muets est probablement le plus sous-estimé en SOC aujourd'hui.

Sur la chaîne logicielle, l'incident relance le débat sur la transparence des certificats Code Signing, équivalent du Certificate Transparency déjà bien établi pour TLS. Microsoft et Apple ont commencé à publier des journaux pour leurs propres autorités, mais les CA tierces ne sont pas tenues à la même obligation. Une obligation de log public pour chaque délivrance de certificat EV permettrait aux éditeurs comme Lenovo ou Kingston de détecter immédiatement les certificats qui se réclament d'eux. La proposition est en discussion au CA/Browser Forum depuis 2024 ; cet incident lui donnera vraisemblablement un coup d'accélérateur.

Pour les entreprises françaises, la lecture pratique est immédiate. D'abord, vérifier que les binaires installés depuis avril 2026, signés Lenovo, Kingston, Shuttle Inc. ou Palit Microsystems, n'appartiennent pas à la liste des certificats révoqués. Les bulletins DigiCert publient les empreintes concernées, et les outils de gestion de parc (SCCM, Intune, Tanium) peuvent générer un inventaire en quelques heures. Ensuite, mettre à jour les CRL et listes OCSP côté postes : un certificat révoqué ne sera bloqué que si la chaîne de validation est correctement actualisée. Enfin, réviser les politiques d'allow-listing fondées uniquement sur l'éditeur : la confiance ne peut plus s'arrêter à la signature, elle doit intégrer la version, le hash et le canal d'approvisionnement.

Ce qu'il faut retenir

• 60 certificats EV Code Signing DigiCert révoqués après une intrusion via un .scr envoyé en chat Salesforce au support client.
• Une fenêtre de dix jours non détectée à cause d'un capteur CrowdStrike silencieux ; l'absence de heartbeat n'avait pas été qualifiée comme alerte critique.
• Vérifier les binaires Lenovo, Kingston, Shuttle Inc. et Palit Microsystems installés depuis avril 2026, mettre à jour CRL/OCSP et durcir le contrôle d'exécution sur les postes support.