Nearly 150 npm packages posing as school Wi-Fi bypass tools were used to turn visiting browsers into potential DDoS engines.
The campaign presented itself as harmless tutoring-branded web proxies, giving students a way to reach blocked websites and games while quietly loading harmful code in the background.
Unlike a typical malicious npm package, this operation did not need to infect a developer’s computer during installation. The packages acted as a delivery system for browser-based proxy pages.
Anyone who opened one of the hosted sites could be exposed to pop-under advertising, tracking, and, during a key period, traffic-flooding code. JFrog and SafeDep researchers identified different stages of the activity.

SafeDep first documented 141 related packages as adware-hosting abuse in May, while JFrog later deobfuscated the application and uncovered remote code loading and DDoS functions that had operated in late May.
JFrog said in a report shared with Cyber Security News (CSN) that the findings show how a seemingly useful bypass site can create risk for schools, workplaces, and ordinary users.
The operators relied on npm’s broad availability to distribute static web assets, then used changing external scripts to alter what the proxy did after a visitor arrived.
150+ npm Packages Promise Wi-Fi Bypass Students
The campaign used names and pages tied to Lucide Proxy, Riverbend Tutoring, and Northstar Tutoring.
The visible service worked as advertised: it routed browsing through a proxy designed to bypass content restrictions. That normal behavior made it easier to hide the scripts running alongside it.
JFrog said the first wave began on May 27 and a later wave appeared on July 8, bringing the total to 148 packages.
Besides this, many packages were removed, but some remained available when the research was published.

The earlier SafeDep analysis found no installation hooks or credential-stealing component. Instead, the packages contained web files that could be served from npm-backed infrastructure.
A service worker routed proxy traffic and injected code that could capture navigation events, while advertising scripts opened pop-under pages after user interaction.
That distinction matters because the main victims were not necessarily developers who added a dependency to a project. A student who simply visited a deployed proxy page could unknowingly contribute browser resources.
The approach also made takedowns harder, as the same basic files could be copied across many package names and hosting locations.
Hidden Loaders Enabled DDoS Traffic
JFrog’s analysis found an obfuscated JavaScript bundle that loaded two hidden modules before the proxy interface appeared.
One pulled a remotely hosted script from a mutable GitHub branch without an integrity check. This gave the operators a way to change code delivered to every visitor without republishing the npm package.

An archived second-stage payload sent repeated large POST requests to a target education site every half second.
JFrog estimated that one active browser could generate about 2 MB of upload traffic per second, and a thousand visitors could produce roughly 2 GB per second. Such traffic can slow or overwhelm a public-facing service.
A separate component fetched live WebSocket settings and instructed browsers to open connections to a Wisp-compatible proxy endpoint. It could create and close connections at high speed, placing pressure on a server’s socket capacity and logs.
The remote loader and traffic generator were later removed, but external script loading remained a concern.
Administrators should block the listed infrastructure domains, especially on school and corporate networks where proxy use is common. Users who accessed affected sites should clear browser cookies, cached files, and service workers.
Development teams should remove matching packages from manifests and lockfiles, rebuild from clean sources, and verify that direct and indirect dependencies are gone.
Security teams should also review web filtering logs for visits to tutoring-themed proxy pages and investigate unusual browser upload activity.
Since the harmful code was delivered after a page loaded, endpoint alerts focused only on package installation may miss affected users. Browser telemetry and DNS records are therefore important for scoping exposure across campus networks today.
Indicators of compromise (IoCs):-
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.