Zerologon CVE-2020-1472 Aplicação Active Directory: Por que Ainda Falta em Tantos DCs

Zerologon CVE-2020-1472 Aplicação Active Directory: O Que Isso Significa

Zerologon CVE-2020-1472 Aplicação Active Directory são a parte da remediação dessa vulnerabilidade que continua sendo pulada, mesmo que a vulnerabilidade em si já seja notícia antiga. Zerologon é uma falha crítica (CVSS 10.0) de elevação de privilégio no Netlogon Remote Protocol (MS-NRPC), o mecanismo que máquinas associadas ao domínio usam para estabelecer um canal seguro com um controlador de domínio. Foi descoberta e divulgada de forma responsável por Tom Tervoort, da Secura, que publicou o whitepaper técnico em setembro de 2020 (Secura). O próprio aviso da Microsoft a classifica como uma Netlogon Elevation of Privilege Vulnerability (MSRC CVE-2020-1472).

O motivo pelo qual ainda vale a pena escrever sobre isso mais de três anos após a divulgação não é o exploit em si — é a fase de aplicação (enforcement). A Microsoft lançou as correções do Zerologon em duas etapas, e é na segunda etapa que a maioria dos ambientes silenciosamente estaciona: corrigido, mas nunca confirmado como estando em aplicação. Isso importa porque "Zerologon" carrega reconhecimento suficiente para que muitas equipes o tratem como um problema resolvido e histórico, em vez de algo que vale a pena reverificar em uma auditoria de rotina — e ele continua aparecendo ao lado das más configurações mais comuns de segurança do Active Directory que as auditorias encontram todos os anos.

Como o Zerologon Funciona

A causa raiz é um erro de implementação criptográfica em ComputeNetlogonCredential, a função que o MS-NRPC usa para derivar uma chave de sessão durante NetrServerAuthenticate3. O Netlogon usa AES-CFB8 nessa troca, mas a implementação da Microsoft definiu o vetor de inicialização (IV) com um valor fixo de 16 bytes zero em vez de um valor aleatório — uma violação de como o AES-CFB8 deveria ser usado (whitepaper da Secura, via Pwnie Awards).

Essa falha tem uma consequência específica e explorável: para aproximadamente 1 em cada 256 chaves possíveis, criptografar um texto simples totalmente zero com AES-CFB8 e um IV zero produz um texto cifrado totalmente zero.

A Sequência do Ataque

Um atacante não autenticado na rede pode:

1. Personificar uma conta de computador (incluindo a própria conta do controlador de domínio) no handshake do Netlogon.
2. Enviar um desafio de cliente composto por 8 bytes zero.
3. Repetir o handshake — em média cerca de 256 tentativas — até que o servidor aceite a credencial totalmente zero.
4. Após autenticado, chamar NetrServerPasswordSet2 para redefinir a senha da conta de máquina de um alvo, incluindo o próprio DC, para um valor conhecido.

A partir daí, um atacante que redefiniu a senha da própria conta de computador de um controlador de domínio pode se autenticar como esse DC e executar DCSync para extrair todos os hashes de senha do domínio — comprometimento total do domínio, não autenticado, em minutos. Sem credenciais, sem phishing, sem malware no endpoint — apenas alcance de rede até o serviço Netlogon de um controlador de domínio. Nosso artigo complementar sobre abuso de ACL e DCSync cobre como é esse abuso de replicação uma vez que um atacante tem os direitos para acioná-lo.

Exploração Confirmada em Ambiente Real

A CISA adicionou a CVE-2020-1472 ao seu catálogo Known Exploited Vulnerabilities e emitiu a Emergency Directive 20-04, ordenando que todas as agências federais dos EUA corrigissem ou desconectassem os controladores de domínio afetados até as 23h59 EDT de 21 de setembro de 2020 (CISA ED 20-04). A CISA confirmou posteriormente a exploração ativa da falha por atores estatais (alerta da CISA, outubro de 2020), e desde então ela também foi observada em invasões de ransomware direcionadas a controladores de domínio não corrigidos. A combinação de uma pontuação CVSS máxima, nenhuma exigência de autenticação e uma prova de conceito pública é exatamente o motivo pelo qual essa classe de vulnerabilidade merece uma reverificação, e não apenas um "corrigir e esquecer" único.

Por Que a Aplicação É um Problema Separado da Correção

A Microsoft lançou a correção em duas fases, e é exatamente esse faseamento que faz as lacunas de aplicação persistirem anos depois de todos acreditarem que o assunto está encerrado.

Fase 1 — Atualização de 11 de Agosto de 2020

Esse patch mudou a forma como os DCs tratam conexões Netlogon vulneráveis e introduziu a configuração de registro FullSecureChannelProtection sob HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters, mas a aplicação era opcional. Os DCs entravam em uma "Initial Deployment Phase", na qual dispositivos não compatíveis eram registrados em log, não bloqueados, a menos que um administrador definisse explicitamente o valor de registro ou implantasse o GPO de aplicação (Suporte Microsoft: gerenciando alterações nas conexões de canal seguro do Netlogon).

Fase 2 — Atualização de 9 de Fevereiro de 2021

Essa atualização tornou o modo de aplicação o comportamento padrão para todos os controladores de domínio Windows, independentemente da configuração de registro ou de Política de Grupo (Tenable: Microsoft finaliza a aplicação padrão do Zerologon).

A Lacuna da Lista de Exceção do GPO

A lacuna que a maioria das auditorias encontra hoje não é "Zerologon não corrigido" — são ambientes em que dispositivos legados ou de terceiros (appliances NAS, servidores de impressão, clientes Netlogon não Windows mais antigos) quebraram sob a aplicação em 2021, e um administrador os adicionou à lista de exceção de Política de Grupo "Controlador de domínio: Permitir conexões de canal seguro do Netlogon vulneráveis" para interromper a interrupção. Essa lista de exceção é exatamente a lacuna de aplicação: ela continua lá, sem revisão, anos depois, permitindo silenciosamente o mesmo handshake vulnerável que o Zerologon explora — limitada às contas que foram isentadas. Um controlador de domínio pode estar totalmente corrigido e ainda assim ter esse buraco aberto por política, motivo pelo qual o relatório de nível de patch, sozinho, não é evidência suficiente de aplicação.

Detecção

O Netlogon registra em log IDs de evento específicos para atividade de canal seguro vulnerável em cada controlador de domínio. Monitore-os em todos os DCs, não apenas em um. Consulte também o guia sobre prioridades de hardening do Active Directory para colocar esses controles em contexto:

(Suporte Microsoft: gerenciando alterações nas conexões de canal seguro do Netlogon)

Coletando os Eventos

Concretamente, em cada controlador de domínio:

# Coletar eventos recentes de canal vulnerável do Netlogon a partir do log do Sistema
Get-WinEvent -LogName System -FilterXPath "*[System[(EventID=5827 or EventID=5828 or EventID=5829 or EventID=5830 or EventID=5831)]]" -MaxEvents 200 |
    Select-Object TimeCreated, Id, Message |
    Format-Table -AutoSize

# Confirmar diretamente o estado de aplicação no registro (informativo em DCs corrigidos com o
# patch de fevereiro de 2021, onde a aplicação é o padrão independentemente desse valor)
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name FullSecureChannelProtection -ErrorAction SilentlyContinue

Qualquer evento 5829, 5830 ou 5831 é um sinal que vale a pena investigar — ele identifica exatamente qual dispositivo ainda depende do handshake vulnerável e por quê, e fornece uma lista concreta para trabalhar em vez de uma suposição de política. Combine o monitoramento de eventos do Netlogon com o conjunto mais amplo de event IDs de segurança do Active Directory que já deveriam estar no seu SIEM.

Remediação

1. Confirme o nível de patch em cada DC, não em uma amostra. Verifique se cada controlador de domínio tem, no mínimo, a atualização de 11 de agosto de 2020, e idealmente a atualização cumulativa de 9 de fevereiro de 2021 ou posterior, que torna a aplicação o padrão. DCs esquecidos (incluindo DCs somente leitura e DCs em domínios/florestas menos visíveis) são a lacuna mais comum.
2. Audite o GPO "Controlador de domínio: Permitir conexões de canal seguro do Netlogon vulneráveis". Revise cada entrada da lista de exceção. Para cada dispositivo isento, confirme que ele ainda existe, ainda precisa da exceção e não tem atualização de firmware/software do fabricante disponível que adicione suporte adequado a RPC seguro. Remova entradas obsoletas.
3. Monitore continuamente os eventos 5829/5830/5831, não apenas durante uma janela de implantação única. Qualquer nova ocorrência significa que um dispositivo depende hoje do caminho vulnerável.
4. Defina (ou verifique) FullSecureChannelProtection = 1 em qualquer DC que ainda não tenha recebido a atualização de fevereiro de 2021 ou posterior, como controle provisório enquanto a correção é concluída.
5. Reverifique após mudanças de infraestrutura. Novos controladores de domínio, promoções de DC a partir de templates/imagens e mudanças de trust entre florestas/domínios podem reintroduzir um estado não aplicado ou não corrigido — incorpore isso à revisão padrão de GPO e de build de DC, não apenas ao rollout inicial de 2020/2021.
6. Trate a exposição a DCSync como o risco a jusante. O impacto real do Zerologon é dar a um atacante a capacidade de redefinir a senha da própria conta de um DC e extrair os hashes de senha do domínio. Revisar quem e o que já possui direitos legítimos de replicação capazes de DCSync fecha a segunda metade desse caminho de ataque — veja nosso guia sobre abuso de ACL e DCSync.

Como a EtcSec Detecta Isso

A verificação ZEROLOGON_PATCH_ENFORCEMENT da EtcSec sinaliza controladores de domínio nos quais a aplicação do Zerologon não pode ser confirmada — seja um patch ausente, uma configuração FullSecureChannelProtection desativada em um DC anterior a fevereiro de 2021, ou uma GPO de exceção do Netlogon ativa — para que isso não seja silenciosamente assumido como "resolvido em 2020". Ela é combinada com DCSYNC_CAPABLE, que sinaliza contas e objetos de computador com direitos de replicação que um comprometimento no estilo Zerologon permitiria a um atacante explorar para extração completa de credenciais. Juntas, as duas verificações mapeiam o caminho de ataque completo: o ponto de apoio inicial não autenticado e os direitos de replicação privilegiados que o transformam em uma violação em todo o domínio.