特権昇格攻撃は、世界中のセキュリティチームにとって最も差し迫った問題の1つであり、一般的には 横移動攻撃者は、特権アカウントは通常監視され保護されているため、侵害するのが難しいことを知っています。しかし、攻撃者は 特権昇格 監視の行き届いていないアカウントを乗っ取り、セキュリティチームの目を逃れながら、高いレベルのアクセス権限を獲得するための脆弱性を悪用する。
今日のハイブリッド環境において、企業は機密性の高いリソースをSaaSアプリケーションに移行する傾向を強めている。Azure Active Directory は、企業がこうしたアプリケーションへのアクセスと利用を一元的に管理できるようにする、主要なクラウドIDプロバイダーの1つです。
最近、権限昇格の問題を発見しました Entra ID （旧 アズールAD攻撃者がパスワードリセットの保護機能を回避し、下位レベルの管理者が完全な特権を持つ管理者になれる可能性がある脆弱性がありました。この問題はマイクロソフト セキュリティ レスポンス センター (MSRC) に報告され、MSRC が検証して修正を適用しました。この問題はもはや、 Entra ID （旧Azure AD）ユーザーの皆様だけでなく、より広範なセキュリティコミュニティの皆様にも、私たちの分析と調査結果をご覧いただくことでメリットが得られると考えています。
テクニカル分析
その Entra ID （旧称 Azure AD）の特権ロールシステムは階層構造になっており、権限の低い管理者が権限の高い管理者のパスワードをリセットできないようになっています。このシステムは運用上のロジックに加え、権限の低い管理者アカウントが侵害された場合でも、攻撃者が権限の高い管理者のパスワードを変更できないようにすることで、セキュリティを強化します。
この保護措置は、ユーザーの役割が「適格」または「アクティブ」に設定されている場合に有効です。ただし、 Entra ID （旧Azure AD）では、 ユーザーアカウント 割り当てられる予定 将来の利用 つまり、上位レベルの権限は、あらかじめ定められた日時において付与される。
この場合、 パスワードによる保護は適用されません。 これにより明らかになる Entra ID （旧称 Azure AD）を次のシナリオに変更します。
- 最初の妥協攻撃者が権限の低い管理者アカウントを侵害する。
- 将来の役割分担の発見攻撃者はスキャンします Entra ID （旧Azure AD）を使用して、将来的に高度な権限を持つ管理者になる予定のアカウントを検索します。
- パスワードのリセット攻撃者は、役割割り当てが行われる前にこれらのアカウントのパスワードをリセットし、アカウントを侵害します。理想的には、攻撃者は役割変更のタイミングにできるだけ近いタイミングでこのリセットを実行します。
- 特権エスカレーション役割変更が行われ、攻撃者はアクティブな高権限管理者アカウントを完全に制御できるようになります。
それでは、これらの段階を一つずつ見ていきましょう。
最初の妥協
本分析では、既にこの事態が発生していると仮定します。攻撃者は「Shay Katz」のアカウントを侵害しており、そのアカウントには「ヘルプデスク管理者」の権限が付与されています。
スクリーンショット1：シェイ・カッツに割り当てられた役割画面
以下の表は、 Entra ID（旧Azure AD）の組み込みロールWebページでは、さまざまなロールのパスワードリセット権限が表示されます。 Entra ID （旧称 Azure AD）。「ヘルプデスク管理者」は「認証管理者」および「パスワード管理者」ロールのパスワードをリセットできないことがわかります。
スクリーンショット2: Entra ID （旧称 Azure AD）パスワードリセット権限テーブル
攻撃者は現在ログインしています Entra ID （旧Azure AD）ユーザー「Shay Katz」として。
将来の役割割り当ての発見
Microsoftの修正以前は、将来の管理者割り当てを低コストで発見するための2つのオプションがありました。 特権ユーザー:
- 介して Entra ID （旧称 Azure AD）ポータルで、上位階層の管理者の将来の役割割り当てに関する「保留中のリクエスト」ページを確認します。
- スクリプトを介して、リソースグラフを使用します。
a) 必要な権限:
スケジュールされた役割資格要求の一覧表示: 必須: ReadWrite.AzureAD
以下の内容を含むリスト：
- DeviceManagementApps.Read.All
- デバイス管理アプリ.読み取り書き込み.すべて
- ディレクトリ.読み取り.すべて
- ディレクトリ。ReadWrite。すべて
- ユーザー.読み取り.すべて
- User.ReadBasic.All
- ユーザー.読み取り書き込み.すべて
b) スケジュールされたリクエストを取得するには、「https://graph.microsoft.com/beta/roleManagement/directory/roleEligibilityScheduleRequests」クエリを実行します。
ステータスが「provisioned」かつ scheduleInfo['startDateTime'] > currentTime でフィルタリングします。 役割定義ID protectedRoleIdList 内。
c) principalId キーを使用してユーザーの display_name を取得するには、「https://graph.microsoft.com/beta/users?$select=displayName,id」クエリを実行します。
使い方 Entra ID （旧称 Azure AD）ポータル（オプション A）では、攻撃者は現在「アクティブ」または「適格」の役割が割り当てられていないサンプル テスト アカウントを発見します。
スクリーンショット3：「テスト」アカウント（「適格」または「アクティブ」な割り当てがない状態）
しかし、「リクエスト時間」と「開始時間」のフィールドを見ると、このテストアカウントには、将来グローバル管理者として追加されるための保留中のリクエストがあることがわかります。
スクリーンショット4：テストアカウントをグローバル管理者にするためのリクエストが保留中
攻撃者はついに格好の標的を見つけた。権限が低く、将来的に役割が割り当てられるアカウントだ。これで次の段階に進むことができる。
パスワードのリセット
攻撃者は、テストアカウントのパスワードをリセットできるようになりました。 Entra ID （旧称：Azure AD）ポータル：
スクリーンショット5：テストアカウントのパスワードリセット
権限昇格
任務完了。指定された開始時刻になると、テストアカウントはグローバル管理者アカウントにアップグレードされ、攻撃者は完全な制御権を得ます。
マイクロソフトの修正
マイクロソフトは、以下の対策を講じることでこの問題に対処しました。
- 権限の低い管理者は、ポータルで保留中のリクエストを表示できなくなりました。
- 将来の特権ロール割り当てのためにパスワードをリセットしようとすると、エラーが発生します。（通常、パスワードのリセットが許可されていない場合は、パスワードリセットボタンがロックされます。）
結論
前述のとおり、Microsoft はこの問題を修正したため、この攻撃手法はもはや有効ではありません。ただし、Just-in-Time アクセス保護におけるこのような問題は、攻撃者を引き付けることが知られています。このケースでは、特権の割り当てと、それを保護するために構築されたセキュリティ対策の実際の有効化との間にギャップがありました。企業がクラウド指向になるにつれて、SaaS 管理インフラストラクチャにおけるこのような脆弱性を探す脅威アクターの欲求が高まっています。この機会に、 攻撃対象 また、マイクロソフト社の迅速かつ効率的な対応に感謝の意を表します。
