(In)segurança virtualizada: Como invasores podem transformar enclaves VBS em arma

Invasores estão sempre buscando novas formas de entregar e executar malware em um host sem serem detectados. Pesquisamos algumas técnicas inéditas para executar malware dentro de um VBS (Virtualization-Based Security, enclave baseado em virtualização) e contornamos proteções de segurança comuns. Em 8 de agosto de 2025, explorei essa superfície de ataque em uma apresentação na DEF CON 33 em Las Vegas.

Parte da implementação de segurança da Microsoft, o VBS cria um ambiente virtual projetado para isolar componentes críticos do SO. Os enclaves VBS permitem isolar uma região de um processo, tornando-a inacessível a outros processos, ao próprio processo e até mesmo ao kernel. 

Embora os enclaves VBS possam melhorar a segurança, eles também podem apresentar possibilidades tentadoras para invasores. Isso porque malware em exdecução dentro de um enclave poderia ser invisível para detecções baseadas em memória e análises forenses comumente em uso. Exploramos essa ideia e encontramos várias maneiras pelas quais enclaves VBS poderiam potencialmente ser abusados.

É importante entender o conceito de VTLs (Virtual Trust Levels, níveis de confiança virtuais) subjacente aos enclaves VBS. Cada nível de confiança provê às entidades que rodam sob ele diferentes permissões de acesso à memória física. VTLs inferiores não podem acessar a memória dos superiores. 

No momento, o Windows usa dois níveis principais de segurança:  VTL0, usado para executar componentes tradicionais do SO, incluindo o kernel normal e modos de execução de usuário normais; e VTL1, que é mais privilegiado que o VTL0, criando dois novos modos de execução: o modo de kernel seguro e modo isolado de usuário.

• O Modo kernel seguro é usado para executar o kernel seguro que é executado em VTL1 e, portanto, é mais privilegiado do que o kernel normal. O kernel seguro pode impor políticas sobre o kernel normal e restringir seu acesso a regiões sensíveis da memória. Como o kernel seguro é muito restrito e não suporta drivers de terceiros, ele apresenta uma superfície de ataque significativamente reduzida.
• O Modo de usuário isolado é usado para executar processos seguros, um tipo especial de processo de modo de usuário que usa os recursos de isolamento de memória do VTL1. A memória dentro do modo de usuário isolado não pode ser acessada por nenhum código VTL0, incluindo o kernel normal.

Juntos, VTL0 e VTL1 criam quatro modos de execução: 

• Ring0 VTL0 — modo kernel normal
• Ring0 VTL1 — modo kernel seguro
• Ring3 VTL0 — modo de usuário normal
• Ring3 VTL1 — modo de usuário isolado

Os enclaves VBS criam uma seção de um processo de modo de usuário que reside no modo de usuário isolado, no qual podemos carregar DLLs chamados de "módulos de enclave". Eles se tornam um "ambiente de execução confiável" com dados e códigos inacessíveis a qualquer coisa em execução em VTL0. Isso facilita o isolamento de operações sensíveis de invasores que podem comprometer o sistema.

Como o acesso ao VTL1 é restrito, carregar uma DLL em um enclave requer que ela seja corretamente assinada usando um certificado especial emitido pela Microsoft. Qualquer tentativa de carregar um módulo sem essa assinatura falhará. Embora apenas terceiros confiáveis possam assinar módulos de enclave, não há restrições sobre quem pode carregar esses módulos. Desde que estejam assinados, qualquer processo pode carregar módulos arbitrários em um enclave.

Os enclaves VBS são atraentes para invasores por alguns motivos. Primeiro, o espaço de endereço dos enclaves é inacessível a qualquer coisa em execução em VTL0, incluindo detecção e resposta de ponto de extremidade (EDR) e ferramentas de análise. Segundo, as chamadas de API feitas de dentro de um enclave podem ser invisíveis a EDRs.

Ao reconhecer isso, investigamos como invasores poderiam executar código malicioso dentro de um enclave. Além disso, exploramos que técnicas eles poderiam empregar uma vez que seu malware estivesse em execução. Esta publicação no blog apresentará o que descobrimos.

Um módulo de enclave VBS pode ser configurado para ser depurado. Como os módulos do enclave são executados no VTL1, a depuração deles normalmente não é possível porque o depurador não pode acessar a memória do enclave para recuperar dados ou colocar pontos de interrupção. No entanto, descobrimos que, quando um módulo de enclave com depuração é executado, ele ainda é carregado no VTL1. 

Para permitir a depuração, o kernel seguro implementa algumas exceções que se aplicam aos módulos de enclave depuráveis. As permissões de memória dentro de um módulo de enclave com depuração também podem ser modificadas pelo processo VTL0. Os dados manipulados pelo módulo podem ser facilmente expostos.

Isso minaria efetivamente o propósito central dos enclaves VBS: isolar uma seção de memória do VTL0. Por esse motivo, a Microsoft recomenda enfaticamente que os desenvolvedores não enviem módulos de enclave com depuração.

Se um atacante obtiver qualquer módulo de enclave assinado com depuração, ele poderá executar códigos VTL1 realizando algumas etapas que descrevi na DEF CON. Isso representa um risco para o invasor; assim como o invasor pode acessar a memória do enclave, o EDR também pode. No entanto, o ataque pode evadir o monitoramento de API, o que pode limitar a visibilidade de uma solução EDR.

Essa técnica pode ser usada para criar um implante "semi-VTL1" furtivo, que aproveita algumas das vantagens obtidas por rodar dentro de um enclave.

Exploramos se um invasor poderia usar uma versão da técnica BYOVD (Bring Your Own Vulnerable Driver, traga seu próprio driver vulnerável) para rodar o malware em um enclave do VBS. Isto envolve encontrar um módulo de enclave assinado com uma vulnerabilidade.

Isso nos leva ao CVE-2023-36880, um módulo de enclave VBS usado pelo Microsoft Edge. Descoberta por Alex Gough, da Chrome Platform Security Team, essa vulnerabilidade permite a um invasor ler e gravar dados arbitrários dentro do enclave. 

Tentamos abusar da primitiva de leitura/gravação para substituir a pilha de enclave por uma cadeia de programação orientada por retorno (ROP), o que eventualmente nos permitiria executar shellcode dentro do enclave. No entanto, descobrimos que os enclaves são protegidos contra a execução de código não assinado usando ACG (arbitrary code guard, proteção de código arbitrário), uma atenuação de segurança projetada para bloquear a execução de código criado em tempo de execução (Figura). 

Ainda não encontramos um método para burlar o ACG dentro de um enclave e carregar código não assinado nele, embora, em teoria, seja possível fazer uma exploração ROP completa.

Exploramos uma técnica de evasão de leitura de memória que apelidamos de "Mirage", inspirada em Gargoyle, uma técnica de evasão que cria uma carga útil que alterna continuamente entre um estado benigno e um estado armado. 

O Mirage alcança isso ao transicionar entre a memória VTL1 e VTL0. Ele armazena o shellcode na memória do enclave do VTL1, transfere-o periodicamente de volta para o VTL0 usando a vulnerabilidade, executado-o e, em seguida, remove-o rapidamente da memória do VTL0.

Como a carga útil passa a maior parte do tempo oculta no VTL1, ela é resistente a varreduras e despejos de memória. Durante sua fase dormente, a carga é tanto furtiva quanto inacessível. Além disso, a escrita do shellcode em VTL0 é realizada pelo enclave, fora do escopo das ferramentas EDR, o que dificulta sua detecção por monitoramento.

Outra aplicação interessante para o malware de enclave é a de antidepuração. O código executado no enclave permanece inacessível a aplicações VTL0, incluindo depuradores, o que fornece uma vantagem significativa ao malware.

Exploramos várias abordagens. Contar com o acesso do enclave ao espaço de endereços do VTL0 do processo permite que ele leia manualmente o PEB (Process Environment Block - bloco do ambiente do processo) e verifique o valor do sinalizador BeingDebugged. Se um depurador for detectado, o processo pode ser finalizado pelo enclave.

Também examinamos uma técnica anti-depuração baseada em tempo usando ciclos do clock do processador para medir o tempo gasto entre diferentes chamadas de enclave, e encerrar o processo se um atraso significativo for detectado.

Ao mover partes críticas do nosso código para um enclave com uma verificação de antidepuração, podemos criar um malware que seja quase completamente imune à análise dinâmica. Se implementada corretamente, essa abordagem só poderia ser derrotada ao depurar o Hyper-V ou o kernel seguro.

No momento, os enclaves são usados apenas por um número limitado de aplicativos. Isso pode transformar o uso/abuso de enclave anômalo em uma grande oportunidade de detecção. Para aproveitar essa oportunidade, defensores podem focar no seguinte:

• Crie uma linha de base de usos conhecidos e legítimos de enclaves VBS e sinalize quaisquer desvios
• Monitore APIs de enclave em busca de anomalias
• Monitore o carregamento de DLLs de enclave, que pode indicar um novo processo
• Use outras técnicas de segurança projetadas para isolar sistemas e aplicações críticas, como microsegmentação

Embora os enclaves de VBS sejam uma ferramenta eficaz para proteger seções sensíveis de seus aplicativos, eles também podem ser usados por agentes maliciosos para "proteger" seu malware. Como expliquei na minha apresentação na DEF CON, estratégias de ataque a enclaves são, em grande parte, teóricas neste ponto. No entanto, podemos ter certeza de que agentes de ameaça avançados estão fazendo suas próprias pesquisas para encontrar vulnerabilidades que lhes permitam usar enclaves VBS para fins maliciosos. 

Controlar o uso de enclaves dentro do seu ambiente é um ótimo primeiro passo para se antecipar a essa ameaça em evolução.

Leia meu post anterior no blog, Abuso de enclaves de VBS para criar malware evasivo, para obter a explicação técnica completa.