コンテナ・Kubernetes環境を狙う「クリプトジャック（暗号資産不正採掘）」

背景と概要

DockerやKubernetesに代表されるコンテナ技術は、クラウドネイティブなアプリ開発の標準となりました。しかし、設定不備のあるコンテナ環境を占拠し、その膨大な計算リソースを無断で使って暗号資産のマイニング（採掘）を行う「クリプトジャック（Cryptojacking）」の被害が続いています。

直ちに重大なデータ漏えいに繋がらないように見えますが、高額なクラウド利用料の請求や、システムの応答遅延といった実害を引き起こします。

コンテナ環境が狙われる理由と侵入ルート

コンテナ環境はリソースの増減が容易であり、攻撃者にとって格好のターゲットです。

1. 未認証のKubernetes APIやDocker Daemonの露出

　インターネット上に誤って管理者権限のAPIポートが公開されている場合、攻撃者は簡単に自前のマイニング用コンテナを起動・配置（デプロイ）できます。

2. パブリックリポジトリからの悪質な基本イメージ取得

　Docker Hubなどで提供されている非公式なコンテナイメージに、あらかじめマイニングプログラムが仕込まれているケースがあります。

3. 潜伏による発見の遅れ

　CPU使用率を意図的に50〜70%程度に抑えることで、システム管理者の監視アラートに引っかからないようステルス動作します。

コンテナセキュリティにおける防衛策

コンテナライフサイクル全体でのセキュリティ（CWPP等）が必要です。

1. コンテナイメージの署名と脆弱性スキャン

　信頼できるプライベートレジストリのみを利用し、デプロイ前にイメージ内の脆弱性やマルウェアを自動チェックします。

2. 最小権限原則とポッドセキュリティの適用

　コンテナをRoot権限で実行させない設定（Non-root設定）や、不要な権限の削除を徹底します。

3. 異常なリソース消費と外部通信の監視

　既知のマイニングプール（Monero等）へのアウトバウンド通信や、予期せぬコンテナの起動を検知・自動遮断するツールを導入します。

実務で深掘りしたい確認点

クラスタ権限、コンテナイメージ、ワーカーノード、クラウド請求をひとまとまりの管理対象として捉えます。CPU急増、未知イメージ、特権Pod、外部マイニングプール通信を検知します。 単発の警告だけで判断せず、利用者・端末・時刻・変更履歴を関連付けると、通常業務との違いを説明しやすくなります。

発見時の初動と影響確認

Podを削除する前に設定とログを保全し、侵入口となった権限・イメージ・秘密情報を更新します。 復旧を急ぐ場合も、後から原因と影響範囲を説明できるよう、時刻、担当者、実施した操作、保全した証拠を残します。外部への通知や専門家への相談が必要かも、扱うデータと業務影響から判断します。

継続運用へ落とし込む方法

リソース上限、署名済みイメージ、Admission制御、最小権限RBACを標準化します。 導入時だけで終わらせず、例外件数、検知から対応までの時間、再発、利用者からの相談を定期的に確認します。訓練や実際の対応で見つかった手順の曖昧さを更新し、責任者不在時にも動ける状態を維持します。