Se você depende de virtualização aninhada em estações de trabalho de laboratório ou em cenários de desenvolvimento avançados, a atualização para o Windows 11 Pro 24H2 pode ter transformado um ambiente estável em um pesadelo: mesmo após repetir todos os procedimentos tradicionais para desligar o Virtualization‑based Security (VBS), o hipervisor continua voltando nas inicializações seguintes, impedindo a execução do VMware Workstation Pro ou de outros hipervisores de terceiros em modo “nested”. Este artigo explica, passo a passo, por que isso acontece, o que mudou na arquitetura do sistema, e apresenta o único método confiável hoje documentado para realmente eliminar o VBS—sem recorrer a reinstalações ou hacks de firmware.
Visão geral do problema
Até o Windows 10 22H2 e o Windows 11 23H2 bastava executar bcdedit /set hypervisorlaunchtype off, desativar o “Isolamento de Núcleo” na interface do Windows Security e remover eventuais chaves remanescentes do DeviceGuard para que a VBS fosse totalmente desativada. Tudo voltava a funcionar imediatamente: softwares que exigem acesso direto às extensões de virtualização do processador (Intel VT‑x ou AMD‑V) podiam operar em modo aninhado, contêineres Docker que recorrem a VT‑x funcionavam, e qualquer benchmark deixava de pagar o overhead representado pelo hipervisor.
Com a chegada do Windows 11 24H2, no entanto, os mesmos comandos não surtem efeito. Mesmo aparentemente “desativado” em Configurações ↦ Segurança do Windows, o VBS segue ativo após cada reinicialização. O sintoma mais evidente é o erro de inicialização no VMware Workstation: “Nested virtualization is not supported. Check that the hypervisor is turned off.” A causa real para essa mudança atende pelo nome de LSA Isolation with UEFI Lock.
O que mudou no Windows 11 24H2
Introduzido como camada adicional contra ataques de roubo de credenciais, o “LSA Isolation” já existia em versões anteriores, mas a 24H2 passa a aplicar um bloqueio no firmware UEFI—o chamado UEFI Lock. Esse bloqueio grava uma flag persistente (ACPI NVS) que sinaliza ao boot loader do Windows que o isolamento deve ser restabelecido se for detectada a remoção do hipervisor ou de outros componentes da VBS.
Em termos simples: ainda que o usuário desligue o hipervisor via BCD, o próximo processo de boot verifica a flag de bloqueio, reinjeta os drivers do VBS e volta a subir o hypervisor. Como o bcdedit tradicional mexe somente na chave hypervisorlaunchtype, a alteração é sobreposta logo nos estágios iniciais da sequência de boot.
Conceito de loadoptions
Menos conhecido que hypervisorlaunchtype, o parâmetro loadoptions faz parte das entradas de configuração do BCD e permite sinalizar instruções adicionais ao kernel antes mesmo da inicialização completa. Entre as flags aceitas na 24H2 está DISABLE‑LSA‑ISO, justamente a diretiva que ordena ao boot loader ignorar a flag de UEFI Lock e, consequentemente, não religar o VBS.
Solução prática (workaround confirmado)
A correção envolve duas linhas em um Prompt de Comando elevado (executado como Administrador):
bcdedit /set {current} loadoptions DISABLE-LSA-ISO
bcdedit /set {current} hypervisorlaunchtype offO primeiro comando adiciona a flag que neutraliza o UEFI Lock; o segundo mantém o comportamento clássico de impedir o carregamento do hipervisor. Siga estes passos cuidadosamente:
- Abrir o Menu Iniciar → Digite “cmd” → Clique com o botão direito em “Prompt de Comando” → Executar como Administrador.
- Copiar e colar as duas linhas acima, pressionando Enter após cada uma.
- Reiniciar o computador.
- Verificar o resultado em Iniciar → Executar →
msinfo32(ou viasysteminfo):
- O campo “Segurança baseada em virtualização” deve mostrar Desligado.
- Os “Requisitos de virtualização” precisam aparecer como Não.
Dica rápida: para duplo‑cheque, execute coreinfo -v (utilitário Sysinternals). Se “Hypervisor” não constar na lista de recursos presentes, a desativação foi bem‑sucedida.
Desativar componentes gráficos da VBS
A interface do Windows Security continua exibindo o painel “Isolamento de núcleo”. Para evitar que futuras atualizações reabilitem o recurso:
- Abra Segurança do Windows → Segurança do Dispositivo → Isolamento de núcleo e mantenha a chave Desativado.
- Clique em Detalhes de Isolamento de Núcleo e marque Integridade de Memória como desativada.
Remover políticas herdadas do Device Guard
Em ambientes que já adotavam diretrizes de segurança por GPO, a VBS pode ter sido imposta pelo Device Guard, substituto do antigo AppLocker. Vale conferir:
Editor de Diretiva de Grupo Local
Configuração do Computador
Modelos Administrativos
Sistema
Device Guard
Ativar a segurança baseada em virtualização… → Definir como DesativadoApós alterar a política, execute gpupdate /force no prompt de comando ou reinicie para aplicar.
Impacto na segurança e boas práticas
| Aspecto | Detalhes |
|---|---|
| Redução de proteção | Desativar a VBS remove mecanismos de defesa contra malware que atuam em nível de kernel, contra roubo de credenciais e contra ataques pass-the-hash. Use somente em laboratórios, ambientes de teste ou quando a virtualização aninhada for requisito inegociável. |
| Perfomance vs. Segurança | Sem o hypervisor, benchmarks de I/O e CPU costumam ganhar entre 3 % e 8 % de desempenho bruto, mas o sistema perde recursos como o HVCI e o Credential Guard. |
| Acompanhamento | Repita as verificações após cada grande atualização cumulativa do Windows; patches de segurança podem restabelecer o UEFI Lock. |
Alternativa: conservar o VBS usando Hyper‑V
Se a prioridade é máxima segurança, considere migrar todo o fluxo de trabalho de VMs para o Hyper‑V integrado ao Windows. Ele compartilha o mesmo hypervisor da VBS e, portanto, opera sem conflito. Para expor as instruções VT‑x/AMD‑V dentro de uma VM no Hyper‑V, habilite a virtualização aninhada:
Set-VMProcessor -VMName "SuaVM" -ExposeVirtualizationExtensions $trueO desempenho não será exatamente o mesmo que executar VMware ou VirtualBox diretamente no host, mas garante compatibilidade com políticas corporativas e mantém todas as camadas de segurança.
Cenários corporativos e UEFI Lock gerenciado
Em computadores ingressados em domínio, o UEFI Lock pode ser imposto via políticas MDM ou GPO distribuídas pelo Intune, SCCM ou soluções equivalentes. Nessas situações, mesmo que o administrador local rode o comando DISABLE‑LSA‑ISO, a próxima sincronização de política poderá restabelecer a flag de bloqueio. Recomenda‑se:
- Solicitar à equipe de segurança a criação de exceção na política de LSA Protection para estações que precisem de nested virtualization.
- Documentar a justificativa de negócio (laboratório, automação de testes, compatibilidade de legado) para auditorias futuras.
- Manter inventário de máquinas isentas, revisitando a decisão periodicamente.
Perguntas frequentes
1. Preciso editar o firmware UEFI manualmente?
Não. A flag de UEFI Lock é armazenada em regiões NVS que o Windows controla. O comando DISABLE‑LSA‑ISO é suficiente para ignorá‑la, desde que você tenha privilégios administrativos.
2. Esse procedimento se aplica ao Windows 11 Home?
Sim, mas distribuições Home raramente habilitam o LSA Isolation por padrão. Ainda assim, se o VBS estiver ativo e você precisar desativá‑lo, o método descrito funciona igualmente.
3. Posso automatizar via PowerShell?
Sim. Exemplo:
Start-Process cmd -Verb RunAs -ArgumentList "/k bcdedit /set {current} loadoptions DISABLE-LSA-ISO && bcdedit /set {current} hypervisorlaunchtype off"Lembre‑se de incluir lógica de verificação e registro em log para ambientes de TI gerenciada.
4. Existe risco de corromper o boot?
As opções alteradas afetam somente parâmetros de kernel; não mexem no BCD vital de partida. Ainda assim, anote os valores originais com bcdedit /enum {current} antes de prosseguir, para fins de restauração.
Checklist rápido pós‑atualização
- Rodar
coreinfo -ve confirmar ausência de “Hypervisor present”. - Confirmar em
msinfo32: “Segurança baseada em virtualização → Desligado”. - Abrir VMware ou VirtualBox e iniciar uma VM aninhada com Ubuntu Server ou similar; validar acesso a
/dev/kvmdentro da convidada. - Armazenar log de execução dos comandos
bcdeditpara auditoria.
Considerações finais
O Windows 11 24H2 reforça a segurança ao elevar o LSA Isolation para o nível de firmware, mas deixa sem alternativas oficiais quem precisa de nested virtualization fora do Hyper‑V. Até que a Microsoft disponibilize um “toggle” amigável na GUI ou atualize a documentação pública, o fluxo DISABLE‑LSA‑ISO + hypervisorlaunchtype off permanece como solução indispensável para desenvolvedores, testadores de nuvem híbrida e entusiastas que dependem de VMware Workstation ou de stacks de contêineres que exigem VT‑x/AMD‑V direto no host. Aplique com cautela, monitore depois de cada Patch Tuesday e mantenha backups completos do sistema para evitar surpresas.
Ficou com dúvidas ou encontrou variações em hardware específico? Compartilhe sua experiência nos comentários para que possamos manter este guia sempre atualizado e útil à comunidade lusófona.