One UDP-package on port 389 - and you are SYSTEM on the domain controller. No login, no password, no click from the user. On May 12, 2026, Microsoft as part of the Patch Tuesday closed the stack buffer overflow in Windows Netlogon - CVE-2026-41089 with CVSS 9.8 (Critical). After 17 days, the Belgian CERT (CCB) confirmed the active operation in the wild, although Microsoft announced the lack of evidence. EPSS at the beginning of July - 0.7225, Top 1% among all CVE probability of operation for 30 days.
The vulnerability does not require either authentication or user actions: a specially formed network request to the domain controller - and the attacker receives remote execution of the code with the privileges of SYSTEM. For a pentester working with AD-infrastructures, this critical vulnerability of Active Directory is a direct path from one UDP-package to a complete domain capture. In terms of destructive potential, it is superior to ZeroLogon, and below I will explain why.
Business logic of attack: why an attacker 0-click RCE on the domain controller
Domain controller is not an ordinary Windows Server with file balls. This is the identity control plane Active Directory: the repository of all accounts, the Kerberos Authentication Center, the source of group policies, the node of trusting relationships between forest domains. Microsoft Documentation on the Nelogon Remote Protocol describes MS-NRPC as an interface to maintain the relationship between domain machines and controllers, transport authentication requests and transfer password changes.
Attacking from RCE on DC is in a position where two or three steps remain until the infrastructure is completely compromised: the dump of all hashes through the DCSync, the creation of Golden Ticket with hash krbtgt. deployed ransomware through Group Policy. No need for a chain of five vulnerabilities, you do not need a phishing - one UDP-package and a direct hit in the core of the infrastructure.
Technical Anatomy CVE-2026-41089: Stack overflow in Windows Netlogon
CVSS vector and MS-NRPC Vulnerability
According to the MSRC entry (date of publication on May 12, 2026), the vulnerability is described as: "Stack-based bufferflow in Windows Netlogon allows an unauthorized attacker to execute code over a network""Buffer overflow in Windows Netlogon slipper allows an unauthorized attacker to execute code over the network". CVSS-vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - we will analyze each component, because it determines the operational context:
• AV:N - operation over the network, physical access is not needed
• AC:L - low complexity, special conditions in the target configuration is not required
• PR:N - no privileges, attack before authentication
• UI:N - user actions are not required, full 0-click
• C:H / I:H / A:H - complete loss of privacy, integrity and accessibility
Vulnerability is classified as CWE-121 (Stack-based Buffer Overflow) - option CWE-787 (Out-of-bounds Write) and CWE-788 (Access of Memory Location). According to the MITRE description, CWE-121 Characteristic of languages without automatic control of memory boundaries (C, C++) and can lead to memory modifications, bypassing protection mechanisms or performing arbitrary code. CISA-APD ranks Technical Impact as "total", and Automatable - "yes", which means the possibility of mass automated operation. Simply put, it is wormable.
Mechanics of overcrowding in the CLDAP handler
[Applicable to: internal pentest, all versions of Windows Server to patch from May 12, 2026]
CLDAP (Connectionless LDAP, UDP 389) is one of the mechanisms through which clients detect domain controllers on the network. The Netlogon Service processes incoming CLDAP requests and generates answers with domain information.
Tool-checker ADScanPro/CVE-2026-41089-LongLogon (13 stars) is positioned as "unauthenticated, non-destructive precondition checker" and checks whether the long domain name of the controller is enough to call crash. The detail is not obvious, but important: the length of the DC domain name is a precondition for the overflow trigger.
According to third-party analyzes, patch, the patch replaces the vulnerable function of writing lines in netlogon.dll: old implementation copied the symbols into a fixed stack buffer without size control (hello, strcpy from the 90's), and the new takes the size of the buffer as a parameter and stops the record when the limit is reached, returning the error instead of overflowing to the adjacent stack area.
Operation scenario for attacker: send a specially formed CLDAP request to UDP 389 domain controller -> provoke overflow of the stack buffer when processing the line -> re-register the return address -> get control over the execution stream in the context of the process lsass.exe (which is hosted by Netlogon) with the privileges of SYSTEM.
Touched versions of Windows Server
Patch released for Windows Server 2012, 2012 R2, 2016, 2019, 2022, 2022 23H2 and 2025 - including Server Core. According to the NVD, Windows Server 2012, 2012 R2, 2016, 2019 and 2022 are affected; accurate minimum patches should be checked with the relevant KB items on support.microsoft.com. Suitable KB: KB5087471, KB5087470, KB5087537.
In short, everything Microsoft still supports is vulnerable. And what no longer supports, but continues to work in the production (and there are enough DCs).
Operation Netlogon RCE: a place in kill chain Active Directory
The Realistic Path of Attack
The internal pentest scenario in grey box mode has access to the corporate network (via VPN or physical connection), but without domain account data:
Stage 1 - Discovery. Find Domain Controllers via DNS Request _ldap._tcp.dc._msdcs.<domain> or broadcast CLDAP on UDP 389. The OS version is defined from LDAP rootdES-responses. To check the preconditions, the launch of the LongLogon checker, which determines whether the length of the domain name is suitable for operation without sending an exploit package.
Stage 2 - Exploitation of Remote Services (T1210, Lateral Movement) Sending a crafted CLDAP request for UDP 389 unpatept DC. Successful is the execution of arbitrary code.
Stage 3 - Exploitation for Privilege Escalation (T1068, Privilege Escalation) The code is executed in context lsass.exe - SYSTEM on the domain controller. Further increases in privileges are not required. We're already at the top.
Stage 4 - DCSync (T1003.006, Credential Access). With the privileges of SYSTEM on DC, perform the DCSync via secretsdump.py (Impacket) or mimikatz lsadump::dcsync /all - obtain NTLM hashes of all domain accounts, including krbtgt.
Stage 5 - Persistence and Lateral Movement. Hash krbtgt - Golden Ticket for the entire domain. Administrators' Heaches Pass the HashT1550.002) via SMB/Windows Admin Shares (T1021.002) Registration rogue domain controller (T1207) for long-term presence. Reconnaissance of trust (T1482) - going beyond the current domain to other forest domains. Creating backdoor accounts in Domain Admins (T1078.002)
From UDP-package to Golden Ticket - four steps. On a real project, it's minutes, not hours.
Predictions and limitations in modern environments
Works if: DC is not patchy (no KB508771/KB508770/KB5087757), UDP 389 is available from the attacker's position, the domain name is sufficient length for the overflow trigger (verified by the LongLogon checker).
Does not work if:
Patch is installed - after updating the line record function checks the boundaries of the buffer, and overflow is impossible.
Network Segmentation DC is in the isolated management VLAN, UDP 389 is blocked from work subnets. In practice, stateful firewall (Palo Alto, Fortinet) filters UDP 389 from non-mustard zones. But I’ve seen enough “flat” nets not to rely on it.
External pentest - DC should not be available from the Internet. But CLDAP exposure is a real problem: Shodan captures thousands of open UDP 389 on Windows Server.
Stack Mimmation - ASLR, DEP and stack cookies on Windows Server 2019+ complicate the operation (requires bypassing ASLR to control RIP), but does not eliminate the vulnerability. Patch is mandatory.
EDR on DC CrowdStrike Falcon and Microsoft Defender for Endpoint Detectal Behavior lsass.exe after operation (child processes, memory access patterns). SentinelOne fixes injection in lsass.exe. Elastic 8.x+ with Endpoint Security module logs networks connections from lsass.exe (Sysmon EID 3) But none of the listed products block the CLDAP-package itself until overflow - they catch the consequences, not the cause.
Vulnerability Verification and Patt Check on Domain Controllers
Adjustments to the environment
• OS: Windows Server with AD DS role (any supported version)
• Rights: Domain Admin or local administrator on each DC
• RAM: DC standard requirements (minimum 4 GB, recommended 8+ GB for Server 2019/2022)
• Tools: PowerShell 5.1+, ActiveDirectory module, optional - ADScanPro/CVE-2026-41089-LongLogon
The first step is to inventory all DCs in the forest and checking the status of KB-update:
Code:
Get-ADDomainController -Filter * | ForEach-Object {
$kb = Invoke-Command -ComputerName $_.HostName -ScriptBlock {
Get-HotFix | Where-Object {$_.HotFixID -match 'KB508747[01]|KB5087537'}
}
[PSCustomObject]@{
DC=$_.HostName; Site=$_.Site; OS=$_.OperatingSystem
Patched=[bool]$kb; KB=$kb.HotFixID -join ','
}
} | Format-Table -AutoSize
In the absence of KB - additional check of the hash of the binary file: Get-FileHash C:\Windows\System32\netlogon.dll -Algorithm SHA256. Any DC with a non-coincient hash is considered vulnerable until the opposite is confirmed.
And here is the moment that is ignored on projects most often: you need to patch all DC in one maintenance window. Half-patched AD forest is not defensable state. One unpatept DC in the forest of ten - and that's enough. The attacker will simply direct the exploit to this particular node.
Determination of operation CVE-2026-41089: IOC and SIEM-rule
Compromise Indicators
Network level: anomalous CLDAP traffic (UDP 389) from sources that are not domain machines. A characteristic feature is the non-standard size of packages directed to DC from hosts outside the desktop list. According to CCB and SecPod, the IOC infrastructure (IP addresses C2, domains, campaign files hashes) at the time of June 2026 are not publicly disclosed - the available indicators are of a behavioral nature.
Host level: Key IOC - crash lsass.exe with faulting module netlogon.DLL and Exclus Code 0xc0000409 (STATUS_STACK_BUFFER_OVERRUN). In Windows Event Log - Event ID 1000 (Application Error). Any such event on an unpatept DC is the basis for launching the incident-response procedure. Not "the probable cause of the reboot", not "probably, the memory is over" - and IR. Immediately.
Post-operational IOC: Subsidiary processes from lsass.exe (Sysmon EID 1 with ParentImage lsass.exe). Outgoing networking compounds from lsass.exe to non-standard addresses (Sysmon EID 3), adding accounts to the preferred groups - Event ID 4728, 4732, 4756 - in non-working hours.
SIEM-rule by vendor
Microsoft Sentinel (KQL):
Code:
Event
| where EventID == 1000 and Source == "Application Error"
| where RenderedDescription contains "lsass.exe"
and RenderedDescription contains "netlogon"
and RenderedDescription contains "c0000409"
| project TimeGenerated, Computer, RenderedDescription
| extend Alert = "CVE-2026-41089 crash candidate"
Splunk: source="WinEventLog:Application" EventCode=1000 "lsass.exe" "netlogon.DLL" "0xc0000409" - followed by the correlation on Computer name to detect serial crashes.
Elastic (KQL): event.code:1000 AND process.name:lsass.exe AND winlog.event_data.ModuleName:netlogon AND winlog.event_data.ExceptionCode
"0xc0000409" OR "c0000409").
Limitation of these rules should be understood: they fix crash - DoS state or an unsuccessful attempt to operate. Successful RCE without crash may not leave these artifacts. To cover this scenario - monitoring of child processes from lsass.exe through Sysmon EID 1 and network connections via Sysmon EID 3.
For Netlogon debug logging on unpatept DCs until the update is set: nltest /dbflag:0x2080ffff - Logs are recorded in %windir%\debug\netlogon.log. After the patch disable: nltest /dbflag:0x0, to avoid overhead from the volume of logging.
CVE-2026-41089 vs ZeroLogon: a comparison of critical vulnerabilities Netlogon Remote Protocol
Key difference to practice: ZeroLogon when operating broke AD - after the DC machine account password, the replication ceased to work, and it was impossible to hide it. On real projects, it was necessary to coordinate with the customer the recovery, write explanatory, wait until the backup will be raised. CVE-2026-41089 with pure operation gives the shall without destructive side effects - the attacker can act secretly. This makes Windows Server RCE CVE more dangerous in the hands of APT groups: ZeroLogon made noise like an elephant in a china shop, and here it is silence.
The vulnerability does not require either authentication or user actions: a specially formed network request to the domain controller - and the attacker receives remote execution of the code with the privileges of SYSTEM. For a pentester working with AD-infrastructures, this critical vulnerability of Active Directory is a direct path from one UDP-package to a complete domain capture. In terms of destructive potential, it is superior to ZeroLogon, and below I will explain why.
Business logic of attack: why an attacker 0-click RCE on the domain controller
Domain controller is not an ordinary Windows Server with file balls. This is the identity control plane Active Directory: the repository of all accounts, the Kerberos Authentication Center, the source of group policies, the node of trusting relationships between forest domains. Microsoft Documentation on the Nelogon Remote Protocol describes MS-NRPC as an interface to maintain the relationship between domain machines and controllers, transport authentication requests and transfer password changes.
Attacking from RCE on DC is in a position where two or three steps remain until the infrastructure is completely compromised: the dump of all hashes through the DCSync, the creation of Golden Ticket with hash krbtgt. deployed ransomware through Group Policy. No need for a chain of five vulnerabilities, you do not need a phishing - one UDP-package and a direct hit in the core of the infrastructure.
Technical Anatomy CVE-2026-41089: Stack overflow in Windows Netlogon
CVSS vector and MS-NRPC Vulnerability
According to the MSRC entry (date of publication on May 12, 2026), the vulnerability is described as: "Stack-based bufferflow in Windows Netlogon allows an unauthorized attacker to execute code over a network""Buffer overflow in Windows Netlogon slipper allows an unauthorized attacker to execute code over the network". CVSS-vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - we will analyze each component, because it determines the operational context:
• AV:N - operation over the network, physical access is not needed
• AC:L - low complexity, special conditions in the target configuration is not required
• PR:N - no privileges, attack before authentication
• UI:N - user actions are not required, full 0-click
• C:H / I:H / A:H - complete loss of privacy, integrity and accessibility
Vulnerability is classified as CWE-121 (Stack-based Buffer Overflow) - option CWE-787 (Out-of-bounds Write) and CWE-788 (Access of Memory Location). According to the MITRE description, CWE-121 Characteristic of languages without automatic control of memory boundaries (C, C++) and can lead to memory modifications, bypassing protection mechanisms or performing arbitrary code. CISA-APD ranks Technical Impact as "total", and Automatable - "yes", which means the possibility of mass automated operation. Simply put, it is wormable.
Mechanics of overcrowding in the CLDAP handler
[Applicable to: internal pentest, all versions of Windows Server to patch from May 12, 2026]
CLDAP (Connectionless LDAP, UDP 389) is one of the mechanisms through which clients detect domain controllers on the network. The Netlogon Service processes incoming CLDAP requests and generates answers with domain information.
Tool-checker ADScanPro/CVE-2026-41089-LongLogon (13 stars) is positioned as "unauthenticated, non-destructive precondition checker" and checks whether the long domain name of the controller is enough to call crash. The detail is not obvious, but important: the length of the DC domain name is a precondition for the overflow trigger.
According to third-party analyzes, patch, the patch replaces the vulnerable function of writing lines in netlogon.dll: old implementation copied the symbols into a fixed stack buffer without size control (hello, strcpy from the 90's), and the new takes the size of the buffer as a parameter and stops the record when the limit is reached, returning the error instead of overflowing to the adjacent stack area.
Operation scenario for attacker: send a specially formed CLDAP request to UDP 389 domain controller -> provoke overflow of the stack buffer when processing the line -> re-register the return address -> get control over the execution stream in the context of the process lsass.exe (which is hosted by Netlogon) with the privileges of SYSTEM.
Touched versions of Windows Server
Patch released for Windows Server 2012, 2012 R2, 2016, 2019, 2022, 2022 23H2 and 2025 - including Server Core. According to the NVD, Windows Server 2012, 2012 R2, 2016, 2019 and 2022 are affected; accurate minimum patches should be checked with the relevant KB items on support.microsoft.com. Suitable KB: KB5087471, KB5087470, KB5087537.
In short, everything Microsoft still supports is vulnerable. And what no longer supports, but continues to work in the production (and there are enough DCs).
Operation Netlogon RCE: a place in kill chain Active Directory
The Realistic Path of Attack
The internal pentest scenario in grey box mode has access to the corporate network (via VPN or physical connection), but without domain account data:
Stage 1 - Discovery. Find Domain Controllers via DNS Request _ldap._tcp.dc._msdcs.<domain> or broadcast CLDAP on UDP 389. The OS version is defined from LDAP rootdES-responses. To check the preconditions, the launch of the LongLogon checker, which determines whether the length of the domain name is suitable for operation without sending an exploit package.
Stage 2 - Exploitation of Remote Services (T1210, Lateral Movement) Sending a crafted CLDAP request for UDP 389 unpatept DC. Successful is the execution of arbitrary code.
Stage 3 - Exploitation for Privilege Escalation (T1068, Privilege Escalation) The code is executed in context lsass.exe - SYSTEM on the domain controller. Further increases in privileges are not required. We're already at the top.
Stage 4 - DCSync (T1003.006, Credential Access). With the privileges of SYSTEM on DC, perform the DCSync via secretsdump.py (Impacket) or mimikatz lsadump::dcsync /all - obtain NTLM hashes of all domain accounts, including krbtgt.
Stage 5 - Persistence and Lateral Movement. Hash krbtgt - Golden Ticket for the entire domain. Administrators' Heaches Pass the HashT1550.002) via SMB/Windows Admin Shares (T1021.002) Registration rogue domain controller (T1207) for long-term presence. Reconnaissance of trust (T1482) - going beyond the current domain to other forest domains. Creating backdoor accounts in Domain Admins (T1078.002)
From UDP-package to Golden Ticket - four steps. On a real project, it's minutes, not hours.
Predictions and limitations in modern environments
Works if: DC is not patchy (no KB508771/KB508770/KB5087757), UDP 389 is available from the attacker's position, the domain name is sufficient length for the overflow trigger (verified by the LongLogon checker).
Does not work if:
Patch is installed - after updating the line record function checks the boundaries of the buffer, and overflow is impossible.
Network Segmentation DC is in the isolated management VLAN, UDP 389 is blocked from work subnets. In practice, stateful firewall (Palo Alto, Fortinet) filters UDP 389 from non-mustard zones. But I’ve seen enough “flat” nets not to rely on it.
External pentest - DC should not be available from the Internet. But CLDAP exposure is a real problem: Shodan captures thousands of open UDP 389 on Windows Server.
Stack Mimmation - ASLR, DEP and stack cookies on Windows Server 2019+ complicate the operation (requires bypassing ASLR to control RIP), but does not eliminate the vulnerability. Patch is mandatory.
EDR on DC CrowdStrike Falcon and Microsoft Defender for Endpoint Detectal Behavior lsass.exe after operation (child processes, memory access patterns). SentinelOne fixes injection in lsass.exe. Elastic 8.x+ with Endpoint Security module logs networks connections from lsass.exe (Sysmon EID 3) But none of the listed products block the CLDAP-package itself until overflow - they catch the consequences, not the cause.
Vulnerability Verification and Patt Check on Domain Controllers
Adjustments to the environment
• OS: Windows Server with AD DS role (any supported version)
• Rights: Domain Admin or local administrator on each DC
• RAM: DC standard requirements (minimum 4 GB, recommended 8+ GB for Server 2019/2022)
• Tools: PowerShell 5.1+, ActiveDirectory module, optional - ADScanPro/CVE-2026-41089-LongLogon
The first step is to inventory all DCs in the forest and checking the status of KB-update:
Code:
Get-ADDomainController -Filter * | ForEach-Object {
$kb = Invoke-Command -ComputerName $_.HostName -ScriptBlock {
Get-HotFix | Where-Object {$_.HotFixID -match 'KB508747[01]|KB5087537'}
}
[PSCustomObject]@{
DC=$_.HostName; Site=$_.Site; OS=$_.OperatingSystem
Patched=[bool]$kb; KB=$kb.HotFixID -join ','
}
} | Format-Table -AutoSize
In the absence of KB - additional check of the hash of the binary file: Get-FileHash C:\Windows\System32\netlogon.dll -Algorithm SHA256. Any DC with a non-coincient hash is considered vulnerable until the opposite is confirmed.
And here is the moment that is ignored on projects most often: you need to patch all DC in one maintenance window. Half-patched AD forest is not defensable state. One unpatept DC in the forest of ten - and that's enough. The attacker will simply direct the exploit to this particular node.
Determination of operation CVE-2026-41089: IOC and SIEM-rule
Compromise Indicators
Network level: anomalous CLDAP traffic (UDP 389) from sources that are not domain machines. A characteristic feature is the non-standard size of packages directed to DC from hosts outside the desktop list. According to CCB and SecPod, the IOC infrastructure (IP addresses C2, domains, campaign files hashes) at the time of June 2026 are not publicly disclosed - the available indicators are of a behavioral nature.
Host level: Key IOC - crash lsass.exe with faulting module netlogon.DLL and Exclus Code 0xc0000409 (STATUS_STACK_BUFFER_OVERRUN). In Windows Event Log - Event ID 1000 (Application Error). Any such event on an unpatept DC is the basis for launching the incident-response procedure. Not "the probable cause of the reboot", not "probably, the memory is over" - and IR. Immediately.
Post-operational IOC: Subsidiary processes from lsass.exe (Sysmon EID 1 with ParentImage lsass.exe). Outgoing networking compounds from lsass.exe to non-standard addresses (Sysmon EID 3), adding accounts to the preferred groups - Event ID 4728, 4732, 4756 - in non-working hours.
SIEM-rule by vendor
Microsoft Sentinel (KQL):
Code:
Event
| where EventID == 1000 and Source == "Application Error"
| where RenderedDescription contains "lsass.exe"
and RenderedDescription contains "netlogon"
and RenderedDescription contains "c0000409"
| project TimeGenerated, Computer, RenderedDescription
| extend Alert = "CVE-2026-41089 crash candidate"
Splunk: source="WinEventLog:Application" EventCode=1000 "lsass.exe" "netlogon.DLL" "0xc0000409" - followed by the correlation on Computer name to detect serial crashes.
Elastic (KQL): event.code:1000 AND process.name:lsass.exe AND winlog.event_data.ModuleName:netlogon AND winlog.event_data.ExceptionCode
"0xc0000409" OR "c0000409").Limitation of these rules should be understood: they fix crash - DoS state or an unsuccessful attempt to operate. Successful RCE without crash may not leave these artifacts. To cover this scenario - monitoring of child processes from lsass.exe through Sysmon EID 1 and network connections via Sysmon EID 3.
For Netlogon debug logging on unpatept DCs until the update is set: nltest /dbflag:0x2080ffff - Logs are recorded in %windir%\debug\netlogon.log. After the patch disable: nltest /dbflag:0x0, to avoid overhead from the volume of logging.
CVE-2026-41089 vs ZeroLogon: a comparison of critical vulnerabilities Netlogon Remote Protocol
Key difference to practice: ZeroLogon when operating broke AD - after the DC machine account password, the replication ceased to work, and it was impossible to hide it. On real projects, it was necessary to coordinate with the customer the recovery, write explanatory, wait until the backup will be raised. CVE-2026-41089 with pure operation gives the shall without destructive side effects - the attacker can act secretly. This makes Windows Server RCE CVE more dangerous in the hands of APT groups: ZeroLogon made noise like an elephant in a china shop, and here it is silence.
