大規模なサプライチェーン攻撃により、XMRig Moneroマイナーを展開しSSH経由で自己増殖する136件のトロイの木馬化パッケージがRubyGemsに氾濫し、npmやPyPIにとどまらない言語エコシステム全般の構造的な脆弱性が改めて浮き彫りになりました。
2026年7月22日、研究者のMoe Ghasemisharif氏、Ruian Duan氏、Zhanhao Chen氏、Daiping Liu氏は、RubyGemsをXMRigベースのマイナーの配布経路として悪用する、組織的な暗号資産採掘マルウェア(cryptojacking)キャンペーンについて報告しました。
今回の事案では、「Prvaz12_mars」と「monib110」という2つの異なる攻撃者が共同で、人気のあるRubyライブラリを装った136件の悪意あるgemを公開し、開発者環境を標的に長期にわたるMonero採掘を狙っていました。
最初の攻撃者「Prvaz12_mars」(jdvrie98@gmail[.]com)は、2026年7月13日に113件の悪意あるgemを公開し、発見されるまでに合計14,253件のダウンロードを記録しました。
各パッケージは正規のRubyライブラリをトロイの木馬化したクローンで、giga-fast-kitやnano-safe-libといった、形容詞と名詞を組み合わせた3語構成の合成命名規則を使用しています。これはユーティリティ系のgemに紛れ込ませ、迅速なトリアージを妨害するための工夫です。
攻撃者は同一のXMRig暗号資産採掘ペイロードをライブラリのエントリーポイントに直接注入し、Thread.new{sleep 18000; …}という構文を使って実行を5時間遅延させます。これにより、短命なサンドボックスやCIテストハーネスでの検知を回避します。
ペイロードが起動すると、3つの手段で永続化を図ります。~/.bashrcへの悪意あるシェルコードの追記、crontabエントリの登録、systemdユーザーサービスの登録です。これにより、ログインや再起動をまたいでマイナーが再起動する仕組みになっています。
横方向への移動(ラテラルムーブメント)については、このワームは~/.ssh/id_rsaと~/.ssh/known_hostsを読み取り、到達可能なホストへパスワードなしでの拡散を試みます。これにより、開発者間のSSH信頼関係のグラフが感染経路へと変貌します。
このマルウェアは複数言語に対応しており、Node.js(package.jsonのpostinstall)、Python(setup.py)、Ruby(.gemspec)、Docker(Dockerfile)、git(pre-commitフック)、VSCode拡張機能を改変し、ツールチェーン全体に追加の足がかりを仕込みます。
このペイロードには堅牢な解析回避ロジックが搭載されており、VMware、VirtualBox、QEMUといった仮想化プラットフォームや、/.dockerenvやcgroupの特徴といったコンテナの兆候を確認したうえで、マイナーを起動します。
Palo Alto Networksの研究者らによると、今回の活動は2026年5月に発生した以前のRubyGems悪用の波を受け継ぐものです。当時は数百件の悪意あるパッケージが大量にアップロードされたことを受け、レジストリが新規アカウント登録を一時停止する事態に追い込まれました。
このマルウェアは負荷を考慮した採掘機能を実装しており、システム負荷が高い場合は一時停止し、CPU使用率を利用可能なスレッドの約半分に抑制します。これは正規のXMRigチューニングガイダンスを模倣し、ユーザーの疑念を回避するための工夫です。
136件の悪意あるRubyGemsパッケージ
プールのエンドポイントやウォレットを含む設定データは、AES‑256‑GCM、RSA‑4096、ChaCha20による三重層の暗号化スキームで保護されており、静的解析や自動ルール生成による抽出を困難にしています。
ComputerScience
すべてのgemは、moneroocean、p2pool、supportxmr、herominersという4つのプールを通じて、単一のMoneroウォレットへ採掘した通貨を送金します。このパターンは、これまで侵害されたサーバーや企業のエンドポイントで確認されてきた不正なXMRig運用と一致しています。
2人目の攻撃者「monib110」(nsrtytyam687@gmail[.]com)は、23件の追加の悪意あるgemを提供していますが、その手口はかなり単純なものでした。
7月12日、同一の形容詞・名詞の命名パターンと、「大学の研究に基づく…」といった無害な学術風の説明文を使用してクリーンなプレースホルダーパッケージを公開し、正当性を装う下地を作った後で、その成果物を兵器化しました。
7月16日、23件すべてが更新され、隠しファイルであるlib/.threadpool.rbとして実装された最小限のXMRigランチャーが組み込まれました。これはgemのメインエントリーポイントからrequire_relative ‘.threadpool’によって読み込まれます。
Prvaz12_marsとは異なり、monib110は難読化を施していない平文のRubyコードを使用しており、XMRigLauncherモジュール内にカプセル化されています。このモジュールは、GitHub APIのエンドポイント(api.github.com/repos/xmrig/xmrig/releases/latest)から最新のマイナーバイナリを動的に取得します。
マイナーはexec()経由でインラインに実行され、永続化のためのフックやワーム機能、明示的な解析回避策は備えていません。これは、長期的な足がかりの確保よりも、日和見的で短期間の採掘に主眼を置いていることを示しています。
すべての作業負荷は、pool.supportxmr.com:3333という単一のプールに向けられており、オンチェーン上の帰属特定を複雑にするために公開されているXMRig互換プールを悪用するという、よくある不正採掘のパターンと一致しています。
ディスカバリと初期アクセスの手段として、monib110は2つの命名戦略を採用しています。1つはPrvaz12_marsと同様の合成的な形容詞・名詞のgem名、もう1つは広く利用されているRuby依存パッケージに対する、文字置換(i→1、o→0、文字の重複など)を用いた典型的なタイポスクワッティングです。
この手法は、開発者がわずかなタイプミスやオートコンプリートの誤操作によって悪意あるバリアントをインストールしてしまうよう仕向ける、パッケージエコシステムにおける従来からの悪用手口を踏襲しています。
今回のキャンペーンは、2026年に入ってからの大量公開攻撃を受けて登録が一時停止され、悪意あるパッケージの積極的な削除(yanking)が行われるなど、RubyGemsへの監視が強化されている最中に発覚しました。
セキュリティチームは、今回説明された命名パターンに一致する不審なgem、~/.bashrcやsystemdユーザーサービスの異常、予期しないSSH鍵へのアクセス、CPU使用率が約50%に調整されたXMRigプロセスなどがないか、直ちに環境を監査すべきです。
ベンダーやCERTが提供する既存のXMRig検知ガイダンスやcryptojacking対策のハンティングプレイブックは、そのまま適用可能です。特に、採掘プロセスの識別、プール通信のプロファイリング、永続化アーティファクトのクリーンアップに重点を置くべきです。
より深い技術的背景と、継続的なRubyGemsエコシステムの監視状況については、2026年5月のパッケージ氾濫とその後の方針変更に関する記録を含め、RubyGemsのサプライチェーン攻撃とレジストリレベルの対策に関する過去の分析を参照することができます。
2026年のAI SOCに求められる機能とは?完全チェックリスト : AI SOC機能チェックリストをダウンロード
翻訳元: https://gbhackers.com/136-malicious-rubygems-packages/
