SourTrade la malvertising que arma el ejecutable en el navegador y evita la detección por firmas

La operación de malvertising apodada SourTrade representa una variante técnica interesante y preocupante: en lugar de servir un ejecutable malicioso completo desde una URL fija, obliga al navegador de la víctima a construir el binario final en el lado del cliente combinando un runtime legítimo (Bun) con fragmentos controlados por el atacante y datos pseudoaleatorios. Según el análisis público, la campaña ha estado activa desde finales de 2024 y ha utilizado suplantaciones convincentes (TradingView, Solana, Luno) para atraer a traders minoristas y usuarios de criptomonedas en múltiples países y lenguas.

Lo novedoso desde el punto de vista técnico no es una explotación de un fallo del navegador, sino una orquestación de APIs web estándar: el landing page registra un ServiceWorker, crea un SharedWorker embebido y solicita a un endpoint /config una plantilla y valores de sesión. A partir de ahí, el navegador descarga un Bun "limpio" y los fragmentos del ejecutable (PE header, tablas de secciones y una sección .bun con bytecode) en Base64; el worker genera un flujo de bytes con AES-CTR y reensambla el ejecutable siguiendo la plantilla, pasando finalmente el archivo al ServiceWorker para que sea servido como descarga con un Content-Disposition. El resultado práctico es que no existe un “malware terminado” transitando con un hash estable, lo que complica las detecciones basadas en firmas estáticas.

Hay algunas contramedidas técnicas y limitaciones que conviene subrayar. Primero, la técnica no elimina la Marca de la Web (Mark of the Web), de modo que Windows seguirá registrando la página de origen como fuente de la descarga; esto mantiene un rastro forense, aunque puede ocultar el dominio que suministró el runtime. Segundo, la campaña no necesita una vulnerabilidad de navegador: su éxito depende de que la víctima descargue o ejecute el binario entregado desde la página maliciosa, y de que confíe en un instalador obtenido a través de un anuncio suplantado.

Las implicaciones para defensores y usuarios son claras: el problema es de cadena completa. Bloquear o vigilar únicamente el archivo final —cuando no existe de forma íntegra en la red— es insuficiente. Los equipos de respuesta y detección deben instrumentar y correlacionar señales de todo el flujo: referencia del anuncio, comportamiento de fingerprinting en la landing page, registro de ServiceWorker/SharedWorker, peticiones a /config, fetches a dominios secundarios que entregan runtimes (por ejemplo los dominios que alojan binarios de Bun en los incidentes examinados) y la aparición de grandes blobs Base64 o patrones de streaming de descargas.

En términos prácticos para usuarios y administradores, las recomendaciones prioritarias no varían con respecto a otras campañas de malvertising orientadas a descargas: instalar software de trading o wallets solo desde las webs oficiales del proveedor, desconfiar de anuncios que prometen descargas rápidas o atajos, y preferir firmas digitales y canales oficiales. Para organizaciones, conviene aplicar políticas de aislamiento de descargas (por ejemplo descargas auditadas o ejecutadas en entornos contenedorizados o sandboxes), políticas de lista blanca para instaladores y controles EDR/NDLP que registren ejecuciones iniciadas por procesos “inusuales” o por archivos descargados desde páginas externas.

Desde la capa técnica avanzada, hay medidas concretas que las defensas pueden implementar: instrumentar logs para detectar registros de ServiceWorker/SharedWorker y respuestas a /config, bloquear el hosting de runtimes no autorizados en la red saliente, y crear reglas que correlacionen navegación desde anuncios a descargas servidas vía streams con cabeceras Content-Disposition. También es útil generar reglas de detección que busquen fragmentos Base64 masivos en respuestas de configuración o el uso de nombres de mensajes característicos de bibliotecas de streaming (como la arquitectura de StreamSaver) que la campaña ha usado en sus iteraciones anteriores. Estas señales no son infalibles, pero permiten trazar la cadena completa que sí queda en la red aunque el binario final varie por sesión.

No existe un “parche” de navegador para este patrón: la defensa técnica eficaz combina políticas de navegación, educación de usuarios y telemetría completa. La adopción de aislamiento de navegación (browser isolation), restricciones de descarga por políticas de grupo en entornos corporativos y el análisis automático de los artefactos registrados por MotW y por los ServiceWorkers son palancas prácticas. Para entender los límites técnicos de la Marca de la Web puede consultarse la documentación de Microsoft sobre MotW: https://learn.microsoft.com/en-us/windows/win32/wintrust/mark-of-the-web.

Para quien investiga o construye detecciones, es relevante conocer el runtime implicado: Bun es un entorno JavaScript/TypeScript con capacidades para compilar y empaquetar aplicaciones, y su uso legítimo explica por qué los atacantes recurren a él como base para ensamblar ejecutables en el navegador; más información técnica sobre Bun está disponible en su web oficial: https://bun.sh. Asimismo, la arquitectura de descargas por streaming que empleó la campaña en fases previas se apoya en patrones conocidos (StreamSaver), cuya implementación pública puede ayudar a identificar variaciones: https://github.com/jimmywarting/StreamSaver.js.

Finalmente, para equipos de respuesta: conservar y correlacionar artefactos es esencial. Si se dispone de capturas de red y registros del navegador, buscar las peticiones a /config, los dominios secundarios que sirvieron runtimes, los eventuales blobs Base64 y la cadena de mensajes entre la página, el SharedWorker y el ServiceWorker permitirá reconstruir la muestra aun cuando cada sesión produzca un hash distinto. La realidad operativa es que esta técnica complica indicadores estáticos, pero deja múltiples huellas dinámicas y de infraestructura que, bien instrumentadas, permiten detección y mitigación.