溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
Kerberos中MS14068和金銀票據的原理和利用方式是什么，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
下面具體說一下Kerberos曾經爆出的一個經典的漏洞MS14068和金銀票據的原理和利用方式。MS14068是一個比較經典的漏洞，小編對金銀票據以及增強型的金票據做一個說明。
MS14068是一個能夠使普通用戶提權到域控權限的權限提升漏洞。攻擊者可以通過構造特定的請求包來達到提升權限的目的。首先我們來說一下利用方式。
實驗環境：
域：YUNYING.LAB
域控：WindowsServer 2008 R2 x64(DC)
域內主機：Windows7 x64(s1):域帳戶ts1
所需工具：
Pykek
mimikatz
攻擊流程：
實驗之前需要在域控主機查看是否安裝了KB3011780補丁，可通過systeminfo來查看。
一、首先在域內主機s1上通過dir來訪問域控的共享文件夾，示拒絕訪問。
二、通過Pykek工具利用漏洞，我這里使用的是將python腳本編譯之后的exe文件。
參數說明：
-u 域賬號+@+域名稱，這里是ts1+@+yunying.lab
-p 為當前用戶的密碼，即ts1的密碼
-s為ts1的SID值，可以通過whoami/all來獲取用戶的SID值
-d為當前域的域控
腳本執行成功會在當前目錄下生成一個ccache文件。
三、使用mimikatz導入生成的ccache文件，導入之前cmd下使用命令klist purge或者在mimikatz中使用kerberos::purge刪除當前緩存的kerberos票據。
再次dir訪問域控共享已經可以成功訪問。
MS14068工具在使用過程中抓包可以看到s1和域控192.168.254.130（實質上是與安裝在域控上的KDC）有KRB_AS_REQ、KRB_AS_REP、KRB_TGS_REQ、KRB_TGS_REP四次交互。
下面根據流程和工具源碼來看漏洞是如何利用的：
KRB_AS_REQ
首先程序通過build_as_req函數構建AS_REQ，在這里可以看到，參數pac_request設置為false。
也就是說設置了這個參數之后會向KDC申請一張不包含PAC的TGT票據，這是微軟默認的設計，在下列鏈接中有詳細說明。
https://docs.microsoft.com/en-us/previous-versions/aa302203(v=msdn.10)#security-considerations
通過PCAP包可以更直觀的看到在AS-REQ請求中的include-pac:False字段。這是造成這個漏洞的第一個因素。
KRB_AS_REP
在AS發起請求之后，KDC（AS）將返回一張不包含有PAC的TGT票據給Client。在這里是tgt_a。
抓包可以看到這個以268fdb開頭的TGT票據。
KRB_TGS_REQ
攻擊腳本使用了兩個關鍵函數來實現這個過程，首先通過build構造PAC，然后通過build_tgs_req函數構造TGS-REQ的內容。
build_pac
當Client接收到AS返回的不帶有PAC的TGT之后通過腳本中的build_pac函數開始構造PAC。
這里我們重點關注一下PAC中的chksum1和chksum2，也就是“PAC的引入”中提到的PAC的兩個數字簽名PAC_SERVER_CHECKSUM和PAC_PRIVSVR_CHECKSUM。
注意一下其中第一個參數server_key[0]和kdc_key[0]的值其實是程序指定的RSA_MD5，而Key的值為None，但原則上來說這個加密方式是應該由KDC來確定的。也就是說加密PAC_SERVER_CHECKSUM和PAC_PRIVSVR_CHECKSUM這兩個數字簽名的Key應該分別是Server密碼HASH和KDC密碼HASH，在這里卻直接使Key為None，然后直接使用RSA_MD5方式加密。
這是漏洞形成的第二個因素，查看checksum函數即可驗證這一點。
同時在這個過程中我們也需要關注一下user_sid這個參數，build_pac函數會將其分割，然后重新構造高權限的sid的值。在這里user_sid的值為S-1-5-21-4249968736-1423802980-663233003-1104，分割之后domain_sid為S-1-5-21-4249968736-1423802980-663233003，user_id為1104。
其中512、520、518、519分別為不同的組的sid號。513為DOMAIN USERS組。通過這種方式構造了包含高權限組SID的PAC。
build_tgs_req
在build_tgs_req函數的參數中，authorization_data對應的為build_pac生成的pac。
這里將PAC傳入build_tgs_req之后使用subkey將其加密。
而通過下圖可以看到subkey其實是函數generate_subkey生成的一串16位的隨機數。
那現在為止出現的問題有：
A、在域中默認允許設置Include-pac的值為False（不能算漏洞，應該是微軟對于某些特定場景的特殊考慮設計出的機制）；
B、PAC中的數字簽名可以由Client端指定，并且Key的值可以為空；
C、PAC的加密方式也可以由Client指定，并且Key的值為generate_subkey函數生成的16位隨機數；
D、構造的PAC中包含高權限組的SID內容。
也就是說通過這幾點Client完全偽造了一個PAC發送給KDC，并且KDC通過Client端在請求中指定的加密算法來解密偽造的PAC以及校驗數字簽名，并驗證通過。
通過抓包可以看到在這個過程中將接收的TGT（268fdb開頭）和加密方式為ARCFOUR-HMAC-MD5的PAC內容。
KRB_TGS_REP
KDC在根據對偽造的PAC驗證成功之后，返回給Client端一有新的TGT，并且這個TGT會將Pykek生成的PAC包含在其中，這里正常情況下返回的其實是一張用于發送給Server端做認證的ST票據。
當Pykek工具接收到新的TGT之后就將其保存生成ccache文件。也就是說這時Client已經獲得了一張包含有高權限PAC內容的正常的TGT票據（564eab開頭）。
使用Mimikatz利用TGT訪問DC共享文件夾
這時我們通過mimikatz來導入票證，并且用dir \\dc.yunying.lab\c$來訪問域控的共享文件夾。
抓包可以看到這時Client端發起了兩次TGS-REQ請求，重點關注一下第一次，此時用的票據就是使用mimikatz導入的TGT，也就是上面KRB_TGS_REP過程中返回的那個tgt_b（564eab開頭）。
請求之后返回了一張針對dc.yunying.lab（域控）的CIFS票據也就是正常流程中的ST（Service Ticket）票據（234062開頭）：
這時在抓的包中發現并沒有AP_REQ這個流程，是因為在Kerberos中AP_REQ這個過程放在了服務的第一次請求中，這里是放在SMB的Session Setup Request中（其他協議同理，比如HTTP協議是放在GET請求中）。
然后在SMB的Session Setup Response中做出響應，也就是AP-REP這個流程。
到此為止Client能夠越權訪問域控的共享文件夾。
此漏洞是一個14年的漏洞，多數產生在windowsserver 2008和windows server 2003的域環境中，所以安全補丁早已可以下載安裝，用戶可以通過在域控上安裝KB3011780補丁來規避風險。
同時可以根據上文中提到的標記include-pac為False的特征來初步的篩選。
也可以通過windows日志來發現，如ID為4624登錄到目標服務器、ID為5140表示網絡共享對象被訪問等等。
在這個漏洞中主要的問題是存在于KDC會根據客戶端指定PAC中數字簽名的加密算法，以及PAC的加密算法，來校驗PAC的合法性。這使得攻擊者可通過偽造PAC，修改PAC中的SID，導致KDC判斷攻擊者為高權限用戶，從而導致權限提升漏洞的產生。
Golden Ticket（下面稱為金票）是通過偽造的TGT（TicketGranting Ticket），因為只要有了高權限的TGT，那么就可以發送給TGS換取任意服務的ST。可以說有了金票就有了域內的最高權限。
制作金票的條件：
1、域名稱
2、域的SID值
3、域的KRBTGT賬戶密碼HASH
4、偽造用戶名，可以是任意的
實驗環境
域：YUNYING.LAB
域控：WindowsServer 2008 R2 x64(DC)
域內主機：Windows7 x64(s1):用戶ts1
所需工具
Mimikatz
實驗流程
金票的生成需要用到krbtgt的密碼HASH值，可以通過mimikatz中的
lsadump::dcsync /domain:yunying.lab /user:krbtgt
命令獲取krbtgt的值。如果已經通過其他方式獲取到了KRBTGT HASH也可以直接進行下一步。
得到KRBTGT HASH之后使用mimikatz中的kerberos::golden功能生成金票golden.kiribi，即為偽造成功的TGT。
參數說明：
/admin：偽造的用戶名
/domain：域名稱
/sid：SID值，注意是去掉最后一個-后面的值
/krbtgt：krbtgt的HASH值
/ticket：生成的票據名稱
金票的使用
通過mimikatz中的kerberos::ptt功能（Pass The Ticket）將golden.kiribi導入內存中。
已經可以通過dir成功訪問域控的共享文件夾。
這樣的方式導入的票據20分鐘之內生效，如果過期再次導入就可以，并且可以偽造任意用戶。
Silver Tickets（下面稱銀票）就是偽造的ST（Service Ticket），因為在TGT已經在PAC里限定了給Client授權的服務（通過SID的值），所以銀票只能訪問指定服務。
制作銀票的條件：
1.域名稱
2.域的SID值
3.域的服務賬戶的密碼HASH（不是krbtgt，是域控）
4.偽造的用戶名，可以是任意用戶名，這里是silver
實驗環境
域：YUNYING.LAB
域控：WindowsServer 2008 R2 x64(DC)
域內主機：Windows7 x64(s1):用戶ts1
所需工具
Mimikatz
實驗流程
首先我們需要知道服務賬戶的密碼HASH，這里同樣拿域控來舉例，通過mimikatz查看當前域賬號administrator的HASH值。注意，這里使用的不是Administrator賬號的HASH，而是DC$的HASH。
這時得到了DC的HASH值，通過mimikatz生成銀票。
參數說明：
/domain：當前域名稱
/sid：SID值，和金票一樣取前面一部分
/target：目標主機，這里是dc.yunying.lab
/service：服務名稱，這里需要訪問共享文件，所以是cifs
/rc4：目標主機的HASH值
/user：偽造的用戶名
/ptt：表示的是Pass TheTicket攻擊，是把生成的票據導入內存，也可以使用/ticket導出之后再使用kerberos::ptt來導入
這時通過klist查看當前會話的kerberos票據可以看到生成的票據。
使用dir \\dc.yunying.lab\c$訪問DC的共享文件夾。
銀票生成時沒有KRBTGT的密碼，所以不能偽造TGT票據，只能偽造由Server端密碼加密的ST票據，只能訪問指定的服務。
在Golden Ticket部分說明可利用krbtgt的密碼HASH值生成金票，從而能夠獲取域控權限同時能夠訪問域內其他主機的任何服務。但是普通的金票不能夠跨域使用，也就是說金票的權限被限制在當前域內。
為什么普通金票會被限制只能在當前域內使用？
在上一篇文章中說到了域樹和域林的概念，同時說到YUNYING.LAB為其他兩個域（NEWS.YUNYING.LAB和DEV.YUNYING.LAB）的根域，根域和其他域的最大的區別就是根域對整個域林都有控制權。而域正是根據Enterprise Admins組（下文會說明）來實現這樣的權限劃分。
實驗環境
根域：YUNYING.LAB 域控：DC.YUNYING.LAB
子域：NEWS.YUNYING.LAB 域控：NEWSDC.NEWS.YUNYING.LAB
子域：DEV.YUNYING.LAB 域控：DEVDC.DEV.YUNYING.LAB
操作系統均為WindowsServer 2008 R2 x64
使用工具：
Mimikatz
實驗流程：
首先使用mimikatz在NEWSDC（NEWS.YUNYING.LAB的域控）上生成普通的金票，真實環境會是在域內的主機中，這里方便演示所以在域控中，原理和結果是一樣的。
kerberos::golden /admin:administrator /domain:news.yunying.lab /sid:SID /krbtgt:XXXXX /ptt
這里使用的是NEWS.YUNYING.LAB域的SID號，訪問根域的DC共享文件夾被拒絕。
下面說明下具體原因。
Enterprise Admins組
EnterpriseAdmins組是域中用戶的一個組，只存在于一個林中的根域中，這個組的成員，這里也就是YUNYING.LAB中的Administrator用戶（不是本地的Administrator，是域中的Administrator）對域有完全管理控制權。
通過whoami命令在yunying.lab的域控上可以看到Enterprise Admins組的RID為519（最后三位）
Domain Admins組
可以看到在子域中是不存在EnterpriseAdmins組的，在一個子域中權限最高的組就是Domain Admins組。截圖是news.yunying.lab這個子域中的Administrator用戶，這個Administrator有當前域的最高權限。
通過whoami命令也可以看到在news.yunying.lab這個子域中沒有EnterpriseAdmins組的SID號。
在子域中使用mimikatz創建的黃金票據不能跨域使用的原因也就在這里，通過whoami可以看到YUNYING.LAB中Enterprise Admins組的SID號是：
S-1-5-21-4249968736-1423802980-663233003-519
而NEWS.YUNYING.LAB域中的SID號是：
S-1-5-21-3641416521-285861825-2863956705-XXX
mimikatz通過/sid選項接收SID號然后在尾部拼接RID號（512,519等），拼接之后生成的EnterpriseAdmins組的完整SID是：
S-1-5-21-3641416521-285861825-2863956705-519
而這個SID在整個域林中都是不存在的，所以在子域中通過mimikatz生成的金票無法跨域或者是訪問其他域的資源。在一個域林中，域控權限不是終點，根域的域控權限才是域滲透的終點。
普通的黃金票據被限制在當前域內，在2015年Black Hat USA中國外的研究者提出了突破域限制的增強版的黃金票據。通過域內主機在遷移時LDAP庫中的SIDHistory屬性中保存的上一個域的SID值制作可以跨域的金票。這里沒有遷移，直接拿根域的SID號做演示。
如果知道根域的SID那么就可以通過子域的KRBTGT的HASH值，使用mimikatz創建具有 EnterpriseAdmins組權限（域林中的最高權限）的票據。環境與上文普通金票的生成相同。
首先我們通過klist purge刪除當前會話的Kerberos票據，也可以在mimikatz里通過kerberos::purge來刪除。
然后通過mimikatz重新生成包含根域SID的新的金票
kerberos::golden /admin:administrator /domain:news.yunying.lab /sid:XXX /sids:XXX /krbtgt:XXX /startoffset:0 /endin:600 /renewmax:10080 /ptt
Startoffset和endin分別代表偏移量和長度，renewmax表示生成的票據的最長時間
注意這里是不知道根域YUNYING.LAB的krbtgt的密碼HASH的，使用的是子域NEWS.YUNYING.LAB中的KRBTGT的密碼HASH。
然后再通過dir訪問DC. YUNYING.LAB的共享文件夾，發現已經可以成功訪問。
此時的這個票據票是擁有整個域林的控制權的。我們知道制作增強金票的條件是通過SIDHistory那防御方法就是在域內主機遷移時進行SIDHistory過濾，它會擦除SIDHistory屬性中的內容。MS14068的利用方式和金銀票據，主要用來提升和維持域內權限，通常情況下需要結合其他的域內攻擊方式進行使用，比如獲取了域控制器的NTLM HASH等內容時。
關于Kerberos中MS14068和金銀票據的原理和利用方式是什么問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
