(In)Sécurité virtualisée : comment les attaquants exploitent les enclaves VBS

Les attaquants cherchent constamment de nouveaux moyens de déployer et d'exécuter des logiciels malveillants sur un hôte sans être détectés. Nous avons examiné certaines techniques novatrices pour l'exécution de logiciels malveillants dans une enclave de sécurité virtualisée (VBS) et sommes parvenus à échapper aux mesures de sécurité courantes. Le 8 août 2025, j'ai exploré cette surface d'attaque lors d'une présentation à la DEF CON 33 qui s'est tenue à Las Vegas.

La VBS, composante de l'architecture de sécurité de Microsoft, crée un environnement virtuel destiné à isoler les fonctions critiques du système d'exploitation. Les enclaves VBS permettent l'isolation d'une zone d'un processus, la rendant inaccessible aux autres processus, au processus proprement dit et même au noyau. 

Bien que les enclaves VBS renforcent la sécurité, elles peuvent également ouvrir la voie à de nouvelles opportunités d'exploitation pour les pirates. En effet, les logiciels malveillants qui s'exécutent dans une enclave peuvent échapper à la détection basée sur la mémoire et aux analyses fréquemment utilisées. Nous avons étudié cette idée et découvert plusieurs façons d'exploiter les enclaves VBS.

Il est important de comprendre le concept des niveaux de confiance virtuelle (VTL) sous-jacents des enclaves VBS. Chaque niveau de confiance accorde aux entités exécutées sous celui-ci des autorisations d'accès différentes à la mémoire physique. Les VTL inférieurs ne peuvent pas accéder à la mémoire des VTL supérieurs. 

Windows utilise actuellement deux niveaux de confiance principaux :  VTL0, utilisé pour exécuter les composants traditionnels du système d'exploitation, y compris le mode noyau normal et le mode utilisateur normal ; et VTL1, qui dispose de davantage de privilèges que VTL0 et crée deux nouveaux modes d'exécution : le mode noyau sécurisé et le mode utilisateur isolé.

• Le mode noyau sécurisé est utilisé pour exécuter le noyau sécurisé, qui s'exécute en VTL1 et qui dispose donc de davantage de privilèges que le noyau normal. Le noyau sécurisé peut appliquer des règles au noyau normal et restreindre son accès aux zones de mémoire sensibles. Le noyau sécurisé est très étroit et ne prend pas en charge les pilotes tiers, sa surface d'attaque est donc considérablement réduite.
• Le mode utilisateur isolé est utilisé pour exécuter des processus sécurisés, un type spécial de processus en mode utilisateur qui utilise les capacités d'isolation de la mémoire du VTL1. Aucun code VTL0, y compris le noyau normal, ne peut accéder à la mémoire à l'intérieur du mode utilisateur isolé.

Rassemblés, VTL0 et VTL1 offrent quatre modes d'exécution : 

• Ring0 VTL0 — Mode noyau normal
• Ring0 VTL1 — Mode noyau sécurisé
• Ring3 VTL0 — Mode utilisateur normal
• Ring3 VTL1 — Mode utilisateur isolé

Les enclaves VBS créent une section d'un processus en mode utilisateur qui réside dans un mode utilisateur isolé, dans laquelle nous pouvons charger des DLL appelées « modules d'enclave ». Ces modules constituent un « environnement d'exécution de confiance » contenant des données et du code inaccessibles à tout ce qui s'exécute dans le VTL0. Cela facilite l'isolation des opérations sensibles des attaquants capables de compromettre le système.

L'accès à VTL1 étant restreint, le chargement d'une DLL dans une enclave nécessite qu'elle soit correctement signée à l'aide d'un certificat spécial émis par Microsoft. Toute tentative de chargement d'un module sans cette signature échouera. Bien que seuls des tiers de confiance puissent signer des modules d'enclave, il n'existe aucune restriction quant aux personnes autorisées à charger ces modules : tant qu'ils sont signés, n'importe quel processus peut charger des modules arbitraires dans une enclave.

Les enclaves VBS suscitent l'intérêt des attaquants pour deux raisons. La première est que l'espace d'adressage des enclaves est inaccessible à tout ce qui s'exécute en VTL0, y compris les outils de détection et réponse aux points de terminaison (EDR) et d'analyse. La seconde est que les appels d'API effectués à l'intérieur d'une enclave peuvent être invisibles pour les EDR.

Nous avons donc étudié la manière dont les attaquants pouvaient exécuter un code malveillant à l'intérieur d'une enclave. En outre, nous avons exploré les techniques qu'ils pouvaient utiliser une fois leur logiciel malveillant déployé. Cet article relate ce que nous avons découvert.

Un module d'enclave VBS peut être configuré de manière à être déboguable. Comme les modules d'enclaves s'exécutent dans VTL1, le débogage n'est normalement pas possible, car le débogueur ne peut pas accéder à la mémoire de l'enclave pour récupérer des données ou placer des points d'arrêt. Cependant, nous avons constaté que lorsqu'un module d'enclave déboguable est exécuté, il est toujours chargé dans VTL1. 

Pour permettre le débogage, le noyau sécurisé met en œuvre certaines exceptions qui s'appliquent aux modules d'enclaves déboguables. Les autorisations de mémoire au sein d'un module enclave déboguable sont également modifiables par le processus VTL0. Les données traitées par le module peuvent être facilement exposées.

Cela compromet l'objectif principal des enclaves VBS, à savoir isoler une section de la mémoire de VTL0. C'est pourquoi Microsoft recommande vivement aux développeurs de ne pas livrer de modules d'enclaves déboguables.

Si un attaquant obtient n'importe quel module d'enclave signé déboguable, il peut exécuter du code VTL1 en effectuant les étapes que j'ai présentées lors de la DEF CON. Cela reste risqué pour l'attaquant, car s'il peut accéder à la mémoire de l'enclave, un EDR le peut aussi. Cependant, l'attaque peut échapper à la surveillance des API, ce qui peut limiter la visibilité d'une solution EDR.

Cette méthode pourrait être utilisée pour créer un implant « semi-VTL1 » furtif, qui tire parti de certains des avantages obtenus en étant exécuté à l'intérieur d'une enclave.

Nous avons vérifié si un attaquant pouvait utiliser une version de la technique bring your own vulnerable driver (BYOVD) pour exécuter des logiciels malveillants dans une enclave VBS. Pour ce faire, il lui faudrait trouver un module d'enclave signé vulnérable.

Cela nous a conduits à la vulnérabilité CVE-2023-36880, dans un module d'enclave VBS utilisé par Microsoft Edge. Identifiée par Alex Gough, de l'équipe de sécurité de la plateforme Chrome, cette vulnérabilité permet à un attaquant de lire et d'écrire des données arbitraires à l'intérieur de l'enclave. 

Nous avons tenté d'abuser de la primitive lecture/écriture pour écraser la pile de l'enclave avec une chaîne ROP, ce qui nous permettrait finalement d'exécuter un shellcode dans l'enclave. Cependant, nous avons constaté que les enclaves sont protégées contre l'exécution de code non signé à l'aide d'une protection contre l'exécution de code arbitraire (ACG), une mesure de sécurité conçue pour bloquer l'exécution de code généré lors de l'exécution (Figure). 

Nous n'avons pas (encore) trouvé le moyen de contourner l'ACG à l'intérieur d'une enclave et d'y charger du code non signé, mais en théorie, une exploitation complète des ROP est possible.

Nous avons testé une technique d'évasion par balayage de la mémoire que nous avons baptisée « Mirage ». Nous nous sommes inspirés de Gargoyle, une technique d'évasion qui crée une charge utile qui passe continuellement d'un état bénin à un état malveillant. 

Mirage y parvient en passant de la mémoire VTL1 à la mémoire VTL0. Elle stocke le shellcode dans la mémoire de l'enclave VTL1, le transfère périodiquement vers VTL0 en utilisant la vulnérabilité, l'exécute, puis l'efface rapidement de la mémoire de VTL0.

Comme la charge utile passe la plupart du temps cachée dans le VTL1, elle résiste aux analyses de la mémoire et aux vidages. Lorsqu'elle est inactive, la charge utile est à la fois furtive et inaccessible. En outre, le shellcode est écrit dans VTL0 par l'enclave, hors de portée des outils EDR, ce qui le rend difficile à détecter par le biais de la surveillance.

Une autre application intéressante des logiciels malveillants d'enclave est l'anti-débogage. Le code exécuté à l'intérieur de l'enclave reste inaccessible aux applications VTL0, y compris aux débogueurs, ce qui confère aux logiciels malveillants un avantage significatif.

Nous avons exploré un certain nombre d'approches. Tout d'abord, nous pouvons nous appuyer sur l'accès de l'enclave à l'espace d'adressage VTL0 du processus, ce qui lui permet de lire manuellement le Process Environment Block (PEB) et de vérifier la valeur du drapeau BeingDebugged. En cas de détection d'un débogueur, le processus peut être arrêté par l'enclave.

Nous avons également étudié une technique anti-débogage basée sur le temps, selon laquelle nous utilisons les cycles d'horloge du processeur pour mesurer le temps passé entre les différents appels de l'enclave et mettre fin au processus en cas de détection d'un retard important.

En déplaçant des parties critiques de notre code dans une enclave, parallèlement à une vérification anti-débogage, nous pouvons créer un logiciel malveillant avec une haute résistance à l'analyse dynamique. Correctement mise en œuvre, cette approche ne pourrait être déjouée qu'en déboguant Hyper-V ou le noyau sécurisé.

À ce jour, les enclaves sont uniquement utilisées par un nombre limité d'applications. C'est pourquoi l'utilisation anormale, voire abusive, d'une enclave peut constituer une excellente opportunité de détection. Pour tirer parti de cette opportunité, les responsables de la sécurité peuvent se concentrer sur les points suivants :

• Établir une base de référence des utilisations connues et légitimes des enclaves VBS et signaler tout écart
• Vérifier toute anomalie au niveau des API d'enclave
• Surveiller le chargement des DLL d'enclave, qui peut indiquer un nouveau processus
• Utiliser d'autres techniques de sécurité conçues pour isoler les systèmes et applications critiques, telles que la microsegmentation

Les enclaves VBS constituent un outil efficace pour protéger les sections sensibles de leurs applications, mais elles peuvent également être utilisées par les acteurs malveillants pour « protéger » leurs logiciels malveillants. Comme je l'ai expliqué lors de ma présentation à la DEF CON, les stratégies d'attaque des enclaves sont en grande partie théoriques à ce stade. Toutefois, il est certain que les acteurs malveillants sophistiqués effectuent leurs propres recherches pour identifier les vulnérabilités qui leur permettront d'utiliser les enclaves VBS à des fins malveillantes. 

Il est important de maîtriser l'utilisation des enclaves au sein de votre environnement pour anticiper cette menace grandissante.

Lisez ma dernière publication, Utilisation abusive des enclaves VBS pour créer des logiciels malveillants évasifs, pour obtenir des explications techniques complètes.