Azure Active Directoryを介して流出する内部情報

2022年4月5日（火）
著者：カウンター・スレット・ユニット（CTU™）リサーチチーム

最終更新日：2022年4月12日

※本記事は、https://www.secureworks.com/ で公開されている Azure Active Directory Exposes Internal Information を翻訳したもので、 2022 年 4 月 12 日執筆時点の見解となります。

Microsoft Azure Active Directory (Azure AD)は、Fortune 500掲載企業の 88％以上*に利用されているアイデンティティおよびアクセス管理ソリューションです（*ブログ投稿日現在）。普及率が高いため、攻撃グループにとって大きな儲けにつながる格好の標的となります。当社のカウンター・スレット・ユニット™ (CTU™)リサーチャーは2021年下半期を通じてAzure ADのテナントを分析し、Azure AD利用組織に関するオープンソースインテリジェンス(OSINT) を抽出することに成功しました。攻撃グループによる偵察活動の際は、OSINTが頻繁に活用されます。この分析によって、Azure AD利用組織の内部情報へのアクセス経路となるAPIが複数存在することが判明しました。APIを介して収集された詳細データのなかには、ライセンス情報、メールボックス情報、ディレクトリの同期状態などの情報もありました。

当社は、前述の知見をMicrosoft社に共有しました。特定された問題のうち2項目を除くすべての問題は本ブログ投稿日現在、すでに緩和対応が完了しています。Azure ADテナントすべてを対象にMicrosoft社による自動更新版が適用されているため、Azure AD管理者による対策は必要ありません。Microsoft社は、対応未完了の2項目を「by-design（元々の仕様である）」としています。一つ目は、ディレクトリの同期状態に関するクエリを誰でも実行できる、という問題です。つまり、場合によっては同期処理で使用する特権アカウントの情報がAzure ADを介して外部に露出する可能性があります。二つ目は、Azure ADテナントに関する内部情報（技術窓口の氏名や電話番号など）が露出する可能性がある、という問題です。技術窓口となる担当者は通常、Azure ADのグローバル管理者権限を有しています。

追記：上記の2項目は2022年4月、Microsoft社にて対応が完了しました。

Azure ADのOSINT詳細情報

AADInternalsなどのツールを使うと、認証不要なAPIを介してAzure ADのOSINTを収集できます。収集可能なOSINTには、対象のテナントの登録ドメイン名およびその種類、テナント名およびテナントID、シームレスシングルサインオンの状態（別名：デスクトップSSO）などがあります。図1は、Invoke-AADIntReconAsOutsiderのコマンド出力画面です。出力結果には、対象組織のOSINT情報が含まれています。

図1：認証不要のAPIを介してOSINT情報を出力するInvoke-AADIntReconAsOutsiderコマンド（出典：Secureworks）

認証不要のAPIに加え、Azure ADテナントにログインしたユーザーのみが使用できる認証済APIもあります。認証済みユーザーは管理者権限がなくても、自らのテナントから以下の情報（図2に列挙した情報）にアクセスすることができます。当該APIを使えばユーザー本人以外のテナントの情報にもアクセス可能であることがCTUリサーチャーの調べで確認されています。

図2：認証が必要なAPIを介して取得したデータが列挙されているInvoke-AADIntReconAsInsiderコマンドの出力画面（出典：Secureworks）

Diagnostics API（診断用API）

Microsoftでは、文書化されていないDiagnostics APIをサポート/回復アシスタント(SaRA)ツールで使用しており、ログイン済みのユーザーがMicrosoftクラウドサービスにアクセスする際の問題を診断・解決できるよう支援しています。2019年の時点でSaRAツールの処理に当該APIのanalysisエンドポイントが用いられていたことがCTUリサーチャーの調べで確認されています。SaRAクライアントとanalysisエンドポイントを結ぶトラフィックでは、以下の処理（図3）が行われていました。

図3：Diagnostics APIのanalysisエンドポイントを介した処理（出典：Secureworks）　

1. ユーザーがSaRAを開き、問題の症状を入力して診断を開始。
2. SaRAからanalysisエンドポイントに対して最初のHTTP POSTリクエストを送信（図4）。このリクエストにはAnalyzerIdおよびDiagnosisInfoが含まれている。
   
   図4：Diagnostics APIのanalysisエンドポイントへの初回リクエスト（出典：Secureworks）
   
   
3. SaRAにSessionIdが返される。
4. Diagnostics APIがバックエンドでアナライザーを起動し、ユーザーのテナントとメールボックスを探索。
5. SaRAがHTTP GETリクエストとSessionIdを用いて分析ステータスをポーリング（図5）。
   
   図5：Diagnostics APIのanalysisエンドポイントへのポーリングリクエスト（出典：Secureworks）
6. Diagnostics APIが分析結果をSaRAに返す。
7. SaRAが分析結果を画面に表示。

AnalyzerIdとは、ユーザーの代理としてSaRAがDiagnostics APIに実行させる診断命令を含むアナライザーを指します。SaRAクライアントのソースコードには、アナライザーが列挙されています（図6）。

図6：ソースコードのアナライザーリストに記載されているSaRAアナライザーIDおよびアナライザー名のサンプル（出典：Secureworks）

CTUリサーチャーが調査した結果、当該リストにはクラウド関連のアナライザーが含まれていました（表1）。

表1：Diagnosis APIのanalysisエンドポイントで指定できるクラウド関連のアナライザー

SaRAクライアントからアナライザーにパラメータを受け渡す際は、DiagnosisInfo構造体が用いられます。図7は、個々のクラウド関連アナライザーが使用するパラメータの一覧です。

図7：個々のクラウド関連アナライザーに関するDiagnosisInfoの内容（出典：Secureworks）

実行結果には、ライセンスに関するすべての情報、テナントに対して有効化されているOfficeのバージョン、対象組織におけるExchangeのハイブリッド構成および外部とのリレーションシップ、ユーザーのメールボックス情報、メッセージングAPI （MAPI）のステータスをはじめとするユーザー情報が含まれています（図8）。

図8：Diagnostics APIのanalysisエンドポイントから返される情報（出典：Secureworks）

SaRAクライアントは、OAuthトークンからログイン済みユーザーのメールアドレスを抽出し（図9）、当該アドレスをDiagnosisInfoパラメータのターゲットSmtpAddressとして使います。

図9：Diagnostics APIのOAuthトークン（出典：Secureworks）

Diagnostics APIではSmtpAddressとログイン済みユーザーとの一致・不一致を検証しないため、SmtpAddressを標的のユーザーのメールアドレスに置き換えれば、どのテナントのどのユーザーの情報も自由に取得できます。また、指定したユーザーが存在せずともドメイン名が正しければ、テナントに関するすべての情報がAPI経由で返されます。これが、攻撃グループにとって貴重な情報となります。たとえばライセンス情報には、標的のテナントが使用している可能性がある保護機能の情報が含まれています。さらに、組織のリレーションシップをもとに、テナントに侵入するためのフィッシング攻撃の標的候補者が連鎖的に特定されることもあります。

当該脆弱性を2021年9月7日付でMicrosoft社に報告したところ、9月22日にMicrosoft社より「問題を解決した」との回答を得ました。CTUリサーチャーは以下の2箇所の修正が行われていることを確認しました。

• 他のユーザーの情報に対するアクセスの禁止（図10）
  
  図10：「指定されたユーザーにアクセスできません」という応答メッセージ（出典：Secureworks）
• すべてのAnalyzerIDを無効にすることで、analysisエンドポイントを廃止（図11）
  
  図11：「アナライザーIDが不明です」という応答メッセージ（出典：Secureworks）

当社CTU は2021年、SaRAのバージョン17.0.7.7119.4を解析しました。その結果、クライアントがanalysisエンドポイントではなくcloudcheckエンドポイントを使用するようになっていることを確認しました。図12は、cloudcheckエンドポイントによる処理フローです。

図12：Diagnostics APIのcloudcheckエンドポイントによる処理（出典：Secureworks）

1. ユーザーがSaRAを開き、問題の症状を入力して診断を開始。
2. SaRAからcloudcheckエンドポイントに対して最初のHTTP POSTリクエストを送信（図13）。
   
   図13：Diagnostics APIのcloudcheckエンドポイントによる初回リクエスト（出典：Secureworks）
   
   このリクエストには、ユーザーがステップ1で入力した問題の症状とパラメータの詳細が含まれています（図14）。
   
   図14：cloudcheckエンドポイントに送信された情報（出典：Secureworks）
   
   
3. SaRAにRequestIdが返される（図15）。
   
   図15：Diagnostics APIのレスポンス（出典；Secureworks）
   
   
4. Diagnostics APIのバックエンドで診断を開始し、ユーザーのテナントとメールボックスを探索。
5. SaRAがHTTP GETリクエストとRequestIdを用いて分析ステータスをポーリング（図16）。
   
   図16：Diagnostics API v1のポーリングリクエスト（出典：Secureworks）
   
   
6. cloudcheckエンドポイントが診断結果をSaRAに返す
7. SaRAが診断結果を画面に表示

SaRAクライアントから、analysisエンドポイントと同様の診断情報を取得可能な以下のリクエストが存在することが判明しました。

• CasMailbox
• DirSyncCheck
• ExchangeHybridTenant
• GetUserDiagnostic
• TenantUserInfo

図17には、DirSyncCheckに関するパラメータが列挙されています。

図17：DirSyncCheckリクエストで用いるパラメータ値（出典：Secureworks）

analysisエンドポイントの事例と同様に、初回リクエストに含まれているUserUpnおよびUserSMTPEmailの属性が、APIアクセス時に使うベアラートークンのユーザープリンシパル名と一致していました。さらに、値を標的のユーザーのメールアドレスに置き換えることで、他のユーザーやテナントの情報を取得できる点も、analysisエンドポイントと共通しています。Microsoft社によるanalysisエンドポイントの問題への対応完了以降は、ログイン済みユーザーが取得できる情報の範囲が「同一テナントユーザーのCasMailBox」のみに限定されました。しかし他の情報はすべて、どのテナントからも要求できる状態です。

当社は当該脆弱性を2021年9月23日付でMicrosoft社に報告し、Microsoft社によるアップデートが同12月2日に実施されました。更新内容を確認した結果、ディレクトリ同期状態に関する問題以外はすべて対応が完了していました。Microsoft社は2022年1月28日、同期状態の問題には手を加えないまま当該脆弱性を「修正済」として対応終了（クローズ）しました。

表2は、ディレクトリ同期状態で使用する値の一覧です。攻撃グループにとってはどれも重要な情報ですが、なかでも貴重なものは、同期用のアカウント名が表示されている「パスワード失効メッセージ」です。このアカウントは、テナントにおいて高い権限をもち、すべてのテナントを対象にユーザーの作成、編集、削除を実行することができるほか、一部テナントにおけるユーザーのパスワードリセットを実行することができます。初期設定では、同期用アカウントのパスワードは同期構成時に生成され、有効期限はありません。セキュリティの観点から、構成設定時に自社テナントのパスワードに有効期限を設けている組織もあります。パスワード有効期限の通知は、失効日の前日から30日前までの間に送信されるように設定できます。

表2：ディレクトリ同期状態を示すメッセージ

組織に関する情報

組織の代表者が新たなMicrosoft 365またはAzure AD環境/テナントを登録（サインアップ）する際、Azure ADによる情報収集が実行されます。収集する情報は、サインアップフォームに入力された代表者の氏名および電話番号（図18）です。この代表者が、テナント側の技術窓口となります。

図18：Office 365のサインアップフォーム（出典：Secureworks）

サインアップが完了すると、技術窓口となった担当者はMicrosoft 365管理センター経由で自社の連絡先詳細を編集することができます（図19）。会社名および電話番号は、最初のサインアップフォームに事前入力されたものが使われます。

図19：管理センター画面に表示される組織情報（出典：Secureworks）

Microsoftのクラウドサービス（Microsoft 365、 Azure ADなど）を利用中の顧客企業向けに、Microsoft社のビジネスパートナー各社から複数のサービスが提供されています。顧客企業のAzure AD管理者は、Microsoftのパートナーに自社テナントへのアクセス権限を付与することができます。これにより、顧客企業のテナント内で外部パートナーとのリレーションシップが確立されますが、当該リレーションシップの管理操作は、管理者のみがアクセス可能なMicrosoft 365管理センター以外からは実行できません。

CTUリサーチャーの調べで、管理センターのAPIを介してパートナー組織の詳細情報が取得されていたことが判明しました（図20）。当該APIは管理センター専用ですが、パートナーのテナントIDを入力すれば、管理者権限がなくてもAPIにアクセスできます。

図20：管理センターAPIによるパートナー詳細情報の要求（出典：Secureworks）

レスポンス（図21）には、組織情報およびサインアップフォームに記載されている連絡先データが含まれています。初回サインアップ後に氏名（姓・名）を変更する場合はMicrosoft社による対応が必要です。これらのフィールドは、管理センターからは閲覧・変更できません。

図21：管理センターAPIから返されたパートナー情報（出典：Secureworks）

当該APIを使うとパートナーの状態を問わず、あらゆるテナントの情報を取得できることがCTUリサーチャーの検証によって判明しました。当該脆弱性は2021年12月14日付でMicrosoft社に報告済です。Microsoft社は2022年1月12日付で、「この情報は表示されることを想定している」として緩和対策を講じていません。

まとめ

Azure ADテナントを介して膨大な量のOSINTが攻撃グループに収集される可能性があります。当社CTUが特定した問題のうち、2項目以外はすべてMicrosoft社による対応が完了しています。

• テナントの同期状態に関するクエリを通じて、同期の構成有無や運用状態、最終同期日時、同期用アカウント名などの情報が露出する可能性があります。これらの情報が攻撃者の手に渡ると、（同期エラーデータを悪用した）ソーシャルエンジニアリング攻撃や、（アカウント名を悪用した）標的型ブルートフォース攻撃などが仕掛けられる恐れがあります。
• 組織情報に関するクエリを通じて、対象テナントのグローバル管理者の氏名および電話番号が露出する可能性があります。この情報が、ソーシャルエンジニアリング攻撃、スピアフィッシング攻撃、標的型ブルートフォース攻撃などに乱用される恐れがあります。

以下は、OSINTの乱用からテナントを保護するために当社CTUリサーチャーが推奨する対策です。

• ディレクトリ同期のエラーメッセージ経由で自社の詳細情報が外部に露出しないよう、指定された時間内での同期完了を徹底しましょう。管理者へのメール通知は、同期が完了しないまま24時間以上経過してから送信されますが、エラーメッセージは同期処理が3時間発生しなかった時点で表示されます。
• ディレクトリ同期用アカウントのパスワードに有効期限を設定している場合は、Azure AD画面に「パスワードがXX日後に失効します」という通知が表示される前にパスワードをリセットしましょう。これにより、同期用アカウント名の流出を防止できます。
• 社内テナントの詳細情報を、個人が特定されない一般名（「IT部門」など）に変更しましょう。一般的な名称に置き換えることで、グローバル管理者アカウントとなっている可能性のある個人の名前の流出を防止できます。一部のフィールド（電話番号など）は顧客組織側で変更できますが、技術窓口の個人名（姓・名）を変更する際はAzureポータル経由でサポート依頼を作成する必要があります。

追記（4月12日付）

前述の分析内容は2022年4月5日に公表したものですが、その後Microsoft社により、対応未完了となっていた2項目が再検討されました。当該項目の対応は4月12日時点で完了していることが、当社CTUリサーチャーの調べで確認されています（以下のとおり）。

• 同期状態：ユーザーが所属するテナントの情報以外は閲覧できない仕様に修正されている。
• 組織情報：組織情報の露出につながる管理センターAPIには管理者以外アクセスできず、APIの応答結果に技術窓口の名前が含まれない仕様に修正されている。