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

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

@@ -2,39 +2,41 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Основна інформація
+## Базова інформація
 
-У цьому розділі описані техніки pivoting, що дозволяють переміщуватися зі скомпрометованого Entra ID tenant до локального Active Directory (AD) або навпаки — із скомпрометованого AD у Entra ID tenant.
+У цьому розділі описані техніки pivoting для переходу з скомпрометованого тенанта Entra ID у локальний Active Directory (AD) або з скомпрометованого AD у тенант Entra ID.
 
 ## Pivoting Techniques
 
-- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Якщо нападник може контролювати або створити AD computer account і отримати доступ до Azure Arc GPO deployment share, він може розшифрувати збережений Service Principal secret і використати його для автентифікації в Azure як відповідний service principal, повністю скомпрометувавши пов’язане середовище Azure.
+- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Якщо нападник може контролювати або створити обліковий запис комп'ютера в AD і отримати доступ до Azure Arc GPO deployment share, він може розшифрувати збережений Service Principal secret і використати його для автентифікації в Azure як відповідний service principal, повністю скомпрометувавши пов'язане Azure-середовище.
 
-- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Як pivot з Entra ID до AD, коли налаштовано Cloud Kerberos Trust. Global Admin в Entra ID (Azure AD) може зловживати Cloud Kerberos Trust і sync API, щоб видавати себе за облікові записи AD з високими привілеями, отримувати їхні Kerberos tickets або NTLM hashes і повністю скомпрометувати локальний Active Directory — навіть якщо ці облікові записи ніколи не були cloud-synced — фактично створивши міст між підвищенням привілеїв з cloud до AD.
+- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): How to pivot from Entra ID to AD when Cloud Kerberos Trust is configured. Global Admin в Entra ID (Azure AD) може зловживати Cloud Kerberos Trust і sync API, щоб видавати себе за облікові записи AD з високими привілеями, отримувати їхні Kerberos tickets або NTLM hashes і повністю скомпрометувати локальний Active Directory — навіть якщо ці облікові записи ніколи не були синхронізовані в хмару — фактично створюючи міст між cloud і AD для ескалації привілеїв.
 
-- [**Cloud Sync**](az-cloud-sync.md): Як зловживати Cloud Sync, щоб переміщуватися з хмари в локальний AD і навпаки.
+- [**Cloud Sync**](az-cloud-sync.md): Як зловживати Cloud Sync для переходу з хмари в локальний AD та навпаки.
 
-- [**Connect Sync**](az-connect-sync.md): Як зловживати Connect Sync, щоб переміщуватися з хмари в локальний AD і навпаки.
+- [**Connect Sync**](az-connect-sync.md): Як зловживати Connect Sync для переходу з хмари в локальний AD та навпаки.
 
-- [**Domain Services**](az-domain-services.md): Що таке Azure Domain Services Service і як pivot з Entra ID до того AD, який воно генерує.
+- [**Domain Services**](az-domain-services.md): Що таке Azure Domain Services і як перейти з Entra ID в AD, який він створює.
 
-- [**Federation**](az-federation.md): Як зловживати Federation, щоб переміщуватися з хмари в локальний AD і навпаки.
+- [**Federation**](az-federation.md): Як зловживати Federation для переходу з хмари в локальний AD та навпаки.
 
-- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Різні атаки, які можна використовувати для pivot з хмари в локальний AD і навпаки.
+- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Різноманітні атаки, які можна використати для переходу з хмари в локальний AD та навпаки.
 
-- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Де шукати креденціали до хмари, коли ПК скомпрометовано.
+- [**Exchange Hybrid Impersonation (ACS Actor Tokens)**](az-exchange-hybrid-impersonation.md): Exchange Hybrid actor-token internals, patched vs still-relevant abuse paths, and how to assess residual risk after service-principal split migrations.
 
-- [**Pass the Certificate**](az-pass-the-certificate.md): Згенерувати cert на основі PRT, щоб увійти з однієї машини на іншу.
+- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Де шукати облікові дані до cloud, коли ПК скомпрометовано.
 
-- [**Pass the Cookie**](az-pass-the-cookie.md): Викрасти Azure cookie з браузера і використати їх для входу.
+- [**Pass the Certificate**](az-pass-the-certificate.md): Generate a cert based on the PRT to login from one machine to another.
 
-- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): Що таке PRT, як його вкрасти і використати для доступу до Azure resources від імені користувача.
+- [**Pass the Cookie**](az-pass-the-cookie.md): Вкрасти Azure cookies з браузера і використати їх для входу.
 
-- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Як зловживати Pass-through Authentication, щоб переміщуватися з хмари в локальний AD і навпаки.
+- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): Що таке PRT, як його вкрасти і використовувати для доступу до ресурсів Azure, видаючи себе за користувача.
 
-- [**Seamless SSO**](az-seamless-sso.md): Як зловживати Seamless SSO, щоб переміщуватися з on-prem в cloud.
+- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Як зловживати Pass-through Authentication для переходу з хмари в локальний AD та навпаки.
 
-- **Another way to pivot from cloud to On-Prem is** [**abusing Intune**](../az-services/intune.md)
+- [**Seamless SSO**](az-seamless-sso.md): Як зловживати Seamless SSO для переходу з локальної інфраструктури в cloud.
+
+- **Ще один спосіб перейти з хмари в On-Prem —** [**abusing Intune**](../az-services/intune.md)
 
 
 {{#include ../../../banners/hacktricks-training.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}}
+
+## Основна інформація
+
+У застарілих дизайнах Exchange Hybrid, on-prem розгортання Exchange могло автентифікуватися як та сама Entra application identity, яку використовує Exchange Online. Якщо атакуючий скомпрометував сервер Exchange, витягнув приватний ключ гібридного сертифіката і виконав OAuth client-credentials flow, він міг отримати first-party tokens з контекстом привілеїв Exchange Online.
+
+Практичний ризик не обмежувався доступом до mailbox. Оскільки Exchange Online мав широкі back-end довірчі відносини, ця identity могла взаємодіяти з додатковими Microsoft 365 сервісами і, у старій поведінці, могла бути використана для глибшого компрометації tenant.
+
+## Шляхи атаки та технічний потік
+
+### Зміна конфігурації федерації через Exchange
+
+Exchange tokens історично мали дозволи на запис налаштувань домену/federation. З точки зору атакуючого, це дозволяло пряму маніпуляцію даними довіри federated domain, включаючи списки token-signing certificate та конфігураційні прапорці, що контролювали MFA-claim прийняття з on-prem federation інфраструктури.
+
+Це означає, що скомпрометований Exchange Hybrid сервер міг бути використаний для підготовки або посилення ADFS-style impersonation шляхом зміни federation config з боку cloud, навіть якщо атакуючий починав лише з on-prem Exchange компрометації.
+
+### ACS Actor Tokens і сервіс-до-сервісної імперсонації
+
+Exchange's hybrid auth path використовував Access Control Service (ACS) actor tokens з `trustedfordelegation=true`. Ці actor tokens потім вбудовувалися у другий, unsigned service token, який ніс identity цільового користувача у секції, контрольованій атакуючим. Оскільки зовнішній токен був unsigned, а actor token делегував широко, викликач міг змінювати цільових користувачів без повторної автентифікації.
+
+На практиці, як тільки actor token був отриманий, атакуючий мав довготривалий імперсонаційний примітив (зазвичай близько 24 годин), який важко відкликати посеред життєвого циклу. Це давало змогу імперсонувати користувачів через Exchange Online та SharePoint/OneDrive APIs, включаючи high-value data exfiltration.
+
+Історично такий же патерн також працював проти `graph.windows.net` шляхом побудови impersonation token з `netId` жертви. Це забезпечувало прямі Entra адміністративні дії від імені довільних користувачів і дозволяло workflows повного takeover tenant (наприклад, створення нового Global Administrator акаунта).
+
+## Що більше не працює
+
+Шлях impersonation через `graph.windows.net` через Exchange Hybrid actor tokens був виправлений. Старий ланцюжок "Exchange to arbitrary Entra admin over Graph" слід вважати вилученим для цього конкретного маршруту токена.
+
+Це найважливіша корекція при документуванні атаки: тримайте ризик Exchange/SharePoint impersonation окремо від тепер виправленого Graph impersonation escalation.
+
+## Що все ще може мати значення на практиці
+
+Якщо організація досі працює зі старою або неповною hybrid конфігурацією з shared trust і відкритими сертифікатними матеріалами, вплив Exchange/SharePoint impersonation може залишатися серйозним. Кут зловживання federation-configuration також може залишатися релевантним в залежності від налаштування tenant і стану міграції.
+
+Довгострокова міграція Microsoft — розділення on-prem і Exchange Online identities, щоб шлях shared-service-principal trust більше не існував. Середовища, які завершили цю міграцію, суттєво зменшують цю attack surface.
+
+## Примітки щодо виявлення
+
+Коли ця техніка зловживається, audit events можуть показувати невідповідності identity, де user principal name відповідає імперсонованому користувачу, тоді як display/source контекст вказує на активність Exchange Online. Такий змішаний патерн identity — високоякісний сигнал для hunting, хоча захисникам слід базувати baseline легітимних Exchange-admin workflows, щоб зменшити false positives.
+
+## References
+
+- https://www.youtube.com/watch?v=rzfAutv6sB8
+
+{{#include ../../../banners/hacktricks-training.md}}