BlackX : pourquoi des PC Windows à jour ont pu être infectés avant le démarrage

Un PC Windows peut afficher toutes ses mises à jour installées et rester exposé à une ancienne méthode de contournement de Secure Boot. Le bootkit BlackX en fournit un exemple concret : les chercheurs de Kaspersky l’ont observé dans une campagne d’espionnage visant des organismes diplomatiques en Asie centrale.

Le sujet revient dans l’actualité ce 3 novembre, mais l’analyse initiale a été publiée le 22 octobre. Il ne s’agit ni d’une faille découverte aujourd’hui ni d’une infection automatique de tous les ordinateurs Windows. Dans les attaques étudiées, les intrus avaient déjà compromis les réseaux et obtenu des droits administrateur avant de déployer BlackX.

Le malware cherche à s’installer avant Windows

Un bootkit intervient très tôt dans la chaîne de démarrage, avant que Windows et une partie de ses protections aient pris la main. Secure Boot sert précisément à vérifier que les composants exécutés à ce stade sont autorisés.

BlackX exploite Baton Drop, une vulnérabilité connue sous la référence CVE-2022-21894. Son fonctionnement présente de fortes ressemblances avec BlackLotus, un autre bootkit analysé en 2023. Les chercheurs ont toutefois relevé des différences et ne présentent pas les deux programmes comme identiques.

L’objectif est de manipuler la confiance accordée aux composants de démarrage, puis de charger un pilote malveillant dans le noyau de Windows. Cela donne aux attaquants un point d’appui particulièrement sensible pour protéger leurs fichiers et déployer d’autres outils d’espionnage.

Le piège : installer un correctif ne révoque pas toujours l’ancien composant

Les machines examinées étaient à jour. Le problème était ailleurs : un ancien composant de démarrage vulnérable pouvait encore être accepté, car le certificat qui lui accordait cette confiance n’avait pas été révoqué.

Le certificat concerné est nommé Windows Production PCA 2011. Dans l’état du déploiement décrit par les chercheurs, la protection nécessite une activation supplémentaire pour empêcher les composants concernés de démarrer. La présence du correctif sur le disque ne garantit donc pas, à elle seule, que toute la chaîne de confiance a été mise à niveau.

Microsoft documente cette distinction dans sa procédure de gestion des révocations des gestionnaires de démarrage. Elle prévoit une évaluation et une activation des mesures de protection, avec des conséquences possibles pour les anciens supports d’installation et de récupération.

C’est ce décalage qui rend l’affaire intéressante : le panneau Windows Update et la confiance accordée au démarrage ne décrivent pas exactement le même état de sécurité.

Pourquoi ne pas tout bloquer automatiquement ?

Révoquer un certificat empêche aussi de lancer des composants légitimes qui s’appuient encore dessus. D’anciennes clés USB de dépannage, certains environnements de démarrage et des configurations particulières peuvent donc cesser de fonctionner.

Le déploiement progressif cherche à éviter ces blocages. Mais il crée aussi un angle mort : un administrateur habitué à installer les correctifs peut penser son travail terminé, alors qu’une étape complémentaire reste à évaluer.

Je trouve surtout problématique que cette différence soit difficile à lire pour l’utilisateur. Une protection présente mais non activée n’a pas le même effet qu’une protection opérationnelle, même lorsque les deux machines paraissent « à jour ».

Une campagne ciblée, une attribution prudente

Les organismes visés se trouvent notamment au Tadjikistan, en Ouzbékistan et au Turkménistan. Kaspersky attribue la campagne à APT41 avec un niveau de confiance moyen, à partir de plusieurs indices techniques. Cette attribution ne constitue donc pas une certitude absolue.

Les charges observées comprennent des outils de contrôle à distance et des composants capables de recevoir d’autres modules. Certains utilisent des services cloud légitimes pour leurs communications. Cela ne signifie pas que Google Drive ou OneDrive auraient eux-mêmes été piratés.

Le pilote cherche également à perturber des protections de sécurité, dont Kaspersky et Avast. Les chercheurs indiquent cependant que les routines testées n’ont pas réussi à interférer avec leurs propres produits : l’intention du code ne suffit pas à prouver son efficacité.

Ce qu’il faut vérifier sur son PC ou son parc

• Continuer les mises à jour Windows et celles du firmware : ce cas ne rend pas les correctifs inutiles.
• Conserver Secure Boot activé : le désactiver ne résout pas le problème.
• Pour les administrateurs, vérifier le déploiement des révocations : leur état doit être contrôlé séparément de la simple présence des mises à jour.
• Préparer les moyens de récupération : sauvegardes, clé BitLocker et supports de démarrage compatibles avant toute modification de la chaîne de confiance.

Je déconseille d’appliquer une commande de révocation trouvée au hasard : Microsoft précise que ces changements peuvent être difficiles à annuler et rendre d’anciens médias inutilisables. Sur un parc, la démarche passe par un test sur les différentes familles de machines. En cas de compromission suspectée, il faut une réponse à incident ; activer une protection préventive ne nettoie pas à elle seule un système infecté.