Storm‑2949：たった1つのID侵害がMicrosoft 365とAzure全体の侵害に発展した仕組み

Microsoftが公開した脅威レポートによると、Storm‑2949と追跡されている攻撃は、マルウェアを使わずにクラウド環境へ深く侵入した典型例だった。攻撃の出発点はわずか1つのユーザーアカウントの乗っ取りであり、その後はMicrosoft 365やAzureの正規機能を利用して組織全体のクラウド環境へとアクセスを広げていった。

この事例は、近年のサイバー攻撃が「ソフトウェアの脆弱性」よりもクラウドのアイデンティティ管理とAPIを狙う方向に移っていることを象徴している。

侵入の始まり：単一アカウントの乗っ取り

Microsoftの分析によると、攻撃はまず1つのユーザーIDの侵害から始まった。攻撃者はこのアカウントを使ってMicrosoft Entra ID（旧Azure AD）のテナント内部を調査し、追加のターゲットを探し始めた。

この段階で使われたのがMicrosoft Graph APIである。これはMicrosoft 365やAzureのユーザー、グループ、アプリケーション、ロールなどの情報を取得できる公式APIだ。

攻撃者はPython製のカスタムスクリプトを使い、Graph APIへのリクエストを自動化。大量のクエリを実行して以下の情報を列挙した。

• ユーザーアカウント
• アプリケーション登録
• ロールや権限
• 特権アカウントの候補

アカウント名のパターンやロール属性を分析し、管理者権限を持つ可能性が高いIDを特定していたとみられる。

Self‑Service Password Reset（SSPR）の悪用

侵入の拡大に重要な役割を果たしたのが、Microsoft Entra IDの**Self‑Service Password Reset（SSPR）**だった。

SSPRはユーザーが自分でパスワードをリセットできる機能で、通常はヘルプデスクの負担を減らすために使われる。しかし今回のケースでは、攻撃者がアカウント復旧フローを悪用してアクセスを強化・維持したと報告されている。

この機能は正規の認証プロセスの一部であるため、不正利用があってもログ上では通常のアカウント回復操作に見える可能性がある。

Graph APIとAzure RBACによる権限昇格

環境の構造を把握した後、攻撃者はシステム脆弱性を突くのではなく、クラウドの権限管理そのものを利用して権限を拡大した。

重要だったのは次の2つの仕組みである。

• Microsoft Graph API：ディレクトリ情報の取得や操作
• Azure RBAC（Role‑Based Access Control）：Azureリソースの権限管理

これらを組み合わせることで、攻撃者は特権ロールや管理アカウントを見つけ出し、クラウド環境全体に影響を及ぼす権限へ段階的に昇格していった。

Azureの重要リソースにアクセス

権限を広げた後、攻撃者は複数のAzureサービスへアクセスしたとされる。

対象には次のような高価値リソースが含まれていた。

• App Services
• Key Vault
• SQLデータベース
• 仮想マシン（VM）

これらのリソースにはアプリケーションの秘密情報、認証情報、業務データ、運用環境などが保存されていることが多く、クラウド侵害では特に狙われやすい。

正規の管理ツールを使って検知を回避

Storm‑2949が発見されにくかった理由の一つは、攻撃者が既存の管理ツールだけを使って行動した点にある。

観測された主なツールは以下の通り。

• VMAccess
• Run Command
• PowerShell

これらはAzure管理者が日常的に使うツールであるため、ログ上では正規の運用操作と区別がつきにくい。

その結果、攻撃者は環境内を横断的に移動しながらも比較的低い検知リスクで活動できた。

数日間続いたデータ流出

最終段階では、攻撃者は数日間にわたって機密データを外部へ持ち出していたことが確認された。

長期間のデータ流出が可能だったことは、攻撃者がテナント内で持続的なアクセス権を維持していた可能性を示している。

なぜこのタイプの攻撃は見つけにくいのか

Storm‑2949は、近年増えているアイデンティティ主導型クラウド攻撃の特徴をよく示している。

検知が難しい主な理由は次の通り。

• 有効な認証情報を使用している
• APIベースの操作が自動化や管理タスクに見える
• 権限昇格がRBACなど正規の仕組みを通じて行われる
• 管理ツールがすべて公式機能

つまり、攻撃者はクラウド内部の“正しい機能”だけで侵入を拡大できてしまう。

Microsoftが推奨する防御策

Microsoftは、同様の攻撃を防ぐためにアイデンティティセキュリティの強化を強く推奨している。

主な対策は以下の通り。

1. アイデンティティ保護の強化
単一のアカウント侵害がテナント全体の侵害につながらないよう、認証防御を強化する。

2. SSPR設定の見直し
特権アカウントでは特に慎重に設定し、不正な回復手段が登録されないよう監査する。

3. MFAと条件付きアクセスの強制
多要素認証とコンテキストベースのアクセス制御により、盗まれた認証情報の価値を下げる。

4. Microsoft Graph APIの監視
大量のディレクトリ列挙や自動化されたAPI呼び出しを検知できるようにする。

5. Azure RBACの監査
ロール割り当てを定期的に確認し、最小権限の原則を徹底する。

6. 管理ツールの異常利用を検知
VMAccess、Run Command、PowerShellなどの利用を監視し、通常と異なるパターンをアラート化する。

7. 重要リソースのアクセス制御
Key Vault、データベース、運用VMなど高価値リソースへのアクセスを厳格に管理する。

Storm‑2949が示したクラウドセキュリティの教訓

この事件が示した最大のポイントは、クラウド環境では「アイデンティティ」が最大の攻撃面になっているという事実だ。

攻撃者が1つのアカウントを支配すると、API、権限管理、管理ツールを利用して環境全体に広がることができる。

そのため現代のクラウド防御では、従来のマルウェア検知やエンドポイント監視だけでは不十分だ。組織は次の領域まで可視化を広げる必要がある。

• アイデンティティの挙動
• APIの利用状況
• 権限の変更
• クラウドコントロールプレーンの操作

Storm‑2949は、クラウド侵害が「マルウェアなし」で成立する時代をはっきり示したケースといえる。