Un nuevo episodio de ataque a la cadena de suministro ha puesto en el foco a los ecosistemas de JavaScript. En esta ocasión, el incidente se conoce como ChainDrop y, según los reportes disponibles, involucró paquetes NPM infectados que publicaron versiones maliciosas para aprovechar el proceso de instalación de dependencias.
La campaña habría afectado a más de 440 paquetes, con más de 2.200 iteraciones maliciosas observadas. Además, varias de esas versiones contaban con un alto volumen de descargas semanales, lo que incrementa el impacto potencial en proyectos de terceros y en entornos automatizados como CI/CD.
Cómo empezó ChainDrop
El inicio del ataque se asocia a la compromisión de una cuenta de GitHub vinculada a mantenedores. A partir de ese acceso, el adversario logró publicar contenido en el registro de NPM.
La campaña arrancó con múltiples componentes maliciosos en espacios de nombres específicos (keyv y cacheable). Una vez dentro, el objetivo no se limitó a “infectar y ya”, sino que buscó convertir las instalaciones en una plataforma para el robo de información y para la propagación.
Qué hacen los paquetes NPM infectados al instalarse
Los paquetes comprometidos ejecutaban código malicioso durante la instalación. El comportamiento descrito incluye la descarga de un cargador y la presencia de una segunda etapa ofuscada, además de la inclusión de un componente diseñado para obtener el entorno de ejecución legítimo de Bun.
Una vez que el malware se ejecuta en la máquina afectada, prioriza la búsqueda de secretos. La lógica general es la siguiente: localiza credenciales e información sensible, realiza un proceso de cifrado de esos datos y posteriormente los exfiltra, ya sea hacia un punto de acceso mediante HTTPS o hacia repositorios públicos creados por el atacante.
Recopilación de credenciales y alcance a sistemas de desarrollo
De acuerdo con la explicación atribuida a Microsoft en el informe, el malware intenta localizar credenciales de NPM, GitHub, servicios en la nube y plataformas de infraestructura. Con las identidades recuperadas, puede autenticarse y enumerar recursos como:
- paquetes disponibles en NPM
- repositorios de GitHub
- secretos de flujos de trabajo (workflows)
- parámetros de la nube
- valores almacenados en sistemas de secretos
Ese enfoque hace que el impacto no dependa únicamente del usuario final. También puede afectar pipelines, runners y máquinas de desarrollo donde se instalan dependencias con privilegios o con acceso a secretos.
Propagación: del robo de credenciales a la publicación de versiones envenenadas
Uno de los aspectos más preocupantes del caso es la capacidad de los atacantes para propagar el problema. Los reportes indican que el malware usa credenciales robadas para publicar versiones manipuladas de otros paquetes a los que puede acceder desde la máquina comprometida.
En paralelo, también se menciona el uso de credenciales comprometidas de GitHub y de GitHub Actions para infectar repositorios adicionales, con el objetivo de seguir extrayendo credenciales.
En términos prácticos, el proceso descrito incluye la enumeración de paquetes asociados a la identidad comprometida, la descarga de los tarballs más recientes, la inserción de la carga maliciosa y la modificación de metadatos (incluyendo hooks) antes de volver a publicar versiones alteradas.
Persistencia y ruta extra de infección
Además del comportamiento inicial, se describe una estrategia de persistencia: el malware puede inyectar archivos de configuración vinculados a herramientas del ecosistema de desarrollo, como opciones para Claude o Visual Studio Code, con el fin de mantener el acceso y crear una ruta adicional de infección entre desarrolladores.
Esto significa que el incidente puede “moverse” entre entornos de trabajo y no quedar restringido al momento de instalación de una sola dependencia.
Volumen del ataque: miles de iteraciones en poco tiempo
Los detalles disponibles señalan que, debido a que muchos de los paquetes afectados se republicaron incluso en versiones históricas, el número total de iteraciones maliciosas detectadas llegó a 2.212 versiones en menos de cuatro horas, en el periodo observado el 4 de agosto.
Un ritmo así sugiere un proceso automatizado y optimizado para aprovechar ventanas de exposición cortas, especialmente si los proyectos actualizan dependencias de forma frecuente o si confían en instalación no controlada.
Infraestructura de mando y control y mecanismos de autolimpieza
Para coordinar la operación, el malware habría incorporado una técnica de comando y control basada en una blockchain de Ethereum, descrita como “EtherHiding”. Este tipo de enfoque busca dificultar el trazado tradicional del canal de comunicación.
Por otro lado, el malware también añade lo que se conoce como un dead-man’s switch a nivel del host. Tras lograr persistencia en macOS y Linux, el código consultaría periódicamente la API de GitHub usando el token robado del usuario. Si el token deja de funcionar, el malware eliminaría su estado y terminaría.
También se reporta un comportamiento de autolimpieza: después de 24 horas, el malware se elimina por sí mismo, reduciendo la evidencia local y acortando el tiempo en el que podría ser analizado en entornos comprometidos.
Qué hacer si instalaste paquetes NPM infectados
Si tu equipo instaló alguna de las versiones afectadas, los reportes recomiendan asumir que la máquina podría estar comprometida y actuar de inmediato. Las medidas sugeridas apuntan a limitar el alcance y a recuperar el control de credenciales y entornos de construcción.
Entre las acciones recomendadas se incluyen:
- aislar los sistemas afectados para frenar la propagación
- preservar artefactos antes de limpiar (tarballs del paquete, logs de NPM, logs de CI, auditorías de GitHub y las imágenes de runners)
- reconstruir runners y máquinas de build para eliminar el código implantado
- revocar y rotar credenciales potencialmente comprometidas
- auditar repositorios en busca de actividad anómala
La lógica detrás de conservar registros es clara: necesitas evidencias para acotar la ventana de exposición y entender qué tan lejos llegó el ataque, especialmente en pipelines y automatizaciones.
Por qué este caso importa más allá de NPM
Aunque el incidente se centra en NPM, el patrón descrito es relevante para todo el desarrollo moderno: cuando un atacante consigue credenciales, puede transformar dependencias en un vector para robar secretos, modificar automatizaciones y publicar contenido manipulando la confianza del ecosistema.
Por eso, más que enfocarse solo en “la dependencia concreta”, conviene revisar procesos: cómo se gestionan tokens, cómo se ejecutan builds, qué tan rápido se detectan cambios en repositorios y cómo se monitorean workflows de CI/CD.
Conclusión
ChainDrop es un recordatorio contundente de que los paquetes NPM infectados pueden convertirse en una puerta de entrada a entornos completos de desarrollo. Al ejecutar código durante la instalación, buscar secretos, cifrarlos y exfiltrarlos, además de aprovechar credenciales para publicar versiones envenenadas, la campaña combina varias técnicas en un solo flujo.
Si existe la posibilidad de que hayas instalado versiones comprometidas, la prioridad debe ser la contención: aislar, preservar evidencia, reconstruir entornos de build y rotar credenciales. Con esas acciones, reduces el impacto y recuperas una base segura para seguir desarrollando.
Fuente: https://www.securityweek.com/over-400-npm-packages-infected-in-chaindrop-supply-chain-attack/
