Storm-2949が単一ID窃取からM365/Azure全体侵害に至った全手口｜MITRE ATT&CKマッピングと検知ルール

「マルウェアを置かない、正規API経由で完結する、検知の網に最も引っかからない」──2026年5月18日にMicrosoft Threat Intelligence (MSTIC) が公表した攻撃クラスタ Storm-2949 は、防御側の前提を根本から揺さぶる事例でした。攻撃者は誰一人ファイルを落とさず、ただ一人のEntra ID（旧Azure AD）ユーザーを電話一本で窃取することから、Microsoft 365とAzure環境全体への侵害へとつなげています。

本記事は、Storm-2949の手口を「攻撃者目線」で時系列にバラし、MITRE ATT&CK のTactic/Techniqueに対応づけ、Microsoft Sentinel や Defender XDR で使える検知ルールの組み立て方、SOCが最初の48時間で踏むべき封じ込め手順までを一気通貫で整理します。「自社で同じ攻撃を受けたら、どこで止められるか」を答えられる状態を目指す情シス・SOC担当者の方に向けた構成です。一次情報は Microsoft Security Blog（2026年5月18日付）と、SOC PrimeのThreat Detection Marketplace解説記事を出典としています。

Storm-2949攻撃の全体像と攻撃者プロファイル

まず、何者が、いつ、何を狙ったのかを公開情報の範囲で押さえます。

Storm-2949は、MSTIC が割り振る一時的な「Storm-####」識別子で追跡されているクラスタです。この命名は「攻撃グループとして確定的に帰属判定する前段階」で使われるもので、国家系・金融犯罪系のいずれかの帰属はMicrosoft非開示。執筆時点（2026年5月22日）で目的は「ターゲット組織の高価値資産からのデータ持ち出し」と明示されています。ランサムウェア配備や破壊活動は確認されておらず、純粋なデータ窃取型です。

公表は2026年5月18日。Microsoft Security Blogの記事タイトル「How Storm-2949 turned a compromised identity into a cloud-wide breach」が示すとおり、ストーリーの主役は「単一IDの侵害が、なぜクラウド全体の侵害に化けるのか」です。

特徴を一行でまとめると、こうなります。

・マルウェア: 従来型マルウェアを使わない「Living-off-the-Cloud（クラウド組み込み機能のみで完結）」型
・初期侵入: SSPR（セルフサービスパスワードリセット）の運用上の隙を狙ったソーシャルエンジニアリング
・持続化: 攻撃者デバイスでのMicrosoft Authenticator再登録、ScreenConnect（RMM）のVM配備
・偵察: カスタムPythonスクリプトでMicrosoft Graph APIを反復列挙
・横展開: Azure RBACの正規権限、Run Command、VMAccess拡張機能、Kudu Console
・持ち出し: OneDriveのWeb UIから一括ダウンロード、Azure Storage SAS、SQL FW書換え

被害組織の業種・規模・地域はMicrosoft非開示ですが、「複数Azureサブスクリプション・複雑なテナント・特権ロール保持のIT担当と経営層を多く抱える大規模組織」という記述から、エンタープライズ規模であることがうかがえます。SOC Prime の解説では「3つの攻撃者管理のIPアドレスと関連付けられた」とされていますが、具体IP・C2ドメイン・実行ファイルのハッシュは執筆時点で非公開です。本記事でも憶測の数値は書きません。

初期侵入：SSPRソーシャルエンジニアリングの完全分解

最大のポイントは「MFAを有効にしていても突破された」という事実です。Storm-2949 の侵入は、技術的脆弱性の悪用ではなく、SSPRの運用設計の隙を突くソーシャルエンジニアリングでした。

攻撃の流れを、MSTIC公表内容に基づき5段階で整理します。

・段階1（標的選定）: 攻撃者は事前に LinkedIn・公開組織図・テナントの公開設定などから、特権ロール（Global Administrator、User Administrator、Application Administrator など）に近いIT担当者および経営層を選定
・段階2（SSPR起動）: 攻撃者が標的本人を装い、または並行して、標的ユーザーのアカウントに対してSSPRリセット手続きを起動
・段階3（IT詐称電話）: 攻撃者が標的本人に電話やTeams等で接触し「IT部門の○○です、システム障害でパスワードリセット手続きが進行中です、まもなくMFAプロンプトが届くので承認してください」と依頼
・段階4（MFA承認誘導）: 標的が善意でMFAプロンプトを承認 → 攻撃者がパスワード変更を完遂
・段階5（既存MFA方法の削除）: 攻撃者がEntra IDに正規ログインし、被害者のMFA登録（電話番号・メール・Microsoft Authenticator）をすべて削除、自分のデバイスにMicrosoft Authenticatorを再登録して恒久アクセスを確保

ここで重要なのは、段階5の「MFA方法の入れ替え」が 正規のSelf-Service Account Management機能 で完結している点です。Entra IDの監査ログには「ユーザー自身が認証方法を変更しました」としか記録されないため、ふつうの監査では異常として浮き上がりません。これがLiving-off-the-Cloudの怖さです。

MITRE ATT&CK対応では、初期侵入クラスタは以下のTechniqueに対応します。

・T1566（Phishing）: 電話/メッセージング経由のソーシャルエンジニアリング
・T1621（Multi-Factor Authentication Request Generation）: 連続MFAプロンプト送信で承認を誘導
・T1078.004（Valid Accounts: Cloud Accounts）: 正規Entra IDアカウントの悪用
・T1098.005（Account Manipulation: Device Registration）: 攻撃者デバイスのMFA登録
・T1556.006（Modify Authentication Process: Multi-Factor Authentication）: 既存MFA方法の削除

防御側の論点は単純で、SSPRと認証方法管理の 「実行可能な範囲」と「実行時の通知/承認フロー」 を見直すことです。Microsoftの推奨は、特権ロール保持者にはフィッシング耐性MFA（FIDO2セキュリティキーやWindows Hello for Business）を強制し、認証方法の追加・削除には管理者承認またはユーザー自身への即時通知（メール＋プッシュ）を必須化する設定です。

特権昇格と横展開：正規Azure管理プリミティブだけで完結する攻撃

初期侵入で1つのアカウントを掌握した後、Storm-2949は カスタムPythonスクリプトでMicrosoft Graph APIを反復クエリ し、テナント内のユーザー・グループ・サービスプリンシパル・アプリ・ロール割り当てを列挙しました。狙いは「特権Azure RBACロールが付いた他ユーザー」と「マネージドID・アプリ登録から特権昇格できる経路」の特定です。

特権昇格は、最初の被害ユーザーで完結せず、同じSSPR手口で 追加で3アカウントを連鎖侵害 しました。それぞれ異なるサブスクリプション・異なるリソースグループに特権を持つユーザーで、攻撃者は意図的に「権限の差分を補完するように」狙ったとMSTICは記しています。

横展開フェーズで悪用された正規Azure管理プリミティブを、実際に呼ばれたAzure RBAC操作と一緒に整理します。

特に Key Vault 侵害は深刻で、MSTICによれば 「4分間で数十のシークレットを読み出し、そのうちのDB接続文字列を使って本命の本番Webアプリに認証突破した」 と記載されています。Key Vaultは攻撃者にとって「シークレットの自販機」であり、ここを抜かれた瞬間に侵害の爆発半径が一気に広がります。

防御側の論点は次の3点に集約されます。1つ目、Azure RBACの custom role と built-in role の付与状況を棚卸しし、特に「Owner」「Contributor」「User Access Administrator」「Key Vault Administrator」の保有者数を最小化すること。2つ目、Key Vault の「purge protection」「公開ネットワークアクセス無効化」「アクセスポリシーまたはRBACモデルの統一」を徹底すること。3つ目、Run Command と VMAccess 拡張機能の利用を必要最小限のロールに制限し、利用時は即時SOC通知を発火させることです。

OneDriveとAzure Storageからのデータ持ち出し手口

データ持ち出しは2つの経路で並行実行されました。

1つ目はMicrosoft 365側で、攻撃者は侵害した複数アカウントで OneDrive のWeb UIにログインし、「フォルダ全体をzipダウンロード」機能で 1回のアクションで数千ファイル を持ち出しました。複数アカウントを使う理由は単純で「アカウントごとに見えるフォルダ・共有が違う」ためです。SharePoint Online の共有ドキュメントも同様に取得されています。

2つ目はAzure Storage側で、攻撃者はストレージアカウントのネットワークアクセス設定を改変し、「storageAccounts/listKeys」操作で Shared Access Signature（SAS）トークン を取得しました。SASは「鍵を渡すと指定期間どこからでもアクセスできる」仕組みで、いったん発行されればMFAも条件付きアクセスも効きません。攻撃者はカスタムPythonスクリプトで数日かけて大量データを系統的にダウンロードし、並行してSQL Serverのファイアウォール規則を書き換えてSQL経由のデータ取得も実施しました。

検知側の論点は3つです。

・OneDrive異常ダウンロード: Microsoft 365 監査ログの「FileDownloaded」イベントを集計し、ユーザー単位・時間窓単位で「平常時の10倍以上」を即時アラート
・SAS発行異常: Azure Activity Logs の「listKeys」「Storage Account Key 取得」を全件SIEM転送、新規SAS発行を即時通知
・SQL FW書換え: Azure Activity Logs の「microsoft.sql/servers/firewallrules/write」を最優先アラート、特に「0.0.0.0/0」「1.0.0.0/0.0.0.0」のような広範IP許可は自動ブロック

SOC初動48時間プレイブック：封じ込めの順序

「もし自社で同様の侵害シグナルを検知したら」という前提で、SOC初動48時間に踏むべき手順を順序立てて整理します。経験上、ID侵害インシデントは「順序を間違えると攻撃者を取り逃がす」典型ケースなので、優先度を明示します。

・0～2時間（封じ込め）: 侵害疑いユーザーをEntra IDで即時ブロック（Sign-in blocked）、リフレッシュトークン全失効（Revoke-AzureADUserAllRefreshToken相当）、Azure RBAC 割り当てから一時的に剥奪
・2～6時間（影響範囲特定）: 過去30日のSign-in Logs・Audit Logs を侵害ユーザー単位で抽出、SSPR起動履歴・認証方法変更履歴・Graph API呼び出し履歴を時系列で並べ、関連するセッショントークン・SP認証情報を全失効
・6～12時間（連鎖侵害確認）: 侵害ユーザーの「最近のSign-in IP」「アクセスしたサブスクリプション・リソース」を起点に、同IPからアクセスされた他ユーザー・同サブスクリプションでの異常Activity Logsを横展開で調査
・12～24時間（シークレット全回転）: 侵害サブスクリプション配下のKey Vault シークレット・App Service 発行プロファイル・Storage Account Key・SQL認証情報をすべて回転、関連SASトークンを全失効
・24～36時間（VM/PaaS残置物確認）: 侵害サブスクリプションのVM全台でWindowsイベントログ・Defender Tamper Protection状態を確認、不審なRMMバイナリ（ScreenConnect等）・予期しないVM拡張機能を洗い出し
・36～48時間（再発防止）: 特権ロール保持者にフィッシング耐性MFA強制、SSPRの認証方法変更時の管理者承認・通知設定、Run Command/VMAccessのRBAC制限、Key Vault公開アクセス無効化＋purge protection有効化

検知ルール側で「踏まれた瞬間に違和感が出る」シグナルとして、Microsoft Sentinelで使えるKQLパターンを3つ挙げます（実装はテナントに合わせて調整してください）。

# パターン1: 同一ユーザーが短時間でMFA方法を「削除→追加」した検知
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName in ("Delete authentication method", "Register authentication method", "User registered security info")
| summarize Events = make_list(OperationName), Count = count() by TargetUser = tostring(TargetResources[0].userPrincipalName), bin(TimeGenerated, 30m)
| where Count >= 2 and Events has "Delete authentication method" and Events has "Register authentication method"

# パターン2: Key Vault シークレットread が短時間で急増した検知
AzureDiagnostics
| where ResourceType == "VAULTS"
| where OperationName == "SecretGet"
| summarize SecretReads = count() by CallerIPAddress, identity_claim_upn_s, bin(TimeGenerated, 5m)
| where SecretReads >= 10

# パターン3: Azure Storage SAS発行（listKeys）の異常検知
AzureActivity
| where TimeGenerated > ago(1d)
| where OperationNameValue == "MICROSOFT.STORAGE/STORAGEACCOUNTS/LISTKEYS/ACTION"
| project TimeGenerated, Caller, CallerIpAddress, ResourceGroup, Resource, ActivityStatusValue

KQLはあくまでサンプルで、しきい値や除外ユーザー（バックアップ運用アカウント等）は自社環境で調整が必要です。重要なのは 「攻撃者が必ず通る正規API呼び出し」を最初に検知シグナル化する という発想で、Storm-2949の場合は ①認証方法変更、②Key Vault大量read、③SAS発行、の3点を最低限カバーしておくと、同種攻撃の早期発見につながります。

恒久対策：Storm-2949型攻撃に強いテナント設計の8項目

48時間プレイブックで火を消したあと、再発させない恒久対策を「8つのテナント設計ポイント」として整理します。優先順位はMSTIC推奨と現場運用の現実解を加味して並べました。

第1に、特権ロール保持者へのフィッシング耐性MFA強制。FIDO2セキュリティキーまたはWindows Hello for Businessを必須化し、SMS/電話/通常Authenticatorは特権ロールでは認証方法から除外します。条件付きアクセスポリシーで「Directory Roles=Privileged」スコープに対して「Authentication Strength=Phishing-resistant MFA」を強制適用するのが定型実装です。

第2に、SSPRと認証方法管理の運用見直し。SSPRを完全無効化するのは現実的でない組織が多いので、（1）特権ロール保持者はSSPR対象外、（2）認証方法の追加・削除には管理者承認またはユーザー本人への即時メール＋プッシュ通知、（3）認証方法削除イベントは全件SIEMへ転送、を最低ラインとします。

第3に、条件付きアクセスの「除外リスト」定期棚卸し。例外として除外リストに入ったユーザーが、いつの間にか特権ロール保持者になっているケースが現場では頻発します。月次で除外リスト×ロール割り当てのクロス突合を自動化し、特権ロール保持者が除外されていれば即アラート。

第4に、Key Vault の防御3点セット。（1）公開ネットワークアクセス無効化＋プライベートエンドポイント、（2）purge protection有効化、（3）アクセスポリシーモデル → RBACモデルへ統一、を全Key Vaultに適用。Soft Delete無効のKey Vaultは即時棚卸し対象です。

第5に、Azure Storage SASの監視と制限。User Delegation SASへの統一、Stored Access PoliciesでSASに即時失効の余地を残す、Account Key発行を「Storage Account Key Operator Service Role」に限定し利用時は即時SIEM通知。

第6に、SQL FW・Storage FWの最優先アラート化。「microsoft.sql/servers/firewallrules/write」「microsoft.Storage/storageAccounts/write（networkAcls変更）」のActivity LogsをP1優先度で扱い、0.0.0.0/0開放は自動ロールバック。

第7に、Run Command/VMAccess/Custom Script Extensionの厳格制限。これらの操作は「Azure VM Contributor」「Virtual Machine Administrator Login」相当のロールに集中し、PIM（Privileged Identity Management）でJust-In-Time承認、実行時はSOCに即時通知。

第8に、Microsoft Graph API異常呼び出しの検知。Entra ID のSign-in Logsから「Microsoft Graph PowerShell」「Azure CLI」等のクライアントアプリ単位で、ユーザー/SP列挙系API呼び出しの異常頻度を検知。Sentinel のFusionルールやUEBAで「短時間に大量のGraph API呼び出し」を学習・検知させるのが現実解です。

FAQ：現場のSOC・情シスから出る疑問

まとめ：Living-off-the-Cloud時代の防御は「正規操作の異常検知」で決まる

Storm-2949の事例が示したのは、攻撃者がもはやマルウェアを必要としていないという厳しい現実です。Microsoft Graph API・Azure RBAC・Run Command・VMAccess・Kudu Console・Key Vault・OneDrive Web UI──すべて正規の管理プリミティブで、IT管理者が日常的に使う操作で侵害が完結します。

防御側のロジックも、ここで一段アップデートが必要です。「マルウェア検知」「シグネチャ検知」だけでは届かず、「正規操作のなかから異常パターンを掘り出す」 アプローチに重心を移す必要があります。具体的には、（1）認証方法変更イベント、（2）Key Vault大量read、（3）Storage Account Key/SAS発行、（4）VMへのRun Command/拡張機能追加、（5）OneDrive一括ダウンロード、の5つを最低限「即時アラート対象」に格上げすることが、Storm-2949型攻撃への第一防衛線です。

48時間プレイブックで火を消し、8つのテナント設計ポイントで再発を防ぐ。この2段構えを「自社のテナントに対して具体的にどう実装するか」を、SOC内で検証する材料として本記事を使っていただければと思います。クラウド側の運用実装の詳細は、姉妹サイトクラウドマスターズ.TOKYO「Storm-2949クラウドID侵害事例に学ぶ｜CSPM/IAM運用の見直しポイントと最小権限の実装パターン」で、CSPM運用と最小権限実装の観点から扱っています。攻撃手口側を本記事で押さえ、運用実装側を姉妹サイトで補完する読み方をおすすめします。

【一次情報】
Microsoft Security Blog「How Storm-2949 turned a compromised identity into a cloud-wide breach」（2026年5月18日、Microsoft Threat Intelligence）／SOC Prime Active Threats解説記事（2026年5月18日）