Microsoftは、マルウェアの使用や脆弱性の悪用がなくても、1つのIDの侵害が開発環境やクラウド環境内で広範なアクセス経路へと変化し得ることを明らかにした。Cyberattack Seriesの新たな報告書で、Microsoft Detection and Response Team（DART）は、Storm-3068が侵害されたアカウントからAzure DevOps、開発パイプライン、Kubernetesリソースへと移動した経緯を記録した。
侵入はセルフサービスによるパスワードリセットの手続きから始まった。ユーザーアカウントへのアクセスを得た後、攻撃者は自身の認証手段を登録し、IDへの継続的なアクセスを確保した。その後、正規の管理ツールと自動化スクリプトを使い、Azure DevOps内のリポジトリ、プロジェクト、パイプライン、デプロイ環境を棚卸しした。
IDからデプロイ経路へ
Azure DevOpsは、ID、ソフトウェア開発、クラウド運用を結び付けるため、価値の高い地点となっていた。デプロイ経路と関連リソースの構成を把握することで、Storm-3068は環境の他の部分へ移動する方法を特定した。
調査担当者は、Kubernetesの認証情報を大規模に収集するよう設計された悪意のあるパイプラインを発見した。このパイプラインはKubernetesエージェントをデプロイし、複数のタスクを実行して、クラスターへの接続情報と認証データを含むkubeconfigファイルを収集した。侵害されたアカウントの権限により、このパイプラインは50を超えるリソースへのアクセスと、さまざまなサービスへの認証を許可されていた。
また、パイプラインのスクリプトは、リモート管理エージェントAteraをインストールし、トンネル作成ツールChiselをダウンロードするよう変更された。Chiselのコマンドは外部IPアドレスへのリバーストンネルの作成に使われ、Kubernetesクラスターとリモートでやり取りできる可能性を生み出した。調査チームは、Azure DevOpsの監査ログとGitのバージョン履歴に基づき、攻撃の次の段階を再構成した。そこでは、盗まれた7つのkubeconfigファイルがリポジトリに追加されていた。
この事例は防御側に何を示すのか？
このインシデントの重要性は、最初の侵害地点だけでは、最終的なアクセス範囲の大きさを説明できない点にある。リスクは、IDシステム、リポジトリ、ビルドおよびデプロイパイプライン、運用基盤の相互接続から生じた。そのため、各層を個別に保護するだけでは、侵害されたアカウントの権限が後続の層へ信頼された経路を開いている場合、そのアカウントを封じ込めることはできない。
DARTは、IDシステム、開発プラットフォーム、クラウド基盤からデータを分析し、顧客と日次の説明会を行いながら、封じ込めと修復に向けた優先順位付きの指針を提供して対応した。また、Microsoft Threat Intelligenceとも連携し、この活動をより広い文脈の中に位置付けた。
実践的な防御策
- 繰り返される試行や複数のユーザーを標的とするパターンを探すため、パスワードリセット活動を監視する。
- 高い権限を持つアカウントがセルフサービスのリセット経路にさらされる範囲を減らし、フィッシング耐性のある多要素認証を強制する。
- コード変更への承認を必須とし、無許可の変更を防ぐためブランチ保護を有効にする。
- 重要なブランチへの直接コミットを制限し、変更に明確なレビューと承認を義務付ける。
- ビルドおよびデプロイパイプラインの権限を管理し、それらを作成、変更、実行できる人物を特定する。
- ID、開発プラットフォーム、クラウドリソースに最小権限の原則を適用し、1つのアカウントが侵害された場合の影響を抑える。
なぜこのニュースが重要なのか？
この事例は、ID、Azure DevOps、Git、Kubernetes環境のログを、分離した情報源ではなく、相互に結び付いたセキュリティ状況として読み取る必要があることを示している。一方、情報源が示す未解決の問いは、正規ツールの悪用を組織がどの程度発見できるのか、環境をまたぐ権限を見直せるのか、そして認証情報ファイルが本番環境へのアクセスに使われる前に、リポジトリへの流出を防げるのかという点にある。