標題：針對macOS的RustBucket惡意軟件如何逃避檢測？

https://hacker.bz/t/entry/15872-%E6%A8%99%E9%A1%8C%EF%BC%9A%E9%87%9D%E5%B0%8Dmacos%E7%9A%84rustbucket%E6%83%A1%E6%84%8F%E8%BB%9F%E4%BB%B6%E5%A6%82%E4%BD%95%E9%80%83%E9%81%BF%E6%AA%A2%E6%B8%AC%EF%BC%9F/

Followers

今年4月，JAMF的研究人員就詳細介紹了一場針對macOS用戶的複雜APT活動，該活動利用多階段惡意軟件，最終形成了能夠在受感染的設備上下載和執行下一步惡意軟件的Rust後門，他們稱之為“RustBucket”，根據已有的證據，研究人員認為其幕後組織是朝鮮黑客組織“BlueNoroff”，“BlueNoroff”通常被認為是Lazarus的分支。

RustBucket能夠被植入到受害者的設備中，隨時自動調整各項配置，以逃避殺毒軟件的檢測，因此非常難以被察覺。 RustBucket 利用AppleScript，當用戶打開某些特定網站時，會加載相關惡意組件，然後將這款木馬儲存在本地。之後，黑客則可以通過NSTask 啟動這款木馬並收集受害者的隱私信息。為了能夠持續收集用戶信息，攻擊者會將這款木馬加入名為LaunchAgents 的開機自啟文件夾中，並且會不斷調整木馬的各項配置，以盡可能地迴避殺毒軟件的檢測。目前，該惡意軟件還無法被檢測到，因此用戶在實際的使用過程中，往往非常難以察覺這款惡意木馬的存在。

今年5月，ESET發布了針對macOS用戶的第二個RustBucket變體的詳細信息，隨後在6月，Elastic發現了第三個變體，其中包括以前未見過的持久化功能。

值得注意的是，RustBucket在惡意軟件的各個階段所採取的反逃避和反分析措施的範圍和類型。我們將在本文回顧該活動中使用的多種惡意軟件有效負載，並強調了RustBucket為逃避分析和檢測而部署的新技術。

階段1：AppleScript Dropper攻擊始於一個偽裝成PDF Viewer應用程序的Applet。 Applet只是以.app格式保存的經過編譯的AppleScript。與常規的macOS應用程序不同，Applet通常缺乏用戶界面，其功能僅作為開發人員向用戶傳播AppleScript的一種方式。

惡意攻擊者選擇不將腳本保存為僅運行，這允許我們使用內置的osadecompile工具輕鬆地反編譯腳本，實際上，這就是蘋果GUI腳本編輯器在查看編譯腳本時在後台運行的內容。

階段1執行三個“執行shell腳本”命令來設置階段2

該腳本包含三個do shell腳本命令，用於下載和執行下一階段。在JAMF描述的變體中，這是一個名為內部PDF查看器的基本PDF查看器。

階段1將階段2寫入/Users/Shared/文件夾，該文件夾不需要權限，惡意軟件無需繞過TCC即可訪問。與Elastic描述的階段1變體的不同之處在於，它將階段2作為隱藏文件寫入/Users/Shared/.pd。

階段1很容易成為攻擊鏈中最簡單和最容易被檢測到的部分。 do shell腳本命令的參數應該出現在Mac的統一日誌中，並作為命令行工具（如ps實用程序）的輸出。

階段1的成功在很大程度上取決於攻擊者使用社會工程策略的程度。在JAMF描述的示例中，攻擊者使用了一個精心設計的技巧，要求“內部”PDF閱讀器讀取所謂的機密或“受保護”文件。受害者被要求執行階段1，相信它能夠閱讀他們收到的PDF文件。事實上，階段1只是一個dropper，旨在保護階段2順利運行，以防沒有惡意PDF的人偶然發現它。

階段2：用Swift和Objective-C編寫的有效負載研究人員發現了許多不同的Stage 2有效負載，有些是用Swift編寫的，有些是用Objective-C編寫的，並且都是為英特爾和蘋果的矽架構編譯的。階段2示例的大小和代碼工件各不相同。通用的“fat”二進製文件在160Kb到210Kb之間。

大小不一

在這些示例中，可以找到各種用戶名字符串。到目前為止，我們在階段2的二進製文件中觀察到內容如下所示：

儘管在大小和代碼構件方面存在差異，但是階段1、2的有效負載都具有從命令和控制服務器檢索階段3的共同任務。階段2有效負載需要一個特製的PDF來解鎖代碼，這將導致下載階段3，並提供一個異或密鑰來解碼附加在PDF末尾的混淆C2。

在一些變體中，這些數據是在之前的研究人員所描述的downAndExecute函數中執行的，在其他情況下，研究人員注意到下一階段的下載是在名為down_update_run函數中執行的。此函數會因示例而異。例如，在b02922869e86ad06ff6380e8ec0be8db38f5002b中，它通過system()運行硬編碼命令。

階段2通過system()調用執行shell命令來檢索並運行階段3

但是，相同的函數在其他示例中(例如，d5971e8a3e8577dbb6f5a9aad248c842a33e7a26)使用NSURL API和完全不同的邏輯。

不同示例的代碼差異很大，這可能表明開發人員不同

Elastic的研究人員進一步指出，在用Swift編寫的階段2的一個新變體中，User Agent字符串都是小寫的，而在早期的Objective-C示例中則不是。

User Agent字符串從階段2的Objective-C版本微妙地更改為Swift版本

雖然User-Agent字符串本身不區分大小寫，但如果這是一個有意的更改，則攻擊者可能正在服務器端解析User-Agent字符串，以排除對C2的不必要調用。也就是說，在RustBucket示例的其他地方(例如，階段1中的“/users/shared”)可以看到大小寫方面的粗心，並且大小寫差異可能是不同開發人員使用不同標準的結果。

在最近的示例中，在受害者的設備上執行之前，階段2檢索的有效負載在_CS_DARWIN_USER_TEMP(又名$TMPDIR，通常位於/var/folders/……/……/t /)中以“ErrorCheck.zip”的形式寫入磁盤。

階段3：新版本釋放持久性LaunchAgent到目前為止，階段3的有效負載有兩種不同的變體：

A: 182760cbe11fa0316abfb8b7b00b63f83159f5aa Stage3

B: b74702c9b82f23ebf76805f1853bc72236bee57c ErrorCheck, System Update

這兩個變體都是從Rust源代碼編譯的Mach-O通用二進製文件。變體A比變體B大得多，前者的通用二進製文件重11.84MB，而變體B的通用二進製文件重8.12MB。精簡後的新變體導入的crate要少得多，並且較少使用兩者中的sysinfo crate。值得注意的是，變體B取消了變體A中用於收集環境信息和通過查詢system_profiler的SPHardwareDataType值來檢查虛擬機中的執行情況的webT類。

webT類出現在階段3有效負載的變體A中

然而，變體B並沒有清除代碼中的所有webT構件，對缺失模塊的引用仍然可以在字符串中找到。

8.1.png

8.2.png

在階段3變體B中仍然可以找到引用缺失的webT模塊的字符串

子字符串“Trojan”在早期變體中沒有出現，它也出現在同一字符串引用的文件路徑中。

重要的是，變體B包含了一個在早期版本的RustBucket中不存在的持久機制。它採用了硬編碼的LaunchAgent的形式，它被寫入磁盤~/Library/LaunchAgents/com.apple.systemupdate.plist。 ErrorCheck文件也將自己的副本寫入~/Library/Metadata/System Update，並作為LaunchAgent的目標可執行文件。

因為階段3需要URL作為啟動參數，因此在屬性列表中提供URL作為程序參數。奇怪的是，在啟動時傳遞給ErrorCheck的URL被附加到LaunchAgent plist中的這個硬編碼URL。

RustBucket LaunchAgent將硬編碼的URL與啟動時提供的URL聯繫起來

在變體A的webT方法中發現的許多惡意軟件功能，在變體B中，現在隱藏在巨大的symm .updator:main函數中。它負責監視環境並解析啟動時接收到的參數、處理命令、收集磁盤信息等。這個龐大的函數超過22Kb，包含501個基本塊。不過經過分析，除了Elastic之前描述的功能之外，該功能還收集磁盤信息，包括主機設備的磁盤是SSD還是舊的rotational platter 類型。