Over 150 Malicious npm Packages Enable DDoS Attacks on Students

Key Takeaways

• A campaign involving nearly 150 malicious npm packages masqueraded as school Wi-Fi bypass tools.
• These packages were not designed to infect developer systems but rather to serve malicious browser-based proxy pages.
• Visitors to these proxy pages were exposed to pop-under ads, tracking, and, critically, code that transformed their browsers into participants in DDoS attacks.
• The operators leveraged npm for static asset distribution, dynamically altering malicious functionality via remote scripts, making detection and takedown challenging.
• The DDoS functionality, active in late May, specifically targeted an educational website, generating significant traffic.

A sophisticated campaign has been uncovered where approximately 150 npm packages, disguised as legitimate Wi-Fi bypass tools for students, were weaponized to transform unsuspecting browsers into nodes for distributed denial-of-service (DDoS) attacks. This deceptive operation presented itself as benign web proxies, offering students a way to access restricted websites and games, while covertly injecting malicious code in the background.

Unlike conventional malicious npm packages that typically compromise a developer’s system during installation, this operation primarily functioned as a delivery mechanism for browser-based proxy pages. Users who accessed these hosted sites were unwittingly subjected to various illicit activities, including pop-under advertising, extensive tracking, and, during a specific period, code designed to flood target networks with traffic. Researchers from JFrog and SafeDep collaboratively identified and analyzed the different phases of this campaign.

SafeDep initially documented 141 of these packages in May, categorizing them as adware-hosting abuse. Subsequently, JFrog successfully deobfuscated the application, revealing its remote code loading and DDoS capabilities, which were actively deployed in late May. JFrog said in a report that these findings underscore the significant risks that seemingly innocuous bypass sites can pose to educational institutions, corporate environments, and individual users.

The attackers exploited npm’s widespread accessibility for distributing static web assets. They then dynamically changed the proxy’s behavior after a visitor landed on the page by using external scripts. This method allowed them to modify the malicious payload without updating the npm packages themselves, enhancing their operational flexibility and evasion tactics.

Deceptive Tactics and Malicious Functionality

The campaign utilized branding and web pages associated with names like Lucide Proxy, Riverbend Tutoring, and Northstar Tutoring. The front-facing service performed its advertised function, routing browser traffic through a proxy to circumvent content restrictions. This seemingly legitimate behavior was crucial in camouflaging the malicious scripts operating concurrently.

JFrog reported that the initial wave of malicious packages emerged on May 27, followed by a second wave on July 8, bringing the total to 148 packages. While many of these packages have since been removed, some remained accessible at the time the research was published.

The earlier analysis by SafeDep indicated that the packages lacked traditional installation hooks or credential-stealing components. Instead, they contained web files designed to be served from npm-backed infrastructure. A service worker was employed to route proxy traffic and inject code capable of capturing navigation events. Concurrently, advertising scripts triggered pop-under pages following user interactions.

This distinct approach meant that the primary victims were not developers integrating these packages into their projects. Instead, any student simply visiting a deployed proxy page could unknowingly contribute their browser’s resources to the malicious activities. This strategy also complicated takedown efforts, as the same core files could be replicated across numerous package names and hosting locations, making it difficult to eradicate the threat entirely.

Hidden Loaders Enabled DDoS Traffic

JFrog’s in-depth analysis revealed an obfuscated JavaScript bundle that executed two hidden modules before the legitimate proxy interface became visible. One module retrieved a remotely hosted script from a mutable GitHub branch, critically lacking any integrity checks. This allowed the attackers to modify the code delivered to every visitor dynamically, circumventing the need to republish the npm package for each change.

An archived second-stage payload was designed to transmit repeated, large POST requests to a targeted educational website every half-second. JFrog’s estimations suggest that a single active browser could generate approximately 2 MB of upload traffic per second. With a thousand concurrent visitors, this could escalate to roughly 2 GB of traffic per second, a volume sufficient to significantly degrade or overwhelm a public-facing service.

Another component dynamically fetched live WebSocket settings, instructing browsers to establish high-speed connections to a Wisp-compatible proxy endpoint. This functionality enabled the rapid creation and termination of WebSocket connections, effectively stressing a server’s socket capacity and logging systems. While the remote loader and traffic generator components were eventually removed, the persistent threat of external script loading remains a concern.

What You Should Do

• For Network Administrators: Block all listed infrastructure domains (e.g., whatsadmaidk, changiairportpromax, testdonotredeem, 21baseballacademy.com, lucideon.top, cdn.conditionfuneral.com, wisp.breadarchive.dpdns.org, realizationnewestfangs.com, protrafficinspector.com, preferencenail.com, skinnycrawlinglax.com) and IP addresses (e.g., 92.38.177.17, 92.38.177.101, 53.75.225.178, 5.188.124.67, 92.38.177.169, 92.38.177.37) on all network perimeters, especially within school and corporate environments where proxy usage might be prevalent.
• For End-Users: If you have visited any tutoring-themed proxy pages, immediately clear your browser’s cookies, cached files, and service workers to remove any lingering malicious scripts or tracking elements.
• For Development Teams: Review project manifests and lockfiles to identify and remove any matching packages. Rebuild applications from clean sources and verify that both direct and indirect dependencies are free from these malicious components.
• For Security Operations Centers (SOCs): Enhance monitoring of web filtering logs for any visits to the identified tutoring-themed proxy pages. Investigate any unusual browser upload activity, as the malicious code was delivered post-page load, meaning endpoint alerts focused solely on package installation might not detect affected users. Prioritize browser telemetry and DNS records for comprehensive exposure assessment across campus or enterprise networks.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.