Storm-2949クラウドID侵害事例に学ぶ｜CSPM/IAM運用の見直しポイントと最小権限の実装パターン

「Microsoftが公表したStorm-2949の事例、うちのテナントでも同じことが起きたら止められるのか」
オンプレのActive Directoryを20年以上面倒見てきた感覚で読み解くと、今回の攻撃は「マルウェアのない侵入」「正規API経由のデータ持ち出し」という、検知の網に最も引っかかりにくい型でした。SSPR（セルフサービスパスワードリセット）の運用上の隙を突かれ、1人の侵害が Microsoft 365 と Azure 全体に広がっています。

この記事では、2026年5月18日にMicrosoft Threat Intelligenceが公表した攻撃クラスタ「Storm-2949」を題材に、攻撃の詳細解説ではなくCSPM（Cloud Security Posture Management）とIAM運用の見直しに焦点を絞って整理します。AWS／Azure／GCP の最小権限実装の違い、Key Vault・ストレージファイアウォール・条件付きアクセスをどう運用ダッシュボードへ載せるか、そしてCSPM入門記事（CSPM入門｜マルチクラウド構成ミス検知ツール比較と運用フロー設計）で扱った基礎を、実事例の運用見直しレベルに引き上げるのが本記事の役割です。攻撃手口・IoC・SOC初動の詳細は姉妹サイトSecurityMaster側で別途扱います。

Storm-2949事例の要点（一次情報の整理）

まず伝聞や憶測を排して、Microsoft公式発表ベースで要点を整理します。

Microsoft Threat Intelligenceは2026年5月18日、攻撃クラスタ「Storm-2949」が単一のID侵害をMicrosoft 365とAzure全体への侵害へ発展させた事例を公表しました。従来型マルウェアにほぼ依存せず、Microsoft Graph API・Azure RBAC・Run Command・VMAccess等の正規管理プリミティブで攻撃が完結している、いわゆるLiving-off-the-Cloud型です。
・公開日: 2026年5月18日（Microsoft Security Blog）
・命名: Microsoft Threat Intelligenceによるクラスタ「Storm-2949」
・初期侵入: Microsoft SSPRのソーシャルエンジニアリング悪用（攻撃者がIT担当を装い、ターゲット本人にMFAプロンプト承認を依頼）
・標的: IT担当者・経営層など特権ロール保持者を意図的に選定
・影響範囲: Microsoft 365（OneDrive・SharePoint）／Azure Key Vault／Azure SQL／Azure Storage／App Service／VM
・持続化: ScreenConnect（RMM）をVMにデプロイ、認証電話／メール／Authenticator登録を削除し再登録
・マルウェア: 従来型マルウェア不使用、カスタムPythonスクリプト経由のGraph API列挙が中心

被害企業名・C2インフラの具体IPはMicrosoft非開示のため本記事でも書きません。MFAを有効化していても、再登録権限がユーザー自身に開いていれば、社内ITを装った電話一本で実質的な突破口になるのが運用側にとっての怖さです。教訓は「攻撃グループの追跡」ではなく、自テナントのCSPM・IAM運用がLiving-off-the-Cloud型でも検知・遮断できる構成かを問い直すことにあります。

CSPM運用ダッシュボードで見直すべき5項目

CSPMツールを入れただけで満足してしまっている現場は珍しくありませんが、Storm-2949事例を運用ダッシュボードに落とすと、見直すべき項目は次の5つに集約されます。

1つ目はKey Vault／Secrets Managerのアクセス設定変更検知。Storm-2949は侵害したIDでKey Vaultアクセスポリシーを書き換えシークレット数十件を窃取しました。CSPM側で「アクセスポリシー変更」「権限拡張」「purge protection無効化」を常時監視し、AWS Secrets Manager側でも「リソースポリシー編集」「クロスアカウント許可付与」をウォッチします。

2つ目は条件付きアクセス（Conditional Access）の除外リスト定期棚卸し。運用が進むと例外が増え、特権ロール保持者が除外に入っていればフィッシング耐性MFAも効きません。「除外リストに特権ロールが含まれていないか」のスキャンルールが、入門段階では未設定なケースが多いです。

3つ目はストレージ／DBファイアウォールのIP許可リスト改変監視。Storm-2949はAzure SQL／StorageのIPファイアウォールを書き換えました。S3バケットポリシー／RDS SG／GCP Cloud SQL承認済みネットワークも同様で、「24時間以内の許可IP追加」「0.0.0.0/0開放」を最優先アラートに昇格させます。

4つ目はMicrosoft Graph API／AWS CLI／gcloudの異常APIコール頻度。Storm-2949はカスタムPythonでGraph APIをループ列挙していました。Microsoft Sentinel／CloudTrail Insights／Cloud Audit Logsと連動させ、「短時間でのユーザー／ロール／アプリ列挙」を検知シグナル化します。

5つ目はRMMツールの計画外インストール検知。Storm-2949はVMにScreenConnectを展開しました。Defender for Cloud／GuardDuty／Defender for Endpointで「想定外RMMバイナリ実行」「VM拡張機能の予期せぬ追加（CustomScriptExtension／RunCommand）」をCSPM経由で集約します。

CSPM入門記事の「構成ミス検知」を一段引き上げるには、スナップショットではなく「過去24時間の構成変更差分」を検知シグナル化し、変更を起点に「誰が／いつ／どの権限で」を即座に紐づける運用が現実解です。

AWS／Azure／GCPで最小権限をどう実装するか

最小権限の原則はどのクラウドにも共通しますが、実装の文法が異なります。Microsoftも筆頭で「Practice the principle of least privilege」を挙げており、これを各クラウドへ翻訳します。

AWS IAMでは、IAM Identity Center を Permission Set 単位で組み合わせるのが現代的です。AWS IAM Identity Center入門の設計を本事例で見直すと「Permission Setに `secretsmanager:GetSecretValue` を広域許可していないか」「`iam:PassRole` を Resource:* で開いていないか」が問われます。

Azure RBACは、Role／Role Assignment／Scopeの3層で権限を構成します。Storm-2949がKey Vaultアクセスポリシーを書き換えた経路を遮断するには、Vaultを Azure RBAC ベースへ移行（Access Policiesから）し、Key Vault Secrets User／Crypto User など最小スコープのビルトインロールを使い、Owner や Contributor を Vault スコープに直接割り当てないことが要諦です。

GCP IAMは、principal／role／resourceの3要素で権限を表現し、「基本ロール（Owner/Editor/Viewer）を避け、Predefined Roleまたはカスタムロールを使う」指針が公式に明示されています。Storage Object Admin を Project スコープで配布していないか、roles/iam.serviceAccountTokenCreator が広く付与されていないかをCSPMでスキャンします。

実務で三者を組み合わせる鉄則は「権限はグループ／ロールに付与」「最大スコープから下位で必要分だけ追加」「特権ロールはJIT昇格」の3点です。Azure側はPIM、AWS側は IAM Identity Center + 一時昇格 + SCP、GCP側は IAM Conditions + Org Policy がJITに相当し、常時付与された特権ロールを足がかりにする本事例で有効な追加防御になります。

条件付きアクセスとフィッシング耐性MFAの実装パターン

Storm-2949は、ユーザー本人にMFAプロンプトを承認させる「ソーシャル経由のMFA突破」をやってのけました。これは「MFA有無」ではなく「どのMFA方式を、誰に、どの条件で要求しているか」を問い直す事例です。

フィッシング耐性MFAとして現実的な選択肢は、FIDO2セキュリティキー（YubiKey等）／Windows Hello for Business／プラットフォーム認証器（Passkey）／証明書ベース認証（CBA）の4つです。電話／SMS／音声／プッシュ通知のみのAuthenticatorは、Storm-2949のソーシャル文脈では突破されうるため、特権ロール保持者には不可と考えるのが妥当です。

実装は、Azure Entra IDのConditional Accessで Global Administrator／Privileged Role Administrator／Security Administrator／Authentication Administrator などTier 0相当ロール保持者にAuthentication Strengthを「Phishing-resistant MFA」固定にします。同時にSSPRの認証方法再登録権限を、特権ユーザーには Self-Service ではなく管理者代行のみに限定するのが、本事例に最も直接的に効く防御です。
・Tier 0特権ロール: フィッシング耐性MFA + Self-Service SSPR無効化
・Tier 1管理者: フィッシング耐性MFA + Self-Service SSPRは管理者承認制
・一般従業員: 多要素 + Self-Service SSPR可、ただしSSPRログを Sentinel で集約
・外部ゲスト: B2B招待 + Conditional Accessでサイト限定

AWS側はrootにハードウェアMFA必須、IAM Identity Center 特権Permission Set には WebAuthn 必須、一般ユーザーには TOTP を要求し、セッション期間を1時間程度に短縮して再認証頻度を上げます。GCP側は組織レベルで 2-Step Verification を必須化、admin保持者にはFIDO2を強制、Context-Aware Access で「特定IP範囲・特定デバイス・OSパッチ状態」を条件に重ねます。

なお、フィッシング耐性MFAだけ入れてもSSPRで認証方法を再登録できる経路が開いていれば、Storm-2949同型の手口は通り続けます。Microsoft公式でも「authentication method の再登録」が攻撃の鍵として明示されており、SSPR運用の見直しはMFA強度と同等以上に優先度が高い実装課題です。

Storm-2949事例のCSPM/IAM運用見直しチェックリスト

実装の優先順位を整理するため、Storm-2949事例から導かれるCSPM/IAM運用見直しチェックリストを5つにまとめます。
・チェック1（48時間以内）: 特権ロール（Global Admin／Privileged Role Admin／Security Admin等）保持者のリストを抽出し、認証方法をフィッシング耐性MFA（FIDO2／CBA／Windows Hello）に固定する条件付きアクセスポリシーを発動する
・チェック2（1週間以内）: SSPRの認証方法再登録権限を、特権ロール保持者に対して無効化または管理者承認制に切り替える。一般ユーザーのSSPRログを Microsoft Sentinel／CloudTrail／Cloud Audit Logs へ集約し、異常検知ルールを設定する
・チェック3（2週間以内）: Key Vault／Secrets Manager／Secret Manager のアクセスポリシー変更検知をCSPMの最優先アラートに昇格し、purge protection を全 Vault で有効化、Conditional Access 除外リストから特権ユーザーを外す
・チェック4（1ヶ月以内）: Azure SQL／Storage／AWS RDS／S3／GCP Cloud SQL／Cloud Storage のIP許可リスト・パブリックアクセス設定の現状スナップショットを取得し、CSPM側で「過去24時間以内のIP許可追加」「パブリック化」を即時アラートに登録する
・チェック5（継続）: 管理プレーンAPI（Microsoft Graph／AWS IAM／gcloud）の異常列挙・大量呼び出しを、Microsoft Sentinel／CloudTrail Insights／Cloud Audit Logs と連携してUEBA（User and Entity Behavior Analytics）的に監視する

1と2は攻撃が成立した経路に直接効くため48時間～1週間で必ず手を打ち、3と4はCSPM既存フローに組み込み、5はSIEM／UEBAへ寄せる中期施策として位置付けます。

CSPM入門段階の「構成ミス検知」を、Storm-2949の現実を踏まえて「構成変更の差分」と「特権アカウントの認証強度」へ一段深める必要があります。

よくある質問（FAQ）

Q1. CSPMツール導入済みなら、Storm-2949のような事例は防げますか？

CSPMだけでは不十分です。多くのCSPMは「構成のスナップショット監査」が中心で、正規API経由で短時間に設定変更を重ねるパターンは変更差分検知ルールを別途設定しないと拾えません。CSPM＋SIEM＋ID Threat Detection（ITDR）の3点セットで初めて、本事例タイプの侵害に網が張れます。

Q2. 中小規模の組織でフィッシング耐性MFAを一気に導入するのは現実的ですか？

特権ロール保持者（管理者数名）から段階導入するのが現実解です。Global Administrator・Privileged Role Administrator など Tier 0、AWSのroot／IAM Identity Center 管理者、GCPのOrg Admin から FIDO2 セキュリティキーを配布します。一般ユーザーは TOTP＋デバイス制約から始め、半年～1年でパスキーへ段階移行する計画が現実的です。

Q3. SSPRを完全に無効化すべきですか？

完全無効化は推奨しません。ヘルプデスク負荷で運用が破綻します。推奨は「特権ロール保持者のみSSPR無効化（または管理者承認制）」「一般ユーザーはSSPR有効＋認証方法再登録時に追加検証を必須化」「SSPRログをSIEMで集約し認証方法変更を即時アラート化」の3点セットです。Microsoft公式でもSSPRの仕組み自体ではなく「ソーシャル経由でMFA再登録を許す運用」が問題と整理されています。

Q4. Key Vault のアクセスポリシーをそのまま使い続けてはダメですか？

新規 Vault は Azure RBAC ベースへ統一することを推奨します。アクセスポリシーベースは個別Vault単位の管理になり、CSPMのスキャンルールが Vault ごとに散らばるため、「全VaultでKey Vault Secrets User以上の権限を持つプリンシパル一覧」を即座に取りにくい構造になります。Microsoftも Azure RBAC ベースを推奨方向としており、既存Vaultも段階移行が現実的です。

Q5. Storm-2949はマルウェア不使用とのことですが、EDRは不要ですか？

不要ではありません。ScreenConnect（RMM）の計画外インストール、ユーザー端末上の偽装プロセス、認証情報窃取段階では、Defender for Endpoint／CrowdStrike Falcon／SentinelOne 等のEDRが検知する余地があります。Microsoftも「Defender for Endpoint を EDR in block mode で有効化」を明記しており、CSPM／IAM とエンドポイントEDRはセットで考えるのが妥当です。

本記事のまとめ

Storm-2949の事例は、攻撃グループの追跡そのものより、自テナントのCSPM・IAM運用が「正規APIを経由した侵害」でも検知・遮断できる構成かどうかを運用責任者に問い直す題材として価値があります。
・CSPMは「構成ミス検知」から「構成変更差分検知」へ評価軸を一段深める。Key Vault／ストレージFW／条件付きアクセス除外リストを最優先で監視する
・最小権限はAWS／Azure／GCPの文法差を踏まえて翻訳する。AWS Permission Set／Azure RBAC＋PIM／GCP Predefined RoleでJIT昇格を組み込む
・フィッシング耐性MFAは特権ロール保持者から段階導入。FIDO2／Windows Hello／CBAのいずれかをTier 0必須化する
・SSPRの認証方法再登録権限は、特権ロールに対して無効化または管理者承認制。これがStorm-2949同型の侵害に最も直接的に効く
・CSPM＋SIEM＋ITDR＋EDRの4点セットで多層防御を構成し、構成・ID・行動・端末の4面から異常を捕捉する

CSPM／IAM運用の入門は終わり、次は「事例を踏まえた運用ダッシュボードの設計」に進むフェーズです。Storm-2949はその切り替えの号砲だと受け止めるのが、運用責任者として妥当な姿勢だと考えます。攻撃手口・IoC・SOC初動・検知ルールの具体は姉妹サイトSecurityMaster側で別途扱う予定です。