Windows Hyper-V NT Kernel Integration VSP Elevation of Privilege Vulnerability
Priorize a correção. Ela está sob exploração confirmada pelo CISA.
Apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable.
Resumo
Falha de use-after-free (CWE-416) no componente VSP (Virtualization Service Provider) da integração Hyper-V com o NT Kernel do Windows, que permite a um atacante local já autenticado escalar privilégios até SYSTEM. Está no catálogo KEV da CISA com exploração confirmada em campo, mas o vetor é estritamente local — não há componente de rede ou execução remota — o que limita seu uso a pós-exploração ou cadeias que já garantiram execução de código na máquina.
Detalhamento técnico
O VSP de integração Hyper-V/NT Kernel é o componente que faz a ponte entre o kernel do Windows host e os serviços de integração expostos a partições virtualizadas (VSCs). A vulnerabilidade é um use-after-free: uma estrutura de kernel referenciada pelo VSP é liberada em um caminho de código (provavelmente durante tratamento de mensagens ou desconexão de canal VMBus) enquanto outra referência ainda ativa continua apontando para a região de memória, que pode ser realocada e preenchida pelo atacante antes do uso subsequente.
O vetor de ataque é local (AV:L), com baixa complexidade (AC:L), exige privilégio baixo (PR:L) e nenhuma interação do usuário (UI:N). O impacto é total em confidencialidade, integridade e disponibilidade (C:H/I:H/A:H), coerente com execução de código arbitrário em contexto kernel após a corrupção de memória ser convertida em controle de fluxo.
O MSRC não publicou (nas fontes disponíveis) detalhamento do fluxo exato de alocação/liberação nem da struct afetada — a Microsoft mantém a descrição do advisory em nível alto, como é padrão em EoPs de Hyper-V. A classificação CWE-416 vem do catálogo KEV da CISA, que também confirma que a explotação observada resulta em obtenção de privilégios SYSTEM.
Como é explorada
Pré-requisito central: o atacante precisa já ter acesso local autenticado com privilégio baixo na máquina Windows afetada (ou em uma VM que interage com o host via os serviços de integração Hyper-V, dependendo do ponto exato de exploração). Não há indicação de que a falha seja explorável remotamente ou sem autenticação — isso reduz drasticamente a superfície de exposição direta pela internet, mas não elimina o risco em ambientes de virtualização multi-tenant, VDI ou pós-comprometimento em pentest/red team, onde escalar de usuário padrão para SYSTEM é o objetivo típico.
A CISA confirma exploração ativa (entrada no KEV, adicionada em 2025-01-14, prazo de mitigação até 2025-02-04), mas não há detalhes públicos sobre o ator, campanha ou setor alvo nas fontes catalogadas. O padrão típico para EoPs de Hyper-V/VSP nesse perfil é uso em cadeias de exploração pós-comprometimento: o atacante obtém um ponto de apoio inicial (phishing, credencial vazada, outra vulnerabilidade) e usa esta falha para sair de um contexto de usuário limitado e assumir controle total do sistema.
A complexidade de exploração de use-after-free em kernel normalmente exige manipulação precisa de timing e heap grooming para garantir que a memória liberada seja realocada de forma controlada — não é trivial, mas também não é considerada de alta complexidade pelo próprio CVSS (AC:L). O resultado final documentado é elevação a privilégios SYSTEM.
Versões
Como se proteger
A correção é a atualização de segurança da Microsoft para as versões afetadas, distribuída no Patch Tuesday de janeiro de 2025. O advisory oficial no MSRC (link nas fontes) lista os KBs específicos por versão de Windows/Windows Server — como não temos o número exato de build/KB confirmado nas fontes lidas, a recomendação objetiva é aplicar a atualização cumulativa de janeiro de 2025 correspondente à build instalada e validar via Windows Update ou WSUS que o sistema não está mais reportando a versão vulnerável.
Não há paliativo de configuração documentado pela Microsoft para esta falha — a CISA, no próprio KEV, resume a ação recomendada como 'aplicar mitigações conforme instruções do fornecedor ou descontinuar o uso do produto se não houver mitigação disponível', o que na prática significa: não existe workaround substituto confiável, só a atualização. Desativar o role Hyper-V reduziria a superfície apenas em hosts onde ele não é necessário, mas isso não é uma mitigação suportada oficialmente, é remoção do componente vulnerável — custo alto em ambientes que dependem de virtualização.
Controles compensatórios genéricos (segregação de privilégios locais, EDR monitorando comportamento anômalo de processos relacionados a VMBus/Hyper-V, restrição de quem tem logon local em hosts com Hyper-V habilitado) reduzem a chance de um atacante chegar ao pré-requisito de acesso local, mas não corrigem a falha em si.
Como detectar
Não há assinatura pública de exploração ou IOC divulgado nas fontes disponíveis (MSRC e CISA KEV não publicam detalhes de payload ou artefato de exploração para esta CVE). Como é uma falha de memória em kernel explorada localmente, o sinal mais realista de tentativa é: crashes ou eventos de Bug Check (BSOD) relacionados ao driver/componente VSP de integração Hyper-V nos logs de eventos do sistema (Event Viewer, canal System/Kernel-PnP ou Hyper-V-specific), especialmente crashes repetidos em processos associados a vmicsvc, vmbus ou serviços de integração, que podem indicar tentativas de heap grooming falhas. Na ausência de IOC oficial, a defesa prática é monitorar EDR para escalonamento anômalo de privilégio (processo de usuário padrão obtendo token SYSTEM) e garantir aplicação do patch como controle primário.