
クラウド上の設定不備や公開された管理画面を足がかりに、攻撃者が“次の攻撃に使う基盤”を大量に構築するキャンペーンが報告されています。
DockerやKubernetesなど、運用上の露出ポイントを連鎖的に突き、プロキシやスキャナー基盤を拡大させる流れが特徴です。
クラウド利用企業が「自社は標的ではない」と考えていても、悪用される側(踏み台)になり得る点に注意が必要です。
The Hacker News:TeamPCP Worm Exploits Cloud Infrastructure to Build Criminal Infrastructure
この記事のポイント
影響のあるシステム
- インターネットから到達可能なDocker API(設定不備として言及)
- Kubernetesクラスタ/Kubernetes API(設定不備・侵入経路として言及)
- Ray dashboards(公開・設定不備の侵入経路として言及)
- Redisサーバー(侵入経路として言及)
- React/Next.jsアプリケーション(侵入経路として言及)
- React2Shell:CVE-2025-55182(CVSS 10.0)を含む脆弱性の影響を受ける環境(侵入経路として言及)
- AWSおよびMicrosoft Azure環境(主な標的として言及)
推奨される対策
- Docker API、Kubernetes API、Ray dashboards、Redisなどの管理系コンポーネントが外部公開されていないかを直ちに点検し、不要な公開を停止する
- 脆弱性が言及されているReact/Next.js関連コンポーネントについて、影響確認と更新(パッチ適用)を優先する
- Kubernetes環境では、権限の強いPodの不審な作成や、Pod内へのスクリプト投下(横展開)を想定し、監査ログと検知ルールを強化する
- 不審なプロキシ/トンネリング動作、外部C2中継、暗号資産マイニングなど“踏み台化”の兆候を監視し、異常時に遮断できる運用を整える
上記の対策は、元記事の事実に基づき日本の読者向けに整理したものです。
この記事に出てくる専門用語
- TeamPCP:クラウドネイティブ環境を狙うサイバー犯罪活動の脅威クラスターとして報告された名称です(別名としてDeadCatx3、PCPcat、PersyPCP、ShellForceが言及)。
- ワーム型(worm-driven):侵入後に次の標的を探索して拡散する挙動を指す表現です。
- Docker API / Kubernetes API:コンテナ運用・管理のためのAPIで、設定不備や露出があると侵入経路になり得ます。
- Ray dashboard:分散処理基盤Rayの管理・可視化機能で、外部公開されると悪用される可能性があります。
- Redis:インメモリ型データストアで、設定不備があると不正アクセスの起点になり得ます。
- CVE / CVSS:脆弱性識別子(CVE)と深刻度評価(CVSS)を示す枠組みです。
- C2(Command and Control):攻撃者が侵害端末・サーバーを遠隔操作するための通信基盤です。
- Sliver:オープンソースのC2フレームワークで、侵害後の操作に悪用されることがあるとされています。
クラウド運用の“露出”が攻撃基盤に転用されるシナリオ
研究者は、クラウドネイティブ環境を系統的に狙い、後続の悪用に使う不正インフラを構築する「大規模キャンペーン」に注意を促しています。
この活動は2025年12月25日ごろに観測され、「ワーム型」と表現されています。
侵入の入口として挙げられているのは、外部から到達可能なDocker API、Kubernetesクラスタ、Rayのダッシュボード、Redisサーバー、そして“最近公表された”React2Shell(CVE-2025-55182、CVSS 10.0)です。
これらの露出や脆弱性があると、攻撃者にとっては「踏み台を増やすための入口」になり得ます。
報告では、目的が特定業界の破壊ではなく、分散プロキシとスキャン基盤を大規模に作り、その後にデータ窃取、ランサムウェア展開、恐喝、暗号資産マイニングへ繋げる点が強調されています。
侵入と拡散の仕組み:proxy.shとPython系ペイロードが担う自動化

TeamPCP(別名:DeadCatx3、PCPcat、PersyPCP、ShellForce)は、目新しい高度手口よりも、既存ツールや既知の脆弱性、そしてよくある設定不備を組み合わせ、プロセス全体を自動化・工業化することで規模を出していると説明されています。
侵害に成功すると、外部サーバーから次段のペイロードが投入され、シェルやPythonベースのスクリプトが新たな標的を探して拡大する流れです。
中核コンポーネントとして挙げられている「proxy.sh」は、プロキシ、P2P、トンネリングのユーティリティを導入し、さらにスキャナー群を配布して、脆弱・設定不備のサーバーを継続的に探索するとされています。
加えて、proxy.shは実行時に環境の“指紋採取”を行い、Kubernetes内で動いているかを判定し、検出した場合はクラスタ向けの二次ペイロードへ分岐する、と報告されています。
クラウドネイティブ標的に合わせた道具立てが用意されている点が特徴です。
国内クラウド運用で直ちに点検すべきポイント:Kubernetesの永続化と“踏み台化”の兆候
報告では、複数のペイロードが役割分担していることが具体的に示されています。
例えばscanner.pyは、GitHub上の「DeadCatx3」アカウントからCIDRリストを取得し、設定不備のDocker APIやRayダッシュボードを探索するとされ、暗号資産マイナー(mine.sh)実行の選択肢もあると説明されています。
kube.pyはKubernetes特有の機能として、クラスタの認証情報収集やAPI経由のリソース探索(PodやNamespaceなど)を行い、アクセス可能なPodへproxy.shを投下して拡散を狙うほか、各ノードでホストをマウントする特権Podを展開して永続的バックドアを設置する、と報告されています。
react.pyはReactの脆弱性(CVE-2025-29927)を大規模に悪用する設計として触れられ、pcpcat.pyは広いIP帯で露出したDocker APIやRayダッシュボードを探索し、Base64でエンコードされたペイロードを実行する悪性コンテナ/ジョブを自動展開するとされています。
攻撃はAWSやMicrosoft Azureを主に狙い、特定業種ではなく“目的達成に資するインフラ”を機会的に狙うため、運用者が意図せず「巻き込まれる被害者」になる点が警戒ポイントです。
日本の組織としては、管理系インターフェースの外部露出、Kubernetes上の不審な特権Pod、プロキシ/トンネリング/C2中継の兆候を最優先で洗い出し、遮断と監視強化を同時に進めることが現実的です。





