Huntress Discloses Windows Search URI Flaw That Leaks NTLMv2 Hashes

Huntress disclosed a Windows Search URI handler flaw that silently sends NTLMv2 hashes to attacker servers with one click. Microsoft declined to patch.
Table of Contents
    Add a header to begin generating the table of contents

    Huntress Security disclosed on June 3, 2026 a vulnerability in Windows Search’s URI handler that silently transmits users’ NTLMv2 authentication hashes to attacker-controlled servers with a single click — no warning dialogs, no security prompts, and no additional user interaction required beyond opening a malicious link. Microsoft reviewed the report, determined the flaw “falls below the servicing bar,” and declined to issue a patch.

    How the Windows Search URI Handler Leaks NTLMv2 Hashes to Attacker Servers

    The attack exploits the crumb=location parameter within Windows Search URIs — links that use the search: protocol to trigger the Windows Search application. When a user clicks a search: link embedded in a webpage, document, or email message, Windows initiates an SMB authentication handshake against the server specified in the URI’s location parameter. If that server is attacker-controlled, Windows automatically transmits the victim’s Net-NTLMv2 credential hash during the handshake — without any security warning or user consent.

    What Captured NTLMv2 Hashes Enable: Offline Cracking and NTLM Relay

    The NTLMv2 hash is not the same as a plaintext password, but in practice the distinction matters less than it appears. Captured hashes can be cracked offline using tools like Hashcat on modern GPU hardware — particularly effective against shorter or dictionary-based passwords. More immediately, the hashes can be relayed directly using tools like Responder and NTLM relay attack frameworks to authenticate to other network resources as the victim, enabling lateral movement across Windows enterprise environments without ever recovering the original password.

    Microsoft’s “Below the Servicing Bar” Response and the April 14 Snipping Tool Precedent

    Microsoft’s rejection characterized the vulnerability as falling below the threshold the company applies for security patch decisions. Huntress proceeded with public disclosure after receiving that determination — making the technical details publicly available to both defenders and adversaries.

    The Inconsistency With CVE-2026-33829 in the Windows Snipping Tool

    The flaw directly parallels CVE-2026-33829, a similar NTLMv2 hash leakage vulnerability discovered in the Windows Snipping Tool — an attack through a different URI protocol handler following the same structural pattern. Microsoft patched that vulnerability on April 14, 2026. The existence of a patched, same-class vulnerability in the Snipping Tool raises questions about why the Snipping Tool leak met the servicing bar while the Windows Search URI leak did not.

    The pattern suggests incomplete remediation of NTLM hash leakage across Windows URI protocol handlers — a class of vulnerability rather than an isolated flaw. Protocol handlers that initiate outbound SMB connections in response to user input are a consistent mechanism for NTLM hash exposure, and the Windows Search handler represents one more instance of that pattern.

    Defensive Mitigations Against Windows Search URI NTLMv2 Leakage

    In the absence of a Microsoft patch, the primary mitigations available to enterprise defenders are network-level controls: blocking outbound SMB connections at the perimeter prevents the authentication handshake from reaching attacker-controlled servers. Enforcing SMB signing across the environment reduces the effectiveness of NTLM relay attacks even if outbound SMB reaches external hosts. Both controls represent established best practices for Windows enterprise environments that take on additional urgency given Huntress’s disclosure and Microsoft’s refusal to patch the root cause.

    Related Posts