Família de empacotadores maliciosos baseada em NSIS dificulta análise estática de amostras

A técnica usa instaladores NSIS, arquivos criptografados, DLLs de plugin e shellcode para ocultar cargas maliciosas e exigir desempacotamento antes da extração de configuração.

Componente	Família de empacotadores maliciosos baseada em NSIS, com instaladores autoextraíveis, arquivos criptografados, DLLs em $PLUGINSDIR, variantes em executável e shellcode embutido ou armazenado em recurso RT_RCDATA.
Vetor	A amostra é distribuída como pacote NSIS aparentemente semelhante a um instalador legítimo; o script extrai arquivos para diretório temporário e chama uma função exportada por DLL maliciosa ou aciona um executável por ExecWait.
Impacto	O empacotamento impede classificação estática direta, oculta payloads e configuração, aumenta custo de sandboxing e exige reconstrução do fluxo de descriptografia para obter a carga final.
Prioridade	Priorizar extração controlada do pacote, identificação de DLLs ou executáveis invocados pelo script NSIS, recuperação defensiva de artefatos criptografados e validação em ambiente isolado.
Artefatos	Estruturas recorrentes incluem dois arquivos binários com dados criptografados no diretório raiz, DLL chamada Loader.dll em algumas amostras, caminho PDB com o mesmo nome e funções exportadas chamadas pelo script.
Variações	Foram observadas variantes com shellcode em arquivo separado, shellcode embutido na DLL, substituição da DLL por executável, uso de recurso RT_RCDATA e uma variante com payload criptografado por RC4.

Resumo técnico

A família analisada usa o Nullsoft Scriptable Install System como camada de empacotamento para amostras maliciosas. O pacote NSIS funciona como arquivo autoextraível com linguagem própria de instalação, o que permite misturar compressão, extração de arquivos, lógica de script e chamada de plugins. Em uma instalação legítima, esse mecanismo simplifica distribuição de software. No uso malicioso descrito, ele cria uma superfície que parece compatível com instaladores comuns, mas carrega arquivos criptografados, código auxiliar e uma etapa de execução destinada a revelar o payload real apenas depois de uma sequência interna de descriptografia.

O objetivo operacional do empacotador é dificultar detecção e análise estática. Como o NSIS já oferece compressão, o desenvolvedor da ameaça não precisa implementar uma camada própria de arquivamento. A complexidade aparece na divisão da carga entre script, arquivos criptografados, DLL de plugin e shellcode. Isso atrasa a classificação por antivírus, prejudica extração direta de configuração e força analistas a identificar primeiro o método de desempacotamento. O contexto também indica que a família é ampla, conhecida pelo menos desde 2016, e foi observada em campanhas envolvendo XLoader, além de outras famílias de malware não nomeadas no material recebido.

A análise defensiva tem dois problemas principais. O primeiro é que a execução em sandbox, seguida de coleta de dumps de memória, pode consumir tempo e recursos, além de gerar dumps que nem sempre podem ser executados novamente para inspeção profunda. O segundo é que cada amostra pode usar uma sequência própria de operações para descriptografar o payload. Mesmo quando a cifra é simples, a automação precisa recuperar a chave, localizar o shellcode, compreender a rotina de transformação byte a byte e aplicar a mesma lógica sobre o arquivo criptografado. Portanto, a investigação não se limita a abrir o instalador; ela depende de reconstrução controlada da cadeia de carregamento.

Fluxo técnico

Na variante principal, o pacote contém dois arquivos binários criptografados no diretório raiz e uma DLL colocada em $PLUGINSDIR. Essa pasta é relevante porque o NSIS permite uso de plugins por DLL, e o script do instalador consegue chamar funções exportadas por esses plugins. A DLL maliciosa se disfarça como componente desse mecanismo. O script observado tem papel reduzido, mas decisivo: extrai arquivos, coloca dados em um diretório temporário e aciona uma função da DLL. Em uma amostra, a função exportada chamada era HvDeclY; esse nome deve ser tratado como artefato de uma amostra, não como identificador universal da família.

Depois da chamada, a DLL lê o menor arquivo criptografado, cujo nome fica codificado no próprio binário. A descriptografia inicial usa operação XOR com uma chave textual. Em algumas variantes, antes do XOR, cada byte passa por deslocamento cíclico. O resultado dessa etapa é um shellcode independente de posição. Esse shellcode inicializa o nome do arquivo que contém o payload criptografado, resolve funções da API do Windows e então lê e descriptografa a carga principal. Em vez de armazenar nomes de APIs em claro, o loader guarda hashes de 4 bytes e percorre a tabela de exportação de kernel32.dll, calculando hashes de nomes de funções até encontrar os endereços necessários.

A etapa mais variável está na descriptografia do payload. As amostras analisadas usam uma sequência própria de operações sobre o byte corrente e o índice do buffer. O conjunto citado inclui operações como not, dec, inc, sar, shl, or, add, sub, neg, xor e movzx. Isso significa que uma ferramenta defensiva não pode assumir uma fórmula fixa para todas as amostras. Ela precisa localizar o trecho da rotina, filtrar instruções relevantes sobre registradores como EAX e ECX, mapear acessos de memória para variáveis equivalentes ao byte atual e ao índice, e então emular essa sequência para recuperar a carga.

Outras variantes alteram o local onde o shellcode fica armazenado, mas preservam a lógica geral de carregamento. Em uma delas, o shellcode não aparece como arquivo separado; ele é embutido diretamente na DLL e carregado em um array na pilha. Em outra, o plugin DLL é substituído por um executável comum, com os arquivos posicionados no diretório raiz do pacote e execução acionada pelo script por ExecWait. Também há variante em que o shellcode criptografado fica dentro de recurso RT_RCDATA. A forma com maior diferença técnica citada usa chamadas de API a partir do script, aloca memória, define proteção PAGE_EXECUTE_READWRITE, lê um arquivo para essa região e transfere controle para o conteúdo carregado.

Superfície afetada

A superfície exposta para defesa não é um produto vulnerável, mas um formato legítimo abusado como contêiner de malware. Sistemas de correio, gateways de download, EDR, sandboxes, pipelines de análise de amostras e estáções de resposta a incidentes devem tratar executáveis NSIS suspeitos como arquivos compostos, não apenas como binários únicos. A presença de estrutura de instalador não reduz o risco; neste caso, ela é parte do mecanismo de ocultação. O conteúdo relevante pode estar comprimido dentro do pacote, criptografado em arquivos sem extensão significativa ou dividido entre script e binários auxiliares.

A estrutura recorrente ajuda a priorizar inspeção. Arquivos criptografados no diretório raiz, DLLs em $PLUGINSDIR, funções exportadas chamadas pelo script e referências a nomes como Loader.dll são sinais úteis quando aparecem juntos. Entretanto, a família não depende de um único nome de arquivo. O contexto indica nomes aleatórios em amostras e variações no caminho de armazenamento do shellcode. Assim, detecções baseadas apenas em string isolada tendem a perder variantes. A defesa deve observar o encadeamento: pacote NSIS, extração para temporário, chamada de plugin ou executável auxiliar, leitura de arquivo criptografado e criação de código executável em memória.

Ambientes de análise também são afetados pela limitação de dumps dinâmicos. Executar a amostra em sandbox pode revelar comportamento, mas nem sempre produz artefatos reaproveitáveis para engenharia reversa posterior. Quando o objetivo é extrair configuração, chaves e endereços de comando e controle de uma amostra empacotada, o desempacotamento estático reduz dependência de execução completa. Ainda assim, a automação deve ser validada com cuidado, porque o próprio material técnico ressalta que exemplos simplificados de desempacotador podem não funcionar para todas as amostras dessa família.

• Pacotes NSIS autoextraíveis que contêm arquivos criptografados e scripts de instalação com chamadas a plugins ou executáveis auxiliares.
• Diretório $PLUGINSDIR com DLL exportando funções chamadas pelo script, inclusive casos em que a DLL maliciosa se apresenta como plugin.
• Variantes sem $PLUGINSDIR, com executável no diretório raiz e passagem de parâmetro pelo script.
• Shellcode em arquivo separado, embutido na DLL, armazenado em recurso RT_RCDATA ou carregado por memória com permissão PAGE_EXECUTE_READWRITE.

Hunting e telemetria

A caça deve começar pela camada de contêiner. Em repositórios de amostras, filas de anexos e telemetria de endpoint, procure executáveis que sejam reconhecidos como pacotes NSIS e que tenham conteúdo interno incompatível com instaladores comuns. A extração controlada do pacote, sem executar a instalação, permite listar arquivos internos, nomes de diretórios e script. A presença de poucos arquivos, binários com dados aparentemente criptografados e plugin em $PLUGINSDIR merece análise manual ou automação específica. Nomes aleatórios de arquivos, ausência de interface de instalação coerente e script reduzido a operações de extração e chamada de função aumentam a prioridade.

No endpoint, a telemetria deve diferenciar comportamento de instalador legítimo de carregamento de malware. Sinais importantes incluem criação de arquivos temporários seguida de chamada de DLL exportada, processo de instalador acionando executável auxiliar, leitura de blob criptografado e alocação de memória executável. A variante com System.dll e chamadas de API a partir do script é especialmente relevante para produtos que registram eventos de memória, porque o fluxo citado inclui alocação, alteração de proteção para PAGE_EXECUTE_READWRITE, leitura de arquivo em memória e transferência de controle. Esses eventos, quando associados a pacote NSIS, formam uma cadeia mais forte do que qualquer indicador isolado.

Na engenharia reversa, a telemetria estática deve buscar padrões de resolução de API por hash, acesso à tabela de exportação de kernel32.dll e rotinas byte a byte de transformação do payload. O uso de hashes de 4 bytes para APIs reduz strings em claro e atrapalha análise automática, mas deixa uma técnica rastreável: enumeração de exportações, cálculo de hash de nomes e comparação com valores esperados. A etapa de descriptografia pode ser reconhecida por blocos de instruções repetitivas que atualizam o byte atual do buffer e aplicam operações aritméticas ou lógicas antes de gravar o resultado. Esses sinais são úteis para construir classificadores internos e priorizar amostras para análise aprofundada.

• Pacote NSIS com dois arquivos criptografados no diretório raiz e DLL de plugin em $PLUGINSDIR.
• Script de instalação que apenas extrai artefatos e chama função exportada por DLL ou executa binário auxiliar.
• Leitura de arquivo criptografado com nome codificado dentro da DLL ou passado como parâmetro.
• Resolução de APIs por hash e varredura da tabela de exportação de kernel32.dll.
• Alocação de memória com proteção PAGE_EXECUTE_READWRITE antes da transferência de controle.
• Shellcode independente de posição recuperado após XOR e, em algumas variantes, deslocamento cíclico byte a byte.

Mitigação

A resposta deve tratar essas amostras como contêineres multiestágio. O primeiro passo defensivo é extrair o conteúdo do pacote em ambiente isolado, registrar a estrutura interna e preservar o script NSIS para análise. A execução direta deve ser evitada fora de laboratório, porque o próprio mecanismo de instalação é usado para acionar a cadeia. A partir da extração, a equipe pode identificar se a amostra usa DLL de plugin, executável auxiliar, shellcode embutido ou recurso RT_RCDATA. Essa classificação inicial determina qual rotina de desempacotamento precisa ser aplicada e quais eventos devem ser correlacionados na telemetria.

Para detecção, regras devem combinar estrutura e comportamento. Uma regra frágil baseada em Loader.dll ou em nome específico de função pode falhar quando a variante troca nomes. Uma abordagem mais resistente combina formato NSIS, presença de dados criptografados, plugin ou executável auxiliar, script mínimo de chamada, resolução de API por hash e criação de memória executável. Em ambientes com EDR, vale correlacionar criação de arquivos temporários por instaladores, carregamento de DLL de diretório extraído, chamadas de função exportada e eventos de proteção de memória. Em pipelines de malware, a automação deve recuperar chaves textuais quando presentes, tentar identificar deslocamento cíclico e validar shellcode apenas por características estruturais, sem executar payload final em ambiente de produção.

A contenção deve ser proporcional ao estágio observado. Se a amostra foi bloqueada antes da execução, preserve artefatos para análise e busque ocorrências do mesmo pacote, hashes internos e nomes de arquivos extraídos no ambiente. Se houve execução, investigue processos filhos do instalador, arquivos temporários criados, módulos carregados, regiões de memória executáveis e conexões de rede associadas ao processo resultante. O material analisado não fornece indicadores de rede específicos nem confirma exfiltração, portanto a investigação deve se concentrar nos efeitos comprovados da cadeia: desempacotamento, descriptografia, carregamento de shellcode e execução do payload recuperado.

Equipes de laboratório podem ganhar eficiência ao manter um fluxo de desempacotamento estático para essa família, mas precisam validar resultados por amostra. A própria variação entre DLL, executável, recurso e payload com RC4 exige que a automação registre falhas e encaminhe casos fora do padrão para engenharia reversa manual. O resultado esperado do processo não é produzir uma prova de conceito executável, mas obter a carga desempacotada e sua configuração para classificação, criação de detecções, enriquecimento de alertas e resposta a incidentes.

• Extrair o pacote NSIS em ambiente isolado e registrar script, diretórios, DLLs, executáveis e arquivos criptografados.
• Priorizar análise de chamadas a plugins em $PLUGINSDIR, uso de ExecWait e referências a arquivos passados como parâmetro.
• Criar detecções compostas para formato NSIS suspeito, dados criptografados, resolução de API por hash e memória PAGE_EXECUTE_READWRITE.
• Correlacionar eventos de extração temporária, carregamento de DLL, execução de binário auxiliar e criação de regiões executáveis em memória.
• Evitar publicação interna de payloads completos ou rotinas reproduzíveis de exploração; usar artefatos recuperados para classificação, bloqueio e hunting.
• Validar manualmente variantes que não sigam a estrutura esperada, especialmente amostras com shellcode embutido, recurso RT_RCDATA ou payload com RC4.