New research from **JFrog** has uncovered a sophisticated operation that used seemingly innocuous **npm** packages to weaponize user browsers for DDoS attacks. Unlike typical supply chain attacks that target developers during installation, this campaign focused on end-users, specifically students seeking to bypass school web filters. The malicious packages, distributed under names like **charlie-kirk**, **ilovefemboys**, and **miguelphonk**, presented themselves as tutoring landing pages such as "Riverbend Tutoring" or "Northstar Tutoring." While the proxies functioned as intended, allowing students to access blocked content, they secretly loaded a remote code loader and a **WebSocket** flood generator capable of speaking the **Wisp** proxy protocol. ### The Mechanics of the Browser Botnet **JFrog**'s deep dive into the obfuscated JavaScript bundle, a 5.4 MB single line of code that expanded to over 20,600 readable lines, revealed two primary malicious modules: * **G2 (Remote Script Loader):** This module fetched JavaScript from a **GitHub** repository via the **jsDelivr CDN**. Crucially, it pointed to a mutable `main` branch without **Subresource Integrity** checks, granting the operators the ability to change the code running in visitors' browsers at will. Archived payloads from May 30 showed this module executing a crude HTTP flood, sending 2 MB per second of upload traffic from each active visitor to `cdn.caan.edu`, identified as the public domain of a nursing school in Matteson, Illinois. * **I2 (WebSocket Flood Generator):** This more sophisticated module retrieved a plain text file, `websocket.txt`, containing a target **WebSocket** URL and a socket count (capped at 1,024). It then opened numerous connections in a staggered loop. The archived configuration directed each browser to establish 30 connections to a **Wisp** endpoint on `lunaron[.]top`, itself a live proxy injecting malvertising. ### Targeting Wisp Servers The **I2** module's attack was a control-plane rather than volumetric. By sending valid **Wisp CONNECT** and **CLOSE** frames every 100 milliseconds, each browser could force a **Wisp** server to allocate and tear down approximately 10,240 connections per second. This activity exhausts file descriptors, floods log storage, and ultimately crashes the proxy server. **JFrog** noted that the deprecated **Mercury Workshop**'s `wisp-server-node` was particularly vulnerable to this type of attack due to its failure to check destination addresses and extensive logging. Essentially, the campaign repurposed a student proxy tool to attack the very servers that other student proxies rely on, alongside a separate HTTP flood aimed at a specific educational institution. ### Operator Profile and Campaign Evolution The operators left a clear trail, with infrastructure clustered tightly and not designed for stealth. **JFrog** traced builds to a **GitHub** organization named `lucideproxy`, with accounts registered seconds apart, tied to an email at `geeked[.]wtf` and a **Discord** handle. Most deployment hostnames resolved to a single IP address, `92.38.177[.]17`, hosted by **G-Core Labs**. Both **JFrog** and **SafeDep**, who previously cataloged 141 of the packages, surmise the operator is young, citing juvenile package names, an auto-publish shell script, and a "TY WAVES + CHATGPT ILY" comment found in a service worker. One account alone pushed 116 packages in under 35 minutes, reportedly without **npm** intervention. The campaign evolved from plain adware in March to include the remote loader and **Wisp** generator in mid-May. The live flood against the nursing school occurred at the end of May, with malicious modules stripped out on May 31 as reporting began. A second wave on July 8, under a new account, brought the total to 148 packages, distributing a cleaned-up, adware-only build. Crucially, the **DDoS** capability was not removed, merely switched off, indicating the operators retain the ability to re-arm it with a single commit to the mutable branch, requiring no package update. Many of the campaign's packages have since been pulled from **npm** and replaced with the standard `0.0.1-security` placeholder. However, a spot check on July 14, 2026, by The Hacker News found that `charlie-kirk` was still serving the malicious versions 2.0.0 and 3.0.1. Given the client-side web app delivery method, **JFrog**'s remediation advice focuses on network administrators in school and corporate environments to mitigate the threat.