One Week After CVE-2026-41089: Taking Stock of the Netlogon Response Across Enterprise Environments

One week has passed since Belgium’s Centre for Cybersecurity confirmed active exploitation of CVE-2026-41089 — the Netlogon CVSS 9.8 stack overflow that allows unauthenticated remote code execution on domain controllers. For most organisations, this means the emergency response phase is complete and it is time to take stock of what the response revealed.

The Patching Picture

CISA’s Shodan-adjacent scanning data and reports from threat intelligence vendors paint a consistent picture of the response: organisations with mature patch management programmes patched domain controllers within 24–72 hours of the exploitation confirmation. Organisations with fragmented patch management, large legacy DC populations, or weak asset inventory are still completing remediation as of 31 May.

The specific challenges encountered during the Netlogon patch response this week:

Read-Only Domain Controllers (RODCs): Multiple organisations discovered during the response that their RODC inventory was incomplete. Branch office RODCs deployed and largely forgotten are a persistent gap in DC inventories. The patch is the same for RODCs as for full DCs, but finding all RODCs first required unexpected discovery work.

Domain-joined cloud workloads: Organisations with Azure AD DS deployments or DC VMs in cloud environments needed to patch through their cloud provider’s update mechanisms rather than standard on-premises tools. Some found that their WSUS/SCCM coverage did not include cloud-hosted DCs.

Windows Server 2012 R2: Organisations still running 2012 R2 DCs — which requires Extended Security Update coverage for continued patch support — discovered that ESU patch distribution was not configured in their patch management tools, requiring a separate manual update process.

Patch verification: Several organisations patched DCs but could not verify patch success because they lacked a systematic way to query running kernel build number or installed KB number across all DCs simultaneously. Discovery work that should have been done months ago was compressed into the 48-hour response window.

What the Post-Patch Investigation Found

For the population of organisations that completed post-patch forensic investigations, the findings split roughly into three categories:

No exploitation indicators found: Most organisations with DCs not accessible from untrusted networks found no indicators of exploitation. The network segmentation held.

Exploitation attempts with no success: Organisations with DCs on more permissive network segments found evidence of exploitation attempts — Netlogon RPC calls with oversized parameters from external source IPs — but the attempts failed, likely because the attacker’s PoC was not reliable against all Windows Server versions or required tuning the payload for the specific target.

Confirmed compromise requiring remediation: A smaller population — concentrated in organisations with internet-accessible DCs or DCs reachable from guest networks — found confirmed indicators of exploitation and conducted full AD recovery procedures. The krbtgt double-rotation and Domain Admin account audit was completed.

The Structural Finding

The most consistent structural finding from this week’s response is the same one that Zerologon produced in 2020: organisations that had not implemented DC network isolation did not know they had not implemented it until they needed to verify exposure scope. The architecture review that should follow every major DC-targeting vulnerability was again prompted by the exploitation event rather than proactive programme work.

The operational debt created by deferred DC isolation work is paid in emergency response cycles. Organisations that complete the AD Tier Model implementation and DC subnet isolation in the weeks following CVE-2026-41089 will be in a structurally different position for the next Netlogon-class vulnerability.

Immediate Remaining Actions

For organisations still working through the response:

1. Confirm patch status on all DCs: Query all DCs for installed KB number and confirm they show the expected security update. Use Get-ADDomainController -Filter * | ForEach-Object { Invoke-Command -ComputerName $_.HostName -ScriptBlock { Get-HotFix | Where-Object {$_.HotFixID -eq "KB<number>"} } } adapted to your environment.

2. Complete post-patch investigation: Any DC that was accessible from an untrusted network during the exposure window (prior to patching) warrants a forensic review — not optional, even if no obvious indicators have surfaced.

3. Document the DC network architecture gaps found during this response: These gaps are the investment case for the next DC network segmentation project. Capture them while the incident is fresh.