diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md index 3d4009cf7..4bac82850 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md @@ -4,37 +4,39 @@ ## Informations de base -Cette section couvre les techniques de pivot pour passer d'un tenant Entra ID compromis vers l'Active Directory (AD) sur site ou d'un AD compromis vers le tenant Entra ID. +Cette section couvre les techniques de pivot permettant de passer d'un tenant Entra ID compromis vers l'Active Directory (AD) sur site, ou d'un AD compromis vers le tenant Entra ID. ## Techniques de pivot -- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Si un attaquant peut contrôler ou créer un compte ordinateur AD et accéder au partage de déploiement GPO d'Azure Arc, il peut déchiffrer le secret du Service Principal stocké et l'utiliser pour s'authentifier à Azure en tant que service principal associé, compromettant totalement l'environnement Azure lié. +- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Si un attaquant peut contrôler ou créer un compte ordinateur AD et accéder au partage de déploiement GPO Azure Arc, il peut déchiffrer le secret du Service Principal stocké et l'utiliser pour s'authentifier auprès d'Azure en tant que service principal associé, compromettant complètement l'environnement Azure lié. -- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Comment pivoter depuis Entra ID vers AD lorsque Cloud Kerberos Trust est configuré. Un Global Admin dans Entra ID (Azure AD) peut abuser de Cloud Kerberos Trust et de l'API de sync pour usurper des comptes AD à haut privilège, obtenir leurs tickets Kerberos ou hachages NTLM, et compromettre totalement l'Active Directory sur site — même si ces comptes n'ont jamais été synchronisés vers le cloud — réalisant ainsi une élévation de privilèges du cloud vers AD. +- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Comment pivoter d'Entra ID vers AD lorsque Cloud Kerberos Trust est configuré. Un Global Admin dans Entra ID (Azure AD) peut abuser de Cloud Kerberos Trust et de la sync API pour usurper des comptes AD à haute privilège, obtenir leurs tickets Kerberos ou leurs hachages NTLM, et compromettre complètement l'Active Directory sur site — même si ces comptes n'ont jamais été synchronisés vers le cloud — établissant ainsi une passerelle de montée en privilèges du cloud vers l'AD. - [**Cloud Sync**](az-cloud-sync.md): Comment abuser de Cloud Sync pour passer du cloud vers l'AD sur site et inversement. - [**Connect Sync**](az-connect-sync.md): Comment abuser de Connect Sync pour passer du cloud vers l'AD sur site et inversement. -- [**Domain Services**](az-domain-services.md): Qu'est-ce que le service Azure Domain Services et comment pivoter depuis Entra ID vers l'AD qu'il génère. +- [**Domain Services**](az-domain-services.md): Qu'est-ce que le service Azure Domain Services et comment pivoter d'Entra ID vers l'AD qu'il génère. - [**Federation**](az-federation.md): Comment abuser de Federation pour passer du cloud vers l'AD sur site et inversement. - [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Attaques diverses pouvant être utilisées pour pivoter du cloud vers l'AD sur site et inversement. -- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Où trouver des identifiants pour le cloud lorsqu'un PC est compromis. +- [**Exchange Hybrid Impersonation (ACS Actor Tokens)**](az-exchange-hybrid-impersonation.md): Internes des actor-tokens Exchange Hybrid, voies d'abus corrigées vs encore pertinentes, et comment évaluer le risque résiduel après des migrations avec séparation de service-principal. + +- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Où trouver les identifiants pour le cloud lorsqu'un PC est compromis. - [**Pass the Certificate**](az-pass-the-certificate.md): Générer un certificat basé sur le PRT pour se connecter d'une machine à une autre. - [**Pass the Cookie**](az-pass-the-cookie.md): Voler les cookies Azure depuis le navigateur et les utiliser pour se connecter. -- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): Qu'est-ce que le PRT, comment le voler et l'utiliser pour accéder aux ressources Azure en usurpant l'utilisateur. +- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): Qu'est-ce que le PRT, comment le voler et l'utiliser pour accéder aux ressources Azure en se faisant passer pour l'utilisateur. - [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Comment abuser de Pass-through Authentication pour passer du cloud vers l'AD sur site et inversement. -- [**Seamless SSO**](az-seamless-sso.md): Comment abuser de Seamless SSO pour passer du sur site vers le cloud. +- [**Seamless SSO**](az-seamless-sso.md): Comment abuser de Seamless SSO pour passer du on-prem vers le cloud. -- **Another way to pivot from cloud to On-Prem is** [**abusing Intune**](../az-services/intune.md) +- **Une autre façon de pivoter du cloud vers On-Prem est** [**abusing Intune**](../az-services/intune.md) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.md new file mode 100644 index 000000000..eb9e313a6 --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.md @@ -0,0 +1,47 @@ +# Az - Exchange Hybrid Impersonation (ACS Actor Tokens) + +{{#include ../../../banners/hacktricks-training.md}} + +## Informations de base + +Dans les architectures Exchange Hybrid legacy, le déploiement Exchange on-prem pouvait s'authentifier en tant que la même identité d'application Entra utilisée par Exchange Online. Si un attaquant compromettait le serveur Exchange, extrayait la clé privée du certificat hybride et effectuait un flux OAuth client-credentials, il pouvait obtenir des first-party tokens avec le contexte de privilèges d'Exchange Online. + +Le risque pratique ne se limitait pas à l'accès aux boîtes aux lettres. Comme Exchange Online avait de larges relations de confiance back-end, cette identité pouvait interagir avec d'autres services Microsoft 365 et, dans des comportements plus anciens, être exploitée pour une compromission plus profonde du tenant. + +## Voies d'attaque et flux technique + +### Modifier la configuration de fédération via Exchange + +Les Exchange tokens avaient historiquement des permissions pour écrire les paramètres de domaine/fédération. Du point de vue de l'attaquant, cela permettait la manipulation directe des données de confiance de domaine fédéré, y compris les listes de certificats de signature de token et les flags de configuration qui contrôlaient l'acceptation des revendications MFA depuis l'infrastructure de fédération on-prem. + +Cela signifie qu'un serveur Exchange Hybrid compromis pouvait être utilisé pour orchestrer ou renforcer une usurpation de type ADFS en modifiant la configuration de fédération depuis le côté cloud, même si l'attaque avait débuté uniquement par une compromission Exchange on-prem. + +### ACS Actor Tokens and Service-to-Service Impersonation + +Le chemin d'auth hybride d'Exchange utilisait Access Control Service (ACS) actor tokens avec `trustedfordelegation=true`. Ces actor tokens étaient ensuite intégrés dans un second service token non signé qui portait l'identité de l'utilisateur ciblé dans une section contrôlée par l'attaquant. Parce que le token externe n'était pas signé et que l'actor token délégait largement, l'appelant pouvait remplacer les utilisateurs cibles sans se réauthentifier. + +En pratique, une fois l'actor token obtenu, l'attaquant disposait d'une primitive d'usurpation durable (typiquement autour de 24 heures) difficile à révoquer en plein cycle de vie. Cela permettait l'usurpation d'utilisateurs à travers les APIs Exchange Online et SharePoint/OneDrive, y compris l'exfiltration de données à forte valeur. + +Historiquement, le même schéma fonctionnait aussi contre `graph.windows.net` en construisant un token d'usurpation avec la valeur `netId` de la victime. Cela permettait une action administrative Entra directe en tant qu'utilisateurs arbitraires et autorisait des workflows de takeover total du tenant (par exemple, la création d'un nouveau compte Global Administrator). + +## Ce qui ne fonctionne plus + +Le chemin d'usurpation `graph.windows.net` via les Exchange Hybrid actor tokens a été corrigé. L'ancienne chaîne "Exchange to arbitrary Entra admin over Graph" doit être considérée comme supprimée pour cette route de token spécifique. + +C'est la correction la plus importante à signaler dans la documentation de l'attaque : séparer le risque d'usurpation Exchange/SharePoint de l'escalade d'usurpation Graph maintenant patchée. + +## Ce qui peut encore être pertinent en pratique + +Si une organisation exécute encore une configuration hybrid ancienne ou incomplète avec une confiance partagée et du matériel de certificat exposé, l'impact de l'usurpation Exchange/SharePoint peut rester sévère. L'angle d'abus de la configuration de fédération peut aussi rester pertinent selon la configuration du tenant et l'état de migration. + +La mitigation long terme de Microsoft consiste à séparer les identités on-prem et Exchange Online afin que le chemin de confiance du shared-service-principal n'existe plus. Les environnements ayant réalisé cette migration réduisent matériellement cette surface d'attaque. + +## Notes de détection + +Lorsque cette technique est abusée, les événements d'audit peuvent montrer des discordances d'identité où le user principal name correspond à un utilisateur usurpé tandis que le contexte d'affichage/source pointe vers une activité Exchange Online. Ce schéma d'identité mixte est un signal de chasse à haute valeur, bien que les défenseurs devraient baseliner les workflows légitimes d'Exchange-admin pour réduire les faux positifs. + +## Références + +- https://www.youtube.com/watch?v=rzfAutv6sB8 + +{{#include ../../../banners/hacktricks-training.md}}