Resumo
CVE-2025-50154 é uma vulnerabilidade do Windows File Explorer que pode expor material de autenticação confidencial na rede. A Microsoft classifica o problema como spoofing, com a fraqueza subjacente mapeada para CWE-200 (Exposição de Informações Confidenciais).
Nas configurações afetadas, o Windows Explorer pode iniciar a autenticação de rede durante o processamento de metadados relacionados a atalhos. Se o destino remoto referenciado for controlado pelo invasor, este poderá capturar o material de desafio-resposta NTLM. O que, dependendo dos controlos de segurança da organização, pode permitir abusos subsequentes, como retransmissão NTLM ou adivinhação de senhas offline.
Neste blog, exploramos o CVE-2025-50154 com base em pesquisas realizadas por estudantes de pós-graduação participantes do Programa de Bolsas de Estudo OPSWAT e fornecemos orientações práticas de mitigação para reduzir o risco de autenticação NTLM forçada.
Impacto e risco
A CVE-2025-50154 foi divulgada em 12 de agosto de 2025 e afeta várias versões suportadas do cliente e servidor Windows ( Server Windows 10/11 e Windows Server ) anteriores aos níveis de compilação corrigidos. A vulnerabilidade é classificada como CVSS v3.1 6.5 (Média).
A principal consequência para a segurança é a exposição de credenciais: um invasor pode obter material de desafio-resposta NTLM fazendo com que o Explorer autentique-se num terminal controlado pelo invasor. Dependendo do ambiente, isso pode ser usado para:
• Retransmissão NTLM (spoofing): autenticação em outros serviços como vítima quando as proteções de retransmissão estão ausentes ou mal configuradas.
• Adivinhação/quebra de senhas offline: tentativa de recuperar senhas fracas a partir de material de desafio-resposta capturado.
A viabilidade depende muito dos controlos empresariais, tais como assinatura SMB, restrições NTLM, segmentação de rede e reforço do lado do serviço.
Cenário de ataque
CVE-2025-50154 é um problema de autenticação forçada. Quando o Windows Explorer processa um atalho que faz referência a um local SMB/UNC remoto, ele pode iniciar uma ligação SMB durante a renderização normal ou a validação do caminho. Como resultado, o ponto final remoto pode receber material de troca de autenticação NTLM gerado durante a configuração da sessão.
Um cenário de ataque representativo é o seguinte:
- Preparação do invasor: o adversário controla um servidor SMB e prepara um recurso partilhado referenciado pelo atalho.
- Colocação do atalho: um ficheiro .lnk apontando para o caminho SMB controlado pelo invasor é entregue ao ambiente da vítima através de canais comuns (por exemplo, anexos de phishing, pastas sincronizadas, repositórios de ficheiros partilhados ou um ponto de apoio existente).
- Acesso acionado pelo Explorer: quando a vítima navega num diretório que contém o atalho, o Windows Explorer analisa os metadados do atalho e pode tentar resolver o destino remoto como parte do processamento rotineiro da interface do utilizador.
- Autenticação implícita: durante a configuração da sessão SMB, o Windows autentica no contexto do utilizador (frequentemente através do NTLM). A vítima não precisa de executar o destino do atalho para que a troca de autenticação ocorra.
- Resultados pós-captura (dependentes do ambiente): Dependendo dos controlos do ambiente, o material NTLM capturado pode ser aproveitado para retransmissão NTLM ou quebra de senhas offline. A viabilidade prática é influenciada por fatores como assinatura SMB, restrições NTLM e segmentação de rede.
Contexto técnico
Explorador do Windows e renderização de atalhos
O Windows Explorer (explorer.exe) é o processo do shell do Windows que enumera o conteúdo dos diretórios e renderiza a interface do usuário do File Explorer, invocando componentes do Shell (por exemplo, manipuladores de ícones/sobreposições/miniaturas) para obter e exibir ícones, sobreposições e miniaturas.
Um atalho do Windows (.lnk) não é um simples ponteiro de texto; é um formato de metadados estruturado que pode armazenar um caminho de destino (caminho local ou caminho UNC/SMB), argumentos opcionais e diretório de trabalho, além de uma referência de ícone separada. Durante a navegação normal pela pasta, o Explorer analisa os metadados do atalho para apresentá-lo na interface do usuário (por exemplo, resolvendo o ícone e validando o destino). Dependendo do destino referenciado e dos metadados relacionados, esse processamento pode fazer com que o Explorer tente acessar a rede como parte da renderização de rotina ou verificação do caminho.
Autenticação NTLM sobre SMB
No partilhamento de ficheiros do Windows, a autenticação SMB normalmente prefere Kerberos em ambientes de domínio, mas NTLM ainda pode ser negociado quando Kerberos não está disponível ou não é selecionado. NTLM é um protocolo de desafio-resposta: o cliente primeiro anuncia os recursos, o servidor retorna um desafio (nonce) e o cliente responde com uma mensagem de autenticação derivada do desafio e do segredo do utilizador, sem enviar a senha em texto simples.
Variantes NTLM e postura de segurança (NTLMv1 vs NTLMv2)
O NTLM tem várias variantes. Os ambientes Windows modernos geralmente dependem do NTLMv2 e devem evitar o LM/NTLMv1 legado sempre que possível.
O NTLMv1 tornou-se amplamente reconhecido como inseguro por várias razões importantes (criptografia fraca, chaves de baixa entropia, vulnerabilidade de retransmissão, risco de quebra offline, etc.).
Para melhorar isso, a Microsoft introduziu o NTLMv2, que fortalece o cálculo da resposta. Na prática, o NTLMv2 substitui a construção de resposta mais antiga do tipo DES por um esquema baseado em HMAC-MD5 e incorpora contexto adicional à resposta, tornando-a significativamente mais robusta do que o NTLMv1 contra várias classes de técnicas de recuperação offline.
Mesmo com o NTLMv2, as organizações devem continuar a tratar o NTLM como um protocolo de autenticação de maior risco em comparação com o Kerberos e aplicar controlos de defesa em profundidade (por exemplo, assinatura SMB e segmentação) para reduzir o raio de impacto de cenários de autenticação forçada.
Por que o NTLM continua a ser um alvo frequente
Embora o NTLM seja um protocolo de desafio-resposta, continua a ser atraente para os atacantes porque a troca de autenticação é diretamente utilizável em condições de rede hostis. Durante a configuração da sessão SMB, o terminal remoto recebe metadados de autenticação e os valores de desafio-resposta necessários para autenticar o cliente. Se um adversário puder operar o terminal de destino (por exemplo, um servidor SMB controlado pelo invasor) ou puder interceptar/encerrar a conexão em trânsito, ele poderá capturar o material de troca NTLM e tentar abusos subsequentes, como retransmissão NTLM ou adivinhação de senha offline, dependendo das proteções do ambiente.
O Windows também integra o NTLM na sua experiência de Single Sign-On (SSO). O material de credenciais derivado do segredo do utilizador é gerido pelo LSASS e pode ser usado para autenticar recursos de rede (por exemplo, partilhas SMB) sem solicitar repetidamente ao utilizador. Embora isso melhore a usabilidade, expande a superfície de ataque para cenários de autenticação forçada: quando um atalho .lnk faz referência a um caminho SMB remoto, o Windows Explorer pode iniciar uma ligação SMB durante o processamento de atalhos de rotina e negociar automaticamente a autenticação.
No contexto do CVE-2025-50154, isso significa que o material de troca de autenticação NTLM pode ser enviado para um terminal SMB controlado pelo invasor sem que a vítima execute o alvo referenciado, criando um caminho silencioso de exposição de credenciais durante a navegação normal pela pasta.
Análise técnica
Renderização do ícone do Explorer e processamento de atalhos
Quando uma pasta é aberta no Explorador de Ficheiros, o Explorador enumera o conteúdo do diretório e determina o tipo de cada item com base na sua associação de ficheiros registada (normalmente determinada pela extensão do ficheiro). O Windows utiliza então o registo da classe shell correspondente (por exemplo, através dos mapeamentos CLSID/ProgID associados no registo) para localizar o manipulador shell apropriado - normalmente um componente COM responsável pela extração e renderização do ícone. O Explorador invoca as interfaces relevantes para recuperar e exibir o ícone.
Para ficheiros .lnk (Shell Link), o Explorer normalmente não apresenta um ícone de atalho genérico por predefinição. Em vez disso, analisa os metadados do atalho, tenta resolver o destino referenciado (e as informações relacionadas com o ícone) e, em seguida, apresenta o ícone associado a esse destino resolvido.
Quando o Explorer renderiza um ficheiro .lnk, determina o ícone chamando CShellLink::GetIconLocation, que identifica de onde o ícone deve ser carregado (por exemplo, o binário de destino, um caminho de ícone explícito ou um ícone padrão do sistema). Como parte desse fluxo, o Explorer inicializa a extração do ícone (_InitExtractIcon) e, em seguida, executa a lógica de resolução principal (_GetExtractIcon), que avalia a origem do ícone (por meio de _CheckExtractLocation).
• Se o atalho especificar uma localização de ícone local (por exemplo, um executável ou DLL no disco), o Explorer carrega o ícone diretamente desse recurso.
• Se a localização do ícone for um URL remoto, o Explorer poderá descarregar o ícone para o seu cache local (por exemplo, usando URLDownloadToCacheFileW) e, em seguida, carregar o ícone a partir da cópia em cache.
• Se não houver nenhuma fonte de ícones válida disponível, o Explorer recorre a um ícone padrão fornecido pelo gestor do sistema.
Após resolver os metadados relacionados ao ícone, o Explorer prossegue através do CShellLink::Extract, que lida com o destino do atalho e conclui o fluxo de trabalho de extração. Como parte desse caminho, o Explorer invoca o CShellLink::_ShortNetTimeout para aplicar tempos limite de rede mais curtos quando o atalho faz referência a um local remoto, reduzindo os atrasos da interface do utilizador se o destino da rede estiver lento ou inacessível.
Quando o destino é identificado como um caminho de rede (UNC), o Explorer realiza a validação do destino de forma assíncrona. Ele gera um segmento de trabalho que executa o CShellLink::_VerifyPathThreadProc, que verifica se o destino referenciado existe.
Nessa rotina, o Explorer chama PathFileExistsAndAttributesW para consultar a existência do destino e os atributos básicos (por exemplo, ficheiro vs. diretório), o que, por sua vez, requer uma tentativa de acesso à rede para destinos SMB/UNC.
Causa principal da vulnerabilidade
Ao longo do fluxo de renderização de atalhos descrito acima, duas operações de saída são relevantes:
• Recuperação de ícones através de URLDownloadToCacheFileW (quando a fonte do ícone do atalho é um URL remoto).
• Validação do destino através de PathFileExistsAndAttributesW (quando o destino do atalho é um caminho UNC/SMB).
Para validar o comportamento do URLDownloadToCacheFileW, testámos a API um teste mínimo e independente.
A atividade da rede consistiu numa busca HTTP convencional e, nas nossas observações, não expôs credenciais relevantes para esta vulnerabilidade.
O comportamento mais significativo ocorre com PathFileExistsAndAttributesW quando o caminho avaliado é um destino UNC/SMB. Durante a depuração, observámos que esta verificação pode iniciar a configuração da sessão SMB e negociar a autenticação no contexto do utilizador atual.
Como o Explorer pode invocar essa validação automaticamente durante o processamento de um .lnk, um terminal SMB controlado por um invasor pode receber material de troca de autenticação NTLM sem que a vítima execute o ficheiro referenciado, criando um caminho silencioso de exposição de credenciais durante a navegação rotineira pela pasta.
Prova de Conceito
Num laboratório isolado, os participantes do nosso programa OPSWAT Fellowship validaram o CVE-2025-50154 usando um atalho (.lnk) que fazia referência a um caminho SMB/UNC remoto. Num sistema Windows vulnerável, simplesmente navegar pela pasta no Windows Explorer acionava uma conexão SMB durante o processamento normal do atalho, fazendo com que o material de troca de autenticação NTLM fosse enviado para o terminal remoto, sem que a vítima executasse o destino do atalho.
Remediação
As organizações devem garantir que os seus sistemas operacionais e aplicações sejam regularmente corrigidos e mantidos atualizados para mitigar vulnerabilidades conhecidas. Isso inclui aplicar todas as atualizações de segurança relevantes da Microsoft e verificar se todos os terminais estão a executar os níveis de compilação corrigidos e mais recentes do Windows. Paralelamente, as organizações devem reduzir a sua superfície de ataque, restringindo o acesso SMB de saída quando apropriado e reforçando os controlos de fortalecimento NTLM/SMB de acordo com o seu ambiente.
MetaDefender apoia esses esforços e ajuda a operacionalizá-los em escala, oferecendo visibilidade clara da exposição e da prontidão dos patches. Com recursos robustos de gestão de vulnerabilidades e patches que suportam mais de 1.100 aplicações,Endpoint MetaDefender Endpoint identificaEndpoint os terminais que executam versões do Windows sem patches ou desatualizadas, bem como aplicações de terceiros, e fornece as correções recomendadas.
Além disso, através da sua consola de gestão no My OPSWAT Central Management, os administradores obtêm uma visão centralizada e unificada do estado de segurança dos terminais, exposição a vulnerabilidades e gestão de patches, tudo numa única plataforma para definir e aplicar políticas de segurança em toda a organização. Os administradores também podem criar e implementar scripts personalizados nos terminais com MetaDefender Endpoint para automatizar ações de reforço relacionadas com o acesso SMB e a utilização de NTLM. Esta abordagem simplifica a aplicação da segurança, ao mesmo tempo que fornece feedback claro sobre os resultados da execução, permitindo aos administradores identificar rapidamente os terminais que podem necessitar de investigação adicional ou intervenção manual.
Endpoint MetaDefender Endpoint as equipas de segurança e TI priorizem implementações, acelerem a correção, monitorizem continuamente a postura de segurança da organização e, por fim, reduzam a exposição a vulnerabilidades e exposições comuns (CVEs), como CVE-2025-50154 e ameaças semelhantes baseadas em terminais.
