<bdo id="2b3yk"><code id="2b3yk"></code></bdo>

  • <output id="2b3yk"><sup id="2b3yk"></sup></output>
    <output id="2b3yk"><ruby id="2b3yk"></ruby></output>
  • <code id="2b3yk"><delect id="2b3yk"></delect></code>

  • 探討后滲透測試工具SILENTTRINITY的工作原理與檢測技巧

    2019-02-27 36421人圍觀 ,發現 1 個不明物體 系統安全

    介紹

    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)。   
    1.pngDLR是一個運行時環境,允許像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”庫來實現,如下面的代碼片段所示。
    3.png因此,我們可以嘗試使用Python腳本跟蹤此類函數調用的存在,如下圖所示。
    4.png如圖所示,我們可以觀察到“GetType”和“CreateInstance”函數的JIT-Inlining失敗,因此表明這些函數至少執行了一次。但是,我們也看到內存中的程序集負載與實例創建和SILENTTRINITY程序集本身相關:
    5.png

    IronPython程序集

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

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

     這可以通過利用“ResolveAssembly”事件的回調方法來完成(Richter,2010)。下面的代碼片段顯示了如何實現這一目標。 6.png一旦正確加載了程序集,C#后門就能夠利用IronPython引擎來執行Python代碼,如下面的代碼片段所示。
    7.png由于上述DLL的加載是SILENTTRINITY的關鍵部分,我們也可以嘗試尋找這些裝配負載的證據:
    8.png在這個例子中,我們可以通過“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的實現:
    9.png正如在動態語言運行時一節中提到的,可以通過使用.NET ETW提供程序來跟蹤JIT和Interop事件來檢測這一點。
    10.png正如所料,我們能夠觀察到來自SharpSploit模塊的VirtualAlloc和MinDumpWrite函數調用的互操作事件所關注的事件。

    流程活動

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

    結論

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

    參考

    https://github.com/byt3bl33d3r/SILENTTRINITY

    https://docs.microsoft.com/en-us/dotnet/framework/reflection-and-codedom/dynamic-language-runtime-overview

    https://blogs.msdn.microsoft.com/microsoft_press/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition/

    *參考來源:countercept,由周大濤編譯,轉載請注明來自FreeBuf.COM

    發表評論

    已有 1 條評論

    取消
    Loading...
    css.php 宁夏卫视在线直播观看