天天看點
傳回

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

0x00 前言

上次的文章分析了mimikatz的token子產品，并簡單介紹了windows通路控制模型的概念。在本篇文章中，主要介紹sid相關的概念，并介紹mimikatz的sid子產品，着重分析sid::patch功能的原理

0x01 SID簡介

1. 安全辨別符(SID)

在Windows作業系統中，系統使用安全辨別符來唯一辨別系統中執行各種動作的實體，每個使用者有SID，計算機、使用者組和服務同樣也有SID，并且這些SID互不相同，這樣才能保證所辨別實體的唯一性

SID一般由以下組成：

  • “S”表示SID，SID始終以S開頭
  • “1”表示版本，該值始終為1
  • “5”表示Windows安全權威機構
  • “21-1463437245-1224812800-863842198”是子機構值，通常用來表示并區分域
  • “1128”為相對辨別符(RID)，如域管理者組的RID為512
【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

Windows也定義了一些内置的本地SID和域SID來表示一些常見的組或身份

SID Name
S-1-1-0 World
S-1-3-0 Creator Owner
S-1-5-18 Local SYSTEM
S-1-5-11 Authenticated Users
S-1-5-7 Anonymous

2. AD域中的SID

在AD域中，SID同樣用來唯一辨別一個對象，在LDAP中對應的屬性名稱為

objectSid

：

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

重點需要了解的是LDAP上的

sIDHistory

屬性

(1) SIDHistory

SIDHistory是一個為支援域遷移方案而設定的屬性，當一個對象從一個域遷移到另一個域時，會在新域建立一個新的SID作為該對象的

objectSid

，在之前域中的SID會添加到該對象的

sIDHistory

屬性中，此時該對象将保留在原來域的SID對應的通路權限

比如此時域A有一個使用者User1，其LDAP上的屬性如下：

cn objectSid sIDHistory
User1 S-1-5-21-3464518600-3836984554-627238718-2103 null

此時我們将使用者User1從域A遷移到域B，那麼他的LDAP屬性将變為：
S-1-5-21-549713754-3312163066-842615589-2235

此時當User1通路域A中的資源時，系統會将目标資源的DACL與User1的

sIDHistory

進行比對，也就是說User1仍具有原SID在域A的通路權限

值得注意的是，該屬性不僅在兩個域之間起作用，它同樣也可以用于單個域中，比如實戰中我們将一個使用者A的

sIDHistory

屬性設定為域管的

objectSid

，那麼該使用者就具有域管的權限

另一個實戰中常用的利用，是在金票中添加Enterprise Admins組的SID作為

sIDHistory

，進而實作同一域林下的跨域操作，這個将在後面關于金票的文章中闡述

(2) SID Filtering

SID Filtering簡單的說就是跨林通路時目标域傳回給你的服務票據中，會過濾掉非目标林中的SID，即使你添加了

sIDHistory

屬性。SID Filtering林信任中預設開啟，在單林中預設關閉

具體可以參考微軟的文檔和@dirkjanm的文章：

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/55fc19f2-55ba-4251-8a6a-103dd7c66280?redirectedfrom=MSDN

https://dirkjanm.io/active-directory-forest-trusts-part-one-how-does-sid-filtering-work/

0x02 mimikatz的sid子產品

1. sid::lookup

該功能實作SID與對象名之間的互相轉換，有三個參數：

  • /name：指定對象名，将其轉換為SID
  • /sid：指定SID，将其轉換為對象名
  • /system：指定查詢的目标計算機
【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

這個功能其原理就是直接使用LDAP查詢，通過

sAMAccountName

查詢對應的

objectSid

，或者通過

objectSid

sAMAccountName

其核心是調用Windows一系列的LDAP操作API，主要是

ldap_search_s()
【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

2. sid::query

該功能支援通過SID或對象名來查詢對象的資訊，同樣有三個參數，使用時指定/sam或/sid，/system可選

  • /sam：指定要查詢對象的

    sAMAccountName
  • /sid：指定要查詢對象的

    objectSid
  • /system：指定查詢的目标域控（LDAP）
【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

sAMAccountName

objectSid

objectSid

sAMAccountName

ldap_search_s()
【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

3. sid::modify

該功能用于修改一個域對象的SID，可以使用的參數有三個：

  • /sam：通過

    sAMAccountName

     指定要修改SID的對象
  • /sid：通過

    objectSid
  • /new：要修改對象的新SID

使用該功能是需要先使用sid::patch功能對xxxx進行patch（自然也需要先開啟debug特權），需要在域控上執行

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

修改時的操作就很簡單了，調用LDAP操作的API對域對象的

objectSid

進行修改，主要使用的是

ldap_modify_s()
【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

4. sid::add

該功能用來向一個域對象添加

sIDHistoy

屬性，有兩個參數：

  • sAMAccountName

     指定要修改的對象

  • objectSid
  • /new：要修改

    sIDHistory

     為哪個對象的SID，該參數可指定目标的

    sAMAccountName

     或

    objectSid

     ，當指定名稱時會先調用

    LookupAccountSid

     将其轉換為SID

使用該功能也要先執行sid::patch，修改時同樣是操作LDAP通過

ldap_modify_s()

修改，不再贅述

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

5. sid::clear

該功能用來清空一個對象的

sIDHistory
  • /sam：要清空

    sIDHistory

     的對象的

    sAMAccountName
  • /sid：要清空

    sIDHistory

    objectSid
【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

原理就是使用

ldap_modify_s()

将目标對象

sIDHistory

屬性修改為空

6. sid::patch

對域控LDAP修改過程中的驗證函數進行patch，需要在域控上執行，該功能沒有參數

patch共分為兩個步驟，如果僅第一步patch成功的話，那麼可以使用sid::add功能，兩步都patch成功的話才可以使用sid::modify功能

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

0x03 sid::patch分析

sid::patch在系統版本 < Vista時，patch的是samss服務中ntdsa.dll的記憶體，更高版本patch的是ntds服務中ntdsai.dll的記憶體

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

整個patch過程分為兩步：

  1. 第一步patch的是

    SampModifyLoopbackCheck()

     的記憶體
  2. 第二步patch的是

    ModSetAttsHelperPreProcess()
【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

我們以Windows Server 2012 R2環境為例來分析，首先我們需要找到NTDS服務所對應的程序，我們打開任務管理器選中NTDS服務，單擊右鍵，選擇“轉到詳細資訊”就會跳轉到對應程序，這裡NTDS服務對應的程序是lsass.exe

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

1. 域控對LDAP請求的處理

大緻分析一下域控對本地LDAP修改請求的過濾與處理流程，當我們修改

objectSid

和

sIDHistory

時，

SampModifyLoopbackCheck()

會過濾我們的請求，即使繞過該函數修改

objectSid

時，仍會受到

SysModReservedAtt()

的限制

侵入式切換到lsass程序并重新加載使用者态符号表：

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

給兩個檢查函數打斷點

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

此時我們修改一個使用者的描述來觸發LDAP修改請求

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

命中斷點後的調用棧如下：

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

SampModifyLoopbackCheck()

函數中存在大量Check函數，通過動态調試發現修改

sIDHistoy

的請求經過該函數後便會進入傳回錯誤代碼的流程

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

繼續調試到下一個斷點

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

在

SysModReservedAtt()

執行結束後，正常的修改請求不會在

jne

處跳轉，而當修改

objectSid

時會在

jne

處跳轉，進入傳回錯誤的流程

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

2. Patch 1/2

當我們想要進行記憶體patch時，通常會尋找目标記憶體位址附近的一塊記憶體的值作為标記，編寫程式時首先在記憶體中搜尋該标記并拿到标記的首位址，然後再根據偏移找到要patch的記憶體位址，然後再進行相應的修改操作

mimikatz正是使用這種方法，其在記憶體中搜尋的标記在代碼中有明确的展現：

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

我們将域控的ntdsai.dll拿回本地分析，在其中搜尋标記

41 be 01 00 00 00 45 89 34 24 83
【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

這一部分内容是在函數

SampModifyLoopbackCheck()

函數的流程中，我們可以使用windbg本地調試對比一下patch前後的函數内容

首先我們找到lsass.exe的基址并切換到該程序上下文：

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

使用

lm

列出子產品，可以看到lsass程序中加載了ntdsai.dll，表明此時我們可以通路ntdsai.dll對應的記憶體了

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

我們直接檢視

SampModifyLoopbackCheck()

函數在記憶體中的反彙編

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

為了對比patch前後的差別，我們使用mimikatz執行sid::patch，然後再檢視函數的反彙編。如下圖所示，箭頭所指處原本是

74

也就是

je

，而patch後直接改為

eb

即

jmp

，使流程直接跳轉到

0x7ffc403b2660
【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

而

0x7ffc403b2660

處的代碼之後基本沒有條件檢查的函數了，恢複堆棧和寄存器後就直接傳回了，這樣就達到了繞過檢查邏輯的目的

3. Patch 2/2

同理，按照mimikatz代碼中的标記搜尋第二次patch的位置

0f b7 8c 24 b8 00 00 00
【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

檢視

ModSetAttsHelperPreProcess()

處要patch的記憶體，patch前如下圖所示

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

patch完成後記憶體如下圖，其實本質是讓

SysModReservedAtt()

函數失效，在記憶體中尋找到标記後偏移-6個位元組，然後将驗證後的跳轉邏輯

nop

掉

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

4. 解決patch失敗的問題

由于mimikatz中記憶體搜尋的标記覆寫的windows版本不全，是以經常會出現patch失敗的問題。例如在我的Windows Server 2016上，第二步patch就會失敗，這種情況多半是因為mimikatz中沒有該系統版本對應的記憶體patch标記

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

此時我們隻需要将目标的ntdsai.dll拿下來找到目标位址

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

然後修改為正确的記憶體标記和對應的偏移位址即可，如果新增的話記得定義好版本号等資訊

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

此時重新編譯後就可以正常patch了

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

0x04 ***測試中的應用

在***測試中的利用，一個是使用SIDHistory屬性來留後門，另一個是修改域對象的SID來實作域内的“影子賬戶”或者跨域等操作

1. SIDHistoy後門

拿下域控後，我們将普通域使用者test1的

sIDHistory

屬性設定為域管的SID：

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

此時test1将具有域管權限，我們可以利用這個特性來留後門

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

2. 域内“影子賬戶”

假設我們此時拿到了域控，然後設定一個普通域使用者的SID為域管的SID

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

此時我們這個使用者仍然隻是Domain Users組中的普通域成員

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

但該使用者此時已經具有了域管的權限，例如dcsync：

并且此時也可以用該使用者的賬号和密碼登入域控，登入成功後是administrator的session。但該操作很有可能造成域内一些通路沖突（猜測，未考證），建議在生産環境中慎用

3. 跨域

通常我們拿到一個域林下的一個子域，會通過黃金票據+SIDHistory的方式擷取企業管理者權限，控制整個域林

除了這種方法，我們也可以直接修改目前子域對象的

sIDHistory

屬性，假設我們現在拿到一個子域域控，通過信任關系發現存在一個父域，此時我們無法通路父域域控的CIFS

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

但我們給子域域管的

sIDHistory

屬性設定為父域域管的SID

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

此時就可以通路父域域控的CIFS了：

【安全研究】從mimikatz學習Windows安全之通路控制模型（二）

0x05 參考

Windows
上一篇: 企業資訊安全架構之安全縱深模型設計
下一篇: 【安全研究】從mimikatz學習Windows安全之通路控制模型（三）

繼續閱讀