O que é DLL hijacking e por que seu novo plugin de IA pode ser a forma mais fácil de entrar

Passei muito tempo este ano analisando como as organizações estão integrando AI em ferramentas que nunca foram feitas para isso. A maior parte do risco é discutida em termos de exposição de dados ou comportamento do modelo. Menos atenção é dada a algo mais básico: o próprio processo de instalação. Quando uma equipe adiciona um plugin AI a um aplicativo desktop legado, geralmente está adicionando um novo executável, um novo conjunto de dependências e uma nova série de pastas que o Windows procura quando o aplicativo tenta carregar uma DLL. Essa é uma configuração familiar para quem acompanha o sequestro de DLLs ao longo dos anos, e está se tornando mais comum.

O que é DLL hijacking

Aplicações Windows nem sempre carregam suas DLLs de um local fixo e confiável. Quando um aplicativo solicita uma DLL pelo nome em vez do caminho completo, o Windows procura em uma ordem definida de diretórios para encontrá-la. Se um invasor conseguir colocar uma DLL maliciosa com o nome correto em algum lugar antes nessa ordem de busca, o aplicativo carrega o código do invasor em vez da biblioteca legítima, e faz isso com os privilégios que o aplicativo já possui.

Esta não é uma técnica nova. É uma vulnerabilidade documentada há anos e continua funcionando porque muitos aplicativos de desktop, especialmente os mais antigos ou mal projetados, ainda carregam DLLs pelo nome em vez do caminho completo. O que mudou foi a superfície de ataque. Cada plugin, complemento ou extensão com IA instalada em um aplicativo legado é uma nova oportunidade para uma pasta pouco controlada, uma dependência não assinada ou um diretório gravável no caminho de pesquisa.

Exemplo de sequestro de DLL

Imagine uma equipe de engenharia usando um aplicativo CAD que está em uso há uma década. A TI adiciona um plugin de IA que oferece aos usuários uma camada inteligente de busca e resumo sobre seus desenhos. Como muitos softwares nessa categoria, o aplicativo CAD carrega uma de suas DLLs auxiliares pelo nome, em vez do caminho completo, uma decisão de design que ninguém questionou porque nunca causou um problema visível.

Um atacante com acesso mesmo que limitado àquela máquina, por phishing, uma conta comprometida ou outro ponto de apoio, não precisa quebrar o plugin AI em si. Ele só precisa colocar um DLL com o mesmo nome de arquivo em uma pasta que fique antes na ordem de busca do app. Na próxima vez que um usuário iniciar o app, ele carrega o DLL do atacante, e o código malicioso roda com os mesmos privilégios da aplicação CAD. Nenhuma exploração contra o plugin AI é necessária. O plugin simplesmente deu ao atacante uma nova pasta para trabalhar.

Como detectar o sequestro de DLL

A detecção geralmente consiste em observar comportamentos que não correspondem ao que uma DLL legítima deveria fazer:

• Aplicações que carregam DLLs pelo nome de diretórios incomuns ou editáveis pelo usuário em vez de um caminho totalmente qualificado e confiável
• DLLs não assinadas lançadas por utilitários como rundll32.exe, um padrão comum de sequestro
• Monitoramento da integridade de arquivos sinalizando alterações em DLLs que não deveriam mudar entre ciclos de patch
• Logs de Endpoint mostrando um processo pai legítimo seguido por um carregamento inesperado ou não assinado de DLL

Outra forma é verificar a integridade de qualquer DLL no caminho de busca (na verdade, a integridade de todos os arquivos) comparando seus valores hash com uma fonte confiável conhecida.

Nada disso é exótico. É a mesma disciplina que as equipes de segurança já aplicam à integridade de arquivos e ao monitoramento de processos, direcionada especificamente às pastas onde plugins de terceiros e aplicativos legados tendem a introduzir comportamento fraco na ordem de carregamento.

Como prevenir o sequestro de DLL

A prevenção geralmente se divide em duas categorias: corrigir os aplicativos e controlar o que é permitido executar no endpoint.

Corrigir o aplicativo significa usar caminhos totalmente qualificados para carregamento de DLLs, restringir permissões de pastas para que usuários padrão não possam gravar nos diretórios que o aplicativo procura, e manter o software do fornecedor atualizado. Essa é a correção correta a longo prazo, mas depende de cada fornecedor fazer o trabalho, e muitas das aplicações mais expostas a esse problema são exatamente as que têm menos probabilidade de serem atualizadas rapidamente.

Controlar o endpoint significa não depender do fornecedor. PolicyPakDLL Hijack Protection do PolicyPak, parte do Least Privilege Manager, opera em três modos: auditoria, que registra carregamentos de DLL arriscados sem bloqueá-los para que as equipes possam avaliar a exposição primeiro; safe elevated, que bloqueia o carregamento de DLL arriscadas para processos elevados; e anti-hijack, que estende esse bloqueio para processos regulares executados em locais protegidos como Program Files. Ele para diretamente os dois padrões de sequestro mais comuns: um aplicativo carregando uma DLL por um nome não qualificado em vez de um caminho completo, e uma DLL não assinada lançada por meio de uma ferramenta como rundll32.exe. Quando uma DLL legítima é bloqueada por engano, os administradores podem liberá-la por caminho de arquivo, assinatura digital ou hash do arquivo sem desativar completamente a proteção.

Se sua equipe está implementando capacidades de IA em aplicativos anteriores a esta conversa, o sequestro de DLL merece um lugar no registro de riscos, não como uma hipótese, mas como uma consequência de curto prazo de como esses plugins são instalados.