MagnoSec
Navegador web con múltiples pestañas abiertas y tráfico de red malicioso representando paquetes npm que convierten navegadores en botnet DDoS

MagnoSec Blog

148 Paquetes npm Convierten Navegadores en una Botnet DDoS: El Ataque que se Escondía en Proxies para Estudiantes

Por Equipo MagnoSec4 min de lectura

148 paquetes npm convertían navegadores en una botnet DDoS sin que nadie lo notara

El ecosistema npm aloja más de 2 millones de paquetes y recibe miles de nuevas publicaciones cada día. Entre ellas, 148 paquetes que se hacían pasar por proxies para estudiantes —herramientas que prometían desbloquear contenido académico y saltar restricciones de red en campus universitarios— estaban convirtiendo los navegadores de quienes los usaban en nodos de una botnet de denegación de servicio distribuido (DDoS). La campaña, descubierta por JFrog, operó durante dos semanas y afectó a miles de desarrolladores, estudiantes y sitios web que utilizaban estos paquetes como dependencias en sus proyectos. Cada visitante de un sitio web que incluía uno de estos paquetes se convertía, sin saberlo, en un soldado de la botnet: su navegador realizaba peticiones HTTP masivas a objetivos seleccionados por los atacantes mientras la víctima navegaba por el sitio legítimo.

Web Workers ocultos: el ejército invisible dentro de cada navegador

El mecanismo técnico es una variante particularmente insidiosa del malware en npm: en lugar de ejecutarse en el servidor o en la máquina del desarrollador al hacer npm install, el código malicioso se incrustaba en el frontend —en los recursos JavaScript que el paquete servía a los visitantes del sitio web— y se ejecutaba en el navegador de cada usuario que visitaba una página que utilizaba el paquete comprometido. El JavaScript malicioso creaba Web Workers ocultos —hilos de ejecución en segundo plano que el usuario no puede ver— y desde ellos lanzaba peticiones HTTP a objetivos designados por el servidor de comando y control. Cada visitante del sitio web se convertía en un nodo de ataque involuntario. Si el sitio tenía 10.000 visitas diarias, los atacantes tenían 10.000 IPs diferentes desde las que lanzar ataques DDoS, sin necesidad de infectar servidores ni comprometer infraestructura. Los navegadores de los visitantes hacían todo el trabajo.

Ingeniería social dirigida a estudiantes: la campaña de proxies académicos falsos

La ingeniería social detrás de la campaña fue quirúrgica. Los nombres de los paquetes —variaciones de 'student-proxy', 'campus-access', 'academic-unlock', 'edu-bypass'— apelaban directamente a estudiantes universitarios que buscan herramientas para acceder a contenido bloqueado en redes de campus. Las descripciones prometían desbloquear Netflix, YouTube y artículos académicos detrás de paywalls. Los READMEs incluían instrucciones detalladas de instalación y capturas de pantalla falsas de la herramienta funcionando. Todo diseñado para que un estudiante con conocimientos básicos de programación web instalara el paquete, lo incluyera en su proyecto, y sin querer convirtiera a los visitantes de su sitio web en parte de una botnet. La campaña explotaba la combinación perfecta: motivación del usuario (acceso a contenido), baja barrera técnica, y desconocimiento del riesgo.

El multiplicador de fuerza: cómo un paquete infecta miles de sitios y cada sitio infecta a sus visitantes

El verdadero peligro de este ataque está en el modelo de distribución: un solo paquete npm malicioso puede infectar cientos o miles de sitios web si se vuelve popular, y cada uno de esos sitios web convierte a sus visitantes en atacantes involuntarios. Es un multiplicador de fuerza: comprometes un paquete, infectas N sitios web, cada sitio web convierte a sus M visitantes en nodos de ataque. El atacante no necesita una infraestructura de servidores comprometidos —los navegadores de las víctimas proporcionan todo el ancho de banda necesario—. Y como el tráfico de ataque sale de direcciones IP residenciales y universitarias legítimas, es extremadamente difícil de filtrar sin bloquear también a usuarios legítimos.

Auditoría de dependencias frontend: por qué revisamos el código que se ejecuta en el navegador

En MagnoSec, las auditorías de código fuente y seguridad de aplicaciones web incluyen la revisión de dependencias frontend como vector de ataque. Un paquete npm malicioso en el frontend no solo compromete el sitio web que lo incluye: compromete a todos los visitantes de ese sitio. Revisamos las dependencias de cada proyecto en busca de paquetes sospechosos por nombre, patrón de publicación o comportamiento en tiempo de ejecución, y recomendamos políticas de Content Security Policy (CSP) estrictas que limiten las conexiones salientes del frontend exclusivamente a los dominios necesarios para la funcionalidad legítima de la aplicación. Si el JavaScript malicioso intenta lanzar peticiones a un servidor de C2, CSP lo bloquea antes de que salga del navegador.

Protección: SRI, CSP estricto y auditoría periódica de paquetes frontend

La mitigación para desarrolladores y equipos que gestionan sitios web es triple. Primero, auditar las dependencias frontend con el mismo rigor que las dependencias de backend: un paquete malicioso en el frontend es igual de peligroso que uno en el servidor. Segundo, implementar Subresource Integrity (SRI) en todas las dependencias de terceros para garantizar que el código que se ejecuta en el navegador del usuario es exactamente el que el desarrollador revisó. Tercero, revisar periódicamente los paquetes instalados en busca de nombres sospechosos, repositorios con poca actividad o cambios de mantenedor inesperados —señales de alerta que a menudo preceden a la publicación de versiones maliciosas. La seguridad del frontend ya no es opcional: es la última línea de defensa entre tus usuarios y una botnet.

Temas tratados

npm malware · DDoS botnet · paquetes maliciosos · browser botnet · JFrog · supply chain npm · proxy estudiante

¿Quieres saber si tu empresa tiene estas vulnerabilidades?

Auditamos la seguridad de empresas de toda España con alcance cerrado por escrito, informe técnico y ejecutivo, y retest de las correcciones. Presupuesto en 24 horas y primera consultoría sin coste. Si no sabes por dónde empezar, haz el test de seguridad de 15 preguntas.

¿Quieres más información?