Resumen ejecutivo
La Silverfort El equipo de investigación de seguridad identificó una vulnerabilidad de denegación de servicio (DoS) en el protocolo Netlogon de Microsoft, un componente fundamental que utilizan todos los controladores de dominio de Windows. El problema, al que nos referimos como NOTLogon y Microsoft lo ha denominado... Vulnerabilidad de denegación de servicio de Kerberos en Windows, permite cualquier máquina unida a un dominio con privilegios mínimos para enviar una solicitud de autenticación especialmente diseñada que bloqueará un controlador de dominio y provocará un reinicio completo.
Esta vulnerabilidad no requiere privilegios elevados; solo se necesita acceso a la red estándar y una cuenta de equipo vulnerable. En entornos empresariales típicos, cualquier usuario con pocos privilegios puede crear dichas cuentas por defecto.
El fallo afecta a LSASS, el proceso de seguridad principal de Windows, y provoca una interrupción generalizada en Active Directory servicios, incluyendo inicios de sesión de usuarios, aplicación de políticas y recursos que dependen de la autenticación. Microsoft le ha otorgado una calificación CVE de 6.5 y ha publicado una corrección para CVE-2025-47978 como parte del martes de parches del 8 de julio de 2025. Recomendamos encarecidamente la implementación inmediata de esta actualización en todos los controladores de dominio, junto con el refuerzo de los controles de acceso para las cuentas de servicio y de equipo.
Descubrimiento de vulnerabilidades mediante IA
Una de las primeras y más difíciles preguntas que debe plantearse un investigador de seguridad es dónde es más probable encontrar una vulnerabilidad. Los investigadores examinan minuciosamente grandes cantidades de datos, código y documentación, y luego eligen los lugares adecuados para profundizar. Para acelerar el proceso y poner a prueba los límites de la IA, utilizamos LLM para identificar posibles fallos comparando las notas de versiones antiguas con las nuevas. Este enfoque condujo recientemente al descubrimiento de este día cero. Active Directory Vulnerabilidad de denegación de servicio.
Cómo funciona la vulnerabilidad DoS
El Protocolo Remoto Netlogon (MS-NRPC) es un componente fundamental de las redes basadas en dominios de Windows. Se utiliza para autenticar usuarios y equipos, así como para mantener canales seguros entre los miembros del dominio y los Controladores de Dominio (DC). Dada su posición privilegiada y su presencia constante en la red, incluso las vulnerabilidades de Netlogon que no implican escalada de privilegios pueden ser catastróficas.
Cuando pensamos en la autenticación En cuanto a las vulnerabilidades, a menudo imaginamos a los atacantes escalando privilegios, robando credenciales o ejecutando código remoto. Sin embargo, algunas de las amenazas más disruptivas pueden ser puramente destructivas: cortan el acceso, detienen los servicios e interrumpen las operaciones de todo el dominio. En esta publicación, descubrimos NOTLogon, una vulnerabilidad de denegación de servicio (DoS) en el protocolo Netlogon que puede desestabilizar o inhabilitar el núcleo. Active Directory operaciones explotando fallas en la negociación de sesiones y el manejo de estados.
NETLOGON 101
Para comprender las implicaciones de NOTLogon, debemos comprender el protocolo Netlogon, un componente fundamental de la arquitectura de seguridad basada en dominios de Microsoft. El Protocolo Remoto Netlogon (MS-NRPC) es un protocolo de autenticación privilegiada y establecimiento de canales utilizado por equipos unidos a un dominio y controladores de dominio (DC). Introducido en Windows NT y aún en uso activo, Netlogon habilita funcionalidades de dominio remoto como la autenticación de cuentas de equipo, actuando como intermediario de autenticación, facilitando la rotación de contraseñas y dando soporte a numerosas otras operaciones sensibles críticas para... Active Directory infraestructura.
Una de las funciones más importantes, aunque a menudo ignoradas, del protocolo Netlogon es su función como intermediario de autenticación en entornos de dominio Windows. Si bien se asocia comúnmente con el establecimiento de canales seguros para cuentas de equipo, Netlogon también actúa como intermediario entre el Servicio de Subsistema de Autoridad de Seguridad Local (LSASS) y los controladores de dominio para procesar las solicitudes de autenticación de usuarios. Cuando un usuario inicia sesión en una aplicación remota a través de la red, LSASS delega la autenticación a Netlogon si es necesario validar las credenciales. Active DirectoryNetlogon encapsula la solicitud en un mensaje específico del protocolo llamado NetrLogonSamLogon y la reenvía al controlador de dominio correspondiente, gestionando la negociación y la respuesta de forma transparente. Esto se conoce como autenticación de paso a través.
¿Qué tipos de escenarios de autenticación admite Netlogon?
Netlogon admite una amplia gama de escenarios de autenticación mediante su unión NETLOGON_LEVEL, oficialmente conocida como NETLOGON_LOGON_INFO_CLASS, que define cómo se empaquetan y reenvían las credenciales de usuario y servicio. Según la especificación MS-NRPC, los niveles admitidos incluyen:
Información interactiva de Netlogon: Para inicios de sesión interactivos, donde los usuarios ingresan sus credenciales en la estación de trabajo (p. ej., mediante Ctrl+Alt+Supr). Este nivel permite la verificación por desafío/respuesta (normalmente NTLM o Kerberos) enviados al DC.
Información de red de inicio de sesión de red: Para inicios de sesión en red, como acceder a recursos SMB o RPC después de un inicio de sesión interactivo. Credenciales (como NTLM Los tokens se reenvían de forma transparente sin avisarle al usuario.
Información del servicio de inicio de sesión de red:Para inicios de sesión de cuentas de servicio, se utiliza cuando los servicios de Windows se autentican con credenciales de dominio para acceder a los recursos.
Niveles transitivos (interactivo, red, servicio): Variantes de lo anterior que permiten la autenticación entre dominios o basada en confianza, donde las credenciales se propagan a través de dominios con relaciones de confianza, por ejemplo, NetlogonInteractiveTransitiveInformation, NetlogonNetworkTransitiveInformation y NetlogonServiceTransitiveInformation.
Información genérica de inicio de sesión de red:Para la autenticación de paso genérico, incluidos NTLM, Digest y Kerberos Validación de PAC, donde un servidor acepta las credenciales del usuario y las transmite a un DC para su validación.
¿Cómo está evolucionando Netlogon?
Con NTLM oficialmente obsoleto, Microsoft presentó la especificación de inicio de sesión de ticket de red el 29 de julio de 2024 y la finalizó en una actualización de MS-NRPC publicada el 19 de noviembre de 2024. Esta mejora permite a los servicios presentar tickets Kerberos preemitidos a un controlador de dominio mediante el RPC NetrLogonSamLogonEx, lo que elimina la necesidad de que el cliente original se comunique directamente con el DC.
Este escenario admite capacidades futuras como LocalKDC, donde la validación de tickets puede realizarse sin conexión o mediante intermediarios. Dado que introduce una nueva lógica para el análisis de tickets, la verificación de PAC y la gestión de confianza delegada dentro de una ruta RPC privilegiada, comenzamos a analizar el mecanismo de inicio de sesión de tickets de red para evaluar sus límites de seguridad y su potencial de uso indebido.
Nuestro análisis del nuevo escenario de inicio de sesión con ticket de red comenzó con su mecanismo de entrega: la llamada RPC NetrLogonSamLogonEx. Microsoft introdujo esta llamada originalmente para generalizar los flujos de inicio de sesión, pero a partir de julio de 2024, admite una ruta de autenticación completamente nueva al aceptar la estructura NETLOGON_TICKET_LOGON_INFO. Este es el corazón del escenario de inicio de sesión del ticket de red—permite a los servicios enviar tickets Kerberos a un controlador de dominio para su validación, sin necesidad de que el cliente original interactúe directamente con el DC.
Nos centramos en la especificación de NETLOGON_TICKET_LOGON_INFO y de inmediato nos topamos con complejidad y ambigüedad. Dos campos en particular atrajeron nuestra atención: ServiceTicket y FurtherTicket, ambos declarados como búferes PUCHAR (un tipo de puntero utilizado en la programación de la API de Windows para representar una matriz de bytes sin formato; esencialmente, una dirección que apunta a un búfer de caracteres sin signo de longitud arbitraria). La función de ServiceTicket se definió claramente como «un puntero a una matriz de caracteres sin signo que contiene el ticket de servicio». Bastante simple.
Pero el campo "AdditionalTicket" era mucho más ambiguo. La especificación indica: "Si el ticket de servicio es un ticket de usuario a usuario, también debe proporcionarse el ticket de concesión de tickets (TGT) utilizado como fuente de la clave de sesión". Esto generó más preguntas que respuestas. ¿Es este campo opcional a menos que el ticket represente un escenario U2U? ¿El contenido esperado es siempre un TGT? ¿Podrían ser válidos otros tipos de ticket? Para complicar las cosas, el campo "AdditionalTicketLength" que lo acompaña se describe como "la longitud del ticket de servicio Kerberos que es la fuente de la autorización", una afirmación contradictoria si el búfer está diseñado para contener un TGT.
Ante la poca claridad de la documentación, pasamos a la experimentación. Construimos la estructura manualmente y comenzamos a enviar solicitudes controladas a un controlador de dominio con todos los parches instalados. Al trabajar con RPC privilegiados como Netlogon, la implementación suele ser más importante que las especificaciones.
El requisito mínimo para ejecutar NetrLogonSamLogonEx es una cuenta de equipo registrada en el dominio, que representa una computadora o servidor. Cabe destacar que, de forma predeterminada, cada usuario puede crear hasta 10 cuentas de equipo en un... Active Directory Dominio. Esto significa que un usuario débil es suficiente para vincularse a la interfaz Netlogon y realizar un inicio de sesión de ticket de red en un controlador de dominio.
El fallo: dónde falla el inicio de sesión del ticket de red
Una vez que tuvimos una estructura NETLOGON_TICKET_LOGON_INFO funcional, enviamos una solicitud estándar de inicio de sesión de ticket de red al controlador de dominio mediante NetrLogonSamLogonEx. La solicitud incluía un ticket de servicio válido, como se esperaba. Si bien la llamada a Netlogon devolvió STATUS_SUCCESS, el campo KerberosError incrustado en la respuesta contenía STATUS_INSUFFICIENT_RESOURCES, un resultado inusual y sospechoso para una solicitud aparentemente válida.
Para investigar más a fondo, comenzamos a realizar fuzzing en la estructura. Al omitir por completo el ServiceTicket, se devolvió el parámetro STATUS_INVALID_PARAMETER esperado. Sin embargo, al seleccionar el campo FurtherTicket y enviarlo como un búfer vacío, observamos un fallo en el controlador de dominio.
El volcado de memoria apuntó a una función llamada KdcUnpackAdditionalTgt, responsable de decodificar el búfer de "AdditionalTicket" en una estructura Kerberos KERB_TICKET ASN.1. Críticamente, la función no pudo validar que el búfer de entrada no estuviera vacío y tuviera el formato correcto antes de intentar la decodificación. Esto provocó una desreferencia a "NULL" dentro de LSASS, el proceso de Windows que rige la autenticación y la aplicación de políticas de seguridad.
Dado que LSASS es un proceso protegido, su bloqueo provocó un fallo total del sistema y el reinicio del controlador de dominio. Para comprender los requisitos mínimos de explotación, comprobamos si era necesario un ticket de servicio válido. No fueSe accede a la ruta de código vulnerable antes de evaluar el ServiceTicket. Y lo que es más importante, no requiere privilegios elevados: basta con acceso a la red y una cuenta de equipo vulnerable para provocar el fallo.
Esto constituye el núcleo de NOTLogon: una vulnerabilidad de denegación de servicio introducida por el nuevo escenario de inicio de sesión de ticket de red. Debido a la falta de validación en un controlador de búfer recientemente agregado, una sola llamada RPC malformada puede desestabilizar los controladores de dominio, lo que representa una grave amenaza de confiabilidad y disponibilidad en entornos empresariales.
Creando caos: implicaciones y mitigación
Las implicaciones de NOTLogon son directas y graves. Con solo una cuenta de equipo válida y un mensaje RPC diseñado, un atacante puede bloquear remotamente un controlador de dominio, un sistema responsable de las funcionalidades principales de... Active Directory, incluyendo autenticación, autorización, aplicación de directivas de grupo y emisión de tickets de servicio. La caída de todos los controladores de dominio paraliza el dominio, cortando el acceso a los recursos, interrumpiendo los inicios de sesión de los usuarios e interrumpiendo todos los componentes que dependen de la identidad centralizada.
No requiere privilegios elevados, solo acceso a la red y una cuenta de equipo débil. En entornos con credenciales mal administradas o segmentación insuficiente entre estaciones de trabajo y controladores de dominio, NOTLogon se convierte en un factor de bajo costo y alto impacto para la interrupción operativa.
Le recomendamos encarecidamente que instale la última versión Actualización del martes de parches de Microsoft publicada el 8 de julio de 2025, que incluye una corrección para CVE-2025-47978. Las organizaciones deben aplicar parches a todos los controladores de dominio sin demora, ya que el problema reside en el propio servicio Netlogon. Paralelamente, los administradores deben auditar y reforzar las cuentas de los equipos. Restringir el acceso a la red a los controladores de dominio, y limitar y supervisar el acceso a las cuentas de servicio, especialmente aquellas capaces de iniciar flujos RPC de Netlogon.
Cómo crear una postura de seguridad de identidad más segura en Active Directory
Se recomienda encarecidamente parchar esta vulnerabilidad; sin embargo, en paralelo, los equipos deben auditar y reforzar las cuentas de las máquinas, restringir el acceso a los controladores de dominio y limitar y supervisar el acceso a las cuentas de servicio, especialmente aquellas capaces de iniciar flujos RPC de Netlogon. Con Active Directory (AD) como columna vertebral de las redes de la mayoría de las organizaciones, es esencial garantizar su higiene de seguridad para reducir la amenaza de que los atacantes la utilicen para obtener acceso no autorizado a datos confidenciales. Silverfort puede ayudarte a limpiar Active Directory y reducir su deuda tecnológica de varias maneras, entre ellas:
- Descubriendo cuentas de administrador ocultas (también llamado administradores en la sombra) y configuraciones erróneas que podrían expandir silenciosamente su superficie de ataque.
- Identificar y eliminar prácticas riesgosas, como Uso de NTLMv1 y rancio cuentas de servicio que pasan desapercibidos en las herramientas nativas.
- Defendiendo contra ataques sigilosos basados en la identidaddel ADN, tales como los kerberasting y vulnerabilidades de Print Spooler, antes de que se intensifiquen.
NOTLogon nos recuerda que las nuevas funciones de protocolo, especialmente en servicios de autenticación privilegiada, pueden convertirse en superficies de ataque de la noche a la mañana. Mantenerse seguro no se trata solo de aplicar parches, sino de examinar los sistemas fundamentales de los que dependemos a diario.
Para obtener más información sobre cómo endurecer su Active Directory postura, descarga nuestra guía “5 maneras de mejorar la higiene de su AD."
