Unpatched `search:` URI Handler Leaking NTLMv2 Hashes? Here's What We Know
Has anyone else dug into the recent Huntress disclosure regarding the search: URI handler? It appears we have another unpatched vector for NTLMv2 hash theft, echoing the issues we saw with the Snipping Tool (CVE-2026-33829).
The core issue is that the search: protocol handler can be abused to initiate a connection to a remote attacker-controlled server. When a victim clicks a specially crafted link, Windows attempts to authenticate via the current user's context, sending the NTLMv2 hash over the wire. If the attacker captures this, it's just a matter of time before they crack it or relay it.
Since there's no patch yet, we need to focus on detection and mitigation. We can check the registry association for these handlers using PowerShell:
Get-ItemProperty "HKCU:\Software\Classes\search\shell\open\command" -ErrorAction SilentlyContinue
**Mitigation Options:**
* **Network Level:** Block outbound SMB (TCP 445) and NTLM traffic to the internet.
* **Registry:** Remove or disable the `search:` URI handler association entirely, though this might impact local search functionality in some apps.
I'm leaning towards disabling the handler in our golden image for now. How is everyone else handling this while we wait for a Microsoft fix? Are you relying solely on NetNTLMv1/2 relaying defenses?
We've seen this behavior in our pentest lab environments. It's scary reliable. If the user is logged in as a local admin, that hash is gold. We recommend checking your proxy logs for NTLMSSP negotiations to unknown external IPs. Also, ensure you have NTLM Relay protections enabled on your domain controllers and critical servers.
I wouldn't recommend nuking the registry key immediately if your users rely on Cortana or Windows Search integrations in third-party apps. A safer interim bet is enforcing NTLM blocking at the firewall level for egress traffic. You can use this PowerShell snippet to verify if NTLM is being used in active auth attempts:
gpresult /h gpreport.html
# Then check 'Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers' settings
Another MSP here. We're deploying a script to change the default behavior of the handler. Not ideal, but the risk of credential theft is too high right now. Has anyone confirmed if this affects just Windows 10/11 or if Server 2022 is also vulnerable to the specific URI trigger?
Solid points from everyone. To quickly triage which endpoints are actively registering this handler without disrupting users, you can query the registry remotely. This helps scope the remediation efforts for Quinn's script.
Get-ItemProperty -Path "HKCR:\search\shell\open\command" -ErrorAction SilentlyContinue | Select-Object -ExpandProperty '(default)'
Just remember to run this in a privileged context for remote checks.
Building on Nina's advice, if you need to verify exactly which executable is handling the search: protocol to ensure it hasn't been hijacked by something else, this PowerShell one-liner is efficient:
Get-ItemProperty 'HKCU:\Software\Classes\search\shell\open\command' -ErrorAction SilentlyContinue | Select-Object -ExpandProperty '(default)'
This reveals the command string, useful for confirming the expected system binary is in use before you push any registry fixes.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access