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

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md

@@ -6,7 +6,7 @@
 
 **Cloud Sync** est essentiellement la nouvelle façon d'Azure de **synchroniser les utilisateurs d'AD dans Entra ID**.
 
-[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) 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 réalisé 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.
+[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) 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
 
@@ -43,14 +43,14 @@ az-connect-sync.md
 
 ### AD --> Entra ID
 
-- Si les utilisateurs de l'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)**.
+- 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 **`provAgentgMSA`** credentials :
+Pour compromettre les identifiants de **`provAgentgMSA`** :
 ```powershell
 # Enumerate provAgentgMSA account
 Get-ADServiceAccount -Filter * -Server domain.local
@@ -81,10 +81,10 @@ https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/i
 {{#endref}}
 
 > [!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 d'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 exploiter :
+> 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 :
 
 {{#ref}}
-../../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
+../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
 {{#endref}}
 
 Concernant la persistance, [cet article de blog](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) suggère qu'il est possible d'utiliser [**dnSpy**](https://github.com/dnSpy/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) :
@@ -129,12 +129,12 @@ C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.C
 
 - Si **Password Writeback** est activé, vous pourriez modifier le mot de passe de certains utilisateurs d'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](./az-connect-sync.md) 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 un certain 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](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits):
+- À ce stade, Cloud Sync permet également **"Microsoft Entra ID to AD"**, mais après un certain 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](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 qui 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 à partir duquel les utilisateurs sont synchronisés afin de compromettre un utilisateur dans l'autre domaine (et les deux doivent apparemment être dans 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 à partir duquel 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