Laboratoire montre l'exécution de code dans l'enclave Windows SFAPE (CVE-2026-83498) et patch

Les chercheurs de l'entreprise Doyensec ont montré en laboratoire qu'il est possible d'exécuter le code choisi par un attaquant dans une partie de la mémoire Windows qui devrait rester scellée même lorsque le reste du système a été compromis. Le composant affecté est une bibliothèque VBS (Virtualization-Based Security) utilisée par la fonction de Protection de Phishing Enhanced de Microsoft - en particulier l'enclave SFAPE.dll - et Microsoft corrige la vulnérabilité dans le patch cumulatif publié le 8 septembre 2026 (KB5124008). L'échec apparaît comme CVE-2026-83498, a été décrit par Microsoft comme "lifting privilèges" avec une sévérité critique (CVSS 7.8).

D'un point de vue technique, l'architecture VBS isole les librairies signées - enclaves - dans un monde de plus grande confiance géré par l'hyperspectateur Windows (VTL1 ou Mode utilisateur isolé). Un processus système dans le monde ordinaire (VTL0), tel que LSASS.exe - qui gère les identifiants et fonctionne comme SYSTEM - peut charger l'enclave mais pas lire ou modifier sa mémoire. L'objectif est de protéger les secrets critiques (par exemple les hachages de mot de passe pour la protection anti-phishing) même si un attaquant a obtenu des privilèges dans le noyau ou le SYSTEME.

Ce que les chercheurs ont obtenu n'était pas une porte d'entrée éloignée, mais une escalade de l'intérieur: l'opération exige que le code local existe déjà avec un faible accès à l'équipement et la possibilité d'invoquer l'enclave chargée par LSASS. Doyensec documente une chaîne de défaillances enchaînées : un second appel à la fonction Initiative fait écrire à l'enclave une valeur d'erreur fixe de quatre octets dans une direction contrôlée par le processus d'appel ; ce second appel omet une vérification qui fait la première invocation. Cette seule écriture est limitée, mais si elle affecte les données que l'enclave utilise pour distinguer sa propre mémoire de celle de l'hôte, les contrôles de sécurité cessent de fonctionner. A partir de là, un bug de timing dans une autre fonction vous permet de forcer une suppression contrôlée qui redirige une recherche interne, ce qui entraîne des lectures et des écritures qui vous permettent de remplacer la table de fonction qui décide quel code peut exécuter l'enclave. Le résultat final décrit par Doyensec est l'exécution du code choisi par l'attaquant dans l'enclave.

Il est important de séparer les faits confirmés des extrapolations : est montré en laboratoire que l'enclave vulnérable peut être manipulée pour exécuter le code arbitraire, et Microsoft et Doyensec conviennent que l'atténuation corrige ces vecteurs. Il n'y a aucune preuve publique d'exploitation dans des environnements réels ou de vol de mot de passe prouvé de cette défaillance; Microsoft définit l'impact comme une possible filtration de données ou exécution de code dans l'enclave. La recherche de Doyensec ne prétend pas non plus avoir récupéré des hachages de mots de passe utilisateur sur des équipements réels - qui restent non confirmés - mais le contrôle de l'enclave ouvre ce risque théorique si associé à d'autres conditions d'attaque.

Microsoft a publié la correction dans sa mise à jour cumulative pour Windows 11 (versions 24H2 et 25H2) le 8 septembre 2026 et, selon Doyensec, le fichier patché ajoute le contrôle de la direction avant la première écriture et durcit la fonction affectée par la condition de course. En outre, la mise à jour installe une politique qui empêche le chargement de l'ancienne version vulnérable de SFAPE.dll, de sorte que les systèmes mis à jour n'exécutent pas l'enclave dangereuse. Il n'existe pas de procédure alternative distincte: l'action recommandée pour tous les utilisateurs est d'installer la mise à jour correspondante.

Toutefois, la stratégie globale d'atténuation présente toujours une lacune : Windows n'a pas de liste globale de verrouillage pour les enclaves vulnérables, similaire à celle qu'il conserve pour les pilotes. L'atténuation appliquée en septembre bloque seulement la version affectée de SFAPE.dll; Doyensec avertit que d'autres enclaves signées avec des défaillances connues peuvent continuer à être chargées - par exemple, une enclave Microsoft Edge avec CVE-2023-36880 qui avait une vulnérabilité de lecture / d'écriture reste, selon Doyensec, autorisée. Cette différence peut laisser ouverte la tactique connue sous le nom de « mettre votre propre enclave vulnérable », dans laquelle un attaquant charge délibérément une enclave signée mais imparfaite pour cacher du code ou des données devant des outils de sécurité, une technique discutée dans des travaux antérieurs de l'industrie.

Qui cela affecte - t - il? En pratique, le plus grand risque est pour les environnements où un attaquant peut exécuter du code avec des privilèges bas à moyen sur la machine cible - par exemple, par une explosion locale, un service mal configuré ou un accès physique - et où LSASS ou autre procédé privilégié charge l'enclave vulnérable. Les équipements et systèmes isolés sans comptes locaux exposés sont moins susceptibles d'être objectifs, mais dans les organisations avec des utilisateurs qui atteignent l'altitude locale avec une relative facilité (des phisings plus tard, de mauvaises configurations RDP, ou un logiciel qui permet l'exécution de code), le vecteur est pertinent.

Recommandations spécifiques et vérifiables: installer la mise à jour KB5124008 ou appliquez les politiques de mise à jour Windows que votre organisation utilise; c'est la seule mesure offerte par Microsoft pour atténuer ce défaut. Vérifiez l'état de mise à jour sur les serveurs et les terminaux sous Windows 11 24H2 / 25H2 et prioriser les machines avec des comptes administratifs ou des services qui chargent des enclaves. Pour les environnements d'affaires, intégrer le patch dans votre cycle de gestion des patchs et confirmer la présence de la politique qui bloque l'ancienne version de SFAPe.dll.

Plus de mesures défensives qui réduisent la probabilité et l'impact de telles attaques comprennent la limitation de l'accès privilégié local, la désactivation des services inutiles qui permettent l'exécution de code, l'application du principe de moindre privilège, et le déploiement de solutions EDR qui surveillent les charges et les appels à des processus sensibles tels que LSASS. Activer et maintenir à jour l'atténuation de la sécurité basée sur la virtualisation (HVCI) et l'utilisation d'applications permettant le contrôle de liste aide à réduire la surface d'attaque. Pour les équipements essentiels, vérifier les enclaves chargées et les signatures de contraste et les versions avec les sources officielles après le patch.

Enfin, il est nécessaire de suivre deux fronts : d'une part, de confirmer l'installation du patch sur tous les terminaux et serveurs ; d'autre part, de presser les fabricants pour mettre en place un mécanisme de verrouillage centralisé pour les enclaves défectueuses signées, tel qu'il existe pour les pilotes, de sorte qu'il n'existe pas de techniques de « mise en place de votre propre enclave vulnérable ». Pour la documentation technique sur VBS et l'isolement fourni par les enclaves, Microsoft conserve les documents sur son portail de documentation: https: / / learn.microsoft.com / fr-us / windows / sécurité / virtualisation-based-security /. La recherche Doyensec est publiée par l'entreprise et est disponible sur son site comme référence sur la méthodologie et l'analyse: https: / / doyensec.com /.

En résumé : la conclusion montre que, même en couches conçues pour contenir des secrets devant un noyau compromis, les erreurs logiques et de synchronisation peuvent permettre à l'attaquant d'augmenter sa présence et de cacher le code dans ce niveau fiable. L'atténuation existe et doit être mise en œuvre d'urgence; un débat ouvert porte sur la façon d'empêcher que d'autres enclaves signées et vulnérables ne soient disponibles à l'avenir pour des exploitations similaires.