The research, published by Alexander Neff, Tobias Holl and Kevin Borgolte at USENIX WOOT 2026, revisits Zerologon, the Netlogon authentication flaw tracked as CVE-2020-1472. iTnews highlighted the central claim: a new attack called Onelogon can bypass the narrow cryptographic check Microsoft added in 2020. But the practical exposure is more specific than “Zerologon is back”: Onelogon requires a target account for which a domain controller still permits Netlogon without secure RPC signing and sealing.
That distinction is the operational story. Microsoft’s post-Zerologon guidance has warned since 2020 that any account placed in the Domain controller: Allow vulnerable Netlogon secure channel connections policy remains exposed to attack. The Bochum paper shows that this was not merely a general compatibility risk. The exception can still provide the exact opening needed to bypass the original patch’s challenge-filtering logic and seize an exempted Active Directory machine identity.
The 2020 fix had two layers, and one remains effective
Zerologon abused the way Netlogon used AES-CFB8 encryption with an all-zero initialization vector. An attacker could repeatedly attempt authentication until they hit a session where an all-zero credential was accepted, then use that foothold to reset a computer account password. If the target was a domain controller account, the attacker could take control of the Active Directory domain.
Microsoft’s response had two separate components. The first changed Netlogon to reject a recognizable pattern associated with the original exploit: challenges and authenticators whose first five bytes are identical. The second was the more consequential deployment change: domain controllers would require Netlogon traffic to use secure RPC, meaning RPC messages are signed and sealed with the session key.
The Bochum researchers found that the first mechanism is incomplete. A carefully structured challenge can pass Microsoft’s five-byte check while retaining the cryptographic property the attacker needs. In other words, the patch blocks the known all-zero form of Zerologon but does not correct Netlogon’s underlying cryptographic design.
However, the second layer still stops the attack. Onelogon can establish a fraudulent Netlogon channel, but it does not give the attacker the session key needed to sign later RPC requests. If secure RPC is enforced, the forged channel cannot be used to reset a password or make privileged Netlogon calls.
This makes the policy exception—not a missing Patch Tuesday update—the decisive condition.
Legacy allow lists turn a compatibility choice into an AD takeover path
Microsoft began enforcing secure RPC for Netlogon connections in February 2021, while allowing organizations to preserve exceptions for devices that could not support the newer requirement. The policy was intended as a transition mechanism for older appliances, third-party domain members, and unusual trust configurations. Microsoft’s documentation says plainly that the end goal should be to remove every account from that exception list.
Yet those exceptions persist. The researchers received aggregate data from SpecterOps covering 44 enterprise customers and found that 23% still had an active vulnerable-connection policy in late 2025. They also report a separate 2026 scan of 270 organizations in which six had configurations directly exploitable by Onelogon.
Those are not population-wide prevalence figures. The SpecterOps sample is small, aggregate-only, and potentially biased toward organizations already seeking Active Directory security help; the researchers acknowledge that limitation. Still, it establishes something more useful than a theoretical demonstration: vulnerable configurations are still present in production environments years after Microsoft’s enforcement phase began.
The risk is also broader than a single forgotten workstation. The exception policy can name machine accounts, trust accounts, groups, or security principals. A broadly scoped entry—such as one inherited through a large group—can make many computer accounts eligible targets. An exempted domain controller account is the worst case because control of that identity can become full domain compromise.
Microsoft specifically warned administrators in its Zerologon deployment guidance not to place accounts running high-privilege services, including Microsoft Exchange or Configuration Manager, on the vulnerable-connection allow list. Onelogon gives that old warning renewed urgency. A compatibility exception attached to an infrastructure account is no longer a temporary inconvenience; it is a material identity-security boundary.
Onelogon is slower than Zerologon, but fast enough to matter
The original Zerologon exploit became notorious because its favorable condition occurred with a probability of one in 256, allowing attacks to work in seconds. Microsoft’s five-byte filter makes a naïve bypass far less likely, pushing a straightforward brute-force attempt into impractical territory.
The researchers’ contribution is showing how Netlogon’s handling of pending challenge requests changes that math. Netlogon maintains a server-side global challenge list, accepts up to 100,000 pending entries, and uses a lookup process that lets an attacker test authentication attempts against many outstanding challenges. The research turns the restrictive patch into a practical attack through two methods.
One method assumes the attacker has already compromised any low-privilege domain-joined computer account. That account can be used to clear the relevant pending challenges, enabling a 24-bit brute-force approach. In the researchers’ testing, the expected time to compromise a vulnerable target account was 32.44 minutes.
The second method does not require prior access to a domain computer account. It uses a meet-in-the-middle approach that stays within Netlogon’s challenge-list limit but sprays authentication attempts fast enough to find a usable combination before challenge entries expire. The reported expected average was 36.84 minutes.
Those timings should not be mistaken for an Internet-wide remote attack claim. Zerologon and Onelogon concern Netlogon access to a domain controller, normally reachable from an internal network segment or from a system already positioned inside it. The no-account variant lowers the authentication prerequisite, but network placement, firewalling, and exposure of RPC services still matter.
The practical implication is straightforward: an intruder who has reached the internal network no longer necessarily needs to steal a specific privileged credential before pursuing an exempted Active Directory account. A stale exception can provide a route from network access to control of that account.
Microsoft’s existing logs are the first place to look
Microsoft has not announced a new Onelogon-specific fix. According to the Bochum researchers, Microsoft’s position during disclosure was that Netlogon use without secure RPC is already documented as vulnerable. That position is defensible in a narrow sense: Microsoft’s existing documentation repeatedly says accounts in the allow policy can be taken over.
But the research changes the urgency of treating exceptions as temporary. The original cryptographic check may create a false sense that systems are “patched for Zerologon” even while a compatibility policy leaves a subset of identities exposed to a related takeover attack.
Administrators should begin with the domain controller-side configuration, not an endpoint vulnerability scanner:
- Review the Domain controller: Allow vulnerable Netlogon secure channel connections setting in every applicable Group Policy Object and determine which principals are effectively exempted.
- Inspect the corresponding
VulnerableChannelAllowListconfiguration and its permissions, because an attacker who can modify it could create or expand an exposed target set. - Remove stale machine and trust account exemptions, and obtain secure-RPC-capable updates from third-party vendors where possible.
- Isolate devices that truly cannot support secure RPC into a separate Active Directory forest rather than retaining a permanent exception inside the production forest.
- Check domain controller System logs for Netlogon events 5830 and 5831, which record vulnerable machine-account and trust-account connections allowed because of the policy.
The research also identifies Event ID 5805 as a useful signal during an attack: repeated failed Netlogon authentication attempts are an expected byproduct of the brute-force process. A successful exploitation sequence against an exempted machine or trust account should also create Event ID 5830 or 5831. Those events are not exclusive proof of Onelogon—legacy devices can produce them legitimately—but a burst of failed authentication activity followed by an allowed vulnerable connection warrants immediate investigation of the source host and target account.
The patch status is less important than the exception status
Calling Onelogon a patch defeat is accurate at the cryptographic level but incomplete for administrators deciding what to do next. The 2020 challenge filter can be bypassed; secure RPC enforcement cannot be bypassed by the attack described in the paper. Domains with no vulnerable Netlogon allow-list entries are not in the paper’s practical attack path.
The uncomfortable finding is that Microsoft’s long-standing backward-compatibility valve has outlived the migration period in a meaningful number of environments. There is no new KB number to chase, and installing the latest cumulative update does not erase a deliberate policy exemption.
For Windows and Active Directory teams, the immediate milestone is therefore measurable: drive the vulnerable Netlogon allow list to zero, or move the remaining legacy dependency out of the production forest. Until then, “patched for Zerologon” is not an adequate description of the domain’s exposure.