Azure DevOps/Kubernetes リソースへの不正アクセス:1つのアカウントから始まった侵害

Hackers Turn One Compromised Account Into Access to Azure DevOps and Kubernetes

2026/09/30 CyberSecurityNews — 1つのアカウントが侵害されるだけで、クラウド環境全体への侵入経路が開かれる可能性がある。最近の調査で明らかになったのは、攻撃者が侵害した1つのアイデンティティを悪用してパスワードをリセットし、Azure DevOps/開発パイプライン/Kubernetesリソースへとアクセスを拡大した事例である。このインシデントでは、ソフトウェアの脆弱性や独自のマルウェアは使用されておらず、攻撃者は組織が日常的に使用する信頼済みサービスを介し、通常のアクセス権を悪用してソースコード/導入設定/基盤の認証情報へとアクセスを拡大していた。

Microsoftのアナリストは、この活動をStorm-3068と特定し、攻撃者がセルフサービスのパスワードリセットを通じてアカウントを乗っ取ったことを確認した。Microsoftのレポートによると、攻撃者は独自の認証方法を登録し、アクセスを維持できる状態にした。

今回の事例は、開発システムが攻撃対象となる理由を示している。以前に発生したMicrosoft Entra IDアカウントへの攻撃でも、同様に正規のクラウド機能が悪用されたが、今回の攻撃者が関与したものではない。一方、今回の侵害では、接続されたリポジトリ/自動化パイプライン/クラウドリソースを介して、1つのアイデンティティの侵害が広範な環境へのアクセスにつながった。

侵害された1つのアカウントからアクセスを拡大

アカウントを掌握したStorm-3068は、正規の管理ツールや自動化スクリプトを使用して Azure DevOpsのプロジェクト/リポジトリ/パイプライン/展開環境を調査し、接続されたシステムや価値の高い認証情報が存在する可能性のある場所を把握した。ソフトウェア開発とクラウド運用を結び付けるAzure DevOpsは、こうした情報を探索する上で攻撃者にとって有用だった。

別の Azure DevOps MCP の脆弱性では、認可されたアクセスを悪用する別の手法が明らかになったが、今回の侵害では、攻撃者がすでに侵害したアカウントを悪用して、信頼されたデプロイ経路や接続されたリソースを特定した。

続いて攻撃者は、Kubernetes の認証情報を大規模に収集するための悪意のパイプラインを作成し、kube エージェントを導入して、Kubernetes リソースへのアクセスに必要な接続情報や認証情報を含むクラスタ設定ファイルを収集する、複数のジョブを実行した。

Microsoftによると、このパイプラインには 50 を超えるリソースへのアクセス権とサービスへの認証権限が付与されている。その後の調査では、窃取された 7 つのクラスタ設定ファイルがリポジトリに追加され、標的となった Kubernetes クラスタへのアクセスに必要な認証情報が含まれていたことが判明した。

この一連の活動は、開発プラットフォームがソースコードだけでなく、リポジトリ/サービス接続/導入設定を通じて、組織の広範な環境への侵入経路にもなり得ることを示している。攻撃者は、組織が信頼している接続関係を悪用することで、侵害したアカウントからアクセス範囲を拡大できる。

クラウドへのアクセス拡大と対応

Storm-3068はパイプラインのスクリプトを変更し、Ateraリモート管理エージェントのインストールと Chiselトンネリング・ユーティリティのダウンロードを行った。調査担当者によると、これらの変更は別のリモートアクセス経路を構築し、Kubernetes API サーバを外部からアクセス可能にしてクラスタとの通信を可能にすることを目的としている。Chisel のコマンドによって、外部 IP アドレスへのリバーストンネルが確立されたが、当該 IP アドレスは公表されていない。

侵害経路の再構築やリポジトリに保存された、窃取済み認証情報の特定には、Azure DevOps の監査ログや Git のバージョン履歴が有用だった。Microsoft の対応チームは、認証システム/開発プラットフォーム/クラウド基盤にわたる記録を分析して攻撃者のアクセス範囲を調査し、影響を受けた組織に対して、日々の状況説明や優先順位を付けた封じ込めの指針と、再侵害の可能性を低減するための推奨事項を提供した。

また、DART は Microsoft Threat Intelligence と連携して、より広範な脅威情報を踏まえた分析を行い、新たな詳細が明らかになる中で調査を進展させ、影響を受けた環境全体で対応すべき対象を絞り込んだ。

組織に求められるのは、パスワードリセットの活動を監視し、繰り返される試行や複数のユーザーにまたがるパターンを確認するとともに、特権アカウントで利用できるセルフサービスのリセット処理を制限し、フィッシング耐性の高い多要素認証 (MFA) を必須にすることだ。これらの対策は、今月初めに報告された別のパスワードリセット・ポータルの情報露出にも関連する。

開発環境の保護については、コード変更時の承認を必須とし、ブランチ保護を適用するとともに、重要なブランチへの直接コミットを制限して、すべての変更が所定のレビュー手順を経るようにする必要がある。さらに、パイプラインの権限を適切に管理し、ビルドやデプロイのワークフローを作成/変更/実行できるユーザーを制限するほか、認証システム/開発プラットフォーム/クラウドリソース全体に対して最小権限の原則を適用し、不正な変更や権限の悪用によるリスクを低減する必要がある。

認証システム/DevOps/クラウドの管理策を定期的に見直すことで、組織が信頼する接続関係を介して、侵害された1つのアカウントから本番環境へアクセスされるリスクを低減できる。