Security researchers Moe Ghasemisharif, Ruian Duan, Zhanhao Chen, and Daiping Liu have uncovered a RubyGems cryptojacking campaign that distributed trojanized copies of popular Ruby libraries.
The malicious packages delay execution for five hours, check for sandboxed environments, and then deploy the XMRig miner to secretly mine Monero on compromised systems.
The campaign involves at least two publisher accounts, Prvaz12_mars and monib110, which used similar package names but deployed different levels of malicious functionality.
A third account, Andrey78, published hundreds of similarly named gems and may represent a staging or testing component of the operation.
The most capable activity was linked to the RubyGems account Prvaz12_mars, associated with jdvrie98@gmail[.]com.
The account published 113113113 malicious gems on July 131313, 202620262026, which received 14,25314,25314,253 downloads.
The packages impersonated legitimate Ruby libraries and used generic three-word names such as ultra-smart-tool, nano-sharp-kit, and hyper-safe-hub.
Each gem contained an identical XMRig-based cryptojacking payload injected into the bundled library’s entry-point file.
The payload starts a background Ruby thread containing sleep 18000, delaying the malicious routine for 555 hours.
This timing helps it avoid automated security systems, which often execute a package for only a short time before declaring it safe.
Before mining begins, the malware checks for virtual machines, including VMware, VirtualBox, and QEMU.
It also looks for container indicators such as /.dockerenv and cgroup artifacts, along with debugger-related traces. If it identifies an analysis environment, it stops execution.
The malware limits mining activity when the host is busy and sets XMRig’s CPU thread limit to 50%50\%50%. This reduces obvious performance degradation that could alert developers or system administrators.
RubyGems Evade Sandboxes Mine Monero
The Prvaz12_mars payload is more than a miner. It establishes persistence by modifying ~/.bashrc, adding a crontab task, and creating a systemd user service.
It also attempts lateral movement by reading ~/.ssh/id_rsa and ~/.ssh/known_hosts, then attempting to spread to known SSH hosts.
Researchers found cross-language propagation features capable of modifying local development projects.
The worm-like component targets Node.js package.json post-install scripts, Python setup.py files, Ruby .gemspec files, Dockerfiles, Git pre-commit hooks, and Visual Studio Code extensions.
Its configuration is protected with layered AES-256256256-GCM, RSA-409640964096, and ChaCha20 encryption.
The miner connects to several pools, including pool. moneroocean[.]stream, p2pool[.]io, pool.supportxmr[.]com, and de.monero.herominers[.]com, using the Monero wallet:
The malicious code is stored in lib/.threadpool.rb and loaded from the gem’s main entry point. It uses a plaintext XMRigLauncher module to download the latest XMRig release through the GitHub API.
It starts the miner through exec(). Unlike the first cluster, it has no persistence, propagation, obfuscation, or sandbox checks.
Developers should immediately audit Gemfiles, lockfiles, build systems, CI runners, and developer endpoints for the listed package names and IOCs.
Teams should remove suspicious gems, rotate SSH keys and repository credentials where exposure is suspected, inspect persistence mechanisms, and review recent changes to project files and Git hooks.
Dependency pinning, package allowlists, typo detection, and automated software supply-chain scanning can reduce exposure to similar attacks.
Cut SOC investigation blind spots and contain threats earlier to reduce response costs and business disruption with ANY.RUN.
