Windows Elevation of Privilege Vulnerability

Falha de controle de acesso (ACL excessivamente permissiva) que permite a qualquer usuário local não privilegiado ler os hives de registro do Windows — incluindo o SAM — via cópias VSS shadow do disco de sistema, e escalar para SYSTEM. Ficou conhecida como HiveNightmare/SeriousSAM e afeta várias versões do Windows 10 (1809 a 21H1) porque o grupo BUILTIN\Users recebeu permissão de leitura/execução em %windir%\system32\config. É crítica porque não exige exploit de memória nem bug de código: é apenas uma permissão errada, fácil de verificar e de abusar.

O problema (CWE-1220, granularidade insuficiente de controle de acesso) está nas ACLs de arquivos em %windir%\system32\config — diretório que contém os hives SAM, SYSTEM e SECURITY. Em builds afetadas, o grupo BUILTIN\Users tem permissão RX (leitura e execução) herdada nesses arquivos, quando deveria ser restrito a Administradores e SYSTEM. O bug foi introduzido, segundo pesquisadores, por uma mudança relacionada à proteção do sistema/System Restore em builds do Windows 10 a partir da 1809.

Normalmente esses hives estão bloqueados em uso pelo processo do kernel enquanto o sistema roda, o que impediria leitura direta mesmo com a ACL frouxa. O vetor real de exploração passa pelas cópias de sombra do Volume Shadow Copy Service (VSS): se existir ao menos uma shadow copy do volume do sistema, uma cópia estática dos hives fica acessível através do caminho \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\Windows\System32\config\, sem o lock do processo ativo, herdando a mesma ACL permissiva do diretório original.

Com leitura desses hives, um atacante local obtém: hashes de senha de contas locais (SAM), chaves DPAPI da máquina (permitindo descriptografar chaves privadas de usuários armazenadas no perfil) e a conta de máquina do computador (utilizável em ataque de silver ticket contra Kerberos). Nenhuma dessas capacidades depende de falha de memória — é leitura de arquivo autorizada por ACL incorreta, o que torna a exploração determinística e sem necessidade de bypass de mitigação de exploração.

Pré-requisito central, e frequentemente omitido: o atacante precisa já ter execução de código como usuário autenticado no sistema (AV:L, PR:L) — não é uma falha remota. O segundo pré-requisito, decisivo para explorabilidade, é a existência de pelo menos uma VSS shadow copy do volume de sistema. Shadow copies não são criadas em toda configuração, mas o Windows as cria automaticamente com frequência: discos de sistema maiores que 128 GB combinados com Windows Update ou instalação de um MSI disparam a criação automática de uma shadow copy, o que faz a pré-condição estar presente em uma fatia grande de máquinas reais sem qualquer configuração deliberada.

A verificação de vulnerabilidade é trivial e não requer privilégio: `icacls %windir%\system32\config\sam` mostrando `BUILTIN\Users:(I)(RX)` indica ACL vulnerável; a ausência de shadow copy pode ser checada com `vssadmin list shadows` (privilegiado). Com ambas as condições satisfeitas, o atacante lê os hives via caminho de dispositivo da shadow copy e extrai localmente hash de senha, chaves DPAPI e conta de máquina — sem executar payload contra o kernel, apenas cópia de arquivo.

A vulnerabilidade está no catálogo KEV da CISA (adicionada em 2022-02-10, com exploração confirmada em ambiente real) e existem múltiplas provas de conceito públicas e um módulo Metasploit, reduzindo a complexidade prática de exploração a quase zero para quem já tem uma sessão local, mesmo sem privilégios administrativos.

A atualização de julho de 2021 corrige as ACLs para arquivos criados a partir da instalação do patch, mas a própria Microsoft afirma explicitamente que instalar o update por si só NÃO mitiga o problema: shadow copies já existentes antes do patch continuam contendo os hives com a ACL antiga e permissiva. É necessário, após aplicar o patch, corrigir a herança de ACL nos arquivos atuais com `icacls %windir%\system32\config\*.* /inheritance:e` e então apagar todas as shadow copies existentes com `vssadmin delete shadows /for=%systemdrive% /Quiet`, confirmando com `vssadmin list shadows`. O procedimento completo está documentado na KB5005357 da Microsoft.

O custo real dessa mitigação: apagar as shadow copies existentes destrói pontos de restauração do System Restore anteriores à correção — funcionalidades que dependem deles deixam de funcionar para o passado, embora novas shadow copies criadas após a correção de ACL já sejam geradas com permissões corretas. Não há mitigação equivalente via configuração de rede ou WAF, porque o vetor é puramente local — controles de segmentação de rede não têm efeito algum aqui; o controle compensatório real, na ausência de patch, é restringir manualmente a ACL do diretório de configuração e eliminar shadow copies órfãs, ou impedir execução de código não confiável por usuários locais.

O mito a evitar: acreditar que "instalei o patch de julho/2021, está resolvido" — sem a etapa manual de exclusão de shadow copies, sistemas que já tinham shadow copy antes da atualização permanecem explorável.

Verificação direta de vulnerabilidade: `icacls %windir%\system32\config\sam` executado sem privilégio — saída contendo `BUILTIN\Users:(I)(RX)` indica sistema vulnerável; saída `Access is denied` indica sistema corrigido. Para checar exposição real, `vssadmin list shadows` (requer prompt elevado) revela se existe shadow copy do volume `(C:)` — ausência de shadow copies elimina o vetor de exploração mesmo em sistema com ACL vulnerável.

Não há assinatura de rede, já que o ataque é inteiramente local: não há tráfego a inspecionar. Em nível de host, acesso de leitura a arquivos sob \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy*\Windows\System32\config\ por processos não administrativos é o sinal mais próximo de tentativa de exploração, mas exige auditoria de acesso a objeto habilitada explicitamente nesses caminhos — não é coletado por padrão na maioria dos ambientes.