Executive summary
The Silverfort security research team identified a denial-of-service (DoS) vulnerability in Microsoft’s Netlogon protocol, a core component all Windows domain controllers use. The issue, which we refer to as NOTLogon and Microsoft has named the Windows Kerberos Denial of Service vulnerability, allows any domain-joined machine with minimal privileges to send a specially-crafted authentication request that will crash a domain controller and cause a full reboot.
This vulnerability does not require elevated privileges—only standard network access and a weak machine account are needed. In typical enterprise environments, any low-privileged user can create such accounts by default.
The crash impacts LSASS, the core security process in Windows, and leads to widespread disruption in Active Directory services, including user logins, policy application, and authentication-dependent resources. Microsoft has given it a CVE rating of 6.5 and issued a fix for CVE-2025-47978 as part of the July 8th, 2025 Patch Tuesday. We strongly recommend immediate deployment of this update across all domain controllers, along with tightening access controls for service and machine accounts.
Vulnerability discovery through AI
One of the first and most difficult questions a security researcher must consider is where they are most likely to find a vulnerability. Researchers sift through vast amounts of data, code, and documentation, then choose the right places to look deeper. To speed up the process, and test the boundaries of AI, we used LLMs to identify potential flaws by comparing old release notes to new. This approach recently led to the discovery of this zero-day Active Directory Denial of Service vulnerability.
How the DoS vulnerability works
The Netlogon Remote Protocol (MS-NRPC) is a fundamental part of Windows domain-based networking, used to authenticate users and machines and maintain secure channels between domain members and Domain Controllers (DCs). Given its privileged position and constant network presence, even non-privilege escalation vulnerabilities in Netlogon can be catastrophic.
When we think of authentication vulnerabilities, we often imagine attackers escalating privileges, stealing credentials, or executing remote code. But some of the most disruptive threats can be purely destructive—cutting off access, halting services, and disrupting domain-wide operations. In this post, we uncover NOTLogon, a Denial-of-Service (DoS) vulnerability in the Netlogon protocol that can destabilize or disable core Active Directory operations by exploiting flaws in session negotiation and state handling.
NETLOGON 101
To appreciate the implications of NOTLogon, we must understand the Netlogon protocol, a fundamental part of Microsoft’s domain-based security architecture. The Netlogon Remote Protocol (MS-NRPC) is a privileged authentication and channel-establishment protocol used by domain-joined computers and Domain Controllers (DCs). Introduced in Windows NT and still actively used today, Netlogon enables remote domain functionalities such as machine account authentication, acting as an authentication broker, facilitating password rotation, and supporting numerous other sensitive operations critical to Active Directory infrastructure.
One of the most critical yet often overlooked roles of the Netlogon protocol is its function as an authentication broker within Windows domain environments. While commonly associated with secure channel establishment for machine accounts, Netlogon also acts as an intermediary between the Local Security Authority Subsystem Service (LSASS) and domain controllers for processing user authentication requests. When a user logs in over the network to a remote application, LSASS delegates the authentication to Netlogon if the credentials must be validated against Active Directory. Netlogon then encapsulates the request into a protocol-specific message called NetrLogonSamLogon and forwards it to the appropriate domain controller, handling the negotiation and response transparently. This is known as passthrough authentication.
What kind of authentication scenarios does Netlogon support?
Netlogon supports a wide range of authentication scenarios through its NETLOGON_LEVEL union, officially known as NETLOGON_LOGON_INFO_CLASS, which defines how user and service credentials are packaged and forwarded. According to the MS-NRPC specification, the supported levels include:
NetlogonInteractiveInformation: For interactive logons, where users enter credentials at the workstation (e.g., via Ctrl+Alt+Del). This level enables challenge/response verification (typically NTLM or Kerberos) sent to the DC.
NetlogonNetworkInformation: For network logons, such as accessing SMB or RPC resources after an interactive logon. Credentials (like NTLM tokens) are transparently re-sent without prompting the user.
NetlogonServiceInformation: For service account logons, used when Windows services authenticate with domain credentials to access resources.
Transitive Levels (Interactive, Network, Service): Variants of the above enabling cross-domain or trust-bound authentication, where credentials propagate across domains with trust relationships—e.g., NetlogonInteractiveTransitiveInformation, NetlogonNetworkTransitiveInformation, and NetlogonServiceTransitiveInformation.
NetlogonGenericInformation: For generic pass-through authentication, including NTLM, Digest, and Kerberos PAC validation, where a server accepts user credentials and relays them to a DC for validation.
How is Netlogon evolving?
With NTLM officially deprecated, Microsoft unveiled the Network Ticket Logon specification on July 29th, 2024, and finalized it in an MS-NRPC update released November 19th, 2024. This enhancement allows services to present pre-issued Kerberos tickets to a domain controller using the NetrLogonSamLogonEx RPC—eliminating the need for the original client to directly contact the DC.
This scenario supports future capabilities like LocalKDC, where ticket validation can occur offline or through intermediaries. Since it introduces new logic for ticket parsing, PAC verification, and delegated trust handling within a privileged RPC path, we began analyzing the Network Ticket Logon mechanism to assess its security boundaries and potential for misuse.
Our journey into the new Network Ticket Logon scenario began with its delivery mechanism: the NetrLogonSamLogonEx RPC call. Microsoft originally introduced this call to generalize logon flows, but as of July 2024, it now supports an entirely new authentication path by accepting the NETLOGON_TICKET_LOGON_INFO structure. This is the heart of the Network Ticket Logon scenario—enabling services to submit Kerberos tickets to a domain controller for validation, without requiring the original client to directly interact with the DC.
We turned our attention to the specification for NETLOGON_TICKET_LOGON_INFO, and immediately encountered complexity and ambiguity. Two fields in particular drew our focus: ServiceTicket and AdditionalTicket, both declared as PUCHAR buffers (a pointer type used in Windows API programming to represent a raw byte array—essentially an address pointing to an unsigned char buffer of arbitrary length). The role of ServiceTicket was clearly defined as “a pointer to an unsigned character array containing the service ticket.” Simple enough.
But AdditionalTicket was far more ambiguous. The spec notes: “If the service ticket is a User2User ticket, then the ticket-granting ticket (TGT) used as the source of the session key must also be provided.” That raised more questions than it answered. Is this field optional unless the ticket represents a U2U scenario? Is the expected content always a TGT? Could other ticket types be valid? To complicate matters, the accompanying AdditionalTicketLength field is described as “the length of the Kerberos service ticket that is the source of authorization”—a conflicting statement if the buffer is meant to contain a TGT.
With limited clarity from the documentation, we shifted to experimentation. We constructed the structure manually and began sending controlled requests to a fully patched domain controller. When dealing with privileged RPCs like Netlogon, implementation often speaks louder than spec.
The minimal requirement to perform a NetrLogonSamLogonEx is a machine account registered in the domain, which represents a computer or server. Notably, by default, each user may create up to 10 machine accounts in an Active Directory domain. This means a weak user is enough to bind to the Netlogon interface and perform a Network Ticket Logon to a domain controller.
The crash: Where Network ticket logon breaks
Once we had a working NETLOGON_TICKET_LOGON_INFO structure, we sent a standard Network Ticket Logon request to the domain controller using NetrLogonSamLogonEx. The request included a valid service ticket, as expected. While the Netlogon call returned STATUS_SUCCESS, the embedded KerberosError field inside the response contained STATUS_INSUFFICIENT_RESOURCES—an unusual and suspicious result for a seemingly valid request.
To investigate further, we began fuzzing the structure. Omitting the ServiceTicket entirely returned the expected STATUS_INVALID_PARAMETER. However, when we targeted the AdditionalTicket field and sent it as an empty buffer, we observed a crash on the domain controller.
The crash dump pointed to a function named KdcUnpackAdditionalTgt, responsible for decoding the AdditionalTicket buffer into a Kerberos KERB_TICKET ASN.1 structure. Critically, the function failed to validate that the input buffer was non-empty and well-formed before attempting the decode. This led to a NULL dereference inside LSASS, the Windows process that governs authentication and security policy enforcement.
Since LSASS is a protected process, its crash resulted in a full system failure and triggered a reboot of the domain controller. To understand the minimal requirements for exploitation, we tested whether a valid service ticket was necessary. It wasn’t—the vulnerable code path is reached before the ServiceTicket is evaluated. More importantly, it doesn’t require high privileges—just network access and a weak machine account is sufficient to trigger the crash.
This forms the core of NOTLogon: a denial-of-service vulnerability introduced by the new Network Ticket Logon scenario. Due to a lack of validation in a newly added buffer handler, a single malformed RPC call can destabilize domain controllers—posing a serious reliability and availability threat in enterprise environments.
Creating chaos: Implications and mitigation
The implications of NOTLogon are straightforward and severe. With only a valid machine account and a crafted RPC message, an attacker can remotely crash a domain controller—a system responsible for the core functionalities of Active Directory, including authentication, authorization, Group Policy enforcement, and service ticket issuance. Crashing all domain controllers effectively paralyzes the domain, cutting off access to resources, interrupting user logins, and disrupting every component that depends on centralized identity.
It doesn’t require high privileges—just network access and a weak machine account. In environments with poorly managed credentials or insufficient segmentation between workstations and domain controllers, NOTLogon becomes a low-cost, high-impact vector for operational disruption.
We strongly suggest installing the latest Microsoft Patch Tuesday update released on July 8th, 2025, which includes a fix for CVE-2025-47978. Organizations should patch all domain controllers without delay, as the issue resides in the Netlogon service itself. In parallel, administrators should audit and harden machine accounts, restrict network access to domain controllers, and limit and monitor service account access, especially those capable of initiating Netlogon RPC flows.
How to create a more secure identity security posture in Active Directory
Patching this vulnerability is highly recommended; however, in parallel, teams should audit and harden machine accounts, restrict access to domain controllers, and limit and monitor service account access, especially those capable of initiating Netlogon RPC flows. With Active Directory (AD) as the backbone of most organizations’ networks, ensuring its security hygiene to reduce the threat of attackers using it to gain unauthorized access to sensitive data is essential. Silverfort can help you clean up Active Directory and reduce your tech debt in various ways, including:
- Uncovering hidden admin accounts (aka shadow admins) and misconfigurations that could silently expand your attack surface.
- Identifying and eliminating risky practices, such as NTLMv1 usage and stale service accounts that go undetected in native tools.
- Defending against stealthy identity-based attacks, like Kerberoasting and Print Spooler exploits, before they escalate.
NOTLogon is a reminder that new protocol features—especially in privileged authentication services—can become attack surfaces overnight. Staying secure isn’t only about applying patches—it’s about examining the foundational systems we rely on every day.
To learn more about how to harden your Active Directory posture, download our guide “5 Ways to Step Up Your AD Hygiene.”