# Finding Entra ID CA bypasses the structured way
# Author Introduction
## **Fabian Bader**
- 居住地：德國
- 職位：Cyber Security Architect / Researcher @ glueckkanja AG
- 榮譽：Microsoft MVP
- 首次於 TROOPERS 發表演講
- 社群角色：Purple Elbe Security User Group 主辦人
- 工具作者：
- `TokenTacticsV2`
- `SentinelARConverter`

---

## **Dirk-jan Mollema**
- 居住地：荷蘭
- 身分：Hacker / Researcher / Founder / Trainer @ Outsider Security
- 榮譽：Microsoft MVP 和 MVR
- TROOPERS 資深演講者（自 2019 起）
- 著名工具作者（專注於 Active Directory 與 Entra ID）：
- `mitm6`
- `ldapdomaindump`
- `adidnsdump`
- `BloodHound.py`
- `ntlmrelayx` / `krbrelayx`
- `ROADtools`

# Motivation & Goals

- With all first-party apps we could find from the internet + customer environments:
- 1. Sign in to all the clients
- 2. Get tokens for all the resources
- 3. Find all the scopes
- 4. Find all the possible CA bypasses for these scopes

# Background
## Azure Entra ID
Azure Entra ID 就是「雲端版 AD + OAuth2 身分憑證中心」，把身份、設備、權限、資源的存取整合起來，讓各種 SaaS/PaaS/IaaS 服務都能在相同的身份框架下驗證與授權。

接下來有關的名詞基本上都是在 Azure Entra ID 這個 SaaS 服務的應用架構下去理解的。提醒這點主要是 Azure 中部份的專有名詞有所重疊，但定義卻不同。

如 Entra ID 的 App 指的是註冊於 Entra ID 的 Application，而不完全指 Azure app service 的 Cloud Native SaaS 服務。

## Apps, Clients, Resources, Scopes, FOCI 簡介
### Apps

- 定義
Apps（應用程式）在 Azure AD 中指的是註冊於目錄下、需要存取資源或執行身分驗證的軟體元件。每個 App 會有唯一的 Client ID（Application ID），可設定權限、憑證等。

- 用途
讓開發者將自家服務、網站、API 或自動化腳本與 Azure 生態系整合。控制哪些應用可以代表使用者或自己存取哪些資源。像是與 Micrisoft Teams 做整合。

像是有一個 HR 用的 Application 想要進行使用者身份驗證，如 log in 之類的。但又不想自己架設驗證服務，所以用 Entra ID 託管驗證的職能，讓使用者利用 Azure 帳戶來登錄。


- 參考資料
[Microsoft: Application and service principal objects in Azure Active Directory](https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals?tabs=browser)

### Clients
- 定義
Clients（用戶端）是指發起存取請求的軟體，通常是註冊於 Azure AD 的應用程式本身，也可能是使用者操作的瀏覽器、行動裝置 App、桌面程式等。
- 用途
代表使用者或服務主體向 Azure AD 請求 access token。

依據不同情境，client 可能是 public client（無密碼，例如手機 App）或 confidential client（有密碼/憑證，例如伺服器程式）。


- Reference
[Microsoft: Types of client applications](https://learn.microsoft.com/en-us/entra/identity-platform/v2-app-types)

### Resources

- 定義
Resources（資源）是被保護的服務或 API，例如 Microsoft Graph、SharePoint Online、Azure Key Vault 等。資源會定義可被請求的權限（scopes/roles）。

- 大概用來幹嘛
作為 OAuth 2.0 授權流程中「資源伺服器」角色，驗證 access token 並決定是否允許存取。控制哪些應用/使用者可以對哪些資源進行哪些操作。


- Reference
[Microsoft: Protected resources and resource servers](https://learn.microsoft.com/en-us/entra/identity-platform/permissions-consent-overview#resource-servers)

### Scopes
- 定義
Scopes 是應用程式請求的細項權限，描述可對資源執行的操作。例如 User.Read 代表讀取使用者資訊。

- 大概用來幹嘛
精細化授權，讓應用程式只獲得所需最小權限（最小權限原則）。在 OAuth 2.0 流程中，client 會在請求 access token 時指定 scope，使用者或管理員需同意。

- 參考來源
[Microsoft: Scopes, permissions, and consent in the Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/scopes-oidc)

### FOCI
- 定義
FOCI（Family of Client ID）是一種機制，允許同一家族的 Microsoft 官方應用程式 refresh token，以達到跨應用單一登入（SSO）。

- 大概用來幹嘛
提升使用者體驗，讓同一裝置上的多個 Microsoft 應用程式間無縫切換帳號。降低重複登入次數，簡化 token 管理。

- 可能存在的攻擊面
- Family Refresh Tokens（FRTs）Steal
是 FOCI 機制下的特殊刷新權杖，允許同一 FOCI 家族內的多個應用程式共用。若攻擊者竊取了 FRT，便可用它來為任一 FOCI 應用程式請求新的 access token，進而存取不同資源與範圍。
- 可能的攻擊手法 :
- steal、replay 瀏覽器的 Cache、Session cookie
- MITM Proxy
- 取得後的受害可能
- Token Replay (雲端環境的 persistence)
- 如果有其他服務使用同一帳戶，可能有機會橫向移動的機會。

- Issue
- 有機會 FRT 有可能從本地端撈出來嗎? 像是 Mimikatz 偷 NTLM Hash

- Reference
- [Abusing Family Refresh Tokens for Unauthorized Access and Persistence in Azure Active Directory](https://github.com/secureworks/family-of-client-ids-research)
- [Understanding Token Theft-How Hackers Steal Your Access & How to Stay Safe](https://itbutler.sa/blog/understanding-token-theft-how-hackers-steal-your-access-how-to-stay-safe/)
- [Family Matters: Abusing Family Refresh Tokens to Gain Unauthorised Access to Microsoft Cloud Services Exploratory Study of Azure Active Directory Family of Client IDs ](https://www.scitepress.org/PublishedPapers/2022/110612/110612.pdf)
- [Hybrid Envs Attacks, Techniques, Tools and Attack Paths — Putting it All Together](https://medium.com/understanding-and-attacking-hybrid-environments/part-6-entra-id-active-directory-hybrid-envs-attacks-attack-techniques-tools-and-attack-paths-b45469dc2e30)

## Azure Authorization Type
### OAuth

- 具體來說這啥?
OAuth（Open Authorization）是一種開放標準的授權協議，允許應用程式在不暴露使用者密碼的情況下，安全地存取第三方資源。Azure AD 採用 OAuth 2.0 作為主要的授權框架，讓應用程式能以「代表使用者」或「代表自己」的方式，取得資源存取權杖（Access Token）。

- 用來幹嘛?
讓應用程式安全地存取受保護的 API（如 Microsoft Graph、SharePoint Online）。實現單一登入（SSO）、細緻權限管理（scopes）。支援多種授權流程（如授權碼流程、用戶端憑證流程、裝置碼流程等）。

- 如何運行?
- 應用程式向 Azure AD 請求授權，指定所需 scope。
- 使用者或管理員同意授權後，Azure AD 發放授權碼（或直接發 access token）。
- 應用程式用授權碼換取 access token（和 refresh token）。
- 應用程式攜帶 access token 向資源伺服器（如 Microsoft Graph）請求資料。
- 資源伺服器驗證 token，決定是否授權存取。

- Reference
[Microsoft: OAuth 2.0 and OpenID Connect protocols on the Microsoft identity platform](https://learn.microsoft.com/en-us/entra/architecture/auth-oauth2)

### Conditional Access

- 具體來說這啥?
Conditional Access（條件式存取）是 Azure AD 的一套動態存取控制機制，根據使用者、裝置、應用程式、位置等多重條件，決定是否允許、拒絕或要求額外驗證（如 MFA）來存取資源。

- 用來幹嘛?
強化企業安全政策，動態調整存取規則。避免帳號外洩後遭濫用，提升對高風險情境的防護。實現零信任（Zero Trust）安全模型。

- 如何運行?
- 使用者或應用程式發起存取請求（如登入、存取資源）。
- Azure AD 根據預先設定的條件式存取政策，驗證請求（如 IP、裝置狀態、應用程式、使用者身分等）。
- 根據政策結果，允許、拒絕存取，或要求額外驗證（如多因素認證）。
- 若存取被允許，使用者/應用程式即可繼續操作。

- Reference
[Microsoft: What is Conditional Access in Azure Active Directory?](https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview)

## Conditional Access (CA) Policy Bypass
### Company Portal CA bypass
當 Conditional Access Policy
- 啟用 ALL Resource Policy 時
- 同時排除特定 Application，讓其可獨立於 ALL Resource Policy
- 並單獨為這個 "特定的 Application"，設定獨立的 CA Policy

則會讓這個 "特定的 Application" 在某些低權限的 scope ，默認 bypass Conditoinal Access，像是 user.read、people.read

- 延伸的攻擊面
- 駭客如果打下這個 "特定的 Application"，就能夠進一步取得橫向移動所需的相關資訊。如 People.Read：允許應用程式讀取登入使用者的「相關人物」清單（如最近聯絡人、組織內部常互動對象）

- Reference
[Microsoft Graph permissions reference](https://learn.microsoft.com/en-us/graph/permissions-reference#peopleread)

### Device registration CA bypass
如果我們透過 Company Portal APP，使用一組帳號，將自己的移動裝置 (如 手機) 註冊到 Intune，則預設我們的 "新" 移動裝置，能夠 Bypass CA。

- 攻擊面
- 駭客拿到帳號，並成功註冊 "新" 裝置上去
- 由於新裝置上去以後，可能會自動化獲取 VPN 資訊，這可能使駭客取得橫向移動的內網網絡架構 等相關資訊。

- 防禦面
- 要求註冊新裝置需要 MFA

- 延伸的 issue，不過我不太確定
- 如果說今天有一間公司的 A 帳號被偷走
- CA 有設定 IP 位置作為登錄限制
- 駭客透過 Company Portal APP 註冊新裝置，Bypass CA
- 駭客成功登錄

- Reference
- [How to use Intune Device Enrollment Restrictions to block “Second Wave Phishing”](https://thecloudtechnologist.com/2022/01/27/how-to-use-intune-device-enrollment-restrictions-to-block-second-wave-phishing/)
- [Compliant Device Bypass, Oh My!](https://www.itpromentor.com/device-compliance-bypass/)

# Experiment
## Sign in to all the apps : Sign in to all the clients
- 首先透過 ROPC flow 與密碼檔暴力破解，使用者的登錄密碼，並取得 refresh token。
- 透過 refresh token 暴力掃描出所有可以存取的 resource 以及相應的 scope。
- Replay refresh token for FOCI clients

- issuse
- 這個實驗成果大概僅對於採用弱密碼的公司有用。

### Result
- Total enumerated clients: 219 •
- Total FOCI clients: 48 (10 new) •
- Total tokens requested: 347k

### reference
ROPC flow（Resource Owner Password Credentials flow）是 OAuth 2.0 標準中的一種授權流程，允許應用程式直接用使用者的帳號與密碼向授權伺服器換取 access token。[Microsoft identity platform and OAuth 2.0 Resource Owner Password Credentials](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc)

採用的工具。[ROADtools](https://github.com/dirkjanm/ROADtools)

## Sign in to all the apps : Get tokens for all the resources
「不是所有應用都是 public client」，因此無法使用 ROPC（Resource Owner Password Credential flow）。

是故，嘗試用更通用的方法（如 Primary Refresh Token, PRT）

- PRT 是一種針對 M365 SSO 設計的 token，預設對所有應用都有效。
- 預設駭客已經取得 PRT。
- 使用 PRTv3 broker flow，搭配 scope 與 redirect_uri 參數進行登入。
- 測試各種可疑的 redirect URLs

### 目前已知可取得 PRT 的手段
- [地端有存，從地端偷出來。用 Mimikatz 偷。](https://www.linkedin.com/pulse/laterally-moving-cloud-tenant-from-on-prem-exploiting-de-cissp-qrchc/)
- [瀏覽器的 cookies 有存，偷 cookies。](https://blog.knowbe4.com/primary-refresh-tokens-arent-your-parents-browser-token)

### Result
- Total enumerated clients: 229
- Total FOCI clients: 50 (2 new)
- Total tokens requested: ~600k

### Reference

採用的工具。[ROADtools](https://github.com/dirkjanm/ROADtools)

## Scope troubles : Find all the scopes
使用一個有效的 Refresh Token（通常來自某個已登入的第一方應用），嘗試向所有可識別的 Microsoft 資源（resource IDs）請求 Access Token，進而找出 Conditional Access Policy（CA）是否能正確套用，或是否存在 scope / resource 造成的繞過行為。

- 準備一組 Refresh Token
- 列舉所有可識別的 Resource ID
- 對每個 Resource ID 嘗試請求 Access Token
- 記錄 Scope + Resource 的組合與結果

## Find all the possible CA bypasses for these scopes

### challenge
- 有些 App 使用 特殊 redirect URI（非標準 URI）
- 出現類似 Broker authentication 的情況
- Nested App Authentication（NAA） 的應用程式架構無法被一般 token flow 涵蓋。所以要有識別機制，才能討論這種 APP 的 CA Bypas。

### 如何判斷 Broker/Nested APP
他沒講

### 實驗流程
- 假設 : 使用者帳戶已經被竊取、broker refresh token 已知
- 識別所有 Broker Client
- 使用 roadtx 自動化掃描 brk- 開頭的 redirect URI 是否有效
- 取得「Broker Refresh Token」
- 使用 Broker Token 請求 Nested Apps 的 access token
- 利用 roadtx --autobroker 嘗試不同 nested apps 組合，觀察哪些成功
- 對 Nested App 請求高權限 access token

### Result
- Total enumerated clients: 537
- Total FOCI clients: 52 (24 new in total) -1 that got disabled last week
- Total tokens requested in final run: 839k
- Runtime: around 25 minutes
- Sentinel bill: ???

### Reference
- [Nested app authentication](https://learn.microsoft.com/en-us/microsoftteams/platform/concepts/authentication/nested-authentication)
- [roadtx](https://github.com/dirkjanm/ROADtools/wiki/ROADtools-Token-eXchange-(roadtx))

# Detection Sollution

- 一個酷酷的掃描工具 [GraphPreConsentExplorer](https://github.com/zh54321/GraphPreConsentExplorer)

## Reference
[Use Unified Sign-In logs in Advanced Hunting](https://cloudbrothers.info/en/unified-sign-logs-advanced-hunting/)

# Rabbit hole : Scope CA Bypass
- 比較重要的結論 : scope 的組合也可能決定是否執行 CA 規則
- 指定特定 scope（如 UserAuthenticationMethod.Read）可繞過合規裝置/MFA 檢查。
- 使用者在非合規裝置上仍成功取得一個具有敏感權限的 access token：
- 包含 UserAuthenticationMethod.Read scope（可查使用者 MFA 方法）
- 當移除此 scope 後再發送請求 → 被 CA 阻擋
- 推測 CA 的行為不僅依賴應用與資源，還可能受到 scope 組合的影響

# Note
- 一個公司設定好 Condition access，想要做靜態分析。
- 所以要整理繞過的手法
- 研究防禦如何、有無缺陷