38 paquetes fingían ser herramientas de Apple y Google. Ataque a desarrolladores casi provoca una brecha de seguridad masiva
Se jugó a la confianza en lo conocido y a un error que pasa fácilmente desapercibido.
Especialistas en seguridad de la información revelaron una gran campaña maliciosa dirigida a desarrolladores, en la que el atacante apostó no por vulnerar productos terminados, sino por las debilidades de los procesos de ensamblaje. A través del registro público NPM, intentó introducir paquetes maliciosos haciéndose pasar por herramientas internas de grandes empresas, confiando en que los sistemas automáticos de desarrollo descargarían el paquete falso por sí mismos.
Según Panther Threat Research, entre el 24 y el 30 de abril de 2026 aparecieron 38 paquetes maliciosos en NPM. Se relacionan con un atacante indonesio que usó el seudónimo "frank" y la cuenta principal frengki0707. Para publicar también se emplearon las cuentas raya4321, cketol y frengki4321.
La técnica principal fue Dependency Confusion (confusión de dependencias). El autor del ataque elegía nombres con el fragmento "internal" para que los paquetes parecieran bibliotecas internas cerradas de Apple, Google, GCP, Alibaba y Aliyun. Si la CI/CD se configuraba erróneamente, el paquete público podía tener prioridad sobre la dependencia interna real y ejecutarse durante la instalación habitual.
El grupo más grande imitó herramientas de Apple, incluyendo bibliotecas de App Store, utilidades PKI, CloudKit y componentes de infraestructura. En los nombres había palabras que sugerían evasión de protecciones, sigilo y filtrado de datos. Versiones concretas como v3, v9 y v99 estaban pensadas para dar a los paquetes la apariencia de dependencias habituales en package.json.
Los paquetes dirigidos a Google y GCP se disfrazaban de utilidades de compilación, registro, monorrepositorios y auditoría. Tenían como objetivo recopilar claves de servicio de GCP, tokens OAuth y configuraciones de Kubernetes. En el grupo de paquetes dirigidos a Alibaba, el atacante imitó componentes internos del SDK de Alibaba Cloud y buscó claves Aliyun RAM. La serie frank-newton3 era más bien una herramienta universal para buscar archivos .env, variables DB_, claves SSH y volcados de MySQL o Postgres.
El código malicioso se ejecutaba mediante los scripts postinstall después del comando estándar npm install. Primero los paquetes recopilaban información del sistema, incluido el nombre de usuario, el host y datos del sistema operativo; luego buscaban secretos y enviaban lo encontrado a la infraestructura de control. Tenían especial interés en NPM_TOKEN y NODE_AUTH_TOKEN, ya que el robo de esos tokens podría permitir inyectar código malicioso en paquetes legítimos.
Panther atribuye la campaña a un solo operador por el seudónimo repetido frank, nombres de cuentas similares, comentarios en indonesio en el código y direcciones webhook comunes en algunos paquetes. Según la empresa, la rotación de cuentas ayudó a conservar parte de la infraestructura tras la eliminación de publicaciones individuales.
Se aconseja a los equipos de desarrollo que verifiquen las referencias a paquetes públicos de NPM con "internal" en el nombre, que controlen los scripts postinstall en CI/CD y que supervisen el acceso de los procesos de compilación a ~/.npmrc, ~/.aws/credentials y ~/.kube/config.