Az - Exchange Hybrid Impersonation (ACS Actor Tokens)

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.

Informations de base

Dans les architectures Exchange Hybrid héritées, le déploiement Exchange sur site (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 tokens first-party avec le contexte de privilèges d’Exchange Online.

Le risque pratique ne se limitait pas à l’accès aux boîtes aux lettres. Parce qu’Exchange Online disposait de larges relations de confiance back-end, cette identité pouvait interagir avec d’autres services Microsoft 365 et, dans un comportement plus ancien, pouvait être exploitée pour une compromission plus profonde du tenant.

Voies d’attaque et déroulement technique

Modification de la configuration de fédération via Exchange

Historiquement, les tokens Exchange avaient la permission d’écrire les paramètres de domaine/fédération. Du point de vue d’un attaquant, cela permettait la manipulation directe des données de confiance des domaines fédérés, y compris les listes de certificats de signature de token et les flags de configuration qui contrôlaient l’acceptation des MFA-claim depuis l’infrastructure de fédération on-prem.

Cela signifie qu’un serveur Exchange Hybrid compromis pouvait être utilisé pour préparer ou renforcer une impersonation de type ADFS en modifiant la config de fédération depuis le cloud, même si l’attaquant avait démarré uniquement par une compromission Exchange sur site.

ACS Actor Tokens et impersonation service-to-service

Le chemin d’auth hybride d’Exchange utilisait des Access Control Service (ACS) actor tokens avec trustedfordelegation=true. Ces actor tokens étaient ensuite incorporés dans un second service token non signé qui portait l’identité de l’utilisateur cible dans une section contrôlée par l’attaquant. Parce que le token externe était non signé et que l’actor token déléguait largement, l’appelant pouvait remplacer les utilisateurs cibles sans se ré-authentifier.

En pratique, une fois l’actor token obtenu, l’attaquant disposait d’un primitive d’impersonation longue durée (souvent autour de 24 heures) difficile à révoquer en cours de vie. Cela permettait l’impersonation 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’impersonation avec la valeur netId de la victime. Cela fournissait des actions administratives Entra directes en tant qu’utilisateurs arbitraires et permettait des workflows de prise de contrôle complète du tenant (par exemple, la création d’un nouveau compte Global Administrator).

Ce qui ne fonctionne plus

Le chemin d’impersonation via graph.windows.net par les Exchange Hybrid actor tokens a été corrigé. L’ancienne chaîne “Exchange vers un Entra admin arbitraire via Graph” doit être considérée comme supprimée pour cette route de token spécifique.

Ceci est la correction la plus importante lors de la documentation de l’attaque : garder le risque d’impersonation Exchange/SharePoint séparé de l’escalade d’impersonation Graph désormais patchée.

Ce qui peut encore importe 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 d’impersonation 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 est de séparer les identités on-prem et Exchange Online afin que le chemin de confiance du service principal partagé n’existe plus. Les environnements ayant complété cette migration réduisent substantiellement cette surface d’attaque.

Notes de détection

Quand cette technique est abusée, les événements d’audit peuvent montrer des mismatchs d’identité où le user principal name correspond à un utilisateur impersonné tandis que le contexte d’affichage/source pointe vers une activité Exchange Online. Ce pattern d’identité mixte est un signal de chasse hautement utile, bien que les défenseurs doivent baseliner les workflows légitimes d’admin Exchange pour réduire les faux positifs.

Références

• https://www.youtube.com/watch?v=rzfAutv6sB8

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.