Windows Netlogon RCE Turns Patch Lag Into Domain Risk

Windows Netlogon remote code execution (RCE, the ability to run code on another system) is now an active exploitation risk for unpatched Windows Server domain controllers after the Centre for Cybersecurity Belgium (CCB), Belgium’s national cybersecurity authority, updated the Netlogon exploitation advisory on May 29. The flaw lets an unauthenticated attacker send a crafted network request to a Windows Server acting as a domain controller (DC, the server that authenticates domain users and machines) and potentially run code with SYSTEM privileges.

For Windows admins, the painful point is timing: Microsoft shipped the fix on May 12, before the warning changed. A normal maintenance delay now has to be treated like a possible Active Directory (AD, Microsoft’s directory and authentication system) incident.

A May Patch Turns Urgent After the CCB Update

The May Patch Tuesday release did not start as a confirmed zero-day wave. The CCB advisory, first published on May 13 and updated on May 29, said Microsoft patched 118 vulnerabilities requiring action, including 16 critical and 102 important issues. That same update moved the Netlogon item out of the ordinary patch queue.

It is now actively exploited in the wild.

The Centre for Cybersecurity Belgium wrote that sentence in its section on CVE-2026-41089, after describing the attack path as a specially crafted network request sent to a Windows server that is acting as a domain controller. The advisory also says exploitation does not require prior privileges or user interaction, which removes the phishing click, stolen password, or local foothold that often slows an attack chain.

Defenders should sort the bundle by blast radius rather than by bundle size. This entry now combines observed exploitation, remote reach, and a service that sits at the identity root of many Windows estates.

Netlogon Makes This a Domain Problem

The U.S. National Vulnerability Database describes the issue as a stack-based buffer overflow in Windows Netlogon and gives Microsoft’s Common Vulnerability Scoring System (CVSS, a 0 to 10 severity scale) rating as 9.8 critical in the NVD entry for the Netlogon flaw. The vector is the part admins should read closely: network attack vector, low attack complexity, no privileges required, and no user interaction required.

Microsoft’s own protocol documentation explains why that score matters. The Microsoft Netlogon protocol overview says Netlogon Remote Protocol is used for secure communication between domain-joined machines and DCs. It also supports the machinery that discovers and maintains domain relationships.

That role changes the operational math. A web server compromise can be contained around an application boundary; code execution on a writable DC can put credential material, Group Policy paths, trust relationships, and administrative group membership within reach. Attackers still need a working exploit and network access, but the prize is the control plane, not one workload.

Risk Rises With Every Route to a Domain Controller

The most exposed controller is not always the oldest one. It is the one reachable from the most places: VPN pools, branch subnets, server VLANs, contractor networks, test labs, jump boxes, and legacy monitoring tools that were allowed broad access years ago and never reviewed.

That is why port filtering needs care. Microsoft’s AD firewall guidance lists Remote Procedure Call (RPC, the Windows method services use to call each other over a network) endpoint mapper on TCP 135, RPC for LSA, SAM, and NetLogon, SMB on TCP 445, LDAP, Kerberos, DNS, and dynamic RPC ranges. Blocking one port at the edge while leaving broad internal routes untouched can give a false sense of safety.

The queue is already crowded for Microsoft administrators. Many of the same teams are also triaging a separate Defender patch deadline, endpoint updates, identity outages, and monthly server reboots. Domain controller exposure should still rise to the front when a routed path from untrusted or loosely trusted networks exists.

Network teams can help before the maintenance window closes. Map which subnets can initiate RPC and SMB sessions to each controller, then remove access that has no current business owner. For a bug like this, reachability is the multiplier.

The Remediation Queue Needs a Forest View

Microsoft and NVD data put affected Windows Server families from 2012 through 2025 in the risk zone when configured as DCs. The practical problem is rarely one clean server list. Most environments have writable controllers in data centers, read-only domain controllers (RODCs, branch controllers with limited credential storage), Server Core installs, lab systems, and old machines kept alive for one application nobody wants to touch.

A forest-wide view matters because half-finished remediation leaves confusing evidence. If some controllers are fixed and others are still vulnerable, failed logons, replication warnings, and service restarts become harder to interpret during an investigation.

Detection Starts With Crashes, Traffic, and New Privilege

Patching closes the known hole, but it does not answer whether someone reached a controller before the reboot. The CCB’s recommendation to increase monitoring is the right baseline, especially because a fixed server can still carry last week’s evidence.

Microsoft’s Netlogon debug logging guide says the logging can help monitor or troubleshoot authentication, DC locator, account lockout, and other domain communication issues. For this incident, those logs are only one layer. They should sit beside network flow data, security event logs, endpoint detections, and change records.

• Look for unexpected Netlogon service crashes or restarts on controllers that were reachable before patching.
• Review unusual RPC or SMB traffic to DCs from workstation, VPN, guest, or contractor segments.
• Check for new administrator accounts, group membership changes, or policy edits after suspicious traffic windows.
• Compare authentication failures, trust errors, and replication problems against the patch timeline.
• Preserve logs before aggressive cleanup, because a rebooted and patched controller may be the only system with the useful trace.

None of those signals proves exploitation by itself. Together, they give responders a way to decide whether this was a patch job or the start of credential reset, tier-zero rebuild, and incident notification work.

The Hardest Part Is Proving Every Controller Moved

On June 2, the right artifact for this story is patch proof. A screenshot from one server is not enough. The change record should show every controller name, operating system family, installed update, reboot time, replication state, Netlogon service status, and the owner of any exception.

Exceptions deserve expiration dates. If a business unit asks to hold a controller back, the answer should include a temporary route restriction, named approver, compensating monitoring, and a date when the machine either patches or leaves service. Open-ended exceptions are how a May fix becomes a summer incident.

One more check belongs in the runbook: identity recovery. If a controller showed suspicious traffic before patching, teams should be ready to protect backups, validate privileged accounts, rotate exposed secrets, and make sure logging still reaches a place attackers cannot edit from the same domain.

If every controller is patched and the review finds no evidence of contact, this becomes a painful but closed change ticket. If one routed DC remains exposed, the attacker does not need the whole forest to be open, just the one server the rest of the domain still trusts.