Student Proxy Campaign Turns npm Into a Distributed DDoS Weapon
A swarm of 148 malicious npm packages exploited student browsers to fuel a sophisticated, dual-layered botnet operation.
When students sought to circumvent restrictive web filters using proxy tools, they inadvertently became participants in a widespread infrastructure attack. Researchers at JFrog uncovered a campaign utilizing 148 npm packages, masked as educational tools like Riverbend Tutoring or Northstar Tutoring, to transform ordinary browser sessions into a distributed denial-of-service botnet.
The Anatomy of a Browser Botnet
Rather than targeting developers during the software build process, these packages were designed to remain dormant until a student accessed the proxy web page. Once active, the application deployed a remote code loader that could be updated at any time by the operators. This setup allowed attackers to bypass standard security scrutiny by keeping the malicious payload entirely within the browser environment.
The operation utilized two distinct modules to achieve its goals. The first, labeled G2, acted as a flexible script loader, while the second, I2, functioned as a high-frequency socket generator. This structure allowed the attackers to switch between different types of malicious activity, ranging from volumetric HTTP flooding to precision control-plane attacks targeting server stability.
Weaponizing the Wisp Protocol
The campaign demonstrated a sophisticated understanding of web communication protocols, specifically targeting the Wisp protocol to stress-test and eventually crash remote servers. By automating thousands of connection attempts, the attackers exploited the resource limits of proxy infrastructure.
- 148 packages were identified as part of the malicious campaign.
- 20,600 lines of code were uncovered after deobfuscating a 5.4 MB bundle.
- 1,024 sockets could be opened simultaneously by a single browser instance.
- 10,240 connections per second could be allocated and torn down by a single bot.
- 2 GB per second of upload traffic could be generated by 1,000 open proxy tabs.
Infrastructure and Attacker Intent
The research suggests the operators were likely young, given the informal comments found in the source code and the rapid, amateurish deployment patterns. The attackers utilized a GitHub organization named lucideproxy to manage the project, with nearly all deployment hostnames resolving to a single IP address: 92.38.177.17. While the initial malicious modules were stripped out following public reporting on May 31, the underlying infrastructure remained in place, allowing the operators to re-arm the botnet with a single commit.
Implications for Network Defense
The primary danger of this attack lies in its ability to evade traditional supply chain security measures. Because the code is not designed to execute during the installation of a package, it remains invisible to standard dependency scanners and sandboxes that monitor build pipelines.
Security teams should recognize that the threat resides in the browser, not just the build environment. Administrators must move to block associated domains at the DNS level and mandate that users clear browser caches and local storage to remove persistent service workers. As registries are increasingly utilized as free hosting platforms, the industry must prepare for more attacks that bypass the server-side pipeline entirely.
