這篇文章給大家介紹SILENTTRINITY的工作原理與檢測技巧是什么，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

員工經(jīng)過長期磨合與沉淀，具備了協(xié)作精神，得以通過團隊的力量開發(fā)出優(yōu)質的產(chǎn)品。成都創(chuàng)新互聯(lián)堅持“專注、創(chuàng)新、易用”的產(chǎn)品理念，因為“專注所以專業(yè)、創(chuàng)新互聯(lián)網(wǎng)站所以易用所以簡單”。公司專注于為企業(yè)提供成都網(wǎng)站制作、成都網(wǎng)站設計、外貿(mào)營銷網(wǎng)站建設、微信公眾號開發(fā)、電商網(wǎng)站開發(fā)，微信小程序開發(fā)，軟件按需設計網(wǎng)站等一站式互聯(lián)網(wǎng)企業(yè)服務。

介紹

SILENTTRINITY 是最近發(fā)布的一款基于IronPython和c#的工具。這篇文章將深入探討它的工作原理和檢測技術。 .NET由于其強大的功能、易于開發(fā)以及在現(xiàn)代Windows平臺上的默認存在的特點，已經(jīng)成為安全領域中的一個重要組件。由于藍隊檢測惡意PowerShell的能力不斷增強，它開始取代PowerShell(最初出于類似的原因使用它)。 IronPython本質上是與.NET框架緊密結合的Python。這意味著攻擊者能夠利用簡單的Python腳本與.NET庫的強大功能，更輕松地在Windows平臺上開發(fā)。

DLR

.NET語言變量類型和方法在編譯時綁定，而Python是一種解釋型腳本語言。因此，如何在.NET環(huán)境中執(zhí)行Python代碼？答案就在于DLR(dynamic language runtime)。下圖顯示了DLR的架構視圖（Microsoft 2017）。       
DLR是一個運行時環(huán)境，允許像Python這樣的動態(tài)語言在.NET上運行，并最終編譯成相應的通用中間語言（CIL）格式。使這成為可能的DLR組件之一是“動態(tài)對象互操作性”。   Python的一個關鍵特性是它不必在編譯時聲明其變量類型。相反，變量類型解析在運行時執(zhí)行，這與標準.NET語言（如C＃）的運行方式不同。為了解決這個問題，DLR提供了一種稱為“動態(tài)”的數(shù)據(jù)類型。分配有“動態(tài)”數(shù)據(jù)類型的變量在運行時而不是編譯時解析，從而允許Python保持其動態(tài)特性并仍然能夠在.NET環(huán)境中運行。 在SILENTTRINITY中，IronPython代碼嵌入并在C＃對象中執(zhí)行，并且通過擴展，在.NET環(huán)境中執(zhí)行。這意味著它將首先編譯為CIL代碼，隨后通過使用JIT引擎成為本機代碼。我們之前已經(jīng)在博客中對此進行了更詳細的討論（    第1 部分和第2部分）。  

SILENTTRINITY的工作原理

SILENTTRINITY由運行Python的C2服務器和C＃后門組成，使用動態(tài).NET程序集在受害者的機器上執(zhí)行。下面的圖片顯示了SILENTTRINITY如何工作的。我們將使用msbuild stager機制作為示例。    
   
1.首先將包含c#后門的xml文件放入受害者。2.通過MsBuild.exe執(zhí)行，C＃后門被反序列化并加載到內存中。3.一旦植入到內存中，后門將連接回SILENTTRINITY C2服務器并將名為staged.zip的zip文件下載到內存中。該zip文件實際上由IronPython的.NET程序集和一個名為stage.py的Python腳本組成。4.隨后，.NET程序集通過使用.NET的庫加載到內存中。一旦加載了程序集，就能夠調用IronPython引擎來執(zhí)行stage.py.5.C2服務器現(xiàn)在可以向受害者推送Python編碼的模塊。 

檢測SILENTTRINITY

現(xiàn)在我們已經(jīng)了解了SILENTTRINITY的工作原理，讓我們來看看如何檢測它。我們將通過發(fā)布的Python腳本使用. NET ETW提供程序來跟蹤CLR底層使用的行為。

動態(tài)裝配加載

C＃implant實際上是“ST”類型的C＃類，它的一個實例是在運行時動態(tài)創(chuàng)建的。這可以通過.NET的“Reflection”和“Activator”庫來實現(xiàn)，如下面的代碼片段所示。    
因此，我們可以嘗試使用Python腳本跟蹤此類函數(shù)調用的存在，如下圖所示。    
如圖所示，我們可以觀察到“GetType”和“CreateInstance”函數(shù)的JIT-Inlining失敗，因此表明這些函數(shù)至少執(zhí)行了一次。但是，我們也看到內存中的程序集負載與實例創(chuàng)建和SILENTTRINITY程序集本身相關:    

IronPython程序集

C＃后門如果想要使用python引擎執(zhí)行python代碼,那么在這之前，它必須首先在運行時導入一組程序集，即： 

?IronPython.dll
?IronPython.Modules.dll
?Microsoft.Dynamic.dll
?Microsoft.Scripting.dll

 這可以通過利用“ResolveAssembly”事件的回調方法來完成（Richter，2010）。下面的代碼片段顯示了如何實現(xiàn)這一目標。 一旦正確加載了程序集，C＃后門就能夠利用IronPython引擎來執(zhí)行Python代碼，如下面的代碼片段所示。    
由于上述DLL的加載是SILENTTRINITY的關鍵部分，我們也可以嘗試尋找這些裝配負載的證據(jù)：    
在這個例子中，我們可以通過“DomainModuleDCStart_V1”和“ModuleDCStart_V2”事件來觀察正在加載的dll，從而表明IronPython的存在。它們也在內存中加載，沒有文件支持。但是，重要的是要注意這些程序集的存在并不表示任何惡意行為本身。使用IronPython引擎的合法.NET應用程序也會加載這些，，不過它更有可能從磁盤加載這些文件。但是，在大多數(shù)企業(yè)環(huán)境中，很多應用程序不太可能合法地使用IronPython。與其他IronPython用法的另一個重要區(qū)別是，這里涉及的程序集用于SILENTTRINITY使用的IronPython的嵌入式使用。如果IronPython被用作一個獨立的python解釋器來運行在。net框架上調用的python腳本，那么可以看到ipy.exe獨立解釋器正在使用。

SafetyKatz模塊

SILENTTRINITY包含一些后期開發(fā)階段的模塊。我們將看看其中一個模塊SafetyKatz。這很像同名的GhostPack模塊，它會轉儲lsass的進程內存，然后在內存中加載Mimikatz來提取憑據(jù)。下面的代碼片段顯示了Python中SafetyKatz的實現(xiàn)：    
正如在動態(tài)語言運行時一節(jié)中提到的，可以通過使用.NET ETW提供程序來跟蹤JIT和Interop事件來檢測這一點。    
正如所料，我們能夠觀察到來自SharpSploit模塊的VirtualAlloc和MinDumpWrite函數(shù)調用的互操作事件所關注的事件。

流程活動

除了查看.NET ETW事件，我們還可以跟蹤可疑的流程活動。由于我們在此示例中使用了msbuild stager，因此我們顯然會看到msbuild進程執(zhí)行事件。    
由于MSBuild負責執(zhí)行xml文件，我們可以尋找由MSBuild執(zhí)行的xml執(zhí)行的跡象。大多數(shù)MSBuild事件遵循術語或父和參數(shù)的通用格式，因此在整個企業(yè)中，可以基線正常活動和點偏差。我們還可以尋找源自MSBuild的連接。C＃后門必須定期連接回C2服務器以檢查待處理的操作，如下面的代碼所示。    
因此，即使沒有掛起的作業(yè)，c#后門也必須定期與C2通信，或者直到MSBuild進程終止。因此，我們可以搜索流量，如下圖所示。      

結論

作為維護者，當我們確定IOC時，這也是正確的。這篇文章提出了幾個IOC來檢測SILENTTRINITY的存在。一些IOC，例如檢測IronPython裝配加載，本身就是低保真度指標，但當你將所有活動結合起來時，SILENTRINITY的行為變得越來越具體，這有助于尋找它。在調查期間，維護者通常必須得出一個假設，并且有幾個不同的IOC通?？梢约訌娺@個假設。例如，如果我們要檢測動態(tài)程序集加載，結合IronPython程序集加載，結合MSBuild.exe的XML參數(shù)和常規(guī)網(wǎng)絡連接，那么即使在像Safetykatz這樣的惡意模塊運行之前，我們也有更多的妥協(xié)證據(jù)。    。 我們要感謝byt3bl33d3r創(chuàng)建這樣一個令人印象深刻的工具。 

關于SILENTTRINITY的工作原理與檢測技巧是什么就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。