Microsoftは、Storm-3068によるものとされるクラウド標的型の侵入事案について詳細を公表しました。攻撃者は乗っ取ったユーザーアカウントを足がかりにAzure DevOpsを悪用し、Kubernetesの認証情報を窃取しました。さらに、接続先のクラウド環境へアクセスされた可能性もあります。
この攻撃は、開発プラットフォームに広範な権限が付与されている場合、ID侵害がソフトウェアサプライチェーンや本番インフラのインシデントへ急速に発展しうることを示しています。
侵入の発端は、セルフサービスのパスワードリセット手続きの悪用に成功したことでした。
Storm-3068は標的アカウントを掌握した後、攻撃者が管理する認証方式を登録し、正規の多要素認証（MFA）方式を削除して、永続的なアクセスを確保しました。
その後は、マルウェアのエクスプロイトや従来型のエンドポイント経由の攻撃チェーンには頼らず、有効な認証情報と正規のクラウド管理機能を使って活動しました。
攻撃の要となったのがAzure DevOpsです。攻撃者は乗っ取ったアカウントを使い、リポジトリ、プロジェクト、デプロイ環境、パイプライン、サービス間の関係を列挙しました。
この情報収集により、攻撃者は組織の開発・クラウド運用の全体像を把握しました。信頼されたデプロイ経路や接続先インフラも含まれます。
現代のDevOps環境では、リポジトリやパイプライン設定からソースコード以上の情報が漏れる可能性があります。サービス接続、シークレット管理のワークフロー、クラウドリソース、デプロイ用IDなどが明らかになりかねません。
悪意あるパイプラインの1つは、50を超えるリソースへのアクセスを許可されていました。
その主な目的は、Kubernetesのkubeconfigファイルの取得でした。このファイルには、Kubernetes APIサーバーのエンドポイント、クラスター識別子、認証局データ、名前空間、ユーザーコンテキスト、サービスアカウントの認証情報が含まれる場合があります。
インシデントレスポンス計画
攻撃者は、パイプライン経由でサードパーティ製スクリプトをダウンロードして実行し、kubeagentを展開しました。
続いて、DUMPCLUSTERNAMEというパターンで複数のジョブを作成し、kubeconfigの内容を抽出してファイルをローカルに保存しました。
Storm-3068によるAzureの乗っ取り
Microsoftのインシデントレスポンス調査によると、Storm-3068は乗っ取ったアカウントに紐づく管理者権限を使い、Azure DevOpsのパイプラインを作成・削除していました。
窃取したファイルは、標的リポジトリ内にある既存のkubeconfigsディレクトリにコミットされました。これにより、攻撃者の活動は通常のDevOpsワークフローに紛れ込みました。
この手順は重大な権限昇格にあたります。kubeconfigファイルがあれば、Azure DevOpsを介さずにKubernetesクラスターへ直接アクセスできる可能性があるためです。
Storm-3068はさらに、パイプラインを改変してリモート管理エージェントのAteraとトンネリングツールのChiselを展開しました。Ateraはリモート管理機能を提供します。Chiselは、Kubernetes APIのトラフィックをプロキシしたり、攻撃者管理下のインフラへリバーストンネルを確立したりできます。
これらのツールを組み合わせれば、攻撃者はアクセスを維持し、侵害した環境と通信できます。信頼されたパイプラインの実行経路を通じて、Kubernetesのコントロールプレーンサービスにも到達できた可能性があります。
この事案は、クラウドネイティブな組織が直面する、より広範なセキュリティ課題を浮き彫りにしています。CI/CDシステムは、IDプロバイダー、ソースリポジトリ、シークレット、クラウドサブスクリプション、Kubernetesクラスター、本番ワークロードをつなぐ存在になりつつあります。
そのため、過剰な権限を持つ開発者や管理者のアカウントは、価値の高い標的になりえます。
今回のケースでは、1つのID侵害をきっかけに、攻撃者は数時間のうちに次の段階へ進みました。パスワードリセットの悪用から、IDの永続的な掌握、Azure DevOpsの偵察、パイプラインの改変、Kubernetes認証情報の収集、クラウド環境の探索へと展開しています。
防御側は、セルフサービスのパスワードリセットの異常な動きを監視する必要があります。特に、単一のIPアドレスからの繰り返しのリセット試行や、短時間に複数のユーザーを狙った試行に注意が必要です。
特権アカウントはフィッシング耐性のあるMFAで保護し、セルフサービスのパスワードリセットを許可することが適切かどうかも見直すべきです。
あわせて、ブランチ保護の適用、プルリクエストの承認必須化、重要ブランチへの直接コミットの制限を行い、ビルド／デプロイパイプラインを作成・変更・実行できる人を限定することも求められます。
とりわけ重要なのは、パイプラインのIDとサービス接続に最小権限の原則を適用することです。
Kubernetesの認証情報は、パイプラインが広く取得できないようにし、可能な限り有効期間を短くする必要があります。パイプラインの侵害が疑われる場合は、直ちにローテーションしてください。
調査では、Azure DevOpsの監査ログ、Gitの履歴、パイプラインの実行記録、MFA登録イベント、Intuneのデバイス登録テレメトリ、Kubernetes APIの監査ログを突き合わせて分析する必要があります。
Storm-3068の攻撃は、信頼されたDevOps自動化が攻撃者にとって最も効果的なアクセス手段になりうることを裏付けています。
CI/CDパイプラインの保護には今後、特権ID管理や本番インフラに従来適用されてきたものと同等の厳格さが求められます。
SOCのアラート調査を1件あたり21分短縮。即座にIOCのコンテキストを得て、迅速な対応を実現します。 SOCにTI Lookupを導入する
翻訳元: https://gbhackers.com/storm-3068-hijacks-azure/
