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を設定している場合、攻撃者はそれをバイパスできるでしょう。
デバイスプラットフォーム(Android、iOS、Windows、macOS)に基づいて条件を設定することが可能ですが、これはユーザーエージェントに基づいているため、バイパスは非常に簡単です。すべてのオプションでMFAを強制しても、認識されないユーザーエージェントを使用すれば、MFAをバイパスできます。
もちろん、これが条件付きポリシーに設定されている場合、攻撃者は許可された国でVPNを使用するか、許可されたIPアドレスからアクセスする方法を見つけてこれらの条件をバイパスすることができます。
クライアントがブラウザからOffice 365アプリにアクセスする場合、MFAが必要であることを示すことができます:
これをバイパスするには、デスクトップアプリケーションからアプリにログインするふりをすることが可能です(以下の例ではMicrosoft Teams)これにより保護をバイパスできます:
Microsoft Teamsアプリには多くの権限があるため、そのアクセスを利用することができます。
あらかじめ定義されたOffice365権限を持つより多くの公開アプリケーションのIDをroadtoolsのデータベースで見つけることができます:
この攻撃は特に興味深いです。なぜなら、デフォルトでパブリックなOffice365アプリケーションは、いくつかのデータにアクセスする権限を持つからです。
デフォルトでは、ユーザーが作成した他のアプリは権限を持たず、プライベートである可能性があります。 しかし、ユーザーはパブリックなアプリを作成し、いくつかの権限を付与することもできます。
ユーザーがブラウザを使用しているときにアプリケーションにアクセスするためにMFAを要求するポリシーが設定されている潜在的なシナリオでは(おそらくそれがWebアプリケーションであり、唯一の方法であるため)、プロキシアプリケーション -ユーザーの代理で他のアプリと対話することを許可されたアプリ- がある場合、ユーザーはプロキシアプリケーションにログインし、その後このプロキシアプリケーションを通じて最初にMFAで保護されたアプリにログインすることができます。
Invoke-MFASweepとdonkeytokenの技術を確認してください。
Azure MFAのオプションの一つは、設定された電話番号に電話を受け取ることで、ユーザーに**#
の文字を送信するように求められます**。
文字は単なるトーンであるため、攻撃者は電話番号のボイスメールメッセージを妨害し、メッセージとして**#
のトーンを設定し、その後、MFAを要求する際に被害者の電話が通話中であることを確認**することで、Azureの電話がボイスメールにリダイレクトされるようにします。
ポリシーはしばしば準拠デバイスまたはMFAを要求するため、攻撃者は準拠デバイスを登録し、PRTトークンを取得し、この方法でMFAをバイパスすることができます。
まず、Intuneに準拠デバイスを登録し、その後PRTを取得します:
以下のページでこの種の攻撃に関する詳細情報を見つけてください:
すべてのポリシーを取得する
MFASweepは、提供された資格情報を使用してさまざまなMicrosoftサービスにログインし、MFAが有効かどうかを特定しようとするPowerShellスクリプトです。条件付きアクセス ポリシーやその他の多要素認証設定がどのように構成されているかによって、一部のプロトコルは単一要素のままになる可能性があります。また、ADFS構成の追加チェックがあり、検出された場合はオンプレミスのADFSサーバーにログインを試みることができます。
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)