侵害されたサービスプリンシパルで復旧を刈り取る——Storm-3168が突いた“クラウドIDの死角”

今日の深掘りポイント

• ワークロードID（サービスプリンシパル）が「MFAの効かない最短路」になっており、破壊の初手として狙われやすいです。
• 攻撃はデータ窃取に留まらず「復旧阻害（バックアップ無力化）」まで踏み込み、事業継続の前提を奪う設計です。
• テレメトリは短時間・高頻度の読み取りと、破壊/資格情報収集アクションの反復を示し、検知の糸口が明確です。
• 同一テナント内で複数サービスプリンシパルを用いる運用妨害型の手口は、横持ち・冗長化を意図した可能性が高いです（仮説です）。
• 対策は「鍵をなくす」方向（Managed Identityやフェデレーション）と「消せない」方向（不変化・多者承認・ロック）の二軸で設計するべきです。

はじめに

Storm-3168（別名 JADEPUFFER）によるAzure環境への破壊的キャンペーンが確認されました。侵害されたサービスプリンシパルを使って環境をマッピングし、重要リソースやストレージアカウントを削除、さらに復旧の保護策そのものを狙う挙動が観測されています。クラウドが基盤化した現在、これは単なるインシデントではなく「復元力」を直接に断つ攻撃の青写真です。CISOやSOCに求められるのは、高度な脅威インテリジェンスより前に、クラウドIDと復旧機構の“設計の前提”を見直す決断だと強く感じます。

深掘り詳細

事実整理（報道・公開情報ベース）

• 攻撃者は、同一Azureテナント内の2つのサービスプリンシパルを用いました。
• 約15時間の間に300回以上の成功した読み取り操作を実行しました。
• 破壊もしくは認証情報収集に該当するアクションを150回以上試みました。
• ストレージアカウントの認証情報を取得し、最終的にAzureストレージアカウントを削除、復旧能力を弱体化させる行動を取りました。
  （以上はいずれも公開要約の事実関係です。）

インサイト：ワークロードIDが「最後の弱点」になる理由

• サービスプリンシパルは人ではなくアプリが使うIDのため、MFA等の人中心制御をバイパスしやすいです。長寿命のシークレットや過大なRBACが混在しやすく、棚卸しの盲点になりがちです。
• 破壊行為の前段で「読み取りを重ねる」動きは、管理プレーンとデータプレーン双方の列挙・状態確認に重心があることを示します。ここで得た「何が消せば効くか」の知識が、その後の復旧阻害につながったと読むべきです。
• 同一テナントから複数のサービスプリンシパルを使うのは、片方の検知・失効に備えた冗長化、あるいは権限の使い分けを意図した可能性があります（仮説です）。一度テナントのワークロードID管理が破られると、横持ちと持久戦に移行しやすい構図です。

監視と検知の糸口（実装のヒント）

• 「短時間に集中する大量のRead」と「権限・保護の変更や削除」のシーケンスは強い兆候になります。具体的には、リソース列挙、キー/トークンの取得、保護設定の無効化・ポリシー変更、リソース削除の順で連続するパターンです。
• ストレージでは account-level keys の取得やSAS発行、バージョニング/ソフトデリート/不変ポリシーの変更、アカウント削除などの管理プレーン操作を相関させると誤検知を抑えながら高感度に捉えやすいです。
• サービスプリンシパルごとに「所有してよい操作」と「通常の操作レート」をベースライン化し、逸脱（異常な時刻帯・リージョン・APIセット・レート）を検知する運用が効きます。

脅威シナリオと影響

以下はMITRE ATT&CKに沿った仮説シナリオです。事実として確認されていない部分は推測であることを明記します。

• シナリオA：ワークロードIDからの破壊・復旧阻害

  • 初期アクセス：Valid Accounts（T1078.004：Cloud Accounts）— 侵害済みサービスプリンシパルを使用します。
  • 発見：Cloud Service Discovery（T1526）— サブスクリプション/リソースの列挙を行います。
  • 認証情報奪取（推測）：Unsecured Credentials（T1552）— Storage account keys/SAS等の資格情報取得を狙います。
  • 影響：Data Destruction（T1485）— ストレージアカウントやデータの削除を実行します。
  • 復旧阻害：Inhibit System Recovery（T1490）— バックアップ/バージョニング/不変化等の保護を無効化または削除します。
  • 防御回避：Impair Defenses（T1562）— ログ/アラートやポリシー設定の弱体化を試みます（仮説です）。
  • 影響評価：データ消失とSLA崩壊、RTO/RPOの悪化、対外的信頼失墜が直撃します。

• シナリオB：同一テナント内の多重侵害と横持ち（仮説）

  • 永続化/権限操作：Account Manipulation（T1098）やCreate Cloud Account（T1136.003）— 追加の役割付与や新規アプリ登録の作成を行い、冗長な侵害経路を確保します（仮説です）。
  • 目的：片系統の失効や検知に備えた継戦能力の確保、監査の撹乱です。
  • 影響：封じ込めの難易度が跳ね上がり、インシデント対応の時間軸が長期化します。

• シナリオC：資格情報収集からの二段攻撃（仮説）

  • データアクセス：Data from Cloud Storage（T1530）— 取得したSAS/Keysでデータ吸い上げを実施します（仮説です）。
  • 破壊へ移行：足跡隠蔽や身代金圧力のために、最終段で削除・復旧阻害に切り替えます。
  • 影響：情報漏えいと事業継続阻害が同時多発し、広報・法務・規制対応の複合危機となります。

総じて、本件は「クラウドIDの脆弱性」と「復旧機構の脆弱性」を直列につないだ攻撃です。緊迫度と実行可能性の両面が高く、迅速な体制見直しが必要です。

セキュリティ担当者のアクション

優先度順に、実行可能なアクションを整理します。

• 直ちに（0〜24時間）

  • 侵害が疑われるサービスプリンシパルの無効化、資格情報（シークレット/証明書/SAS/アカウントキー）の即時失効・ローテーションを実施します。
  • Azure Activity/監査ログとストレージの管理プレーン/データプレーンログを横断相関し、「大量の読み取り→保護変更→削除」の連続パターンを緊急探索します。
  • 重要ストレージ/バックアップ/Key Vaultに対してリソースロック（削除不可）や多者承認/保護機構（利用可能な場合）を強制します。
  • 共有キーアクセス（AllowSharedKeyAccess）を許容しているストレージがあれば、短期的に利用最小化し、ユーザ委任SASやAzure ADベースの認可へ移行計画を切り出します。

• 短期（48〜72時間）

  • 全サービスプリンシパル棚卸し：所有者・付与ロール・認証方式・資格情報の年齢・最終使用時刻を可視化し、最小権限へ是正します。所有者ロールの一律排除とカスタムロールの細粒度化を進めます。
  • 長寿命シークレット撤廃の計画を立案し、Managed IdentityやOIDCフェデレーションへの移行方針を確定します。
  • バックアップの独立性を検証します。論理的に分離された保護（不変WORM、バージョニング、削除保持、Key VaultのPurge Protection等）を監査し、欠落を即時是正します。
  • 検知ルールを導入します。サービスプリンシパル単位のレート逸脱、listKeys/SAS発行、保護設定の変更、連続削除を相関検知するアナリティクスを有効化します。

• 中期（30〜90日）

  • ポリシー強制（Azure Policy/Initiatives）：ストレージのバージョニング/ソフトデリート/不変化の既定有効化、Key Vaultの削除保護、バックアップ資産の削除制御と多者承認（Resource Guard等、利用可能な場合）の適用を組織横断で必須化します。
  • 変更権限の分離と多者承認：バックアップ保持や保護無効化、ロール割当、アプリ登録変更など「復旧に直結する操作」は人・組織・サブスクリプションを跨いだ分離を徹底します。
  • ブレークグラス設計：緊急時の回復用ID（オフライン保管）の定義、運用手順の訓練を行います。

• 継続KPI（運用モニタリング）

  • サービスプリンシパル総数に占めるOwner/Contributor保有率、長寿命シークレット比率、最終使用から一定期間未使用のワークロードID比率を月次で可視化します。
  • 「読み取り集中→保護変更→削除」の検知から封じ込めまでの平均時間（MTTD/MTTR）をRTO/RPOと結び付けて改善します。
  • 定期的なゲームデイ演習（ストレージアカウント削除前提の復旧演習）で、隔離・復元の筋肉を鍛えます。

最後に、この種の攻撃に対する唯一の“銀の弾丸”はありません。鍵を減らし（Managed Identity/フェデレーション）、消しづらくし（不変化・多者承認・ロック）、見逃さない（相関検知・ベースライン）の三位一体で、復旧力を攻撃者より速く設計していくしかないと考えます。今日の判断が、来月の危機管理を救います。

参考情報

• 二次情報（速報）：Storm-3168 Hackers Abuse Compromised Service Principals in Destructive Azure Campaign (GBHackers)
  本稿は公開情報に基づく速報分析です。一次情報の詳細が公開され次第、内容を更新します。