SILENTTRINITY的工作原理與檢測技巧是什么

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

介紹

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

DLR

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

SILENTTRINITY的工作原理

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

檢測SILENTTRINITY

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

動態裝配加載

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

IronPython程序集

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

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

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

SafetyKatz模塊

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

流程活動

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

結論

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

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