Netlogon DoS exposure shows the fragility of active directory trust

At a glance

What this is: Silverfort’s research identifies NOTLogon, a Netlogon-based DoS flaw that can crash domain controllers and disrupt Active Directory-wide authentication services.

Why it matters: It matters because identity teams must treat domain controller availability, machine-account governance, and protocol validation as core security controls, not just infrastructure concerns.

👉 Read Silverfort's analysis of the Netlogon DoS vulnerability in Active Directory

Context

NOTLogon is a denial-of-service weakness in a core Windows identity path, not a privilege-escalation exploit. The primary issue is that a specially crafted Netlogon authentication request can crash a domain controller when protocol validation and machine-account trust are too permissive, which puts Active Directory availability at risk.

For IAM teams, the lesson is broader than one protocol bug. Domain controllers, machine accounts, and authentication brokers sit on the critical path for human logins, service authentication, and policy enforcement, so a failure in one identity control plane can quickly become an enterprise outage.

The article also shows how weak defaults widen the blast radius. If low-privileged users can create machine accounts by default, the attack path becomes much easier to reach, which is why NHI governance and AD hardening need to be considered together rather than in separate silos.

Key questions

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. If Netlogon accepts malformed input, the result is not just a failed request. It can crash LSASS, reboot a domain controller, and interrupt logins, policy processing, and other identity-dependent services across the domain.

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. When they fail, the impact cascades into human access, service access, and directory operations. That is why identity teams must evaluate DC vulnerabilities as control-plane risk, not just host-level exposure.

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. The goal is to prevent low-privilege identities from reaching privileged authentication paths in the first place.

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.

Technical breakdown

Netlogon as an authentication broker

Netlogon is not just a machine-account channel. In Windows domains it brokers authentication between clients, LSASS, and domain controllers, including passthrough authentication and service logons. That makes it a privileged control point: if the protocol accepts malformed input or handles state incorrectly, the impact is not limited to one user session. It can affect the core path that validates identities across the domain, which is why protocol hardening and identity availability are tightly linked.

Practical implication: Treat Netlogon as part of the identity control plane and review it with the same rigor you apply to directory and authentication infrastructure.

Why a weak machine account becomes enough

The attack surface opens because the vulnerable path only requires a domain-joined machine account and network access. In many environments, default permissions allow ordinary users to create machine accounts, which means the bar for initiating a Netlogon request is much lower than most teams assume. This is an NHI governance issue as much as a protocol issue, because machine-account creation and scope determine who can reach the authentication path in the first place.

Practical implication: Restrict machine-account creation and monitor which identities can initiate privileged RPC flows toward domain controllers.

LSASS failure and domain-wide outage

The crash occurs inside LSASS, the Windows process that governs authentication and security policy enforcement. When LSASS fails, the domain controller reboots, and the effect is systemic rather than local: user logins, Group Policy application, and authentication-dependent services all degrade or stop. That means the security bug is also an availability bug, because identity service resilience depends on strict input validation and fault isolation at the protocol boundary.

Practical implication: Prioritise patching and resilience testing for any issue that can terminate LSASS or destabilise domain controller authentication processing.

Threat narrative

Attacker objective: The objective is to deny identity services to the organisation by taking domain controllers offline and breaking centralized authentication.

1. Entry occurs when an attacker with network access and a weak machine account sends a crafted Netlogon RPC request to a domain controller.
2. Escalation happens when the malformed AdditionalTicket buffer reaches the vulnerable decode path and triggers a NULL dereference inside LSASS.
3. Impact is a domain controller crash and reboot, which disrupts authentication, policy application, and Active Directory-dependent services across the domain.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

This flaw exposes a standing machine-account reachability problem, not a classic privilege escalation problem. The attacker did not need elevated rights, only access to a protocol boundary that many organisations leave broadly reachable. That is a governance failure in the NHI layer because machine identities were granted enough ambient access to become an availability weapon.

Identity controls that assume successful validation are fragile when the validation engine itself is the target. LSASS and Netlogon form a dependency chain where one malformed request can take down the system that authorises everyone else. Practitioners should read this as a warning that protocol hardening and account scoping are inseparable from identity resilience.

Low-privilege machine-account creation is a classic example of identity blast radius inflation. The issue is not just that one account can be abused, but that default configuration gives many users a path into a privileged authentication subsystem. That changes how teams should think about AD hardening, because the attack surface is defined by who can initiate identity traffic, not only by who can sign in.

OWASP NHI Top 10 thinking applies even in Windows domain infrastructure. Over-permissive identity reach, weak validation, and inadequate lifecycle control combine to create a condition where an NHI can destabilise core authentication. The practitioner takeaway is to review machine-account governance and protocol boundaries as a single control problem, not as separate projects.

From our research:

• 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.
• For teams hardening identity infrastructure, the next step is to align operational controls with Ultimate Guide to NHIs , Key Challenges and Risks before a low-privilege identity becomes a domain-wide outage trigger.

What this signals

Identity control-plane resilience is becoming a board-level availability issue, not a narrow directory concern. As more business services depend on Active Directory and related authentication brokers, the failure of one protocol can halt access across multiple programmes. Security teams should expect domain-controller resilience, segmentation, and fault isolation to sit closer to IAM roadmaps than many current operating models assume.

Low-privilege reach into privileged identity services is the next governance gap to close. The article shows how a default machine-account path can create an unnecessary attack entry point, and that pattern will keep reappearing wherever identity infrastructure trusts broad internal reach. Teams should look for similar exposure in service accounts, directory tooling, and administrative RPC surfaces.

With only 1.5 out of 10 organisations highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security, the practical signal is clear: machine identities are still being governed as operational conveniences rather than as security-critical actors.

For practitioners

• 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.
• Audit LSASS-triggering failures Treat any protocol path that can destabilise LSASS as a high-priority resilience issue and test whether monitoring, alerting, and failover procedures detect the crash fast enough to contain outage impact.

Key takeaways

• NOTLogon shows that an identity protocol bug can become a domain-wide availability incident when a low-privilege machine account reaches a privileged authentication path.
• The scale of impact is larger than the exploit itself because domain controller failure disrupts logins, policy application, and authentication-dependent services across Active Directory.
• Restricting machine-account creation, narrowing Netlogon reachability, and patching every domain controller are the controls most likely to reduce both exposure and outage risk.

Key terms

• Netlogon: Netlogon is a privileged Windows authentication and channel-establishment protocol used by domain-joined systems and domain controllers. It brokers machine and user authentication, which means errors in its input handling can affect the core identity control plane rather than a single application or user session.
• Machine Account: A machine account is a non-human identity representing a computer or server in an Active Directory domain. It is used for secure channel setup and authentication tasks, so weak creation policies or excessive reach can turn it into an entry point for broader identity abuse.
• LSASS: LSASS is the Windows process that enforces local security policy and handles authentication-related operations. If LSASS crashes, the domain controller can reboot or lose authentication capability, making it one of the most sensitive failure points in enterprise identity infrastructure.
• Identity Control Plane: The identity control plane is the set of services that authenticate, authorise, and enforce policy for users, services, and machines. When it fails, the impact is systemic because access decisions, logon flows, and directory operations all depend on that shared trust layer.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Silverfort: the Netlogon denial-of-service vulnerability in Microsoft Active Directory. Read the original.