Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md

@@ -4,35 +4,37 @@
 
 ## Podstawowe informacje
 
-Ta sekcja obejmuje pivoting techniques pozwalające przejść z przejętego dzierżawcy Entra ID do lokalnego Active Directory (AD) lub z przejętego AD do dzierżawcy Entra ID.
+Ta sekcja obejmuje techniki pivotowania umożliwiające przejście z przejętego tenanta Entra ID do lokalnego Active Directory (AD) lub z przejętego AD do tenanta Entra ID.
 
-## Pivoting Techniques
+## Techniki pivotowania
 
-- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Jeśli atakujący może kontrolować lub utworzyć konto komputera AD i uzyskać dostęp do Azure Arc GPO deployment share, może odszyfrować przechowywane Service Principal secret i użyć go do uwierzytelnienia się w Azure jako powiązany service principal, całkowicie kompromitując powiązane środowisko Azure.
+- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Jeśli atakujący może kontrolować lub utworzyć AD computer account i uzyskać dostęp do Azure Arc GPO deployment share, może odszyfrować przechowywane Service Principal secret i użyć go do uwierzytelnienia się w Azure jako powiązany service principal, całkowicie przejmując skojarzone środowisko Azure.
 
-- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Jak pivotować z Entra ID do AD, gdy skonfigurowano Cloud Kerberos Trust. Global Admin w Entra ID (Azure AD) może wykorzystać Cloud Kerberos Trust oraz sync API do podszycia się pod konta AD o wysokich uprawnieniach, uzyskania ich biletów Kerberos lub hashy NTLM oraz całkowitego przejęcia lokalnego Active Directory — nawet jeśli te konta nigdy nie były synchronizowane z chmurą — skutecznie łącząc eskalację uprawnień z chmury do AD.
+- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Jak pivotować z Entra ID do AD, gdy skonfigurowany jest Cloud Kerberos Trust. Global Admin w Entra ID (Azure AD) może nadużyć Cloud Kerberos Trust i sync API, aby podszyć się pod konta AD o wysokich uprawnieniach, pozyskać ich Kerberos tickets lub NTLM hashes i całkowicie przejąć on-prem Active Directory — nawet jeśli te konta nigdy nie były cloud-synced — efektywnie łącząc eskalację uprawnień z chmury do AD.
 
-- [**Cloud Sync**](az-cloud-sync.md): Jak wykorzystać Cloud Sync do przejścia z chmury do lokalnego AD i odwrotnie.
+- [**Cloud Sync**](az-cloud-sync.md): Jak nadużyć Cloud Sync, aby przemieścić się z chmury do on-premises AD i odwrotnie.
 
-- [**Connect Sync**](az-connect-sync.md): Jak wykorzystać Connect Sync do przejścia z chmury do lokalnego AD i odwrotnie.
+- [**Connect Sync**](az-connect-sync.md): Jak nadużyć Connect Sync, aby przemieścić się z chmury do on-premises AD i odwrotnie.
 
-- [**Domain Services**](az-domain-services.md): Czym jest Azure Domain Services Service i jak pivotować z Entra ID do AD, które ono generuje.
+- [**Domain Services**](az-domain-services.md): Czym jest Azure Domain Services oraz jak pivotować z Entra ID do AD, które ono generuje.
 
-- [**Federation**](az-federation.md): Jak wykorzystać Federation do przejścia z chmury do lokalnego AD i odwrotnie.
+- [**Federation**](az-federation.md): Jak nadużyć Federation, aby przejść z chmury do on-premises AD i odwrotnie.
 
-- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Różne ataki, które można wykorzystać do pivotowania z chmury do lokalnego AD i odwrotnie.
+- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Różne ataki, które można wykorzystać do pivotowania z chmury do on-premises AD i odwrotnie.
 
-- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Gdzie znaleźć poświadczenia do chmury, gdy PC zostanie przejęty.
+- [**Exchange Hybrid Impersonation (ACS Actor Tokens)**](az-exchange-hybrid-impersonation.md): Internals actor-token Exchange Hybrid, załatane vs wciąż istotne ścieżki nadużyć oraz jak ocenić ryzyko resztkowe po service-principal split migrations.
 
-- [**Pass the Certificate**](az-pass-the-certificate.md): Wygenerować certyfikat oparty na PRT, aby zalogować się z jednej maszyny na drugą.
+- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Gdzie znaleźć credentials do chmury, gdy PC jest przejęty.
+
+- [**Pass the Certificate**](az-pass-the-certificate.md): Wygenerowanie certyfikatu opartego na PRT, aby zalogować się z jednej maszyny na drugą.
 
 - [**Pass the Cookie**](az-pass-the-cookie.md): Ukradnij Azure cookies z przeglądarki i użyj ich do logowania.
 
-- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): Czym jest PRT, jak go ukraść i użyć do dostępu do zasobów Azure podszywając się pod użytkownika.
+- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): Co to jest PRT, jak je ukraść i użyć do dostępu do zasobów Azure podszywając się pod użytkownika.
 
-- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Jak wykorzystać Pass-through Authentication do przejścia z chmury do lokalnego AD i odwrotnie.
+- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Jak nadużyć Pass-through Authentication, aby przejść z chmury do on-premises AD i odwrotnie.
 
-- [**Seamless SSO**](az-seamless-sso.md): Jak wykorzystać Seamless SSO do przejścia z lokalnego środowiska do chmury.
+- [**Seamless SSO**](az-seamless-sso.md): Jak nadużyć Seamless SSO, aby przejść z on-prem do chmury.
 
 - **Another way to pivot from cloud to On-Prem is** [**abusing Intune**](../az-services/intune.md)
 

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}}
+
+## Podstawowe informacje
+
+W starszych projektach Exchange Hybrid lokalna instalacja Exchange mogła uwierzytelniać się jako ta sama tożsamość aplikacji Entra, której używa Exchange Online. Jeśli atakujący przejął serwer Exchange, wyodrębnił prywatny klucz certyfikatu hybrydowego i wykonał OAuth client-credentials flow, mógł uzyskać first-party tokens z kontekstem uprawnień Exchange Online.
+
+Ryzyko praktyczne nie ograniczało się do dostępu do skrzynek pocztowych. Ponieważ Exchange Online miało szerokie relacje zaufania po stronie zaplecza, ta tożsamość mogła oddziaływać z dodatkowymi usługami Microsoft 365 i, w starszym zachowaniu, być użyta do głębszego przejęcia tenanta.
+
+## Ścieżki ataku i przebieg techniczny
+
+### Modyfikacja konfiguracji federacji przez Exchange
+
+Exchange tokens historycznie miały uprawnienia do zapisu ustawień domeny/federacji. Z perspektywy atakującego pozwalało to na bezpośrednią manipulację danymi zaufania domen federowanych, w tym listami certyfikatów podpisujących tokeny i flagami konfiguracyjnymi kontrolującymi akceptację roszczeń MFA z infrastruktury federacyjnej on-prem.
+
+To oznacza, że skompromitowany serwer Exchange Hybrid mógł posłużyć do przygotowania lub wzmocnienia impersonacji w stylu ADFS przez zmianę konfiguracji federacji po stronie chmury, nawet jeśli atakujący zaczynał jedynie od kompromitacji lokalnego Exchange.
+
+### ACS Actor Tokens i impersonacja między usługami
+
+Ścieżka uwierzytelniania hybrydowego Exchange wykorzystywała Access Control Service (ACS) actor tokens z `trustedfordelegation=true`. Te actor tokens były następnie osadzane w drugim, niepodpisanym service tokenie, który przenosił tożsamość docelowego użytkownika w sekcji kontrolowanej przez atakującego. Ponieważ zewnętrzny token był niepodpisany, a actor token delegował szeroko, wywołujący mógł zamieniać docelowych użytkowników bez ponownego uwierzytelniania.
+
+W praktyce, po uzyskaniu actor tokena, atakujący dysponował długotrwałym mechanizmem impersonacji (zwykle około 24 godzin), który był trudny do unieważnienia w trakcie życia. Pozwalało to na impersonację użytkowników w Exchange Online oraz SharePoint/OneDrive APIs, w tym eksfiltrację danych o wysokiej wartości.
+
+Historycznie ten sam wzorzec działał też przeciwko `graph.windows.net` poprzez zbudowanie tokena impersonacji z wartością ofiary `netId`. To dawało bezpośrednie działania administracyjne w Entra jako dowolni użytkownicy i umożliwiało workflowy pełnego przejęcia tenanta (na przykład utworzenie nowego konta Global Administrator).
+
+## Co już nie działa
+
+Ścieżka impersonacji `graph.windows.net` przez Exchange Hybrid actor tokens została naprawiona. Stary łańcuch "Exchange to arbitrary Entra admin over Graph" należy uznać za usunięty dla tej konkretnej ścieżki tokena.
+
+To najważniejsza korekta przy dokumentowaniu ataku: oddziel ryzyko impersonacji Exchange/SharePoint od teraz załatanej eskalacji impersonacji przez Graph.
+
+## Co może nadal mieć znaczenie w praktyce
+
+Jeśli organizacja nadal działa na starej lub niekompletnej konfiguracji hybrid z współdzielonym zaufaniem i ujawnionym materiałem certyfikatu, wpływ impersonacji Exchange/SharePoint może pozostać poważny. Wektor nadużyć konfiguracji federacji również może być istotny w zależności od ustawień tenanta i stanu migracji.
+
+Długoterminowe rozwiązanie Microsoft polega na rozdzieleniu tożsamości on-prem i Exchange Online, tak aby ścieżka zaufania shared-service-principal przestała istnieć. Środowiska, które zakończyły tę migrację, znacząco zmniejszają tę powierzchnię ataku.
+
+## Notatki dotyczące wykrywania
+
+Gdy ta technika jest nadużywana, zdarzenia audytu mogą pokazywać niezgodności tożsamości, gdzie user principal name odpowiada impersonowanemu użytkownikowi, podczas gdy kontekst wyświetlania/źródła wskazuje na aktywność Exchange Online. Ten mieszany wzorzec tożsamości stanowi wartościowy sygnał do wykrywania incydentów (threat hunting), choć obrońcy powinni ustalić bazowe przepływy pracy administratorów Exchange, aby zmniejszyć liczbę fałszywych alarmów.
+
+## Bibliografia
+
+- https://www.youtube.com/watch?v=rzfAutv6sB8
+
+{{#include ../../../banners/hacktricks-training.md}}