GlassWorm se Cambia a Mac: Nueva Infraestructura, Nuevos Trucos

Resumen

El actor de amenaza detrás de GlassWorm ha pasado de actividades enfocadas en Windows a macOS, distribuyendo extensiones maliciosas de VS Code que obtienen cargas útiles de JavaScript encriptadas a través de punteros C2 derivados de la blockchain de Solana. Esta ola amplía su capacidad al añadir troyanización de monederos de hardware mientras continúa con el robo de credenciales a gran escala a través de navegadores, herramientas de desarrollo y el llavero de macOS. La infraestructura incluye una dirección de monedero de Solana y una IP reutilizada de operaciones anteriores de GlassWorm, lo que sugiere continuidad en las herramientas y alojamiento del operador. Los investigadores observaron más de 50,000 descargas antes de que las extensiones fueran eliminadas, indicando una exposición significativa en entornos de desarrollo.

Investigación

Koi Security identificó tres extensiones maliciosas de VS Code en el mercado Open VSX y vinculó su flujo de trabajo de comando y control a un monedero de Solana más una dirección IP compartida previamente asociada a GlassWorm. Los implantes incorporan un retraso de ejecución de 15 minutos, luego desencriptan y ejecutan una carga útil de JavaScript AES-256-CBC. En macOS, la persistencia se establece a través de LaunchAgents. Los objetivos de recopilación incluyen monederos de navegador y datos de monederos de escritorio, tokens de acceso de desarrolladores, claves SSH y material del llavero de macOS. El malware almacena datos robados en /tmp/ijewf/ antes de la exfiltración hacia una ruta de servidor que se asemeja a /p2p. También intenta reemplazar aplicaciones de acompañamiento de moneders de hardware legítimas, como Ledger Live y Trezor Suite, con versiones troyanizadas para capturar secretos y transacciones de alto valor.

Mitigación

Refuerza los controles en las herramientas de desarrollo al hacer cumplir la lista blanca de extensiones y requerir una revisión de seguridad para las extensiones de VS Code, particularmente aquellas provenientes de mercados abiertos. Despliega detecciones en tiempo de ejecución para patrones de ejecución retrasada y creación o modificación sospechosa de LaunchAgents. Monitorea y bloquea la actividad saliente sospechosa asociada con búsquedas de C2 derivadas de Solana, y agrega detecciones de red para conexiones inusuales hacia la IP identificada reutilizada. Requiere MFA para cuentas de desarrolladores y en la nube e implementa verificaciones de integridad en monederos de hardware (validación de editor, notarización/verificación de firma y canales controlados de actualizaciones de software).

Respuesta

Genera alertas sobre LaunchAgents nuevos o modificados, acceso anómalo a almacenes del llavero y intentos de recuperación desde puntos de referencia C2 en Solana. Aísla y elimina las extensiones maliciosas de VS Code, luego erradica cualquier persistencia asociada con LaunchAgent. Realiza forenses dirigidos en /tmp/ijewf/ para delimitar el almacenamiento de credenciales y confirmar qué datos se recopilaron. Valida la integridad de las aplicaciones de monederos de hardware (Ledger Live, Trezor Suite) y reinstala desde fuentes confiables si se sospecha manipulación. Restaura credenciales afectadas, rota claves SSH y tokens de desarrolladores, invalida sesiones, y amplía la caza en los endpoints para los mismos IDs de extensiones, rutas de archivos y artefactos de persistencia.

Ejecución de Simulación

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

Justificación: 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 TTPs identificados y tienen como objetivo generar la telemetría exacta esperada por la lógica de detección. Ejemplos abstractos o no relacionados conducirán a diagnósticos erróneos.

• Narrativa del Ataque y Comandos:
  Un atacante que ya ha comprometido una cuenta de usuario de macOS con privilegios bajos desea recolectar una contraseña de cuenta de servicio almacenada en el Llavero bajo la etiqueta pass_users_for_script. Para evitar dejar caer un binario separado, el atacante escribe un AppleScript de una línea que invoca la herramienta incorporada security a través de do shell script. El script se ejecuta directamente en la sesión del usuario, produciendo un evento de creación de proceso con la línea de comando exacta que la regla Sigma coincide.

  # Crear un elemento de llavero de prueba (solo para demostración; un atacante real apuntaría a un elemento existente)
  security add-generic-password -a attacker -s pass_users_for_script -w SuperSecret123
  
  # Ejecutar el AppleScript que lee la contraseña
  osascript -e 'do shell script "security find-generic-password -s '''pass_users_for_script''' -w"'

• Script de Prueba de Regresión:

  #!/usr/bin/env bash
  set -euo pipefail
  
  # Paso 1: Asegurarse de que la entrada de llavero objetivo exista (idempotente)
  if ! security find-generic-password -s pass_users_for_script -w >/dev/null 2>&1; then
      security add-generic-password -a attacker -s pass_users_for_script -w SuperSecret123
  fi
  
  # Paso 2: Ejecutar el AppleScript que activa la regla de detección
  echo "[+] Ejecutando AppleScript para leer la entrada del llavero..."
  osascript -e 'do shell script "security find-generic-password -s '''pass_users_for_script''' -w"'

• Comandos de Limpieza:

  # Eliminar el elemento de llavero de prueba para dejar el sistema limpio
  security delete-generic-password -s pass_users_for_script
  echo "[+] Limpieza completada: entrada de llavero de prueba eliminada."