Nearly 150 malicious npm packages disguised as school Wi-Fi bypass tools have been discovered covertly recruiting visiting browsers into a distributed denial-of-service (DDoS) botnet, marking a significant shift in how open-source ecosystems can be abused to weaponize unsuspecting users. The campaign, which presented itself as harmless tutoring-branded web proxies such as Lucide Proxy, Riverbend Tutoring, and Northstar Tutoring, promised students a way to reach blocked websites and games while quietly loading harmful code in the background. Unlike a typical malicious npm package that infects a developer’s machine during installation, these packages acted solely as a delivery system for browser-based proxy pages, meaning anyone who opened one of the hosted sites could be exposed to popunder advertising, tracking, and, during a key period, traffic-flooding code.
How the Lucide Proxy Campaign Weaponized Browsers
Researchers from JFrog and SafeDep independently identified stages of the activity, with SafeDep first documenting 141 related packages as adware-hosting abuse in May, before JFrog deobfuscated the application and uncovered remote code loading and DDoS functions that had operated in late May. 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. The first wave began on May 27, and a later wave appeared on July 8, bringing the total to 148 packages. While many packages were removed, some remained available at the time of publication.
The visible service worked exactly 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. A service worker routed proxy traffic and injected code that could capture navigation events, while advertising scripts opened popunder pages after user interaction. 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. This 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 to an attack.
Hidden Loaders Enabled Large-Scale DDoS Traffic
JFrog’s analysis uncovered an obfuscated JavaScript bundle that loaded two hidden modules before the proxy interface appeared. One module pulled a remotely hosted script from a mutable GitHub branch without any integrity check, giving operators the ability 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 approximately 2 MB of upload traffic per second, and a thousand visitors could produce roughly 2 GB per second — enough traffic to 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 the external script loading mechanism remained a concern, leaving the infrastructure capable of being reactivated at any time.
Indicators of Compromise and Remediation Guidance
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 both 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.
The campaign leveraged domains including whatsmadmaidk, changiairportpromax, testdonotredeem, and infrastructure URLs such as https://cdn.jsdelivr.net/gh/canyoupleasesaysomething/cdn/main/cdn.jscodecodecodecodecode and https://cdn.jsdelivr.net/gh/canyoupleasesaysomething/cdn/main/websocket.txtcodecodecodecodecode. Additional indicators include the IP addresses 92.38.177.17, 92.38.177.101, 53.75.225.178, 5.188.124.67, and the obfuscated JavaScript file assets73sxysj46r.jscodecodecodecodecode (SHA-256: eb4e1394d537d8eba509dd5c57e7aaf4c1df57715c7161330012a11f6202af84).
What Affected Users and Organizations Should Do Now
For individual users who may have visited any tutoring-themed proxy site, immediately clear all browser cookies, site data, and registered service workers. Update your browser to the latest version and consider using a reputable ad-blocker or script-blocker extension to prevent similar code injection in the future. For organizations, particularly schools and universities, review DNS logs for connections to the domains listed above, block the identified infrastructure IP ranges at the network perimeter, and deploy endpoint detection rules that flag unusual outbound POST traffic from browsers. This campaign demonstrates that the attack surface in open-source ecosystems extends beyond developer workstations — any user who visits a page served from a compromised package can become a participant in a DDoS attack. Proactive monitoring of web filtering logs and browser telemetry is essential for detecting these types of client-side threats before they cause service disruption.
