前言
在本篇文章中,主要介紹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來表示一些常見的組或身份
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:
重點需要了解的是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屬性將變為:
cn |
objectSid |
sIDHistory |
User1 |
S-1-5-21-549713754-3312163066-842615589-2235 |
S-1-5-21-3464518600-3836984554-627238718-2103 |
此時當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:指定查詢的目標計算機
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():
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處的代碼之后基本沒有條件檢查的函數了,恢復堆棧和寄存器后就直接返回了,這樣就達到了繞過檢查邏輯的目的
3. 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了: