Bug Microsoft Defender
pourquoi des certificats DigiCert légitimes ont été pris pour un cheval de Troie.

Le faux positif est apparu après l’ajout de nouvelles détections dans Microsoft Defender le 30 avril 2026. Ces signatures avaient été conçues pour repérer des certificats de signature de code frauduleux apparus dans le contexte d’un incident distinct chez DigiCert.

Le 3 mai, les premiers signalements se sont multipliés chez des administrateurs système et des utilisateurs. Defender identifiait des certificats DigiCert présents dans le magasin de confiance de Windows comme étant associés à « Trojan:Win32/Cerdigent.A!dha ». BleepingComputer a documenté le phénomène le jour même, avec confirmation ultérieure de Microsoft.

Microsoft a reconnu que ses alertes avaient été déclenchées par erreur. L’entreprise a expliqué avoir mis à jour sa logique de détection, puis diffusé une nouvelle version de ses renseignements de sécurité afin de ne plus considérer les certificats racines légitimes comme malveillants.

La définition 1.449.430.0, publiée le 3 mai, est la version de référence citée par Microsoft et les retours techniques comme corrigeant le faux positif. Les systèmes mis à jour automatiquement ont cessé de signaler les racines concernées, et les certificats retirés ont pu être restaurés automatiquement.

Cette chronologie rappelle que même une mise à jour destinée à renforcer la sécurité peut avoir des effets de bord. Nous avons déjà observé la même logique dans les incidents Patch Tuesday affectant BitLocker : le problème ne vient pas toujours d’une attaque, mais parfois d’un correctif ou d’une règle de détection trop agressive.

Les signalements publics ont identifié deux certificats racines DigiCert présents dans le magasin de confiance Windows. Ces certificats servent de point d’ancrage à des chaînes de certification utilisées par de nombreux services, sites et logiciels.

Le premier correspond au certificat DigiCert Assured ID Root CA, dont l’empreinte SHA-1 publiée est 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43.

Le second est DigiCert Trusted Root G4, avec l’empreinte SHA-1 DDFB16CD4931C973A2037D3FC83A4D7D775D05E4. Microsoft Q&A et DigiCert ont tous deux confirmé que cette empreinte correspondait bien à un certificat racine officiel et légitime.

Le point essentiel est que ces racines n’avaient pas été compromises. Defender les avait confondues avec des certificats frauduleux liés à un incident séparé. Cette différence change complètement la réponse à apporter : il n’était pas nécessaire de supprimer définitivement DigiCert ou de réinstaller Windows, mais simplement d’appliquer les définitions corrigées.

La cause publique est relativement claire : Microsoft a ajouté une logique de détection destinée à identifier des certificats de signature de code frauduleux qui avaient servi à signer des logiciels malveillants. Cette logique a été trop large et a capturé des certificats DigiCert légitimes qui ne faisaient pas partie de la compromission.

Le faux positif est donc un exemple classique de sur-détection. Dans un antivirus, une signature ou une règle comportementale doit être suffisamment large pour capturer les variantes d’une menace, mais suffisamment précise pour éviter de bloquer des composants sains.

Ici, la confusion était particulièrement sensible car elle touchait des certificats racines. Une racine de confiance n’est pas un simple fichier quelconque : elle permet à Windows et aux applications de vérifier qu’un certificat intermédiaire ou final appartient bien à une chaîne approuvée.

Quand Defender a retiré une racine du magasin de confiance sur certaines machines, ce n’est pas seulement une alerte visuelle qui est apparue. Des logiciels ou services dépendant de cette chaîne pouvaient alors se comporter comme si un certificat parfaitement valide n’était plus digne de confiance.

Ce type d’erreur montre pourquoi la cybersécurité repose autant sur la précision que sur l’agressivité. Une protection qui bloque trop peut produire un effet opérationnel proche d’une panne. C’est une logique comparable à celle que l’on retrouve lors des incidents affectant des infrastructures de messagerie ou de certification : le problème n’est pas uniquement la donnée ou le fichier, mais tout ce qui dépend de la confiance accordée à cette infrastructure.

Le contexte du faux positif vient d’un autre incident survenu en avril 2026. ThreatLocker a documenté une opération d’ingénierie sociale visant le support de DigiCert. Des attaquants ont envoyé des fichiers ZIP malveillants en se faisant passer pour des clients ayant besoin d’assistance.

Selon cette analyse, l’un de ces fichiers contenait un écran de veille Windows malveillant. Après plusieurs tentatives, le code a atteint des systèmes de support disposant d’un accès permettant d’interagir avec des comptes clients et des opérations de certificats.

L’attaque a finalement permis l’obtention frauduleuse de certificats de signature de code EV. DigiCert a révoqué 60 certificats de signature de code dans le cadre de la réponse à l’incident. DigiCert précise aujourd’hui qu’il s’agissait d’un nombre limité de certificats mal émis et qu’aucune preuve ne montre un impact plus large sur les certificats racines, les comptes, les données ou les systèmes généraux de ses clients.

Le fichier source associait cet incident à Zhong Stealer et à plusieurs groupes chinois avec un niveau de certitude trop élevé. Les analyses techniques ont bien relié certains certificats frauduleux à des logiciels malveillants et à des campagnes de vol d’informations, mais il est plus prudent de ne pas présenter chaque attribution de groupe comme un fait officiel DigiCert ou Microsoft.

La distinction la plus importante reste donc simple : les certificats frauduleux de signature de code ont été révoqués ; les deux certificats racines ensuite signalés par Defender n’étaient pas compromis.

Cette nuance évite une erreur fréquente en cybersécurité : confondre un incident de chaîne de certification avec la compromission d’une autorité racine entière. Une véritable compromission de racine aurait eu des conséquences beaucoup plus graves et aurait nécessité une réponse radicalement différente.

Microsoft a modifié sa logique de détection puis distribué la définition 1.449.430.0 le 3 mai 2026. La page officielle des mises à jour Microsoft Security Intelligence confirme la publication de cette version à cette date.

Les retours Microsoft Q&A indiquent que le faux positif ne se reproduit plus à partir de cette définition. DigiCert précise de son côté qu’après la mise à jour, les certificats légitimes incorrectement supprimés doivent être restaurés automatiquement.

Il n’est donc plus pertinent, en septembre 2026, de conseiller aux particuliers de lancer des procédures manuelles complexes. La très grande majorité des machines Windows utilisant les mises à jour automatiques disposent depuis longtemps d’une définition largement supérieure à 1.449.430.0.

La bonne pratique reste de vérifier que Microsoft Defender reçoit ses mises à jour de renseignements de sécurité. Dans un parc d’entreprise, les administrateurs peuvent également contrôler les politiques de sécurité et les journaux afin de confirmer qu’aucun certificat n’a été supprimé manuellement ou laissé dans un état incohérent.

Pour un particulier dont Windows Update fonctionne normalement, il n’y a généralement rien à faire. Si votre ordinateur ne présente plus d’alerte et que Defender est à jour, l’incident de mai est clos.

Si vous rencontrez encore des problèmes HTTPS ou des applications qui refusent certaines connexions sécurisées, commencez par vérifier la date et la version des renseignements de sécurité de Microsoft Defender dans l’application Sécurité Windows.

Il est également possible de vérifier que les racines DigiCert concernées sont bien présentes dans le magasin de certificats Windows. Pour une entreprise, cette vérification peut être automatisée avec des outils d’inventaire ou PowerShell, mais elle ne doit pas conduire à réinstaller manuellement un certificat téléchargé depuis une source non vérifiée.

Dans tous les cas, ne désactivez pas Defender pour « éviter le bug ». Le problème est corrigé depuis mai. Désactiver la protection aujourd’hui supprimerait une défense réelle contre des menaces actuelles pour résoudre un faux positif qui n’est plus actif.

Les bonnes pratiques générales restent les mêmes : mises à jour automatiques, sauvegardes, contrôle des certificats et surveillance des alertes. Elles complètent les mesures plus larges de sécurisation de vos appareils et de gestion rigoureuse des données et des accès.

Enfin, si un certificat ou une alerte inhabituelle réapparaît aujourd’hui, ne supposez pas automatiquement qu’il s’agit du même bug. Les signatures Defender ont évolué depuis mai et de nouvelles alertes peuvent correspondre à de vraies menaces. Vérifiez le nom exact de la détection, l’empreinte du certificat et la version de Defender avant de conclure.