Refine hybrid pivot docs with current exploitability status

Author: carlospolop

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

@@ -16,15 +16,15 @@ This section covers the pivoting techniques to move from a compromised Entra ID
 
 - [**Connect Sync**](az-connect-sync.md): How to abuse Connect Sync to move from the cloud to on-premises AD and the other way around.
 
-- [**Connect Sync Policy Abuse**](az-connect-sync-policy-abuse.md): How to abuse Connect Sync access to modify internal policies (e.g., enable Seamless SSO or add external auth methods) and pivot from AD to Entra ID.
+- [**Connect Sync Policy Abuse**](az-connect-sync-policy-abuse.md): Historical Connect Sync internal-policy abuse paths (Seamless SSO key injection, auth-method manipulation), including what was patched and what to validate in legacy tenants.
 
 - [**Domain Services**](az-domain-services.md): What is the Azure Domain Services Service and how to pivot from Entra ID to the AD it generates.
 
 - [**Federation**](az-federation.md): How to abuse Federation to move from the cloud to on-premises AD and the other way around.
 
 - [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Miscellaneous attacks that can be used to pivot from the cloud to on-premises AD and the other way around.
 
-- [**Exchange Hybrid Impersonation (ACS Actor Tokens)**](az-exchange-hybrid-impersonation.md): How to abuse Exchange Hybrid to impersonate users across Exchange/SharePoint/Entra ID and pivot from AD to Entra ID.
+- [**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.
 
 - [**Local Cloud Credentials**](az-local-cloud-credentials.md): Where to find credentials to the cloud when a PC is compromised.
 
@@ -42,4 +42,3 @@ This section covers the pivoting techniques to move from a compromised Entra ID
 
 
 {{#include ../../../banners/hacktricks-training.md}}
-

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

@@ -4,41 +4,39 @@
 
 ## Basic Information
 
-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 Entra ID Connect Sync identity (historically a user account and later a service principal) was allowed to call undocumented `graph.windows.net` internal endpoints, including the `1.61-internal` API surface. Those endpoints exposed policy objects that were not visible or writable through standard public Graph paths, and that design created a direct AD-to-Entra pivot from an on-prem compromise.
 
-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.
+The important historical finding was not just "the sync account can update policies", but that these policy objects controlled authentication trust boundaries. In practice, this meant an attacker with Connect Sync credentials could reconfigure how Entra accepted first-factor and second-factor authentication signals for hybrid identities.
 
-## Attack Paths
+## Historical Attack Chain
 
 ### Enable Seamless SSO by Adding Kerberos Keys
 
-If the sync principal can modify the **On‑Premises Authentication Policy**, it can **add new key material** for Seamless SSO. This effectively **backdoors Seamless SSO** even if it was not enabled before.
+The on-premises authentication flow policy stored KeyCredential material used by Seamless SSO. Existing keys were not readable, but the sync identity could add new key entries. That distinction was enough for compromise: an operator did not need to extract current keys if they could append attacker-controlled keys and then mint Kerberos tickets with that material.
 
-High‑level flow:
+A subtle implementation detail made this more dangerous in multi-domain tenants. In Entra, hybrid users from different on-prem AD domains are not isolated in separate trust silos the way many defenders assume. By introducing key material under a tenant-owned `onmicrosoft.com` domain entry, the attacker could still target hybrid users across synchronized domains.
 
-- 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.
+Operationally, the flow was: obtain tokens as the sync identity, update the on-prem auth policy through internal Graph, insert attacker-controlled key credentials, and forge Seamless SSO tickets for target hybrid users.
 
-Notes from the talk:
+### Bypass MFA by Editing Authentication Methods Policy
 
-- 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).
+The default policy object (type `24`) contained tenant authentication method configuration. By adding an external authentication method provider there, an attacker could register a malicious MFA backend and make Entra accept that second factor for users in scope. This turned a Seamless SSO foothold into full hybrid-user impersonation even when MFA was enforced.
 
-### Abuse Authentication Methods Policy to Bypass MFA
+In other words, this was not a simple "disable MFA" control-plane change. It was more powerful because it allowed introducing an attacker-operated factor that still looked like compliant MFA from the relying party perspective.
 
-The sync principal can also modify **Authentication Methods Policy** (e.g., adding external authentication methods). This can allow an attacker to:
+### Conditional Access Policy Tampering (Patched Earlier)
 
-- **Add a custom external method** as a valid MFA provider.
-- Combine this with SSO/ADFS token forging to **satisfy MFA** requirements for hybrid users.
+A related path allowed modification of Conditional Access policy objects through internal Graph. Microsoft restricted that path in December 2023 to first-party applications, which removed this capability from the sync identity.
 
-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.
+## Logging and Detection Characteristics
 
-### (Historical) Conditional Access Policy Tampering
+A major defensive problem in this chain was telemetry quality. Changes often appeared as generic policy-update events with little or no field-level diff, and some operations generated no useful audit detail. That forced defenders to rely on secondary signals such as suspicious trust changes, unexpected authentication method providers, or newly introduced Seamless SSO key material.
 
-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).
+## Current Exploitability Status
+
+This Connect Sync policy-abuse pivot should be treated as a historical technique in modern tenants. Microsoft removed the sync identity's ability to modify Entra objects through these Graph write paths, which breaks the on-prem-to-cloud escalation chain described above.
+
+The technique remains relevant for retrospective incident response, old misconfigured environments, and understanding why stale overprivileged sync identities are high risk. It should not be documented as a broadly working AD-to-Entra path today.
 
 ## References
 

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

@@ -4,42 +4,41 @@
 
 ## 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** (commonly marked exportable) and use it to request **client‑credentials tokens** as Exchange Online.
+In legacy Exchange Hybrid designs, the on-prem Exchange deployment could authenticate as the same Entra application identity used by Exchange Online. If an attacker compromised the Exchange server, extracted the hybrid certificate private key, and performed an OAuth client-credentials flow, they could obtain first-party tokens with Exchange Online privilege context.
 
-This opens multiple pivot paths into Entra ID and other services.
+The practical risk was not limited to mailbox access. Because Exchange Online had broad back-end trust relationships, this identity could interact with additional Microsoft 365 services and, in older behavior, could be leveraged for deeper tenant compromise.
 
-## Attack Paths
+## Attack Paths and Technical Flow
 
 ### Modify Federation Configuration via Exchange
 
-Exchange Hybrid can **write domain federation configuration**. This can be abused to:
+Exchange tokens historically had permissions to write domain/federation settings. From an attacker perspective, this enabled direct manipulation of federated domain trust data, including token-signing certificate lists and configuration flags that controlled MFA-claim acceptance from on-prem federation infrastructure.
 
-- **Add a new token‑signing certificate** for a federated domain.
-- **Relax MFA claims acceptance** for ADFS‑issued tokens.
+That means a compromised Exchange Hybrid server could be used to stage or reinforce ADFS-style impersonation by changing federation config from the cloud side, even when the attacker started only from on-prem Exchange compromise.
 
-Once a malicious token‑signing cert is added (or MFA acceptance is loosened), an attacker can **forge ADFS tokens** and impersonate hybrid users in Entra ID.
+### ACS Actor Tokens and Service-to-Service Impersonation
 
-### ACS Actor Tokens → Impersonate Any User
+Exchange's hybrid auth path used Access Control Service (ACS) actor tokens with `trustedfordelegation=true`. Those actor tokens were then embedded into a second, unsigned service token that carried the target user identity in an attacker-controlled section. Because the outer token was unsigned and the actor token delegated broadly, the caller could swap target users without re-authenticating.
 
-Exchange can request **ACS actor tokens** that include **`trusted for delegation`**. Those tokens allow **service‑to‑service impersonation** across Exchange and other Microsoft 365 services.
+In practice, once the actor token was obtained, the attacker had a long-lived impersonation primitive (typically around 24 hours) that was difficult to revoke mid-lifetime. This enabled user impersonation across Exchange Online and SharePoint/OneDrive APIs, including high-value data exfiltration.
 
-Impact:
+Historically, the same pattern also worked against `graph.windows.net` by building an impersonation token with the victim's `netId` value. That provided direct Entra administrative action as arbitrary users and enabled full-tenant takeover workflows (for example, creating a new Global Administrator account).
 
-- **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`** parameter.
+## What No Longer Works
 
-Technical notes from the talk:
+The `graph.windows.net` impersonation path via Exchange Hybrid actor tokens has been fixed. The old "Exchange to arbitrary Entra admin over Graph" chain should be considered removed for this specific token route.
 
-- 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.
+This is the most important correction when documenting the attack: keep the Exchange/SharePoint impersonation risk separate from the now-patched Graph impersonation escalation.
 
-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.
+## What Can Still Matter in Practice
 
-### Detection Notes
+If an organization still runs an old or incomplete hybrid configuration with shared trust and exposed certificate material, Exchange/SharePoint impersonation impact can remain severe. The federation-configuration abuse angle can also remain relevant depending on tenant setup and migration state.
 
-Entra audit logs may show **odd mixed identities** (the impersonated user UPN combined with **Exchange Online** as the display name), which can be a detection signal for this abuse path.
+Microsoft's long-term mitigation is splitting the on-prem and Exchange Online identities so the shared-service-principal trust path no longer exists. Environments that completed that migration materially reduce this attack surface.
+
+## Detection Notes
+
+When this technique is abused, audit events can show identity mismatches where the user principal name corresponds to an impersonated user while the display/source context points to Exchange Online activity. That mixed identity pattern is a high-value hunting signal, though defenders should baseline legitimate Exchange-admin workflows to reduce false positives.
 
 ## References