Pluto Security、Hugging Face上でのLoad/Mine暗号資産マイニングキャンペーンの詳細を公表

Pluto Securityの調査チームは2026年10月29日、Load/Mineに関するレポートを公開し、悪意のあるHugging Faceのモデルリポジトリを通じて拡散された暗号資産マイニングおよびバックドアのキャンペーンを明らかにした。同レポートによると、Hugging Faceの7アカウントにまたがる悪意のあるリポジトリは31件で、ModelScope上のミラーも1件確認された。キャンペーンのダウンロード数は29,818件で、関連する13件のリポジトリを含めると32,376件に上る。Plutoは、この数値がダウンロード数を示すものであり、感染が確認された件数や被害者の実数を表すものではないとしている。

Shaked Chen、Eitan Chassid、Yotam Perkalが執筆した同レポートによると、キャンペーンは最初の削除措置から数日以内に再開した。第2波のリポジトリ19件は29,000回を超えるダウンロードを記録し、Plutoが報告してから8日後も公開されたままだった。レポートによれば、第1波の報酬受取用ウォレットには、オンチェーンでのマイニング収益として約2,276 PRL、約5,000ドルが入金された。

悪意のあるコードが実行される仕組み

このキャンペーンは、重みを改ざんするのではなく、文書化されているTransformersの読み込み動作を悪用している。次の指定を使ってリポジトリを読み込むと、 trust_remote_code=True リポジトリの config.json は、 auto_map 読み込むPythonモジュールとクラスを指定するために使われる。Transformersは参照先のファイルをモジュールキャッシュにダウンロードし、 exec_module() 呼び出しは、要求されたモデルクラスを返す前にファイルのトップレベルコードを実行する。レポートによると、これは文書化された動作であり、デフォルトの動作ではない。また、Transformersのセキュリティポリシーでは、この引数を使用する際にモデリングファイルの内容を確認するようユーザーに求めている。レポートはさらに、CVE-2026-22807にも言及している。この脆弱性では、vLLMのバージョン0.10.1から修正が適用された0.14.0までのバージョンが、 auto_map モジュールを trust_remote_code 設定を確認せずに読み込んでいたため、悪意のあるリポジトリがサーバー起動時にコードを実行できた。

発見の経緯とアカウント間の関連性

Plutoは、あらゆる .py によって参照されるファイルを対象とするスキャナーを構築した。 auto_map のほか、 config.jsonモデルの重みと同じ場所に置かれたPythonファイルも対象とし、 subprocess, socket, ctypes, memfd_create やbase64デコードなどのパターンを検出した。最初に見つかったのは dsxk4mr8tq/qwen2-tiny-gpt2で、そこには305行のファイル modeling_evil.pyが含まれていた。このアカウントでは、2026年10月12日に2.5時間以内に作成されたリポジトリが6件確認された。

帰属の手がかりとなったのはバックアップファイルだった。 qwen2-tiny-lite リポジトリには modeling_evil.py.bak-src と modeling_evil.py.bak-syncが含まれていた。これらは同じマルウェアの旧バージョンで、ダウンロードURLは使い捨てのアカウントではなく、 hhzz667 Hugging Face上の wssb123e とModelScope上のリポジトリを指していた。レポートによると、運用者は本番用コードをテストアカウントにコピーし、メインファイル内のURLを更新したものの、バックアップのURLを変更し忘れた。第1波では、2つのプラットフォームにまたがる3アカウントで計12件のリポジトリが確認された。削除前のダウンロード数は700回を超えていた一方、セキュリティフラグは一つも付いていなかった。

ペイロードの構成

代表的なビルドとして MENXIANGYU/qwen2-tiny を取り上げ、レポートはペイロードの動作について説明している。最初に書き込まれるのは /tmp/.cch/svc.pyで、マイナーが停止していると120秒ごとに再起動する監視プロセスも含まれる。起動フックは /root/.bashrc, /root/.profile とユーザーの .bashrcに追加される。3つのビルドには、ポート443または9443で212.32.253.3に接続し、切断のたびに再接続を試みるリバースシェルも含まれている。

マイナーのバイナリである syscore.binは、 memfd_create を通じて起動され、 fexecve カーネルワーカーに偽装されている。 kworker/u20:1初回起動時にはディスク上に実行ファイルのパスを残さず、フォールバック用のコピーは /tmp/.cch/syncに保存される。この40.6 MBのバイナリはUPXで圧縮され、2つの UPX! マーカーが PEK! に変更されているため、標準の展開ツールでは展開できない。Plutoはマーカーを元に戻して展開し、peakminerというマイナーを確認した。このマイナーは、プールの接続先とログイン情報 krxXJ2PKQW.workerを指定して起動される。進捗を示す受信記録は、ローカルのXinferenceモデルレジストリに qwen2-tiny- として書き込まれ、その後にbase32形式のステータスコードが続く。また、ペイロードは競合するマイナーの登録情報を削除し、該当するプロセスを終了させる。

削除後の2つの波と手口の変化

レポートは、第1波の発信元をアカウント hhzz667と特定している。このアカウントは2026年4月29日に作成され、5か月間活動がなかった。2026年9月21日、同アカウントは qwen2-shellを公開した。これは、 authorized_keys にed25519鍵を設置する37行のSSHバックドアで、Alibaba Cloudのサーバーにビーコンを送信するものだった。READMEは公式のQwen2.5-0.5Bモデルカードからコピーされていた。9月22日までに、運用者は qwen2-finalを投入した。これは、カーネルスレッドへの偽装、競合するマイナーを停止させる機能、そして Qwen2Configなどの無害に見える名前を使ったXinferenceのステータス報告機能を備える、305行のファイルレスマイナーだった。コードのコメントは簡体字中国語で書かれていた。

Plutoは最初の波についてHugging FaceとModelScopeに報告し、該当アカウントは削除された。数日以内に第2波が続き、5つのアカウントで19件のリポジトリが確認された。内訳には、13件のリポジトリを持つMENXIANGYUのほか、wjsbg、soumikmahato、r1r13、htt0118が含まれていた。最後のアカウントは2026年10月25日に作成された。あるリポジトリは、 MENXIANGYU/qa-whl-1021、Plutoの開示メールから8.5時間後に公開されたもので、コンテナからホストへの脱出スクリプトだった。ホストのディスクをマウントし、GPUStackの /var/lib/gpustack ディレクトリを標的にして、ホスト上でrootログインを可能にする。後続のドロッパーは、第2段階の実行を送信元IPアドレスで制限し、それ以外のリクエストには「static ip.」というテキストとともに403レスポンスを返す。代表的なリポジトリは MENXIANGYU/qwen2-tiny 10月20日のダウンロード数が7,354件だったのに対し、10月28日には28,412件に増加し、第2波のダウンロード数の97.7%を占めた。

マイニング収益と確認された被害者

第1波のウォレットは、716件の取引で約2,276 PRLを受け取り、約2,241 PRLを送金した。リポジトリが削除された後の10月21日時点でも、公開プールのダッシュボード上で稼働が確認されていた。Kryptexでは、ウォレットにオンラインのワーカーが2台表示され、報告されていたのは peakminer/2.16.5 約1,008 PRLで、取得時点の30日間の報酬は約2,237ドルだった。分析中、ノートパソコン風の名前を持つ9台のワーカーが互いに90秒以内に参加し、その約6分後にはシェアの送信を停止した。報告書は、この動きがGPUクラスターの共有利用と一致すると述べている。別途追跡された hl ファミリーは、インポート時に同様の処理を実行し、MoneroOceanのウォレットには13台のワーカーが表示され、約1か月でおよそ26ドルが支払われていた。

スキャナーの検出範囲にある抜け穴

第1波の12件のリポジトリはいずれもフラグが付けられておらず、第2波の代表的なペイロードも modeling_evil2.py Plutoの確認によると、実行されたすべてのスキャナーで「safe」と判定され、JFrogは機械学習モデルではないと報告した。Hugging Faceのマルウェアスキャンに関するドキュメントには、2 GB未満のリポジトリ内ファイルはすべて、コミットのたびにマルウェアスキャナーで検査されると記載されている。pickleスキャンに関するドキュメントによると、スキャナーはClamAVによるウイルススキャンとpickleのインポートスキャンを実行する。ただし、ClamAVはpickleのエクスプロイトを検出できず、スキャンは「100%確実ではない」ため、安全性の確認はユーザーの責任とされている。Plutoによると、 .py ファイルを指す、ある auto_map フラグが設定される前に参照されるファイルを確認していれば、キャンペーン内のすべてのペイロードを検出できたはずであり、アップロード時に静的検査を行って subprocess, socket, ctypes またはraw-IPへの呼び出しを auto_map参照するファイル内で検出していれば、より早く発見できたはずだという。

帰属の評価と推奨される対策

Plutoは、金銭目的の中国語話者の単独犯または小規模グループによるものと評価している。その根拠として、簡体字中国語のコメント、Alibaba Cloud上のコマンド＆コントロールサーバー、ModelScopeおよびhf-mirror.com上でのミラーリング、XinferenceとTencent Cloudの利用を前提とした標的設定、そして18:38から21:19 UTCにかけての活動の集中を挙げている。soumikmahatoの「parasit」ビルドにはインドネシア語のコメントが含まれている。報告書は、これは同じ分野で活動する別のオペレーター、あるいは意図的に異なる外観の系統を運用する同一のオペレーターのいずれとも整合するとしている。

報告書は、カスタムコードを有効にして掲載モデルを読み込んだ人に対し、ホスト上で次の項目を確認するよう勧めている。 /tmp/.cch/、予期しない svc.py プロセス、 kworker/u20:1 マイニング用の引数を伴うプロセス、エンコードされた qwen2-tiny- または ezv- Xinferenceの登録情報、ならびに記載されたサーバーやプールへの接続だ。Plutoは、影響を受けたマシンを隔離し、証拠を保全し、すべての永続化経路を取り除き、侵害された認証情報をクリーンなマシンから更新し、ホストの完全性を確認できない場合は信頼できるイメージから再構築し、Xinference APIに認証を必須とし、レビュー済みのモデルのリビジョンを固定するよう推奨している。Plutoは、この種のキャンペーンが今後も発生すると予想しており、追跡を続けているという。