8,100万件のAzure CLIパスワードスプレー攻撃。攻撃者はMFAを突破しようとはしていなかった――回避していた。
8,100万回のパスワードスプレー攻撃。78件のアカウント侵害。39の組織が被害に。これらは、Huntressが2026年7月1日に発表した、Microsoft Azure環境を標的としたアクティブな攻撃キャンペーンの数字です――しかし、最も重要な数字はこれらではありません。最も重要なのは「ゼロ」、つまり攻撃者がMFA（多要素認証）を一度も発動させなかったという事実です。
このキャンペーンはMFAを破ることを目的としたものではなく、MFA自体を完全に回避することを狙ったものでした。この手法自体は新しいものではなく、セキュリティ研究者によってROPCベースの認証攻撃は以前から報告されていますが、今回の大規模な攻撃とAzure CLIを標的とした点が、レガシー認証フローと最新のアイデンティティ制御が同一のエンタープライズ環境で共存した場合に何が起こるかを示す、最も明確な最近の事例となっています。
Huntressの調査では、攻撃者がResource Owner Password Credentials（ROPC）OAuth 2.0フローを利用し、条件付きアクセス制御やMFA要件を発動させることなく、Azure ADに直接認証した手口が記録されています。なぜこれが可能なのかを理解するには、ROPCとは何か、最新の認証フローとどう異なるのか、そしてMicrosoftがこのプロトコルを非推奨としながらも、なぜ多くのAzureテナントで依然として利用可能なのかを理解する必要があります。
主なポイント
1. Huntressは8,100万回のAzure CLIパスワードスプレー攻撃を記録し、39組織で78件のアカウントが侵害されました。
この攻撃キャンペーンは、Resource Owner Password Credentials（ROPC）と呼ばれるレガシーOAuth 2.0フローを標的とし、認証情報を直接Azure ADに送信することで、最新のMFAや条件付きアクセス制御を完全に回避しています。
2. ROPCはMicrosoftにより非推奨とされていますが、広く利用可能な状態が続いています。
OAuth 2.0のROPCフローは、ブラウザリダイレクトによる認証ができないレガシーシステム向けに設計されました。Microsoftはこれを最新フローへ移行するため非推奨としましたが、多くのAzureテナントで技術的には依然として利用可能なため、攻撃者はMFAや条件付きアクセス制御を発動させずに認証できてしまいます。
3. 条件付きアクセス制御の設定ミスが根本的な原因です。
条件付きアクセス制御を導入している組織でも、特定アプリケーションやユーザーグループ、場所ベースの条件など、ROPCトラフィックが保護されないカバレッジの隙間が残りがちです。Azure CLIはその代表的な例で、ROPC経由で認証された開発者の認証情報が本番リソースに到達するケースが多く見られます。
4. この攻撃パターンは、ポリシーの意図と技術的な適用の間にある認証ギャップを突いています。
多くの組織は、MFAがブラウザベースの認証を保護しているためAzure環境も守られていると考えています。しかしROPC認証は同じフローを通らず、これはMFA自体の脆弱性ではなく、レガシー認証経路が最新の経路と並行して開放されている設定ミスによるものです。
5. 対策にはパスワード管理だけでは不十分です。
ROPC攻撃経路を遮断するには、テナントレベルでレガシー認証プロトコルをブロックし、条件付きアクセス制御のカバレッジギャップを監査し、Azure CLIアクセス権を持つアカウントの認証情報をローテーションし、ROPC認証イベントを異常として検知できるIDおよびアクセス管理制御を実装するなど、複合的な対策が必要です。
自社のセキュリティ、信じていますか？その確証はありますか？
Read Now
ROPCとは何か、なぜ今も存在するのか
OAuth 2.0フレームワークは、用途ごとに複数の認証フローを提供しています。対話型ユーザー認証の最新標準はPKCE付き認可コードフローで、ユーザーをIDプロバイダーにリダイレクトし、そこで認証情報を入力させ、認可コードをアプリケーションに返します。このフローはMFAや条件付きアクセス制御と連携できるのは、認証がIDプロバイダー側で行われるためです。
ROPCは、ブラウザリダイレクトができないレガシーアプリケーション向けの代替手段として設計されました。ユーザーをログインページに誘導する代わりに、アプリケーションが直接認証情報を受け取り、POSTリクエストとしてIDプロバイダーに渡します。認証情報のやり取りはアプリケーション側で完結します。
MicrosoftがROPCを非推奨とした理由は、設計上、最新のセキュリティ制御と両立できないためです。認証情報がIDプロバイダーの認証UIを経由せずアプリケーションを通過するため、MFAをフロー内に挿入できません。条件付きアクセス制御もサインインイベントで発動しません。トークン発行は、IDプロバイダーによる完全な条件付きアクセス評価が完了する前に行われてしまいます。
問題は、非推奨＝無効化ではないことです。ROPCは多くのAzureテナントで依然として利用可能です。Microsoftは顧客を最新認証フローへ移行させていますが、レガシーシステムとの後方互換性のため、ROPCは動作し続けています。Huntressが記録した今回の攻撃キャンペーンでは、攻撃者はAzureリソースへのアクセス権を持つ一般的な開発者ツールであるAzure CLIを標的に、ROPC認証を利用しました。多くの組織が明示的にブロックしていないためです。認証プロトコルカバレッジの正式なリスク評価――特に、どのレガシーフローがどのアプリケーションスコープで有効になっているかをマッピングすること――が、この種のギャップを侵害に至る前に塞ぐための出発点となります。
実際の攻撃の流れ
Huntressが記録したキャンペーンは、典型的なパターンに従っています。まず有効なユーザー名を列挙し、ROPCでアクセス可能なエンドポイントに対してクレデンシャルスタッフィングやスプレー攻撃を実行、認証に成功したトークンを収集し、それを使ってAzureリソースにアクセスします。
Azure CLIが重要なのは、CLIアクセスが通常到達できる範囲の広さにあります。Azure CLIアクセス権を持つ開発者アカウントは、本番環境やリソースグループ、ストレージアカウント、コンピュートリソースへの権限を持っていることが一般的です。CLIは管理ツールであり、広範なアクセスが前提です。攻撃者がROPC経由でCLIの認証情報を侵害すると、メールアクセスだけでなく、インフラ全体へのアクセスを得る可能性があります。
総当たり攻撃は、従来の認証エンドポイントに対しては目立ちやすく、SIEMやID保護システムが失敗したログインイベントを検知・アラートします。しかしROPCベースのパスワードスプレーはより静かで、ブラウザセッションの認証イベントを発生させず、多くの組織のログ設定ではROPCトークン発行をインタラクティブなサインインイベントほど詳細に記録していません。
8,100万回という試行回数は、大規模なクレデンシャルスプレーにかかる計算コストを示しています。成功した78件（成功率0.000096%）は、多数の試行の中で一致する認証情報が見つかったことを意味します。真の脅威は試行回数そのものではなく、ROPC認証に成功するごとに、そのアカウントがアクセス可能な全リソースへのベアラートークンが発行される点です。本番ストレージアカウントやコンピュートリソース、CI/CDパイプラインにアクセス可能な開発者アカウント1件の侵害は、データ侵害とインフラレベルのインシデントを同時に引き起こします――コードリポジトリの知的財産やクラウドストレージの規制対象データが組み合わさることで、通知や対応義務が重大化します。
フィッシングやパスワードの使い回しが、スプレー攻撃で使われる認証情報の主な流出源です。認証情報が侵害データベースに記録されれば（多くの場合、最終的には記録されます）、自動化されたスプレーツールの入力データとなります。ROPC認証の大規模実行は、（a）攻撃者が過去の侵害から入手した有効な認証情報の数、（b）ROPC経由でCAP制御なしにアクセス可能なテナントエンドポイントの数、の関数となります。
条件付きアクセス制御のカバレッジ問題
条件付きアクセス制御は、Azure AD環境における多層防御の主要な制御策です。組織は、認証が成功する条件――特定の場所からのMFA必須、リスクの高いサインインのブロック、準拠デバイスへのアクセス制限など――を定義できます。正しく設定されていれば、CAPによって有効な認証情報でもポリシー条件を満たさなければ認証できず、パスワードスプレー攻撃はほぼ無効化されます。
ROPC攻撃におけるカバレッジ問題は、CAPが機能しないのではなく、カバレッジが完全でないことにあります。多くの組織は、CAPを優先度の高いアプリケーションやユーザーグループから段階的に導入し、例外が積み重なっていきます。Azure CLIは典型的な例外で、開発者にCLIアクセスが必要であり、CLIベースのツールは自動化パイプラインでMFA中断に対応できないため、結果としてCLI認証がCAP例外となり、攻撃対象となります。
ID層のセキュリティ設定ミスは、常に最も大きな攻撃ベクトルの一つです。たった一つの設定ミスによるポリシー例外が、堅牢なMFA制御をすり抜けるレガシー認証経路を開放します。Huntressのキャンペーンは、その典型例です。MFAが弱いからではなく、78件のアカウントがCAP例外やROPC認証を許可するアプリケーションスコープにあったために侵害されました。
組織が問うべき監査の問いは「条件付きアクセス制御があるか」ではなく、「すべての認証経路（レガシープロトコルのエンドポイントを含む）とすべてのユーザーアカウントにCAPが適用されているか」です。多くの組織は、プロトコルレベルでの監査を実施していません。サプライチェーンリスク管理の観点から、Azure CLIアクセスをサードパーティ開発者や請負業者、マネージドサービスプロバイダーに付与している場合は特に重要です――外部のCLIアクセス認証情報はROPCの露出ポイントとなり、元の組織のCAP監査では直接制御できない場合があります。
MFAを超えたアイデンティティガバナンス
ROPC攻撃パターンは、MFAだけでは解決できないアイデンティティセキュリティの構造的課題を示しています。MFAはインタラクティブな認証フロー上で機能する制御策ですが、レガシー認証プロトコルは設計上インタラクティブフローの外で動作し、MFAとは本質的に非互換です。
この課題へのアーキテクチャ的対応は、認証情報レベルだけでなくプロトコルレベルでの対策が必要です。レガシー認証の遮断は、Azure ADでROPCトークンリクエスト自体を拒否する設定を行うことを意味します。すべてのユーザー、または特定のユーザーグループに対してレガシー認証をブロックするCAPを作成できます。これはMicrosoft自身やHuntressの調査でも推奨されている主要な対策です。
ロールベースアクセス制御や属性ベースアクセス制御フレームワークで、開発者認証情報の権限を最小限に絞ることで、ROPC侵害時の影響範囲（ブラスト半径）を縮小できます。特定のストレージコンテナの読み取りや特定リソースグループへのデプロイだけが許可された開発者アカウントの侵害は、サブスクリプション全体のContributor権限アカウントの侵害よりも被害が限定的です。認証情報のスコープにデータ最小化を適用し、開発者アカウントには現在の業務に必要な最小限のAzure権限のみを付与し、定期的に見直す運用が、最小権限を現実の運用レベルで実現します。
IDおよびアクセス管理プログラムで、開発者認証情報を独立したリスクカテゴリとして扱い、ローテーションスケジュールやアクセススコープの見直し、ROPCトークン発行の異常検知を実施することが、この攻撃パターンへのエンタープライズレベルの対応です。多くのIAMプログラムは、ブラウザベースのワークフローで人が発行する認証情報の管理を前提に設計されていますが、CLIツールや自動化パイプラインで使われる開発者認証情報は、そのワークフローの外に置かれがちです。
ゼロトラスト・アーキテクチャをクラウドアイデンティティに適用するには、アプリケーションアクセスレベルだけでなく、認証イベントレベルでの継続的な検証が必要です。ROPC経由でトークンが発行された場合、ゼロトラストの原則では、そのトークンに対してリスクシグナル（異常な地理情報、認証情報の再利用パターン、アクセス速度など）を評価し、リソース提供前に確認すべきです。この継続的な評価こそがCAPベースの制御が提供するものであり、ROPCがCAPをバイパスすることの重大性はここにあります。
Kiteworks 2026年データセキュリティ＆コンプライアンスリスク年次予測レポートでも、IDおよびアクセス管理のギャップがエンタープライズのデータ侵害の最も一般的な根本原因の一つであることが明らかになっています。Huntressが記録したROPCキャンペーンは、その具体例です。高度なゼロデイ攻撃ではなく、多くの組織がIDガバナンスプログラムで明確に対処していないレガシープロトコルのギャップです。機密コンテンツをポリシー制御付きアクセス管理と不変の監査ログを備えたプライベートデータネットワーク経由でルーティングする組織は、追加の封じ込め境界を持つことになります――たとえ本番アクセス権を持つAzure認証情報が侵害されても、Kiteworks独自のABACポリシーで特定の認可IDに限定されたコンテンツには到達できません。
即時対応ステップ
Huntressの調査は、組織が直ちに実施できる具体的なガイダンスを提示しています。主な対策は以下の通りです：
テナントレベルでレガシー認証をブロックする。 Azure ADの条件付きアクセス制御で、ROPCを含むレガシー認証プロトコルをすべてのユーザー、または特定のユーザーグループやアプリケーションに対してブロックできます。Microsoftはこのためのポリシーテンプレートも提供しています。レガシーアプリケーション依存のためにこの対応を遅らせている組織は、依存関係を監査し、移行計画を策定する必要があります。
条件付きアクセス制御のカバレッジを監査する。 すべてのユーザーアカウントとアプリケーションを、適用されているCAPポリシーと照合し、ギャップ――CAPが適用されていないアプリケーション、MFA要件から除外されたユーザーアカウント、条件付きアクセス制御を回避できるCLIアクセス権を持つサービスアカウント――を特定します。すべてのギャップがROPC露出の可能性です。
Azure CLIアクセス権を持つアカウントの認証情報をローテーションする。 Huntressのキャンペーンでは、検知前に78件のアカウントがROPC経由で認証されていました。露出を否定できない組織は、CLIやプログラムによるAzureアクセス権を持つすべての開発者アカウントの認証情報をローテーションしてください。
ROPCイベントのサインインログを有効化する。 Azure ADのサインインログは、レガシー認証を含む認証イベントを記録します。ROPC認証イベントに対するSIEMアラートを設定することで、将来のスプレー攻撃の早期警告となり、監査ログのベースライン確立がインシデント対応に役立ちます。
トークン発行時の異常検知を実装する。 予期しないIPレンジや地理、異常な時間帯からのROPCトークンリクエストは検知可能なシグナルです。認証リスクイベントをスコアリングするID保護ツールで、ROPCスプレー攻撃を認証成功が増える前に検知できます。CISOダッシュボードは、すべての管理チャネルにわたるコンテンツアクセスパターンをリアルタイムで可視化し、認証情報侵害後の異常な活動を報告義務が発生する前に表面化させます。
Kiteworksが規制環境下でのアイデンティティガバナンス、アクセス制御、クラウドセキュリティ設定ミスにどう対応しているか、カスタムデモを今すぐご予約ください。
よくあるご質問
Resource Owner Password Credentials（ROPC）フローは、アプリケーションからIDプロバイダーへユーザー認証情報を直接POSTリクエストで渡すレガシーOAuth 2.0認証方式で、最新フローのようなブラウザリダイレクト認証を経由しません。認証情報がIDプロバイダーの認証UIを通らずアプリケーションを経由するため、MFAプロンプトをフロー内に挿入できず、条件付きアクセス制御のサインイン評価も発動しません。Microsoftはこれらのセキュリティ上の制約からROPCを非推奨としましたが、レガシーアプリケーションとの後方互換性のため、多くのAzureテナントでプロトコルは依然として有効です。Huntressは、攻撃者がこのフローを使って2026年にAzure CLIエンドポイントに対し8,100万回のパスワードスプレー攻撃を実行し、MFAを一度も発動させずに78件のアカウントを侵害した事例を記録しました。セキュリティの設定ミスはMFA自体ではなく、それを回避する認証経路が残り続けていることにあります。HIPAA、CMMC、GDPR、FINRAなどの規制コンプライアンス義務を負う組織は、AzureテナントにおけるROPCの利用可能性をコンプライアンスギャップと見なし、監視されていないレガシー認証経路がアクセス制御の証跡を損なうことに注意すべきです。
ROPCを利用したAzure CLIパスワードスプレー攻撃は以下の流れです。攻撃者は、過去の侵害データベースやフィッシング、クレデンシャルスタッフィングの結果などから有効なAzure ADユーザー認証情報のリストを入手または作成します。次に、その認証情報をAzure CLI認証リクエストとしてAzure ADのROPCトークンエンドポイントに送信します。認証情報が有効で、そのアカウントに対してROPCフローをブロックする条件付きアクセス制御がなければ、Azure ADはMFAを発動させずにアクセストークンを発行します。攻撃者はそのトークンを使って被害者のAzureリソースに対しCLIコマンドで認証します。この攻撃は、Azure ADログのレガシー認証サインインイベントをSIEMで監視することで検知可能ですが、ログの有効化とアラート設定が必要です。ゼロトラスト・アーキテクチャの原則で、トークン発行レベルでの継続的な検証（レガシー認証リクエストのリスクスコアリングを含む）を行うことで、MFAだけではカバーできない検知が可能です。ROPC侵害シナリオを明示的にカバーしたインシデント対応計画（Azureアクティビティログの確認手順や認証情報のローテーション手順を含む）が、検知から封じ込めまでの明確な対応フローとなります。
Azure ADの条件付きアクセス制御（CAP）は、認証が成功する条件――特定の場所からのMFA必須、リスクの高いサインインのブロック、準拠デバイスへのアクセス制限など――を定義します。正しく設定・適用されていれば、CAPによって有効な認証情報でもポリシー条件を満たさなければ認証できず、パスワードスプレー攻撃はほぼ無効化されます。ROPC攻撃は、CAPがインタラクティブなサインインイベントで発動するため、ROPCトークンリクエストが同じサインインイベントフローを通らず、CAPをバイパスします。さらに、多くの組織は開発者ツールや自動化パイプライン、ROPC互換認証が必要なレガシーアプリケーションにCAP例外を設けており、これがHuntressの記録した攻撃キャンペーンで悪用されたカバレッジギャップとなっています。IDおよびアクセス管理監査で、アプリケーション単位だけでなく認証プロトコル単位でカバレッジをマッピングすることが、こうしたギャップの特定に不可欠です。ID層だけでなくコンテンツ層にもアクセス制御を適用することで、認証ギャップによるトークン発行が発生しても有効な第二の防御境界となります。
Azure ADでMFAを必須化すると、インタラクティブな認証フローでトークン発行前にMFAチャレンジが発動します。レガシー認証のブロックは、Azure ADがレガシー認証プロトコル（ROPCを含む）によるトークンリクエスト自体を、認証情報の有効性に関係なく拒否するものです。これは別個の制御策であり、効果も異なります。MFAだけではROPC攻撃を防げません。なぜならROPCはMFAが発動するインタラクティブ認証フローをバイパスするからです。レガシー認証のブロックは、認証情報評価前にROPCトークンリクエストを遮断し、プロトコルレベルで攻撃を防ぎます。Microsoftは、レガシー認証のブロックをセキュリティ構成のベースラインとして推奨しており、Azure ADにはこの目的のCAPテンプレートも用意されています。すべてのインタラクティブ認証にMFAを必須化し、最新認証フローに移行済みのすべてのユーザーアカウント・アプリケーションでレガシー認証プロトコルをブロックする、両方の制御策を実装すべきです。ロールベースアクセス制御で開発者認証情報の権限を最小化すれば、残存するレガシー認証ギャップによる被害も限定できます。サードパーティリスク管理プログラムでは、Azure環境で運用するマネージドサービスプロバイダーや請負業者が、自身の管理ツールでもレガシー認証をブロックしていることを確認すべきです――ROPC経由でCLI認証情報にアクセスできるMSPアカウントも、内部開発者アカウントと同じリスクとなります。
Azure CLIのROPCパスワードスプレー攻撃の標的になった疑いがある場合、組織は直ちに5つの対応を取るべきです。第一に、Azure ADのサインインログを過去90日分抽出し、レガシー認証イベント（ROPCトークンリクエストはレガシー認証サインインイベントとして記録）をフィルタします。第二に、レガシー認証で認証に成功したアカウントを特定し、そのAzureアクティビティログで不正なリソースアクセスがないか確認します。第三に、ROPC認証の有無に関わらず、Azure CLIアクセス権を持つすべてのアカウントの認証情報をローテーションします。第四に、すべてのユーザーアカウント、または最低でもCLIやAPIアクセス権を持つアカウントに対し、レガシー認証をブロックする条件付きアクセス制御を実装します。第五に、開発者ツールや自動化サービスアカウントのCAP例外をすべて見直し、閉じます。監査ログのベースライン確立と、今後のROPC認証イベントに対するSIEMアラート設定も続けて行うべきです。インシデント対応プロセスでは、規制コンプライアンス上の通知義務が発生する場合に備え、調査結果を記録します。PHI、CUI、PIIなど規制対象データを管理している組織は、侵害されたAzure認証情報でアクセス可能なストレージアカウントやデータリポジトリに、データ侵害通知が必要なコンテンツが含まれていないか追加で評価すべきです。
追加リソース
- ブログ記事
サードパーティベンダー・請負業者向けセキュアなファイル転送ワークフロー設計方法 - ブログ記事
CISOのためのベンダーリスク管理の重要性 - ブログ記事
外部パートナーとの協業時に知的財産を守る方法 - ブログ記事
サプライチェーンセキュリティ＆リスク管理で脅威に立ち向かう - ブログ記事
パートナーのデータ侵害：最も弱いパートナーが組織の強さを決める