Translated ['', 'src/pentesting-cloud/azure-security/az-lateral-movement

This commit is contained in:
Translator
2025-08-25 21:25:48 +00:00
parent f867638aff
commit 44306c0d92
@@ -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.
<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
**Connect Sync** - це, по суті, "старий" спосіб Azure для **синхронізації користувачів з AD в Entra ID.** Новий рекомендований спосіб - це використання **Entra Cloud Sync**:
**Connect Sync** це по суті «старий» спосіб Azure для **синхронізації користувачів з AD в Entra ID.** Новіший рекомендований спосіб використання **Entra Cloud Sync**:
{{#ref}}
az-cloud-sync.md
{{#endref}}
### Згенеровані принципали
### Згенеровані principals
- Обліковий запис **`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**.
- Обліковий запис **`MSOL_<installationID>`** автоматично створюється в локальному 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<id>`** без будь-яких спеціальних привілеїв за замовчуванням.
- У Entra ID створюється обліковий принципал **`ConnectSyncProvisioning_ConnectSync_<id>`** з сертифікатом.
- У локальному AD створюється керований обліковий запис служби **`ADSyncMSA<id>`** без якихось спеціальних привілеїв за замовчуванням.
- В Entra ID створюється Service Principal **`ConnectSyncProvisioning_ConnectSync_<id>`** з сертифікатом.
## Синхронізація паролів
### Синхронізація хешів паролів
Цей компонент також може бути використаний для **синхронізації паролів з 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_<id>`, автоматично згенерованому в 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_<id>`, автоматично згенерованому в 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\_<id>
Цей додаток створюється без призначення будь-яких ролей управління Entra ID або Azure. Однак він має такі API дозволи:
### Зловживання ConnectSyncProvisioning_ConnectSync_<id>
Цей додаток створено без призначених ролей управління 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_<id>`**. Однак він все ще може бути присутнім в деяких середовищах, тому варто перевірити його наявність.
> Раніше в Entra ID створювався користувач з ім'ям `Sync_*` з дуже чутливими дозволами, що дозволяло виконувати привілейовані дії, такі як зміна пароля будь-якого користувача або додавання нових облікових даних до service principal. Однак з Jan2025 цей користувач більше не створюється за замовчуванням, оскільки тепер використовується Application/SP **`ConnectSyncProvisioning_ConnectSync_<id>`**. Проте він може все ще бути присутній у деяких середовищах, тому варто перевірити його.
Скомпрометувавши обліковий запис **`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/)