對2019全年的Mac惡意程序的全面分析
Lazarus Loader (又名macloader)
Lazarus黑客組織創建的Lazarus Loader (又名macloader)，作為第一階段的植入程序載入程序，可以直接從內存中下載並執行模塊！
感染媒介：被植入惡意載荷的應用
2019年12月，安全研究人員Dinesh_Devadoss發現了來自朝鮮的黑客可能在新發現的傳播惡意軟體的加密貨幣交易網站的背後，如果他們下載了一個所謂的套利平台，將會感染macOS用戶。
該惡意軟體最初是由安全研究員Dinesh Devadoss發現的，他在推特上發布了該發現。Bleeping Computer對其進行了檢測，發現在大多數病毒檢測引擎中幾乎未檢測到該惡意軟體，只有五個經過測試的惡意軟體發現了該惡意軟體。
#Lazarus #macOS＃木馬
md5：6588d262529dc372c400bef8478c2eec
hxxps：//unioncrypto.vip/
包含代碼：從內存中載入Mach-O並執行/寫入文件並執行@patrickwardle
我們已經注意到，Lazarus APT組織喜歡以加密貨幣的用戶或管理員為目標。他們實際上是通過偽造的加密貨幣公司和交易應用程序感染此類目標的方法。在該惡意程序中，我們再次看到他們利用這種方法感染目標。
具體來說，他們首先創建了一個經過偽造的加密貨幣交易平台「 Union Trader Crypto」 ，它託管在一個名為「 unioncrypto.vip」的網站上，該網站宣傳「智能加密貨幣套利交易平台」。
使用此IP地址查詢VirusTotal，我們找到一個觸發了惡意應用程序下載的URL請求（https://www.unioncrypto.vip/download/W6c2dq8By7luMhCmya2v97YeN）：
該應用程序通過名為UnionCryptoTrader.dmg的磁碟映像交付，我們可以通過hdiutil attach命令安裝該磁碟映像：
$ hdiutil attach ~/Downloads/UnionCryptoTrader.dmg
expected CRC32 $7720DF1C
/dev/disk4 GUID_partition_scheme
/dev/disk4s1 Apple_APFS
/dev/disk5 EF57347C-0000-11AA-AA11-0030654
/dev/disk5s1 41504653-0000-11AA-AA11-0030654 /Volumes/UnionCryptoTrader
它包含一個包：UnionCryptoTrader.pkg：
$ ls -lart /Volumes/UnionCryptoTrader
total 40120
-rwxrwxrwx 1 patrick staff 20538265 Sep 4 06:25 UnionCryptoTrader.pkg
通過我們的「WhatsYourSign」應用程序，可以很容易地看到UnionCryptoTrader.pkg包未簽名：
這意味著如果macOS試圖打開它，用戶將受到警告：
顯然，Lazarus組織還是使用了其賴以成功的攻擊手段，即針對具有木馬交易應用程序的加密貨幣交換的員工。
持久性攻擊的來源：LaunchAgent
調查UnionCryptoTrader.pkg程序包，發現將在安裝過程結束時執行的安裝後腳本：
所以，該腳本的目的是永久安裝啟動守護程序。
具體而言，腳本將執行以下操作：
1.將隱藏的plist（.vip.unioncrypto.plist）從應用程序的Resources目錄移至/ Library / LaunchDaemons；
2.將其設置為root許可權；
3.創建一個/ Library / UnionCrypto目錄；
4.將隱藏的二進位文件（.unioncryptoupdater）從應用程序的Resources目錄移至/ Library / UnionCrypto /；
5.將其設置為可執行；
6.執行此二進位文件（/ Library / UnionCrypto / unioncryptoupdater）；
我們可以通過文件或進程監控器來被動地觀察安裝的這一部分：
# ProcessMonitor.app/Contents/MacOS/ProcessMonitor -pretty
{
"event" : "ES_EVENT_TYPE_NOTIFY_EXEC",
"process" : {
"uid" : 0,
"arguments" : [
"mv",
"/Applications/UnionCryptoTrader.app/Contents/Resources/.vip.unioncrypto.plist",
"/Library/LaunchDaemons/vip.unioncrypto.plist"
],
"ppid" : 3457,
"ancestors" : [
3457,
951,
1
],
"signing info" : {
"csFlags" : 603996161,
"signatureIdentifier" : "com.apple.mv",
"cdHash" : "7F1F3DE78B1E86A622F0B07F766ACF2387EFDCD",
"isPlatformBinary" : 1
},
"path" : "/bin/mv",
"pid" : 3458
},
"timestamp" : "2019-12-05 20:14:28 0000"
}
...
{
"event" : "ES_EVENT_TYPE_NOTIFY_EXEC",
"process" : {
"uid" : 0,
"arguments" : [
"mv",
"/Applications/UnionCryptoTrader.app/Contents/Resources/.unioncryptoupdater",
"/Library/UnionCrypto/unioncryptoupdater"
],
"ppid" : 3457,
"ancestors" : [
3457,
951,
1
],
"signing info" : {
"csFlags" : 603996161,
"signatureIdentifier" : "com.apple.mv",
"cdHash" : "7F1F3DE78B1E86A622F0B07F766ACF2387EFDCD",
"isPlatformBinary" : 1
},
"path" : "/bin/mv",
"pid" : 3461
},
"timestamp" : "2019-12-05 20:14:28 0000"
}
...
{
"event" : "ES_EVENT_TYPE_NOTIFY_EXEC",
"process" : {
"uid" : 0,
"arguments" : [
"/Library/UnionCrypto/unioncryptoupdater"
],
"ppid" : 1,
"ancestors" : [
1
],
"signing info" : {
"csFlags" : 536870919,
"signatureIdentifier" : "macloader-55554944ee2cb96a1f5132ce8788c3fe0dfe7392",
"cdHash" : "8D204E5B7AE08E80B728DE675AEB8CC735CCF6E7",
"isPlatformBinary" : 0
},
"path" : "/Library/UnionCrypto/unioncryptoupdater",
"pid" : 3463
},
"timestamp" : "2019-12-05 20:14:28 0000"
}
儘管安裝啟動守護程序需要root許可權，但安裝程序將提示用戶輸入其憑據：
安裝程序完成後，二進位的unioncryptoupdater將執行並永久安裝：
$ ps aux | grep [u]nioncryptoupdater
root 1254 /Library/UnionCrypto/unioncryptoupdater
當然，BlockBlock會檢測啟動守護進程的持久性嘗試：
由於RunAtLoad項被設置為true時，將指示macOS每次重新啟動受感染的系統時自動啟動ProgramArguments數組中指定的二進位文件。因此，/Library/UnionCrypto/unioncryptoupdater將自動重新執行。
重新安裝啟動守護程序（其plist和二進位文件都隱藏在應用程序的資源目錄中），再次與Lazarus組的操作方式匹配。具體請見卡巴斯基的報告：「 AppleJeus：Lazarus使用偽造的安裝程序和macOS惡意程序盜竊加密貨幣。」
功能：第一階段植入（內存模塊載入器）
好了，現在來分析持久化的unioncryptoupdater二進位文件。
通過file命令，我們可以確定它是一個標準的macOS(64位)二進位：
$ file /Library/UnionCrypto/unioncryptoupdater
/Library/UnionCrypto/unioncryptoupdater: Mach-O 64-bit executable x86_64
codesign實用程序向我們顯示了它的標識符（macloader-55554944ee2cb96a1f5132ce8788c3fe0dfe7392）以及未使用有效的代碼簽名ID進行簽名的事實，而是使用了adhoc (Signature=adhoc)：
$ codesign -dvv /Library/UnionCrypto/unioncryptoupdater
Executable=/Library/UnionCrypto/unioncryptoupdater
Identifier=macloader-55554944ee2cb96a1f5132ce8788c3fe0dfe7392
Format=Mach-O thin (x86_64)
CodeDirectory v=20100 size=739 flags=0x2(adhoc) hashes=15 5 location=embedded
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=0 size=12
運行字元串實用程序（帶有-a標誌）將顯示一些有趣的字元串：
$ strings -a /Library/UnionCrypto/unioncryptoupdater
curl_easy_perform() failed: %s
AES_CYPHER_128 encrypt test case:
AES_CYPHER_128 decrypt test case:
AES_CYPHER_192 encrypt test case:
AES_CYPHER_192 decrypt test case:
AES_CYPHER_256 encrypt test case:
AES_CYPHER_256 decrypt test case:
Input:
IOPlatformExpertDevice
IOPlatformSerialNumber
/System/Library/CoreServices/SystemVersion.plist
ProductVersion
ProductBuildVersion
Mac OS X %s (%s)
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 /
/tmp/updater
%s %s
NO_ID
%s%s
12GWAPCT1F0I1S14
auth_timestamp
auth_signature
check
https://unioncrypto.vip/update
done
/bin/rcp
Could not create image.
Could not link image.
Could not find ec.
Could not resolve symbol: _sym[25] == 0x4d6d6f72.
Could not resolve symbol: _sym[4] == 0x4d6b6e69.
諸如IOPlatformSerialNumber之類的字元串以及對SystemVersion.plist的引用可能暗示了基本的調查功能，比如收集有關受感染系統的信息，對libcurl API（curl_easy_perform）和嵌入式URL的引用表明可能含有網路或命令和控制功能。
在反彙編器中打開一個二進位文件（unioncryptoupdater），顯示主函數簡單地調用一個名為onRun的函數：
1int _main() {
2 rbx = objc_autoreleasePoolPush();
3
4 onRun();
5
6 objc_autoreleasePoolPop(rbx);
7 return 0x0;
8}
雖然很長、很複雜，但我們可以分析它的邏輯，過程分6步：
1.實例化一個名為Barbeque: Barbeque::Barbeque()的c 類，通過將nm實用程序的輸出傳遞到c filt中，我們可以從Barbeque類中轉儲其他方法：
$ nm unioncryptoupdater | c filt
unsigned short Barbeque::Barbeque()
unsigned short Barbeque::get( ... )
unsigned short Barbeque::post( ... )
unsigned short Barbeque::~Barbeque()
根據方法名稱，也許Barbeque類包含與網路相關的邏輯。
2.調用一個名為getDeviceSerial的函數，通過IOKit (IOPlatformSerialNumber)檢索系統序列號：
調試惡意軟體(在VM中)，顯示此方法正確返回虛擬機的序列號(VM nL/ueNmNG)：
(lldb) x/s $rax
0x7ffeefbff810: "VM nL/ueNmNG"
3.通過讀取系統文件/System/Library/CoreServices/SystemVersion.plist（包含各種與版本有關的信息），調用名為getOSVersion的函數以檢索系統版本：
$ defaults read /System/Library/CoreServices/SystemVersion.plist
{
ProductBuildVersion = 18F132;
ProductCopyright = "1983-2019 Apple Inc.";
ProductName = "Mac OS X";
ProductUserVisibleVersion = "10.14.5";
ProductVersion = "10.14.5";
iOSSupportVersion = "12.3";
}
同樣，在調試器中，我們可以觀察到惡意軟體正在檢索這些信息，特別是ProductName、ProductUserVisibleVersion和ProductBuildVersion：
(lldb) x/s 0x7ffeefbff790
0x7ffeefbff790: "Mac OS X 10.14.5 (18F132)"
4.構建一個由時間和硬編碼值組成的字元串：12GWAPCT1F0I1S14；
5.調用Barbeque :: post（）方法以聯繫遠程命令和控制伺服器（https://unioncrypto.vip/update）：網路邏輯通過libcurl來執行實際的通信：
防火牆LuLu可以輕鬆檢測到此連接嘗試：
6.如果伺服器使用字元串「 0」響應，則惡意程序將休眠10分鐘，然後再次通過伺服器重啟：
否則，它將調用base64解碼伺服器的響應的函數，然後調用名一個為processUpdate的函數來執行從伺服器下載的有效載荷。
好的，我們已經有了一個相當標準的持久性第一階段植入載荷，它將信標發送到遠程伺服器，以便（可能）實現第二階段全功能植入載荷。
這時，遠程命令和控制伺服器仍處於聯機狀態，它只響應一個「0」，這意味著沒有提供有效載荷。
因此，在其餘的分析中，我們必須依靠靜態分析方法。
但是，第一階段的植入的特別之處在於：含有直接從內存執行接收到的有效載荷的能力！
那該惡意程序如何實現這種隱身功能？
回想一下，如果伺服器以有效載荷（而不是字元串「0」）響應，則惡意程序將調用processUpdate函數。首先，processUpdate通過aes_decrypt_cbc解密所述有效載荷，然後調用一個名為load_from_memory的函數。
首先，load_from_memory函數映射一些內存（帶有保護：PROT_READ | PROT_WRITE | PROT_EXEC）。然後，在調用名為memory_exec2的函數之前，將解密後的有效載荷複製到此內存區域中：
memory_exec2函數調用Apple API NSCreateObjectFileImageFromMemory，來從mach-O文件的內存緩衝區創建「目標文件映像」。之後，將調用NSLinkModule方法來鏈接「目標文件映像」。
由於內存中的進程映像的布局與磁碟中的映像不同，所以不能簡單地將文件複製到內存中並直接執行它。相反，必須調用NSCreateObjectFileImageFromMemory和NSLinkModule等API（它們負責準備內存中的映射和鏈接）。
一旦惡意程序映射並鏈接了下載的有效載荷，它就會調用一個名為find_macho的函數，該函數似乎在內存映射中搜索MH_MAGIC_64，mach_header_64結構（0xfeedfacf）中的64位「mach magic number」：
一旦find_macho方法返回，惡意程序便開始解析內存中的mach-O文件，它似乎正在尋找LC_MAIN載入命令（0x80000028）的地址：
有關解析mach-O文件的深入技術討論，請參閱：「解析Mach-O文件」。
LC_MAIN載入命令包含諸如mach-O二進位文件的入口點之類的信息，例如，unioncryptoupdater二進位文件的偏移量18177：
然後，惡意程序檢索入口點的偏移量（在LC_MAIN load命令中的偏移量0x8處找到），設置一些參數，然後跳轉到該地址：
此時，內存中已經開始執行遠程下載的有效載荷！
在2015年的BlackHat大會上，我討論了這種內存中文件執行方法，該方法可增加隱身性並使取證複雜化。
不出所料，它終於出現在macOS惡意程序中了。
有關在macOS中執行內存中代碼的更多詳細信息，請參閱：
1.從內存運行macOS上的可執行文件；
2.蘋果的「 MemoryBasedBundle 」示例代碼；
如果你想基於此方法處理Mach-O的內存中載入，我可以編寫一個簡單的PoC：https：//t.co/IP3JhRyf7h，只需運行make即可。
前#OBTS發言人Felix Seele（@ c1truz_ ）指出，著名的InstallCore惡意程序還使用了NSCreateObjectFileImageFromFromMemory和NSLinkModule API來實現內存中執行。
有趣的是，如果內存中的代碼執行失敗，則該惡意程序具有一個「備份」計劃。具體來說，如果load_from_memory不返回0，則代表成功，它將把接收到的有效載荷寫到/ tmp / updater，然後通過調用系統來執行：
這幾篇文章對2019年新出現的Mac惡意程序進行了全面技術分析，但是，如前所述，我們沒有涵蓋前幾年出現的惡意程序。
本文翻譯自：https://objective-see.com/blog/blog_0x53.html
