TL;DR: A denial-of-service flaw in Microsoft’s Netlogon protocol lets a low-privileged, domain-joined machine crash a domain controller through a malformed authentication request, disrupting logins, policy application, and other AD-dependent services, according to Silverfort. The issue shows that availability failures in core identity services can become enterprise-wide outages when machine-account trust and protocol validation are weak.
NHIMG editorial — based on content published by Silverfort: the Netlogon denial-of-service vulnerability in Microsoft Active Directory
Questions worth separating out
Q: What breaks when a low-privileged machine account can reach Netlogon?
A: A low-privileged machine account can become a path into a privileged authentication service.
Q: Why do domain controller vulnerabilities create broader identity risk than server bugs?
A: Domain controllers sit on the critical path for authentication, authorisation, and policy enforcement.
Q: How do security teams reduce the blast radius of machine-account abuse?
A: They narrow who can create or use machine accounts, segment traffic to domain controllers, and monitor RPC activity that should never originate from ordinary endpoints.
Practitioner guidance
- Patch all domain controllers immediately Deploy the July 8, 2025 update that addresses CVE-2025-47978 across every domain controller, then verify that the fix is present in all sites and recovery clusters.
- Restrict machine-account creation Reduce or remove default permissions that let ordinary users create machine accounts, and review every delegated path that can bind a low-privilege identity to Netlogon.
- Limit Netlogon reachability Segment domain controllers so only required systems can initiate Netlogon RPC flows, and log any unexpected source that attempts authentication broker traffic.
What's in the full article
Silverfort's full analysis covers the protocol-level detail this post intentionally leaves for the source:
- The exact Netlogon request structure used to trigger the failure path in LSASS.
- The MS-NRPC fields and buffer-handling ambiguity that made the crash reachable.
- The patch reference for CVE-2025-47978 and the deployment context for domain controllers.
- The author’s broader research workflow, including how LLMs were used to surface the flaw.
👉 Read Silverfort's analysis of the Netlogon DoS vulnerability in Active Directory →
Netlogon DoS in active directory: are your controls ready?
Explore further
Netlogon trust was designed for authenticated domain operations, not for arbitrary malformed input from low-privileged machine accounts. That assumption fails when a weak account can reach a privileged RPC path and trigger a crash before higher-level identity controls even engage. The implication is that availability protections for domain controllers must be treated as part of identity governance, not as an adjacent infrastructure task.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- The same research found that 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months.
A question worth separating out:
Q: Who is accountable when an identity protocol flaw takes down authentication services?
A: Accountability sits with the teams that own directory services, machine-account governance, and platform patching together. In practice, this means IAM, endpoint, and infrastructure owners must share responsibility for identity control-plane resilience under frameworks such as the NIST Cybersecurity Framework.
👉 Read our full editorial: Netlogon DoS exposure shows the fragility of active directory trust