SourTrade o malvertising que arma o executável no navegador e evita a detecção por assinaturas

A operação de malvertising apodada SourTrade representa uma variante técnica interessante e preocupante: em vez de servir um executável malicioso completo a partir de um URL fixo, obriga o navegador da vítima a usar o seu navegador. construir o binário final no lado do cliente combinando um runtime legítimo (Bun) com fragmentos controlados pelo atacante e dados pseudo-aleatorios. De acordo com a análise pública, a campanha tem estado ativa desde o final de 2024 e usou suplantações convincentes (TradingView, Solana, Luno) para atrair traders retalhistas e usuários de criptomoedas em vários países e línguas.

A novidade do ponto de vista técnico não é uma exploração de uma falha do navegador, mas sim uma orquestração de APIs web padrão: o landing page registra um ServiceWorker, cria um SharedWorker embebido e solicita a um endpoint /config um modelo e valores de sessão. A partir daí, o navegador descarrega um Bun "limpio" e os fragmentos do executável (PE header, tabelas de secções e uma seção .bun com bytecode) em Base64; o worker gera um fluxo de bytes com AES-CTR e reensambla o executável seguindo o modelo, passando finalmente o arquivo ao ServiceWorker para ser servido como download com um Content-Disposition. O resultado prático é que não existe um "malware terminado" transitando com um hash estável, o que complica as detecções baseadas em assinaturas estáticas.

Há algumas contramedidas técnicas e limitações que convém sublinhar. Primeiro, a técnica não elimina a Marca da Web (Mark of the Web), de modo que o Windows continuará a gravar a página de origem como fonte de download; isto mantém um rastro forense, embora possa esconder o domínio que forneceu o runtime. Segundo, a campanha não precisa de uma vulnerabilidade de navegador: seu sucesso depende de que a vítima baixe ou execute o binário entregue a partir da página maliciosa, e de que confie em um instalador obtido através de um anúncio suplantado.

As implicações para defensores e usuários são claras: o problema é de cadeia completa. Bloquear ou vigiar apenas o ficheiro final — quando não existe totalmente na rede — é insuficiente. Os equipamentos de resposta e detecção devem instrumentar e correlacionar sinais de todo o fluxo: referência do anúncio, comportamento de fingerprinting na landing page, registro de ServiceWorker/SharedWorker, pedidos a /config, fetches a domínios secundários que entregam runtimes (por exemplo, domínios que hospedam binários de Bun nos incidentes examinados) e o aparecimento de grandes blobs Base64 ou padrões de streaming de downloads.

Em termos práticos para usuários e administradores, as recomendações prioritárias não variam em relação a outras campanhas de malvertising orientadas para downloads: instalar software de negociação ou wallets apenas a partir de sites oficiais do fornecedor, desconfiar de anúncios que prometem downloads rápidos ou atalhos, e preferir assinaturas digitais e canais oficiais. Para organizações, é conveniente aplicar políticas de isolamento de descargas (por exemplo, descargas auditadas ou executadas em ambientes contentorizados ou sandboxes), políticas de lista branca para instaladores e controles EDR/NDLP que registram execuções iniciadas por processos “inusuales” ou por arquivos baixados a partir de páginas externas.

Desde a camada técnica avançada, há medidas concretas que as defesas podem implementar: instrumentar logs para detectar registros de ServiceWorker/SharedWorker e respostas a /config, bloquear a hospedagem de runtimes não autorizados na rede saliente, e criar regras que correlacionem navegação a partir de anúncios a downloads servidos via streams com cabeçalhos Content-Disposition. Também é útil gerar regras de detecção que busquem fragmentos Base64 massivos em respostas de configuração ou uso de nomes de mensagens característicos de bibliotecas de streaming (como a arquitetura do StreamSaver) que a campanha usou em suas iterações anteriores. Estes sinais não são infalívels, mas permitem traçar a cadeia completa que resta na rede, embora o binário final varie por sessão.

Não existe um “parche” de navegador para este padrão: a defesa técnica eficaz combina políticas de navegação, educação de usuários e telemetria completa. A adoção de isolamento de navegação (browser isolation), restrições de descarga por políticas de grupo em ambientes corporativos e a análise automática dos artefatos registrados por MotW e pelos ServiceWorkers são alavancas práticas. Para entender os limites técnicos da Marca da Web, você pode consultar a documentação da Microsoft sobre MotW: https://learn.microsoft.com/en-us/windows/win32/wintrust/mark-of-the-web.

Para quem pesquisa ou constrói detecções, é relevante conhecer o runtime implicado: Bun é um ambiente JavaScript/TypeScript com capacidades para compilar e empacotar aplicativos, e seu uso legítimo explica por que os atacantes recorrem a ele como base para montar executáveis no navegador; mais informações técnicas sobre Bun estão disponíveis em seu site oficial: https://bun.sh. Além disso, a arquitetura de downloads por streaming que utilizou a campanha em fases anteriores apoia-se em padrões conhecidos (StreamSaver), cuja implementação pública pode ajudar a identificar variações: https://github.com/jimmywarting/StreamSaver.js.

Finalmente, para equipes de resposta: conservar e correlacionar artefatos é essencial. Se estiverem disponíveis capturas de rede e registros do navegador, procurar os pedidos para /config, os domínios secundários que serviram runtimes, os eventuais blobs Base64 e a cadeia de mensagens entre a página, o SharedWorker e o ServiceWorker permitirá reconstruir a amostra mesmo que cada sessão produza um hash diferente. A realidade operacional é que esta técnica complica indicadores estáticos, mas deixa múltiplas pegadas dinâmicas e de infraestrutura que, bem instrumentadas, permitem detecção e mitigação.