最新消息:

利用 Kerberos delegation 打造變種黃金票據

SEEBUG IMGIT 10浏览 0评论

作者:n1nty@360 A-TEAM
公眾號:n1nty

正文開始前,再次感慨一下 mimikatz 與 impacket 二位作者的強大。在有了本文的思路后本來想着自己寫一下代碼實現一個小工具,來讓本文顯得有點技術含量,一查資料,發現他們早都已經把相關工具寫好了。 🙁

所以,決定直接用 impacket 已經實現好的工具來跟大家介紹一下。但是,為了避免這篇文章墮落成一篇單純的工具介紹類的水貨,我會像以前一樣,在文章內簡述涉及到的相關背景知識。想深入真正地理解的話,還是建議自己去看一下 Kerberos RFC,我在最後會貼出我看過的與本文有關的資料。

黃金票據,golden ticket

所謂黃金票據,就是我們自己通過竊取 KRBTGT 這個賬號的 NTHASH 或者 AESKEY 后,自己離線偽造的 TGT,偽造 TGT 的全程不經過 KDC。 正常情況下 TGT 全是由 KDC 在驗證了客戶端的身份后(kerberos pre-authentication)發給客戶端的。KDC 會對自己所發出去的所有票據進行加密,可以支持多種不同加密算法,不同的加密算法有不同的 key。

比如支持的加密算法有:

利用 Kerberos delegation 打造變種黃金票據

我們通過 mimikatz 可以導出 KRBTGT 賬號的這幾種 KEY,然後離線生成加密的 TGT,這就是黃金票據的原理。我們可以利用 mimikatz 或者 impacket 的 ticketer.py 來生成黃金票據。

說到了這裡,你是否明白 pass the key 的原理?:-)

變種黃金票據優點及缺點

前面說到了,要生成黃金票據,我們是需要 KRBTGT 這個賬號的相關 KEY 的(NT HASH,AES KEY)。而且一旦 KRBTGT 的賬號密碼被改過,以前生成的黃金票據就作廢了。

而利用 Kerberos delegation 做成的另類的黃金票據,並不直接依賴於 KRBTGT 賬號。當然也有它的不足之處,就是它會在系統日誌裏面留下一些痕迹,而且需要我們對域用戶進行一些改動。

Delegation,委派

假如用戶 A 利用 windows 身份驗證(或者其他驗證方式也可以,更複雜一些而已)登陸了遠程服務器上的 Service1,Service1 隨後利用用戶 A 的身份向另一台服務器上的 Service2 發起了某個請求,這就是委派。

實際的場景有可能是用戶 A 利用 Windows 身份驗證訪問了一個網站,請求網站內的一個文件,但是這個網站服務器本身並沒有這個文件,它需要利用用戶 A 的身份去訪問另一台服務器,從另一台服務器上獲取這個文件后再返回給用戶。為什麼網站會利用用戶 A 的身份去獲取文件,而不是直接利用網站自身的權限去獲取呢?因為要充分利用 Windows 系統自身提供的權限控制啊,也許有的用戶有權限訪問那個文件而有的用戶沒有權限啊。

Kerberos delegation

前面說到了,delegation 的意思就是客戶在訪問一個服務的時候,這個服務利用客戶端的身份又去訪問了另一個服務。 delegation 是為了解決 authentication double hop 問題。我之前 PSEXEC 那篇公眾號文章從另一個角度提到了 double hop。

user –> service1 –(以 user 的身份)–> service2

kerberos 實現 delegation 有以下幾種方案:
利用 Kerberos delegation 打造變種黃金票據

Forwardable TGT/Unconstrained delegation

指的是 user 在訪問 service1 的時候,如果 service1 的賬號開啟了 unconstrained delegation 的功能(需要域管理員進行設置),則 user 訪問 service1 時會將自己的 TGT 發送給 service1。隨後 service1 就可以利用這張 TGT 以 user 的身份去訪問任何服務,所以它叫 「無限制委派」 或者 「非受限委派」。 這造成了很大的風險,用戶的身份可能被這個 service1 濫用。

如果你打下一台有 unconstrained delegation 服務的機器,也許你可以從這台機器上導出大量用戶的 TGT。為了避免這個問題,出現了 constrained delegation

Constrained delegation,受限委派

前面說到 unconstrained delegation 有可能導致 service1會 濫用 user 身份的風險。所以出現了 constrained delegation。實現的方式就是,域管理員對 service1 的賬號加以限制,當 user 訪問 service1 的時候,使得 service1 只能利用 user 的身份去訪問 service2,而無法像 unconstrained delegation 那樣去訪問域中的任何服務。

S4U, Service for user

S4U 是微軟對 MIT Kerberos 的一個擴展,這個擴展帶來了兩個功能:

  1. Service for User to Proxy (S4U2proxy),這個就是 constrained delegation
  2. Service for User to Self (S4U2self),這個也被稱為 Protocol transition

Protocol transition

也就是 S4U2self (Service for User to Self),作用就是驗證協議切換。

user –> service1 –> service2

user 訪問了 service1 后,service1 要利用 kerberos 協議以 user 的身份去訪問 service2,但是這要求 user 訪問 service1 的時候,也是利用的 kerberos 協議去與 service 1 進行驗證的。那麼如果不是的話怎麼辦呢?

service1 有可能只是一個網站,user 在登陸這個網站的時候只是像登陸普通網站一樣在一個表單裏面輸入了一個賬號密碼而已,而且這個賬號密碼可能只是網站內部的賬號密碼,並不是域的賬號密碼。

這個時候就需要 protocol transition 來進行驗證協議切換。

這裡涉及到 S4U 協議的細節內容,不太好描述,有興趣的直接看協議文檔吧:

https://msdn.microsoft.com/en-us/library/cc246071.aspx

簡而言之一句話:
如果 service1 有了 protocol transition 權限的話,service1 可以以任何一個域內用戶的身份向 KDC 申請一張訪問 service1 自身的票據,而且不需要知道目標用戶的密碼。比如 service1 可以以域管理員 Administrator 的身份向 KDC 申請一張訪問 service1自身的票據。(如果你能找到這麼一個服務,並且可以通過這個服務執行代碼的話,你是有可能直接利用這個功能提權至域管理員的,當然這個時候你獲取到的域管權限是被限制在這台機器上的,無法訪問別的服務器。)

匯總

背景知識介紹完成,下面講一下如何利用 S4U2self 與 S4U2Proxy 的功能來實現變種黃金票據。這肯定是建立在你已經有了域管權限的基礎上。

假如有域 EAST.COM
域控名為:2008-EAST-DC
域控 IP 為:192.168.99.150
另一台域內機器名:2008-DM1,IP 為 192.168.99.101
我自己使用的機器為 MAC,IP 為 192.168.99.1

同時,我的 /etc/hosts 中有如下配置,這是為了照顧 impacket 的代碼邏輯(或者說 kerberos 的工作邏輯,在 kerbeors 的世界里機器的 netbios name 或 FQDN 是很重要的),否則工具無法正常工作:

192.168.99.101 2008-dm1
192.168.99.150 east.com
192.168.99.150 2008-EAST-DC

1.我們需要有一個普通域賬號(你可以新建一個,或者選一個不怎麼常用的),且這個域賬號的密碼一定要非常強壯。防止被別人利用 kerberoast 類的攻擊破解出來。 假如我這裡選擇名為 ateam 的賬號,因為只是演示,所以我把密碼設置為 1qazCDE#

利用 Kerberos delegation 打造變種黃金票據

2.要讓這個域賬號成為「服務賬號」(並不需要以這個賬號來啟動任何服務),所以我們需要在這個域賬號上面設置 spn。只有服務賬號才可以開啟 S4U 的功能。

setspn -U -A variant/golden ateam

利用 Kerberos delegation 打造變種黃金票據

3.為 ateam 賬號設置了 SPN 后,用域管理員權限為這個賬號開啟 s4u2self (protocol transition) 的權限,並設置 S4U2Proxy 列表。

利用 Kerberos delegation 打造變種黃金票據

第一處箭頭表示為此賬號開通 constrained delegation 權限,也就是 S4U2Proxy 權限。第二處箭頭表示為此賬號開通 protocol transition 權限,也就是 S4U2self 權限。第三處本應是一個由目標 SPN 組成的列表,我們要添加的目標 SPN 是 krbtgt/EAST.COM。但是因為 krbtgt 這個域賬號默認是禁用的而且無法啟用,導致我們無法利用界面來添加這個 SPN。

可以用如下 powershell 腳本:

Import-Module activedirectory
$user = Get-ADUser ateam -Properties "msDS-AllowedToDelegateTo"
Set-ADObject $user -Add @{ "msDS-AllowedToDelegateTo" = @("krbtgt/EAST.COM") }

我對 powershell 不熟,上面的代碼執行完后好像會把選項改成 「僅使用 Kerberos」,還需要手動改回來,最終的設置應該如下:

利用 Kerberos delegation 打造變種黃金票據

(考驗你 Kerberos 基礎的時刻到了,想一下為什麼目標 SPN 要設置成 krbtgt/EAST.COM)

4.準備完成

下面來看一下效果,利用 impacket 的 getST.py 與 wmiexec.py:

1、./getST.py -dc-ip 192.168.99.150 -spn krbtgt/EAST.COM -impersonate Administrator east.com/ateam:1qazCDE#

(注意,這條命令執行兩次的話,先刪除上一次執行生成的 Administrator.ccache 文件)

a. getST.py 先以 ateam 為賬號 1qazCDE# 為密碼向域控申請了一張 TGT,我們將這張 TGT 稱為 ticket1 吧。這張 TGT 代表的是 ateam 這個賬號的身份。

利用 Kerberos delegation 打造變種黃金票據

b. 然後利用這張 TGT 進行 S4U2self 請求,利用 S4U2self 以 Administrator 的名義向 TGS 申請了一張訪問自身服務的票(雖然並沒有任何服務以 ateam 這個賬號啟動,也許更準確地說應該是申請了一張訪問 variant/golden 這個 SPN 的票,還記得前面我們在 ateam 這個賬號上面註冊了 variant/golden 這個 SPN 吧?) ,我們將這張票稱為 ticket2 吧

利用 Kerberos delegation 打造變種黃金票據

c. 拿到了 ticket2 后,次向 KDC 發起 SU42Proxy 請求(會帶上 ticket2,在下圖的 addtitional-tickets 中),以 Administrator 的名義向 KDC 申請一張到 krbtgt/EAST.COM 的票,將這張票稱為 ticket3 吧

利用 Kerberos delegation 打造變種黃金票據

d. 最後,我們拿到了一張代表着 Administrator 身份的可以訪問 krbtgt/EAST.COM 服務的票。 那這張 ticket3 到底是什麼票?能做什麼?這就是 Administrator 這個賬號 TGT 啊!所謂的 TGT 跟其他的 Kerberos 票據沒有任何區別。用來訪問 TGS 服務或者說在這個例子裏面 krbtgt/EAST.COM 這個服務的票就是 TGT。

e. 最終我們拿到的這個 TGT 會被保存到當前目錄 Administrator.ccache 下。

export KRB5CCNAME=Administrator.ccache
klist

利用 Kerberos delegation 打造變種黃金票據

需要去看 SFU 的協議文檔才能完全看明白這幾步

所以實現的效果就是,我們通過 ateam 這個普通的域賬號,通過利用 S4U 協議,拿回了 Adminstrator 這個賬號(可以是域內任何賬號)的一張 TGT。全程是不需要用到 krbtgt 這個賬號的任何信息的。

最終效果

用獲取到的 Administrator 的 TGT 訪問 2008-DM1 這台機器:

export KRB5CCNAME=Administrator.ccache
./wmiexec.py -no-pass -k administrator@2008-dm1 -dc-ip 192.168.99.150

利用 Kerberos delegation 打造變種黃金票據

訪問域控:

利用 Kerberos delegation 打造變種黃金票據

需要在域裏面做的所有操作都可以用 powershell 完成,不過我對 powershell 不熟,也沒心情去現學了。

總結

這種方法相對於傳統的黃金票據動作稍微有點大。傳統的黃金票據也沒有太好的檢查方案,而本文說到的這種說法好檢查一些,只需要查一下域裏面哪些賬號開了 protocol transtition 權限,以及他們的 S4U2Proxy 的 SPN 列表就可以了。

參考資料


利用 Kerberos delegation 打造變種黃金票據
本文由 Seebug Paper 發佈,如需轉載請註明來源。本文地址:https://paper.seebug.org/620/

转载请注明:IMGIT » 利用 Kerberos delegation 打造變種黃金票據

发表我的评论
取消评论

*

code

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址