CVE-2016-0099

Falha de elevação de privilégio local no serviço Secondary Logon (SecLogon) do Windows, que permite a um usuário autenticado localmente — sem privilégios administrativos — obter execução de código como SYSTEM. É crítica em cenários de pós-exploração e escalação lateral, mas não é remota: exige que o atacante já tenha logon válido na máquina, ainda que com conta de baixo privilégio.

O SecLogon expõe via RPC as APIs CreateProcessWithLogonW e CreateProcessWithTokenW, que na prática são executadas dentro do processo de serviço (svchost.exe hospedando seclogon), não no processo do chamador. Quando a flag STARTF_USESTDHANDLES é usada na STARTUPINFO, a função interna SlpSetStdHandles duplica os handles padrão (stdin/stdout/stderr) do processo chamador para o novo processo via DuplicateHandle, sem sanitizar os valores recebidos.

O problema (CWE-264, controle de acesso impróprio) é que NtDuplicateObject trata de forma especial dois valores de pseudo-handle: -1 (processo atual) e -2 (thread atual). Ao passar -2 como handle padrão, a duplicação ocorre dentro do contexto do processo de serviço seclogon, e o handle resultante aponta para uma thread do próprio pool de threads do svchost que hospeda seclogon — não para uma thread do processo do atacante. Como a duplicação usa DUPLICATE_SAME_ACCESS, o handle vazado para o processo de baixo privilégio chega com THREAD_ALL_ACCESS.

Com esse handle de thread do processo de serviço em mãos, o atacante pode suspender a thread, limpar seu token de impersonação e chamar NtImpersonateThread para forçar essa thread a impersonar a si mesma, obtendo um token de impersonação SYSTEM que pode então ser aplicado à própria thread do atacante via SetThreadToken. Como as threads capturadas pertencem ao pool de RPC compartilhado por vários serviços (BITS, Task Scheduler, o próprio seclogon), o atacante pode repetir a captura até obter uma thread útil.

Pré-requisito real: o atacante precisa de logon local na máquina (sessão interativa ou equivalente), não é necessário privilégio administrativo nem SeImpersonatePrivilege verdadeiro. CreateProcessWithTokenW é bloqueado para usuários comuns porque o serviço valida SeImpersonatePrivilege no token primário do chamador, mas CreateProcessWithLogonW funciona: usando a flag LOGON_NETCREDENTIALS_ONLY, o valor de senha passado é irrelevante — o SecLogon apenas troca a credencial de rede de uma cópia do token do próprio chamador, então nenhuma senha válida é necessária.

A exploração pública demonstrada (Google Project Zero / James Forshaw, com PoCs em C# e em PowerShell) envolve uma corrida de condição: o atacante dispara repetidamente CreateProcessWithLogonW com STARTF_USESTDHANDLES apontando o handle -2, captura o handle de thread vazado no processo local, testa se pertence ao pool de RPC do seclogon (ou de outro serviço no mesmo host de processo) e usa NtImpersonateThread para roubar um token de impersonação SYSTEM. A exploração é mais confiável em máquinas com 2 ou mais núcleos de CPU, por depender de timing entre processos concorrentes.

O CVE está no catálogo KEV da CISA com exploração confirmada e existem módulo Metasploit e múltiplos PoCs públicos (ExploitDB), o que tornou a técnica amplamente incorporada em toolkits de pós-exploração e escalação de privilégio em Windows entre 2016 e anos seguintes, mesmo após patch disponível — refletindo ambientes sem atualização, não uma falha de correção do patch.

A correção definitiva é aplicar a atualização de segurança do boletim MS16-032 (KB3143141 para Vista SP2, Server 2008 SP2/R2 SP1, Windows 7 SP1, 8.1, Server 2012/R2 e RT 8.1; KB3140745 para Windows 10 Gold; KB3140768 para Windows 10 1511), que corrige como o Windows sanitiza os handles padrão passados ao SecLogon. Microsoft não identificou workarounds nem fatores mitigantes para esta vulnerabilidade — ou seja, não há configuração de compensação documentada pelo fornecedor além do patch.

Como controle compensatório real na ausência de patch, restringir logon local a usuários não confiáveis (RDP, contas de serviço compartilhadas, terminais compartilhados) reduz a superfície, já que a falha exige sessão local. Desabilitar o serviço Secondary Logon (seclogon) onde não for necessário para "Executar como outro usuário" elimina o vetor específico, mas quebra funcionalidades legítimas que dependem dele — avalie o impacto operacional antes de aplicar.

Não há assinatura de evento nativo do Windows específica para esta falha — a exploração usa APIs legítimas (CreateProcessWithLogonW, DuplicateHandle, NtImpersonateThread) e chamadas RPC padrão ao SecLogon, o que a torna difícil de distinguir de uso normal em logs padrão. Sinais indiretos a observar incluem: processos filhos suspensos criados repetidamente em rajada por um mesmo usuário não administrador com redirecionamento de handles padrão via STARTF_USESTDHANDLES; uso de PowerShell invocando funções com nomes como "Invoke-MS16-032" (presente em PoCs públicos e em módulos de frameworks de pós-exploração); e escalonamento abrupto de uma sessão de usuário padrão para contexto SYSTEM sem evento de logon administrativo correspondente. Nenhum desses sinais é conclusivo isoladamente — correlação com EDR que monitore chamadas a NtImpersonateThread e duplicação de handles entre processos é o caminho mais confiável.