Campaña de suministro de paquetes infecta npm y PyPI con binario Go sckit y robo de credenciales

Una campaña de suministro de paquetes ha comprometido recientemente componentes legítimos usados por desarrolladores y pipelines de integración continua para distribuir una herramienta maliciosa multiplataforma. Los atacantes insertaron un binario Go llamado "sckit" en versiones concretas de un paquete npm y de un paquete en PyPI, y el código malicioso se activa automáticamente al cargar la dependencia o al procesar eventos de memoria en tiempo de ejecución. Informes de Aikido, SafeDep, Socket y StepSecurity confirman la afectación de las versiones 0.1.21, 0.1.23 y 0.1.25 del paquete npm @memtensor/memos-cloud-openclaw-plugin y de la versión 2.0.34 del paquete PyPI MemoryOS (esta última ha sido puesta en cuarentena en PyPI). Puede consultarse el paquete npm en su registro público en npmjs.com y la entrada afectada del ecosistema Python en pypi.org.

En lo que está verificado hasta ahora, las versiones maliciosas incluyen un cargador que lanza el binario Go cuando se inicializa el plugin (en el caso de npm) o cuando el módulo "memos" se importa (en PyPI). El ejecutable está compilado de forma estática y actúa como un ladrón de credenciales: recolecta ficheros de configuración y tokens (.npmrc, .vault-token, id_ecdsa, credentials.db, access_tokens.json, stored_tokens), variables de entorno que contienen claves (NPM_TOKEN, PYPI_API_TOKEN, etc.), y claves o tokens de servicios como AWS, GitHub, GitLab, Hugging Face, HashiCorp Vault, Slack, Stripe y SendGrid. El malware exfiltra esta información a un servidor de comando y control alojado bajo el dominio reportado por las firmas de análisis como skyleen.fr.

Técnicamente, cómo funciona la intrusión: el vector inicial fue la publicación maliciosa de nuevas versiones de bibliotecas legítimas. SafeDep documenta que los atacantes consiguieron publicar estos paquetes aprovechando tokens de publicación disponibles en los pipelines de GitHub Actions del proyecto MemTensor; concretamente, introdujeron commits que dispararon workflows que exponían o facilitaron el uso del token de publicación. Una vez distribuido el paquete, el binario sckit se ejecuta en el contexto del proceso que carga la dependencia, lo que le permite heredar variables de entorno y acceso al mismo usuario y sistema de ficheros que la aplicación o job de CI donde se importó la dependencia.

Además, el análisis del malware indica capacidades de autopropagación: plantillas y mecanismos para insertar la carga útil en paquetes npm, paquetes Python y workflows de GitHub Actions, lo que le permite comportarse de forma worm-like y publicar por sí mismo nuevas versiones maliciosas si obtiene tokens válidos. En términos prácticos, esto significa que un equipo con acceso a repositorios, credenciales de publicación o con workflows con privilegios excesivos podría facilitar la propagación automática a otros proyectos y cuentas.

Quiénes son los afectados y por qué importa: la víctima primaria son las máquinas de desarrolladores y los jobs de CI que instalen o importen las versiones comprometidas. Dado que el plugin afecta a un componente diseñado para integrarse en agentes de "memoria" para herramientas de IA y runtime de agentes, los procesos infectados suelen manejar texto de usuario, prompts y credenciales temporales o permanentes, por lo que la exposición puede incluir secretos inyectados para una tarea concreta. En práctica, esto pone en riesgo repositorios, cuentas de servicios en la nube, tokens de paquetes y secretos usados por pipelines, con el potencial de escalada (reutilización de credenciales, publicación de versiones maliciosas, movimiento lateral en infraestructuras de CI/CD).

Hechos confirmados: las versiones señaladas de los paquetes contienen el binario y el launcher maliciosos; el dominio de exfiltración reportado es skyleen.fr; la técnica de obtención del token de publicación involucró pipelines de GitHub Actions del proyecto; PyPI ha puesto en cuarentena la versión afectada. Estimaciones y elementos aún inciertos: no está plenamente confirmado el alcance total (si hay otros paquetes comprometidos además de MemTensor), la autoría del actor que puso la carga útil ni el número de organizaciones afectadas. Los análisis también sugieren, pero no garantizan, que la campaña está diseñada para auto-propagarse cuando consigue credenciales suficientes.

Qué debe hacer un equipo de desarrollo o una organización ahora: las medidas son urgentes y concretas. Primero, pinnear dependencias a versiones seguras: para el paquete npm, volver a la versión 0.1.20; para PyPI, a la 2.0.33, según los análisis disponibles. Segundo, revocar y rotar inmediatamente cualquier credencial que pudiera haber estado en el entorno del proceso (tokens de npm/PyPI, claves AWS, tokens de GitHub/GitLab, secretos de Vault, etc.). Tercero, buscar y detener procesos sospechosos llamados o que ejecuten "sckit" y eliminar binarios no reconocidos en entornos de desarrollo y runners de CI; además bloquear el dominio de C2 y sus subdominios a nivel de red y proxy (skyleen.fr y variantes).

Acciones técnicas de detección y contención recomendadas: buscar trazas de "skyleen" y de nombres de binario en repositorios y artefactos: grep -R "skyleen" . /var && ps aux | grep sckit || true; comprobar ficheros de tokens (.npmrc, credentials.db, .vault-token, id_ecdsa) por modificaciones recientes, comparar checksums con builds esperados, revisar logs de GitHub Actions en busca de commits o workflows no autorizados y auditar la configuración de secrets en repositorios. Auditad qué cuentas y workflows tienen permisos de publicación y eliminad tokens de publicación embebidos en repositorios; en su lugar, usar mecanismos de federación temporal como OIDC y principios de menor privilegio (ver guía de GitHub sobre OIDC: Configuring OpenID Connect in your workflow).

Medidas de mitigación a medio plazo: habilitar escaneo de secretos en commits y en artefactos, forzar 2FA en cuentas relevantes, restringir permisos de los runners de CI, rotar claves de largo uso a credenciales de corta duración, auditar y limitar tokens de publicación, generar SBOMs y firmar artefactos y releases para detectar modificaciones no autorizadas. También es clave revisar los puntos de integración de terceros (bots, plugins, agentes de memoria) y tratar las dependencias como activos que requieren control de cambios y verificación de integridad.

Por último, no se debe asumir que la incidencia está contenida hasta completar una revisión forense. Si su organización utilizó las versiones comprometidas, proceda con la rotación de secretos, una búsqueda exhaustiva de contaminación en repositorios y runners, y una reconstrucción de artefactos desde fuentes limpias. Si detecta publicaciones no autorizadas hechas por sus cuentas o workflows, investigue inmediatamente y, de ser necesario, contacte con los proveedores de registro (npm, PyPI, GitHub) para asistencia en la remediación y notificación.

El episodio subraya que los pipelines automatizados y los tokens de publicación son un objetivo crítico para adversarios interesados en comprometer la cadena de suministro de software. La combinación de binarios multiplataforma y mecanismos para heredar contexto de ejecución convierte dependencias populares en vectores extremadamente potentes: la prevención exige tanto controles técnicos (least privilege, OIDC, rotación de secretos) como operativos (revisiones de commits, monitoreo de CI, bloqueo de dominios maliciosos y respuestas forenses rápidas).