Two separate threat actor groups have published malicious RubyGems packages that transform developer machines into Monero cryptocurrency miners while spreading through SSH connections to compromise additional systems. The malicious RubyGems packages employed different tactics but shared the common goal of establishing persistent cryptomining operations on developer endpoints.
How Did the First Attack Group Operate?
The first threat actor created packages with automated-looking names built from simple words including “ultra,” “smart,” “tool,” and “kit.” This naming strategy made the packages appear ordinary during rushed dependency searches, particularly when developers searched for small utilities or replacement libraries. Each package delivered identical mining payloads that incorporated a five-hour delay before execution, specifically designed to evade automated sandbox environments that typically monitor suspicious software for only brief periods after installation.
The malware included detection capabilities for common virtual machines, containers, and debugging environments. When analysis setups were detected, the payload avoided execution entirely, making defender investigation significantly more difficult. Once active, the miner throttled its activity when the system was busy, reducing obvious performance degradation while still utilizing spare processing capacity for cryptocurrency mining.
What Approach Did the Second Group Take?
The second group employed simpler tactics. Their gems contained hidden Ruby files that downloaded mining programs when packages loaded, launching them directly without the same persistence or anti-analysis features. Some packages from this group were typosquats, with names deliberately crafted to resemble trusted libraries through minor spelling variations.
How Does the SSH Worm Component Work?
The more sophisticated payload extended beyond mining operations. It searched for SSH private keys and known-host records, then attempted connections to systems already trusted by the compromised machine. This capability allowed a single infected development endpoint to become a stepping stone into build servers, cloud workloads, and other internal systems.
The malware also spread through local development assets by altering Node.js package files, Python setup scripts, Ruby gem specifications, Dockerfiles, Git hooks, and Visual Studio Code extensions. This cross-language behavior significantly complicates cleanup efforts, as teams may remove the original Ruby dependency while missing changed project files, compromised container builds, or malicious Git hooks that reinfect systems later.
What Security Measures Should Organizations Take?
Organizations should audit recent RubyGems installations, investigate unusual processor usage, review SSH access logs, rotate potentially exposed keys, and monitor for unexpected connections to mining infrastructure. Package reviews must include publisher history, download patterns, source code verification, and exact dependency name matching.
The campaign utilized two Monero wallets and multiple mining pools including pool.moneroocean.stream:443, p2pool.io:443, pool.supportxmr.com:443, de.monero.herominers.com:443, and pool.supportxmr.com:3333. Three RubyGems profiles were identified: Prvaz12mars, monib110, and Andrey78, with associated email addresses jdvrie98@gmail.com, nsrtytyam687@gmail.com, and cakoc614@gmail.com respectively.
Source: Cybersecurity News