Typosquatting Attack Strikes RubyGems and npm
Malicious actors brazenly targeted developers utilizing counterfeit packages deployed simultaneously across two highly prominent repositories. Cybercriminals stealthily introduced 16 malicious libraries into RubyGems and strategically placed another 37 within the npm registry. They meticulously selected package names incorporating subtle typographical errors, mimicking widely utilized dependencies. Installing these deceptive lures on a Windows environment triggered the execution of StubMaker, a pernicious data stealer designed to indiscriminately harvest sensitive information. The malware eagerly collected browser passwords, active session tokens, credit card details, cryptocurrency wallet credentials, crucial seed phrases, and Telegram Desktop archives. Comprehensive analysis of both attack sequences revealed a shared infrastructure, an identical payload downloader, and a singular, unified core malicious module.
The RubyGems Infiltration Strategy
Security analysts unearthed the initial phase of this sophisticated campaign on August 15 within the RubyGems ecosystem. The perpetrators heavily relied upon a classic typosquatting technique for malware distribution. In this scenario, an attacker maliciously registers a package bearing a name dangerously similar to a legitimate, popular library. They calculatingly rely upon a developer making a simple typographical error when inputting the installation command or selecting a project dependency. Investigators directly linked 16 specific package names to the StubMaker malware: ubnuler, ubnlder, ri18nr, reaker, rakier, orakw, joxn, ise18n, ioe18n, ie18u, iai8n, i1l8n, i18om, activesupmport, brumdler, and brundlef. These deceptive monikers purposefully imitated essential libraries, including Bundler, i18n, Rake, and Active Support.
Exploiting RubyGems Registration Mechanics
The campaign architects maliciously exploited a specific operational quirk within RubyGems, a feature that permits the re-registration of a previously relinquished package name. At least two packages, brumdler and brundlef, were initially published utilizing one specific user account. Subsequently, the threat actors deleted these packages, allowing the names to seamlessly transition to alternative malicious accounts under their control. When a user deletes all versions of a specific gem, the system renders the name available for immediate registration once again. Consequently, any other user possesses the legitimate right to claim it. Therefore, the mere deletion of a malicious library does not permanently secure or retire the original package name.
Furthermore, an additional obfuscation technique assisted in masking the sinister connections between the compromised packages. Within the RubyGem specification architecture, the authors field accommodates standard, unverified text; it does not function as an authenticated identification record for the package owner. A package creator can simply insert any arbitrary name into this field, completely independent of the actual user account utilized for the publication process. The attackers systematically populated varying author names across several distinct libraries, despite uploading the packages through identical user accounts. The official RubyGems documentation precisely describes authors as a standard metadata field within the gem specification, positioned alongside the package name, version number, description, and contact email address.
Malicious Execution During Installation
The execution of the malicious code commenced immediately during the installation phase of the compromised Ruby package. To trigger the execution, the attackers abused the extconf.rb file, a component traditionally designed for the meticulous preparation of native extensions. Typically, RubyGems executes extconf.rb to rigorously verify the presence of prerequisite functions and libraries, subsequently generating a Makefile essential for the ensuing compilation of the native extension. The official RubyGems documentation explicitly outlines this standard operational workflow.
StubMaker deviously substituted the legitimate compilation process with a completely fabricated procedure. The compromised extconf.rb script generated a deceptive Makefile containing utterly vacant all, install, and clean targets, alongside innocuous stub functions targeting both Unix and Windows environments. These malicious scripts deliberately avoided compiling any functional component. Instead, they simply terminated execution without generating any error codes. Consequently, RubyGems received a deceptive notification confirming a successful compilation. Simultaneously, the installer subtly identified the host operating system and discreetly launched the malicious execution chain. The moniker “StubMaker” specifically derives from the creation of these deceptive stubs, which masterfully concealed the true, malicious intent of the installation script.
Deploying the Windows Payload
Operating within a Windows environment, the malicious Ruby code initiated the download of an approximately 22-megabyte file directly from GitHub. The attackers had previously obfuscated the download URL utilizing Base64 encoding. The retrieved file, designated main.exe, contained a sophisticated loader written in Rust. Nestled within this loader resided an encrypted, executable module, approximately 11 megabytes in size, meticulously crafted using the Go programming language. Crucially, the system did not require a separate download for the primary stealer component. The loader autonomously decrypted the embedded PE file, rigorously verified the crucial MZ signature, located the necessary Windows API functions, and smoothly injected the malicious program directly into system memory.
The Core Data Stealer Module
The primary malicious module, internally identified as wincfg, aggressively hunted for sensitive data, primarily targeting Chromium-based web browsers. The comprehensive list of targeted applications included Google Chrome, Microsoft Edge, Brave, Opera, Opera GX, Vivaldi, Yandex Browser, Avast Secure Browser, AVG Secure Browser, and CCleaner Browser. The malware systematically scoured these browsers for saved login credentials, valuable cookies, active session tokens, extensive browsing history, extension details, and highly sensitive payment card numbers.
Bypassing App-Bound Encryption
To successfully access deeply protected browser data, StubMaker ruthlessly utilized a specific dynamic link library named abe_payload.dll. This specialized library assisted the malware in circumventing App-Bound Encryption (ABE) protections. Google proactively implements the ABE mechanism within Chrome to significantly complicate the theft of local secrets by rogue Windows processes. These highly protected cryptographic keys are intrinsically linked to the specific application authorized to perform the decryption. StubMaker aggressively injected its proprietary DLL directly into the active browser process, subsequently attempting to extract the desired data from within that trusted execution context. Google has publicly confirmed the deployment of App-Bound Encryption as a robust defensive measure against malware attempting to purloin sensitive browser data.
Targeting Cryptocurrency and Telegram
A dedicated, specialized set of functions meticulously gathered valuable cryptocurrency data. The malicious code actively hunted for software-based wallets and prominent browser extensions, including MetaMask, Coinbase Wallet, Phantom, Solflare, Exodus, Electrum, Bitcoin, Litecoin, Dogecoin, Monero, Atomic, Guarda, and Trezor Suite. Furthermore, the stealer exhaustively scanned text and JSON files, desperately searching for word sequences resembling critical recovery phrases. It then rigorously compared any discovered words against the standard BIP-39 dictionary. The malware dutifully recorded all successful findings within specifically designated files named wallets.txt and seeds.txt.
Notably, researchers did not discover any mechanisms designed for the automated transfer of cryptocurrency within the analyzed samples. Instead, StubMaker focused on stealing the crucial data required to facilitate unauthorized wallet access at a later date. Telegram Desktop also featured prominently on the malware’s extensive target list. The stealer actively searched for the tdata directory, the specific location where the Telegram client securely stores localized session data. It also meticulously checked the standard installation paths utilized by the program.
Simultaneously, the malware aggressively harvested the active Windows username, the designated computer name, the specific operating system version, detailed CPU and GPU specifications, the total volume of installed RAM, and the victim’s public IP address. To accurately determine the external IP address, the malware queried the api.ipify.org service.
Exfiltration and Persistence
StubMaker meticulously packed all harvested files into a secure, password-protected ZIP archive, subsequently transmitting it to the Gofile file-sharing service. Following a successful upload, the malware received a direct link to the archive. It then transmitted this crucial URL to the operator via dresslee.com utilizing unencrypted HTTP communications. Accompanying this link, the malware dispatched a comprehensive summary detailing the compromised computer’s specifications, alongside the exact quantity of discovered passwords, cookies, history records, and cryptocurrency data artifacts. The specifically analyzed samples did not attempt to establish permanent persistence via Windows services, the Task Scheduler, autorun registry keys, or the standard Startup folder. The overarching campaign was explicitly designed to execute immediate information theft directly following the installation of the compromised dependency.
The Second Wave: The npm Assault
The following day, investigators uncovered the second, massive wave of the StubMaker campaign. On August 16, a staggering 37 malicious packages materialized within the npm registry, bearing names deceptively similar to Axios, Chalk, Commander, Lodash, TypeScript, and React. Crucially, the attackers did not compromise the legitimate projects; instead, they calculatingly published independent, counterfeit duplicate packages. Prominent examples included axois-http, chalk-core, comander-cli, loadashjs, typescirpt-cli, and raectjs. The malicious authors deliberately transposed letters, omitted characters, and appended suffixes such as -core, -lib, or -cli. This strategy aimed to deceive developers into perceiving the malicious package as a legitimate auxiliary library associated with a well-known project.
Exploiting npm Postinstall Scripts
All 37 malicious npm packages were uniformally designated as version 1.0.0 and contained an essentially identical, malicious postinstall.js script. The npm ecosystem automatically executes postinstall scripts immediately following package installation. Therefore, the targeted developer was not required to manually import the library or execute any specific function. The mere act of installing the compromised dependency was sufficient to trigger the attack.
The initial execution stages for the RubyGems and npm variants differed significantly. The Ruby variant exploited extconf.rb and concealed the loader’s URL within a Base64 encoded string. Conversely, the npm variant initiated via postinstall and obfuscated the URL using a XOR operation combined with a repetitive, hardcoded key. Following the successful decryption of the URL, both execution chains seamlessly transitioned to downloading the identical Windows loader component.
Targeting Windows Subsystem for Linux (WSL)
The malicious npm packages ingeniously accounted for the presence of the Windows Subsystem for Linux (WSL). Standard Linux and macOS environments are inherently incapable of executing a PE file specifically designed for Windows. However, the malware handled WSL environments uniquely. The installation script, operating from within the Linux environment, directly invoked the Windows powershell.exe executable. It then downloaded main.exe and initiated the loader directly upon the primary host Windows system. Consequently, operating securely within a WSL environment offered the developer absolutely no protection against the Windows-specific version of StubMaker.
Publication Velocity and Unified Infrastructure
The speed at which the attackers published the malicious packages varied considerably between RubyGems and npm. The Ruby libraries appeared sequentially over a two-day period. Following the deletion of one batch, the operator seamlessly switched user accounts and continued the publication process. In stark contrast, the attackers uploaded the primary group of npm packages in approximately eight minutes, utilizing five distinct accounts. Distributing the packages across multiple, temporary profiles effectively reduced the campaign’s reliance upon any single user account, although the npm security team rapidly detected and eradicated the entire malicious group.
A unified command and control server ultimately linked the two distinct attack series. Both the RubyGems and npm variants transmitted exfiltrated data to 193.70.34.101:20099/vote. Furthermore, both variants accessed the exact same GitHub Release to download main.exe, retrieving a file possessing an identical SHA-256 hash. Nestled within the loader resided the identical Go-based data stealer. Thus, a singular operator simultaneously propagated the same malicious program through two entirely disparate package ecosystems.
Mitigation and Remediation Strategies
Researchers did not observe any self-propagation mechanisms within StubMaker. The malware did not actively infect legitimate libraries, nor did it hijack the legitimate accounts of their developers. Furthermore, it did not autonomously publish duplicate copies of itself. Successful compromise strictly required the manual installation of one of the specific decoy packages on a Windows or WSL system.
By the time of publication, security teams had successfully eradicated the discovered packages from both RubyGems and npm. Additionally, the GitHub account hosting the malicious loader was rendered inaccessible. Security professionals strongly recommend immediately isolating any computers where the malicious dependency was installed. Users must forcefully terminate all active browser and Telegram sessions and comprehensively change all passwords utilizing a separate, trusted device. If crucial seed phrases were stored on the compromised machine, it is far safer to consider the associated cryptocurrency wallets entirely compromised. Users should immediately transfer all funds to entirely new addresses, meticulously generated within a secure, uncompromised environment.
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
