前言

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

SID簡介

1. 安全標識符(SID)

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

SID一般由以下組成：

“S”表示SID，SID始終以S開頭

“1”表示版本，該值始終為1

“5”表示Windows安全權威機構

“21-1463437245-1224812800-863842198”是子機構值，通常用來表示并區分域

“1128”為相對標識符(RID)，如域管理員組的RID為512

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

2. AD域中的SID

在AD域中，SID同樣用來唯一標識一個對象，在LDAP中對應的屬性名稱為objectSid：

重點需要了解的是LDAP上的sIDHistory屬性。

(1) SIDHistory

SIDHistory是一個為支持域遷移方案而設置的屬性，當一個對象從一個域遷移到另一個域時，會在新域創建一個新的SID作為該對象的objectSid，在之前域中的SID會添加到該對象的sIDHistory屬性中，此時該對象將保留在原來域的SID對應的訪問權限。

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

此時我們將用戶User1從域A遷移到域B，那么他的LDAP屬性將變為：

此時當User1訪問域A中的資源時，系統會將目標資源的DACL與User1的sIDHistory進行匹配，也就是說User1仍具有原SID在域A的訪問權限。

值得注意的是，該屬性不僅在兩個域之間起作用，它同樣也可以用于單個域中，比如實戰中我們將一個用戶A的sIDHistory屬性設置為域管的objectSid，那么該用戶就具有域管的權限。

另一個實戰中常用的利用，是在金票中添加Enterprise Admins組的SID作為sIDHistory，從而實現同一域林下的跨域操作，這個將在后面關于金票的文章中闡述。

(2) SID Filtering

SID Filtering簡單的說就是跨林訪問時目標域返回給你的服務票據中，會過濾掉非目標林中的SID，即使你添加了sIDHistory屬性。SID Filtering林信任中默認開啟，在單林中默認關閉

mimikatz的sid模塊

1. sid::lookup

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

/name：指定對象名，將其轉換為SID

/sid：指定SID，將其轉換為對象名

/system：指定查詢的目標計算機

其原理是調用LookupAccountName()和LookupAccountSid()來實現對象名和SID之間的相互轉化，這類API底層是調用MS-LSAT協議(RPC)，比如將對象名轉換為SID，底層調用的是LsarLookupNames4()

2. sid::query

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

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

/sid：指定要查詢對象的objectSid

/system：指定查詢的目標域控（LDAP）

這個功能其原理就是直接使用LDAP查詢，通過sAMAccountName查詢對應的objectSid，或者通過objectSid查詢對應的sAMAccountName

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

3. sid::modify

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

/sam：通過sAMAccountName指定要修改SID的對象

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

/new：要修改對象的新SID

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

修改時的操作就很簡單了，調用LDAP操作的API對域對象的objectSid進行修改，主要使用的是ldap_modify_s()：從mimikatz學習Windows安全之訪問控制模型（二）

4. sid::add

該功能用來向一個域對象添加sIDHistoy屬性，有兩個參數：

/sam：通過sAMAccountName指定要修改的對象

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

/new：要修改sIDHistory為哪個對象的SID，該參數可指定目標的sAMAccountName或objectSid，當指定名稱時會先調用LookupAccountSid將其轉換為SID

使用該功能也要先執行sid::patch，修改時同樣是操作LDAP通過ldap_modify_s()修改，不再贅述

5. sid::clear

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

/sam：要清空sIDHistory的對象的sAMAccountName

/sid：要清空sIDHistory的對象的objectSid

原理就是使用ldap_modify_s()將目標對象sIDHistory屬性修改為空

6. sid::patch

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

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

sid::patch分析

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

整個patch過程分為兩步：

第一步patch的是SampModifyLoopbackCheck()的內存

第二步patch的是ModSetAttsHelperPreProcess()的內存

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

1. 域控對LDAP請求的處理

大致分析一下域控對本地LDAP修改請求的過濾與處理流程，當我們修改objectSid和sIDHistory時，SampModifyLoopbackCheck()會過濾我們的請求，即使繞過該函數修改objectSid時，仍會受到SysModReservedAtt()的限制

侵入式切換到lsass進程并重新加載用戶態符號表：

給兩個檢查函數打斷點

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

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

SampModifyLoopbackCheck()函數中存在大量Check函數，通過動態調試發現修改sIDHistoy的請求經過該函數后便會進入返回錯誤代碼的流程。

繼續調試到下一個斷點

在SysModReservedAtt()執行結束后，正常的修改請求不會在jne處跳轉，而當修改objectSid時會在jne處跳轉，進入返回錯誤的流程

2. Patch 1/2

當我們想要進行內存patch時，通常會尋找目標內存地址附近的一塊內存的值作為標記，編寫程序時首先在內存中搜索該標記并拿到標記的首地址，然后再根據偏移找到要patch的內存地址，然后再進行相應的修改操作。

mimikatz正是使用這種方法，其在內存中搜索的標記在代碼中有明確的體現：

我們將域控的ntdsai.dll拿回本地分析，在其中搜索標記41 be 01 00 00 00 45 89 34 24 83

這一部分內容是在函數SampModifyLoopbackCheck()函數的流程中，我們可以使用windbg本地調試對比一下patch前后的函數內容

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

使用lm列出模塊，可以看到lsass進程中加載了ntdsai.dll，表明此時我們可以訪問ntdsai.dll對應的內存了

我們直接查看SampModifyLoopbackCheck()函數在內存中的反匯編

為了對比patch前后的區別，我們使用mimikatz執行sid::patch，然后再查看函數的反匯編。如下圖所示，箭頭所指處原本是74也就是je，而patch后直接改為eb即jmp，使流程直接跳轉到0x7ffc403b2660

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

Patch 2/2

同理，按照mimikatz代碼中的標記搜索第二次patch的位置0f b7 8c 24 b8 00 00 00

查看ModSetAttsHelperPreProcess()處要patch的內存，patch前如下圖所示

patch完成后內存如下圖，其實本質是讓SysModReservedAtt()函數失效，在內存中尋找到標記后偏移-6個字節，然后將驗證后的跳轉邏輯nop掉

4. 解決patch失敗的問題

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

此時我們只需要將目標的ntdsai.dll拿下來找到目標地址

然后修改為正確的內存標記和對應的偏移地址即可，如果新增的話記得定義好版本號等信息

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

滲透測試中的應用

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

1. SIDHistoy后門

拿下域控后，我們將普通域用戶test1的sIDHistory屬性設置為域管的SID：

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

2. 域內“影子賬戶”

假設我們此時拿到了域控，然后設置一個普通域用戶的SID為域管的SID

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

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

并且此時也可以用該用戶的賬號和密碼登錄域控，登錄成功后是administrator的session。但該操作很有可能造成域內一些訪問沖突（猜測，未考證），建議在生產環境中慎用

3. 跨域

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

除了這種方法，我們也可以直接修改當前子域對象的sIDHistory屬性，假設我們現在拿到一個子域域控，通過信任關系發現存在一個父域，此時我們無法訪問父域域控的CIFS

但我們給子域域管的sIDHistory屬性設置為父域域管的SID

此時就可以訪問父域域控的CIFS了：


最后

【網安資料詳細】

總結

以上是生活随笔為你收集整理的【安全】从mimikatz学习Windows安全之访问控制模型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。