PhantomRaven la campaña de dependencias remotas que pone en jaque npm

Durante los últimos meses la comunidad JavaScript ha vuelto a recibir un recordatorio incómodo: las cadenas de suministro de software siguen siendo uno de los vectores favoritos para los atacantes. Una campaña conocida como "PhantomRaven", detectada inicialmente a finales de 2025 y ampliada por investigaciones posteriores, ha estado publicando paquetes maliciosos en el registro npm con la intención de robar datos sensibles de desarrolladores y entornos de integración continua.

La peculiaridad técnica de PhantomRaven es su uso de dependencias dinámicas remotas (Remote Dynamic Dependencies, RDD), una táctica simple pero efectiva: en lugar de incrustar el código malicioso dentro del paquete publicado, los atacantes apuntan desde el archivo package.json a una dependencia hospedada en una URL externa. Al ejecutar npm install esa dependencia se descarga desde el servidor del atacante y se ejecuta, eludiendo en muchos casos las comprobaciones estáticas automatizadas que analizan el contenido del paquete en el registro. Puedes ver una explicación técnica de cómo npm interpreta package.json en la documentación oficial de npm: https://docs.npmjs.com/cli/v9/configuring-npm/package-json.

Las investigaciones públicas sobre PhantomRaven, entre ellas la de la empresa Endor Labs, describen varias oleadas de publicación: tras el descubrimiento inicial se detectaron nuevas rondas entre noviembre de 2025 y febrero de 2026 en las que los atacantes lanzaron decenas de paquetes desde cuentas desechables. Endor Labs documenta en detalle la persistencia de la campaña, la consistencia del payload y la infraestructura asociada; su informe está disponible aquí: https://www.endorlabs.com/learn/return-of-phantomraven. Según esos análisis, muchas de las muestras siguen accesibles en el registro npm.

Otro rasgo recurrente en la campaña es el empleo de técnicas de "slopsquatting" o typosquatting: los paquetes maliciosos intentan parecerse a proyectos legítimos muy usados —por ejemplo Babel o GraphQL Codegen— publicando nombres que podrían confundirse con los sugeridos por asistentes automáticos o por quien copia y pega precipitadamente una recomendación. La combinación de nombres convincentes y la dependencia remota reduce la probabilidad de detección y aumenta la probabilidad de que un desarrollador instale el paquete por error.

Una vez que el código malicioso llega a la máquina, su objetivo es claro y peligroso: recolectar información que permita al atacante moverse lateralmente o exfiltrar secretos. Endor Labs observa que las muestras buscan archivos y configuraciones locales como .gitconfig y .npmrc, variables de entorno y tokens utilizados por pipelines CI/CD —GitHub, GitLab, Jenkins, CircleCI—; también recogen huellas del sistema (IP, hostname, versión de Node) para perfilar la víctima. El envío de los datos al servidor de control y comando (C2) se realiza normalmente por HTTP GET, aunque los autores también usaron POST y WebSocket para garantizar redundancia.

La infraestructura usada por PhantomRaven mostró patrones repetidos: dominios que incluyen la palabra "artifact", servidores en Amazon EC2 que a menudo carecían de certificado TLS, y un payload cuya mayor parte del código permaneció inalterada entre oleadas. Aun así, los operadores rotaron cuentas de npm y correos, ajustaron metadatos y cambiaron endpoints PHP para mantenerse operativos con cambios mínimos.

Esto deja varias lecciones prácticas para cualquier desarrollador o equipo de seguridad. Primero, no existe atajo: verificar la procedencia de un paquete y su publicación es más importante que nunca. No basta con copiar el sugerido por un chatbot o pegar sin mirar un nombre que "suena bien". Inspeccionar package.json, revisar el autor y la reputación del publicador, y comprobar la existencia de un repositorio fuente razonable son pasos sencillos que pueden evitar muchas sorpresas desagradables. Para quienes gestionan pipelines y repositorios, es recomendable habilitar herramientas de escaneo de dependencias y detección de secretos que estén integradas en el flujo de trabajo; GitHub ofrece capacidades de secret scanning y Dependabot para actualizaciones de seguridad que ayudan a reducir el riesgo: https://docs.github.com/en/code-security/secret-scanning.

También conviene aplicar controles de seguridad en los tokens y credenciales: limitar el alcance de los tokens CI/CD, rotarlos periódicamente y no exponerlos en archivos que puedan ser leídos por procesos de terceros. A nivel organizacional, la práctica de construir artefactos en entornos aislados y de usar allowlists de paquetes confiables (en lugar de instalar paquetes desde el registro público sin supervisión) reduce la superficie de ataque. Recursos como OWASP y análisis de cadenas de suministro ofrecen orientaciones útiles sobre higiene de dependencias y detección temprana: https://owasp.org/www-project-dependency-check/.

Hay además soluciones comerciales y comunitarias que pueden ayudar a mitigar riesgos: escáneres de seguridad de dependencias, mirrors privados de paquetes, y políticas de publicación más estrictas en los repositorios internos. Plataformas como Snyk han publicado guías y análisis sobre cómo las cadenas de suministro siguen siendo vectores críticos; ver, por ejemplo, su cobertura sobre ataques a la cadena de suministro: https://snyk.io/blog/supply-chain-attacks/.

Aunque la técnica de PhantomRaven no es sofisticada desde el punto de vista criptográfico o de ofuscación del código —el payload apenas cambió entre muestras—, su eficacia reside en la simplicidad operativa y en la explotación de hábitos humanos: confiar en nombres, seguir ejemplos sin verificar y ejecutar instalaciones en entornos con privilegios. Un cambio pequeño en los hábitos de desarrollo y la adopción de controles básicos de seguridad pueden reducir considerablemente la exposición.

Si eres desarrollador, revisa tus proyectos y pipelines: busca dependencias que apunten a URLs externas en package.json, confirma que no haya paquetes desconocidos en tus lockfiles y considera escanear máquinas de desarrollo y runners CI con herramientas que detecten comunicaciones anómalas a dominios sospechosos. Si gestionas una organización, promueve políticas de confianza cero respecto a paquetes de terceros y proporciona a los equipos un catálogo de dependencias aprobadas y actualizadas.

La industria ya ha tenido episodios similares y las soluciones son, en gran medida, conocidas. La lección es que la vigilancia debe ser continua: los atacantes repetirán patrones que funcionen y rotarán lo mínimo necesario para seguir adelante. Mantenerse informado, aplicar controles técnicos y, sobre todo, comprobar dos veces antes de instalar, son pasos que hoy forman parte de la seguridad básica de cualquier proyecto basado en npm.