Attaque DigiCert via fichier screensaver : ce que le vol de certificats EV change pour la défense anti-malware

Un fichier qui ressemble à une simple capture d’écran, un canal de support client, puis une chaîne de confiance logicielle mise sous pression : l’incident DigiCert d’avril 2026 rappelle qu’en cybersécurité, le danger ne vient pas toujours d’une faille spectaculaire. Selon la description d’incident documentée chez Mozilla, un attaquant a contacté le support DigiCert le 2 avril 2026 via un chat client et a transmis une archive ZIP présentée comme une capture d’écran, mais contenant en réalité un fichier .scr malveillant, un format associé aux économiseurs d’écran Windows .

La suite est plus sensible : via des systèmes de support compromis, l’attaquant a pu obtenir des codes d’initialisation pour un nombre limité de certificats de signature de code ; certains ont ensuite été utilisés pour signer des malwares .

Ce qui s’est passé, étape par étape

Le scénario décrit par les sources relève d’un social engineering ciblé contre le support de DigiCert. Help Net Security résume le point de départ de la même manière : une archive ZIP déguisée en capture d’écran client contenait un fichier .scr doté d’une charge malveillante .

D’après SecurityWeek, le malware a infecté deux terminaux : le premier aurait été détecté le 3 avril, le second le 14 avril . Depuis un système compromis, les attaquants auraient ensuite pivoté vers un portail de support interne . Ce portail donnait à des analystes support authentifiés une capacité limitée à accéder à certains comptes clients ; cette fonction permettait notamment d’atteindre des éléments comme les codes d’initialisation de certificats en attente . BleepingComputer décrit aussi un périmètre limité, mais précise que l’accès exposait des codes d’initialisation associés à des certificats EV de signature de code déjà approuvés mais pas encore livrés .

Pourquoi les certificats EV de signature de code sont si convoités

La signature de code sert à établir un lien de confiance autour d’un logiciel : elle aide à vérifier son origine et à détecter d’éventuelles modifications. DigiCert, en tant qu’autorité de certification majeure, joue un rôle important dans la sécurisation des communications Internet et de la distribution logicielle ; ses certificats de signature de code sont utilisés par des éditeurs et développeurs de logiciels .

Le problème ne se limite donc pas à un accès indu à un outil de support. Le vrai enjeu est l’abus d’un mécanisme conçu pour rassurer les utilisateurs, les systèmes d’exploitation et les outils de sécurité. ThreatNoir rapporte que certains des certificats de signature de code obtenus ont servi à signer des malwares . CyberInsider décrit également un incident dans lequel des systèmes internes de support compromis et des données d’émission de certificats ont été exploités pour obtenir des certificats EV valides de signature de code ; certains certificats auraient ensuite été utilisés pour signer des malwares .

C’est précisément ce qui rend l’affaire sérieuse : un malware signé peut, au premier regard, paraître plus légitime qu’un fichier non signé. Vectra décrit ce mode opératoire de façon générale : des acteurs malveillants peuvent utiliser des certificats EV pour signer des fichiers malveillants et profiter de la confiance renforcée associée aux applications signées EV ; les organisations qui s’en remettent uniquement à la confiance par signature restent alors vulnérables .

Ce que les sources ne disent pas

Il faut aussi éviter de tirer des conclusions excessives. Les rapports disponibles décrivent des terminaux de support compromis, des fonctions internes de support et un accès à des codes d’initialisation . Ils ne documentent pas une compromission des clés racines de DigiCert ni des clés d’autorité de certification.

Cela ne rend pas l’incident anodin. Mais, sur la base des éléments publiés, il s’agit d’un abus d’un processus de support et d’émission autour de certificats de signature de code, pas d’une prise de contrôle complète de l’autorité de certification .

Combien de certificats ont été touchés ?

Les chiffres publics ne se recoupent pas parfaitement, car les sources ne parlent pas toujours de la même catégorie de certificats : obtenus, utilisés ou révoqués.

• ThreatNoir évoque un nombre limité de certificats de signature de code, dont certains ont servi à signer des malwares .
• Risky Business parle de 27 certificats de signature de code volés, ensuite utilisés pour signer des malwares .
• ThreatLocker indique que 60 certificats de signature de code ont été révoqués au total .

Pour interpréter ces chiffres, la nuance est essentielle. Un certificat obtenu n’est pas forcément un certificat effectivement utilisé, et un certificat révoqué peut relever d’une mesure de précaution plus large. Même limité, l’incident reste important : quelques certificats valides en apparence peuvent suffire à donner à une campagne de malware une façade de légitimité .

Révocation, annulation : les mesures de confinement

Selon BleepingComputer, DigiCert a révoqué les certificats identifiés dans les 24 heures suivant leur découverte et a fixé la date de révocation à leur date d’émission . Les commandes en attente dans la fenêtre concernée ont aussi été annulées par précaution . ThreatNoir rapporte également que les certificats concernés ont été révoqués sous 24 heures et que les commandes en attente dans la période touchée ont été annulées .

La révocation limite les usages ultérieurs, mais elle ne clôt pas le travail des défenseurs. Les équipes de sécurité doivent encore analyser les fichiers signés à partir des données de certificat, des empreintes de fichiers, du comportement observé et du contexte de threat intelligence, car les signatures EV peuvent être utilisées comme leurre de confiance .

L’effet secondaire Microsoft Defender : vraie crise, faux positifs

L’incident a aussi été accompagné d’une confusion côté détection. BleepingComputer a rapporté que Microsoft Defender avait signalé à tort des certificats DigiCert comme Trojan:Win32/Cerdigent.A!dha . Daily.dev indique que Defender a marqué par erreur des certificats racines DigiCert légitimes après une mise à jour de signatures du 30 avril ; Microsoft aurait ensuite corrigé le problème avec la mise à jour Security Intelligence 1.449.430.0, qui restaurait aussi les certificats supprimés .

Pour les entreprises, c’était un casse-tête très concret : distinguer un abus réel de certificats, des alertes potentielles sur des malwares signés et des faux positifs visant des certificats légitimes .

Ce que les équipes sécurité doivent retenir

La conclusion n’est pas que la signature de code ne sert plus à rien. Elle reste un élément clé de la confiance logicielle. Mais elle ne doit jamais être le seul critère de décision.

Concrètement :

• Vérifier les signatures, sans les accepter aveuglément. Une signature valide, même EV, ne doit pas suffire à déclarer un fichier sûr ; des attaquants peuvent utiliser des certificats EV pour signer des fichiers malveillants .
• Regarder les détails du certificat. Émetteur, numéro de série, chaîne de certification, horodatage et statut de révocation comptent lorsqu’un binaire signé paraît suspect ; dans le cas DigiCert, la révocation et le retour de la date de révocation à la date d’émission ont fait partie des mesures de confinement centrales .
• Prioriser le comportement du fichier. Empreintes, processus lancés, connexions réseau, persistance, résultats de sandbox et contexte de menace doivent être évalués avec la signature, car un malware signé cherche justement à exploiter la confiance .
• Traiter les portails support et admin comme des zones à haut risque. L’incident montre que des fonctions de support apparemment limitées peuvent devenir critiques si elles donnent accès à des comptes clients ou à des codes d’initialisation liés à des certificats .
• Gérer les faux positifs avec méthode. Les alertes de certificat ne signifient pas automatiquement infection : dans l’épisode Microsoft Defender, des certificats racines DigiCert légitimes ont été signalés à tort, puis restaurés via une mise à jour Microsoft selon Daily.dev .

En bref

L’affaire DigiCert est préoccupante parce qu’elle a permis d’utiliser contre les défenseurs un mécanisme censé renforcer la confiance : la signature de code EV. Les éléments disponibles pointent vers un incident limité autour de systèmes de support, de codes d’initialisation et de certificats abusés, sans preuve publiée d’une compromission des clés racines ou des clés d’autorité de certification . La conséquence pratique est pourtant nette : dans la défense anti-malware moderne, une signature numérique ne doit jamais avoir le dernier mot.