暗号通貨マイニングマルウェアの検出方法｜出前館のRedTail感染に学ぶ侵入経路と駆除手順

サーバーのCPU使用率が張り付いたまま下がらず、心当たりのあるバッチも動いていない。暗号通貨マイニングマルウェアの感染では、この「負荷だけが上がる」症状が最初の、そしてしばしば唯一の兆候になります。2024年10月に出前館のサービスが2日連続で停止した事案でも、停止後の調査で暗号資産マイニングマルウェア「RedTail」の感染が見つかりました。この記事の内容は、Linuxサーバーとクラウド環境で感染を見抜く確認手順、RedTailが実際に悪用した脆弱性、そして復旧の正しい順序。すべて公式発表と解析レポートの一次情報に基づいています。

まとめ

• 検出の起点はCPU使用率ではなくプロセスと設定の痕跡です。実行ファイルが削除済みのプロセス、vm.nr_hugepages の非ゼロ値、msrカーネルモジュールの読み込みが、RandomXで採掘するマルウェアに特有のサインになります。
• RedTailはプライベートマイニングプールを使うため、既知のプールドメインやウォレットアドレスを照合するIoC型の検知は空振りします。挙動ベースの検知に切り替える必要があります。
• 侵入経路は主にインターネットに面した機器の既知脆弱性です。CVE-2024-3400（PAN-OS・CVSS 10.0）とCVE-2024-4577（PHP・CVSS 9.8）が代表で、後者は日本語ロケール（コードページ932）のWindowsが悪用条件に含まれます。
• 復旧作業の順序は侵入経路の特定と封鎖が先、駆除は後です。出前館は10月25日に高負荷のサーバーを切り離して再開しましたが、原因が判明しないまま翌26日に別のサーバーが高負荷になり、その停止後にRedTailの感染が発見されています。
• クラウドでは請求額がそのまま実害になります。Sysdigは2022年の調査で、攻撃者が約8,100ドル超を採掘した1件について、被害者側の請求が43万ドルを超えたと報告しました。

以下では、この5点の根拠と、実際に手元のサーバーで叩ける確認手順を順に見ていきます。

暗号通貨マイニングマルウェアの正体とサーバーが標的になる理由

ブラウザ常駐型とサーバー常駐型で異なる被害の重さ

暗号通貨マイニングマルウェア（クリプトジャッキング）は、他人の計算資源を無断で使って暗号通貨を採掘するマルウェアです。実装は2形態。Webページに埋め込まれたJavaScriptがタブを開いている間だけ採掘するブラウザ型と、サーバーにバイナリを常駐させcronで再起動後も動き続ける常駐型です。企業にとって深刻なのは後者。ブラウザ型はタブを閉じれば止まりますが、常駐型は24時間フルパワーでCPUを使い続けます。RedTailはこの常駐型で、採掘エンジンにオープンソースのXMRigを改変したものを使い、Moneroの採掘アルゴリズムRandomXを実装しています。RandomXはGPUではなくCPUで効率よく回るよう設計されているため、汎用サーバーの群れがそのまま採掘装置になってしまう、という関係です。

クラウド課金に跳ね返る被害額の非対称性

採掘で攻撃者が得る額そのものは、それほど大きくありません。問題は費用の負担者が違うこと。Sysdigが2022年9月28日に公開したプレスリリースは、この非対称性を「攻撃者が1ドル稼ぐごとに、被害者は53ドルを請求される（Attackers make $1 for every $53 a victim is billed.）」と表現しました。同社のクラウドネイティブ脅威レポートによれば、攻撃グループTeamTNTが盗んだ計算資源で採掘した額は8,100ドル超、被害者側に発生した請求は43万ドル超。53倍という比率はこの1件から導かれた数字で、母数や期間は示されていません。受け取るべきは、桁が2つ違うという事実のほうです。

オンプレミスなら電気代と機器の劣化で済むところが、従量課金のクラウドでは請求書に直撃します。オートスケーリングが有効なら、CPU使用率の上昇に反応してインスタンスが増え、増えた分だけ採掘も加速するという連鎖まで起こる。マイニングマルウェアを「情報が漏れないから軽微」と見誤ってはいけない理由がここにあります。

出前館の3日超の停止とRedTail発見の経緯

2024年10月29日18時30分に出前館が公開したプレスリリースは、障害の経緯をこう記しています。「10月25日（金）20時頃、サーバが高負荷となったことからサービスを停止し、当該サーバより切り離してサービスを再開いたしました。原因の調査を継続していたところ、翌10月26日（土）14時30分頃、前日とは異なるサーバが高負荷となり再度サービスを停止したのち、暗号資産マイニングマルウェアである通称「RedTail」に感染したことが発見され、当該マルウェアの削除を実施しました。」

読み落としてはいけないのが、25日の時点では原因が分かっていなかったという記述です。高負荷のサーバーを切り離すという対処は取ったものの、RedTailが見つかったのは翌26日に2度目の停止をした後でした。

停止時間も見ておきます。同リリースは冒頭で、10月26日14時30分頃からのサービス停止が「先ほど再開いたしました」と述べており、公開時刻は29日18時30分。2度目の停止だけで3日を超えました。データが盗まれたわけでも暗号化されたわけでもなく、CPUを奪われただけで大手フードデリバリーサービスが3日以上止まった、という事案です。なお個人情報の流出については、現時点でその恐れはないと明記されています。

感染を見抜く確認手順

CPUを占有するプロセスと自己削除バイナリの確認

最初に見るのは負荷そのものではなく、負荷を出しているプロセスの素性です。以下はLinux（procps系）での確認コマンドです。

# CPUを占有しているプロセスを負荷順に表示（ヘッダ1行＋上位10件）
ps -eo pid,ppid,user,pcpu,etimes,cmd --sort=-pcpu | head -11

# 実行ファイルが削除済みのプロセスを洗い出す（rootで実行）
ls -l /proc/*/exe 2>/dev/null | grep -F '(deleted)'

Linuxではプロセスの実行ファイルが削除されても、そのプロセスは動き続けます。このとき /proc/PID/exe のシンボリックリンクの先には、カーネルが付与する「 (deleted)」というサフィックスが残ります。2つ目のコマンドはこれを拾うものです。正規のサーバープロセスがこの状態になるのは、パッケージ更新後にデーモンを再起動していない場合くらい。それ以外で該当するプロセスが出てきたら、ディスク上から自分を消して痕跡を減らすタイプのマルウェアを疑ってください。

RedTailは .redtail というドット始まりの隠しファイル名で設置され、UPXで圧縮されています。ただしファイル名は変種ごとに変わるため、名前で探すより「削除済みバイナリで動いているプロセスがあるか」という条件で探すほうが確実です。

RandomXが残すHugePagesとMSRの設定痕跡

RandomXで採掘するソフトウェアは、ハッシュレートを稼ぐためにOSの設定を書き換えます。XMRigの公式ドキュメントは、HugePagesを使うとハッシュレートが20〜30％、RandomXでは最大50％向上すると説明し、RandomXではNUMAノードあたり1280ページ（2560MB）の確保を推奨しています。

# RandomX用に確保されたHugePages（多くのサーバーでは既定値0）
cat /proc/sys/vm/nr_hugepages

# msrレジスタへの書き込みが許可されているか（Linux 5.9以降）
cat /sys/module/msr/parameters/allow_writes

# モジュールとして読み込まれている場合はここにも現れる
lsmod | grep -w msr

もうひとつがMSR（モデル固有レジスタ）です。XMRigに同梱される randomx_boost.sh は、まず /sys/module/msr/parameters/allow_writes の有無を確かめ、無ければ modprobe msr allow_writes=on でモジュールを読み込みます。そのうえでIntel系はレジスタ0x1a4、AMD Zen系は0xc0011020・0xc0011021・0xc0011022・0xc001102bの4本に書き込み、ハードウェアプリフェッチャを無効化します。RandomXはメモリをランダムに参照するため、プリフェッチャがかえって足を引っ張るからです。

確認の順序にも意味があります。msrがカーネル組み込みのビルドでは lsmod に何も出ませんが、sysfs側のパラメータは存在するため、sysfsを先に見ないと取りこぼします。なお allow_writes はLinux 5.9で追加されたパラメータで、それ以前のカーネルにはファイル自体がありません。無い＝正常ではなく、この方法では判定できないという意味です。

データベースやJVMをチューニングしている環境なら、HugePagesの確保自体は正常です。しかし、そうした設定を入れた覚えがないサーバーで nr_hugepages が数百から数千になっていて、かつmsrへの書き込みが許可されていれば、採掘ソフトが設定を書き換えた跡と考えてまず間違いありません。限界も書いておきます。nr_hugepages は実行時の設定なので、再起動すると0に戻ります。この確認が効くのは感染したまま動き続けているホストに対してです。

cronによる常駐化と外部への常時接続

RedTailは再起動を生き延びるためにcronジョブを追加します。Forescoutの解析では、ユーザーのcrontab内にジョブを設定する形でした。

# ユーザーcrontabと配置型cronの確認
# crontabs付きはDebian系、無しはRHEL系。両方指定して存在する側だけ見る
crontab -l
ls -la /etc/cron.d/ /var/spool/cron/ /var/spool/cron/crontabs/ 2>/dev/null

# 確立済みの外向き接続をプロセス名つきで一覧
ss -tnp state established

採掘プロセスはマイニングプールと常時接続を保つため、ss の出力には長時間張り付いた外向きのTCPセッションが残ります。Akamaiが観測したRedTailの接続先は4つで、いずれもポート2137を使っていました。ただしポート番号も変種ごとに変わるので、番号を覚えるより「業務上の説明がつかない外向き常時接続がないか」を見てください。不正アクセスのログ確認・解析方法で扱っている痕跡調査の考え方が、そのまま応用できます。

Webサーバーログに残るlibredtail-httpの痕跡

感染していなくても、狙われている段階なら侵入試行がWebサーバーのアクセスログに残ります。RedTailのスキャナが名乗るUser-Agentは libredtail-http。SigmaHQには2026年4月30日付でこれを検知するルールが登録されており、ルールの説明は2024年後半から2026年初頭にかけての継続的なスキャンキャンペーンに紐づくものとしています。2024年の事案で終わった話ではありません。

# RedTailのスキャナが名乗るUser-Agent。まず件数を数える
grep -Fc 'libredtail-http' /var/log/nginx/access.log

# CVE-2024-4577の悪用試行に現れる文字列。該当行を目視する
grep -F 'cve_2024_4577' /var/log/nginx/access.log

2つ目の文字列にも根拠があります。SANS Internet Storm Centerが2026年4月29日に公開したハニーポットの観測記録では、CVE-2024-4577を悪用したペイロードが sh -s cve_2024_4577.selfrep という引数付きでシェルスクリプトを実行していました。同記録の筆者は自身のDShieldセンサー上で113個のIPアドレスがlibredtail-httpとして活動したと報告しています。この段階で検知できれば、感染する前に侵入経路を塞げます。

クラウド環境での検出とGuardDutyの検知タイプ

AWS環境では、Amazon GuardDutyが暗号通貨関連の通信を2種類の検知タイプで報告します。CryptoCurrency:EC2/BitcoinTool.B はEC2インスタンスが暗号通貨関連のIPアドレスへ問い合わせた場合、CryptoCurrency:EC2/BitcoinTool.B!DNS はドメイン名へ問い合わせた場合の検知です。未導入ならAmazon GuardDutyの概要と特徴から検討する価値があります。

ただし、この2つはどちらも「既知の暗号通貨関連の宛先」を照合する仕組み。次の章で述べるとおり、RedTailはその前提を意図的に崩しています。対策は同じ製品の中にあります。Runtime Monitoringを有効にすると Impact:Runtime/CryptoMinerExecuted が使えるようになり、これは宛先ではなく「採掘に関連するバイナリファイルを実行しているプロセス」を見る検知です。宛先照合と実行検知は別物なので、両方を有効にしてください。ワークロード側の保護をどう組むかはCWPPとCSPMの違いと導入判断で整理しています。

IoCベースの検知を無効化するプライベートマイニングプール

RedTailを他の採掘マルウェアと分ける最大の特徴が、プライベートマイニングプールの採用です。Akamaiの2024年5月30日の解析によれば、RedTailは公開プールを使わず、攻撃者自身が運用する4つのエンドポイントへ接続していました。しかもバイナリにウォレットアドレスを埋め込んでいません。

この設計が防御側に何をもたらすか、はっきり書きます。既知のマイニングプールのドメインやIPをブロックリストに入れる対策、およびウォレットアドレスを指標にした検知は、RedTailに対してはほぼ機能しません。 接続先は攻撃者が用意した無名のIPアドレスであり、脅威インテリジェンスのフィードに「マイニングプール」として載っていないからです。GuardDutyの2つの検知タイプが照合しているのも、まさにその「既知の暗号通貨関連の宛先」です。

公開プールを使えば運用コストはゼロで済むところを、あえて自前で4台立てる。Akamaiはこの選択を「採掘結果に対するより強い制御を、運用コストと金銭的コストの増加と引き換えに得るため」と説明し、Lazarusグループが使う手口と重なるとも指摘しています（帰属が確定したわけではありません）。

防御側の重心は、宛先の照合から挙動の観測へ移してください。前章で挙げたHugePagesとMSRの設定変更、削除済みバイナリの常駐、cronへの追記は、採掘という行為そのものに付随して必ず現れます。接続先を変えても消えない痕跡なので、IoCのリストを更新し続ける運用よりも費用対効果で勝ります。

RedTailの侵入経路になった脆弱性

RedTailはフィッシングメールで広がるタイプではありません。インターネットに面した機器やアプリケーションの既知脆弱性を自動的に突いて回ります。Akamaiは2024年5月30日の解析時点で6種類以上のWebエクスプロイトを確認しており、その後さらに増えました。

この表は抜粋です。AkamaiはほかにCVE番号のないThinkPHPのファイルインクルードと、実際の攻撃では未観測ながらバイナリに埋め込まれていたCVE-2017-9841（PHPUnit）にも触れています。最終行のCVE-2024-4577はAkamaiの解析より後に公開された脆弱性で、悪用の報告は2024年7月10日のForescoutによるものです。

CVE-2024-3400：PAN-OSのCVSS 10.0

2024年4月12日にNVDへ登録されたCVE-2024-3400は、CVSS v3.1で満点の10.0（AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H）が付いた脆弱性です。PAN-OSのGlobalProtect機能で任意のファイルを作成でき、結果としてファイアウォール上でroot権限のコード実行に至ります。認証もユーザー操作も不要。Akamaiによれば、RedTailはSESSIDクッキーにパストラバーサルを仕込み、作成するファイルの名前と保存先の両方を制御していました。

該当するのはPAN-OS 10.2系・11.0系・11.1系で、最終的な修正はそれぞれ10.2.9-h1、11.0.4-h1、11.1.2-h3です。ここは版番号だけを見て安心しないでください。Palo Alto Networksの公式アドバイザリは各マイナー版ごとにホットフィックスを指定しており、たとえば10.2.9であってもh1未満なら影響下に入ります。PAN-OS 10.1以前と、Cloud NGFW・Panorama・Prisma Accessは対象外です。

もうひとつ、曝露条件があります。公式アドバイザリは「この問題はGlobalProtectゲートウェイまたはGlobalProtectポータル（あるいはその両方）で構成されたファイアウォールにのみ該当する」と限定しました。逆に、その構成でありさえすればデバイステレメトリの有効化は不要で、無効にしていても攻撃を受けます。境界防御を担う機器そのものが侵入口になった点で、内部ネットワークだから安全という前提が崩れる種類の脆弱性でした。

CVE-2024-4577：日本語ロケールが悪用条件に入るPHPの脆弱性

日本の運用者が特に確認すべきなのがこちらです。発見者であるDEVCOREが2024年6月6日に公開した解説によると、CVE-2024-4577はWindows上で動作するすべてのバージョンのPHPが影響を受けます。原因はWindowsの文字コード変換におけるBest-Fit機能で、これを使うと以前修正された脆弱性の対策を迂回して引数インジェクションが成立します。

そして悪用可能と検証されたロケールが、繁体字中国語（コードページ950）、簡体字中国語（コードページ936）、そして日本語（コードページ932）の3つ。日本語環境のWindowsサーバーは、この脆弱性の直撃コースにあります。

該当範囲の読み違いにも注意してください。DEVCOREは「PHPがCGIモードで構成されていなくても、CGIディレクトリにPHPの実行ファイルを置いているだけで影響を受ける」と明記しており、Windows版XAMPPは全バージョンが既定の状態で脆弱だとしています。CGI運用の自覚がなくても対象になり得ます。また英語や韓国語など他のロケールについても、PHPの利用シナリオが広いため悪用の可能性を完全に排除することはできない、というのが同社の立場です。安全と読み替えないでください。

修正版はPHP 8.3.8、8.2.20、8.1.29以降です。PHP 8.0系以前はサポートが終了しており修正が提供されないため、該当する環境は8.1以降への移行が必要になります。Forescoutは2024年7月10日の解析でこの脆弱性を突いて新しいRedTailが配布されていることを報告しており、前述のSANS ISCの観測でも2026年時点で悪用が続いています。

IoT機器と旧世代フレームワークという放置されやすい経路

残りの脆弱性に共通するのは、パッチ適用の対象から漏れやすい場所だという点です。TP-Linkの家庭用ルーター、IvantiのSSL-VPN、そして2018年公開のThinkPHPのリモートコード実行。CVE-2018-20062はAkamaiの解析時点で6年前の脆弱性でした。それがまだ攻撃対象として有効な以上、パッチの当たっていない機器が実際に稼働し続けていることになります。

SANS ISCの観測では、RedTailは侵入に成功するとシステムのアーキテクチャを判別し、書き込み可能なディレクトリを探し、他の採掘マルウェアのcronジョブを探して停止させてから自分を設置します。競合を排除する動作が組み込まれている＝同じ脆弱性を複数の攻撃グループが日常的に突いている前提で作られている、ということです。なおライブラリ側から入り込む経路もあり、パッケージ経由の侵入はaxiosへのマルウェア混入とサプライチェーン攻撃の対処法で扱っています。

駆除とシステム復旧の手順

隔離から駆除・復旧確認までの流れ

感染が確認された場合の手順は次のとおりです。

1. 該当ホストをネットワークから隔離する。クラウドならセキュリティグループの通信を落とす。プロセスをいきなりkillせず、稼働中のプロセス一覧、/proc配下のリンク先、確立済み接続、cron内容を先に保全する。
2. 常駐化の仕掛けを外す。crontab、/etc/cron.d/、systemdユニット、シェルの初期化ファイルを確認し、追加されたエントリを削除する。
3. 採掘プロセスを停止し、バイナリを削除する。あわせて vm.nr_hugepages とmsrモジュールの設定を元に戻す。
4. 侵入経路になった脆弱性を特定し、パッチを適用する。ここを飛ばさない。
5. 認証情報を洗い替える。root権限を取られている以上、そのホストに置かれていた鍵やトークンは漏洩したものとして扱う。
6. 復旧後、CPU使用率と外向き接続を数日間監視して再発がないことを確認する。

迷ったら、隔離したホストは復旧させず作り直すほうが安全です。root権限で任意コードを実行された環境に対して、何が変更されていないかを証明するのは現実的ではありません。

侵入経路を特定しないまま復旧した場合の再発リスク

手順4を最後に回してはいけない理由は、単純です。感染したホストを取り除くことと、感染した経路を塞ぐことは別の作業だから。前者だけでは、同じ経路から次のホストがやられます。出前館の事例でも、25日は原因が判明しないまま高負荷のサーバーを切り離して再開し、翌26日には別のサーバーが同じ症状を示しました。切り離しは事象を止めませんでした。

実務上の優先順位をはっきり書きます。インターネットに面した機器のパッチ適用が最優先で、エンドポイント対策製品の導入はその次です。 RedTailが使う侵入経路はすべて既知脆弱性であり、いずれも修正版が公開済み。VPN装置やファイアウォール、Webサーバーのバージョンを棚卸ししていない状態でEDRだけを増やすのは、順序を間違えています。何が公開されていて何にパッチが当たっていないかの把握には、Amazon Inspectorの対応スキャンと導入判断のような継続的なスキャンの仕組みが要ります。

一方で、パッチ適用が終わったからといって監視を省くのは危険です。ゼロデイの段階で悪用されたCVE-2024-3400のようなケースでは、パッチが存在しない期間に侵入されます。この期間を埋めるのが挙動ベースの検知です。順序は「パッチ適用が先、監視が後」ですが、後を切ってよいという意味ではありません。

よくある質問

マイニングマルウェアに感染するとどうなりますか？

CPUが常時占有され、サーバーの応答が遅くなります。処理能力を使い切ればサービスそのものが停止し、出前館の事案では3日を超える停止に至りました。クラウドでは従量課金の請求額が跳ね上がるという別の実害も出ます。データの暗号化や窃取を伴わないため被害が軽く見えがちですが、可用性とコストの両面で損失が発生する、というのが実態です。さらにroot権限を取られている以上、そのホストの認証情報は漏洩したものとして扱ってください。

CPU使用率が高いだけでマイニングマルウェアと判断できますか？

判断できません。バッチ処理やメモリリークでも同じ症状が出ます。負荷の大きさではなく、負荷を出しているプロセスの素性を見てください。本文の「感染を見抜く確認手順」で挙げた4点、すなわち実行ファイルが削除済みのプロセス、身に覚えのない nr_hugepages、msrへの書き込み許可、説明のつかない外向き常時接続のうち複数が該当すれば、採掘ソフトの可能性が高くなります。

ウイルス対策ソフトを入れていれば検出できますか？

確実ではありません。RedTailはUPXで圧縮されているうえ、GDBによるデバッグを検出すると自身を終了させ、設定を暗号化して保持し、複数回のプロセスforkで解析を妨げます。パターンマッチ型の検出だけに頼るのは危険だと考えてください。プロセスの挙動と設定変更を見る仕組みを併用するのが現実的な解です。

Windowsサーバーも対象になりますか？

なります。RedTailが悪用するCVE-2024-4577は、Windows上で動作するPHPを対象とした脆弱性で、日本語ロケール（コードページ932）が悪用条件に含まれます。CGIモードで構成していなくても、CGIディレクトリにPHPの実行ファイルを置いていれば該当。PHP 8.3.8、8.2.20、8.1.29以降への更新を確認してください。

感染したら個人情報は漏れますか？

採掘そのものはデータを読み出す動作ではありません。出前館も2024年10月29日の発表で、現時点において個人情報の流出の恐れはないとしています。ただし、侵入時にroot権限を取得されている点は変わりません。同じ経路から情報窃取型のマルウェアを送り込むことも技術的には可能なため、採掘の痕跡しか見つからなかった場合でも、アクセスログの精査と認証情報の洗い替えは実施してください。

関連記事

• Amazon GuardDutyとは？AWS環境の脅威検出サービスの基本的な概要と特徴を初心者向けに解説
• 不正アクセスのログ確認・解析方法｜見るべきログと攻撃痕跡の調べ方を実践解説
• CWPPとは？ワークロード保護の仕組みとCSPMとの違い・導入判断を実装視点で解説
• Amazon Inspectorとは？対応スキャンと料金・Classic終了後の導入判断
• axiosにマルウェア混入｜サプライチェーン攻撃の全容と感染確認・安全な対処法