The most useful technique in the average Active Directory attack tree right now is older than Windows Vista. Drop a malicious shortcut in a folder the victim browses, or stand up a rogue RPC endpoint on a hardened workstation, or — if you still feel like it — fire PetitPotam at a domain controller that nobody got around to patching after 2021. In every case you end up holding a Net-NTLMv2 hash that you crack offline or relay live to LDAP, MSSQL, or ADCS, and from there you walk into the domain.

Two disclosures in the last month should make every infrastructure team revisit how much NTLM coercion surface they actually have, because both confirm something defenders have been quietly absorbing for years: NTLM coercion is not a series of bugs. It is the architecture working as designed, and Microsoft’s patching model is structurally incapable of fixing it one CVE at a time.

The first disclosure was CVE-2026-32202 on April 14 — a zero-click Windows Shell flaw that turns folder browsing into a Net-NTLMv2 hash leak, born from an incomplete patch of an APT28 zero-day. The second was PhantomRPC on April 24 at Black Hat Asia — an unpatched architectural defect in rpcrt4.dll that lets a low-privileged process register a rogue RPC endpoint, hijack the next SYSTEM caller, and impersonate. Different bugs, different layers of the stack, same outcome: someone hands you their identity.

This piece is about why those two bugs look so similar, why three separate Microsoft “kill NTLM” initiatives have not yet killed NTLM, and what your fleet actually needs to stop being a relay target between now and the day NTLM finally goes away.

A Brief, Painful History of NTLM Coercion

Coercion attacks are not new. The PrinterBug (MS-RPRN) was disclosed in 2018 — a remote attacker who could authenticate to the Print Spooler service could ask a domain controller to authenticate back to an attacker-controlled host, hashed credential in hand. PetitPotam followed in 2021, abusing the EFSRPC interface to do the same thing without authentication. DFSCoerce hit in 2022 against the MS-DFSNM interface. ShadowCoerce, RemotePotato0, the long parade of *Coerce proof-of-concepts on GitHub — each one finds a different RPC endpoint, a different protocol handler, or a different document-rendering path that issues an outbound SMB connection on demand.

The pattern that ties them together is straightforward. Windows has dozens of authenticated and unauthenticated protocol paths that accept a UNC path as a parameter and faithfully resolve it. The protocol parsers do not consult a zone map. They do not validate that the destination is in the same forest. They issue the SMB connection, the SMB connection negotiates NTLM, and the host that initiated the call coughs up its machine account or user hash to whatever server is on the other end.

Microsoft’s response over seven years has been to patch the specific endpoints — Print Spooler got hardened, MS-EFSRPC got an authentication requirement, and so on — without addressing the underlying behavior. The result is exactly what you would expect: every new Windows release ships a new set of UNC-accepting endpoints, each one a fresh primitive the moment someone notices.

CVE-2026-32202 is that pattern in its 2026 form. Akamai’s Maor Dahan was auditing Microsoft’s February 2026 fix for an APT28 LNK-handling zero-day (CVE-2026-21510). The February patch closed the RCE leg of the chain and the SmartScreen bypass leg. It left intact a third behavior the same code path supported: a .lnk shortcut whose icon path points at \\attacker.example\share\icon.ico triggers an outbound SMB connection the instant Explorer renders the folder. No double-click. No prompt. No user action beyond opening Downloads.

The patch shipped April 14 with a CVSS of 4.3 and no exploited-in-the-wild flag. Microsoft updated the advisory thirteen days later to confirm active exploitation, and CISA added it to the Known Exploited Vulnerabilities catalog two days after that. For nearly two weeks, the average enterprise had a zero-click NTLM coercion primitive on every supported version of Windows from Server 2012 to Windows 11 26H1, and most patch-management workflows had no reason to prioritize it.

What CVE-2026-32202 Tells Us About the Patching Model

The reason this matters as a trend rather than as one more CVE is that the Akamai writeup is, charitably, a roadmap. The original APT28 chain abused LNK files for code execution. Microsoft fixed the most visible leg of the chain. The same .lnk parsing code in Windows Shell still treats UNC paths in icon attributes as worth resolving, and there is no reason to expect that the next disclosed variant will be any different.

We have been here before with Office DDE, with the macro autorun pipeline, with the MOTW propagation logic, and most painfully with NTLM relay through nlmp. Each cycle goes the same way: a researcher publishes a coercion primitive, Microsoft patches the specific function call or endpoint, two years pass, a different researcher finds the same primitive at a different layer. The patch model treats each occurrence as an isolated mistake. Defenders treat each occurrence as another instance of a structural problem they cannot remediate because the structural problem is the protocol’s contract.

The April incident also makes a quieter point about the value of vendor-supplied exploitability metadata. Microsoft’s initial assessment — “Exploitation Less Likely,” CVSS 4.3 — was the input most enterprise vulnerability management programs would have used to triage the April patch. The actual reality was an in-the-wild, zero-click, NTLM coercion primitive. The two-week gap between patch release and the “Exploitation Detected” tag is the kind of window where your fleet ships through three change windows on the old build because nothing in your data said to expedite.

PhantomRPC and the Trust-the-Endpoint Mistake

PhantomRPC is the same kind of structural defect at a different layer. The Windows Endpoint Mapper (RpcEpResolveBinding and friends) returns the most recently registered endpoint for any given interface UUID and provides no mechanism for a client to verify that the server on the other end actually owns the interface. There is no SDDL on the binding. There is no SID check. There is no signed-endpoint negotiation. The RPC runtime opens the transport and trusts whatever responds.

That contract worked when every RPC server on a machine was either part of the operating system kernel or a Microsoft-signed service running under a SYSTEM context. It stopped working the moment unprivileged user processes could register RPC endpoints, which is to say it stopped working roughly twenty years ago. Kaspersky’s Haidar Kabibo walked through five distinct chains at Black Hat Asia 2026 that each end at SYSTEM by waiting for a privileged client to call out, intercepting it through a rogue endpoint, and calling RpcImpersonateClient on the resulting token. Group Policy Client to a stopped TermService. Edge startup to TermService. WinRM bootstrap. BITS. The Schedule service.

Microsoft’s response to Kaspersky’s September 2025 report was to classify the bug as moderate severity, decline to assign a CVE, and close the ticket. As of this writing, seven months later, there is no patch and the public PoC repository ships an audit harness. The reason there is no patch is that fixing PhantomRPC properly requires changing the EPM contract — which means breaking every existing RPC client that depends on the current “trust the endpoint” behavior, which is to say nearly all of them. The economic and compatibility math on Microsoft’s side is not difficult to follow.

The reason PhantomRPC matters in a piece about NTLM coercion is that it is the same shape of problem. A protocol where one party trusts another party to be who it claims to be, with no integrity check baked into the protocol layer, ends up exploitable the moment the trust assumption is violated. The fact that PhantomRPC abuses local impersonation instead of network NTLM authentication is a detail. The structural pattern — protocol layer trusts identity that is not cryptographically bound — is identical.

Why Microsoft Hasn’t Killed NTLM (And Probably Won’t Until 2028)

Microsoft announced the deprecation of NTLM in October 2023. The roadmap promised “disabled by default” in a future Windows release. Two and a half years later, the disabling has not happened, and the public deprecation notice on Microsoft Learn now reads more like a wishlist than a schedule.

There are three reasons. The first is that NTLM is still the fallback authentication mechanism for every scenario where Kerberos cannot work: cross-forest trusts without proper SPNs, local accounts on non-domain-joined machines, workgroup file shares, scenarios where the client cannot resolve the KDC, and a long tail of legacy applications that explicitly request NTLM SSPI. Some of those scenarios are fixable. Many are not — they are baked into vendor software that ships to enterprises and has no Kerberos code path at all.

The second is that the relay surface is not in NTLM the protocol — it is in the protocols layered on top of NTLM that fail to require signing or channel binding. SMB, LDAP, MSSQL, ADCS, RPC over HTTP. Each of those has independent configuration knobs for whether the channel is integrity-protected, and each has its own multi-year deprecation history of operators who turned signing off because something broke. The protocols above NTLM, not NTLM itself, are the actual relay vulnerability.

The third is that disabling NTLM domain-wide is an operations problem of a kind enterprise IT has historically been bad at. The data Microsoft publishes about LDAP signing enforcement on domain controllers in April 2026 still shows a meaningful minority of environments without it enforced. If enterprises cannot turn on LDAP signing — a binary configuration change with broadly understood compatibility consequences — they will not be ready to disable NTLM, which involves auditing every application authentication path in the environment.

Realistic timeline: NTLMv1 finally disappears for most enterprises in 2027 or 2028. NTLMv2 remains usable, but in a “Kerberos preferred, NTLM permitted only for specific exceptions” posture, for another five to seven years after that. Plan accordingly.

The Relay Surface That Still Exists in Your Network

Until then, the relay surface is what matters. A coercion primitive is interesting only if there is somewhere to relay the resulting authentication. The depressing reality of 2026 is that most enterprises still have at least one of the following relay targets reachable from typical lateral movement positions:

A domain controller without LDAP channel binding enforced. Microsoft’s LdapEnforceChannelBinding registry value is still optional in 2026; the default is permissive. A relayed NTLM authentication against LDAP without channel binding is a credential-add primitive — the attacker can write userPassword attributes or modify msDS-KeyCredentialLink for shadow credentials.

An Active Directory Certificate Services web enrollment endpoint that accepts NTLM. ESC8 from SpecterOps is now five years old and still the highest-impact relay target in most environments. Web enrollment over HTTP without Extended Protection for Authentication accepts a relayed authentication and issues a certificate the attacker can then use to authenticate as the relayed identity for the certificate’s lifetime.

An MSSQL server without SMB signing required on the host, configured for Windows authentication. A relayed authentication to MSSQL grants whatever database privileges the relayed identity had — which, in enough environments to matter, is sysadmin on a server hosting business-critical data.

A file server without SMB signing required. The classic relay target, still alive, still useful for accessing whatever the relayed identity could see on the share.

Each of those has had a hardening recommendation in Microsoft documentation for years. The recommendations are not new. What is new is how cheap the coercion side of the equation has become. With CVE-2026-32202, the attacker does not need to find a vulnerable Print Spooler or persuade the victim to click anything. They drop a .lnk and the victim browses Downloads.

A Practical NTLM-Hardening Checklist for Infrastructure Engineers

If your team has not done an NTLM exposure audit in 2026, this is the work. Roughly in priority order:

Enforce LDAP signing and channel binding on every domain controller. The relevant registry values are LDAPServerIntegrity (set to 2, require) and LdapEnforceChannelBinding (set to 2, always). Microsoft has shipped a compatibility logging mode for both — turn it on for two weeks, watch the event logs, fix the application owners who break, then enforce.

Require SMB signing on every server and workstation. The Windows 11 24H2 default finally made this the case for new installations, but most fleets are not fully on 24H2 yet. The group policy is under Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options: “Microsoft network server: Digitally sign communications (always)” and the corresponding client setting. Enforce both directions.

Enable Extended Protection for Authentication on every IIS endpoint that accepts Windows authentication, especially ADCS web enrollment, Exchange, and any internal-line-of-business application that does NTLM. EPA binds the authentication to the TLS channel, which kills HTTP-to-LDAPS and HTTP-to-SMB relay paths.

Block outbound TCP/445 and TCP/139 at the perimeter, and on host firewalls where the environment will tolerate it. There is no legitimate reason for a corporate workstation to initiate an SMB session to an arbitrary internet host. The host firewall rule alone defangs LNK-based coercion against external attacker infrastructure even when the underlying bug is unpatched.

Audit your RPC service inventory for the PhantomRPC shape. Kaspersky’s audit harness enumerates which privileged RPC clients on a host can be hijacked when their target service is in Disabled state. Run it on a representative sample of your fleet — workstation image, server image, RDS host, jump host — and capture the output as a baseline. The fix where you find a hit is usually “stop having that service disabled on this image” rather than a patch.

Hunt for the IOCs. Akamai’s CVE-2026-32202 writeup ships a Sigma rule for outbound SMB connections from user workstations to non-corporate IPs. Run it. The signal is high.

Enable Microsoft’s NTLM auditing on domain controllers (Restrict NTLM: Audit Incoming NTLM Traffic and Audit NTLM Authentication In This Domain) for a 30-day window. The Event 8004 stream will give you a complete inventory of every application in your environment that depends on NTLM, which is the data you need to plan the eventual disable.

The Opinionated Take: Stop Treating Hash Disclosure as Information Disclosure

Microsoft scored CVE-2026-32202 a 4.3. The bug is “information disclosure” — confidentiality only, low impact, no integrity or availability effect — by the CVSS rubric.

This scoring model is wrong for NTLM hash disclosure and has been wrong for the entire decade that NTLM relay has been a viable attack primitive. A Net-NTLMv2 hash is not information in the sense that an exposed config file is information. It is a forgeable credential. Net-NTLMv2 cannot be passed in a direct pass-the-hash, but it can be cracked offline against weak passwords, and more importantly it can be relayed in real time against the relay targets enumerated above. The score should reflect the exploitable downstream impact, which in most enterprise environments is “domain compromise within a single afternoon.”

The same logic applies to PhantomRPC’s “moderate severity” classification. Anywhere an attacker has local code execution at any privilege, PhantomRPC is a SYSTEM primitive. Calling that moderate is a categorization choice that prioritizes the difficulty of remediation on the vendor side over the actual security consequence for the customer.

Two recommendations follow from this, one for vendors and one for defenders.

For vendors: stop scoring hash leaks and impersonation primitives on the immediate-impact rubric and start scoring them on the chain-completion rubric. If the bug is one step in a known multi-step attack chain whose endpoint is privilege escalation or domain compromise, the score should reflect the chain. CVSS supports environmental and temporal metrics; vendors are not required to publish only the base score.

For defenders: do not let your vulnerability management program triage NTLM coercion bugs by the published base score. Treat any CVE with the words “NTLM,” “coerce,” “UNC,” “SMB authentication,” or “Net-NTLMv2” in its description as a Priority 1 fix regardless of the score the vendor assigned. The base rate of “this turned out to be a relay primitive in production” on those bugs is high enough that the override is correct on average even when individual cases are over-graded.

What To Watch For Next

The next twelve months will produce more of the same. There are at least two known coercion primitives in unfixed Windows components (the OLE Automation interface is one; researchers have circulated PoCs for an unpatched MSRPC path that is reachable from Outlook attachment rendering). The Black Hat USA 2026 schedule lists at least one talk on “RPC endpoint trust violations in 2026,” which from the abstract reads like a continuation of PhantomRPC. And the announced Microsoft NTLM deprecation milestone for Windows 11 26H1 will, based on everything that came before, slip again.

What changes the dynamic is enterprises actually completing the NTLM-exposure audit and the LDAP/SMB/ADCS hardening work. The protocols are not the problem. The configuration of the protocols is the problem. That is fixable. It has been fixable since 2021. The reason it has not been fixed is that the work is unglamorous, it breaks legacy apps, and no executive ever made a quarterly OKR out of “enforce LDAP signing on the domain controllers.”

The next NTLM coercion bug will land within a quarter. The deciding question for your environment is not whether the patch ships fast. It is whether, when the next coercion primitive turns out to be zero-click, the relay targets the bug points at are still configured the way they have been for a decade.

The work is to make the answer “no.”