Add technical details for AD-to-Entra pivot techniques

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync-policy-abuse.md

@@ -4,7 +4,7 @@
 
 ## Basic Information
 
-The **Entra ID Connect Sync** account (or its service principal) can access **internal Graph endpoints** (notably `graph.windows.net` internal API versions). With that access it can **modify tenant policies** beyond simple directory sync, which enables **new pivot paths from on‑prem AD to Entra ID**.
+The **Entra ID Connect Sync** account (or its service principal) can access **internal Graph endpoints** (notably **`graph.windows.net` internal versions** such as the **`1.61-internal`** API). With that access it can **modify tenant policies** beyond simple directory sync, which enables **new pivot paths from on‑prem AD to Entra ID**.
 
 The techniques below are based on practical research and are especially relevant in hybrid environments where Connect Sync is present but ADFS/Seamless SSO are not explicitly enabled.
 
@@ -16,11 +16,16 @@ If the sync principal can modify the **On‑Premises Authentication Policy**, it
 
 High‑level flow:
 
-- Use Connect Sync credentials (user or service principal) to obtain tokens for `graph.windows.net` internal API.
-- Modify the **On‑Premises Authentication Policy** and **add KeyCredentials** for a target domain.
-- Use the newly added key to **forge Kerberos tickets** for **hybrid users**, enabling SSO‑based cloud authentication.
+- Use Connect Sync credentials (user or service principal) to obtain tokens for **`graph.windows.net` internal API**.
+- Query/modify the **On‑Premises Authentication Policy** object.
+- **Add new KeyCredentials** for a target domain. The policy stores **symmetric Kerberos keys** used by Seamless SSO.
+- Use the **new key material** to **forge Kerberos tickets** for **hybrid users**, enabling SSO‑based cloud authentication.
 
-This enables AD‑to‑Entra impersonation without needing to steal existing key material. In practice, policy changes are **poorly logged** (often only “policy changed” without details).
+Notes from the talk:
+
+- Existing keys are **not readable** (even as Global Admin), but **new keys can be added**.
+- Adding keys effectively **backdoors Seamless SSO** without enabling it through normal admin flows.
+- Audit visibility is minimal: policy changes are **poorly logged** (often only “policy changed” without details).
 
 ### Abuse Authentication Methods Policy to Bypass MFA
 
@@ -29,7 +34,11 @@ The sync principal can also modify **Authentication Methods Policy** (e.g., addi
 - **Add a custom external method** as a valid MFA provider.
 - Combine this with SSO/ADFS token forging to **satisfy MFA** requirements for hybrid users.
 
-This is useful when MFA is enforced but the policy itself can be modified via internal Graph endpoints.
+This is useful when MFA is enforced but the policy itself can be modified via internal Graph endpoints. The talk notes that policy updates may only show a **generic “policy changed”** entry without details.
+
+### (Historical) Conditional Access Policy Tampering
+
+The talk also mentions that **Conditional Access Policies** could historically be modified through internal Graph endpoints by the sync principal, but this was **patched in December 2023** (restricted to first‑party apps). The **policy‑abuse path still applies** for other policy types (on‑prem auth, auth methods, password management, external identities).
 
 ## References
 

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.md

@@ -4,7 +4,7 @@
 
 ## Basic Information
 
-In **Exchange Hybrid** deployments, the on‑prem Exchange server shares a **service principal identity** with Exchange Online. If an attacker compromises the on‑prem Exchange server, they can often **export the hybrid certificate** and use it to request **client‑credentials tokens** as Exchange Online.
+In **Exchange Hybrid** deployments, the on‑prem Exchange server shares a **service principal identity** with Exchange Online. If an attacker compromises the on‑prem Exchange server, they can often **export the hybrid certificate** (commonly marked exportable) and use it to request **client‑credentials tokens** as Exchange Online.
 
 This opens multiple pivot paths into Entra ID and other services.
 
@@ -27,7 +27,13 @@ Impact:
 
 - **Impersonate any mailbox user** in Exchange Online.
 - **Access SharePoint/OneDrive** as any user (Exchange uses those services under the hood).
-- **Impersonate Entra ID users** via `graph.windows.net` by crafting tokens with the target **`netId`**.
+- **Impersonate Entra ID users** via `graph.windows.net` by crafting tokens with the target **`netId`** parameter.
+
+Technical notes from the talk:
+
+- The actor token is **issued by ACS**, contains the **Exchange audience**, and has **`trusted for delegation`** set.
+- The actor token is embedded into an **unsigned bearer token**, where the **target user** is placed in the unsigned portion.
+- For `graph.windows.net`, the call requires a **`netId`** value for the impersonated user (distinct from UPN). Exchange can query this and reuse it in the crafted token.
 
 These actor tokens are **not subject to Conditional Access** and are typically valid for long periods (e.g., ~24 hours). With them, an attacker can perform **Entra ID admin actions** (e.g., create a Global Admin), resulting in full tenant compromise.