TrickGate manteve empacotamento de malware por seis anos com shellcode mutável

Empacotador oferecido como serviço foi usado para encapsular ransomware, RATs, infostealers, bankers e mineradores, dificultando detecção antes da execução da carga maliciosa.

ComponenteTrickGate, empacotador baseado em shellcode usado como serviço para ocultar diferentes famílias de malware.
VetorAmostras empacotadas foram distribuídas principalmente por e-mails de phishing com anexos maliciosos e também por links maliciosos.
ImpactoO empacotador descriptografa e injeta a carga em novo processo, reduzindo a chance de detecção por antivírus e EDR antes da execução do malware final.
PrioridadeDetectar o empacotador antes da carga final, revisando anexos compactados, criação de processos suspensos, shellcode em memória e chamadas diretas ao núcleo.
ArtefatosForam observados loaders em NSIS, AutoIT e C, armazenamento de shellcode em arquivo, seção .rdata ou recurso, além de hashing de APIs.
Malwares associadosCerber, Trickbot, Maze, Emotet, REvil, Cobalt Strike, AZORult, Formbook, AgentTesla, Remcos e outras famílias foram encapsuladas pelo serviço.
Resumo técnico

TrickGate é um empacotador de malware baseado em shellcode observado desde 2016 e mantido por vários anos como uma camada de ocultação para diferentes cargas maliciosas. A função principal desse tipo de componente não é realizar a ação final do ataque, mas alterar a aparência, o fluxo de execução e os artefatos de memória do binário entregue, dificultando que antivírus e EDR identifiquem o conteúdo real antes da descriptografia e da injeção da carga. Essa separação entre empacotador e payload permite que o mesmo mecanismo seja reutilizado por operadores distintos, com famílias de malware diferentes, sem que a defesa consiga depender apenas do nome da ameaça final.

A atividade atribuída ao TrickGate mostra uma operação persistente porque o invólucro externo muda com frequência, enquanto blocos internos do shellcode permanecem reconhecíveis ao longo do tempo. Esse comportamento explica por que o mesmo serviço recebeu nomes diferentes em análises anteriores, incluindo referências a loader, crypter baseado em NSIS e empacotador associado ao Emotet. A cadeia não se limita a uma família específica: ela foi observada encapsulando ransomware, ferramentas de acesso remoto, infostealers, bankers, mineradores e componentes como Cobalt Strike. O ponto defensivo mais importante é tratar o empacotador como alvo de detecção próprio, pois bloqueá-lo em fase inicial impede que payloads variados cheguem ao estágio de execução.

Fluxo técnico

A cadeia normalmente começa com acesso inicial por phishing, usando anexos maliciosos ou links que levam a arquivos preparados para iniciar o empacotador. O primeiro estágio aparece com frequência como executável arquivado, mas também foram observadas muitas variações de formatos de arquivo e combinações de entrega. O objetivo desse estágio não é expor imediatamente a carga final; ele conduz a um loader de shellcode responsável por descriptografar e carregar o próximo bloco em memória. Foram identificadas implementações desse loader em scripts NSIS, scripts AutoIT e código C, todas com finalidade semelhante: preparar memória, recuperar o shellcode criptografado e transferir a execução de forma indireta.

O shellcode é o núcleo operacional do TrickGate. Ele descriptografa o payload e o injeta em um novo processo, permitindo que a atividade maliciosa final seja executada sob uma aparência menos direta. Versões mais recentes abusam de mecanismos de callback do Windows, registrando endereços de memória controlados no lugar de uma função de callback convencional. Quando o sistema operacional atinge o evento registrado, o fluxo executa o shellcode em um momento menos óbvio para mecanismos de análise comportamental. Exemplos de APIs citadas na técnica incluem EnumTimeFormatsA e EnumSystemCodePagesW, usadas como parte do desvio de fluxo, não como finalidade legítima da aplicação.

Outro bloco consistente é a injeção por chamadas diretas ao núcleo. Depois de descriptografar o payload, o shellcode cria um processo com sinalização de suspensão e usa chamadas diretas associadas a APIs de ntdll para escrever e preparar a carga no processo alvo. A técnica se aproxima do conceito conhecido como Hell's Gate, no qual números de syscall são resolvidos dinamicamente para evitar dependência de uma tabela fixa. O material analisado indica que amostras de 2016 já realizavam ação equivalente para recuperar e executar chamadas diretas, anos antes de essa abordagem receber ampla atenção pública. Para defesa, isso significa que a cadeia pode contornar ganchos de usuário tradicionais e exigir observação combinada de memória, criação de processo, transições de modo e comportamento de injeção.

A manutenção do empacotador também aparece nas rotinas de ofuscação. O código evita strings constantes e pode inserir strings de depuração ou trechos limpos para prejudicar análise estática. As APIs necessárias são escondidas por hashing, com uso de CRC32 até janeiro de 2021 e adoção posterior de uma função de hash personalizada. A descriptografia do payload também varia: algumas amostras antigas usaram implementação de RC4 ou APIs de criptografia do Windows, enquanto muitas versões usam métodos personalizados. Essa mudança contínua torna frágil qualquer desempacotamento rígido baseado em uma versão única.

Superfície afetada

A superfície exposta inclui usuários que recebem anexos compactados, estáções Windows capazes de executar os loaders, mecanismos de inspeção de e-mail que não extraem adequadamente arquivos aninhados e ambientes de endpoint que dependem demais de assinatura estática. O primeiro estágio foi observado em uma grande variedade de contêineres e formatos compactados, incluindo 7Z, RAR, ZIP, ISO, IMG, CAB, TAR, GZ e outros. A variedade de empacotamento cria dificuldade operacional para gateways e sandboxes, porque a normalização do arquivo precisa ocorrer antes da decisão de bloqueio.

A telemetria associada à atividade registrou entre 40 e 650 ataques por semana durante os dois anos observados. O setor de manufatura aparece como principal alvo, com ocorrências também em educação, saúde, finanças e empresas de serviços. A distribuição foi global, com concentração maior em Taiwan e Turquia. Nos dois meses finais do período descrito, Formbook respondeu por 42% da distribuição rastreada, mostrando que o serviço continuava útil para operadores de infostealers, além de ter histórico com ransomware e ferramentas de pós-exploração.

A exposição não depende de uma vulnerabilidade específica em produto corporativo. O risco nasce da combinação de engenharia social, arquivo inicial com baixa reputação, loader que prepara shellcode, técnicas de injeção e payload final escolhido pelo operador. Por isso, controles apenas baseados em família de malware tendem a chegar tarde. O mesmo empacotador pode anteceder cargas com impactos distintos, como roubo de credenciais, acesso remoto, mineração não autorizada ou criptografia de arquivos, mas cada consequência deve ser atribuída ao payload final observado, não ao empacotador isoladamente.

  • Estáções Windows que executam anexos ou arquivos obtidos por links de phishing.
  • Gateways de e-mail e sandboxes que não normalizam múltiplos formatos compactados antes da análise.
  • EDR e antivírus que dependem de strings, hashes de arquivo ou desempacotamento estático de uma versão específica.
  • Ambientes de manufatura, educação, saúde, finanças e negócios, setores citados na distribuição observada.
Hunting e telemetria

A investigação deve priorizar sinais antes da execução plena do payload. Em e-mail, procure mensagens com anexos compactados incomuns, imagens de disco anexadas, arquivos com cadeia de extração longa e links que resultam em executáveis arquivados. Em endpoint, correlacione abertura de anexo com criação de processo filho inesperado, alocação de memória executável, escrita em processo suspenso e transições rápidas entre loader e payload. A presença de loaders em NSIS ou AutoIT deve ser avaliada com contexto: esses componentes podem ser legítimos, mas se tornam suspeitos quando aparecem após phishing e antes de comportamento de injeção.

Em memória, os sinais mais úteis estão ligados a shellcode descriptografado, resolução indireta de APIs, ausência de strings constantes e uso de hashes para localizar funções de Kernel32 ou ntdll. A defesa deve observar padrões de chamadas que aceitam ponteiros de callback e, em seguida, levam à execução de memória recém-alocada. Esse fluxo é mais robusto para hunting do que tentar identificar apenas o nome do empacotador, porque o invólucro externo é projetado para mudar. Também é útil rastrear processos criados em modo suspenso e retomados após escrita de memória por outro processo.

A telemetria de chamadas diretas ao núcleo merece atenção especial. Quando um processo carrega ou mapeia uma cópia limpa de ntdll, resolve números de syscall de forma dinâmica e executa operações equivalentes a escrita de memória remota ou alteração de contexto, há um sinal compatível com tentativa de evasão de ganchos de usuário. Esse indicador deve ser combinado com origem do arquivo, reputação, árvore de processos e comportamento de rede posterior. Como o TrickGate é apenas o empacotador, conexões externas, persistência, coleta de dados e comandos remotos variam conforme a família final, como Formbook, Remcos, AgentTesla ou outra carga encapsulada.

  • Anexos compactados ou imagens de disco recebidos por e-mail e seguidos por execução local.
  • Execução de loaders em NSIS, AutoIT ou C com descriptografia de bloco em memória.
  • Uso de callbacks para transferir execução a memória recém-alocada.
  • Criação de processo suspenso seguida de escrita de memória e retomada de execução.
  • Resolução de APIs por hash, ausência de strings úteis e possíveis chamadas diretas associadas a ntdll.
Mitigação

A mitigação deve começar no ponto de entrega. Gateways de e-mail precisam extrair e analisar anexos compactados, imagens de disco e contêineres aninhados, bloqueando combinações incompatíveis com o perfil normal da organização. Políticas de endpoint devem restringir execução de arquivos originados de e-mail e navegador quando estiverem em diretórios temporários, áreas de download ou caminhos de extração. Para usuários com maior exposição a anexos, a execução de scripts AutoIT e instaladores NSIS desconhecidos deve ser controlada por reputação, assinatura, origem e necessidade de negócio.

No endpoint, a resposta deve isolar máquinas com evidência de loader, preservar memória quando possível e coletar árvore de processos, artefatos de arquivo, eventos de criação de processo e telemetria de alocação executável. Como o payload final pode variar, a contenção não deve terminar ao remover o primeiro binário. É necessário identificar se houve execução de família adicional, comunicação externa, persistência, coleta de credenciais ou movimentação para outros sistemas. Quando a carga final for um infostealer ou RAT conhecido, a rotação de credenciais deve considerar contas usadas no host afetado e sessões autenticadas naquele período.

A validação defensiva deve incluir detecções por comportamento, não somente por assinatura de amostra. Regras de correlação podem combinar origem de anexo, execução de contêiner extraído, loader com ofuscação, uso de callback, criação de processo suspenso e chamadas diretas relacionadas a injeção. Sandboxes devem permitir tempo e cobertura suficientes para que callbacks e eventos registrados disparem, porque versões recentes tentam quebrar a sequência comportamental esperada. Em paralelo, equipes de segurança devem manter bloqueios para famílias finais observadas, mas tratar o TrickGate como camada comum capaz de anteceder cargas novas ou pouco conhecidas.

  • Aplicar inspeção profunda de anexos compactados, imagens de disco e arquivos aninhados em gateways de e-mail.
  • Bloquear ou restringir execução de arquivos extraídos de e-mail e navegador em diretórios temporários.
  • Correlacionar criação de processo suspenso, escrita de memória remota, callbacks incomuns e execução de memória recém-alocada.
  • Isolar hosts com evidência de loader e verificar qual payload final foi executado antes de encerrar a resposta.
  • Atualizar detecções para o empacotador e para as famílias finais associadas, evitando dependência exclusiva de hashes.