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 a91457400..cc410c6bb 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,33 +4,35 @@
 
 ## Grundlegende Informationen
 
-Dieser Abschnitt behandelt die Pivoting-Techniken, um von einem kompromittierten Entra ID tenant in das lokale Active Directory (AD) zu gelangen oder von einem kompromittierten AD in den Entra ID tenant.
+Dieser Abschnitt behandelt die Pivoting-Techniken, um sich von einem kompromittierten Entra ID Tenant in das lokale Active Directory (AD) zu bewegen oder von einem kompromittierten AD in den Entra ID Tenant.
 
 ## Pivoting-Techniken
 
-- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Wenn ein Angreifer ein AD-Computerkonto kontrollieren oder erstellen und auf das Azure Arc GPO deployment share zugreifen kann, kann er das gespeicherte Service Principal secret entschlüsseln und es verwenden, um sich als der zugeordnete service principal bei Azure zu authentifizieren und die verknüpfte Azure-Umgebung vollständig zu kompromittieren.
+- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Wenn ein Angreifer ein AD-Computer-Konto kontrollieren oder erstellen und auf das Azure Arc GPO deployment share zugreifen kann, kann er das gespeicherte Service Principal secret entschlüsseln und es verwenden, um sich als der zugehörige Service Principal bei Azure zu authentifizieren und die verknüpfte Azure-Umgebung vollständig zu kompromittieren.
 
-- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Wie man von Entra ID zu AD pivotiert, wenn Cloud Kerberos Trust konfiguriert ist. Ein Global Admin in Entra ID (Azure AD) kann Cloud Kerberos Trust und die sync API missbrauchen, sich als hochprivilegierte AD-Konten ausgeben, deren Kerberos-Tickets oder NTLM-Hashes erhalten und das lokale Active Directory vollständig kompromittieren — selbst wenn diese Konten nie cloud-synced wurden — und damit effektiv eine Brücke für cloud-zu-AD Privilegienausweitung schlagen.
+- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Wie man von Entra ID zu AD pivotiert, wenn Cloud Kerberos Trust konfiguriert ist. Ein Global Admin in Entra ID (Azure AD) kann Cloud Kerberos Trust und die sync API missbrauchen, um sich als hoch-privilegierte AD-Konten auszugeben, ihre Kerberos-Tickets oder NTLM-Hashes zu erhalten und das lokale Active Directory vollständig zu kompromittieren — selbst wenn diese Konten nie cloud-synced wurden — und damit effektiv eine cloud-to-AD privilege escalation herbeiführen.
 
-- [**Cloud Sync**](az-cloud-sync.md): Wie man Cloud Sync missbraucht, um vom Cloud in das lokale AD und umgekehrt zu gelangen.
+- [**Cloud Sync**](az-cloud-sync.md): Wie man Cloud Sync missbraucht, um von der Cloud ins lokale AD und umgekehrt zu gelangen.
 
-- [**Connect Sync**](az-connect-sync.md): Wie man Connect Sync missbraucht, um vom Cloud in das lokale AD und umgekehrt zu gelangen.
+- [**Connect Sync**](az-connect-sync.md): Wie man Connect Sync missbraucht, um von der Cloud ins lokale AD und umgekehrt zu gelangen.
 
-- [**Domain Services**](az-domain-services.md): Was der Azure Domain Services Service ist und wie man von Entra ID zu dem von ihm erzeugten AD pivot.
+- [**Domain Services**](az-domain-services.md): Was der Azure Domain Services Service ist und wie man von Entra ID zu dem von ihm erzeugten AD pivotiert.
 
-- [**Federation**](az-federation.md): Wie man Federation missbraucht, um vom Cloud in das lokale AD und umgekehrt zu gelangen.
+- [**Federation**](az-federation.md): Wie man Federation missbraucht, um von der Cloud ins lokale AD und umgekehrt zu gelangen.
 
-- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Verschiedene Angriffe, die verwendet werden können, um vom Cloud in das lokale AD und umgekehrt zu pivot.
+- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Verschiedene Angriffe, die verwendet werden können, um von der Cloud ins lokale AD und umgekehrt zu pivotieren.
 
-- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Wo man Anmeldeinformationen für die Cloud findet, wenn ein PC kompromittiert wurde.
+- [**Exchange Hybrid Impersonation (ACS Actor Tokens)**](az-exchange-hybrid-impersonation.md): Interna von Exchange Hybrid actor-token, gepatchte vs. weiterhin relevante Missbrauchspfade und wie man das verbleibende Risiko nach service-principal split migrations bewertet.
 
-- [**Pass the Certificate**](az-pass-the-certificate.md): Erzeuge ein Zertifikat basierend auf dem PRT, um dich von einer Maschine auf eine andere einzuloggen.
+- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Wo man Credentials für die Cloud findet, wenn ein PC kompromittiert ist.
 
-- [**Pass the Cookie**](az-pass-the-cookie.md): Azure-Cookies aus dem Browser stehlen und sie zum Einloggen verwenden.
+- [**Pass the Certificate**](az-pass-the-certificate.md): Erzeuge ein cert basierend auf dem PRT, um sich von einem Rechner auf einen anderen einzuloggen.
 
-- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): Was das PRT ist, wie man es stiehlt und es verwendet, um auf Azure-Ressourcen zuzugreifen, indem man sich als der Benutzer ausgibt.
+- [**Pass the Cookie**](az-pass-the-cookie.md): Azure-Cookies aus dem Browser stehlen und zum Einloggen verwenden.
 
-- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Wie man Pass-through Authentication missbraucht, um vom Cloud in das lokale AD und umgekehrt zu gelangen.
+- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): Was der PRT ist, wie man ihn stiehlt und wie man ihn nutzt, um auf Azure-Ressourcen im Namen des Benutzers zuzugreifen.
+
+- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Wie man Pass-through Authentication missbraucht, um von der Cloud ins lokale AD und umgekehrt zu gelangen.
 
 - [**Seamless SSO**](az-seamless-sso.md): Wie man Seamless SSO missbraucht, um vom On-Prem in die Cloud zu gelangen.
 
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..0b319fd3f
--- /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}}
+
+## Grundlegende Informationen
+
+In veralteten Exchange Hybrid-Architekturen konnte die on-prem Exchange-Bereitstellung sich als dieselbe Entra-Anwendungsidentität authentifizieren, die auch von Exchange Online verwendet wurde. Wenn ein Angreifer den Exchange-Server kompromittierte, den privaten Schlüssel des Hybrid-Zertifikats extrahierte und einen OAuth client-credentials-Flow durchführte, konnte er First-Party-Tokens mit Exchange Online-Berechtigungskontext erhalten.
+
+Das praktische Risiko beschränkte sich nicht auf den Zugriff auf Postfächer. Da Exchange Online weitreichende Back-End-Vertrauensbeziehungen hatte, konnte diese Identität mit zusätzlichen Microsoft 365-Diensten interagieren und — in älterem Verhalten — für tiefere Tenant-Kompromittierungen genutzt werden.
+
+## Angriffswege und technischer Ablauf
+
+### Federation-Konfiguration über Exchange ändern
+
+Exchange-Tokens hatten historisch Berechtigungen, Domain-/Federation-Einstellungen zu schreiben. Aus Sicht eines Angreifers ermöglichte das die direkte Manipulation von Vertrauensdaten föderierter Domains, einschließlich Listen token-signierender Zertifikate und Konfigurationsflags, die die Akzeptanz von MFA-Claims von der on-prem Federation-Infrastruktur steuerten.
+
+Das bedeutet, dass ein kompromittierter Exchange Hybrid-Server dazu genutzt werden konnte, eine ADFS-ähnliche Impersonation zu inszenieren oder zu verstärken, indem die Federation-Konfiguration aus der Cloud heraus geändert wurde, selbst wenn der Angreifer nur mit einer on-prem Exchange-Kompromittierung begonnen hatte.
+
+### ACS Actor Tokens und Service-to-Service Impersonation
+
+Der Hybrid-Auth-Pfad von Exchange verwendete Access Control Service (ACS) actor tokens mit `trustedfordelegation=true`. Diese Actor-Tokens wurden dann in ein zweites, unsigniertes Service-Token eingebettet, das die Identität des Zielbenutzers in einem vom Angreifer kontrollierten Abschnitt trug. Da das äußere Token unsigniert war und das Actor-Token breit delegierte, konnte der Aufrufer Zielbenutzer austauschen, ohne sich erneut zu authentifizieren.
+
+In der Praxis hatte der Angreifer, sobald das Actor-Token beschafft war, eine langlebige Impersonation-Primitive (typischerweise etwa 24 Stunden), die schwer während ihrer Lebensdauer zu widerrufen war. Das ermöglichte Benutzer-Impersonation über Exchange Online- sowie SharePoint/OneDrive-APIs, einschließlich der Exfiltration hochsensibler Daten.
+
+Historisch funktionierte dasselbe Muster auch gegen `graph.windows.net`, indem ein Impersonation-Token mit dem `netId`-Wert des Opfers erstellt wurde. Das ermöglichte direkte Entra-administrative Aktionen als beliebige Benutzer und unterstützte vollständige Tenant-Übernahme-Workflows (zum Beispiel das Erstellen eines neuen Global Administrator-Kontos).
+
+## Was nicht mehr funktioniert
+
+Der `graph.windows.net`-Impersonation-Pfad über Exchange Hybrid Actor-Tokens wurde behoben. Die alte Kette "Exchange to arbitrary Entra admin over Graph" sollte für diese spezifische Token-Route als entfernt betrachtet werden.
+
+Dies ist die wichtigste Korrektur bei der Dokumentation des Angriffs: Halten Sie das Exchange/SharePoint-Impersonation-Risiko getrennt von der inzwischen gepatchten Graph-Impersonation-Eskalation.
+
+## Was in der Praxis weiterhin relevant sein kann
+
+Wenn eine Organisation noch eine alte oder unvollständige Hybrid-Konfiguration mit geteilter Trust-Stellung und offenem Zertifikatmaterial betreibt, kann die Auswirkung von Exchange/SharePoint-Impersonation weiterhin gravierend sein. Der Missbrauch der Federation-Konfiguration kann je nach Tenant-Setup und Migrationsstatus ebenfalls relevant bleiben.
+
+Microsofts langfristige Gegenmaßnahme besteht darin, die on-prem und Exchange Online-Identitäten zu trennen, sodass der Pfad des gemeinsamen Service-Principals nicht mehr existiert. Umgebungen, die diese Migration abgeschlossen haben, reduzieren diese Angriffsfläche erheblich.
+
+## Hinweise zur Erkennung
+
+Wenn diese Technik missbraucht wird, können Audit-Ereignisse Identitätsinkongruenzen zeigen, bei denen der user principal name einem impersonierten Benutzer entspricht, während der Anzeige-/Quellkontext auf Exchange Online-Aktivität hinweist. Dieses gemischte Identitätsmuster ist ein wertvolles Hunting-Signal; Verteidiger sollten jedoch legitime Exchange-Admin-Workflows als Basislinie definieren, um False Positives zu reduzieren.
+
+## Referenzen
+
+- https://www.youtube.com/watch?v=rzfAutv6sB8
+
+{{#include ../../../banners/hacktricks-training.md}}