この段階で使われたのがMicrosoft Graph APIである。これはMicrosoft 365やAzureのユーザー、グループ、アプリケーション、ロールなどの情報を取得できる公式APIだ。
攻撃者はPython製のカスタムスクリプトを使い、Graph APIへのリクエストを自動化。大量のクエリを実行して以下の情報を列挙した。
アカウント名のパターンやロール属性を分析し、管理者権限を持つ可能性が高いIDを特定していたとみられる。
侵入の拡大に重要な役割を果たしたのが、Microsoft Entra IDの**Self‑Service Password Reset(SSPR)**だった。
SSPRはユーザーが自分でパスワードをリセットできる機能で、通常はヘルプデスクの負担を減らすために使われる。しかし今回のケースでは、攻撃者がアカウント復旧フローを悪用してアクセスを強化・維持したと報告されている。
この機能は正規の認証プロセスの一部であるため、不正利用があってもログ上では通常のアカウント回復操作に見える可能性がある。
環境の構造を把握した後、攻撃者はシステム脆弱性を突くのではなく、クラウドの権限管理そのものを利用して権限を拡大した。
重要だったのは次の2つの仕組みである。
これらを組み合わせることで、攻撃者は特権ロールや管理アカウントを見つけ出し、クラウド環境全体に影響を及ぼす権限へ段階的に昇格していった。
権限を広げた後、攻撃者は複数のAzureサービスへアクセスしたとされる。
対象には次のような高価値リソースが含まれていた。
これらのリソースにはアプリケーションの秘密情報、認証情報、業務データ、運用環境などが保存されていることが多く、クラウド侵害では特に狙われやすい。
Storm‑2949が発見されにくかった理由の一つは、攻撃者が既存の管理ツールだけを使って行動した点にある。
観測された主なツールは以下の通り。
これらはAzure管理者が日常的に使うツールであるため、ログ上では正規の運用操作と区別がつきにくい。
その結果、攻撃者は環境内を横断的に移動しながらも比較的低い検知リスクで活動できた。
最終段階では、攻撃者は数日間にわたって機密データを外部へ持ち出していたことが確認された。
長期間のデータ流出が可能だったことは、攻撃者がテナント内で持続的なアクセス権を維持していた可能性を示している。
Storm‑2949は、近年増えているアイデンティティ主導型クラウド攻撃の特徴をよく示している。
検知が難しい主な理由は次の通り。
つまり、攻撃者はクラウド内部の“正しい機能”だけで侵入を拡大できてしまう。
Microsoftは、同様の攻撃を防ぐためにアイデンティティセキュリティの強化を強く推奨している。
主な対策は以下の通り。
1. アイデンティティ保護の強化
単一のアカウント侵害がテナント全体の侵害につながらないよう、認証防御を強化する。
2. SSPR設定の見直し
特権アカウントでは特に慎重に設定し、不正な回復手段が登録されないよう監査する。
3. MFAと条件付きアクセスの強制
多要素認証とコンテキストベースのアクセス制御により、盗まれた認証情報の価値を下げる。
4. Microsoft Graph APIの監視
大量のディレクトリ列挙や自動化されたAPI呼び出しを検知できるようにする。
5. Azure RBACの監査
ロール割り当てを定期的に確認し、最小権限の原則を徹底する。
6. 管理ツールの異常利用を検知
VMAccess、Run Command、PowerShellなどの利用を監視し、通常と異なるパターンをアラート化する。
7. 重要リソースのアクセス制御
Key Vault、データベース、運用VMなど高価値リソースへのアクセスを厳格に管理する。
この事件が示した最大のポイントは、クラウド環境では「アイデンティティ」が最大の攻撃面になっているという事実だ。
攻撃者が1つのアカウントを支配すると、API、権限管理、管理ツールを利用して環境全体に広がることができる。
そのため現代のクラウド防御では、従来のマルウェア検知やエンドポイント監視だけでは不十分だ。組織は次の領域まで可視化を広げる必要がある。
Storm‑2949は、クラウド侵害が「マルウェアなし」で成立する時代をはっきり示したケースといえる。