クラウド型ランサムウェアへと進化する Storm-0501 の手口

Storm-0501-featured image

By マイクロソフトセキュリティチーム 


※本ブログは、米国時間 2025 年8 月 27 日に公開された “Storm-0501’s evolving techniques lead to cloud-based ransomware” の抄訳を基に掲載しています。
 
マイクロソフト セキュリティ チームは、金銭目的の脅威アクター Storm-0501 が、クラウド型の戦術、手法、手順(TTP)に一層注力するようにキャンペーンを継続的に進化させていることを確認しています。 この脅威アクターは、ハイブリッド クラウド環境を標的としてきたことで知られていますが、現在では、オンプレミスのエンドポイントにランサムウェアを展開する手法から、クラウド型ランサムウェアの戦術へと主な目的を移行しています。 

従来のオンプレミス型ランサムウェアでは、脅威アクターが侵害されたネットワーク内のエンドポイント全体にマルウェアを展開して重要なファイルを暗号化し、その後復号キーの交渉を行うのが一般的でしたが、クラウド型ランサムウェアでは根本的な変化が見られます。Storm-0501 はクラウドネイティブ機能を活用し、大量のデータを迅速に流出させ、被害者環境内のデータやバックアップを破壊し、マルウェアの従来型展開に依存することなく身代金を要求します。 

Storm-0501 の標的選定は機会的です。この脅威アクターは、2021 年に米国の学区を標的とした攻撃で Sabbath ランサムウェアを初めて展開しました。2023 年 11 月には、医療分野を標的としました。その後も複数回にわたりランサムウェアの種類を変えており、2024 年の攻撃では Embargo ランサムウェアを使用しています。

2024 年 9 月、マイクロソフトは、Storm-0501 がオンプレミス型ランサムウェアの活動をハイブリッド クラウド環境へと拡大した手口を詳述したblog を公開しました。この脅威アクターは、Active Directory 環境を侵害することで足がかりを得た後、Microsoft Entra ID に軸足を移し、ハイブリッドおよびクラウド ID の権限を昇格させてグローバル管理者権限を取得しました。これらの攻撃の影響フェーズは 2 つの形態のいずれかで実行されました。1 つは、悪意のあるフェデレーション ドメインを追加して Entra ID テナント構成にバックドアを仕込み、ほぼすべてのユーザーとしてサインインできるようにする方法、もう 1 つは、オンプレミス型ランサムウェアを展開してエンドポイントやサーバーを暗号化し、復号キーと引き換えに身代金を要求する方法です。 

Storm-0501 は、オンプレミス環境とクラウド環境を自在に行き来する高度なスキルを引き続き示しており、ハイブリッド クラウドの導入が進む中で脅威アクターがどのように適応しているかを体現しています。 このアクターは、ハイブリッド クラウド環境における管理されていないデバイスやセキュリティ ギャップを狙って検出を回避し、クラウドの権限を昇格させるほか、場合によってはマルチテナント構成内でテナントを横断して目的を達成します。

このブログ記事では、侵害されたクラウド環境に対する最近の Storm-0501 の攻撃による影響について説明します。この脅威アクターが、クラウド環境全体に存在する保護と可視性のギャップを突き、オンプレミスからクラウドへのピボットを通じてクラウド権限を昇格させることで、クラウド型ランサムウェアによる影響をどのように実現したかを追跡しています。このような攻撃がどのように行われるかを理解することは、クラウド環境を保護するうえで極めて重要です。以下では、クラウド ID やクラウド リソースの保護強化を含む保護および緩和策、ならびにマイクロソフトのセキュリティ ソリューション全体にわたる検出ガイダンスを紹介し、組織がこうした攻撃に対してネットワークを強化できるよう支援します。

Figure 1. Overview of Storm-0501 cloud-based ransomware attack chain 800x
図 1. Storm-0501 によるクラウド型ランサムウェア攻撃チェーンの概要

オンプレミス環境の侵害とクラウドへのピボット 

最近のキャンペーンにおいて、Storm-0501 は複数の子会社から構成される大規模な企業を侵害しました。各子会社は独自の Active Directory ドメインを運用しており、これらのドメインはドメイン信頼関係によって相互接続されているため、ドメインをまたいだ認証やリソースへのアクセスが可能になっています。 

クラウド環境も同様に複雑です。各子会社はそれぞれ独立した Microsoft Azure テナントを保持しており、Microsoft Defender 製品の導入状況も異なっていました。特に注目すべき点として、Microsoft Defender for Endpoint が導入されていたのは 1 つのテナントのみであり、複数の Active Directory ドメインに属するデバイスがこの単一のテナントのライセンスにオンボードされていました。このような断片的な導入により、環境全体の状況が把握しにくくなっていました。 

Active Directory ドメインは Entra Connect Sync サーバーを使用して複数の Entra ID テナントと同期されており、1 つのドメインが複数のテナントに同期される場合もあったため、ID 管理と監視がさらに複雑になっていました。本ブログでは、攻撃の影響を受けた 2 つのテナント、すなわちオンプレミスでの活動が確認されたテナントと、クラウドベースの活動が行われたテナントに焦点を当てて説明します。 

Figure2 Storm 0501 on premises attack chain
図 2. Storm-0501 によるオンプレミス攻撃チェーン

オンプレミスでの活動 

このブログでは、オンプレミス攻撃における侵害後フェーズに分析の焦点を当てています。これは、脅威アクターがすでに標的のドメインでドメイン管理者権限を取得していたことを意味します。 Storm-0501 tactics in on-premises environments についてのより包括的な概要は、以前のブログをご覧ください。 

環境全体における Microsoft Defender for Endpoint の導入が限定的であったことにより、検出能力が大きく制限されていました。侵害された複数のドメインのうち、Defender for Endpoint が十分に導入されていたのは 1 つのドメインのみであり、ネットワークの一部は監視されていない状態でした。Storm-0501 の活動が確認された一部のオンボード済みデバイスでは、脅威アクターが悪意のある操作を実行する前に偵察を行っていたことが確認されました。具体的には、脅威アクターは以下のコマンドを使用していました。 

sc query sense 
sc query windefend 

脅威アクターは Defender for Endpoint サービスの有無を確認しており、オンボードされていないシステムを標的にすることで検出を回避しようとする意図的な行動が示唆されます。このことは、エンドポイント全体を包括的にカバーすることの重要性を浮き彫りにしています。 

ラテラルムーブメント(水平移動)は  Evil-WinRM を使用して実行されました。これは、Windows Remote Management(WinRM)上で PowerShell を利用してリモートコードを実行するポストエクスプロイトツールです。前述のコマンドは、このツールで開始されたセッション上で実行されており、quser.exe や net.exe など、他の一般的な Windows のネイティブツールやコマンドによる探索も行われていました。攻撃の初期段階では、Defender for Endpoint にオンボードされていない Entra Connect Sync サーバーが脅威アクターによって侵害されていました。このサーバーがピボットポイントとして機能し、脅威アクターがネットワーク内を水平移動するためのトンネルを確立したと考えられます。 

脅威アクターは DCSync 攻撃も実行しました。これは、Directory Replication Service(DRS)リモートプロトコルを悪用して、ドメイン コントローラーの動作を模倣する手法です。ドメインコントローラーになりすますことで、脅威アクターはドメイン内の任意のユーザー、特権アカウントを含むユーザーのパスワードハッシュを要求することが可能になります。この手法は、従来の認証ベースのアラートを回避しながら認証情報を抽出するためによく使用されます。 

クラウドへのピボット 

 最初のテナントがオンプレミス環境で侵害された後、脅威アクターは Entra Connect Sync の Directory Synchronization Account(DSA)を利用して、テナント内のユーザー、ロール、および Azure リソースを列挙しました。  この偵察には Azure 環境における関係性とアクセス許可をマッピングし、潜在的な攻撃経路や権限昇格の可能性を特定するために設計されたツールである AzureHound が使用されました。 

その直後、脅威アクターは複数の特権ユーザーとしてのサインインを試みましたが、条件付きアクセス ポリシーおよび多要素認証 (MFA) 要件によってブロックされ、失敗に終わりました。このことから、Storm-0501 は有効な認証情報を保持していたものの、必要な第 2 要素を欠いていたか、ポリシー条件を満たすことができなかったと考えられます。 

それでもひるむことなく、Storm-0501 は阻止されることなく戦術を変更しました。Active Directory 環境で得た足がかりを活用し、複数の Active Directory ドメイン間を移動した後、別の Entra ID テナントおよび Active Directory ドメインに関連付けられた 2 台目の Entra Connect サーバーを水平移動をして侵害しました。脅威アクターは Directory Synchronization アカウントを抽出し、偵察プロセスを再実行しました。今回は、2 つ目のテナント内の ID とリソースを標的としました。 

ID 権限の昇格 

脅威アクターは、オンプレミス環境の制御を利用して Active Directory ドメイン間をピボットし、クラウド リソースを広範囲に列挙した偵察フェーズの結果として、組織のセキュリティ体制に関する重要な可視性を獲得しました。その後、対象のテナントにおいて、Microsoft Entra ID のグローバル管理者ロールが割り当てられている非人間の同期済み ID を特定しました。さらに、このアカウントには登録済みの MFA 手段が存在していませんでした。これにより、脅威アクターはそのユーザーのオンプレミス パスワードをリセットすることが可能となり、その後すぐに Entra Connect Sync サービスを通じて、そのユーザーのクラウド ID に正規の手段で同期されました。このパスワード変更は、Entra Connect の Directory Synchronization Account(DSA)によって実行されたことが確認されており、Entra Connect Sync サービスが最も一般的なモードである パスワード ハッシュ同期(Password-Hash Synchronization, PHS)で構成されていたためです。その結果、脅威アクターは新しいパスワードを使用して、そのユーザーとして Entra ID に対して認証を行うことが可能となりました。 

そのユーザーには MFA が登録されていなかったため、新たに設定されたパスワードで認証に成功した脅威アクターは、自身の管理下にある新しい MFA 手段を登録するように誘導されました。以降、侵害されたユーザーには MFA が登録された状態となり、脅威アクターは MFA 条件を満たし、リソースごとに構成された顧客の条件付きアクセス ポリシーに準拠できるようになりました。 

侵害されたグローバル管理者アカウントを使用して Azure ポータルにアクセスするために、脅威アクターはそのリソースに対して条件付きアクセス ポリシーで適用されていたもう 1 つの条件を回避する必要がありました。それは、Microsoft Entra のハイブリッド参加済みデバイスから認証が行われることを要求するものでした。ハイブリッド参加済みデバイスとは、Active Directory ドメインと Entra ID の両方に参加しているデバイスです。条件付きアクセスの条件を満たしていない、ドメイン参加済みまたは Entra 参加済みの社内デバイスからの認証試行が失敗している様子が確認されました。脅威アクターはネットワーク内の複数のデバイス間を水平移動し、最終的にハイブリッド参加済みのサーバーからグローバル管理者アカウントによる Azure ポータルへのサインインが成功したことが確認されました。 

条件付きアクセス ポリシーを満たし、Global Admin アカウントとして Azure ポータルにサインインすることに成功した時点で、Storm-0501 はクラウド ドメインを完全に制御できる状態となっていました。その後、攻撃者はクラウド上で可能な限り最高レベルの権限を利用して、目的の達成を図りました。

図 3. Storm-0501 によるクラウド ID とクラウド環境の侵害、それに伴う恐喝行為  

Entra ID におけるクラウド ID の侵害 

クラウド環境の永続的なアクセスの確保 

テナントに対して Global Admin としての認証に成功した後、Storm-0501 は直ちに永続性のメカニズムを確立しました。 過去の攻撃活動でも確認されているように、Storm-0501 は悪意のあるフェデレーション ドメインを追加することでbackdoorを作成し、ImmutableId (変更不可な一意 ID) ユーザー プロパティに基づいて、ほぼ任意のユーザーとしてサインインできる状態を実現しました。攻撃者は、Global Administrator の Entra ロールの権限と AADInternals ツールを活用し、攻撃者が所有する Entra ID テナントを、標的となるテナントから信頼されたフェデレーション ドメインとして登録しました。2 つのテナント間の信頼関係を確立するために、攻撃者が生成したルート証明書が被害テナントに提供され、それが攻撃者所有のテナントからの認証要求を許可するために使用されます。このbackdoorにより、Storm-0501 は被害テナントに対して有効な SAML(Security Assertion Markup Language)トークンを作成し、被害テナント内のユーザーになりすまして、そのユーザーが持つ Microsoft Entra ロールを引き継ぐことが可能となりました。 

クラウドの侵害:Azure 

Azure における初期アクセスと権限昇格 

テナントの Entra ID と Azure 環境は密接に連携しています。Storm-0501 は Entra ID における最上位の権限を取得したことで、最終的な目的であるクラウドベースのランサムウェア手法を用いた金銭的利益の獲得に向けて行動を進めることが可能となりました。この目的を達成するために、攻撃者は組織の重要なデータ ストアを特定する必要がありました。そして、それらはクラウド、つまり Azure 上に存在していました。

 攻撃者が Microsoft Entra のグローバル管理者権限を持つユーザーを侵害していたため、Azure 環境に侵入するために必要な操作は、Azure リソースへのアクセス権を昇格させることだけでした。攻撃者はMicrosoft.Authorization/elevateAccess/action 操作を実行することで、Azure リソースへのアクセス権を昇格させました。この操作により、組織が所有するすべての Azure サブスクリプションに対して ユーザー アクセス 管理者権限を取得し、それらに保存されている重要なデータにもアクセス可能となりました。 

環境内で自由に操作を行うために、攻撃者はMicrosoft.Authorization/roleAssignments/write 操作を実行し、利用可能なすべての Azure サブスクリプションに対して自らに所有者権限を割り当てました。 

調査 

組織の Azure 環境を掌握した後、攻撃者は AzureHound ツールの使用を含む複数の手法を用いて、包括的な調査フェーズを開始したと考えられます。このフェーズでは、機密情報を含むデータ ストアや、オンプレミスおよびクラウドのエンドポイント デバイスのバックアップを目的としたデータ ストア リソースなど、組織の重要な資産の特定を試みました。攻撃者は Azure 環境の構造を把握し、Azure ポリシーリソース ロックAzure Storage のイミュータビリティ ポリシーなど、既存の環境保護機能についても理解を深めました。 

防御回避 

その後、攻撃者は組織の Azure Storage アカウントを標的にしました。Storm-0501 は Azure Storage のパブリック アクセス機能を利用して、外部からアクセスできないアカウントをインターネットおよび自身のインフラストラクチャに公開し、データの持ち出しフェーズへの道を開きました。この操作は、Azure Storage のパブリック アクセス機能を活用することで実現されました。攻撃者は Azure Storage アカウントのリソースを変更するために、Microsoft.Storage/storageAccounts/write 操作を悪用しました。 

資格情報へのアクセス 

Azure Storage アカウントでキー アクセスが有効になっている場合、攻撃者は Azure の所有者権限を悪用して、Microsoft.Storage/storageAccounts/listkeys/action 操作を実行し、アクセス キーを取得して、持ち出しました。 

データの持ち出し(Exfiltration) 

攻撃者は Azure Storage アカウントを外部に公開した後、AzCopy コマンドライン ツール(CLI)を悪用して、これらのアカウント内のデータを自身のインフラストラクチャへ持ち出しました。 

影響 

オンプレミス型のランサムウェア攻撃では、攻撃者は通常、できる限り多くのエンドポイント上の重要なファイルを暗号化するマルウェアを展開し、復号キーの提供を条件に被害者と交渉します。 一方、クラウドベースのランサムウェア攻撃では、クラウドの機能と特性により、攻撃者は被害者の環境から大量のデータを迅速に持ち出して自身のインフラストラクチャへ送信し、被害者のクラウド環境内のデータやバックアップ リソースを破壊したうえで、身代金を要求することが可能になります。 

Storm-0501 はデータの持ち出しフェーズを完了した後、被害組織のデータが保存されている Azure リソースの大量削除を開始しました。これにより、被害者がデータの復元によって復旧や緩和措置を講じることを妨げました。この操作は、複数の Azure リソース プロバイダーに対して以下の Azure 操作を悪用することで実行されました。 

  • Microsoft.Compute/snapshots/delete – Azure Snapshot を削除します。これは Azure VM のディスク(VHD)の読み取り専用の時点コピーであり、特定の瞬間の状態とデータを保持するもので、元のディスクとは独立して存在し、そのディスクのバックアップやクローンとして使用できます。 
  • Microsoft.Compute/restorePointCollections/delete –  Azure VM Restore Point を削除します。これは、仮想マシン(VM)の構成と、VM に接続されたすべてのマネージド ディスクのアプリケーション整合性のある時点スナップショットを保存するものです。 
  • Microsoft.Storage/storageAccounts/delete –  Azure storage アカウント を削除します。これは、組織の Azure Storage データ オブジェクト(Blob、ファイル、キュー、テーブル)を含むアカウントです。Storm-0501 が実行したすべての Azure キャンペーンにおいて、主にこの操作に焦点を当て、環境内のできる限り多くの Azure Storage アカウント リソースを削除しました。 
  • Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/delete – Azure Recovery Services の Vault 保護コンテナーを削除します。保護コンテナーは、仮想マシン(VM)やワークロードなどのリソースを論理的にグループ化したもので、 Recovery Services vault 内で一括してバックアップすることができます。 

攻撃者がデータ ストアやそれを保持するリソースを大量削除しようとした際、環境に存在する保護機能によって一部のリソースの削除に失敗し、エラーが発生しました。 これらの保護機能には、Azure リソース ロックや Azure Storage のイミュータビリティ ポリシーが含まれます。 その後、攻撃者は以下の操作を悪用して、これらの保護機能の削除を試みました。

  • Microsoft.Authorization/locks/delete Azure リソース ロックを削除します。これは、Azure サブスクリプション、リソース グループ、またはリソースの誤った削除や変更を防ぐために使用される保護機能です。このロックは、ユーザーのアクセス許可を上書きして動作します。 

攻撃者は複数の Azure リソース ロックおよび Azure Storage のイミュータビリティ ポリシーの削除に成功した後、Azure データ ストアの大量削除を継続し、さまざまな Azure サブスクリプション内のリソースを完全に消去しました。 一部のリソースがイミュータビリティ ポリシーによって保護されたままであった場合、攻撃者はクラウドベースの暗号化に手段を切り替えました。 

 Storm-0501 はクラウドベースの暗号化を実行するために、新しい Azure Key Vault を作成し、その中に新しいカスタマー管理キー(Customer-managed key)を作成しました。このキーは、Azure Encryption scopes 機能を使用して、残された Azure Storage アカウントを暗号化するために使用されることを目的としています。 

  • Microsoft.KeyVault/vaults/write – Azure Key Vault を新規作成または既存のものを変更します。攻撃者は暗号化キーを格納するための新しい Azure Key Vault を作成します。 
  • Microsoft.Storage/storageAccounts/encryptionScopes/write – Azure Storage暗号化スコープを新規作成または変更します。暗号化スコープは、コンテナーまたは個々の Blob にスコープされたキーによって暗号化を管理するための機能です。暗号化スコープを定義する際には、マイクロソフト管理キーで保護するか、Azure Key Vault に保存されたカスタマー管理キーで保護するかを指定できます。 

攻撃者は Azure Storage の暗号化スコープ機能を悪用し、Azure Storage アカウント内の Blob を暗号化しました。 しかしこれだけでは不十分であり、組織は適切な Azure 権限を持っていれば依然としてデータにアクセス可能でした。 そこで攻撃者は、暗号化に使用されたキーを削除することで、データへのアクセスを不可能にしようと試みました。 ただし、暗号化目的で使用される Azure Key Vault やキーは、マイクロソフトの Azure Key Vault のソフト削除機能によって保護されており、デフォルトで 90 日間の保持期間が設定されています。この機能により、削除されたキーや Vault を復元することが可能となり、ランサムウェア目的のクラウドベース暗号化を防止することができます。 

Storm-0501 は Azure 環境内のデータの持ち出しと破壊に成功した後、恐喝フェーズを開始しました。  このフェーズでは、以前に侵害したユーザー アカウントの 1 つを使用してマイクロソフト Teams 経由で被害者に連絡を取り、身代金を要求しました。 

緩和策と保護に関するガイダンス 

マイクロソフトは最近、Microsoft Entra Connect Sync および Microsoft Entra Cloud Sync における Directory Synchronization Accounts(DSA)ロールの権限を制限する変更を Microsoft Entra ID に実装しました。 この変更により、攻撃者が Directory Synchronization Accounts を悪用して権限を昇格させる攻撃を防止することができます。さらに、2025 年 5 月にリリースされた新バージョンでは、モダン認証が導入されており、アプリケーションベースの認証を構成することでセキュリティを強化できます(現在パブリック プレビュー中)。また、Storm-0501 による資格情報の抽出手法への対策として、Entra Connect Sync サーバーで Trusted Platform Module(TPM)を有効にし、機密性の高い資格情報や暗号キーを安全に保存することも重要です。 

このブログで説明されている脅威アクターによる手法は、次のセキュリティ対策を採用することで軽減できます。

オンプレミス環境の保護 

  • 改ざん防止機能を有効にすると、Microsoft Defender for Endpoint などのセキュリティ サービスを脅威アクターが停止するのを防ぐことができ、Microsoft Entra Connect の悪用など、ハイブリッド クラウド環境への攻撃を防止するのに役立ちます。 
  • エンドポイント検出と応答 (EDR) をブロック モードで実行すると、非マイクロソフト製のウイルス対策ソフトが脅威を検出できない場合や Microsoft Defender Antivirus がパッシブ モードで実行されている場合でも、Defender for Endpoint が悪意のあるアーティファクトをブロックできます。ブロック モードの EDR は、侵害後に検出された悪意のあるアーティファクトをバックグラウンドで修復します。 
  • 調査と修復を完全自動モードで有効にすると、Defender for Endpoint がアラートに対して即座に対応し、アラートの修復を支援することで、アラートの件数を大幅に削減できます。 

クラウド ID の保護 

  • 資格情報の衛生管理によってアカウントを保護します。最小特権の原則を実践し、Microsoft Entra ID や Azure 環境で特権アカウントのアクティビティを監査することで、脅威アクターの動きを遅らせたり阻止したりできます。 
  • 条件付きアクセス ポリシーを有効にします。条件付きアクセス ポリシーは、ユーザーがサインインを試みるたびに評価および適用されます。デバイスのコンプライアンスや信頼済み IP アドレスの要件などのポリシーを有効にすることで、盗まれた資格情報を悪用する攻撃から組織を保護できます。 
    • 条件付きアクセス ポリシーを設定して、Microsoft Entra ID のディレクトリ同期アカウント (DSA) によるすべてのクラウド アプリへのアクセスを、信頼されていない IP アドレスから制限します。該当する IP アドレスを取得するには、「高度なハンティング」セクションを参照し、関連するクエリを確認してください。 
    • アプリケーションベースの認証を使用している Entra Connect Sync サーバーでは、ワークロード ID に対する条件付きアクセスを使用して、アプリケーションのサービス プリンシパルによる同様の不正アクセスを制限します。 
  • すべての既存の特権ユーザーに対して、悪意のある MFA 登録を防ぐために、すでに登録済みの 多要素認証 (MFA) 方法があることを確認してください。 
  • 従業員および外部ユーザーが重要なアプリにアクセスする際に、フィッシング耐性のある認証を必須とするよう、条件付きアクセスの認証強度を実装してください。 
  • 組織で Microsoft Defender for Cloud Apps のコネクタを有効にして、Microsoft Entra ID Directory Synchronization Account およびその他すべてのユーザーに関するアラートを受信できるようにしてください。 
  • Microsoft Entra ID とフェデレーションされている場合に、クラウドの Microsoft Entra MFA をバイパスされないように 保護機能を有効にしてください。これにより、フェデレーション ドメインに対する攻撃からの保護が強化されます。 
  • federatedTokenValidationPolicy validatingDomains プロパティを “all” に設定して、.onmicrosoft.com のような非フェデレーション ドメインへの SAML トークンによるサインイン試行をブロックしてください。 
  • フェデレーション ドメインに対して Microsoft Entra ID のみが MFA を実行する場合は、federatedIdpMfaBehaviorrejectMfaByFederatedIdp に設定して、MFA 条件付きアクセス ポリシーのバイパスを防止してください。 
  • Microsoft Entra ID protection を有効にして、ID ベースのリスクを監視し、リスクに基づく条件付きアクセス ポリシーを作成して、リスクのあるサインインを修復してください。 

クラウド リソースの保護 

  • Microsoft Defender for Cloud のようなソリューションを使用して、ポスチャ管理と脅威検出機能の両面から、クラウド リソースと資産を悪意のあるアクティビティから保護してください。 
  • Defender for Cloud の一部として Microsoft Defender for Resource Manager を有効にすると、組織内のリソース管理操作を自動的に監視できます。Defender for Resource Manager は高度なセキュリティ分析を実行し、脅威を検出して不審なアクティビティを通知します。
    •  Defender for Resource Manager を有効にすると、Defender XDR 内で Azure の管理操作を調査できるようになり、高度なハンティング機能を活用できます。 
  • Azure Monitor activity ログを活用して、Azure の管理イベントを調査および監視してください。 
  • Azure Storage に対して Azure policies を活用することで、ネットワークやセキュリティの構成ミスを防止し、ストレージ アカウントに保存されている業務データの保護を最大化できます。 
  • Azure Blob Storage に対して イミュータブル ストレージを有効にすることで、BLOB やストレージ アカウントの意図しない、または悪意のある変更や削除から保護できます。 
  • Azure Resource Manager のロックを適用して、ストレージ アカウントの意図しない、または悪意のある変更や削除から保護してください。 
  • Azure Blob Storage に対して Azure Monitor を有効にすると、データの収集、集計、ログ記録が可能になり、セキュリティ インシデントの発生時やネットワークが侵害された場合に、アクティビティの追跡を再現するための情報を取得できます。 
  • Defender for Cloud の一部として Microsoft Defender for Storage を有効にした後は、advanced hunting で CloudStorageAggregatedEvents(プレビュー)テーブルを活用して、ストレージに関する悪意のあるアクティビティを積極的に調査してください。 
  • Azure Blob Storage に対して Azure blob backup有効にすることで、BLOB やストレージ アカウントの意図しない、または悪意のある削除から保護できます。 
  • Microsoft Entra と RBAC を使用して Azure Storage の BLOB データへのアクセスを許可する際は、最小特権の原則を適用し、Azure ABAC を通じて機密データへのアクセスに対してきめ細かなアクセス制御を構成してください。 
  • BLOB データに対して 匿名の読み取りアクセスは使用しないでください。 
  • Azure Key Vault のログを有効にし、最大 1 年間保持することで、セキュリティ インシデントの発生時やネットワークが侵害された場合に、アクティビティの追跡を再現できるようにしてください。 
  • Microsoft Azure Backup を仮想マシンに対して有効にすることで、Microsoft Azure 仮想マシン上のデータを保護し、地理的冗長性のあるリカバリ ボールトに保存される復元ポイントを作成できます。 

一般的なセキュリティ衛生に関する推奨事項 

  • マイクロソフト Defender ポータルで利用可能な Microsoft Security Exposure Management を活用してください。このソリューションには、重要資産の保護攻撃経路の分析などの機能があり、セキュリティ チームが Storm-0501 のハイブリッド攻撃手法による影響を軽減し、事前にリスクを低減することが可能です。 この場合、関与する重要資産 — Entra Connect サーバー、DCSync 権限を持つユーザー、Global Administrators — は、関連するアラートや推奨事項によって特定できます。 
  • オンプレミスおよびハイブリッド環境における Microsoft Security Exposure Management の攻撃経路を調査してください。セキュリティ チームは、攻撃経路分析を使用して、Entra Connect サーバーを悪用してクラウド ワークロードにピボットし、権限を昇格させ、影響範囲を拡大するクロスドメインの脅威を追跡できます。セキュリティ チームは、Microsoft Security Exposure Management の攻撃経路ダッシュボードにある「Chokepoint」ビューを使用して、複数の経路に登場するエンティティを強調表示できます。 

Microsoft Defender XDR による検出 

Microsoft Defender XDR を利用しているお客様は、以下に記載された該当する検出リストを参照できます。Microsoft Defender XDR は、エンドポイント、ID、メール、アプリ全体で検出、防止、調査、対応を連携させることで、このブログで取り上げた脅威のような攻撃に対して統合された保護を提供します。 

アクセス権がプロビジョニングされているお客様は、Microsoft Defender 内で Microsoft Security Copilot を使用して、インシデントの調査と対応、脅威のハンティング、関連する脅威インテリジェンスによる組織の保護を行うこともできます。

Threat intelligence reports (脅威インテリジェンス レポート) 

マイクロソフト製品では、脅威アクター、悪意のあるアクティビティ、および本ブログで取り上げた手法に関する最新情報を取得するために、以下のレポートをご利用いただけます。これらのレポートには、インテリジェンス、保護に関する情報、および関連する脅威がお客様の環境で検出された場合の防止、緩和、対応に向けた推奨アクションが含まれています。 

Microsoft Defender XDR threat analytics 

Microsoft Security Copilot をご利用のお客様は、Microsoft Defender Threat Intelligence に統合された Microsoft Security Copilot を使用することで、この脅威アクターに関する詳細情報を取得できます。情報は、Security Copilot のスタンドアロン ポータル、または Microsoft Defender ポータル内の組み込みこまれたエクスペリエンスからアクセス可能です。 

ハンティング クエリ 

Microsoft Defender XDR 

Microsoft Defender XDR をご利用のお客様は、ネットワーク内の関連アクティビティを検出するために、以下のクエリを実行できます。 

 Sign-in activity 

IdentityLogonEvents を使用してサインイン アクティビティを調査し、通常とは異なる動作を確認します。たとえば、初めて確認された IP アドレスからのサインインや、同期とは関係のない新しいアプリケーションへのサインインなどが該当します。 

IdentityLogonEvents
| where Timestamp > ago(30d)
| where AccountDisplayName contains "On-Premises Directory Synchronization Service Account"
| extend ApplicationName = tostring(RawEventData.ApplicationName)
| project-reorder Timestamp, AccountDisplayName, AccountObjectId, IPAddress, ActionType, ApplicationName, OSPlatform, DeviceType

同期アカウントのアクティビティは通常、同じ IP アドレスから同じアプリへの繰り返しの動作です。自然な流れからの逸脱がある場合は、調査する価値があります。マイクロソフト Entra ID の同期アカウントが通常アクセスするクラウド アプリには、Microsoft Azure Active Directory Connect、Windows Azure Active Directory、Microsoft Online Syndication Partner Portal があります。

Cloud activity(クラウド アクティビティ)  

同期アカウントのアクティビティは通常、同じ IP アドレスから同じアプリケーションへの繰り返しの動作で構成されます。自然な動作の流れから逸脱するものは、調査する価値があります。Microsoft Entra ID の同期アカウントが通常アクセスするクラウド アプリケーションには、Microsoft Azure Active Directory Connect、Windows Azure Active Directory、Microsoft Online Syndication Partner Portal があります。 

CloudAppEvents
| where Timestamp > ago(30d)
| where AccountDisplayName has "On-Premises Directory Synchronization Service Account"
| extend Workload = RawEventData.Workload
| project-reorder Timestamp, IPAddress, AccountObjectId, ActionType, Application, Workload, DeviceType, OSPlatform, UserAgent, ISP

異なる DeviceTypes や OSPlatforms からの操作には注意が必要です。このアカウントによる自動サービスは特定の 1 台のマシンから実行されるため、これらのフィールドにばらつきがあることは本来ありません。 

Azure management events 

Defender ポータルの高度なハンティング機能で、新しい CloudAuditEvents テーブルをクエリすることで、Azure の管理イベントを調査できます。OperationName 列には、ユーザーによって実行されたコントロール プレーン イベントの種類が示されます。 

let Storm0501Operations = dynamic([
//Microsoft.Authorization
"Microsoft.Authorization/elevateAccess/action",
"Microsoft.Authorization/roleAssignments/write",
"Microsoft.Authorization/locks/delete",
//Microsoft.Storage
"Microsoft.Storage/storageAccounts/write",
"Microsoft.Storage/storageAccounts/listkeys/action",
"Microsoft.Storage/storageAccounts/delete",
"Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies/delete",
"Microsoft.Storage/storageAccounts/encryptionScopes/write",
//Microsoft.Compute
"Microsoft.Compute/snapshots/delete",
"Microsoft.Compute/restorePointCollections/delete",
//Microsoft.RecoveryServices
"Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/delete",
//Microsoft.KeyVault
"Microsoft.KeyVault/vaults/write"
]);
CloudAuditEvents
| where Timestamp > ago(30d)
| where AuditSource == "Azure" and DataSource == "Azure Logs"
| where OperationName in~ (Storm0501Operations)
| extend EventName = RawEventData.eventName
| extend UserId = RawEventData.principalOid, ApplicationId = RawEventData.applicationId
| extend Status = RawEventData.status, SubStatus = RawEventData.subStatus
| extend Claims = parse_json(tostring(RawEventData.claims))
| extend UPN = Claims["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
| extend AuthMethods = Claims["http://schemas.microsoft.com/claims/authnmethodsreferences"]
| project-reorder ReportId, EventName, Timestamp, UPN, UserId, AuthMethods, IPAddress, OperationName, AzureResourceId, Status, SubStatus, ResourceId, Claims, ApplicationId

リソースとユーザーのエクスポージャ 

Defender ポータルの高度なハンティングで、ExposureGraphNodes テーブルと ExposureGraphEdges テーブルをクエリすることで、Microsoft Security Exposure Management の機能を確認できます。これらのテーブルを活用することで、機密データを含む Azure Storage アカウントや、不変ストレージ ポリシーによって保護されているアカウントなど、重要なアセットを特定できます。すべての定義済みの重要度ルールは、こちらで確認できます: Predefined classifications 

ExposureGraphNodes
| where NodeLabel =~ "microsoft.storage/storageaccounts"
// Criticality check
| extend CriticalityInfo = NodeProperties["rawData"]["criticalityLevel"]
| where isnotempty( CriticalityInfo)
| extend CriticalityLevel = CriticalityInfo["criticalityLevel"]
| extend CriticalityLevel = case(
            CriticalityLevel == 0, "Critical",
            CriticalityLevel == 1, "High",
            CriticalityLevel == 2, "Medium",
            CriticalityLevel == 3, "Low", "")
| extend CriticalityRules = CriticalityInfo["ruleNames"]
| extend StorageContainsSensitiveData = CriticalityRules has "Databases with Sensitive Data"
| extend ImmutableStorageLocked = CriticalityRules has "Immutable and Locked Azure Storage"
// Exposure check
| extend ExposureInfo = NodeProperties["rawData"]["exposedToInternet"]
| project-reorder NodeName, NodeId, CriticalityLevel, CriticalityRules, StorageContainsSensitiveData, ImmutableStorageLocked, ExposureInfo

次のクエリを使用すると、Global Administrator を含む Microsoft Entra の特権権限が割り当てられている重要なユーザーを特定できます。 

ExposureGraphNodes
| where NodeLabel =~ "user"
| extend UserId = NodeProperties["rawData"]["accountObjectId"]
| extend IsActive = NodeProperties["rawData"]["isActive"]
// Criticality check
| extend CriticalityInfo = NodeProperties["rawData"]["criticalityLevel"]
| where isnotempty(CriticalityInfo)
| extend CriticalityLevel = CriticalityInfo["criticalityLevel"]
| extend CriticalityLevel = case(
            CriticalityLevel == 0, "Critical",
            CriticalityLevel == 1, "High",
            CriticalityLevel == 2, "Medium",
            CriticalityLevel == 3, "Low", "")
| extend CriticalityRules = CriticalityInfo["ruleNames"]
| extend GlobalAdministrator = CriticalityRules has "Global Administrator"
| project-reorder NodeName, NodeId, UserId, IsActive, CriticalityLevel, CriticalityRules, GlobalAdministrator

オムリ リファエリ(Omri Refaeli)、カラム アブ ハンナ(Karam Abu Hanna)、アロン マロム(Alon Marom) 

詳細情報 

マイクロソフトの脅威インテリジェンス コミュニティによる最新のセキュリティ調査については、Microsoft Threat Intelligence Blog をご覧ください。新しい公開情報の通知を受け取ったり、SNS 上でディスカッションに参加したりするには、LinkedInX(旧 Twitter)Bluesky でフォローしてください。進化し続ける脅威の状況について、マイクロソフトの脅威インテリジェンス コミュニティによるストーリーやインサイトを聞くには、Microsoft Threat Intelligence podcast をお聴きください。 

———————————

本ページのすべての内容は、作成日時点でのものであり、予告なく変更される場合があります。正式な社内承認や各社との契約締結が必要な場合は、それまでは確定されるものではありません。また、様々な事由・背景により、一部または全部が変更、キャンセル、実現困難となる場合があります。予めご了承下さい。