O sequestro de ordem de busca de DLL continua relevante em ambientes corporativos modernos porque:

• Abusa de binários legítimos e fluxos de execução confiáveis.
• Frequentemente contorna a detecção baseada em assinaturas.
• Pode operar em ambientes com EDR e controle de aplicativos.
• Permite escalação confiável de privilégios.
• Suporta cenários de ataque de supply-chain e engenharia social.

Esta técnica é mapeada para o MITRE ATT&CK:

• T1574 (Sequestro de Fluxo de Execução)
• T1574.001 (Sequestro de Ordem de Busca de DLL)

⸻

Objetivos da Pesquisa

Este repositório visa:

1. Documentar o comportamento técnico do instalador vulnerável.
2. Analisar o comportamento de resolução e carregamento de bibliotecas.
3. Identificar a causa raiz e os padrões inseguros de carregamento.
4. Fornecer uma PoC mínima demonstrando execução de código.
5. Explorar estratégias de detecção e telemetria.
6. Apoiar cenários de simulação de adversários e BAS.
7. Contribuir para a pesquisa e conscientização defensiva.

Isto não se destina a fornecer exploração armamentizada.

⸻

Prova de Conceito

A PoC incluída demonstra que uma DLL maliciosa pode ser carregada durante a instalação. Em vez de executar um payload prejudicial, a DLL cria um arquivo marcador benigno no diretório temporário para confirmar a execução de código.

A PoC:

• Gera uma DLL maliciosa.
• Coloca-a ao lado do instalador vulnerável.
• Executa o instalador.
• Verifica a execução bem-sucedida por meio da criação de artefatos.

Esta abordagem permite validação segura em ambientes controlados.

⸻

Contexto Técnico

O Windows resolve DLLs usando uma ordem de busca quando uma biblioteca é referenciada sem um caminho absoluto. A ordem normalmente inclui:

1. Diretório do aplicativo
2. Diretórios do sistema
3. Caminhos de ambiente
4. Diretório de trabalho atual

Se o aplicativo usa funções de carregamento inseguras (por exemplo, comportamento padrão do LoadLibrary), os atacantes podem influenciar a resolução.

Causas comuns incluem:

• Caminhos relativos
• Falta de validação de integridade
• Dependências legadas
• Uso inseguro de APIs
• Ausência de flags seguras de carregamento de DLL

⸻

Modelo de Ameaça

Cenários típicos de ataque incluem:

• Comprometimento de supply-chain
• Distribuição por engenharia social
• Empacotamento de software
• USB ou mídia removível
• Persistência local via software confiável

O objetivo do atacante é obter execução em um contexto privilegiado.

⸻

Oportunidades de Detecção

Os defensores podem detectar esta classe de atividade monitorando:

• Carregamentos de DLL de diretórios não padronizados
• Bibliotecas não assinadas ou não confiáveis
• Manipulação suspeita do diretório de trabalho
• Processos elevados carregando dependências inesperadas
• Carregamentos de bibliotecas originados de caminhos controlados pelo usuário

Fontes de telemetria relevantes incluem:

• Sysmon
• ETW
• Sinais comportamentais de EDR
• Rastreamento de processos e carregamento de módulos

⸻

Mitigações Defensivas

Controles recomendados:

• Aplicar SafeDllSearchMode
• Usar caminhos absolutos para bibliotecas
• Validar assinaturas digitais
• Reforçar fluxos de trabalho de instalação
• Restringir acesso de escrita a diretórios executáveis
• Monitorar cadeias de execução privilegiadas

⸻

Roteiro de Pesquisa

Trabalhos futuros podem incluir:

• Engenharia reversa estática e dinâmica do instalador
• Rastreamento de dependências e diffing de patches
• Identificação de módulos vulneráveis adicionais
• Comparação com vulnerabilidades semelhantes em instaladores
• Desenvolvimento de cenários BAS para validação
• Engenharia de detecção e desenvolvimento de regras

⸻

Uso Responsável

Este repositório é fornecido para pesquisa e segurança defensiva. Deve ser usado apenas em ambientes autorizados e condições controladas de laboratório.

⸻

Aviso Legal

O autor não é responsável pelo uso indevido deste material. Os usuários são responsáveis por garantir conformidade legal e ética.

⸻

Como Executar a Prova de Conceito

Esta PoC foi projetada para ser executada apenas em um ambiente de teste isolado e autorizado. Não a execute em sistemas de produção.

Requisitos

Antes de executar a PoC, garanta o seguinte:

• Um ambiente de teste Windows (máquina virtual recomendada).
• O instalador vulnerável: M-Track Duo HD 1.0.0.
• Python 3 instalado.
• Privilégios de administrador.
• Antivírus ou EDR desabilitado ou configurado para permitir testes controlados.
• O sistema não deve conter dados sensíveis ou de produção.

Um snapshot descartável da VM é fortemente recomendado.

Passo 1 – Preparar o Ambiente

Crie um diretório de trabalho limpo e copie o instalador vulnerável para ele.

Exemplo:

C:\lab\cve-2026-25676\

Coloque o instalador nesta pasta.

Passo 2 – Configurar a DLL Embutida

O script da PoC contém uma DLL embutida codificada em base64. Antes da execução:

1. Compile o código-fonte da DLL fornecido usando um toolchain compatível com Windows (como MinGW).
2. Codifique a DLL gerada em base64.
3. Substitua o espaço reservado dentro do script.

Esta DLL é intencionalmente benigna. Ela apenas cria um arquivo marcador para demonstrar a execução de código.

⸻

Passo 3 – Executar o Script

Execute a PoC:

python poc_cve-2026-25676.py <caminho_para_instalador> [nome_dll]

exemplo:

python poc_cve-2026-25676.py M-Track_Duo_HD_1.0.0.exe version.dll

Se o instalador exigir elevação, aceite o prompt do UAC.

Passo 4 – Validar a Execução

Se a vulnerabilidade for acionada com sucesso, a DLL maliciosa será carregada durante o processo de instalação. A PoC criará um arquivo marcador:

%TEMP%\poc_cve-2026-25676.txt

A presença deste arquivo confirma que a execução de código ocorreu no contexto do instalador.

⸻

Passo 5 – Solução de Problemas

Se o arquivo marcador não for criado, considere o seguinte:

• O nome da DLL pode não corresponder à dependência esperada.
• O instalador pode não carregar a biblioteca alvo.
• Incompatibilidade de arquitetura (32 bits vs 64 bits).
• Controles de segurança bloqueando a execução da DLL.
• O diretório de trabalho pode não influenciar o caminho de busca.
• O instalador pode usar mecanismos seguros de carregamento.

Pode ser necessária uma análise adicional das dependências da biblioteca.

⸻

Passo 6 – Limpeza

O script tenta remover a DLL gerada automaticamente. No entanto, a limpeza manual é recomendada para restaurar o ambiente de teste.

Reverter o snapshot da VM após o teste é a opção mais segura.