Sumário executivo
O processo de Silverfort Uma equipe de pesquisa de segurança identificou uma vulnerabilidade de negação de serviço (DoS) no protocolo Netlogon da Microsoft, um componente central usado por todos os controladores de domínio do Windows. O problema, que chamamos de NOTLogon e que a Microsoft nomeou como Vulnerabilidade de negação de serviço do Kerberos do Windows, permite qualquer máquina associada ao domínio com privilégios mínimos para enviar uma solicitação de autenticação especialmente criada que travará um controlador de domínio e causará uma reinicialização completa.
Esta vulnerabilidade não requer privilégios elevados — apenas acesso padrão à rede e uma conta de máquina fraca são necessários. Em ambientes corporativos típicos, qualquer usuário com poucos privilégios pode criar essas contas por padrão.
A falha afeta o LSASS, o principal processo de segurança do Windows, e causa uma interrupção generalizada no Active Directory Serviços, incluindo logins de usuários, aplicação de políticas e recursos dependentes de autenticação. A Microsoft atribuiu a ele uma classificação CVE de 6.5 e emitiu uma correção para CVE-2025-47978 como parte do Patch Tuesday de 8 de julho de 2025. Recomendamos fortemente a implantação imediata desta atualização em todos os controladores de domínio, juntamente com o reforço dos controles de acesso para contas de serviço e de máquina.
Descoberta de vulnerabilidades por meio de IA
Uma das primeiras e mais difíceis perguntas que um pesquisador de segurança deve considerar é onde é mais provável encontrar uma vulnerabilidade. Os pesquisadores analisam vastas quantidades de dados, código e documentação e, em seguida, escolhem os locais certos para uma análise mais aprofundada. Para acelerar o processo e testar os limites da IA, utilizamos LLMs para identificar potenciais falhas, comparando notas de versão antigas com as novas. Essa abordagem levou recentemente à descoberta deste zero-day. Active Directory Vulnerabilidade de negação de serviço.
Como funciona a vulnerabilidade DoS
O Netlogon Remote Protocol (MS-NRPC) é uma parte fundamental da rede baseada em domínio do Windows, usado para autenticar usuários e máquinas e manter canais seguros entre membros do domínio e Controladores de Domínio (DCs). Dada sua posição privilegiada e presença constante na rede, mesmo vulnerabilidades de escalonamento sem privilégios no Netlogon podem ser catastróficas.
Quando pensamos em autenticação Ao analisar vulnerabilidades, frequentemente imaginamos invasores escalando privilégios, roubando credenciais ou executando código remoto. Mas algumas das ameaças mais disruptivas podem ser puramente destrutivas — cortando acessos, interrompendo serviços e interrompendo operações em todo o domínio. Nesta publicação, descobrimos o NOTLogon, uma vulnerabilidade de negação de serviço (DoS) no protocolo Netlogon que pode desestabilizar ou desabilitar o núcleo. Active Directory operações explorando falhas na negociação de sessão e no tratamento de estado.
NETLOGON 101
Para compreender as implicações do NOTLogon, precisamos entender o protocolo Netlogon, uma parte fundamental da arquitetura de segurança baseada em domínio da Microsoft. O Protocolo Remoto Netlogon (MS-NRPC) é um protocolo de autenticação privilegiada e estabelecimento de canal usado por computadores associados a um domínio e Controladores de Domínio (DCs). Introduzido no Windows NT e ainda usado ativamente hoje, o Netlogon habilita funcionalidades de domínio remoto, como autenticação de contas de máquina, atuando como um agente de autenticação, facilitando a rotação de senhas e suportando inúmeras outras operações confidenciais críticas para Active Directory a infraestrutura.
Uma das funções mais críticas, embora frequentemente negligenciadas, do protocolo Netlogon é sua função como um agente de autenticação em ambientes de domínio Windows. Embora comumente associado ao estabelecimento de canais seguros para contas de máquina, o Netlogon também atua como intermediário entre o Serviço de Subsistema de Autoridade de Segurança Local (LSASS) e os controladores de domínio para processar solicitações de autenticação de usuários. Quando um usuário efetua login pela rede em um aplicativo remoto, o LSASS delega a autenticação ao Netlogon se as credenciais precisarem ser validadas. Active DirectoryO Netlogon então encapsula a solicitação em uma mensagem específica do protocolo chamada NetrLogonSamLogon e a encaminha ao controlador de domínio apropriado, processando a negociação e a resposta de forma transparente. Isso é conhecido como autenticação de passagem.
Que tipos de cenários de autenticação o Netlogon suporta?
O Netlogon suporta uma ampla gama de cenários de autenticação por meio de sua união NETLOGON_LEVEL, oficialmente conhecida como NETLOGON_LOGON_INFO_CLASS, que define como as credenciais de usuário e serviço são empacotadas e encaminhadas. De acordo com a especificação MS-NRPC, os níveis suportados incluem:
Informações interativas de logon de rede: Para logons interativos, onde os usuários inserem credenciais na estação de trabalho (por exemplo, via Ctrl+Alt+Del). Este nível permite a verificação de desafio/resposta (normalmente NTLM ou Kerberos) enviado ao DC.
Informações de rede de logon de rede: Para logons de rede, como acessar recursos SMB ou RPC após um logon interativo. Credenciais (como NTLM Os tokens são reenviados de forma transparente, sem avisar o usuário.
Informações do serviço de logon de rede: Para logons de contas de serviço, usados quando serviços do Windows são autenticados com credenciais de domínio para acessar recursos.
Níveis transitivos (interativo, rede, serviço): Variantes do acima que permitem autenticação entre domínios ou vinculada à confiança, onde as credenciais se propagam entre domínios com relacionamentos de confiança — por exemplo, NetlogonInteractiveTransitiveInformation, NetlogonNetworkTransitiveInformation e NetlogonServiceTransitiveInformation.
Informações genéricas de logon de rede: Para autenticação de passagem genérica, incluindo NTLM, Digest e Kerberos Validação PAC, onde um servidor aceita credenciais do usuário e as retransmite para um DC para validação.
Como o Netlogon está evoluindo?
Com o NTLM oficialmente obsoleto, a Microsoft revelou a especificação Network Ticket Logon em 29 de julho de 2024 e a finalizou em uma atualização do MS-NRPC lançada em 19 de novembro de 2024. Esse aprimoramento permite que os serviços apresentem tickets Kerberos pré-emitidos a um controlador de domínio usando o NetrLogonSamLogonEx RPC, eliminando a necessidade de o cliente original entrar em contato diretamente com o DC.
Este cenário oferece suporte a recursos futuros, como o LocalKDC, em que a validação de tickets pode ocorrer offline ou por meio de intermediários. Como ele introduz uma nova lógica para análise de tickets, verificação de PAC e tratamento de confiança delegada em um caminho RPC privilegiado, começamos a analisar o mecanismo de Logon de Tickets de Rede para avaliar seus limites de segurança e o potencial de uso indevido.
Nossa jornada no novo cenário de Logon de Tíquete de Rede começou com seu mecanismo de entrega: a chamada RPC NetrLogonSamLogonEx. A Microsoft introduziu essa chamada originalmente para generalizar os fluxos de logon, mas, a partir de julho de 2024, ela passou a oferecer suporte a um caminho de autenticação totalmente novo, aceitando a estrutura NETLOGON_TICKET_LOGON_INFO. Este é o cerne do cenário de logon do tíquete de rede—permitindo que serviços enviem tickets Kerberos para um controlador de domínio para validação, sem exigir que o cliente original interaja diretamente com o DC.
Voltamos nossa atenção para a especificação de NETLOGON_TICKET_LOGON_INFO e imediatamente nos deparamos com complexidade e ambiguidade. Dois campos em particular chamaram nossa atenção: ServiceTicket e AdditionalTicket, ambos declarados como buffers PUCHAR (um tipo de ponteiro usado na programação de APIs do Windows para representar uma matriz de bytes bruta — essencialmente um endereço que aponta para um buffer de caracteres não assinados de comprimento arbitrário). A função de ServiceTicket foi claramente definida como "um ponteiro para uma matriz de caracteres não assinados contendo o tíquete de serviço". Simples assim.
Mas AdditionalTicket era muito mais ambíguo. A especificação observa: "Se o tíquete de serviço for um tíquete User2User, o tíquete de concessão de tíquete (TGT) usado como fonte da chave de sessão também deve ser fornecido". Isso levantou mais perguntas do que respostas. Este campo é opcional, a menos que o tíquete represente um cenário U2U? O conteúdo esperado é sempre um TGT? Outros tipos de tíquete podem ser válidos? Para complicar a situação, o campo AdditionalTicketLength que o acompanha é descrito como "o comprimento do tíquete de serviço Kerberos que é a fonte da autorização" — uma declaração conflitante se o buffer deve conter um TGT.
Com a clareza limitada da documentação, partimos para a experimentação. Construímos a estrutura manualmente e começamos a enviar solicitações controladas para um controlador de domínio totalmente corrigido. Ao lidar com RPCs privilegiados como o Netlogon, a implementação geralmente fala mais alto do que as especificações.
O requisito mínimo para executar um NetrLogonSamLogonEx é uma conta de máquina registrada no domínio, que representa um computador ou servidor. Notavelmente, por padrão, cada usuário pode criar até 10 contas de máquina em um domínio. Active Directory domínio. Isso significa que um usuário fraco é suficiente para se conectar à interface Netlogon e executar um Logon de Ticket de Rede em um controlador de domínio.
A falha: onde o logon do tíquete de rede falha
Assim que obtivemos uma estrutura NETLOGON_TICKET_LOGON_INFO funcional, enviamos uma solicitação de logon de tíquete de rede padrão ao controlador de domínio usando NetrLogonSamLogonEx. A solicitação incluía um tíquete de serviço válido, como esperado. Embora a chamada do Netlogon tenha retornado STATUS_SUCCESS, o campo KerberosError incorporado na resposta continha STATUS_INSUFFICIENT_RESOURCES — um resultado incomum e suspeito para uma solicitação aparentemente válida.
Para investigar mais a fundo, começamos a fuzzing a estrutura. A omissão completa do ServiceTicket retornou o STATUS_INVALID_PARAMETER esperado. No entanto, quando direcionamos o campo AdditionalTicket e o enviamos como um buffer vazio, observamos uma falha no controlador de domínio.
O despejo de memória apontou para uma função chamada KdcUnpackAdditionalTgt, responsável por decodificar o buffer AdditionalTicket em uma estrutura Kerberos KERB_TICKET ASN.1. A função falhou gravemente ao validar se o buffer de entrada não estava vazio e estava bem formado antes de tentar a decodificação. Isso levou a uma desreferência NULL dentro do LSASS, o processo do Windows que controla a autenticação e a aplicação de políticas de segurança.
Como o LSASS é um processo protegido, sua falha resultou em uma falha completa do sistema e acionou a reinicialização do controlador de domínio. Para entender os requisitos mínimos para exploração, testamos se um tíquete de serviço válido era necessário. Não era— o caminho do código vulnerável é alcançado antes que o ServiceTicket seja avaliado. Mais importante ainda, não requer privilégios altos — apenas acesso à rede e uma conta de máquina fraca são suficientes para desencadear a falha.
Isso forma o núcleo do NOTLogon: uma vulnerabilidade de negação de serviço introduzida pelo novo cenário de Network Ticket Logon. Devido à falta de validação em um manipulador de buffer recém-adicionado, uma única chamada RPC malformada pode desestabilizar controladores de domínio, representando uma séria ameaça à confiabilidade e disponibilidade em ambientes corporativos.
Criando o caos: implicações e mitigação
As implicações do NOTLogon são diretas e severas. Com apenas uma conta de máquina válida e uma mensagem RPC elaborada, um invasor pode derrubar remotamente um controlador de domínio — um sistema responsável pelas principais funcionalidades de Active Directory, incluindo autenticação, autorização, aplicação de Política de Grupo e emissão de tickets de serviço. A falha de todos os controladores de domínio paralisa efetivamente o domínio, cortando o acesso a recursos, interrompendo logins de usuários e interrompendo todos os componentes que dependem de identidade centralizada.
Não requer privilégios altos — apenas acesso à rede e uma conta de máquina fraca. Em ambientes com credenciais mal gerenciadas ou segmentação insuficiente entre estações de trabalho e controladores de domínio, o NOTLogon se torna um vetor de baixo custo e alto impacto para interrupção operacional.
Recomendamos fortemente a instalação da versão mais recente Atualização do Microsoft Patch Tuesday lançada em 8 de julho de 2025, que inclui uma correção para CVE-2025-47978. As organizações devem aplicar patches em todos os controladores de domínio sem demora, pois o problema reside no próprio serviço Netlogon. Paralelamente, os administradores devem auditar e proteger as contas das máquinas, restringir o acesso à rede para controladores de domínio, e limitar e monitorar o acesso à conta de serviço, especialmente aquelas capazes de iniciar fluxos Netlogon RPC.
Como criar uma postura de segurança de identidade mais segura em Active Directory
É altamente recomendável corrigir esta vulnerabilidade; no entanto, paralelamente, as equipes devem auditar e proteger contas de máquina, restringir o acesso a controladores de domínio e limitar e monitorar o acesso a contas de serviço, especialmente aquelas capazes de iniciar fluxos de Netlogon RPC. Active Directory (AD) como a espinha dorsal das redes da maioria das organizações, é essencial garantir sua higiene de segurança para reduzir a ameaça de invasores usá-la para obter acesso não autorizado a dados confidenciais. Silverfort pode ajudar você a limpar Active Directory e reduza sua dívida tecnológica de várias maneiras, incluindo:
- Descobrindo contas de administrador ocultas (Aka administradores sombra) e configurações incorretas que podem expandir silenciosamente sua superfície de ataque.
- Identificar e eliminar práticas de risco, como Uso do NTLMv1 e obsoleto contas de serviço que não são detectados em ferramentas nativas.
- Defendendo-se contra ataques furtivos baseados em identidade, gostar Kerberasting e explorações do Print Spooler, antes que elas se agravem.
NOTLogon é um lembrete de que novos recursos de protocolo — especialmente em serviços de autenticação privilegiada — podem se tornar superfícies de ataque da noite para o dia. Manter a segurança não se trata apenas de aplicar patches — trata-se de examinar os sistemas básicos dos quais dependemos diariamente.
Para saber mais sobre como fortalecer seu Active Directory postura, baixe nosso guia “5 maneiras de melhorar a higiene do seu anúncio. "