Falha não corrigida no manipulador URI do Windows Search expõe hashes NTLMv2

O problema no esquema search: permite induzir conexões SMB para um servidor controlado por atacante e capturar hashes Net-NTLMv2 sob interação do usuário.

Componente	Manipulador URI search: do Windows, com uso do parâmetro crumb=location: para apontar uma localização UNC.
Vetor	Usuário induzido a abrir um link especialmente criado em navegador, página web, mensagem de e-mail ou outra origem de URL, seguido de aprovação para iniciar o manipulador.
Impacto	A estáção pode iniciar autenticação SMB contra servidor escolhido pelo atacante e expor o hash Net-NTLMv2 do usuário, com risco de uso em ataques de relay.
Prioridade	Bloquear SMB de saída quando não for necessário, exigir assinatura SMB e desabilitar NTLM onde a operação permitir.
Artefatos	Esquemas e parâmetros citados incluem search:, crumb=location:, ms-screensketch: e filePath; o comando de demonstração foi omitido.
Status	O problema foi divulgado de forma responsável em 15 de abril de 2026, mas não recebeu correção porque foi enquadrado abaixo do limite de severidade de atendimento informado.

Resumo técnico

Uma falha ainda sem correção no manipulador URI search: do Windows permite que um link especialmente preparado leve o sistema a iniciar uma conexão SMB para um servidor definido pelo atacante. O efeito técnico confirmado é a exposição do hash Net-NTLMv2 do usuário, desde que a vítima abra o link a partir de uma origem como navegador, página web ou e-mail e aprove o lançamento do manipulador associado. O problema não depende de execução direta de código no endpoint; o risco está no acionamento de autenticação NTLM para uma localização remota controlada por terceiro.

O caso é tecnicamente semelhante ao comportamento corrigido em abril de 2026 no CVE-2026-33829, que afetava o manipulador ms-screensketch: da Ferramenta de Captura do Windows. Naquele cenário, o parâmetro filePath aceitava um caminho UNC sem validação suficiente e podia fazer o computador consultar um servidor SMB externo. A nova variação troca esse caminho pelo fluxo do Windows Search, usando search: com crumb=location: para alcançar o mesmo resultado: forçar a autenticação NTLM e revelar material reutilizável em tentativas de relay.

Fluxo técnico

O fluxo começa com a preparação de uma URL que invoca o esquema search: e define uma localização por meio de crumb=location:. Quando essa localização é um caminho UNC apontando para um servidor SMB sob controle do atacante, o Windows pode tentar resolver o recurso remoto como parte do comportamento do manipulador. Durante essa tentativa, se NTLM estiver disponível e a estáção puder iniciar SMB de saída, ocorre negociação de autenticação e o servidor remoto recebe o hash Net-NTLMv2 associado ao usuário que acionou a URL. O comando operacional demonstrativo foi omitido porque não é necessário para defesa.

A exploração exige interação do usuário e aprovação para abrir o manipulador, o que limita o cenário a engenharia social, phishing, páginas com links preparados ou outras fontes de URL capazes de induzir o clique. O impacto não deve ser descrito como comprometimento automático do host ou roubo confirmado de dados internos; o dado exposto é o hash Net-NTLMv2. Ainda assim, esse artefato pode ter valor operacional em ambientes que aceitam relay NTLM contra serviços internos, especialmente quando SMB signing não é obrigatório ou quando serviços legados ainda confiam em NTLM.

Superfície afetada

A superfície principal envolve estáções Windows em que o manipulador search: está disponível, NTLM continua habilitado e o host pode estabelecer conexões SMB de saída por TCP/445 ou TCP/139 para destinos externos ou não confiáveis. A exposição também depende de o usuário aceitar a abertura do link, pois a cadeia descrita não afirma execução silenciosa sem interação. Organizações com controles rígidos de egress SMB, assinatura SMB obrigatória e redução de NTLM têm uma janela de abuso menor.

O histórico do CVE-2026-33829 mostra que manipuladores URI podem virar ponte entre uma ação aparentemente comum no desktop e uma autenticação de rede indesejada. O uso de crumb=location: também tem precedente documentado em CVE-2023-35636, o que reforça que a classe de problema está ligada à validação de caminhos remotos e ao tratamento de localizações UNC em componentes que aceitam parâmetros vindos de URLs.

• Estáções Windows que permitem o acionamento do manipulador URI search: por links externos.
• Ambientes em que NTLM permanece habilitado para autenticação de rede.
• Hosts com saída SMB permitida para redes não confiáveis ou para a internet.
• Serviços internos vulneráveis a relay quando SMB signing não é exigido.

Hunting e telemetria

A detecção deve priorizar a correlação entre abertura de links externos, invocação do manipulador de pesquisa do Windows e conexões SMB iniciadas logo depois para destinos incomuns. Em endpoints, logs de criação de processo e eventos de shell podem indicar acionamento de esquemas URI, embora o material analisado não forneça nomes de eventos específicos. Na rede, a pista mais importante é a tentativa de autenticação NTLM ou sessão SMB de uma estáção de usuário para um endereço que não pertence a servidores de arquivos corporativos esperados.

Em proxy, e-mail e navegação, a investigação deve procurar mensagens ou páginas que tenham levado usuários a abrir URLs com search:. O conteúdo deve ser tratado como evidência, não como artefato para reprodução. Em controladores de domínio e servidores internos, a defesa deve observar tentativas de relay ou autenticações NTLM anômalas originadas após a possível exposição, especialmente quando o mesmo usuário aparece em conexões para serviços que normalmente não acessa.

• Conexões SMB de saída por TCP/445 ou TCP/139 partindo de estáções de trabalho para destinos externos ou não usuais.
• URLs contendo o esquema search: e o parâmetro crumb=location: em mensagens, páginas ou artefatos de navegação.
• Autenticações NTLM fora do padrão normal do usuário, em horários próximos ao clique suspeito.
• Tentativas de acesso a serviços internos compatíveis com relay depois da captura presumida do hash.

Mitigação

A resposta defensiva deve começar pela contenção do caminho de rede usado para vazamento. Hosts que não precisam falar SMB para fora de redes corporativas conhecidas devem ter conexões de saída por TCP/445 e TCP/139 bloqueadas. Esse controle reduz o valor de links que tentam apontar o Windows para servidores UNC controlados por terceiros. Em paralelo, a assinatura SMB deve ser exigida para diminuir a possibilidade de relay contra serviços internos, já que o hash capturado é mais perigoso quando pode ser reaproveitado contra alvos que aceitam autenticação encaminhada.

A redução de NTLM é a mitigação estrutural mais importante quando compatível com o ambiente. Onde a desativação completa não for viável, a organização deve mapear sistemas legados que ainda dependem desse mecanismo, restringir seu uso e monitorar exceções. Como a falha descrita não tinha correção disponível no momento informado, a validação deve focar controles compensatórios: egress filtering, política de autenticação, endurecimento de SMB e revisão de exposição a links vindos de e-mail ou web.

• Bloquear SMB de saída por TCP/445 e TCP/139 em estáções que não tenham necessidade explícita desse tráfego.
• Exigir SMB signing em serviços internos para reduzir viabilidade de relay com hashes Net-NTLMv2 capturados.
• Desabilitar NTLM onde possível e documentar exceções operacionais que ainda dependem dele.
• Investigar mensagens, páginas e logs de navegação que contenham search: associado a crumb=location:.
• Tratar qualquer hash exposto como credencial sensível e revisar acessos do usuário afetado após o evento.