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

This commit is contained in:
Translator
2025-08-25 21:26:31 +00:00
parent 3e2e1b6814
commit bef2812d9b

View File

@@ -4,61 +4,64 @@
## Informations de base
[Selon la documentation :](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Les services de synchronisation Microsoft Entra Connect (Microsoft Entra Connect Sync) sont un composant principal de Microsoft Entra Connect. Ils s'occupent de toutes les opérations liées à la synchronisation des données d'identité entre votre environnement sur site et Microsoft Entra ID.
[D'après la documentation :](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) 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.
Pour l'utiliser, il est nécessaire d'installer l'agent **`Microsoft Entra Connect Sync`** sur un serveur dans votre environnement AD. Cet agent sera responsable de la synchronisation du côté AD.
<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
Le **Connect Sync** est essentiellement l'ancienne méthode Azure pour **synchroniser les utilisateurs d'AD vers Entra ID.** La nouvelle méthode recommandée est d'utiliser **Entra Cloud Sync** :
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** :
{{#ref}}
az-cloud-sync.md
{{#endref}}
### Principaux générés
### Principals généré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**.
- Cela signifie que quiconque compromettant 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 par défaut spéciaux.
- 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](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 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 mots de passe
### Synchronisation des hachages de mot de passe
Ce composant peut également être utilisé pour **synchroniser les mots de passe d'AD vers Entra ID** afin que les utilisateurs puissent utiliser leurs mots de passe AD pour se connecter à Entra ID. Pour cela, il est nécessaire de permettre la synchronisation des hachages de mots de passe dans l'agent Microsoft Entra Connect Sync installé sur un serveur AD.
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.
[Selon la documentation :](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **La synchronisation des hachages de mots 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 d'une instance Active Directory sur site vers une instance Azure AD basée sur le cloud.
[D'après la documentation :](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) 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.
Essentiellement, tous les **utilisateurs** et un **hachage des hachages de mots de passe** sont synchronisés de l'AD sur site vers Azure AD. Cependant, les **mots de passe en clair** ou les **hachages** **originaux** ne sont pas envoyés à Azure AD.
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** 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.
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 de groupes privilégiés connus comme les Administrateurs de domaine 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**.
> 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**.
### Écriture de mots de passe
### Rétroécriture des mots de passe
Cette configuration permet de **synchroniser les mots de passe d'Entra ID vers AD** lorsqu'un utilisateur change son mot de passe dans Entra ID. Notez que pour que l'écriture de mots de passe fonctionne, l'utilisateur `MSOL_<id>` généré automatiquement dans l'AD doit se voir accorder [plus de privilèges comme indiqué dans la documentation](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) afin qu'il puisse **modifier les mots de passe de tout utilisateur dans l'AD**.
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](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) 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.
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 administrateurs de domaine et d'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 qui ont été attribués des privilèges élevés à l'intérieur de l'AD sans appartenir à l'un de ces groupes pourraient voir leur mot de passe changé. Par exemple :
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 directement.
- Utilisateurs ayant des privilèges élevés attribués directement.
- Utilisateurs du groupe **`DNSAdmins`**.
- 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 **`Cert Publishers Group`** qui peuvent publier des certificats dans Active Directory.
- 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**.
## Pivotement AD --> Entra ID
## Pivoting AD --> Entra ID
### Énumération de Connect Sync
### Énumération Connect Sync
Vérifiez les utilisateurs :
Vérifier les utilisateurs :
```bash
# Check for the users created by the Connect Sync
Install-WindowsFeature RSAT-AD-PowerShell
@@ -76,25 +79,25 @@ $searcher.FindAll()
$searcher.Filter = "(samAccountName=Sync_*)"
$searcher.FindAll()
```
Vérifiez la **configuration de Connect Sync** (le cas échéant) :
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'**`MSOL_*`** utilisateur (et de l'**Sync\_\*** utilisateur s'il a été créé) sont **stockés dans un serveur SQL** sur le serveur où **Entra ID Connect est installé.** Les administrateurs peuvent extraire les mots de passe de ces utilisateurs privilégiés en texte clair.\
La base de données est située dans `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.
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 d'une des tables, étant l'une chiffrée :
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 elle 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'obtenir des privilèges élevés dans l'AD et dans AzureAD.
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échiffrés dans cette présentation](https://www.youtube.com/watch?v=JEIR5oGCwdg).
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](https://www.youtube.com/watch?v=JEIR5oGCwdg).
### Abuser de MSOL\_\*
### 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
@@ -112,34 +115,35 @@ 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 ont compromis l'autre mot de passe pour ensuite se connecter à l'utilisateur Entra ID appelé `Sync_*` et ensuite compromettre Entra ID. Cependant, cet utilisateur n'existe plus.
> 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.
### Abus de ConnectSyncProvisioning_ConnectSync\_<id>
Cette application est créée sans avoir de rôles de gestion Entra ID ou Azure assignés. Cependant, elle a les autorisations API suivantes :
### Abuser de ConnectSyncProvisioning_ConnectSync\_<id>
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`
- Service de réinitialisation de mot de passe Microsoft
- 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 en utilisant une API non documentée, mais aucun PoC n'a encore été trouvé à ma connaissance.\
Dans tous les cas, penser que cela pourrait être possible serait intéressant d'explorer davantage comment trouver le certificat pour se connecter en tant que ce principal de service et essayer d'en abuser.
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](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) publié peu avant le changement d'utilisation de l'utilisateur `Sync_*` à ce principal de service, expliquait que le certificat était stocké à l'intérieur du serveur et qu'il était possible de le trouver, de générer un PoP (Proof of Possession) et un token graphique, et avec cela, être capable d'ajouter un nouveau certificat au principal de service (car un **principal de service** peut toujours s'assigner de nouveaux certificats) et ensuite l'utiliser pour maintenir la persistance en tant que SP.
Ce [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71), 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 sont publiés : [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
Pour effectuer ces actions, les outils suivants ont été publiés : [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
D'après mon expérience, le certificat n'est plus stocké à l'endroit où l'outil précédent le cherchait, et par conséquent, l'outil ne fonctionne plus. Donc, des recherches supplémentaires pourraient être nécessaires.
Selon [this question](https://github.com/hotnops/ECUtilities/issues/1#issuecomment-3220989919), pour trouver le certificat, vous devez exécuter l'outil depuis un processus qui a **volé le token du processus `miiserver`**.
### Abus de Sync\_\* [DÉPRÉCIÉ]
### Abuser de Sync\_\* [DEPRECATED]
> [!WARNING]
> Auparavant, un utilisateur appelé `Sync_*` était créé dans Entra ID avec des autorisations 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 une nouvelle crédential à un principal de service. Cependant, à partir de janvier 2025, cet utilisateur n'est plus créé par défaut car maintenant l'Application/SP **`ConnectSyncProvisioning_ConnectSync_<id>`** est utilisé. Cependant, il pourrait encore être présent dans certains environnements, donc il vaut la peine de vérifier.
> 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.
Compromettre le compte **`Sync_*`** permet de **réinitialiser le mot de passe** de n'importe quel utilisateur (y compris les Administrateurs Globaux)
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
@@ -163,7 +167,7 @@ Set-AADIntUserPassword -SourceAnchor "3Uyg19ej4AHDe0+3Lkc37Y9=" -Password "JustA
# 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)
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.
@@ -172,23 +176,23 @@ Get-AADIntUsers | ?{$_.DirSyncEnabled -ne "True"} | select UserPrincipalName,Obj
# 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.
Il est également possible de dump 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 **la permission** de faire, puis **d'accéder à ce principal de service** comme moyen de privesc.
> 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.
### SSO Transparent
### Seamless SSO
Il est possible d'utiliser le SSO Transparent avec PHS, qui est vulnérable à d'autres abus. Vérifiez-le dans :
Il est possible d'utiliser Seamless SSO avec PHS, qui est vulnérable à d'autres abus. Consultez :
{{#ref}}
az-seamless-sso.md
{{#endref}}
## Pivotement Entra ID --> AD
## Pivoting Entra ID --> AD
- Si la réécriture de mot de passe est activée, vous pouvez **modifier le mot de passe de n'importe quel utilisateur dans l'AD** qui est synchronisé avec Entra ID.
- Si la réécriture de groupes est activée, vous pouvez **ajouter des utilisateurs à des groupes privilégiés** dans Entra ID qui sont synchronisés avec l'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