EN
en direct

BlackX contourne Secure Boot sur des Windows à jour grâce à une révocation jamais activée

Kaspersky documente BlackX, un bootkit UEFI utilisé début 2026 contre des diplomaties d’Asie centrale, qui contourne Secure Boot sur des machines pourtant à jour : le correctif Baton Drop ne prend effet que si le certificat Windows Production PCA 2011 est révoqué, une étape manuelle que presque personne n’active. Vérifiez, machine par machine, que la révocation est réellement appliquée — l’installation du patch ne suffit pas.

Un châssis de serveur scellé dont l’étiquette d’inviolabilité est déchirée, une seule fibre jaune ambre exposée à la déchirure.

Octobre 2022. Le bootkit BlackLotus est mis en vente pour 5 000 dollars, exploitant Baton Drop (CVE-2022-21894) pour contourner Secure Boot. Début 2026. Une version dérivée, BlackX, frappe des organisations diplomatiques au Tadjikistan, en Ouzbékistan et au Turkménistan. 22 octobre 2026. Kaspersky publie son rapport. Le point clé : les machines touchées étaient entièrement à jour — le problème, c’était le correctif lui-même, qui ne s’active pas tout seul.

Un correctif qui ne se déclenche pas tout seul

La découverte la plus inconfortable du rapport tient en une phrase. Les victimes avaient installé les correctifs Windows pour CVE-2022-21894, et pourtant BlackX contournait Secure Boot. La raison est documentée par Microsoft depuis 2023 mais reste méconnue : le correctif Baton Drop ne prend effet qu’une fois le certificat « Windows Production PCA 2011 » révoqué, et cette révocation n’est pas automatique lors de l’installation de la mise à jour.

Concrètement, un administrateur doit poser un drapeau de registre sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot, puis une tâche planifiée nommée Secure-Boot-Update doit s’exécuter. Kaspersky note que ces étapes sont « enfouies profondément » sur le site de Microsoft, et que la phase de mise en application automatique prévue par l’éditeur n’était toujours pas implémentée au moment de la publication.

Le certificat a expiré le 19 octobre 2026. Mais l’expiration seule ne bloque pas le chargement des binaires vulnérables — il faut qu’ils soient inscrits sur la liste de révocation. Tant que ce n’est pas fait, un attaquant peut encore signer ou réutiliser les composants de démarrage vulnérables.

BlackX n’est pas un vecteur d’accès initial. Kaspersky précise que les attaquants l’ont déployé après avoir déjà obtenu des privilèges administrateur, par une méthode non précisée. Microsoft décrit depuis longtemps ce type de bootkit comme un mécanisme de persistance et d’évasion de défense — une fois installé, il survit aux réinstallations de l’OS et se charge avant Windows.

Ce que BlackX fait une fois installé

L’installeur, inst.exe, s’appuie sur un fichier chiffré en RC4 nommé PVMDIJGKAX2, qui stocke les composants d’installation et les chaînes. Garder ces ressources hors de l’exécutable complique la collecte et l’analyse du paquet complet par les équipes d’intervention.

Une fois sur la machine, le bootkit enrôle ses propres Machine Owner Keys (MOK) pour charger des fichiers EFI arbitraires — c’est la mécanique héritée de BlackLotus. Il injecte ensuite un pilote noyau dont le certificat de signature a depuis été révoqué. Ce pilote tente de désactiver les callbacks de sécurité des processus, des threads et du registre, et perturbe les fournisseurs ETW (Event Tracing for Windows). Kaspersky note au passage que ces routines n’ont pas réussi à neutraliser ses propres produits lors des tests.

Pour protéger ses fichiers, le pilote intercepte les demandes d’ouverture de fichier et renvoie un handle vers calc.exe à la place. La charge utile d’espionnage est déposée ensuite : un RAT qui utilise Google Drive, OneDrive et Yandex.Disk pour le commande et contrôle, et un second composant, OxiDLLRunner, chargé par side-loading de DLL via un googleupdate.exe légitime. Ce dernier déchiffre v8_context_snapshot.bin pour lancer un implant Rust qui dialogue avec www[.]archivetj[.]com.

Les indicateurs publiés incluent l’installeur sous C:\ProgramData\Intel\inst.exe, le fichier chiffré PVMDIJGKAX2, et un pilote signé au nom de « Wenjiang District Mingyu Network Technology Service Studio » — certificat révoqué depuis.

Le lien vers APT41

Kaspersky relie BlackX à APT41 avec une confiance moyenne. Le lien passe par le rapport ESET de juin 2026 sur FishMonger et par le recours au side-loading de DLL, une technique de prédilection du groupe.

BlackX est évalué comme une reprise de BlackLotus. Or le code source de BlackLotus n’a jamais été rendu public : les auteurs de BlackX l’ont donc soit rétro-conçu, soit obtenu par d’autres canaux. Les différences d’implémentation relevées par les chercheurs penchent pour une réimplémentation, pas une simple copie.

Ce point change la lecture stratégique. BlackLotus n’était pas un one-shot commercial — il est devenu une base de code réutilisable pour un acteur étatique, qui l’adapte à ses propres cibles diplomatiques. La menace UEFI a changé de nature : d’un kit vendu sur un forum, elle est passée à un outil d’espionnage entretenu.

Comment vérifier si vous êtes exposé

Les machines concernées sont des Windows qui ont les correctifs Baton Drop installés mais pas la révocation du certificat Windows Production PCA 2011 appliquée. Le réflexe à corriger est de croire que « patché = protégé ».

  • Vérifiez la révocation, pas le patch. Reprenez le guide Microsoft sur la gestion des révocations du boot manager et confirmez, appareil par appareil, que les étapes de révocation ont été exécutées après la mise à jour.
  • Testez avant de déployer en masse. Kaspersky avertit qu’une révocation automatique peut casser les systèmes en dual-boot qui dépendent du certificat PCA 2011 — c’est précisément pourquoi Microsoft a rendu l’étape manuelle.
  • Chassez les indicateurs. Recherchez C:\ProgramData\Intel\inst.exe, le fichier PVMDIJGKAX2, le pilote signé « Wenjiang District Mingyu Network Technology Service Studio » et le trafic vers archivetj[.]com.
  • Interrogez l’accès initial. Puisque BlackX exige d’abord des privilèges administrateur, demandez-vous comment un tel accès a pu être obtenu sur les machines sensibles — c’est souvent là que la compromission réelle a commencé.

Verdict

Si vous gérez un parc Windows avec des postes sensibles, ne vous contentez pas du statut « à jour ». Vérifiez, machine par machine, que la révocation du certificat Windows Production PCA 2011 est réellement active — c’est la seule chose qui sépare une machine patchée d’une machine protégée face à BlackX et à ses dérivés. Si vous administrez des postes en dual-boot, testez la révocation sur un échantillon avant de généraliser, car elle peut casser le démarrage. La leçon de fond dépasse ce bootkit : un correctif de sécurité dont l’étape d’activation est manuelle et optionnelle est, en pratique, un correctif que personne n’a.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

LiteLLM 1.107.0 volait les credentials dès le démarrage de Python, sans jamais être importé

Le 21 octobre 2026, une release compromise de LiteLLM 1.107.0 a été publiée sur PyPI et dans les images Docker officielles : trois fichiers de démarrage Python exécutaient un collecteur de credentials dès l’initialisation de l’interpréteur, sans que l’application importe jamais LiteLLM. Si vous avez installé la 1.107.0, ne dégradez pas seulement la version : révoquez les credentials accessibles depuis chaque hôte affecté et reconstruisez les environnements.

← Retour au fil

Tapez au moins deux caractères.

↑ ↓ naviguer ↵ ouvrir esc fermer