Abuso de DLLs continua relevante em cadeias de ataque no Windows

Técnica explora a ordem de busca de bibliotecas para executar código malicioso por meio de aplicativos legítimos, com uso recorrente para evasão, persistência e elevação de privilégio.

Componente	Carregamento dinâmico de DLLs em aplicativos Windows, incluindo bibliotecas como dbgeng.dll, jli.dll, lbtserv.dll e version.dll em casos analisados.
Vetor	Posicionamento de uma DLL maliciosa em local consultado pelo carregador, frequentemente junto de um executável benigno empacotado no mesmo diretório.
Impacto	Execução de código no contexto de um processo aparentemente legítimo, com uso documentado para evasão, persistência e, quando o processo possui permissões superiores, elevação de privilégio.
Prioridade	Reduzir dependência de reputação do executável, revisar cargas de DLL sem assinatura esperada, impor caminhos qualificados e validar assinatura ou cadeia interna de confiança quando aplicável.
Artefatos	Casos analisados envolveram abuso de aplicativos de fornecedores conhecidos, produtos de segurança, componentes do Windows e binários antigos como java-rmi.exe.
Mitigação	Aplicações devem evitar busca implícita em diretórios inseguros, usar SetDllDirectory, SetSearchPathMode, LoadLibraryEx e validação criptográfica quando o modelo de distribuição permitir.

Resumo técnico

O abuso de DLLs permanece uma técnica relevante em ambientes Windows porque aproveita uma característica central do carregamento dinâmico de bibliotecas: quando um aplicativo declara ou solicita uma dependência, o sistema precisa localizar um arquivo com o nome esperado e carregá-lo no processo. Em muitos fluxos, a decisão de carga é influenciada por ordem de busca, diretório de execução, manifesto, caminhos relativos e chamadas feitas pela própria aplicação. Quando um operador consegue colocar uma biblioteca maliciosa em um ponto consultado antes da biblioteca legítima, o processo benigno passa a executar código não previsto sem que o binário principal precise ser modificado.

A técnica aparece em diferentes variações chamadas de DLL hijacking ou DLL sideloading, termos que nem sempre são usados de forma idêntica. Em uma leitura prática para defesa, o ponto comum é o abuso de uma relação de confiança entre um executável legítimo e uma biblioteca carregada em tempo de execução. O caso mais frequente nos conjuntos analisados foi o empacotamento de um aplicativo conhecido com uma DLL maliciosa no mesmo diretório, seguido da execução do binário legítimo. Essa forma reduz a necessidade de explorar uma vulnerabilidade tradicional e transfere parte da detecção para o comportamento do processo, da biblioteca carregada e do caminho de arquivo utilizado.

O valor ofensivo decorre de três objetivos técnicos principais. O primeiro é evasão, porque o código passa a rodar dentro de uma imagem de processo derivada de um executável com reputação aparentemente confiável. O segundo é persistência, quando o aplicativo escolhido é iniciado com frequência pelo usuário ou pelo sistema. O terceiro é elevação de privilégio condicionada, quando o processo hospedeiro possui permissões, acesso a objetos protegidos ou exceções internas que um processo comum não teria. Esses impactos não significam, por si só, vazamento de dados ou movimentação lateral; eles indicam execução de código em contexto mais vantajoso para o operador.

Fluxo técnico

O fluxo mais observado começa com a seleção de um executável que carrega bibliotecas por nome, sem validação suficiente de origem, assinatura ou caminho absoluto. O operador distribui esse executável junto de uma DLL construída para satisfazer a expectativa do carregador, mas com lógica maliciosa acoplada. Quando o aplicativo é iniciado, a biblioteca colocada no diretório consultado é carregada antes da dependência legítima ou no lugar dela. O processo resultante pode continuar parecendo associado ao fornecedor original, embora a lógica executada já tenha sido alterada pela DLL controlada pelo atacante.

A escolha do executável não é aleatória. O material analisado mostra interesse recorrente por aplicativos com aparência confiável, incluindo produtos associados a fornecedores populares como Google, Microsoft e Adobe, além de produtos de segurança e componentes amplamente encontrados em máquinas Windows. Essa escolha explora a tendência operacional de algumas defesas de atribuir peso excessivo à reputação do binário principal. Quando a detecção observa apenas nome, assinatura ou prevalência do executável, a carga maliciosa dentro do processo pode ficar subavaliada. A defesa precisa tratar o conjunto processo-biblioteca-caminho-assinatura como uma unidade de análise, não como eventos isolados.

A estrutura interna das DLLs maliciosas também fornece sinais defensivos. Foram observadas bibliotecas com número reduzido de exports, exports distintos apontando para a mesma função, muitas funções redirecionadas para uma mesma rotina maliciosa e exports que apontam para stubs nulos. Em outro caso, uma biblioteca nomeada como version.dll usava uma chamada com grafia sutilmente alterada, vresion, em vez de version. Esses padrões não são prova universal de abuso, mas são bons indicadores para engenharia reversa, classificação de amostras e criação de hipóteses de hunting quando aparecem em bibliotecas que se dizem equivalentes a componentes conhecidos.

O uso de ofuscação também tende a ter limitações específicas em DLLs. Como há menos suporte direto para empacotadores e criptadores em alguns fluxos de construção de bibliotecas, operadores podem recorrer a rotinas simples, como laços de XOR, para ocultar dados ou trechos de código. Para defesa, isso reforça a importância de combinar análise estática, metadados de exportação, assinatura digital, hashes esperados e comportamento em execução. Uma DLL que apresenta editor, versão ou nome coerente com uma biblioteca legítima, mas diverge em assinatura, hash ou estrutura de exports, merece investigação.

Superfície afetada

A superfície exposta inclui aplicações que dependem de bibliotecas carregadas por nome simples, usam diretórios relativos ou mantêm DLLs próprias no mesmo local do executável sem validação criptográfica. Também entram no escopo binários antigos, ferramentas deixadas por runtimes obsoletos, componentes auxiliares de produtos de segurança e cópias de executáveis do Windows empacotadas fora de seus locais esperados. O exemplo de java-rmi.exe, associado ao Java 6 e removido de versões futuras após histórico de bug e fim de vida pública, ilustra como binários legados podem continuar úteis para abuso quando são transportados pelo próprio operador.

Ambientes corporativos ficam mais expostos quando controles de allow-list, EDR ou proxy de execução tratam o executável principal como suficiente para estabelecer confiança. A técnica também afeta times de desenvolvimento que distribuem aplicações com ecossistema próprio de DLLs, mas sem um vínculo verificável entre executável e biblioteca. Quando a biblioteca customizada deve estar no mesmo diretório da aplicação, apenas conferir o caminho não resolve o problema, porque a DLL maliciosa pode estar exatamente no local esperado. Nesse cenário, o controle precisa validar identidade, integridade e compatibilidade da biblioteca antes da carga.

• Aplicativos Windows que chamam bibliotecas por nome simples e dependem da ordem padrão de busca.
• Executáveis legítimos empacotados com DLLs maliciosas no mesmo diretório.
• Produtos conhecidos, componentes de segurança, binários antigos e cópias de ferramentas do sistema usadas fora do local esperado.
• Bibliotecas com assinatura ausente, assinatura divergente, hash inesperado ou metadados incompatíveis com a versão declarada.

Hunting e telemetria

A investigação defensiva deve começar pela relação entre processo e módulo carregado. Eventos de carga de DLL precisam ser correlacionados com caminho do executável, diretório de trabalho, editor assinado do binário principal, assinatura da biblioteca, hash, metadados de versão e prevalência no ambiente. Um processo benigno que carrega uma DLL sem assinatura conhecida a partir do próprio diretório de execução é um sinal relevante, especialmente quando o mesmo executável normalmente carrega bibliotecas de diretórios do sistema ou de caminhos de instalação controlados.

Outra linha de hunting é procurar falhas de resolução de bibliotecas durante testes de aplicações internas. Ferramentas de monitoramento de processos podem revelar tentativas de abrir arquivos .dll inexistentes em diretórios consultados pelo carregador. Esse tipo de evento indica oportunidade de hijacking se um arquivo com o nome esperado puder ser plantado naquele local. Embora esse método não escale perfeitamente para todos os binários e ambientes, ele ajuda equipes de AppSec e engenharia a identificar aplicações que precisam de ajuste antes de serem distribuídas em escala.

Para operações de detecção, repositórios de conhecimento sobre DLLs passíveis de hijacking podem apoiar consultas por nome de biblioteca, versão esperada, assinatura e editor. A busca não deve se limitar ao nome do executável abusado, porque operadores podem alternar o binário hospedeiro ao longo de campanhas. A telemetria mais útil combina criação de arquivo, carga de módulo, execução de processo, alteração de diretório, origem do arquivo e divergência entre metadados declarados e assinatura real. Em endpoints, a prioridade é identificar a quebra de coerência entre um processo confiável e uma biblioteca que não pertence ao ecossistema esperado.

• Processo assinado ou conhecido carregando DLL sem assinatura esperada a partir do mesmo diretório.
• Eventos de busca por .dll com resultado de arquivo ausente durante execução de aplicativos internos.
• DLL com publisher ou versão declarada compatível com biblioteca legítima, mas com hash modificado ou assinatura ausente.
• Exports numerosos apontando para uma única rotina, stubs nulos em massa ou divergências sutis em nomes de função.
• Cópias de binários do Windows, runtimes antigos ou produtos de terceiros executadas fora de diretórios normais de instalação.

Mitigação

A mitigação precisa ser dividida entre desenvolvimento de software e operação de segurança. Para desenvolvedores, a primeira medida é reduzir dependência da ordem padrão de busca. Chamadas como SetDllDirectory podem remover o diretório atual do caminho de busca, enquanto SetSearchPathMode pode empurrar esse diretório para uma posição menos privilegiada. Quando bibliotecas precisam ser carregadas em tempo de execução, o uso de caminhos totalmente qualificados em LoadLibrary ou opções específicas de LoadLibraryEx reduz a ambiguidade. Essas medidas não eliminam todos os cenários, mas tornam mais difícil substituir uma dependência apenas posicionando um arquivo no diretório conveniente.

Quando a aplicação controla seu próprio conjunto de bibliotecas, a validação de assinatura ou de uma cadeia interna de confiança é mais robusta do que confiar apenas no caminho. O contexto analisado descreve a possibilidade de assinar uma DLL com chave privada de um certificado autoassinado e publicar o certificado junto ao componente, permitindo que o executável verifique a integridade antes da carga. Esse modelo não tem o mesmo alcance de uma cadeia pública baseada em autoridade certificadora, e não impede que um operador crie outro executável malicioso, mas ajuda a vincular uma aplicação legítima às DLLs que ela espera carregar.

Para equipes de defesa, a resposta deve priorizar inventário, detecção comportamental e endurecimento de exceções. Regras de confiança baseadas apenas no nome ou reputação do executável devem ser revistas, especialmente para processos que carregam módulos de diretórios graváveis por usuário ou de locais temporários. Quando um alerta indicar hijacking, a contenção deve coletar o executável hospedeiro, a DLL carregada, árvore de processos, origem do arquivo, eventos de criação e qualquer mecanismo que dispare a execução recorrente. A remediação deve remover os artefatos maliciosos, corrigir a aplicação vulnerável ao carregamento inseguro e revalidar se a carga de bibliotecas ocorre de caminhos e assinaturas esperados.

• Revisar aplicações que carregam DLLs por nome simples e substituir por caminhos qualificados quando viável.
• Aplicar validação de assinatura ou cadeia interna de confiança para bibliotecas próprias distribuídas com a aplicação.
• Alertar para DLLs sem assinatura esperada carregadas pelo diretório do executável ou por locais graváveis.
• Evitar allow-list baseada somente no executável principal; incluir bibliotecas carregadas, caminho e comportamento.
• Investigar binários antigos ou fora de suporte empacotados com bibliotecas no mesmo diretório.
• Após correção, validar em telemetria que o processo carrega apenas DLLs de locais e identidades esperadas.