Internet Shortcut Files Remote Code Execution Vulnerability

Falha de controle externo de nome/caminho de arquivo (CWE-73) em Internet Shortcut Files (.url) do Windows, que permite a um atacante remoto executar código arbitrário quando a vítima abre um arquivo .url malicioso. A gravidade real está em como ela foi usada: o grupo de espionagem Stealth Falcon a explorou como zero-day desde março de 2025 contra alvos de defesa e governo no Oriente Médio, o que levou a CISA a incluí-la no catálogo KEV com prazo de correção em 01/07/2025.

O vetor é o parâmetro WorkingDirectory de um arquivo Internet Shortcut (.url). O campo URL do atalho aponta para um binário legítimo do Windows — no caso documentado, iediagcmd.exe, a ferramenta de diagnóstico do Internet Explorer que, ao ser executada, dispara subprocessos auxiliares (ipconfig.exe, netsh.exe, route.exe) via a função .NET Process.Start(). Essa função resolve o executável primeiro no diretório de trabalho atual do processo chamador, e só depois em locais padrão como System32.

O problema é que o WorkingDirectory do .url pode ser definido para um caminho UNC de um servidor WebDAV controlado pelo atacante (formato \\host@porta\DavWWWRoot\...). Quando o binário legítimo tenta localizar seus subprocessos, o Process.Start() busca primeiro nesse diretório de trabalho remoto e executa o binário malicioso hospedado ali (por exemplo, um route.exe falso) em vez do executável legítimo do System32. Isso caracteriza um sequestro de caminho de busca (search-order hijacking) disparado remotamente, sem gravar nada localmente antes da execução — o payload roda diretamente do compartilhamento WebDAV.

O atacante controla o conteúdo do arquivo .url (URL, WorkingDirectory, ShowCommand, IconFile) e o conteúdo do servidor WebDAV remoto onde hospeda os executáveis maliciosos com os nomes esperados pelas ferramentas legítimas. A Check Point também observou indícios de que CustomShellHost.exe pode ser abusado de forma similar para gerar explorer.exe a partir do diretório de trabalho controlado, sugerindo que o binário vulnerável a esse padrão de busca não é único.

A exploração documentada começou com um arquivo .url disfarçado de PDF (nome traduzido: 'RELATÓRIO DE DANO DE MASTRO TELESCÓPICO.pdf.url'), enviado por e-mail de phishing para uma empresa de defesa turca, provavelmente dentro de um anexo compactado. A Microsoft descreve o pré-requisito central: a vítima precisa clicar em uma URL/arquivo especialmente criado (UI:R no vetor CVSS) — não há execução sem interação do usuário. Não é necessária autenticação (PR:N) e o ataque ocorre pela rede (AV:N), mas depende do usuário abrir o atalho.

Ao clicar, o Windows executa o .url, que invoca iediagcmd.exe com o diretório de trabalho redirecionado para o servidor WebDAV do atacante; a cadeia de execução resultante carrega, no caso analisado pela Check Point, um loader multi-estágio ('Horus Loader', protegido com Code Virtualizer, uma versão mais leve do Themida) que por sua vez instala o implante 'Horus Agent', um agente C++ customizado para o framework Mythic C2, com capacidade de fingerprinting de sistema, injeção de shellcode, operações de arquivo e mudança de configuração. O grupo também usou ferramentas pós-exploração como dumper de credenciais de DC, keylogger e backdoor passivo.

A Check Point atribui a campanha ao Stealth Falcon (também conhecido como FruityArmor), ativo desde 2012, com foco em espionagem contra governos e setor de defesa na Turquia, Catar, Egito e Iêmen. A própria Check Point observa que as tentativas de ataque analisadas podem não ter sido bem-sucedidas, mas confirma que a vulnerabilidade é real e foi ativamente explorada como zero-day antes da correção. Após a divulgação pública, surgiram PoC e módulo Metasploit, o que baixa a barreira técnica para replicação por outros atores.

A mitigação primária é aplicar as atualizações de segurança de junho de 2025 (Patch Tuesday), quando a Microsoft corrigiu a falha após divulgação responsável da Check Point. As fontes consultadas não trazem números de KB ou builds específicos por versão do Windows — confirme a atualização exata para cada versão listada (Windows 10 1507/1607/1809/21H2/22H2 e Windows 11 22H2/22H3/23H2) diretamente no MSRC antes de considerar o ambiente corrigido.

Se a atualização não puder ser aplicada imediatamente, o controle compensatório real é reduzir a superfície de ataque do WebDAV: bloquear ou monitorar de perto tráfego de saída do WebClient (serviço WebDAV) para destinos desconhecidos, e, em ambientes onde WebDAV não é necessário, desabilitar o serviço WebClient — isso corta o vetor de execução via caminho UNC remoto usado no exploit. Filtragem de e-mail para bloquear ou colocar em quarentena arquivos .url anexados (inclusive dentro de arquivos compactados) também reduz a exposição ao vetor de entrega observado.

Renomear a extensão .url ou apenas orientar usuários a 'não clicar em links suspeitos' não é mitigação eficaz: o arquivo é reconhecido pelo Windows independente da extensão exibida, e o clique único já é suficiente para disparar a cadeia. Organizações federais dos EUA sob BOD 22-01 tinham prazo até 01/07/2025 para corrigir, conforme entrada no catálogo KEV da CISA — um bom proxy de urgência para qualquer ambiente crítico, independente de jurisdição.

Monitorar tráfego de saída do WebClient/WebDAV para hosts externos desconhecidos é o sinal mais direto: a exploração depende de uma conexão UNC no formato \\host@porta\DavWWWRoot\... para um servidor controlado pelo atacante. Em logs de e-mail/gateway, procurar por anexos .url (inclusive dentro de arquivos compactados) com conteúdo InternetShortcut cujo campo WorkingDirectory aponte para um caminho UNC remoto em vez de um diretório local — esse é o indicador estrutural do exploit, visível se o conteúdo do .url for inspecionado antes da entrega.

No endpoint, execuções anômalas de binários legítimos como iediagcmd.exe (ou de utilitários como route.exe, ipconfig.exe, netsh.exe) originadas de um caminho de rede em vez do diretório System32 são um forte indício de exploração ativa; da mesma forma, CustomShellHost.exe gerando explorer.exe a partir de um diretório de trabalho não padrão. Não há assinatura de rede única e confiável além do padrão de acesso WebDAV, já que a técnica reutiliza binários e protocolos legítimos do sistema — isso limita a eficácia de detecção baseada apenas em assinatura e reforça a importância de monitorar comportamento de processo e origem do diretório de trabalho.