---
title: "學會 Entra ID 與 Azure 攻擊基礎的第一堂課"
event: "HITCON Training 2026"
date: "2026-08-13"
lang: "zh-TW"
format: "openslide-markdown"
audience: "student"
---

# 學會 Entra ID 與 Azure 攻擊基礎的第一堂課

HITCON Training 2026

John Jiang / Echo Lee

---

# 這門課要解決的問題

- 攻擊者拿到 Microsoft 365 / Entra ID 身分後，下一步會怎麼擴張？
- Entra ID 權限、Application、Service Principal 與 Azure RBAC 怎麼串成攻擊面？
- 哪些控制能切斷攻擊鏈？哪些控制只是改變攻擊者路徑？

Sources: `MS-TOKENS`, `MS-CONSENT`, `MS-ROLES`

---

# 課程主線

1. Entra ID / Azure 權限與 token 基礎
2. Initial access：device code 或 OAuth phishing
3. Recon：ROADtools / AADInternals / Graph visibility
4. Lateral movement：roles、app roles、ownership、service principals
5. Persistence：device 或 application persistence
6. Azure resource abuse：Storage、Key Vault、Managed Identity
7. Security boundary：Conditional Access、MFA、device compliance

---

# 身分平面與資源平面

- Entra ID 管身分、登入、token、directory objects。
- Microsoft Graph 讓你查詢與操作 directory / M365 物件。
- Azure Resource Manager 管 subscription、resource group、resources。
- Azure RBAC 決定誰能對 Azure resources 做什麼。

Sources: `MS-CONSENT`, `MS-ROLES`, `MS-AZURE-RBAC`

---

# Entra ID Directory Model

- Tenant 是 directory 與 policy 的安全邊界。
- User、group、role 決定人與管理權限。
- Application 是 app definition；service principal 是 tenant 內的 enterprise app instance。
- Object ownership、consent、app role assignment 會變成攻擊者的決策點。

Sources: `MS-CONSENT`, `MS-ROLES`, `MS-DEFAULT-PERMS`, `MS-GRAPH-APPROLE`

---

# Azure Resource Model

- Subscription 是 billing、policy、RBAC 的主要管理範圍。
- Resource group 是資源生命週期與管理 grouping，不是硬式安全邊界。
- Resource provider 決定 resource type 與 API surface。
- Azure RBAC 用 scope + role assignment 決定 management plane 權限。
- 有 management plane 權限不代表一定有 data plane access。

Sources: `MS-AZURE-RBAC`, `MS-STORAGE-BLOB-RBAC`, `MS-KEYVAULT-RBAC`

---

# Token 是攻擊鏈的中心

- Access token：存取特定 resource 的短效授權證明。
- Refresh token：用來換取新 access token 的長效憑證。
- Primary Refresh Token：裝置與 broker SSO 的核心 artifact。
- Token 不是「登入狀態」而已，它決定攻擊者可以呼叫哪個 resource。

Sources: `MS-TOKENS`, `MS-PRT`

---

# Token 使用邊界

- Delegated access：app 代表使用者行動，還要受使用者本身權限限制。
- App-only access：app 以自己的身分行動，依 application permission / app role 授權。
- Conditional Access、MFA、device claims 會影響 token 發行與使用條件。
- 防禦判斷要問：這個 token 是誰的、發給哪個 resource、帶有哪些 claims？

Sources: `MS-CONSENT`, `MS-TOKENS`, `MS-PRT`, `MS-TOKEN-PROTECTION`

---

# Initial Access：本課只做可控情境

- Password spraying：理解風險與偵測，不做大規模攻擊實驗。
- Device code phishing：作為 threat context 與講師示範候選。
- OAuth consent phishing：暫定為主實驗，用 controlled app 觀察 consent 與 token boundary。
- AitM / Evilginx：只講防禦邊界，不作為預設 hands-on。

Sources: `MS-STORM-2372`, `MS-CONSENT`, `MS-USER-CONSENT`, `MS-CA-AUTH-STRENGTH`

---

# Password Spraying：只做風險與偵測

- Spray 的核心是低頻嘗試大量帳號，避開單一帳號 lockout。
- 本課不做大量嘗試、不碰真實帳號、不產生 classroom-wide spray traffic。
- 防禦觀察重點：risky user、sign-in risk、成功密碼驗證後的偵測限制。
- 預防重點：禁止弱密碼、MFA、risk-based Conditional Access。

Sources: `MS-IDP-RISK`, `MS-PASSWORD-PROTECTION`, `MS-CA-AUTH-STRENGTH`

---

# Device Code vs OAuth Consent

- Device code flow 本來是給輸入受限裝置與 CLI 使用。
- Device code phishing 濫用使用者在另一台裝置輸入 code 的信任流程。
- OAuth consent phishing 濫用使用者或管理員授權 app 存取資料的流程。
- 本課主線選 OAuth consent，因為它能接到 application、service principal、app role abuse。

Sources: `MS-DEVICE-CODE-FLOW`, `MS-STORM-2372`, `MS-CONSENT`

---

# Controlled OAuth Consent Lab

- 使用 training tenant 與 controlled app，不使用真實目標或外部誘導。
- 學生觀察 consent prompt、publisher / app name、requested permissions。
- 學生比對 delegated permissions 與 application permissions 的風險差異。
- Defender checkpoint：user consent settings、admin consent workflow、audit observations。

Sources: `MS-CONSENT`, `MS-USER-CONSENT`, `MS-ADMIN-CONSENT-WORKFLOW`

---

# Recon：先知道自己看得到什麼

- ROADrecon：auth、gather、explore。
- AADInternals：Microsoft 365 / Entra ID security testing toolkit。
- Graph visibility 取決於 token、角色、consent、tenant 設定。
- Low-privilege recon 的限制要在 lab 中實際觀察。

Sources: `ROADTOOLS`, `AADINTERNALS`, `MITRE-AADINTERNALS`

---

# ROADtools / ROADrecon Flow

- Auth：取得目前情境允許的 token。
- Gather：收集 tenant、users、groups、apps、service principals、roles。
- Explore：把 directory 關係轉成可讀的攻擊面。
- 關鍵問題不是「工具有沒有跑完」，而是「這個 token 允許我看見什麼」。

Sources: `ROADTOOLS`, `ROADTOOLS-HOME`, `MS-CONSENT`

---

# AADInternals 的定位

- 適合用來理解 Microsoft 365 / Entra ID 測試面向。
- 可以支援 recon、token、device、tenant 設定等多種檢查。
- 本課不把 AADInternals 當唯一主線，避免工具指令蓋過權限模型。
- 輸出要回到：identity、permission、token、device、resource 的判斷。

Sources: `AADINTERNALS`, `MITRE-AADINTERNALS`

---

# AzureHound：先當可視化候選

- AzureHound / BloodHound 能把 Entra ID 與 Azure 關係轉成 attack path。
- 低權限情境下可見度取決於 tenant policy、Graph permissions、Azure permissions。
- 沒有足夠權限時，圖很乾淨不代表環境真的安全。
- Hands-on 先等 training tenant 驗證；教材先講使用時機與限制。

Sources: `AZUREHOUND-DOCS`, `MS-CONSENT`, `MS-AZURE-RBAC`

---

# Recon 要產出的不是資料量

- 目前身份是誰？token 發給哪個 resource？
- 看得到哪些 apps、service principals、owners、role assignments？
- 哪些結果需要更高權限才能確認？
- 哪些候選路徑適合進入 lateral movement 章節？

Sources: `ROADTOOLS`, `MS-GRAPH-APPROLE`, `MS-DEFAULT-PERMS`

---

# Lateral Movement：常見判斷點

- 角色是否過大？
- Application / Service Principal 是否有高權限 app role？
- Object owner 是否可以改 credential、permission 或 owner？
- Azure RBAC 是否讓 identity 讀到 Storage、Key Vault 或 VM 上的敏感資料？

Sources: `MS-DEFAULT-PERMS`, `MS-GRAPH-APPROLE`, `MS-SP-SECURITY`

---

# Application / Service Principal Abuse

- Application object 定義 app；service principal 是 tenant 內實際被授權的 identity。
- Owner 可能可以改 credential、redirect URI、permission 或其他敏感設定。
- 濫用重點不是「app 很危險」，而是誰可以改 app、誰可以授權 app。
- Defender 要查 owner、credential age、consent grants、app role assignments。

Sources: `MS-DEFAULT-PERMS`, `MS-CONSENT`, `MS-SP-SECURITY`

---

# App Roles and Assignments

- Delegated permission 代表 app 以使用者上下文呼叫 resource。
- Application permission / app role 代表 app 以自己的身份取得更寬的存取。
- `appRoleAssignment` 是 recon 與審計時的重要觀察點。
- 高權限 app role 應該被視為 identity attack path 的一部分。

Sources: `MS-CONSENT`, `MS-GRAPH-APPROLE`

---

# Persistence Candidates

- Service Principal persistence：新增或替換 credential，讓 app identity 可被重用。
- OAuth consent persistence：既有 grant 沒撤銷時，存取可能持續存在。
- Device registration persistence：利用 device identity / claims 影響後續存取條件。
- 本課先選能在 training tenant 中穩定演示、且不需要學生拿 Global Administrator 的路徑。

Sources: `MS-SP-SECURITY`, `MS-DEVICE-REG`, `MS-DEVICE-JOIN`, `DIRKJAN-BACKDOORING`

---

# Lecture-only Until Verified

- Cross-tenant sync abuse：先講概念，不做實驗。
- Azure Lighthouse abuse：先講風險位置，不做實驗。
- Entra Connect / ADFS credential theft：進階補充，不進主線。
- 所有 optional 題目都要先有 source、時間、環境、cleanup 再進學生 hands-on。

Sources: `MS-DEVICE-MGMT`, `DIRKJAN-BACKDOORING`

---

# Persistence：先保留兩到三個主題

候選：

- Service Principal persistence
- Application / OAuth consent persistence
- Malicious device join
- Device registration persistence

本課會優先選能在 6 小時內完成、且不需要學生拿 Global Administrator 的路徑。

Sources: `MS-DEVICE-REG`, `MS-DEVICE-JOIN`, `MS-DEVICE-REG-FLOW`, `DIRKJAN-BACKDOORING`

---

# Azure Resource Abuse：三個主要實驗方向

- Storage Blob：資料平面角色與 management plane 角色不同。
- Key Vault：control plane 與 data plane 權限要分開看。
- Managed Identity：resource identity 可以向支援 Entra 的服務換 token。

Sources: `MS-STORAGE-BLOB-RBAC`, `MS-STORAGE-BLOB-AUTHZ`, `MS-KEYVAULT-RBAC`, `MS-MANAGED-IDENTITY-VM`

---

# Storage：Management Plane vs Data Plane

- Storage account 管理權限不等於 Blob data 讀取權限。
- Blob data access 需要適當的 data role 或其他資料面授權方式。
- 攻擊者會找：誰能讀 blob、誰能改 role assignment、誰能改 storage 設定。
- Defender 要分開盤點 management roles、data roles、public exposure、diagnostic logs。

Sources: `MS-STORAGE-BLOB-RBAC`, `MS-STORAGE-BLOB-AUTHZ`, `MS-AZURE-RBAC`

---

# Key Vault：Secrets Access Boundary

- Key Vault 有 control plane 與 data plane；能管理 vault 不一定能讀 secret。
- Secrets access 要看 RBAC / access model、role assignment、scope、identity。
- 攻擊者會找：誰能讀 secret、誰能改 access、誰能部署或修改會使用 secret 的資源。
- Defender 要查 secret access、role assignment change、vault configuration change。

Sources: `MS-KEYVAULT-RBAC`, `MS-AZURE-RBAC`

---

# Managed Identity：Resource Identity

- Managed Identity 是 Azure resource 使用的 Entra identity。
- Resource 可以向 IMDS / managed identity endpoint 取得 token，再呼叫支援 Entra 的服務。
- 風險不是 identity 本身，而是 identity 被授予的 resource permissions。
- Demo / lab 是否納入，取決於 training VM 與 resource scope 是否穩定。

Sources: `MS-MANAGED-IDENTITY-VM`, `MS-TOKENS`, `MS-AZURE-RBAC`

---

# Deployment History and Hidden Assumptions

- Deployment history 可以幫忙理解誰部署了什麼、什麼時候改了什麼。
- 不應把 deployment history 當作一定會有憑證的地方。
- 教材只講 inspection boundary：哪些 artifact 可能值得檢查、哪些 claim 需要 lab 驗證。
- 真正的 credential hunting 題目先等 training tenant 與 sample artifact 準備好。

Sources: `MS-ARM-DEPLOYMENT-HISTORY`

---

# Resource Abuse Decision Questions

- 我現在的 identity 有哪些 Azure role assignments？
- 這些 role 在哪個 scope：subscription、resource group、resource？
- 這是 management plane access 還是 data plane access？
- 如果要判斷資料可讀，需要觀察到哪些條件？

Sources: `MS-AZURE-RBAC`, `MS-STORAGE-BLOB-RBAC`, `MS-KEYVAULT-RBAC`

---

# 防禦邊界不是口號

- Conditional Access 可以改變 token 發行條件，但要看 policy scope 與 grant controls。
- MFA 類型不同，抗 phishing 能力不同。
- Device compliance 依賴 device identity、management 與 policy。
- 每個控制都要問：阻擋哪一步？留下哪些繞路？

Sources: `MS-CA-AUTH-STRENGTH`, `MS-CA-MFA-STRENGTH`, `MS-DEVICE-MGMT`

---

# Conditional Access：先問 Scope

- Policy 套到哪些 users、groups、roles、apps、platforms、locations？
- Grant controls 是 require MFA、authentication strength、compliant device，還是 block？
- Session controls 影響的是 session 行為，不等於補上所有授權缺口。
- 攻擊鏈判斷：CA 卡的是 sign-in、token issue、session，還是根本沒套到這個 app？

Sources: `MS-CA-AUTH-STRENGTH`, `MS-CA-MFA-STRENGTH`

---

# MFA Type Matters

- MFA 不是單一控制；SMS、push、number matching、FIDO2、certificate-based auth 抗性不同。
- Phishing-resistant MFA 的價值在於降低 replay / prompt abuse / credential capture 成功率。
- AitM 情境要問：攻擊者拿到的是密碼、session、token，還是能通過強驗證的裝置？
- 防禦敘事不能停在「有 MFA」，要說明是哪種 MFA、保護哪一步。

Sources: `MS-CA-AUTH-STRENGTH`, `MS-CA-MFA-STRENGTH`

---

# Device Compliance Boundary

- Compliant device 依賴 device identity、management state、policy evaluation。
- Device claim 可以改變 Conditional Access 結果，但不是所有 resource access 的萬能邊界。
- 惡意 device registration / join 題目要先分清楚：註冊、加入、合規是不同狀態。
- Defender 要檢查 device settings、join restrictions、compliance policy、stale devices。

Sources: `MS-DEVICE-REG`, `MS-DEVICE-JOIN`, `MS-DEVICE-MGMT`

---

# Token Protection and Residual Risk

- Token protection 目標是降低 token replay，但需要支援條件與部署前提。
- Refresh token / PRT / access token 的風險不同，對應的控制也不同。
- OAuth grants、app permissions、role assignments 不會因為開了 MFA 就自動消失。
- 收束問題：控制改變的是哪一個 token、哪一段 flow、哪一個 resource access？

Sources: `MS-TOKEN-PROTECTION`, `MS-TOKENS`, `MS-PRT`, `MS-CONSENT`

---

# Defensive Observation Checklist

- Sign-in：user、app、IP、device、CA result、MFA method。
- Directory：roles、owners、service principals、OAuth grants、app role assignments。
- Azure：role assignment scope、data-plane role、resource logs。
- Device：registration / join state、compliance state、management policy。

Sources: `MS-ROLES`, `MS-GRAPH-APPROLE`, `MS-AZURE-RBAC`, `MS-DEVICE-MGMT`

---

# 把控制對回攻擊鏈

| Attack Step | Useful Control Question |
| --- | --- |
| Initial access | 哪種 MFA / CA policy 會改變登入結果？ |
| OAuth consent | 使用者能否自行 consent？admin workflow 是否啟用？ |
| Recon | 目前 token / role 可以看見哪些 objects？ |
| App/SP abuse | 誰能改 owner、credential、permission、assignment？ |
| Resource abuse | 這是 management plane 還是 data plane？ |
| Persistence | grant、credential、device、role assignment 是否可撤銷與監控？ |

Sources: `MS-CONSENT`, `MS-USER-CONSENT`, `MS-CA-AUTH-STRENGTH`, `MS-AZURE-RBAC`

---

# Learning, Not Flags

- 本課重點是看懂攻擊鏈、權限模型與防禦邊界。
- Lab checkpoint 用來確認理解，不是 CTF 題目。
- 學生不需要提交 flag、log、token、截圖或 tool output。
- 能說清楚「我看到什麼、代表什麼、下一步要查什麼」就是目標。

---

# Lab Chain Draft

1. ROADtools tenant recon
2. Controlled OAuth consent initial-access checkpoint
3. Application / Service Principal abuse path
4. Device persistence candidate
5. Storage Blob data access
6. Key Vault secret access
7. Managed Identity abuse candidate

---

# 完成標準

- 能說清楚 identity plane 與 resource plane 的邊界。
- 能用工具找出 Entra ID / Azure 的可見攻擊面。
- 能把 token、role、application、service principal、resource access 串成攻擊鏈。
- 能判斷 Conditional Access、MFA、device compliance 對攻擊鏈的實際影響。

---

# References

完整來源表在：

`references/source-map.md`