Az - Conditional Access Policies & MFA Bypass
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Azure Conditional Accessポリシーは、特定の条件に基づいてAzureサービスやアプリケーションへのアクセス制御を強制するためにMicrosoft Azureで設定されたルールです。これらのポリシーは、適切な状況下で適切なアクセス制御を適用することにより、組織がリソースを保護するのに役立ちます。 Conditional accessポリシーは基本的に誰が何にどこから****どのようにアクセスできるかを定義します。
いくつかの例を挙げます:
サインインリスクポリシー:このポリシーは、サインインリスクが検出された場合に多要素認証(MFA)を要求するように設定できます。たとえば、ユーザーのログイン行動が通常のパターンと異なる場合、たとえば異なる国からログインしている場合、システムは追加の認証を促すことができます。
デバイスコンプライアンスポリシー:このポリシーは、組織のセキュリティ基準に準拠しているデバイスのみがAzureサービスにアクセスできるように制限できます。たとえば、最新のウイルス対策ソフトウェアがインストールされているデバイスや特定のオペレーティングシステムバージョンを実行しているデバイスからのみアクセスを許可することができます。
Conditional accessポリシーが簡単に改ざんできる情報をチェックしている可能性があり、ポリシーのバイパスを許可することがあります。たとえば、ポリシーがMFAを設定している場合、攻撃者はそれをバイパスできるでしょう。
Conditional accessポリシーを設定する際には、影響を受けるユーザーとターゲットリソース(すべてのクラウドアプリなど)を指定する必要があります。
また、ポリシーをトリガーする条件を設定する必要があります:
ネットワーク:IP、IP範囲、地理的位置
VPNやプロキシを使用して許可されたIPアドレスからログインすることでバイパス可能
Microsoftリスク:ユーザーリスク、サインインリスク、内部者リスク
デバイスプラットフォーム:任意のデバイスまたはAndroid、iOS、Windows Phone、Windows、macOS、Linuxを選択
「任意のデバイス」が選択されていないが他のすべてのオプションが選択されている場合、これらのプラットフォームに関連しないランダムなユーザーエージェントを使用してバイパス可能
クライアントアプリ:オプションは「ブラウザ」、「モバイルアプリとデスクトップクライアント」、「Exchange ActiveSyncクライアント」、「その他のクライアント」
選択されていないオプションでログインをバイパスする
デバイスのフィルタ:使用されているデバイスに関連するルールを生成可能
認証フロー:オプションは「デバイスコードフロー」と「認証転送」
これは、攻撃者がフィッシング試行で被害者のアカウントにアクセスしようとしない限り、影響を与えません
可能な結果は:ブロックまたはアクセスを許可し、MFAを要求する、デバイスが準拠している必要があるなどの条件が付くことがあります…
デバイスプラットフォーム(Android、iOS、Windows、macOSなど)に基づいて条件を設定することが可能ですが、これはユーザーエージェントに基づいているため、バイパスが容易です。すべてのオプションでMFAを強制しても、認識されないユーザーエージェントを使用すれば、MFAまたはブロックをバイパスできます:
ブラウザに不明なユーザーエージェント(例:Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920) UCBrowser/10.1.0.563 Mobile
)を送信させるだけで、この条件をトリガーしないようにできます。
開発者ツールでユーザーエージェントを手動で変更できます:
または、このようなブラウザ拡張機能を使用できます。
これが条件付きポリシーに設定されている場合、攻撃者は許可された国でVPNを使用するか、許可されたIPアドレスからアクセスする方法を見つけることで、これらの条件をバイパスできます。
特定のアプリにアクセスしようとするユーザーに対して、MFAをブロックまたは強制するために条件付きアクセスポリシーを設定することが可能です:
この保護をバイパスしようとする場合、任意のアプリケーションにのみログインできるかどうかを確認する必要があります。 ツールAzureAppsSweepは、ハードコーディングされた数十のアプリケーションIDを持ち、それらにログインしようとし、成功した場合はトークンを提供します。
特定のリソース内の特定のアプリケーションIDをテストするために、次のようなツールを使用することもできます:
さらに、ログイン方法を保護することも可能です(例えば、ブラウザからログインしようとしている場合やデスクトップアプリケーションからの場合)。ツール Invoke-MFASweep は、この保護を回避しようとするいくつかのチェックを実行します。
ツール donkeytoken も同様の目的で使用できますが、メンテナンスされていないようです。
ツール ROPCI もこの保護をテストし、MFAやブロックを回避できるかどうかを確認するために使用できますが、このツールはホワイトボックスの視点から動作します。最初にテナントで許可されているアプリのリストをダウンロードし、その後それらにログインしようとします。
Azure MFAのオプションの1つは、設定された電話番号に電話を受けることで、ユーザーに文字 #
を送信するように求められます。
文字は単なるトーンであるため、攻撃者はボイスメールメッセージを妥協し、メッセージとして**#
のトーンを設定し、その後MFAを要求する際に被害者の電話が通話中であることを確認**することで、Azureの通話がボイスメールにリダイレクトされるようにします。
ポリシーはしばしば準拠デバイスまたはMFAを要求するため、攻撃者は準拠デバイスを登録し、PRTトークンを取得し、この方法でMFAを回避することができます。
まず、Intuneに準拠デバイスを登録し、その後PRTを取得します:
Find more information about this kind of attack in the following page:
Az - Pass the PRTこのスクリプトは、いくつかのユーザー資格情報を取得し、いくつかのアプリケーションにログインできるかどうかを確認します。
これは、後で特権を昇格させるために悪用する可能性のあるいくつかのアプリケーションにログインする際にMFAが必要ないかどうかを確認するのに役立ちます。
すべてのポリシーを取得します。
MFASweepは、提供された資格情報を使用してさまざまなMicrosoftサービスにログインし、MFAが有効かどうかを特定しようとするPowerShellスクリプトです。条件付きアクセス ポリシーやその他の多要素認証設定の構成によっては、一部のプロトコルが単一要素のままになることがあります。また、ADFS構成の追加チェックがあり、検出された場合はオンプレミスのADFSサーバーにログインしようとすることもできます。
このツールは、MFAのバイパスを特定し、その後、複数の本番AADテナントでAPIを悪用するのに役立ちました。AADの顧客はMFAが強制されていると信じていましたが、ROPCベースの認証が成功しました。
アプリのリストを生成するためには、すべてのアプリケーションをリストする権限が必要です。
Donkey tokenは、Conditional Access Policiesを検証する必要があるセキュリティコンサルタントを支援することを目的とした一連の機能です。2FAが有効なMicrosoftポータルのテストなど。
各ポータルをテストして、MFAなしでログインできるか確認します:
なぜなら、Azure ポータルは制約されていないため、前回の実行で検出された任意のサービスにアクセスするためにポータルエンドポイントからトークンを収集することが可能です。この場合、Sharepointが特定され、アクセスするためのトークンが要求されます:
トークンが Sites.Read.All (Sharepoint から) の権限を持っていると仮定すると、MFA のためにウェブから Sharepoint にアクセスできなくても、生成されたトークンを使用してファイルにアクセスすることが可能です:
AWSハッキングを学び、練習する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、練習する:HackTricks Training GCP Red Team Expert (GRTE)