Honeynet UNAMex Lab Logo
Honeynet UNAMex Lab

Malware-Slop en npm: el paquete que robaba archivos de Claude y expuso su propio token de GitHub

Malware-Slop: cuando el paquete malicioso se delata a sí mismo

El 27 de mayo de 2026, investigadores de la firma de seguridad OX Security publicaron el análisis técnico de un paquete malicioso descubierto en el registro público de npm. El paquete, llamado mouse5212-super-formatter, se hacía pasar por una utilidad de formateo pero operaba como un infostealer: robaba archivos del directorio de trabajo del asistente de IA Claude de Anthropic y los exfiltraba hacia una cuenta de GitHub bajo el control del atacante.

Lo que hace este caso particularmente notable —y le da nombre a la campaña, bautizada como Malware-Slop— es que el propio atacante cometió un error operacional elemental: dejó su token privado de GitHub embebido directamente en el código fuente del paquete malicioso, exponiéndolo a cualquiera que revisara el código. Al momento de la publicación del análisis, el paquete acumulaba 676 descargas y permanecía disponible en npm. El paquete fue reportado y posteriormente eliminado del registro.

¿Qué es npm y por qué es un vector de ataque tan atractivo?

Antes de entrar al incidente, conviene situar el contexto. npm (Node Package Manager) es el mayor registro público de paquetes de software del mundo, con más de dos millones de paquetes disponibles y más de 17 millones de descargas diarias. Es la columna vertebral del ecosistema JavaScript y Node.js: prácticamente cualquier proyecto web o de backend moderno depende de decenas o cientos de paquetes externos instalados desde este repositorio.

La propuesta de valor es clara: reutilización y velocidad. En lugar de escribir desde cero funcionalidades ya resueltas —parseo de fechas, formateo de texto, manejo de peticiones HTTP—, los desarrolladores instalan una dependencia en segundos. El problema es estructural: esa confianza es, por defecto, ciega. Cualquier persona puede publicar un paquete en npm. No existe un proceso de revisión de seguridad obligatorio antes de la publicación. Un paquete instalado se ejecuta con los mismos privilegios del proceso que lo invoca, incluyendo scripts automáticos que corren en el momento de la instalación.

Este modelo es exactamente el que mouse5212-super-formatter explotó.

¿Qué es un infostealer y cómo se disfraza este?

Un infostealer es un tipo de malware cuyo objetivo principal no es dañar el sistema ni cifrarlo para pedir rescate, sino recolectar información y enviarla silenciosamente a quien lo controla: credenciales, tokens de acceso, archivos de configuración, documentos. Son difíciles de detectar precisamente porque no interfieren con el funcionamiento normal del sistema; simplemente observan y exportan.

mouse5212-super-formatter adoptaba una cobertura cuidadosamente diseñada para no levantar sospechas:

El análisis de OX Security destaca un detalle revelador: el código evitaba deliberadamente patrones que suelen delatar código generado por IA —como comentarios redundantes o en idiomas no esperados— con la intención de no parecer automatizado. El atacante tomó esa precaución de camuflaje y, al mismo tiempo, dejó su propio token privado embebido en el código. Esa contradicción —cuidado en lo superficial, negligencia en lo crítico— es la firma característica de este tipo de amenaza.

En realidad, ninguna de las funciones declaradas existía. Todo era fachada.

El suceso: cómo funciona el ataque paso a paso

El payload malicioso se activaba durante la etapa de postinstall del ciclo de vida de npm, es decir, en el momento exacto en que el paquete termina de instalarse, sin que el usuario realice ninguna acción adicional. La cadena de ejecución era la siguiente:

Paso 1 — Autenticación en GitHub

El script buscaba primero un token de acceso de GitHub en las variables de entorno del sistema. Si no lo encontraba, recurría a un token embebido directamente en el código como mecanismo de respaldo. Este segundo mecanismo fue el que terminó exponiendo al atacante: el token apuntaba a su propia cuenta de GitHub y era visible en texto plano para cualquiera que revisara el código fuente del paquete.

Paso 2 — Creación del repositorio de exfiltración

Con el token activo, el malware verificaba si existía un repositorio en la cuenta del atacante para almacenar los datos robados. Si no existía, lo creaba automáticamente mediante la API de GitHub.

Paso 3 — Recolección recursiva de archivos

El script recorría de forma recursiva el directorio /mnt/user-data, la ruta que utiliza la herramienta Claude de Anthropic para gestionar archivos de carga y salida en segundo plano. Todo archivo encontrado en esa ruta era candidato para la exfiltración. Los archivos se codificaban en base64 antes de ser enviados, una técnica de ofuscación básica para disimular el contenido saliente ante inspecciones superficiales del tráfico.

Paso 4 — Exfiltración organizada

Los archivos se subían al repositorio del atacante organizados bajo carpetas con nombres aleatorios generadas por sesión. Esto permitía al operador distinguir entre los datos robados de diferentes víctimas sin mezclarlos.

Flujo resumido del ataque

npm install mouse5212-super-formatter
         │
         ▼
Script postinstall se ejecuta automáticamente
         │
         ▼
Autenticación en GitHub (token de env o token hardcodeado)
         │
         ▼
Creación del repositorio de exfiltración si no existe
         │
         ▼
Recorrido recursivo de /mnt/user-data
         │
         ▼
Codificación base64 + upload de archivos vía GitHub Contents API
         │
         ▼
Datos almacenados en carpeta aleatoria del repositorio del atacante

El proceso ocurría de forma completamente silenciosa: no producía errores visibles, no interrumpía el flujo de trabajo del desarrollador y no dejaba rastros evidentes en los logs del sistema.

¿Por qué el directorio de Claude AI es un objetivo valioso?

El directorio /mnt/user-data no es un objetivo elegido al azar. Es la ruta que Claude de Anthropic usa para manejar archivos durante su operación: documentos subidos para análisis, outputs generados, datos de trabajo intermedios. Para un desarrollador que usa Claude en su flujo de trabajo diario, ese directorio puede contener:

Este tipo de ataque representa una evolución en el objetivo del malware: en lugar de apuntar a los sistemas operativos o bases de datos tradicionales, los atacantes empiezan a dirigirse específicamente a las superficies de datos creadas por las herramientas de inteligencia artificial integradas en el flujo de trabajo de los desarrolladores. El escenario es especialmente delicado en entornos corporativos, donde una instancia de Claude puede concentrar en su directorio de trabajo el output de decenas de ingenieros o analistas.

El error que lo delató: el token hardcodeado y la paradoja del Malware-Slop

La característica más significativa del caso —y la que le dio nombre a la campaña Malware-Slop— es el error operacional del propio atacante. En el código fuente del paquete, visible para cualquiera que lo descargara y examinara, estaba incluido el token privado de GitHub del atacante como mecanismo de respaldo para la autenticación.

Ese token fue suficiente para que los investigadores de OX Security pudieran:

El término Malware-Slop captura con precisión esta dinámica: código malicioso generado con descuido, muy probablemente asistido por herramientas de IA generativa, por un actor que no comprende ni aplica principios mínimos de anonimato o seguridad operacional (OPSEC). Este no es un caso aislado. El mismo patrón ya se había documentado a principios de año en VoidLink, un malware para Linux que los investigadores concluyeron fue construido en gran parte mediante un agente de IA dirigido por una sola persona. La IA redujo la barrera para crear el malware; pero también eliminó la fricción que antes obligaba al atacante a adquirir conocimientos básicos de OPSEC antes de operar.

Existe, sin embargo, una advertencia importante frente a la tentación de desestimar estas amenazas por considerarlas “torpes”: incluso el malware imperfecto puede causar daño real si alcanza suficientes usuarios antes de ser detectado. Con 676 descargas antes de su detección, este paquete no fue un experimento fallido, sino un incidente real con potencial genuino de exposición de datos.

OX Security resume el panorama con claridad: ahora que el costo de crear código malicioso se ha reducido significativamente, es previsible un aumento de actores inexpertos publicando malware descuidado, a menudo imitando a grupos más sofisticados, hasta que los registros como npm implementen bloqueo automático sistemático de este tipo de paquetes.

El problema de fondo: ataques a la cadena de suministro de software

Este incidente es un ejemplo concreto de lo que se conoce como un ataque a la cadena de suministro de software (software supply chain attack). La premisa es sencilla y por eso es efectiva: en lugar de comprometer directamente el sistema de la víctima —lo que requiere superar controles de seguridad activos—, el atacante inserta código malicioso en una dependencia de software que la víctima instala voluntariamente.

Los registros públicos de paquetes como npm son la infraestructura sobre la que se construye el desarrollo moderno. Esa confianza es precisamente lo que los atacantes explotan. El desarrollador no instaló malware; instaló lo que parecía una herramienta de formateo. Para quien no revisa el código de cada dependencia —que es la inmensa mayoría de los desarrolladores, por razones prácticas perfectamente justificadas—, no hay señal de alerta visible en el flujo de trabajo habitual.

A esto se suma el riesgo emergente específico de este caso: el malware que apunta a herramientas de IA. Con la proliferación de asistentes integrados en los flujos de trabajo de desarrollo —Claude, GitHub Copilot, Cursor, Gemini Code—, los directorios de trabajo de estas herramientas se convierten en concentradores de información sensible. Son un objetivo de alto valor con una superficie de ataque relativamente nueva y, por tanto, menos vigilada que los vectores tradicionales.

Sistemas y activos afectados

Activos en riesgo para quien instaló el paquete

Alcance del incidente (según el análisis de OX Security)

⚠️ Nota: Si instalaste mouse5212-super-formatter en cualquier entorno, trata los archivos de /mnt/user-data y cualquier token de GitHub disponible en ese entorno como potencialmente comprometidos.

Indicadores de Compromiso (IOC)

Tipo Indicador Descripción
Nombre del paquete mouse5212-super-formatter Paquete npm infostealer; todas las versiones afectadas
Ruta objetivo /mnt/user-data Directorio local recorrido recursivamente para la exfiltración
Método de exfiltración GitHub Contents API Usada para subir los archivos robados al repositorio del atacante
Técnica de ofuscación Codificación base64 Aplicada al contenido de los archivos durante la exfiltración
Cuenta del atacante unplowed3584 (GitHub) Creada horas antes de la publicación; eliminada tras la detección

Recomendaciones de seguridad

Acciones inmediatas si instalaste el paquete

Para evaluar paquetes antes de instalarlos

Para equipos de seguridad y DevSecOps

Recapitulando…

mouse5212-super-formatter es un caso compacto pero revelador de cómo convergen dos tendencias que definirán el panorama de amenazas en los próximos años: el abuso de los ecosistemas de distribución de código abierto como vector de ataque, y el malware diseñado específicamente para apuntar a las superficies de datos generadas por herramientas de inteligencia artificial.

El fallo técnico es simple: un script de postinstall con acceso a red que nadie revisó antes de ejecutarlo. El problema sistémico es más profundo. El registro npm opera sobre un modelo de confianza implícita que no escala bien frente a actores maliciosos con acceso a herramientas que reducen drásticamente el costo de crear código dañino. Cuando generar un infostealer funcional requiere horas en lugar de semanas, el volumen de intentos crece, y con él la probabilidad de que alguno pase desapercibido el tiempo suficiente para causar daño real.

El caso ilustra también la paradoja central del Malware-Slop: la misma IA que bajó la barrera para crear el código eliminó la fricción que antes obligaba al atacante a aprender OPSEC básico. El resultado es malware más frecuente pero más descuidado. A veces, como ocurrió aquí, eso significa que el atacante se delata a sí mismo. Pero incluso un malware torpe puede causar daño real: los 676 usuarios que instalaron este paquete no obtuvieron ninguna ventaja del error del atacante hasta que los investigadores lo descubrieron. La detección temprana fue posible gracias al token expuesto —una ventaja fortuita para los defensores, no un mecanismo de protección estructural.

El mismo patrón se documenta en VoidLink, el malware Linux construido mediante IA por un solo individuo, y en otros incidentes recientes de la cadena de suministro de npm. La tendencia no es nueva, pero la velocidad con que nuevos actores pueden ahora sumarse al juego sí lo es.

La lección no es dejar de usar npm ni abandonar la integración de herramientas de IA en el flujo de trabajo. Es entender que la confianza depositada en una dependencia externa es siempre provisional, y que los directorios de trabajo de los asistentes de IA son hoy tan críticos como cualquier base de datos de producción. Merecen el mismo nivel de vigilancia.

Y en el caso de mouse5212-super-formatter, todo lo que hizo falta fue un npm install.

Fuentes consultadas: