Atalhos perigosos assim os arquivos LNK podem enganar o Windows e executar malware

Há décadas que os acessos diretos .lnk fazem parte do ecossistema Windows: chegaram com Windows 95 e desde então seu formato binário cresceu em complexidade. Essa complexidade é precisamente o que um pesquisador de segurança holandês, Wietze Beukema, aproveitou para demonstrar que esses arquivos podem se tornar sofisticadas armadilhas para usuários desprevenidos.

Em uma apresentação em Wild West Hackin' Fest, Beukema descreveu várias técnicas novas que permitem criar atalhos que mostram uma coisa na janela de propriedades do Explorador do Windows, mas que, ao executá-los, lançam outra completamente diferente. O núcleo do problema é que um arquivo .lnk pode conter várias estruturas opcionais que descrevem a rota de destino, e o Windows Explorer nem sempre prioriza ou valida de forma consistente esses campos. O resultado: podem ser feitos acessos diretos que aparentam apontar para um PDF, por exemplo, e que na verdade executam PowerShell ou outras ordens maliciosas.

Entre as técnicas descritas há variantes que exploram caracteres proibidos em rotas do Windows, como aspas duplas, para construir rotas que parecem válidas a olho nu, mas que são tecnicamente inválidas. Explorer, em vez de rejeitar estes .lnk, os apresenta de forma conciliadora, mostrando a rota "falsa" enquanto ao abrir o acesso direto é executada a rota "real" oculta em outra estrutura do arquivo.

Uma das técnicas mais poderosas baseia-se em manipular a estrutura EnvironmentVariableDataBlock dentro do .lnk. Beukema demonstrou que deixando vazio o campo Unicode e preenchendo apenas a versão ANSI do destino, é possível mostrar um objetivo inocuo na interface - por exemplo, "invoice.pdf" - enquanto o conteúdo real do EnvironmentVariableDataBlock invoca comandos ou executáveis maliciosos. Além disso, nessas configurações os argumentos de linha de comandos podem ficar escondidos, o que complica ainda mais que um usuário detecte o engano simplesmente olhando as propriedades.

Beukema publicou uma análise técnica com exemplos e testes em seu blog, onde explica em detalhes como essas estruturas funcionam e porque o Explorer se comporta de forma permissiva diante de arquivos LNK mal formados: Wietze Beukema. Também libertou uma ferramenta de código aberto chamada lnk-it-up que permite gerar atalhos com essas técnicas e comparar o que mostra Explorer frente ao que é realmente executado, útil para testes e detecção: lnk-it-up no GitHub.

Quando Beukema informou a Microsoft sobre o problema relacionado com o EnvironmentVariableDataBlock (registo VULN-162145), a empresa decidiu não classificar como vulnerabilidade de segurança no seu MSRC, argumentando que sua exploração requer que o usuário execute voluntariamente um arquivo malicioso e que, portanto, não quebra os limites de segurança do sistema. Essa posição foi comunicada pela Microsoft a diversos meios, e a empresa lembrou que o Windows adverte ao tentar abrir .lnk baixados da Internet e que ferramentas como a Microsoft Defender e o Smart App Control adicionam camadas de proteção.

No entanto, a história recente mostra por que muitos pesquisadores e equipes de resposta se preocupam com os .lnk. Um erro relacionado, identificado como CVE-2025-9491, também permitia ocultar argumentos de linha de comandos e foi explorado em ataques reais durante anos. Relatórios da indústria mostraram que vários grupos, incluindo atores estatais e bandas criminosas, serviram-se desse tipo de fraquezas para implantar malware e troianos de acesso remoto. Para aprofundar o alcance das explorações, consultar a ficha pública do CVE: CVE-2025-9491 em NVD, e a análise de ameaças que documentou a atividade de vários atores: Relatório de Trend Micro.

Ante a exploração ativa de CVE-2025-9491 Microsoft terminou introduzindo mudanças no manejo de .lnk em junho de 2025 com a intenção de mitigar o vetor que estava sendo usado em ataques reais. Ainda assim, a postura de que uma técnica “require interação do usuário” continua sendo a linha oficial para classificar a gravidade, e isso deixa margem de debate sobre a obrigação de corrigir como o sistema mostra e prioriza a informação em acessos diretos.

Para qualquer utilizador ou responsável pela segurança há vários pontos práticos que convém ter em conta agora. Em primeiro lugar, os .lnk devem ser considerados arquivos potencialmente perigosos: se forem provenientes de fontes desconhecidas ou de mensagens inesperadas, a opção mais segura é não abri-los. Em segundo lugar, as soluções de detecção e a política de execução de aplicações (por exemplo, o Smart App Control) reduzem o risco, mas não o eliminam; os atacantes continuam a inventar truques para evitar controlos. Finalmente, aqueles que gerem equipamentos ou redes podem usar ferramentas como a mencionada por Beukema para analisar e detectar .lnk suspeitos em seu ambiente, sempre em laboratórios controlados e não em sistemas de produção.

O caso dos acessos diretos .lnk é um bom lembrete de que os vetores de ataque nem sempre passam por e-mails com anexos .exe nem por documentos macros: às vezes a exploração é mais sutil e aproveita comportamentos permissivos do próprio sistema operacional. A combinação de engenharia social (convencer alguém de clicar) e uma implementação indulgente no software dá lugar a armadilhas difíceis de detectar a simples vista.

Se você quer aprofundar os testes técnicos e experimentar com os exemplos, verifique o material publicado por Beukema e usa sua ferramenta em um ambiente isolado: entrada técnica e repositório lnk-it-up. Para entender o contexto histórico e as campanhas que abusaram de falhas semelhantes, as informações coletadas na base de dados NVD e os relatórios de empresas de segurança como a Trend Micro fornecem exemplos concretos de exploração: NVD e análise de Trend Micro.

Em suma, não é uma má ideia rever as práticas de segurança na organização e lembrar aos usuários que as advertências do sistema não são meras formalidades: muitas campanhas bem-sucedidas têm prosperado porque as pessoas clicam sem pensar. Os atalhos do Windows, por muito inocentes que pareçam, continuam a ser um vetor útil para os atacantes e merecem atenção por parte de equipes de segurança e usuários finais.