Malicious RubyGems Turn Developer Machines Into Monero Miners and Spread Through SSH

A malicious RubyGems campaign has turned seemingly useful developer packages into tools for hidden cryptocurrency mining.

The poisoned packages can consume a machine’s computing power, slow down development work, and quietly generate Monero for the attackers.

The campaign also goes beyond a typical package-based infection. One set of malicious gems can examine a compromised developer machine for SSH credentials and known systems, creating a route for the infection to move into other servers and workstations.

Researchers from Unit 42 identified two related groups of malicious RubyGems uploads that used similar naming patterns and targeted developers looking for common libraries.

The activity shows how attackers can exploit the trust developers place in public package repositories.

In total, the first operation published 113 trojanized gems that received 14,253 downloads, while the second uploaded 23 malicious packages.

A related account had uploaded another 309 gems, with more than 139,000 downloads, although no harmful code had been found in those packages at the time of analysis.

Unit 42 said in a report shared with Cyber Security News (CSN) that the packages copied legitimate Ruby libraries and altered their entry-point files to launch mining code.

The threat is especially concerning because a normal dependency install can become the first step in a wider infrastructure compromise.

Malicious RubyGems Turn Developer Machines Into Monero Miners

The first actor used automated-looking package names built from simple words such as “ultra,” “smart,” “tool,” and “kit.”

This approach can make a package appear ordinary during a rushed dependency search, particularly when developers are trying to find a small utility or replacement library.

Each package carried the same mining payload, but it waited five hours before running. That delay is designed to avoid quick checks in automated sandboxes, where suspicious software is often watched only for a short period after installation.

The malware also checks whether it is running inside common virtual machines, containers, or debugging environments.

If it detects an analysis setup, it can avoid executing, making the activity harder for defenders to spot during basic investigation.

Once active, the miner limits itself when the system is busy. That may reduce obvious performance problems, allowing it to remain on a developer machine longer while still using spare processing capacity to mine cryptocurrency.

A second group used a simpler approach. Its gems included a hidden Ruby file that downloaded the mining program when the package was loaded, then launched it directly without the same persistence or anti-analysis features.

Some of the second group’s packages were typosquats, meaning their names were deliberately made to look like trusted libraries with minor spelling changes.

Developers should remain alert to this risk, as earlier malicious RubyGems package attacks have also shown how dependency names can be used to mislead users.

SSH Worm Raises Stakes

The more advanced payload did not stop at mining. It searched for SSH private keys and known-host records, then attempted to connect to systems already trusted by the compromised machine.

This could allow one infected development endpoint to become a stepping stone into build servers, cloud workloads, or other internal systems.

It also tried to spread through local development assets. The malware could alter Node.js package files, Python setup scripts, Ruby gem specifications, Dockerfiles, Git hooks, and Visual Studio Code extensions, broadening its reach across languages and tools.

That cross-language behavior makes cleanup more difficult. A team may remove the original Ruby dependency but still miss a changed project file, a compromised container build, or a malicious Git hook that reinfects systems later.

The campaign underlines why package reviews must include publisher history, download patterns, source code, and exact dependency names.

Organizations should audit recent RubyGems installations, investigate unusual processor use, review SSH access logs, rotate potentially exposed keys, and monitor for unexpected connections to mining infrastructure.

Security teams should also block the indicators below where appropriate and search endpoints for the listed artifacts.

Monitoring outbound traffic is important, particularly because cryptojacking activity can blend into normal developer workloads until systems begin to slow down.

Indicators of compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

ALERT!: 20+ government sites delivered malware to businesses and citizens. See full attack research to check your own exposure.