148 npm Packages Turned Student Proxy Visitors Into DDoS Bots

A campaign involving 148 npm packages used student web proxies to turn visitors’ browsers into sources of distributed denial-of-service traffic.

The packages promoted functional tools for bypassing school or workplace website restrictions. Behind the proxy interface, some versions loaded hidden JavaScript that generated HTTP floods and large numbers of WebSocket connections.

The attack did not rely on malicious code running during package installation. According to JFrog’s Lucide Proxy investigation, the harmful activity started when someone opened a deployed proxy page in a browser.

Lucide Proxy targeted students looking for unblocked websites

The campaign used the Lucide Proxy brand and presented some deployments as tutoring services named Riverbend Tutoring and Northstar Tutoring. The websites allowed visitors to reach blocked pages and games through the Scramjet web proxy framework.

This legitimate proxy function made the pages more convincing. Students could use the service as expected while advertising, tracking, remote scripts, and traffic-generation modules operated in the same browser session.

Researchers traced the packages to npm accounts named `terminal3airport` and `eerikakirk`. Package names included `charlie-kirk`, `ilovefemboys`, `miguelphonk`, `whatsadmaidk`, `changiairportpromax`, and multiple numbered package families.

Campaign detail	Finding
Total packages	148
Main brands	Lucide Proxy, Riverbend Tutoring, and Northstar Tutoring
Delivery method	Browser-based proxy pages hosted with npm package assets
Initial documented packages	141 from the terminal3airport account
Main victims	Visitors to deployed proxy websites
Malicious capabilities	Remote JavaScript loading, HTTP flooding, and WebSocket traffic generation
July package content	Obfuscated adware builds without the earlier DDoS modules

The packages did not infect developers during installation

The campaign differed from conventional npm malware that steals credentials, adds a backdoor, or runs commands through an installation hook. These packages contained static files for a browser application.

SafeDep’s original analysis found no npm lifecycle hooks or credential-stealing component in the first 141 packages. The researchers classified the activity as npm registry abuse and adware distribution at that time.

The packages used npm as free, disposable hosting for the proxy’s web assets. A developer could download one without immediately triggering the documented DDoS behavior, although deploying the included application would expose visitors to its browser code.

• The packages were not designed as normal Node.js libraries.
• The package entry point referenced a proxy service worker.
• The files provided a working Scramjet-based web proxy.
• Popunder advertisements appeared after user interaction.
• External scripts and Google Analytics tracked visitor activity.
• The dangerous traffic modules ran inside visiting browsers.

Deobfuscation exposed two hidden traffic modules

JFrog analyzed a 5.4 MB JavaScript bundle named `assets/73sxysj46r.js`. The original bundle appeared as a single heavily obfuscated line containing encoded strings, generated identifiers, lookup tables, and arithmetic expressions.

After deobfuscation, the file expanded to more than 20,600 lines of readable JavaScript. Two hidden functions ran before the React interface rendered.

One function loaded remote JavaScript through jsDelivr from the main branch of an attacker-controlled GitHub repository. Because the loader referenced a mutable branch rather than a fixed commit, its operators could change the delivered script without publishing another npm version.

The page did not use a Subresource Integrity hash to verify the remote file. Any replacement script could therefore run with the proxy application’s origin privileges and potentially access its cookies, local storage, and same-origin endpoints.

An archived script generated an HTTP flood

JFrog recovered a historical copy of the second-stage script from May 30. The payload sent a large cross-origin POST request to a website belonging to an educational institution.

Every 500 milliseconds, the script generated a string containing one million characters, converted it into a JSON request body, and transmitted it. It did not wait for an earlier request to finish before creating the next one.

The researchers estimated that one active browser could generate roughly 2 MB of upload traffic per second. Under ideal conditions, 1,000 simultaneously active visitors could produce an aggregate rate of about 2 GB per second.

HTTP flood behavior	Observed value
Request interval	Every 500 milliseconds
Generated string size	One million characters
Requests per browser	Approximately two per second
Estimated upload per browser	Approximately 2 MB per second
Estimated traffic from 1,000 browsers	Approximately 2 GB per second
Cache avoidance	Random query parameter added to requests

Actual traffic would depend on browser behavior, connection speed, network controls, and server availability. Even at lower rates, many browsers sending continuous large requests could disrupt the targeted service.

WebSocket code attacked a proxy server’s control plane

A second module downloaded live WebSocket settings from a remote text file. The configuration supplied a Wisp server address and a connection count between one and 1,024.

An archived configuration told each visitor’s browser to establish 30 WebSocket connections. Once connected, every socket repeatedly sent valid Wisp CONNECT and CLOSE control frames.

The commands asked the remote Wisp server to create and destroy connections to `localhost` on port 1. JFrog calculated that the most aggressive configuration could make one browser request up to 10,240 socket operations per second.

• The configuration used a remotely changeable text file.
• The application bypassed its browser cache when retrieving settings.
• Each connection sent a new frame pair every 100 milliseconds.
• The frames followed the Wisp v2 protocol format.
• The target was the remote proxy server rather than the visitor’s computer.

This technique could consume socket capacity, processing resources, and log storage on the targeted server. It also demonstrates how ordinary browser traffic can participate in a protocol-aware denial-of-service attack without installing native malware.

DDoS functions operated for about two weeks in May

The campaign changed significantly over time. The earliest observed Lucide page from March contained adware but no identified DDoS capability.

The operators added the mutable script loader on May 16 and introduced the Wisp traffic generator on May 17. A later update increased the maximum WebSocket count from 64 to 1,024.

An archived page recorded the HTTP flood on May 30. On May 31, the operators removed the remote loader and Wisp modules, returning the upstream build to its ad-supported configuration.

Date	Campaign development
March 5, 2026	Earliest observed Lucide page, with adware only
March 16, 2026	External advertising scripts added
May 7 to May 27, 2026	terminal3airport publishes 141 packages
May 16, 2026	Mutable remote JavaScript loader added
May 17, 2026	Wisp WebSocket traffic generator added and expanded
May 30, 2026	Archived HTTP flood payload observed
May 31, 2026	Remote loader and DDoS modules removed
July 8, 2026	Second package wave raises the total to 148

The July packages contained obfuscated, ad-supported builds without the DDoS modules identified in the May versions. However, external third-party script loading remained, creating a route through which behavior could change again.

SafeDep initially identified adware and registry abuse

SafeDep documented 141 packages published by the `terminal3airport` account between May 7 and May 27. Of those, 116 appeared in a mass-publishing wave completed in less than 35 minutes.

The researchers found byte-identical web content across the packages, apart from changes to package metadata. A publishing script changed the package name, uploaded it, and continued through numbered name families.

The SafeDep report documented popunder ads, third-party tracking, Discord OAuth, and a service worker that intercepted proxied navigation. Its initial static review did not identify the historical DDoS functions later recovered through deeper deobfuscation and archived files.

This difference illustrates why static analysis of the current package may not reveal every past behavior. Mutable external resources can change independently, while archived scripts may preserve evidence of functions that operators later removed.

Schools should monitor browser and DNS activity

Endpoint tools focused on executable files or npm installation commands may miss this campaign. A student only needed to visit an affected proxy deployment for the browser-based modules to run.

Schools and businesses should review DNS, web filtering, proxy, firewall, and endpoint browser records. Sustained browser upload traffic, repeated WebSocket connections, and visits to tutoring-themed proxy pages deserve investigation.

The latest JFrog remediation guidance recommends blocking campaign infrastructure, clearing stored browser data, removing suspicious service workers, and auditing npm dependencies.

• Block confirmed campaign domains through DNS and web filters.
• Search logs for visits to Lucide and tutoring-themed proxy deployments.
• Investigate unusual outbound POST traffic and WebSocket bursts.
• Clear cookies, cached files, local storage, and affected service workers.
• Remove campaign packages from manifests and lockfiles.
• Rebuild affected projects from clean, verified sources.

Corrected indicators of compromise

The following indicators come from JFrog’s published research. They are defanged to prevent accidental access and should be evaluated in context before blocking shared hosting infrastructure.

Type	Indicator
Remote script	hxxps://cdn[.]jsdelivr[.]net/gh/canyoupleasesaysomething/cdn@main/cdn[.]js
WebSocket configuration	hxxps://cdn[.]jsdelivr[.]net/gh/canyoupleasesaysomething/cdn@main/websocket[.]txt
Archived flood target	hxxps://cdn[.]caan[.]edu/-/?v=
Domain	woofbeginner[.]com
Domain	wisp[.]breadarchive[.]dpdns[.]org
Domain	21baseballacademy[.]com
Domain	lucideon[.]top
Domain	c[.]vipersfutbol[.]com
Domain	realizationnewestfangs[.]com
Domain	protrafficinspector[.]com
Domain	preferencenail[.]com
Domain	skinnycrawlinglax[.]com
Domain	cdn[.]conditionfuneral[.]com
IP address	92[.]38[.]177[.]17
IP address	92[.]38[.]177[.]10
IP address	153[.]75[.]225[.]178
IP address	5[.]188[.]124[.]67
IP address	92[.]38[.]177[.]16
IP address	92[.]38[.]177[.]37
Analytics identifier	G-0VL3ZSBXDH
File	assets/73sxysj46r.js
SHA-256	eb4e1394d537d8eba509dd5c57e7aaf4c1df57715c7161330012a11f6202af84
SHA-256	10ddbbae0070267b8d15888b09a3cdb19fa74d861315b71f21c9ace8b9f85c75
SHA-256	4b188d179e50e8208a6efec85e273e88d8fc390c836f299ba12915e0840408fd

Names such as `whatsadmaidk`, `changiairportpromax`, and `testdonotredeemit` are npm package names rather than domains. Development teams should search manifests, lockfiles, artifact caches, and build logs for them and the other packages in the researchers’ complete list.

Users who only installed a listed package did not necessarily execute the browser DDoS modules. Exposure depended mainly on serving or visiting the web application, but organizations should still remove the packages because researchers classified the campaign as malicious.

FAQ