Lucide Proxy: Turning Student Web Proxies into DDoS Bots

We deobfuscated a massive campaign of 148 npm packages, including ilovefemboys, miguelphonk, and charlie-kirk. Disguised as student web proxies under names like Riverbend Tutoring, these packages hid mutable remote code execution vectors and a high-performance Wisp-compatible WebSocket traffic generator. They were designed to silently enlist visiting browsers into distributed denial-of-service botnets while generating aggressive popunder advertising revenue.

During a recent registry audit, we identified a highly active npm malware campaign consisting of 148 packages published under suspicious names. The first wave was uploaded beginning on May 27, 2026, by the npm account terminal3airport, followed by a newer wave on July 8, 2026, by eerikakirk. Many of these packages were removed from npm, but several remained active, including charlie-kirk version 2.0.0 and version 3.0.1.

The campaign's public-facing presentation is a web proxy application branded as "Lucide," disguised as a tutoring landing page named "Riverbend Tutoring" or "Northstar Tutoring." When a user visits the proxy page, the application functions normally, allowing students to browse restricted websites or play games. However, beneath this functional facade, the application executes a series of malicious scripts that connect visitor browsers to a coordinated, remotely controlled traffic-generation network.

This campaign is not a traditional dependency infection. The packages contain no installation lifecycle hooks or native node build scripts. Instead, they abuse the npm registry as a free, high-bandwidth content delivery network to host the static browser application assets. Users are affected when they visit any instance of these web proxies, turning their browser sessions into active denial-of-service nodes.

Prior analysis and what was missed

The early wave of this campaign was covered by SafeDep in a brief advisory, which documented 141 packages published by the terminal3airport account. At the time, prior reporting classified the campaign purely as adware spam and npm registry abuse. SafeDep noted that the packages hosted an ad-supported Scramjet proxy targeting student users to generate click revenue via popunders.

However, static analysis and deobfuscation of the active entry bundles reveal that the campaign carries highly toxic capabilities that were completely undocumented. By tracing the historical evolution of the upstream builds and retrieving archived payloads from the Internet Archive, we recovered the actual operational history of the campaign. During a critical window in late May, the operators actively weaponized the proxy network, turning each visiting student's browser into a high-rate HTTP flood source and a protocol-level WebSocket traffic generator.

Coordinated infrastructure and identities

We traced the campaign back to a group of closely coordinated GitHub accounts and infrastructure.

The active application assets were compiled and distributed from a public GitHub repository under the organization lucideproxy. Metadata from GitHub reveals a tight registration timeline:

• The account coinbaselarper was created on April 12, 2026, at 02:34:09 UTC.
• The account simswaplarper was created exactly 43 seconds later, at 02:34:52 UTC.
• The lucideproxy organization was created at 02:46:33 UTC, just twelve minutes after coinbaselarper.
• The build repository lucideproxy/svg was created at 03:54:05 UTC.

Most commits in the build repository were authored by coinbaselarper, who listed the public commit email main@geeked.wtf and the Discord alias @ap5z. A second account, svg-bot, registered with the email stefanvangetson54@gmail.com, was also used to automate publication.

The hosting footprints are highly concentrated. A pivot on the campaign's stable Google Analytics property (G-0VL3ZSBXDH) and monetization domains recovered 93 deployment hostnames. Ninety of these deployments resolved to a single IP address: 92.38.177.17, hosted in AS199524 (G-Core Labs).

The domains used for these deployments were deep, rapidly changing, education-themed subdomains, such as:

• teamparker.id.au (37 scans)
• homeless.camdvr.org (21 scans)
• appleishealthy.duckdns.org (16 scans)

The threat actors also registered a large number of bizarre, highly specific npm package names. Standalone titles include charlie-kirk, testdonotredeemit, acidic, backupgenuine-updated, bismillahitidakimas, bomboclatwallahi, captainindia, crazynut, fflc-updated, howmanygreatbritain, kirkland, lowkeybored, lowkirkuenly, midnightrush, miguelphonk, omglucidesotuff, omgyesyesyes, pasirianspirit, thebigyahu, whatsadmaidk, changiairportpromax, and ilovefemboys.

The rest of the campaign consists of numbered batches. These include the abuden, imillegal, ishowfeet, nottuff, ratelimitsucks, sixseven, speed, backupsitetuff, and timmytuffknuckles families of packages. The actor also used a loosely numbered backup family, with names such as backup1-gg up to backup5-updated.

Technical analysis of the execution chain

The entry point of the application is loaded from index.html, which runs assets/73sxysj46r.js. This file was distributed as a 5.4 MB, single-line bundle with heavy string arrays, rotation functions, hex-identifier decoding, and arithmetic expressions used to hide simple constants. Before deobfuscation, the original file was a single, massive line of code. After passing it through static deobfuscation, this single line of code expanded into over 20,600 lines of fully structured, readable JavaScript, exposing the hidden logic.

Upon loading, and before any user interface is rendered, the application tail-executes two hidden modules:

The functions G2() and I2() are responsible for the remote code execution and traffic generation capabilities, respectively.

1. Mutable remote JavaScript loader (G2)

Before deobfuscation, the jsDelivr URL is assembled from decoder calls and partial strings, while the loader function is buried beneath generated identifiers and numeric lookup tables:

After running the deobfuscator, the mutable remote URL and the script injection sequence become explicit:

This loader implements several dangerous design patterns:

• Mutable Target: The loader targets the mutable main branch of a GitHub repository rather than an immutable commit hash.
• No Integrity Checks: No Subresource Integrity (SRI) hash is provided, allowing the owner of the GitHub account canyoupleasesaysomething to change the code executed by every visitor at any time.
• Full Origin Privilege: The loaded script runs with the same origin privileges as the proxy app, giving it full access to cookies, local storage, and same-origin API endpoints.
• Concealed Source: The referrerPolicy = "no-referrer" attribute reduces the referrer visibility in the request, helping to conceal the originating site.

2. The CAAN Academy HTTP flood payload

Although the GitHub repository canyoupleasesaysomething/cdn returned HTTP 404 at our analysis time, we recovered a historical response from May 30, 2026, using Wayback Machine archives. This snapshot captured the actual second-stage payload (cdn.js) that was actively served to visitor browsers.

The recovered script was extremely simple but highly destructive:

This payload is an unthrottled browser-based HTTP flood:

• It sets an interval that runs every 500 milliseconds.
• Every half-second, it generates a fresh one-million-character string using "a".repeat(1000000).
• It serializes this string into a JSON request body and issues a cross-origin POST request to cdn.caan.edu, the public network domain of the CAAN Academy of Nursing in Matteson, Illinois.
• Because the interval is unthrottled and does not await the response of prior requests, the client browser will continuously pile up outgoing requests, consuming all available system memory and upload bandwidth.
• At a rate of two 1MB requests per second, each active proxy visitor generates roughly 2 megabytes per second of raw upload traffic. A fleet of only 1,000 active visitors would generate an aggregate flood of 2 gigabytes per second, easily overwhelming a school's public website.
• The randomized query parameter v defeats caching proxies, and mode: "no-cors" allows the simple cross-origin POST to skip CORS preflight, ensuring the packet is sent immediately.

3. Remote WebSocket configuration (I2)

The same contrast appears in the WebSocket module. Before deobfuscation, the configuration URL and operational constants are reconstructed through decoder calls and arithmetic:

The deobfuscated output reveals the mutable websocket.txt endpoint, the 1,024-socket limit, the localhost destination, and the loop that staggers each connection by 120 milliseconds:

The application fetches websocket.txt with cache: "no-store" to bypass browser cache and retrieve the configuration in real-time. It parses the text file for two values: a target WebSocket URL (ws:// or wss://) and a numeric connection count constrained between 1 and 1,024.

An archived copy of websocket.txt recovered from the attacker's GitHub repository contained:

This configuration instructed each visitor's browser to open 30 WebSocket connections to the specified Wisp endpoint. At analysis time, lunaron.top was itself hosting a working web proxy:

Once parsed, the application enters a staggered loop, launching the connection pool with a 120-millisecond delay between sockets.

4. Protocol-aware control-plane attack

Once a WebSocket connection is successfully established with the target, the application sets the socket's binaryType to arraybuffer. Every 100 milliseconds, each of the active connections sends a pair of binary packets: a CONNECT packet followed immediately by a CLOSE packet.

These packets are built using little-endian byte orders and match the transport semantics of the Wisp v2 protocol:

Connect Packet Structure (17 bytes):

• Offset 0: 0x01 (Connect Opcode)
• Offset 1: Stream ID (4-byte little-endian)
• Offset 5: 0x01 (Hostname address type)
• Offset 6: Port 1 (2-byte little-endian)
• Offset 8: localhost (9-byte ASCII string)

Close Packet Structure (6 bytes):

• Offset 0: 0x04 (Close Opcode)
• Offset 1: Same Stream ID (4-byte little-endian)
• Offset 5: 0x02 (Close reason/status code)

Because the proxy application utilizes a Scramjet and Wisp background bridge to route browser traffic, these packets are syntactically valid Wisp control frames. The target is not the visiting user's local machine, but rather the remote Wisp proxy server.

By sending a rapid stream of CONNECT frames targeting localhost:1 followed by a CLOSE frame for the same stream ID, a single visitor's browser asks the remote Wisp server to establish and destroy up to 10,240 socket connections per second.

In legacy Wisp implementations, such as Mercury Workshop's wisp-server-node, each received CONNECT frame triggers the immediate instantiation of a new net.Socket and launches an asynchronous socket connection without verifying if the target is a loopback or private address. Additionally, the server logs every connection attempt at the INFO level.

At the maximum configuration of 1,024 concurrent WebSockets, a single browser session can force a target Wisp server to process:

• 10,240 socket allocations and connection attempts per second.
• 10,240 corresponding socket destructions.
• Over 20,000 log writes per second.

This control-plane attack easily exhausts the target server's file descriptor limits, floods its log storage, and crashes the proxy service entirely.

Controlled capability emulation

To verify these capabilities without risking live network calls, we performed a sandboxed local simulation. Feeding the decompiled variables into a mock browser runtime proved that the remote code easily extracts cookies and local storage tokens, sending them back to the attacker via beaconing. The loopback test also captured the exact binary frames of the Wisp protocol:

This confirmed our manual packet-level reconstruction, demonstrating that the Wisp protocol encoder functions exactly as designed to generate coordinated control-plane traffic.

Evolving monetization: From adware to malware and back

An analysis of 22 public commits in the lucideproxy/svg build repository reveals a rapid evolution of features and threat levels over a very short timeframe:

The timeline shows that the aggressive DDoS capabilities were active for a window of roughly two weeks in May 2026. After public reporting began, the operators cleanly stripped the remote loader and Wisp traffic generators from the upstream repository, reverting the build back to standard popunder adware. The wave of packages published in July 2026 contains these later, adware-only builds.

However, because the underlying application structure remains heavily obfuscated and continues to load external third-party scripts from domains like c.vipersfutbol.com, the threat actor preserves the ability to re-introduce malicious capabilities or direct traffic dynamically.

Remediation guidance

Because this threat is delivered as a client-side web application rather than an installation-phase implant, the remediation steps focus on identifying hosting instances, protecting student workstations, and blocking infrastructure communication.

Step 1: Identify and block malicious domains

Network administrators, particularly in educational and corporate environments where student web proxies are frequently accessed, should immediately block the following domains at the DNS level:

• woofbeginner.com
• c.vipersfutbol.com
• realizationnewestfangs.com
• protrafficinspector.com
• preferencenail.com
• skinnycrawlinglax.com
• cdn.conditionfuneral.com
• lucideon.top
• wisp.breadarchive.dpdns.org
• 21baseballacademy.com

Step 2: Clean browser cache and local storage

Users who have visited any of the affected proxy websites should clear their browser data to remove registered service workers and cached assets:

1. Open the browser's settings menu.
2. Select Clear Browsing Data.
3. Choose to delete Cached images and files and Cookies and other site data for all time.
4. For advanced users, navigate to chrome://serviceworker-internals/ or the equivalent path in your browser and unregister any service worker registered by a tutoring or proxy domain.

Step 3: Audit npm dependencies

If your build pipelines or development environments have fetched any package listed in this campaign, remove every matching package from dependency manifests and lockfiles. Rebuild affected environments from clean sources, then verify that none of the package names in the table below remain in direct or transitive dependencies.

Known malicious packages

Conclusions

The Lucide Proxy campaign illustrates the risks of using third-party unblocking applications and proxies. While students and general users perceive these services as convenient bypass utilities, the underlying infrastructure can be, and has been, used as a weaponized browser botnet. By leveraging mutable remote scripts and high-concurrency connection pools, the threat actors demonstrated how easily static web assets can conduct massive, coordinated floods without direct system infection. Security teams must monitor and block the associated infrastructure domains to keep network resources safe from silent background abuse.

Indicators of Compromise (IOCs)

Domains and URLs

• https[:]//cdn[.]jsdelivr[.]net/gh/canyoupleasesaysomething/cdn@main/cdn[.]js
• https[:]//cdn[.]jsdelivr[.]net/gh/canyoupleasesaysomething/cdn@main/websocket[.]txt
• https[:]//cdn[.]caan[.]edu/-/?v=
• https[:]//woofbeginner[.]com/jivd2xu8
• https[:]//woofbeginner[.]com/0a/91/35/0a913561831bdf2c26dcf18b852b5cc1[.]js
• https[:]//wisp[.]breadarchive[.]dpdns[.]org
• https[:]//21baseballacademy[.]com
• https[:]//lucideon[.]top
• https[:]//c[.]vipersfutbol[.]com/script[.]js
• https[:]//realizationnewestfangs[.]com
• https[:]//protrafficinspector[.]com/stats
• https[:]//preferencenail[.]com/sfp[.]js
• https[:]//skinnycrawlinglax[.]com/dnn2hkn8
• https[:]//cdn[.]conditionfuneral[.]com

Infrastructure IPs

• 92[.]38[.]177[.]17
• 92[.]38[.]177[.]10
• 153[.]75[.]225[.]178
• 5[.]188[.]124[.]67
• 92[.]38[.]177[.]16
• 92[.]38[.]177[.]37

Campaign Identifiers

• Google Analytics: G-0VL3ZSBXDH
• Publisher Placement: 0a913561831bdf2c26dcf18b852b5cc1
• Popunder Key: c6851a038da578a80eeb201e0588c84c
• Developer Email: main@geeked[.]wtf
• Developer Email: me@geeked[.]wtf
• Developer Email: stefanvangetson54@gmail[.]com

Payloads