Novo Playground de Malware

Introdução

Embora o BoxedApp já esteja disponível comercialmente há algum tempo, no ano passado detectamos um aumento significativo no seu abuso para implantar inúmeras famílias de malware conhecidas, principalmente relacionadas a RATs e ladrões. A maioria das amostras maliciosas atribuídas tinha como alvo instituições financeiras e setores governamentais.

Nossa investigação mostra que os principais produtos BoxedApp abusados ​​são  BoxedApp Packer  e  BxILMerge , que são construídos sobre o  BoxedApp SDK . Embora ambos os produtos forneçam aos agentes de ameaças acesso aos recursos mais interessantes do SDK, com o próprio BoxedApp SDK eles podem criar um empacotador personalizado e exclusivo que aproveita os recursos mais avançados e é diversificado o suficiente para evitar a detecção estática.

Compactar o malware para diminuir sua detecção ou para reforçar a análise é uma técnica conhecida e comumente aplicada à carga útil do malware. Embora o uso de um empacotador comercial conhecido tenha algumas desvantagens, os benefícios do uso de recursos avançados e exclusivos os superam facilmente. Entre os recursos e capacidades mais interessantes do BoxedApp SDK estão:

• Sistema de arquivos virtual (parte do armazenamento virtual)
• Registro Virtual (parte do Armazenamento Virtual)
• Processos Virtuais (PE Injection – iniciando processos da memória)
• SDK de conexão de API WIN/NT
• Embalagem geral (destruição de importações originais de PE, compressão, etc.)
• Produzindo um pacote de arquivo único (todas as dependências necessárias fazem parte do armazenamento virtual)
• Todas as E/S para armazenamento virtual permanecem apenas na memória (nenhum arquivo é descartado no disco), por exemplo, carregamento de DLL do armazenamento virtual

Neste relatório, fornecemos uma visão geral dos produtos BoxedApp e seu abuso para fins maliciosos, bem como uma análise aprofundada das estruturas binárias compactadas resultantes com assinaturas Yara que podem ser usadas para detectar estaticamente o empacotador em uso, distinguindo ao mesmo tempo o produto em si.

Antecedentes e principais conclusões

Embora os produtos BoxedApp estejam disponíveis há vários anos, no ano passado houve um aumento significativo no seu abuso para implantar várias famílias de malware diferentes sem qualquer menção pública à sua conexão com o BoxedApp.

Os produtos BoxedApp são  empacotadores comerciais bem conhecidos  , portanto, há prós e contras em abusar deles para ocultar cargas maliciosas:

PRÓS:

• Produtos confiáveis ​​e prontos para uso que oferecem recursos avançados.
• SDK BoxedApp disponível para criar diversos empacotadores personalizados.
• Utiliza um sistema proprietário de Armazenamento Virtual (Virtual File System, Virtual Registry).
• Criação de Processos Virtuais (qualquer processo criado a partir de um arquivo executável que faça parte do Armazenamento Virtual) para injeção de PE.
• SDK simples para realizar a conexão de qualquer API WIN/NT.
• Embalagem geral (destrói importações originais de PE, realiza compactação, etc.).
• Produz um pacote de arquivo único (todas as dependências necessárias fazem parte do armazenamento virtual).
• Todas as E/S para armazenamento virtual permanecem apenas na memória (nenhum arquivo é descartado no disco), por exemplo, carregamento de DLL do armazenamento virtual.
• É difícil distinguir entre aplicativos compactados regulares e maliciosos (alta taxa de falsos positivos).

CONTRAS:

• Fácil detecção estática dos produtos BoxedApp originais usados ​​para compactar o malware.
• Detecção estática genérica de determinados recursos do SDK comumente utilizados para fins maliciosos (por exemplo, conexão de API WIN/NT, processo virtual – injeção PE).
• Alta taxa de detecção de FP (falso positivo) de aplicativos não maliciosos empacotados pelo BoxedApp.

Como você pode esperar, o abuso do BoxedApp para implantar cargas maliciosas e permanecer fora do radar pode resultar em discrepâncias causadas por sua alta taxa de detecção de FP, mesmo em aplicativos não maliciosos. O Windows Defender integrado e outros AVs de primeira linha geralmente não são afetados, mas mesmo um simples aplicativo “Hello World” empacotado pelo BoxedApp é inicialmente detectado por vários mecanismos AV.

produtos	Formato PE original	Detecção Inicial de VT	Link
Empacotador BoxedApp	PE nativo (C/C++)	14/71	VirusTotal
Empacotador BoxedApp	.NET PE (C#, .NET Framework)	20/71	VirusTotal
BoxedApp BxILMerge	.NET PE (C#, .NET Framework)	2/70	VirusTotal

Como observação lateral, o número de detecções de FP pode ser significativamente reduzido assinando o binário compactado resultante (independentemente de qual assinatura é usada) ou usando um empacotador personalizado construído sobre o BoxedApp SDK.

Devido à alta taxa de AV FP na detecção estática, que detona logo no momento do processamento do BoxedApp SDK, decidimos usar o método mais adequado (baseado no comportamento da amostra) para separar o FP das amostras maliciosas reais.

Entre aproximadamente 1.200 amostras testadas (embaladas pelo BoxedApp) submetidas ao VT (VirusTotal) nos últimos 3 anos e processadas com sucesso pelas sandboxes do VT, 25% foram detectadas como “maliciosos” com base em seu comportamento. O cronograma de envio de VT dessas amostras maliciosas mostra a tendência crescente de abuso do BoxedApp para implantação de malware.

A tabela abaixo mostra as famílias de malware atribuídas e mais implantadas. Embora uma parte significativa das amostras maliciosas sejam RATs ou ladrões, também detectamos vários casos de ransomware, alguns dos quais pertencem à notória cepa LockBit.

QuasarRAT	NanoCore	NjRAT	Neshta	AsyncRAT	XWorm	LodaRAT
VingançaRAT	AgenteTesla	Bloqueio	Linha Vermelha	Remcos	ZXShell	Ramnit

Para ilustrar a classificação de malware mais genérica (com base nos resultados do sandbox VT), separamos e classificamos as amostras maliciosas do BoxedApp com base em seus  Veredictos de Comportamento .

Metade das amostras maliciosas submetidas à VT vieram principalmente da Turquia, dos Estados Unidos e da Alemanha, mas a tendência crescente de abuso do BoxedApp é aparentemente mundial.

A maioria das amostras maliciosas atribuídas foi usada em ataques contra instituições financeiras e indústrias governamentais. O uso de produtos BoxedApp para empacotar as cargas maliciosas permitiu que os invasores reduzissem a taxa de detecção, reforçassem suas análises e usassem os recursos avançados do BoxedApp SDK (por exemplo, armazenamento virtual) que normalmente levariam muito tempo para serem desenvolvidos do zero.

Internos do BoxedApp

Quando um aplicativo é compactado pelo BoxedApp, o formato resultante é um único binário PE independente, onde as importações do PE original são destruídas e resolvidas apenas durante o tempo de execução por meio de um retorno de chamada TLS em stub. O retorno de chamada TLS é responsável não apenas pela resolução da API em tempo de execução, mas também por inicializar o armazenamento virtual e possivelmente descompactar seu conteúdo.

Todas as dependências necessárias da aplicação original podem fazer parte do sistema proprietário de Armazenamento Virtual, que consiste em um Sistema de Arquivos Virtuais e um Registro Virtual. As interceptações de E/S do BoxedApp (ligação inline de determinadas APIs do WIN/NT) manipulam esses arquivos virtuais e registros na memória, resultando na criação de um registro (virtual) falso e na ausência de arquivos no disco.

Quando a aplicação compactada realiza E/S em arquivos ou registros que fazem parte do Armazenamento Virtual, os internos do BoxedApp interceptam essas operações de E/S e as direcionam para o Armazenamento Virtual (a aplicação não reconhece que não está interagindo com o Armazenamento Virtual). registro e arquivos reais). Por outro lado, quando o aplicativo compactado tenta interagir com arquivos e registros que não fazem parte do Armazenamento Virtual, a lógica interna do BoxedApp direciona a E/S para o registro real e os arquivos no disco. O armazenamento virtual também pode ser usado para falsificar e marcar determinados arquivos ou registros como inexistentes para o aplicativo compactado, apesar de existirem em um sistema real. Uma lógica simplificada dos componentes internos do BoxedApp é mostrada abaixo.

Por padrão, o conteúdo dos arquivos incorporados no armazenamento virtual é claramente legível no disco (e também no binário principal), mas outras  opções de compactação  podem ser definidas. Isso resulta na compactação de todos os arquivos virtuais incorporados com o  algoritmo Zlib – DEFLATE  , o que torna todos os arquivos virtuais ilegíveis no disco. A descompactação é processada apenas na memória durante o tempo de execução.

Uma das outras capacidades do BoxedApp é a criação de Processos Virtuais que ocorrem após o processo ser criado a partir de um arquivo executável (PE) que é reconhecido como um arquivo virtual (parte do Armazenamento Virtual). Um determinado binário PE adequado do diretório System32/SysWOW64 (dependendo da arquitetura) é selecionado e iniciado como um processo suspenso. O “Arquivo Virtual” PE original é injetado na memória do processo remoto (PE Injection é semelhante ao PE Hollowing sem desmapear o módulo principal original) com uma combinação de APIs WIN ( VirtualAllocEx,  VirtualProtectEx,  WriteProcessMemory,  CreateRemoteThreadEx) e nenhum arquivo é descartado no disco .

Entre os principais produtos BoxedApp construídos sobre o BoxedApp SDK estão  BoxedApp Packer  e  BxILMerge . Embora o BoxedApp Packer possa empacotar PEs nativos e .NET, o último é puramente adaptado para aplicativos .NET.

Empacotador BoxedApp

BoxedApp Packer é um utilitário que compacta o aplicativo em um binário PE independente (são suportados aplicativos nativos e .NET). O binário PE independente é um único binário executável com todos os arquivos dos quais o aplicativo original de destino depende, como controles ActiveX e bibliotecas dinâmicas, “comprimidos” nesse único arquivo. Em outras palavras, o empacotador cria um ambiente de trabalho individual (virtual) para a aplicação.

Os outros arquivos e registros dos quais o aplicativo de destino depende podem ser incorporados ao armazenamento virtual (criando arquivos e registros virtuais). As interceptações de E/S do BoxedApp (ligação inline de certas APIs WIN/NT) manipulam arquivos virtuais e registros na memória, resultando em nenhum arquivo descartado no disco e criando um sistema de registro falso (virtual).

Se uma compactação for selecionada, o conteúdo dos arquivos incorporados no armazenamento virtual será compactado com o  algoritmo Zlib – DEFLATE  . Ao compactar um binário PE nativo com a opção compress, o binário compactado original ainda poderá ser lido no disco. Não está compactado; apenas o armazenamento virtual é compactado.

No entanto, no caso de compactar um binário .NET PE com a opção compress, o   binário PE nativo  do stub compactado DotNetAppStub  ainda pode ser lido no disco e não compactado; o binário .NET PE original e o armazenamento virtual são compactados.

A estrutura do binário PE nativo compactado original:

• O  binário PE nativo compactado original  (as importações destruídas, resolvidas durante o tempo de execução via retorno de chamada TLS) – não afetado pela opção de compactação:
  • Arquivos/Registros Virtuais incorporados ao Armazenamento Virtual, na  .bxpck seção PE – afetados pela opção de compactação.
  • bxsdk32.dll/bxsdk64.dll – Versão 32/64 bits da DLL nativa, dependendo da arquitetura (a parte principal do BoxedAppSDK), na  .main seção PE – não afetada pela opção de compactação:
    • BoxedAppSDK_AppDomainManager.dll – Versão de 32/64 bits da DLL .NET.
    • BoxedAppSDKThunk.dll – Versão de 32/64 bits da DLL nativa.
    • TLSSupport.dll – Versão de 32/64 bits da DLL nativa (biblioteca auxiliar BoxedApp configurando o retorno de chamada DllMain).

A estrutura do binário .NET PE original embalado:

Quando o BoxedApp Packer é usado para empacotar um aplicativo .NET, um PE nativo stub especial  DotNetAppStub é criado que agrupa o .NET PE original na  .bxpck seção logo acima do Armazenamento Virtual. O  binário Packed Stub Native PE  é responsável pela inicialização dos componentes internos do BoxedApp, onde segue a execução na memória do .NET PE original.

• O  binário Packed Stub Native PEDotNetAppStub  – versão 32/64 bits, dependendo da arquitetura do binário .NET PE original (inicialização via TLS Callback) – não afetado pela opção de compactação:
  • Binário .NET PE original , na  .bxpck seção PE – afetado pela opção de compactação.
  • Arquivos/Registros Virtuais incorporados ao Armazenamento Virtual, na  .bxpck seção PE – afetados pela opção de compactação.
  • bxsdk32.dll/bxsdk64.dll – Versão 32/64 bits da DLL nativa, dependendo da arquitetura (a parte principal do BoxedAppSDK), na  .main seção PE – não afetada pela opção de compactação:
    • BoxedAppSDK_AppDomainManager.dll – Versão de 32/64 bits da DLL .NET.
    • BoxedAppSDKThunk.dll – Versão de 32/64 bits da DLL nativa.
    • TLSSupport.dll – Versão de 32/64 bits da DLL nativa (biblioteca auxiliar BoxedApp configurando o retorno de chamada DllMain).

BoxedApp BxILMerge

BxILMerge é semelhante ao  ILMerge , um utilitário que mescla vários assemblies .NET em um único assembly. No entanto, ele também pode agrupar DLLs/PEs não gerenciados e quaisquer outros arquivos, como arquivos de dados, imagens, vídeos e bancos de dados. BxILMerge fornece suporte para empacotar assemblies gerenciados, suas dependências não gerenciadas e outros arquivos em um assembly .NET de arquivo único que usa a lógica interna do BoxedApp para lidar com quaisquer interações com eles.

Os arquivos mesclados adicionais (assemblies .NET, DLLs não gerenciadas e outros arquivos) são incorporados aos recursos de assembly .NET compactados resultantes. Um construtor de módulo criado (uma parte do assembly .NET compactado) é responsável pela inicialização de um resolvedor de assembly personalizado e armazenamento virtual, onde todos os arquivos mesclados que fazem parte dos recursos do assembly .NET compactado se tornam parte deste armazenamento virtual como arquivos virtuais. Todas as operações de E/S que interagem com esses arquivos virtuais (por exemplo, carregamento de dependência de Assemblies .NET referenciados, DLLs não gerenciadas) são tratadas por meio de interceptações BoxedApp de maneira semelhante ao caso do BoxedApp Packer (ligação inline de certas APIs WIN/NT ). Nenhum arquivo é descartado no disco.

A estrutura do binário .NET PE original embalado:

• O  binário .NET PE original embalado  – construtor de módulo, resolvedor de montagem personalizado, inicialização de armazenamento virtual, código gerenciado original:
  • BoxedAppSDK.Managed.dll – Versão AnyCPU (wrapper gerenciado para BoxedAppSDK), incorporada em recursos .NET do binário .NET PE compactado:
    • Ambas  bxsdk32.dll e  bxsdk64.dll – versões de 32/64 bits de DLLs nativas (a parte principal do BoxedAppSDK), incorporadas em recursos .NET do  BoxedAppSDK.Managed.dll:
      • BoxedAppSDK_AppDomainManager.dll – Versão de 32/64 bits da DLL .NET.
      • BoxedAppSDKThunk.dll – Versão de 32/64 bits da DLL nativa.
      • TLSSupport.dll – Versão de 32/64 bits da DLL nativa (biblioteca auxiliar BoxedApp configurando o retorno de chamada DllMain).
  • BxIlMerge.Api.dll – Versão AnyCPU (assembly gerenciado interagindo com  BoxedAppSDK.Managed.dll, inicialização de componentes internos do BoxedApp, armazenamento virtual, criação de arquivos virtuais), incorporada em recursos .NET do binário .NET PE compactado.
  • Arquivos mesclados adicionais que farão parte do armazenamento virtual inicializado (criação de arquivos virtuais), incorporados nos recursos .NET do binário .NET PE compactado.

Com nossa compreensão das estruturas binárias compactadas por diferentes produtos BoxedApp, descompactar o binário PE original e todos os arquivos virtuais é uma tarefa relativamente simples. Embora a abordagem estática possa ser usada para extrair arquivos que fazem parte do armazenamento virtual (por exemplo,  recurso DIE  – Extrator, editor HEX), recomendamos a abordagem dinâmica para despejar o PE compactado da memória e reconstruir o IAT resolvido em tempo de execução. que foi destruído pelo algoritmo de empacotamento (por exemplo, combinação de  x64dbg  e  Scylla ). Infelizmente, as ferramentas existentes para descompactação estática (por exemplo,  unboxed ) não são tão boas ou confiáveis.

Conclusão

Monitoramos o abuso crescente de produtos BoxedApp por alguns meses e descobrimos como esses produtos são usados ​​para implantar inúmeras famílias de malware conhecidas, principalmente relacionadas a RATs e ladrões. A maioria das amostras maliciosas atribuídas foi usada em ataques contra instituições financeiras e indústrias governamentais. O empacotamento de cargas maliciosas permitiu que os invasores reduzissem a detecção de ameaças conhecidas, reforçassem suas análises e usassem os recursos avançados do BoxedApp SDK (por exemplo, armazenamento virtual) sem a necessidade de desenvolvê-los do zero.

Embora o BoxedApp esteja disponível há vários anos, no ano passado houve um aumento significativo no seu abuso. Entre os principais produtos BoxedApp abusados ​​estão BoxedApp Packer e BxILMerge, ambos construídos sobre o BoxedApp SDK. Ambos os produtos oferecem aos invasores uma oportunidade direta de aproveitar os recursos mais interessantes do SDK, mas o próprio BoxedApp SDK abre espaço para criar um empacotador personalizado e exclusivo que aproveita os recursos mais avançados e é diversificado o suficiente para evitar detecção estática.

Ao realizar uma análise aprofundada dos componentes internos do BoxedApp, com foco principal nas estruturas binárias resultantes compactadas por diferentes produtos, ganhamos e compartilhamos conhecimento suficiente que pode ajudar na descompactação do Armazenamento Virtual e na reconstrução dos principais binários maliciosos. As assinaturas Yara fornecidas podem ser usadas para detectar estaticamente o empacotador em uso e, ao mesmo tempo, distinguir o produto em si.

Crianças

importar “pe”

regra Packer_BoxedApp {

meta:

description = “Detecta binário .NET/Native PE compactado por BoxedApp Packer/BxILMerge”

autor = “Jiri Vinopal @ Check Point Research”

data = “29/04/2024”

modificado = “2024-04-29”

referência = “https://www.boxedapp.com/”

hash = “77c30d1e3f12151b4e3d3090355c8ce06582f4d0dd3cdb395caa836bd80a97f6” // Binário PE nativo compactado pelo BoxedApp Packer

hash = “c76d2e396d654f6f92ea7cd58d43e739b9f406529369709adece23638436cd25” // Binário .NET PE compactado pelo BoxedApp Packer

hash = “aefaf8401437262004d384c8f92968cfee9f5563d13c35b347c9f9eefccab7fc” // Binário .NET PE compactado por BoxedApp BxILMerge

tags = “BoxedApp”

ferramenta = “BoxedApp”

cordas:

$boxedapp_s1 = “bxsdk” largura ascii

$boxedapp_s2 = “BoxedAppSDK_Init” ascii

$boxedapp_dotnet1 = “BoxedAppSDK.Managed” em formato ascii

$boxedapp_dotnet2 = “BxIlMerge.Api” em largura ascii

doença:

uint16 ( 0 ) == 0x5a4d e uint16 ( uint32 ( 0x3c )) == 0x4550 e (

( todos ( $boxedapp_s* ) e para qualquer seção em pe.sections : ( section . name ==

” .bxpck” )) ou

( todos eles e pe. data_directories [ pe. IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR ] . virtual_address != 0 ))

}

importar “pe”

regra Packer_BoxedAppPacker_Native {

meta:

description = “Detecta binário PE nativo compactado pelo BoxedApp Packer (o resultado é binário PE nativo)”

autor = “Jiri Vinopal @ Check Point Research”

data = “29/04/2024”

modificado = “2024-04-29”

referência = “https://www.boxedapp.com/boxedapppacker/”

hash = “77c30d1e3f12151b4e3d3090355c8ce06582f4d0dd3cdb395caa836bd80a97f6”

tags = “BoxedApp”

ferramenta = “BoxedApp”

cordas:

$boxedapp_s1 = “bxsdk” largura ascii

$boxedapp_s2 = “BoxedAppSDK_Init” ascii

$boxedapp_dotnet1 = “DotNetAppStub” ascii

doença:

uint16 ( 0 ) == 0x5a4d e uint16 ( uint32 ( 0x3c )) == 0x4550 e

todos ( $ boxedapp_s* ) e não $boxedapp_dotnet1 e

para qualquer seção em pe. seções : ( seção. nome == “.bxpck” )

}

importar “pe”

regra Packer_BoxedAppPacker_Dotnet {

meta:

description = “Detecta binário .NET PE compactado pelo BoxedApp Packer (o resultado é binário PE nativo)”

autor = “Jiri Vinopal @ Check Point Research”

data = “29/04/2024”

modificado = “2024-04-29”

referência = “https://www.boxedapp.com/boxedapppacker/”

hash = “c76d2e396d654f6f92ea7cd58d43e739b9f406529369709adece23638436cd25”

tags = “BoxedApp”

ferramenta = “BoxedApp”

cordas:

$boxedapp_s1 = “bxsdk” largura ascii

$boxedapp_s2 = “BoxedAppSDK_Init” ascii

$boxedapp_dotnet1 = “DotNetAppStub” ascii

doença:

uint16 ( 0 ) == 0x5a4d e uint16 ( uint32 ( 0x3c )) == 0x4550 e

todos ( $boxedapp_ * )

e

para qualquer seção em pe. seções : ( seção. nome == “.bxpck” )

}

importar “pe”

regra Packer_BoxedAppBxILMerge_Dotnet {

meta:

description = “Detecta binário .NET PE compactado por BoxedApp BxILMerge (resultado é binário .NET PE)”

autor = “Jiri Vinopal @ Check Point Research”

data = “29/04/2024”

modificado = “2024-04-29”

referência = “https://github.com/boxedapp/bxilmerge”

hash = “aefaf8401437262004d384c8f92968cfee9f5563d13c35b347c9f9eefccab7fc”

tags = “BoxedApp”

ferramenta = “BoxedApp”

cordas:

$boxedapp_s1 = “bxsdk” largura ascii

$boxedapp_s2 = “BoxedAppSDK_Init” ascii

$boxedapp_dotnet1 = “BoxedAppSDK.Managed” em formato ascii

$boxedapp_dotnet2 = “BxIlMerge.Api” em largura ascii

doença:

uint16 ( 0 ) == 0x5a4d e uint16 ( uint32 ( 0x3c )) == 0x4550 e

todos ( $boxedapp_ * )

e

educaçao Fisica. diretórios_dados [ pe. IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR ] . endereço_virtual ! = 0

}

Referências

BoxedApp:  https://www.boxedapp.com/
Empacotador BoxedApp:  https://www.boxedapp.com/boxedapppacker/
BxILMerge:  https://www.boxedapp.com/boxedappsdk/usecases/ilmerge_ungestion_dll.html
BxILMerge:  https://github.com/boxedapp/bxilmerge
ILMerge:  https://github.com/dotnet/ILMerge
SDK do BoxedApp:  https://www.boxedapp.com/boxedappsdk/