Cybersecurity researchers have uncovered a large-scale campaign involving 148 malicious npm packages that masqueraded as student web proxy applications while secretly turning visitors’ browsers into participants in a distributed denial-of-service (DDoS) botnet.
According to researchers at JFrog, the attackers did not target software developers who installed the packages. Instead, they abused the npm registry as a free hosting platform for malicious web proxy sites, using unsuspecting students attempting to bypass school internet restrictions as the source of attack traffic.
Fake Student Proxy Sites Hidden Inside npm Packages
The malicious packages appeared under unusual names such as:
- charlie-kirk
- ilovefemboys
- miguelphonk
Each package contained a browser-based proxy branded as Lucide, disguised as legitimate tutoring websites including Riverbend Tutoring and Northstar Tutoring.
On the surface, the applications functioned as expected, allowing users to access blocked websites, online games, and other restricted content.
Behind the scenes, however, the sites silently loaded additional malicious code capable of launching denial-of-service attacks and receiving updated payloads from remote servers.
Visitors Became Part of a Botnet
Unlike traditional npm malware that executes during package installation, this campaign activated only when users visited the hosted proxy websites.
The malicious code included two primary components:
- A remote JavaScript loader that could fetch and execute updated code at any time.
- A WebSocket-based traffic generator designed to abuse the Wisp proxy protocol.
Anyone opening one of the proxy pages unknowingly contributed their browser’s network resources to the attackers’ infrastructure.
Different From Typical npm Supply Chain Attacks
JFrog noted that the campaign differs significantly from previous npm compromises.
Earlier supply chain incidents, including the Shai-Hulud worm and the compromise of widely used packages maintained by qix, targeted developers during package installation by stealing credentials or injecting malicious code into software projects.
In contrast, these proxy packages were never intended to be imported into applications.
They contained no installation scripts or lifecycle hooks and instead delivered their malicious functionality entirely through the browser after users accessed the hosted web application.
Researchers Uncovered Hidden Malware Components
Earlier investigations by SafeDep had classified the packages primarily as adware because they contained advertising scripts, analytics tracking, and browser proxy functionality.
JFrog’s deeper analysis revealed far more sophisticated behavior.
Researchers deobfuscated a heavily packed JavaScript bundle measuring approximately 5.4 MB and reconstructed the campaign using archived payloads recovered from the Internet Archive’s Wayback Machine.
Their investigation uncovered two hidden modules that executed before the user interface even loaded.
Remote Code Loader Enabled Dynamic Attacks
The first module, dubbed G2, functioned as a remote code loader.
Rather than embedding its malicious functionality directly inside the package, it downloaded JavaScript from a GitHub repository using the jsDelivr CDN.
Because the loader referenced GitHub’s mutable main branch instead of a fixed commit and lacked Subresource Integrity (SRI) protection, attackers could modify the delivered code at any time without publishing updated npm packages.
The downloaded scripts executed with full privileges inside the proxy website, giving them access to cookies, browser storage, and same-origin resources.
Browsers Launched HTTP Flood Attacks
Archived payloads showed that one downloaded script generated a continuous HTTP flood targeting cdn.caan.edu, the public website of a nursing school in Illinois.
Every 500 milliseconds, the script generated approximately one million characters of random data and transmitted it using a no-cors POST request.
Researchers estimate that each active browser uploaded roughly 2 MB of traffic per second, meaning thousands of simultaneous users could generate several gigabytes of attack traffic every second.
To maximize the attack’s effectiveness, the malware randomized request parameters to bypass caching and avoided browser CORS preflight checks.
WebSocket Module Targeted Proxy Infrastructure
A second module, identified as I2, focused on attacking servers running the Wisp proxy protocol.
The malware downloaded a configuration file specifying a target WebSocket server and the number of simultaneous connections to establish.
Each infected browser repeatedly opened dozens—or even hundreds—of WebSocket connections while continuously sending valid Wisp CONNECT and CLOSE frames.
Rather than attacking the user’s computer, the traffic overwhelmed remote Wisp proxy servers by forcing them to rapidly allocate and destroy thousands of connections while generating massive log volumes.
According to JFrog, a single browser configured with the maximum number of sockets could force a vulnerable Wisp server to process more than 10,000 connection requests every second, eventually exhausting system resources and causing service disruptions.
Campaign Infrastructure Was Poorly Hidden
Researchers found little effort to conceal the operation’s infrastructure.
Most deployment domains resolved to a single IP address hosted by G-Core Labs, while the associated GitHub organization—named lucideproxy—contained multiple accounts created only seconds apart.
JFrog also identified:
- An automated package publishing script left inside the package archives.
- Shared email addresses and Discord identifiers.
- Comments within the code suggesting the operators were relatively inexperienced.
One account reportedly published 116 npm packages in less than 35 minutes, highlighting how quickly malicious content can spread through public package registries.
Timeline of the Campaign
JFrog reconstructed the campaign’s evolution through GitHub commit history.
The project initially appeared in March as a browser-based proxy monetized through advertising.
In mid-May, attackers added the remote code loader and WebSocket attack modules.
By the end of May, the malicious payloads were actively launching DDoS attacks before being removed on May 31, shortly after researchers began investigating.
A second wave appeared on July 8, bringing the total number of identified npm packages to 148.
Although the latest versions no longer contained the active DDoS modules, the remote loader remained intact, allowing attackers to re-enable malicious functionality simply by updating code hosted on GitHub.
Mitigation Recommendations
Many of the malicious packages have since been removed from npm and replaced with the registry’s standard 0.0.1-security placeholder.
However, JFrog advises organizations to take additional precautions, including:
- Blocking known campaign domains at the DNS level.
- Clearing browser cache and local storage after visiting affected proxy sites.
- Removing any service workers installed by the fake tutoring or proxy websites.
- Deleting the malicious npm packages from dependency manifests and rebuilding affected projects from clean sources.
Researchers also recommend monitoring outbound connections to suspicious domains used by the campaign’s infrastructure.
Final Thoughts
The campaign demonstrates how public package registries can be abused for purposes beyond traditional software supply chain attacks. Instead of infecting developers during package installation, the attackers transformed npm into a free hosting platform for malicious web applications that weaponized ordinary web browsers.
Although many of the identified packages have been removed, the remaining infrastructure and remote code loading capabilities suggest the operators could quickly reactivate similar attacks without publishing new package versions, underscoring the need for continued vigilance when using browser-based proxy tools and public package repositories.
