Netlogon Elevation of Privilege Vulnerability

Zerologon é uma falha criptográfica no protocolo Netlogon Remote Protocol (MS-NRPC), usado por controladores de domínio Active Directory para autenticar contas de computador. Um atacante sem qualquer credencial, com acesso de rede a um domain controller, pode se autenticar como qualquer máquina do domínio — inclusive como o próprio DC — e a partir daí zerar a senha da conta de computador do DC, abrindo caminho para admin de domínio completo. O CVSS 5.5 informado aqui reflete apenas um vetor específico e subestima o impacto real; o próprio MSRC classificou a falha original como crítica (9.3) e a CISA a mantém no catálogo KEV por exploração ativa confirmada, inclusive por operadores de ransomware.

A causa é uso indevido de AES-CFB8 na função ComputeNetlogonCredential do MS-NRPC: o protocolo usa um vetor de inicialização (IV) fixo, de 16 bytes zero, em toda autenticação de conta de computador. AES-CFB8 só é seguro com IV aleatório e único por sessão; com IV zero e uma mensagem toda de zeros (challenge e credential escolhidos pelo atacante como zero), há 1 chance em 256 de o texto cifrado resultante também sair todo zero — condição em que a autenticação é aceita como válida. Isso corresponde a um CWE-330 (uso de valor insuficientemente aleatório) na camada criptográfica do protocolo, não a um bug de implementação: qualquer stack que siga a especificação MS-NRPC corretamente reproduz a falha, o que inclui o Samba.

A pesquisa da Secura (Tom Tervoort) que descobriu a falha demonstrou que, repetindo a tentativa de autenticação um número pequeno de vezes (estatisticamente, em torno de algumas centenas), o atacante eventualmente acerta a combinação e é autenticado como o computador de sua escolha — incluindo a conta de máquina do domain controller. A partir desse ponto, o atacante controla os parâmetros das chamadas RPC subsequentes no canal Netlogon, o que basta para invocar operações privilegiadas de gerenciamento de conta de máquina.

O atacante não controla dados de aplicação nem precisa de qualquer credencial prévia: controla apenas os campos client challenge e client credential enviados nas chamadas NetrServerReqChallenge/NetrServerAuthenticate3, que ele pode fixar em zero à vontade.

O vetor é puramente de rede: o atacante precisa apenas de conectividade RPC (interface Netlogon, tipicamente via porta 135/TCP e uma porta dinâmica de RPC) até um domain controller — não precisa estar autenticado, não precisa de interação de usuário e não depende de nenhuma configuração fora do padrão. Isso normalmente significa acesso à rede interna (segmento onde o DC está exposto), algo que um atacante já obtém após comprometer qualquer host dentro do perímetro, tornando a falha extremamente valiosa para escalação lateral e domain takeover em intrusões já em andamento.

Depois de autenticar-se falsamente como conta de computador — inclusive personificando o próprio DC — o atacante pode chamar operações de troca de senha do canal Netlogon para zerar a senha da conta de máquina do DC no Active Directory. Com isso, consegue autenticar-se como o DC e extrair hashes de todas as contas do domínio (via DRSUAPI/replicação), obtendo efetivamente domain admin. A prova de conceito pública (Secura) e o módulo Metasploit tornaram a exploração trivial e amplamente automatizada; o CISA KEV registra exploração ativa, e a falha foi usada por operadores de ransomware (relatos ligados a campanhas Ryuk, entre outras) logo após a divulgação em setembro de 2020.

A complexidade técnica de descoberta foi alta (exigiu pesquisa criptográfica), mas a complexidade de exploração, uma vez publicada a PoC, é baixa: script, alguns segundos a poucos minutos de tentativas, sem necessidade de qualquer credencial válida.

A correção definitiva é aplicar as atualizações da Microsoft. O rollout foi em duas fases: a fase 1 (agosto de 2020) adiciona suporte a RPC seguro obrigatório no Netlogon e passa a registrar em log conexões que usariam o comportamento vulnerável; a fase 2, com enforcement automático habilitado a partir de 9 de fevereiro de 2021, passou a exigir RPC seguro por padrão em todos os DCs, mesmo sem intervenção do administrador. Ambientes ainda em Windows Server sem essas atualizações — nas versões listadas (2008 R2 SP1 até 2016, conforme afetadas) — continuam vulneráveis à técnica original de força bruta contra o handshake Netlogon.

Como paliativo antes do enforcement automático, o próprio guia da Microsoft (KB4557222, referenciado na advisory oficial) permite habilitar manualmente o modo de imposição via chave de registro específica para forçar RPC seguro em contas de computador, DCs e trusts, mas isso pode quebrar dispositivos legados (impressoras, appliances, NAS) que ainda usam Netlogon sem canal seguro — nesses casos é preciso mapear e atualizar/substituir esses dispositivos ou adicioná-los a exceções explícitas, o que tem custo operacional real. Para ambientes com Samba atuando como DC, a mitigação equivalente é garantir 'server schannel = yes' em smb.conf — padrão desde Samba 4.8 (2018), mas ambientes com 'server schannel = auto' ou versões antigas continuam expostos e devem corrigir a configuração imediatamente, além de atualizar para uma versão com o patch (ex.: 4.12.7 e correspondentes em outras branches, conforme distribuições aplicaram).

O que não funciona como mitigação: apenas monitorar ou logar não impede a exploração — a fase 1 registra tentativas mas não bloqueia por padrão até a fase 2/enforcement. Segmentação de rede que não isole completamente o acesso RPC ao DC também não é suficiente, já que qualquer host com rota até a porta de RPC do controlador de domínio pode tentar a exploração.

No log de eventos do sistema dos domain controllers, após a atualização de agosto de 2020, ficam registradas tentativas de conexão Netlogon que usariam o comportamento vulnerável (conforme o guia oficial referenciado na advisory), permitindo distinguir dispositivos legados incompatíveis de tentativas de ataque. Em tráfego de rede, o padrão característico é um volume anômalo de chamadas RPC repetidas contra a interface Netlogon do DC (NetrServerReqChallenge / NetrServerAuthenticate3) partindo de um mesmo host em curto intervalo de tempo — comportamento incomum para autenticação legítima de máquina, que normalmente ocorre uma vez por sessão. Não há uma assinatura de payload único a procurar, já que o ataque manipula apenas campos criptográficos zerados em chamadas RPC estruturalmente válidas; a detecção depende de análise de frequência/comportamento, não de matching de conteúdo.