Una campaña de paquetes de 148 npm disfrazados de proxy web para estudiantes convirtió los navegadores de los visitantes en una botnet descentralizada de denegación de servicio durante aproximadamente dos semanas en mayo, según una nueva investigación de JFrog.
El paquete no rastreaba a los desarrolladores que podrían instalarlo. Los operadores utilizaron el registro como alojamiento gratuito para sitios proxy con trampas explosivas, lo que permitió que los estudiantes que llegaban para evadir los filtros web de su escuela proporcionaran tráfico de ataque.
Los paquetes se enviaron con nombres como charlie-kirk, ilovefemboys y miguelphonk, cada uno de los cuales contenía una aplicación proxy con la marca «Lucide» y se hacía pasar por una página de inicio para un tutor llamado Riverbend Tutoring o Northstar Tutoring.
Los servidores proxy aparentemente funcionaron, permitiendo a los estudiantes eludir los filtros de contenido y acceder a juegos y sitios bloqueados. Debajo se carga un cargador de código remoto que permite a los operadores intercambiar cargas útiles a voluntad y un generador de inundación WebSocket creado para hablar el protocolo proxy Wisp. Cualquiera que abra la página sin saberlo se une a la manada.
Estos no se ejecutan durante la instalación. El paquete no contiene enlaces de ciclo de vida ni scripts de compilación nativos, y no está escrito para importarse a un proyecto.
El gusano autorreplicante Shai-Hulud, que afectó a más de 500 paquetes en septiembre de 2025, recopiló secretos de los desarrolladores y se volvió a publicar utilizando tokens robados. Unos días antes, un ataque de phishing contra el mantenedor conocido como qix infiltró código de drenaje de billetera en choke, debug y otros 16 paquetes, entre los cuales se producen miles de millones de descargas cada semana.
Estos ataques comienzan en el momento en que se instala un paquete y se dirigen a las personas que crean el software. Esto omitirá el proceso de compilación y esperará en la pestaña del navegador.
El aviso anterior de SafeDep catalogó 141 paquetes en mayo, calificando la operación como un exploit de adware y registro. Seguimiento de Google Analytics integrado en anuncios emergentes, scripts de monetización de terceros y servidores proxy Sclamjet para estudiantes. Eso se aplica a lo que apareció en la superficie.
JFrog movió más hilos. El equipo desofuscó el paquete de entrada de la aplicación, que descomprimió una sola línea de JavaScript de 5,4 MB en más de 20.600 líneas de código legible y reconstruyó la línea de tiempo de la campaña restaurando la carga útil archivada desde la máquina Wayback.
Hay dos módulos debajo del adware, los cuales se activan antes de que se procese la interfaz de React.
El primero es lo que JFrog llama G2, un cargador de scripts remoto que recupera la mayor cantidad de código inseguro posible. Extrae JavaScript de un repositorio de GitHub a través de la CDN jsDelivr, apunta a una rama principal mutable en lugar de una confirmación fijada, no envía comprobaciones de integridad de subrecursos y ejecuta todo lo que se devuelve con los permisos de origen del sitio proxy (cookies, almacenamiento local y acceso completo a puntos finales del mismo origen).
Una política de no referencia impide que se anuncie el origen de la solicitud. Cualquier persona con una cuenta de GitHub puede cambiar el código que se ejecuta en los navegadores de todos los visitantes en cualquier momento si es necesario.
En el momento en que JFrog miró, el repositorio devolvía un 404, pero una copia archivada del 30 de mayo conservaba lo que se mostraba: una burda inundación HTTP. Cada 500 milisegundos, el script construye una nueva cadena de 1 millón de caracteres y la envía como una POST sin cors a cdn.caan.edu. JFrog identifica esto como una escuela de enfermería de dominio público ubicada en Matteson, Illinois.
Las solicitudes se acumulan porque no esperan una respuesta. JFrog mide la velocidad de carga de cada visitante activo en aproximadamente 2 MB por segundo. Esto significa que 1000 pestañas de proxy abiertas enviarán aproximadamente 2 GB por segundo al objetivo. Los parámetros de consulta aleatorios desactivan los servidores proxy de almacenamiento en caché y no-cors omite la verificación previa de CORS, por lo que no hay nada que limite los paquetes.
El segundo módulo, I2, es más nítido. Toma un archivo de texto sin formato websocket.txt que contiene la URL del WebSocket de destino y un número máximo de sockets de 1 a 1024, y abre esa cantidad de conexiones en un bucle escalonado. La configuración archivada está destinada a que cada navegador se conecte 30 veces al punto final Wisp en lunaron(.)arriba, que en sí mismo es un proxy en vivo ocupado inyectando publicidad maliciosa.
Wisp es un protocolo de Mercury Workshop de bajo costo para hacer túneles de muchos sockets TCP y UDP a través de un único WebSocket, y es una tubería común en la misma escena de proxy del navegador que imitan estos paquetes.
Una vez conectado, cada navegador configura su socket en modo binario y envía una trama Wisp CONNECT válida seguida de una trama CLOSE cada 100 milisegundos. Ambos apuntan a localhost:1. El marco es un paquete Wisp little-endian válido, por lo que el objetivo no es la propia máquina del estudiante. Este es el servidor Wisp remoto en el otro extremo de la conexión.
Por lo tanto, se trata de un ataque en el plano de control y no de un ataque volumétrico. Un solo navegador que ejecuta 1.024 sockets completos puede solicitar al servidor Wisp que asigne y elimine aproximadamente 10.240 conexiones por segundo y escriba más de 20.000 líneas de registro al mismo tiempo.
JFrog señala que el nodo-servidor wisp de Mercury Workshop abre un nuevo socket para cada trama CONNECT y registra cada intento sin verificar si el destino es un loopback o una dirección privada. Esto agotará los descriptores de su archivo, llenará su almacenamiento de registros y eliminará su proxy. wisp-server-node ya está en desuso. Sus administradores dirigen a los usuarios a otra parte precisamente para este tipo de problemas de seguridad y estabilidad.
Así que la campaña convirtió la herramienta de proxy estudiantil en un arma contra los servidores de los que dependen otros proxy estudiantiles, mientras apuntaba a otra avalancha de escuelas.
La infraestructura está estrechamente agrupada y no está diseñada para permanecer oculta. JFrog rastreó la compilación hasta una organización de GitHub llamada lucideproxy. La cuenta se registró cada pocos segundos y se asoció con el correo electrónico de confirmación de geeked(.)wtf y el identificador de Discord. De los 93 nombres de host de implementación encontrados, 90 se resolvieron en una dirección IP, 92.38.177(.)17, alojada en G-Core Labs.
Las empresas determinaron que el operador era joven basándose en el nombre infantil del paquete, el script shell de publicación automática que quedó en el tarball y el comentario «TY WAVES + CHATGPT ILY» que SafeDep encontró dentro del trabajador del servicio. Una cuenta envió 116 paquetes en 35 minutos y npm no hizo nada para ralentizarlo.
El historial de confirmaciones de JFrog sigue ese arco. El proyecto comenzó como un simple adware en marzo, agregó un cargador remoto y un generador Wisp en dos días a mediados de mayo y realizó una inundación en vivo contra una escuela de enfermería a finales de mes. Luego eliminamos el módulo malicioso el 31 de mayo, cuando comenzaron los informes.
La segunda oleada del 8 de julio resultó en un total de 148 paquetes en cuentas nuevas y se enviaron versiones limpias solo de adware. La aplicación todavía está ofuscada, sigue cargando scripts de terceros desde el dominio del atacante y el cargador todavía apunta a una rama modificable. La funcionalidad DDoS no ha desaparecido, simplemente está desactivada. JFrog señala que los operadores conservan la capacidad de volver a equiparlo. No se requieren actualizaciones de paquetes, solo una confirmación única en una rama mutable.
Desde entonces, muchos de los paquetes de las campañas se retiraron de npm y se reemplazaron con el marcador de posición de seguridad estándar 0.0.1 en el registro. Una verificación aleatoria de toda la familia de paquetes realizada por The Hacker News el 14 de julio de 2026 encontró que la mayoría había desaparecido, pero que charlie-kirk todavía ofrecía dos versiones que JFrog había marcado como maliciosas: 2.0.0 y 3.0.1.
La solución de JFrog sigue el método de entrega, ya que la amenaza se distribuye como una aplicación web del lado del cliente en lugar de integrarse durante la instalación.
Los administradores de redes escolares y corporativas donde estos servidores proxy atraen la mayor cantidad de tráfico deberían bloquear los dominios de la campaña a nivel de DNS. Los hosts de monetización y secuencias de comandos cuyas compilaciones actuales aún estén alcanzadas, como woofbeginner(.)com y c.vipersfutbol(.)com, serán bloqueados primero.
Cualquiera que cargue uno de sus sitios proxy debe borrar la memoria caché de su navegador y el almacenamiento local, y cancelar el registro de cualquier trabajador de servicio que haya dejado el dominio de tutoría o proxy. Los equipos cuyo entorno de compilación selecciona paquetes con nombre deben recuperarlos del archivo de manifiesto y bloqueo y reconstruirlos limpiamente. El artículo de JFrog proporciona una lista completa de 148 paquetes, dominios, direcciones IP y hashes.
Hacker News se comunicó con JFrog para obtener más información sobre el tamaño de la botnet y si el ataque WebSocket se llevó a cabo contra un objetivo real y actualizará este artículo si recibimos una respuesta.
Los escáneres de dependencias y los entornos sandbox en el momento de la instalación están diseñados para detectar el código ejecutado por npm install. Nunca se solicitó la instalación de este código. Mientras los registros públicos funcionen como CDN gratuitos, será cada vez más probable que los paquetes por los que vale la pena preocuparse sean aquellos que su canal de compilación nunca utilizará.
Source link
