Windows Hyper-V NT Kernel Integration VSP Elevation of Privilege Vulnerability
Prioriza la corrección. Ella está bajo explotación confirmada por CISA.
Apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable.
Resumen
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.
Detalle 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.
Cómo se explota
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.
Versiones
Cómo protegerse
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.
Cómo 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.