英語版で読む
技術 約7分で読めます

PCPJack Credential Stealerが5件のCVEでクラウド認証情報を盗む

セキュリティ クラウド マルウェア CVE TeamPCP
いけさん目次

TL;DR

影響 Docker、Kubernetes、Redis、MongoDB、RayML、公開Webアプリを外部または内部ネットワークに露出しているクラウド環境

対応 該当CVEのパッチ、Docker APIとKubernetes APIの認証確認、IMDS（インスタンスメタデータサービス）v2強制、.env・SSH鍵・クラウドキーのローテーション

痕跡 /var/lib/.spm、harvest.jsonl、sys-monitor.service、cdn[.]cloudfront-js[.]com、spm-cdn-assets-dist-2026[.]s3[.]us-east-2[.]amazonaws[.]com

SentinelOneが、クラウド環境を横断して認証情報を盗むPCPJackというフレームワークを公開した。
単発の脆弱性悪用ではなく、侵害したホストから次のホストへ広がり、Docker・Kubernetes・Redis・MongoDB・RayMLまで見に行く構成になっている。

The Hacker Newsの記事では「5件のCVEを悪用してワームのように広がる」と紹介されていたが、原典のSentinelOneレポートを読むと、むしろ気持ち悪いのはCVEの数ではない。
TeamPCP系の痕跡を先に消し、.env、SSH鍵、クラウドメタデータ、Kubernetes Secret、Docker Secretをまとめて吸い上げる「既に荒らされたクラウド環境の乗っ取り直し」みたいな動きになっている。

TeamPCPの置き換えから始まる

PCPJackの入口は bootstrap.sh だ。
Linux上で作業ディレクトリ /var/lib/.spm/ を作り、Pythonと依存ライブラリを入れ、S3上の攻撃者管理リソースから6つのPythonモジュールを落とす。

ここまではクラウド系マルウェアとして普通に見える。
違うのは、最初にTeamPCPやPCPCatに関連するプロセス、ファイル、サービス、コンテナを探して削除するところだ。
SentinelOneは、侵害済みホストからTeamPCPを追い出せたかどうかを PCP replaced というフィールドでC2（攻撃者の指令サーバー）に送っていたと書いている。

この流れは、3月に書いたTeamPCPによるLiteLLM PyPI汚染やtelnyx Python SDKのWAVステガノグラフィ汚染とは性質が違う。
あちらはCI/CDやパッケージ配布経路を踏み台にして、開発者環境やAIアプリのAPIキーを盗むサプライチェーン攻撃だった。
PCPJackは配布経路よりも、既にインターネットや内部ネットワークに出ているクラウド管理面を直接叩く。

帰属は確定していない。
SentinelOneも「TeamPCPの元メンバーか、少なくとも手口をよく知る人物」の可能性にとどめている。
ただ、TeamPCPのマイナー機能を消し、暗号通貨マイナーを置かず、認証情報だけに寄せている点は、同じ市場で足場を奪い合っている感じがある。

盗む対象がクラウド運用そのもの

PCPJackの monitor.py はメインのオーケストレーターで、ローカル認証情報の収集、追加モジュールの起動、外部への伝播を担当する。
収集対象は .env、設定ファイル、環境変数、SSH秘密鍵、AWS IMDS認証情報、Kubernetesサービスアカウントトークン、Docker Secret、暗号通貨ウォレットなど。

もう1つの check.sh 系ツールセットでは、Sliverビーコン（攻撃者が遠隔操作に使うインプラント）を落としつつ、Anthropic、DigitalOcean、Discord、Google API、Grafana Cloud、HashiCorp Vault、OnePassword、OpenAIのキーまで探す。
AIアプリや社内ツールの実装で、環境変数にLLM APIキーを置いている構成にはそのまま刺さる。

graph TD
    A[公開Webアプリや<br/>露出サービスを侵害] --> B[bootstrap.shが<br/>/var/lib/.spmを作成]
    B --> C[TeamPCP系の<br/>痕跡を削除]
    C --> D[monitor.pyと<br/>補助モジュールを展開]
    D --> E[.env・SSH鍵・<br/>クラウド認証情報を収集]
    E --> F[Docker・Kubernetes・Redis・<br/>RayML・MongoDBへ横展開]
    F --> G[Telegramや外部サーバーへ<br/>窃取データを送信]

以前のReact2Shell悪用キャンペーンでも、Next.jsホストからDBクレデンシャル、SSHキー、AWS・Stripe・GitHubトークンがまとめて盗まれていた。
PCPJackはその延長にあるが、対象がNext.jsだけに閉じていない。
WebアプリのCVE、公開Docker API、Kubernetesサービスアカウント、Redis cron rewrite、RayMLジョブ投入を同じフレームワークに詰めている。

使われる5件のCVE

外部伝播では、Common Crawlのparquetデータからホスト名を引き、複数ノードで分担してスキャンする。
中央のターゲットリストを持たず、各感染ノードがWeb上の候補を拾いながら動く形だ。

SentinelOneが挙げているCVEは以下。

CVE対象内容
CVE-2025-29927Next.jsMiddleware認証バイパス
CVE-2025-55182React / Next.jsServer Actionsのデシリアライゼーション問題、React2Shell
CVE-2026-1357WPVivid Backup認証なしファイルアップロード
CVE-2025-9501W3 Total Cachecached mfunc comment経由のPHP injection
CVE-2025-48703CentOS Web PanelFilemanager changePermのshell injection

この一覧だけ見ると、Webアプリの既知脆弱性を並べた話に見える。
ただ、PCPJackでは初期侵害の後が本体だ。
アプリコンテナに入ったあと、Docker socket、Kubernetes API、Redis、MongoDB、RayML、SSHの順に「そこから見える管理面」を探す。

Kubernetesではサービスアカウントトークンを使ってAPIに接続し、namespaceやpodを列挙する。
SecretとConfigMapを読み、base64デコードして中身を取る。
RBACでpod execを拒否していても、Secret読み取り権限が残っていれば認証情報は持っていかれる。

Dockerでは /var/run/docker.sock と2375/2376番ポートを見る。
管理APIに接続できると、コンテナを列挙し、root filesystemをbind mountしてホスト側へ触りに行く。
「Dockerがローカルで動いているだけ」ではなく、socketやTCP APIをどの境界に置いているかが問題になる。

Redisでは KEYS と GET でトークンらしき値を拾い、cron rewriteで5分ごとの再感染を狙う。
RayMLでは8265番ポートにジョブを投げ、MongoDBでは27017番ポートからDB内の認証情報を削る。
外部公開だけでなく、侵害済みホストから見える内部ネットワークも対象だ。

クリプトマイナーを置かないクラウドマルウェア

クラウドを狙うマルウェアは、侵害したCPUでXMRigを回すパターンが多かった。
PCPJackはそこを捨てている。
TeamPCP由来のマイナー機能を消し、暗号通貨ウォレットや取引所の認証情報は狙うが、計算資源そのものの悪用には寄せていない。

この違いは運用側の見落としにつながる。
CPU使用率の急増やマイニングプールへの通信だけを見ていると、PCPJackの中心部分を取り逃がす。
確認するログは、S3や cdn[.]cloudfront-js[.]com へのアウトバウンド、Telegram Bot APIへの通信、Kubernetes APIへの不自然なSecret列挙、Docker APIのコンテナ作成、Redis設定書き換え、RayMLジョブ投入になる。

開発用のAIワークロードも巻き込まれる。
Marimoの未認証RCEの記事で書いたように、公開されたnotebookやdevツールは、.env とクラウドキーを同じ場所に置きがちだ（MarimoのCVSS 9.3 pre-auth RCEとAstralが公開したuvサプライチェーン防御）。
PCPJackはその散らばった鍵をまとめて探す。

すでに入られた前提で見る場所

SentinelOneのIOC（侵害の痕跡）では、ファイルシステム上の /var/lib/.spm、/tmp/.origin、harvest.jsonl、systemdの sys-monitor.service が挙がっている。
外向き通信では spm-cdn-assets-dist-2026[.]s3[.]us-east-2[.]amazonaws[.]com、cdn[.]cloudfront-js[.]com、lastpass-login-help[.]com が出てくる。

ホスト単体の削除だけで終わらせると危ない。
PCPJackが触る認証情報は、ホストの外に権限を伸ばすものばかりだ。
.env に入っていたDBパスワード、SSH鍵、AWSアクセスキー、Kubernetesサービスアカウント、Dockerレジストリ認証情報、OpenAIやAnthropicのAPIキーは侵害済みとして扱う。

AWSではIMDSv2を強制し、IMDSv1で一時認証情報を取られない状態にする。
Kubernetesではpod内のservice account token自動マウントを必要なものに限定し、Secret読み取り権限を広く持たせない。
DockerはTCP APIを公開しない。必要があるならTLSクライアント証明書で認証する。
RedisやMongoDBは内部ネットワーク内でも認証なしにしない。

PCPJack固有のCVE対応だけでなく、露出した管理面と長命の認証情報を潰す話になる。
CI/CD側の長命トークンを消す文脈では、Astralの記事で触れたTrusted PublishingやOIDCが効く。
実行環境側では、Secret ManagerやVaultに寄せ、アプリのファイルシステムに平文の鍵を残さない構成にする。

参考