MENU
  1. Início
  2. Windows
  3. Windows Server
  4. Alterações no Netlogon (CVE‑2022‑38023) e impacto na autenticação NTLM: passo a passo para manter DCs atualizados sem derrubar serviços

Alterações no Netlogon (CVE‑2022‑38023) e impacto na autenticação NTLM: passo a passo para manter DCs atualizados sem derrubar serviços

Windows Server

Administradores de AD estão vendo logons NTLM falharem após o KB5021130? Este guia explica o que mudou no Netlogon, como diagnosticar quem ainda depende de NTLM/Netlogon sem selagem, e um plano prático para manter os controladores de domínio seguros sem derrubar serviços legados, até concluir a migração.

Índice

Contexto e por que o problema aparece agora

O patch que endereça a vulnerabilidade CVE‑2022‑38023 fortaleceu o Netlogon exigindo RPC Sealing (assinar e criptografar) nos canais seguros. Em ambientes com dispositivos antigos, isso gera erros de autenticação NTLM porque esses clientes ainda falam com os DCs apenas com RPC Signing (só assinatura). A mudança foi lançada por fases: atualização inicial em 8/nov/2022, “enforcement por padrão” em 13/jun/2023 e fiscalização final em 11/jul/2023 (quando a opção de “compatibilidade” foi retirada).

O que exatamente mudou no Netlogon

  • RPC Signing x RPC Sealing: Signing apenas garante integridade; Sealing garante integridade e confidencialidade. A correção força Sealing para impedir manipulação de tráfego Netlogon.
  • Chave de registro RequireSeal: disponível em HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters (REG_DWORD). Valores: 0 (desligado), 1 (compatibilidade), 2 (enforcement). Observação importante: a chave não é criada automaticamente; precisa ser adicionada se você quiser defini-la explicitamente. A partir de 11/jul/2023, as atualizações removem a capacidade de usar o valor 1 (compatibilidade).
  • Eventos novos: os DCs passam a registrar quem ainda tenta usar apenas assinatura ou criptografia fraca:
    • 5838 – cliente usando RPC signing em vez de sealing;
    • 5839 – trust (confiança) usando signing em vez de sealing;
    • 5840 (aviso) – canal seguro usando RC4;
    • 5841 – cliente RC4 bloqueado por RejectMd5Clients.
    Há deduplicação de 1 hora desses eventos.

Importante: a Microsoft removeu referências antigas ao GPO “Allow vulnerable Netlogon secure channel connections” deste contexto. Não use essa exceção para a CVE‑2022‑38023.

Como saber quem ainda depende de NTLM/Netlogon sem selagem

Ative auditoria e cole os eventos 5838/5839/5840/5841 de todos os DCs. Para começar rápido, use as consultas abaixo e consolide os resultados por computador.

# Últimos 7 dias: clientes que geraram 5838 (sem sealing)
$start = (Get-Date).AddDays(-7)
$dcs   = (Get-ADDomainController -Filter *).HostName

$events = foreach ($dc in $dcs) {
  Get-WinEvent -ComputerName $dc -FilterHashtable @{
    LogName='System'; Id=5838; StartTime=$start
  } -ErrorAction SilentlyContinue | Select-Object MachineName, TimeCreated, Message
}

$map = $events | ForEach-Object {
  # tenta extrair o SamAccountName do texto do evento
  if ($_.Message -match 'Machine SamAccountName:\s*(\S+)') {
    [pscustomobject]@{
      DC      = $_.MachineName
      Cliente = $matches[1]
      Quando  = $_.TimeCreated
    }
  }
}

$map | Group-Object Cliente | Sort-Object Count -Descending |
  Select-Object Count, Name | Format-Table -Auto

Para relacionamentos de trust entre domínios/florestas (evento 5839), amplie a consulta (Id=5839) e valide se o domínio parceiro também está atualizado.

Tabela de referência rápida

FaseO que fazerDetalhes práticos
Avaliar o ambienteMapear quem ainda usa NTLM/Netlogon sem selagem.Monitore os eventos 5838/5839 (e 5840/5841 para RC4). Use WEF, SIEM ou os scripts acima; lembre do buffer de 1h que suprime duplicatas.
Entender o cronogramaPlanejar à luz das datas de enforcement.Enforcement por padrão desde 13/jun/2023; fiscalização final em 11/jul/2023 removeu a opção de compatibilidade (RequireSeal=1).
Definir política transitóriaSe seus DCs ainda estiverem em builds anteriores a 11/jul/2023, você pode usar RequireSeal=1 por curtíssimo prazo para dar visibilidade enquanto corrige clientes.Em builds atuais (com atualizações de 11/jul/2023 ou posteriores), não conte com o modo de compatibilidade: a capacidade de usar 1 foi removida. Priorize correção no cliente.
Atualizar/substituir clientesAplicar patches de 11/2022 ou mais novos em Windows; atualizar firmware e bibliotecas de dispositivos de terceiros; migrar para Kerberos/LDAP‑TLS onde possível.Vários appliances (NAS, impressoras, proxies, IDS/IPS, etc.) exigem atualização específica para suportar RPC Sealing; confirme com o fornecedor. Casos comuns: NAS/ONTAP e filers herdados que faziam pass‑through NTLM via Netlogon.
Testar antes de mudarValidar em laboratório que replica seu domínio.Atualize DCs, varie RequireSeal (se aplicável no seu build), rode nltest /sc_verify:, Test-ComputerSecureChannel, revise logs.
Ir para EnforcementDefinir RequireSeal=2 explicitamente (quando usar a chave) e manter os DCs atualizados.A chave precisa existir para ser lida; com releases atuais a fiscalização já é o padrão, mas definir 2 formaliza o estado.
Endurecer o restanteRestringir NTLM, assinar SMB, segmentar rede e monitorar continuamente.Use as diretrizes “Network security: Restrict NTLM…”, ative assinatura SMB em cliente/servidor e rastreie 5838/5839 por mais alguns dias após a virada.
Suporte contínuoAcompanhar novos boletins e notas de hardening.Em 2025, a Microsoft publicou hardening adicional no Netlogon contra chamadas anônimas; permaneça atento a mudanças correlatas.

Procedimentos que funcionam no dia a dia

Identificar e priorizar os alvos mais críticos

  1. Junte as evidências de 7–14 dias de 5838/5839 em todos os DCs.
  2. Classifique por impacto: controladoras de storage (NAS), servidores de arquivos, impressão, aplicações line‑of‑business e trusts.
  3. Att&ck surface: onde há 5840/5841, há criptografia fraca (RC4) — alvos prioritários.

Acertar configurações de membro de domínio

  • Verifique a política “Domain member: Digitally encrypt or sign secure channel data (always)” e mantenha-a Habilitada nos membros do domínio.
  • Se possível, habilite também “Domain member: Require strong session key” para aumentar o nível de proteção do canal seguro.

Corrigir trusts que disparam 5839

Se o evento 5839 vier de uma confiança (interna ou com terceiros), alinhe o nível de patch de ambos os lados e valide as opções de segurança da confiança (revalidação de senha de confiança, outgoing/incoming trusts, etc.).

Quando usar a chave RequireSeal

  • Builds atuais: a fiscalização já é o padrão; definir RequireSeal=2 apenas torna explícito no registro (reinício do serviço Netlogon não é requerido, mas um ciclo de GPO/reboot pode ajudar em clientes).
  • Ambientes antigos (pré 11/jul/2023): RequireSeal=1 (compatibilidade) era um tampão com telemetria; hoje, não é o caminho de longo prazo porque a capacidade de usar 1 foi removida nas atualizações mais recentes. Planeje a eliminação.
:: Tornar explícito o enforcement (caso use a chave)
reg add HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters ^
  /v RequireSeal /t REG_DWORD /d 2 /f

Ajustes em dispositivos não‑Windows

Alguns fornecedores liberaram firmware para suportar Netlogon com RPC Sealing. Sem isso, autenticações NTLM pass‑through tendem a falhar. Exemplo típico: arrays de armazenamento e NAS que delegam NTLM para o AD. A orientação nesses casos é atualizar ou migrar o método de autenticação para Kerberos/LDAP‑TLS.

Políticas de endurecimento que reduzem risco enquanto você migra

  • Restrinja NTLM via GPO (Security Options → Network security: Restrict NTLM…):
    • Outgoing NTLM to remote servers: bloqueie por padrão e crie exceções estritamente necessárias.
    • Incoming NTLM traffic: inicie em “Audit All” e evolua para “Deny All” por escopo.
    • Defina “LAN Manager authentication level” para “Enviar apenas NTLMv2. Recusar LM e NTLM”.
  • Assinatura SMB obrigatória no cliente e no servidor para limitar downgrades no acesso a arquivos.
  • Segmentação de rede isolando os legados até a desativação/migração.
  • Monitoração contínua: alimente o SIEM com 5838/5839/5840/5841 para detectar regressões e novos dispositivos não conformes.

Testes de validação após as mudanças

  1. Canal seguro: nltest /sc_verify:SEU.DOMINIO e Test-ComputerSecureChannel -Server DC01 -Verbose.
  2. Autenticação de usuários: testes de logon interativo e de acesso a recursos remotos que antes dependiam de NTLM.
  3. Trusts: verifique autenticações entre florestas/domínios e a emissão de tickets.
  4. Telemetria: confirme a queda a zero de 5838/5839 e se 5840/5841 não estão crescendo (indício de RC4).

Erros comuns e como evitar

  • Confundir eventos: para a CVE‑2022‑38023, foque em 5838/5839 (e 5840/5841). Os eventos 5830–5831 remetem ao endurecimento do Zerologon de 2020 e não indicam, por si só, o problema de RPC Sealing atual.
  • Buscar “atalho” via GPO de exceção: a própria Microsoft removeu essa recomendação deste caso; privilegie atualização/migração do cliente.
  • Pressupor que a chave existe: se você quer definir RequireSeal, crie a subchave; as atualizações não a adicionam/removem automaticamente.

Roteiro sugerido para não derrubar NTLM de um dia para o outro

Se sua operação ainda depende de NTLM em pontos isolados, use um roteiro realista:

  1. Inventariar e medir com base em eventos e testes ponta‑a‑ponta.
  2. Estabilizar serviços críticos: atualizar dispositivos, habilitar RPC Sealing e, quando viável, migrar chamadas para Kerberos ou LDAP com TLS.
  3. Virar a chave para enforcement explícito (RequireSeal=2 quando aplicável) após zerar alertas relevantes.
  4. Endurecer NTLM e SMB; reduzir a superfície; monitorar continuamente.
  5. Remover NTLM por completo de serviços sob seu domínio, priorizando movimentações laterais e pontos de pass-through.

Perguntas rápidas

“Tenho aplicações que ainda precisam de NTLM. O que faço?”
Mantenha os DCs atualizados (não retroceda). Corrija ou isole o cliente. Em último caso, redesenhe o fluxo para usar Kerberos/LDAP‑TLS. Para NAS/impressoras/filers antigos, confirme firmware específico para RPC Sealing.

“Preciso mesmo do registro RequireSeal?”
Em releases atuais, a aplicação já é o padrão. A chave é útil para declarar a postura (por exemplo, 2) e para auditoria/configuração como código.

“Haverá novas quebras?”
Possível. Em 2025 a Microsoft apertou o Netlogon novamente, eliminando chamadas RPC anônimas ao localizador de DCs. Inclua essa verificação no seu runbook de mudanças.

Checklist final de pronto‑para‑enforcement

  • Não há eventos 5838/5839 críticos nos últimos 7 dias em nenhum DC.
  • Toda dependência conhecida de NTLM foi patchada, migrada para Kerberos/LDAP‑TLS ou isolada temporariamente com prazo de desligamento.
  • Políticas “Restrict NTLM” implantadas, com exceções nomeadas e expiradas.
  • Assinatura SMB habilitada em servidores e clientes essenciais.
  • Equipe operacional com monitores/alertas para 5838/5839/5840/5841 e runbooks de resposta.

Conclusão

É totalmente possível manter os controladores de domínio atualizados e preservar a continuidade dos sistemas legados, desde que você trate a exigência de RPC Sealing como o novo piso de segurança e conduza uma migração orientada por telemetria. O caminho sustentável é: diagnosticar com eventos 5838/5839, corrigir ou substituir clientes, explicitar o enforcement e endurecer NTLM até a eliminação definitiva do legado.

Resumo prático: mapeie quem ainda usa NTLM via Netlogon, atualize os clientes para suportar selagem, valide em laboratório e então habilite/enforce o RequireSeal. Paralelamente, aplique políticas “Restrict NTLM”, assinatura SMB e monitoração contínua. Assim, você mantém os DCs com os patches mais recentes sem interromper a autenticação até a conclusão da migração.

Windows Server
Active Directory CVE-2022-38023 KB5021130 Netlogon NTLM RPC Sealing Windows Server
Índice