DigiCert vient de divulguer les détails d’une compromission qui en dit long sur l’ingéniosité des attaquants modernes. En effet, ces derniers ne forcent plus la porte d’entrée : ils sonnent gentiment au support client. Voici le déroulé complet de l’attaque.
L’attaque : un faux ticket support comme cheval de Troie
D’abord, l’incident commence début avril 2026. Un attaquant sophistiqué contacte l’équipe support de DigiCert via un canal de chat Salesforce. Sa stratégie ? Se faire passer pour un client en difficulté.
Ensuite, il envoie de manière répétée une archive ZIP. Cette archive prétend contenir une simple capture d’écran du problème rencontré. Cependant, à l’intérieur du ZIP se cache un fichier exécutable au format .scr (screensaver Windows). Ce fichier embarque une charge malveillante.
DigiCert dispose pourtant de défenses solides. Ainsi, les quatre premières tentatives échouent. Mais l’attaquant insiste. Et à la cinquième tentative, le piège fonctionne enfin. Un analyste support ouvre l’archive. Le fichier .scr s’exécute. Le poste tombe.
Le rôle de CrowdStrike dans la brèche
Là où l’histoire devient particulièrement intéressante, c’est le rôle joué par l’EDR. Sur ce poste précis, le capteur CrowdStrike Falcon dysfonctionnait au moment de l’attaque. Par conséquent, la compromission est passée totalement inaperçue lors du triage initial de l’incident.
Cette anecdote rappelle une réalité gênante. En effet, même les outils de détection les plus réputés laissent parfois passer des menaces. C’est particulièrement vrai quand le capteur lui-même rencontre un problème. La défense en profondeur reste donc indispensable.
Comment les pirates ont exploité le portail de support
Une fois sur le poste compromis, les attaquants accèdent au portail de support interne de DigiCert. Ils utilisent ensuite un outil bien particulier. Cet outil permet aux analystes de voir les comptes du point de vue du client.
Heureusement, cet accès reste limité. Par exemple, les attaquants ne peuvent ni soumettre de nouvelles commandes, ni changer les mots de passe. Cependant, l’outil expose une faille critique : il affiche les codes d’initialisation des certificats EV de signature de code. Or, ces codes concernent des commandes déjà approuvées mais pas encore livrées.
Munis de ces codes et des commandes approuvées, les attaquants peuvent alors générer des certificats valides. Ils le font sur plusieurs comptes clients à la fois.
La chaîne d’attaque en un coup d’œil
Le schéma ci-dessus retrace les étapes clés. Du faux ticket Salesforce jusqu’aux 60 certificats EV émis frauduleusement, puis à leur usage pour signer Zhong Stealer.
L’ampleur du vol : 60 certificats sous des marques connues
DigiCert a identifié l’ampleur exacte du vol. Au total, les attaquants ont généré 60 certificats EV de signature de code sur quatre autorités de certification différentes.
Le détail fait froid dans le dos. En effet, les pirates ont émis ces certificats au nom de grandes entreprises technologiques légitimes :
- Lenovo (constructeur de PC)
- Kingston (mémoire et stockage)
- Shuttle Inc. (mini-PC)
- Palit Microsystems (cartes graphiques)
Sur les 60 certificats volés, au moins 27 ont été explicitement liés à de l’activité malveillante. Des membres de la communauté cybersécurité ont en effet repéré ces certificats sur des binaires signés. Les attaquants les ont utilisés pour signer numériquement le malware Zhong Stealer, une famille connue. Par précaution stricte, DigiCert a finalement traité l’intégralité des 60 certificats comme compromis.
Pourquoi c’est dangereux pour tout l’écosystème
Un certificat EV de signature de code n’est pas un certificat ordinaire. Il offre en effet le plus haut niveau de confiance auprès des systèmes Windows et des antivirus. Ainsi, un binaire signé EV passe souvent les contrôles SmartScreen sans avertissement.
Concrètement, cela signifie ceci. Quand Zhong Stealer arrive signé Lenovo ou Kingston :
- Windows ne déclenche aucune alerte SmartScreen.
- Les antivirus baissent leur niveau de méfiance par défaut.
- L’utilisateur voit un éditeur réputé et clique sans hésiter.
- Les analyses statiques classent souvent le binaire comme légitime.
Par conséquent, le malware s’installe avec une crédibilité usurpée. C’est précisément l’objectif d’une attaque sur la chaîne de confiance PKI.
La réponse de DigiCert
DigiCert a mesuré l’ampleur de la brèche à la mi-avril. La société a alors agi vite, comme rapporté par Mozilla.
Voici les mesures prises :
- Révocation de tous les certificats compromis en moins de 24 heures après la découverte.
- Annulation de toutes les commandes en attente exposées pendant la fenêtre de compromission.
- Masquage immédiat des codes d’initialisation côté interface utilisateur ET côté API. Ce changement ferme définitivement la fenêtre exploitée par l’attaquant.
- Suspension des comptes des analystes affectés.
- Désactivation d’Okta FastPass sur le portail de support.
- Renforcement des exigences MFA pour tous les accès sensibles.
Les leçons de cet incident
Cet incident illustre plusieurs réalités importantes. D’abord, l’ingénierie sociale ciblée reste redoutablement efficace. En effet, l’attaquant n’a pas exploité une faille technique : il a simplement persisté jusqu’à ce qu’un humain craque.
Ensuite, les outils EDR ne sont pas infaillibles. Un capteur défaillant suffit parfois à ouvrir la voie. La défense en profondeur reste donc cruciale.
Par ailleurs, les portails de support internes méritent autant d’attention que les systèmes de production. En effet, ils manipulent souvent des informations sensibles que les attaquants convoitent.
Enfin, cet incident a eu une suite cocasse. Quelques semaines plus tard, Microsoft Defender a faussement signalé deux certificats racine DigiCert comme malware. Ce faux positif venait justement d’une signature ajoutée pour bloquer les certificats compromis. Heureusement, la signature était mal calibrée et Microsoft l’a rapidement corrigée.
