(In)Seguridad virtualizada: Cómo los atacantes pueden convertir en armas los enclaves de VBS

Los atacantes siempre buscan nuevas formas de distribuir y ejecutar malware en un host sin que sea detectado. Hemos investigado algunas técnicas novedosas para ejecutar malware dentro de un enclave de seguridad basada en la virtualización (VBS) y hemos eludido las medidas de seguridad comunes. El 8 de agosto de 2025, exploré esta superficie de ataque en una presentación en DEF CON 33 en Las Vegas.

Como parte de la implementación de seguridad de Microsoft, VBS crea un entorno virtual diseñado para aislar los componentes críticos del sistema operativo. Los enclaves de VBS permiten el aislamiento de una región de un proceso, haciéndola inaccesible a otros procesos, al propio proceso e incluso al kernel. 

Aunque los enclaves de VBS pueden mejorar la seguridad, también pueden presentar posibilidades atractivas para los atacantes. Esto se debe a que el malware que se ejecuta dentro de un enclave podría ser invisible para la detección basada en memoria y los análisis forenses que se utilizan habitualmente. Exploramos esta idea y encontramos varias formas en las que los enclaves de VBS podrían ser objeto de un posible uso indebido.

Es importante comprender el concepto de niveles de confianza virtuales (VTL) que subyace a los enclaves de VBS. Cada nivel de confianza proporciona a las entidades que se ejecutan bajo él diferentes permisos de acceso a la memoria física. Los VTL inferiores no pueden acceder a la memoria de los más altos. 

Windows utiliza actualmente dos niveles de confianza principales:  VTL0, que se utiliza para ejecutar los componentes tradicionales del sistema operativo, incluidos los modos de ejecución normal del kernel y del usuario; y VTL1, que tiene más privilegios que VTL0, creando dos nuevos modos de ejecución: modo de kernel seguro y modo de usuario aislado.

• El modo de kernel seguro se utiliza para ejecutar el kernel seguro, un kernel que se ejecuta en el VTL1 y, por lo tanto, tiene más privilegios que el kernel normal. El kernel seguro puede aplicar políticas en el kernel normal y restringir su acceso a regiones de memoria confidenciales. Dado que el kernel seguro es muy estrecho y no admite drivers de terceros, presenta una superficie de ataque significativamente reducida.
• El modo de usuario aislado se utiliza para ejecutar procesos seguros, un tipo especial de proceso en el modo de usuario que utiliza las capacidades de aislamiento de memoria de VTL1. No es posible acceder a la memoria interna del modo de usuario aislado mediante ningún código de VTL0, incluido el kernel normal.

Juntos, VTL0 y VTL 1 crean cuatro modos de ejecución: 

• Ring0 VTL0: modo de kernel normal
• Ring0 VTL1: modo de kernel seguro
• Ring3 VTL0: modo de usuario normal
• Ring3 VTL1: modo de usuario aislado

Los enclaves de VBS crean una sección de un proceso en el modo de usuario aislado que reside en el VTL1 y en el que podemos cargar archivos DLL denominados "módulos de enclave". Se convierten en un “entorno de ejecución de confianza” con datos y código inaccesibles para cualquier elemento que se ejecute en VTL0. Esto facilita aislar las operaciones confidenciales para protegerlas de los atacantes que pueden poner en peligro el sistema.

Dado el acceso a VTL1 está restringido, la carga de una DLL en un enclave requiere que esté firmado correctamente mediante un certificado especial emitido por Microsoft. Cualquier intento de cargar un módulo sin dicha firma fallará. Aunque solo terceros de confianza pueden firmar módulos de enclave, no existen restricciones sobre quién puede cargar estos módulos; siempre que estén firmados, cualquier proceso puede cargar módulos arbitrarios en un enclave.

Los enclaves de VBS son atractivos para los atacantes por un par de razones. En primer lugar, el espacio de direcciones de los enclaves es inaccesible para todo lo que se ejecute en VTL0, incluida la detección y respuesta en los terminales (EDR) y las herramientas de análisis. En segundo lugar, las llamadas de API realizadas desde el interior de un enclave pueden ser invisibles para las EDR.

Al reconocer esto, investigamos cómo los atacantes podían ejecutar código malicioso dentro de un enclave. Además, exploramos qué técnicas podrían emplear una vez que se ejecutara el malware. Esta entrada de blog presenta lo que hemos descubierto.

Se puede configurar un módulo de enclave de VBS para su depuración. Debido a que los módulos de enclave se ejecutan en VTL1, normalmente no es posible depurarlos porque el depurador no puede acceder a la memoria de enclave para recuperar datos o colocar puntos de interrupción. Sin embargo, descubrimos que cuando se ejecuta un módulo de enclave depurable, sigue cargándose en VTL1. 

Para habilitar la depuración, el kernel seguro implementa algunas excepciones que se aplican a los módulos de enclave depurables. Los permisos de memoria dentro de un módulo de enclave ejecutable también pueden ser modificadas por el proceso VTL0. Los datos que maneja el módulo pueden quedar expuestos fácilmente.

Esto socava efectivamente el objetivo principal de los enclaves de VBS: aislar una sección de la memoria de VTL0. Por este motivo, Microsoft insta encarecidamente a los desarrolladores a que no envíen módulos de enclave depurables.

Si un atacante obtiene cualquier módulo de enclave firmado depurable, puede lograr la ejecución de código en el VTL1 siguiendo estos pasos que describí en DEF CON. esto supone un riesgo para el atacante, ya que puede acceder a la memoria de enclave, al igual que puede hacerlo un EDR. Sin embargo, el ataque puede eludir la supervisión de API, lo que puede limitar la visibilidad de una solución de EDR.

Esta técnica podría utilizarse para crear un implante sigiloso "semi-VTL1" que aproveche algunas de las ventajas obtenidas al ejecutarse dentro de un enclave.

Hemos analizado si un atacante podría utilizar una versión de la técnica de traiga su propio driver vulnerable  (BYOVD) para ejecutar malware en un enclave de VBS. Esto implica encontrar un módulo firmado de enclave con una vulnerabilidad.

Esto nos llevó a la  CVE-2023-36880, una vulnerabilidad en un módulo de enclave de VBS que se utiliza en Microsoft Edge. Esta vulnerabilidad, descubierta por Alex Gough, del equipo de seguridad de Chrome Platform, permite a un atacante leer y escribir datos arbitrarios dentro del enclave. 

Tratamos de hacer un uso de la primitiva de lectura/escritura para sobrescribir la pila de enclave con una cadena de programación orientada a retornos (ROP), que finalmente nos permitiría ejecutar código de shell dentro del enclave. Sin embargo, encontramos que los enclaves están protegidos contra la ejecución de código no firmado mediante protección de código arbitrario (ACG), una mitigación de seguridad diseñada para bloquear la ejecución de código creado en tiempo de ejecución (Figura). 

No hemos encontrado (todavía) un método para omitir la ACG dentro de un enclave y cargar código sin firmar en él, aunque en teoría es posible un ataque de ROP completo.

Exploramos una técnica de evasión de exploración de memoria que denominamos “Mirage”, inspirada por Gargoyle, una técnica de evasión que crea una carga útil que cambia continuamente entre un estado benigno y un estado armado. 

Mirage consigue esto mediante la transición entre la memoria VTL1 y VTL0. Esta técnica almacena el código de shell en la memoria del enclave del VTL1, lo transfiere periódicamente de vuelta al VTL0 utilizando la vulnerabilidad, lo ejecuta y, a continuación, lo borra rápidamente de la memoria del VTL0.

Puesto que la carga útil pasa la mayor parte del tiempo oculta en el VTL1, es resistente a análisis y volcados de memoria. Durante su etapa inactiva, la carga útil es sigilosa e inaccesible. Además, la escritura del código de shell en VTL0 se realiza por el enclave, fuera del alcance de las herramientas EDR, lo que hace que sea difícil detectarlo mediante la supervisión.

Otra aplicación interesante para el malware de enclave es la antidepuración. El código que se ejecuta en el enclave sigue siendo inaccesible para las aplicaciones VTL0, incluidos los depuradores, lo que supone una ventaja significativa para el malware.

Exploramos una serie de enfoques. Confiar en el acceso del enclave al espacio de direcciones de VTL0 del proceso le permite leer el bloque de entorno del proceso (PEB) de forma manual y comprobar el valor del indicador BeingDebugged. Si se detecta un depurador, el enclave puede terminar el proceso.

También analizamos una técnica antidepuración basada en el tiempo que utiliza ciclos de reloj del procesador para medir el tiempo transcurrido entre las diferentes llamadas de enclave y finalizar el proceso si se detecta un retraso significativo.

Al mover partes críticas de nuestro código a un enclave junto con una comprobación antidepuración, podemos crear un malware que sea casi totalmente infalible al análisis dinámico.  Implementado correctamente, este enfoque solo se podría frustrar depurando Hyper-V o el kernel seguro.

En este momento, los enclaves son solo utilizados por un número limitado de aplicaciones. Esto puede hacer que el uso legítimo o indebido del enclave anómalo sea una gran oportunidad de detección. Para aprovechar esa oportunidad, los expertos en protección pueden centrarse en lo siguiente:

• Crear una línea de base de los usos legítimos y conocidos de los enclaves VBS y señalar cualquier desviación
• Supervisar las API de enclave en busca de anomalías
• Supervisar la carga de archivos DLL de enclave, que pueden indicar un nuevo proceso
• Utilizar otras técnicas de seguridad diseñadas para aislar sistemas y aplicaciones esenciales, como la microsegmentación

Mientras que los enclaves de VBS proporcionan una herramienta eficaz para proteger las secciones sensibles de las aplicaciones, los atacantes también pueden utilizarlos para "proteger" su malware. Como expliqué en mi presentación de DEF CON, las estrategias de ataque de enclave son en gran medida teóricas en este punto. Sin embargo, podemos estar seguros de que los atacantes avanzados están investigando para encontrar vulnerabilidades que les permitan utilizar los enclaves de VBS con fines malintencionados. 

Lograr controlar el uso de los enclaves dentro de su entorno es un gran primer paso para adelantarse a esta amenaza en constante evolución.

Lea mi entrada anterior del blog, Uso indebido de enclaves de VBS para crear malware evasivo, para obtener la explicación técnica completa.