Malware usa empacotadores BoxedApp para ocultar cargas em binários autocontidos

A técnica combina armazenamento virtual, resolução de imports em tempo de execução e injeção em memória para dificultar análise estática de RATs, stealer e algumas amostras de ransomware.

Componente	Produtos BoxedApp Packer, BxILMerge e empacotadores personalizados baseados no BoxedApp SDK.
Vetor	Execução de binários PE autocontidos que inicializam recursos de Virtual Storage, resolvem imports em tempo de execução e podem carregar dependências ou processos virtuais sem gravar arquivos no disco.
Impacto	Redução de detecção estática, endurecimento da análise reversa e implantação de famílias conhecidas de RATs, stealers e algumas amostras de ransomware, incluindo instâncias associadas a LockBit.
Prioridade	Correlacionar comportamento em sandbox, eventos de API e artefatos de empacotamento em PE, em vez de depender apenas de assinaturas estáticas com alto risco de falso positivo.
Artefatos	Uso de Virtual File System, Virtual Registry, WIN/NT API hooking, TLS Callback, seção .bxpck, DotNetAppStub e compressão Zlib - DEFLATE em conteúdos de armazenamento virtual.
Superfície observada	Amostras maliciosas atribuídas foram vistas principalmente em campanhas contra instituições financeiras e setores governamentais.

Resumo técnico

Operadores de malware vêm abusando de produtos comerciais da família BoxedApp como camada de empacotamento para distribuir cargas já conhecidas, sobretudo ferramentas de acesso remoto e roubadores de informação. O ponto relevante para defesa não é a existência de um novo malware, mas a forma como o empacotador altera a visibilidade do binário final. Ao transformar uma aplicação em um PE autocontido, com dependências embutidas e resolução dinâmica de elementos críticos, a técnica reduz a utilidade de verificações estáticas simples e aumenta o custo de análise manual. Esse comportamento é especialmente sensível em ambientes nos quais a classificação inicial de arquivos depende muito de metadados, imports, recursos visíveis e extração direta de dependências.

Fluxo técnico

Quando uma aplicação é empacotada com BoxedApp Packer, o resultado é um executável PE único que reúne a aplicação original e seus componentes dependentes. O empacotamento destrói ou remove a visibilidade dos imports originais e posterga a resolução de APIs para a execução. Um TLS Callback inicializa a lógica interna do empacotador, resolve chamadas necessárias em tempo de execução, prepara o Virtual Storage e, quando configurado, descomprime conteúdo embutido. Essa sequência muda o ponto de observação: o analista que examina apenas o arquivo em repouso pode não ver as mesmas dependências, rotas de carregamento e estruturas que aparecem quando o processo está vivo.

O Virtual Storage combina Virtual File System e Virtual Registry para apresentar ao aplicativo uma visão de arquivos e chaves que não precisam existir no sistema real. Chamadas de entrada e saída são interceptadas por hooking de APIs WIN/NT, e a lógica do empacotador decide se a operação deve ser respondida a partir do armazenamento virtual ou encaminhada ao arquivo e registro reais. Na prática, uma DLL ou outro recurso pode ser carregado como se estivesse presente no disco, embora permaneça embutido no binário ou materializado apenas em memória. A mesma camada também pode marcar determinados arquivos ou chaves como inexistentes para a aplicação empacotada, mesmo quando eles existem no sistema subjacente.

A capacidade de Virtual Processes amplia o valor ofensivo do empacotamento. Quando um executável PE é tratado como arquivo virtual, o empacotador pode selecionar um binário adequado de System32 ou SysWOW64, iniciar um processo suspenso e injetar a imagem PE virtual na memória do processo remoto. O fluxo observado usa primitivas do Windows como alocação de memória remota, alteração de proteção, escrita no processo e criação de thread remota. O efeito defensivo a observar é semelhante ao de injeção de PE: execução de uma imagem que não passou pelo caminho tradicional de arquivo no disco, com dependências e carga útil escondidas atrás da camada de empacotamento.

Superfície afetada

A superfície exposta inclui estáções e servidores Windows que recebem binários PE empacotados, especialmente quando a política de execução permite arquivos baixados, anexos, instaladores de terceiros ou ferramentas portáteis pouco controladas. O risco não se restringe a um único tipo de carga. O conjunto analisado inclui RATs, stealers e algumas amostras de ransomware. A presença de LockBit em parte das amostras observadas indica que a técnica pode ser usada tanto para acesso remoto e coleta de credenciais quanto para fases posteriores de campanhas mais destrutivas, embora cada amostra precise ser analisada pelo seu comportamento real.

Há diferenças importantes entre os produtos abusados. BoxedApp Packer suporta empacotamento de PEs nativos e .NET, criando um executável autocontido com dependências incorporadas. Em aplicações .NET, quando há compressão, um stub nativo chamado DotNetAppStub envolve o binário .NET original dentro da seção .bxpck, e o conteúdo é preparado para execução em memória. Já BxILMerge atua em cenários .NET, agrupando assemblies gerenciados, DLLs não gerenciadas e outros arquivos em uma única assembly. Um construtor de módulo inicializa um resolvedor customizado de assemblies e o Virtual Storage, de modo que dependências carregadas a partir de recursos internos pareçam arquivos disponíveis para a aplicação.

A prevalência defensiva deve ser interpretada com cuidado porque produtos BoxedApp também são usados em software legítimo. Detecções estáticas podem gerar falso positivo quando um binário benigno é empacotado com os mesmos componentes comerciais. Em um conjunto aproximado de 1.200 amostras empacotadas por BoxedApp e submetidas ao VirusTotal nos últimos três anos, processadas por sandboxes, cerca de 25% foram classificadas como maliciosas por comportamento. Esse dado reforça que a decisão operacional deve combinar estrutura do arquivo, comportamento dinâmico, reputação, origem do binário, assinatura, relações de processo e telemetria de rede.

• Executáveis PE autocontidos com dependências embutidas em Virtual Storage.
• Aplicações .NET empacotadas com DotNetAppStub e seção .bxpck.
• Carregamento de DLLs, assemblies ou recursos sem criação correspondente de arquivo no disco.
• Processos suspensos que recebem imagem PE virtual por escrita de memória remota.
• Ambientes financeiros e governamentais aparecem como alvos predominantes nas amostras atribuídas.

Hunting e telemetria

A caça deve priorizar a diferença entre o que o arquivo aparenta conter em repouso e o que o processo realiza em execução. Um binário com poucos imports visíveis, recursos embutidos e comportamento de resolução dinâmica não é automaticamente malicioso, mas merece correlação com eventos de criação de processo, chamadas de memória remota, carregamento de módulos e acesso a registro. Em endpoints com EDR, sinais úteis incluem processo recém-criado em estado suspenso, escrita de memória em processo filho, alteração de proteção de páginas executáveis e criação de thread remota após inicialização do binário empacotado.

A telemetria de arquivo também é relevante. O defensor pode procurar binários PE que contenham estruturas compatíveis com armazenamento virtual, seções associadas a empacotamento .NET, stubs nativos envolvendo assemblies e conteúdo comprimido que só se torna legível em memória. Como a compressão Zlib - DEFLATE pode tornar os arquivos virtuais ilegíveis no disco, a coleta de dump de memória e a reconstrução da IAT resolvida em tempo de execução podem ser mais efetivas do que a extração estática direta. O objetivo não é publicar ou executar desempacotadores indiscriminadamente, mas recuperar contexto suficiente para classificar a carga e entender dependências reais.

Logs de rede e identidade devem ser analisados depois que a carga for classificada. Como o empacotador é apenas a camada de ocultação, o comportamento final depende da família implantada. RATs tendem a expor padrões de comando e controle, stealers podem acessar navegadores, armazenamento local e tokens de sessão, e ransomware pode exibir criação intensa de arquivos alterados e operações destrutivas. A correlação temporal entre a inicialização do PE empacotado, a materialização de módulos em memória e conexões externas ajuda a separar aplicação legítima empacotada de uso malicioso.

• PE com imports originais ausentes ou pouco informativos e resolução dinâmica durante a execução.
• Inicialização por TLS Callback seguida de preparação de Virtual Storage.
• Uso de APIs como VirtualAllocEx, VirtualProtectEx, WriteProcessMemory e CreateRemoteThreadEx em sequência compatível com injeção em processo remoto.
• Carregamento de DLLs ou assemblies sem evento equivalente de criação de arquivo no caminho esperado.
• Presença de .bxpck, DotNetAppStub ou recursos .NET agrupados em assembly única.
• Divergência entre arquivos acessados pela aplicação e artefatos realmente existentes no sistema de arquivos.

Mitigação

A resposta deve começar pela classificação do binário empacotado como artefato de risco, não como prova isolada de comprometimento. Como há uso legítimo de BoxedApp, bloquear todo arquivo com características do empacotador pode interromper aplicações válidas. A abordagem mais robusta é aplicar controle de origem e reputação, exigir assinatura confiável quando aplicável, restringir execução de diretórios graváveis pelo usuário e submeter amostras suspeitas a análise dinâmica controlada. Quando o comportamento incluir injeção remota, comunicação externa incomum ou acesso a dados sensíveis, a contenção deve tratar o endpoint como potencialmente comprometido.

Em engenharia reversa defensiva, a prioridade é recuperar a carga real e seus artefatos de execução. Para PEs nativos, dumps de memória e reconstrução da tabela de imports resolvida em tempo de execução tendem a revelar mais do que uma inspeção estática do arquivo original. Para .NET, a presença de DotNetAppStub, .bxpck e assemblies incorporados deve orientar a análise de recursos e do fluxo de inicialização. Em ambos os casos, a investigação precisa registrar hashes internos, nomes de módulos, relações de processo e conexões observadas, mantendo indicadores perigosos defangados em documentação compartilhada.

Na prevenção, políticas de aplicação permitida, bloqueio de execução em caminhos temporários, inspeção de anexos e controle de ferramentas portáteis reduzem a chance de execução inicial. Em ambientes com alto volume de software empacotado legitimamente, as regras devem ser calibradas por comportamento: injeção em processo filho, dependências carregadas apenas em memória, conexões iniciadas logo após a preparação do armazenamento virtual e acesso a credenciais locais são sinais mais fortes do que a presença do empacotador isolado. Depois de um alerta confirmado, a resposta deve incluir isolamento do host, coleta de memória quando viável, revisão de credenciais expostas pela carga e varredura por artefatos equivalentes em endpoints que receberam o mesmo binário.

• Criar regras de detecção que combinem características de empacotamento com comportamento de execução, não apenas assinatura estática.
• Restringir execução de binários não confiáveis em diretórios temporários, perfis de usuário e áreas de download.
• Correlacionar eventos de memória remota com criação de processo suspenso e carregamento de módulos sem arquivo correspondente.
• Submeter amostras suspeitas a sandbox controlada para separar falso positivo de comportamento malicioso real.
• Coletar dump de memória e metadados do processo quando houver indício de carga executada apenas em memória.
• Revisar credenciais e sessões do usuário afetado quando a carga final apresentar comportamento compatível com stealer ou RAT.