La amenaza Miasma expone la fragilidad de npm y convierte GitHub en vector de robo de credenciales

Una nueva oleada de manipulación de la cadena de suministro de paquetes JavaScript, detectada bajo el nombre de campaña "Miasma", ha vuelto a demostrar lo frágil que es el ecosistema npm cuando un actor malicioso consigue contaminar paquetes populares relacionados con servicios en la nube. El vector inicial parece haber sido la toma de una cuenta de GitHub de un empleado de Red Hat, lo que permitió introducir commits huérfanos y cargar código malicioso en paquetes usados por desarrolladores y sistemas de CI/CD.

Los análisis públicos de varias firmas de seguridad muestran que el malware se activa en tiempo de instalación y está diseñado para robar credenciales y secretos locales y de CI: tokens de npm, secretos de GitHub Actions, claves SSH, credenciales de nube (GCP, Azure), material de Kubernetes y Vault, además de archivos de configuración de herramientas de desarrollo. La amenaza se complementa con un mecanismo de exfiltración cifrada y con un canal de respaldo por medio de repositorios públicos de GitHub controlados por los atacantes, lo que les permite tanto robar datos como intentar propagar el compromiso hacia otras dependencias y pipelines.

Lo más preocupante es la sofisticación operativa: el malware emplea intercambio OIDC para tokens, repaqueta y firma artefactos con Sigstore, utiliza la API de GitHub para crear commits aparentemente verificados y puede insertar workflows o cambios en pipelines para persistir o activar nuevas etapas maliciosas. Algunas variantes generan una carga cifrada única por cada infección, dificultando tanto la detección por firmas como el seguimiento de variantes.

En términos de atribución y motivación, la situación es ambigua. El hecho de que herramientas asociadas a la familia Shai-Hulud hayan sido publicadas por un conocido grupo criminal complica la identificación del autor real del ataque: el código abierto de una amenaza permite que múltiples actores repliquen campañas con mínimos cambios, reduciendo la trazabilidad y elevando el riesgo de imitadores.

Para equipos técnicos y responsables de seguridad la lista de impactos posibles es larga: desde el compromiso de cuentas de nube hasta la contaminación de imágenes de contenedor, paquetes publicados o artefactos de build que luego se distribuyan a usuarios finales. En entornos con integración continua, una credencial robada que permita escribir en repositorios o lanzar workflows puede transformar un incidente local en una propagación a escala. La exfiltración cifrada y el uso de commits como canal de fuga convierten a GitHub en un vector doble: objetivo y vehículo.

La respuesta inmediata debe combinar contención y forense: aislar máquinas que hayan instalado versiones comprometidas, suspender ejecuciones de CI afectadas y revocar cualquier token o credencial que pudiera haber estado presente en esos entornos. Es crucial no limitarse a desinstalar los paquetes; la campaña incluye mecanismos de persistencia en herramientas de desarrollo (por ejemplo, hooks para editores y runners) que requieren una auditoría completa del host y restauración desde imágenes limpias cuando proceda. Rotar claves, invalidar OIDC/tokens y auditar commits y workflows en GitHub son pasos ineludibles.

En el plano preventivo, las organizaciones deben reforzar controles sobre cuentas con capacidad de publicar paquetes o modificar workflows: aplicar acceso con el menor privilegio posible, forzar autenticación multifactor, exigir revisiones de código y habilitar políticas de restricción de tokens en los runners. Además, emplear herramientas que verifiquen la procedencia de paquetes y artefactos —como modelos de atestación de suministro o soluciones de escaneo de la cadena de suministro— reduce la probabilidad de que un paquete contaminado llegue sin ser detectado a entornos críticos.

También conviene incorporar detección basada en comportamiento que busque señales atípicas: llamadas a APIs de terceros desde procesos de instalación, creación de commits automáticos que incluyan cambios en acciones de GitHub, o la presencia de archivos y hooks de persistencia en directorios de usuario. Para consultar buenas prácticas y recursos sobre seguridad en repositorios y supply chain puede consultarse la documentación de seguridad de plataformas líderes y el blog de seguridad de GitHub, así como los análisis técnicos publicados por proveedores de seguridad como Microsoft y JFrog. Blog de seguridad de GitHub y Blog de Seguridad de Microsoft ofrecen guías y avisos relevantes.

Finalmente, este incidente recuerda que la higiene de identidad y la protección de cuentas de desarrolladores son parte integral de la seguridad empresarial. Minimizar credenciales persistentes en estaciones de trabajo y runners, usar credenciales efímeras y auditar con frecuencia los permisos en repositorios y proyectos en la nube son medidas que reducen la ventana de exposición. Las organizaciones deben asumir que la contaminación de la cadena de suministro puede suceder y diseñar procesos para contener, erradicar y recuperarse con rapidez sin depender únicamente de la desinstalación de paquetes.