利用Firefox 0day传播的macOS恶意软件（Part 3）

360安全客 安全知识 149250 4

 

0x00 前言

大家可以从此处下载本文分析的恶意样本（密码：infect3d），注意别感染自己的系统。

最近有攻击者利用Firefox 0day针对加密货币交易所的员工发起攻击，在前面两篇文章中（Part 1及Part 2），我们讨论了攻击过程，分析了攻击者利用漏洞植入的Mac恶意软件（OSX.Netwire.A），我们还详细分析了恶意软件的驻留机制，完全逆向分析了恶意样本，澄清该样本可以接受攻击者远程发出的指令。

来自Coinbase的安全研究员Philip Martin最近又提到了此次攻击中使用的第二款Mac恶意软件样本：

最开始时VirusTotal上的所有反病毒（AV）引擎都识别不了第二个样本（sha1：b639bca429778d24bda4f4a40c1bbc64de46fa79）：

因此，我决定仔细分析该样本，与大家分享研究结果。

需要注意的是，（对于VirusTotal上的）AV引擎有可能只是全功能安全产品的一个（很小）子集。

因此，企业所部署的综合类安全产品可能还包括基于行为检测的引擎（未包含在VirusTotal上），通常情况下可能会检测到这个新的威胁。

 

0x01 静态分析

今天我们分析的样本名为mac，最早于2019-06-20提交到VirusTotal上：

MD5: AF10AAD603FE227CA27077B83B26543B
SHA1: B639BCA429778D24BDA4F4A40C1BBC64DE46FA79
SHA256: 97200B2B005E60A1C6077EEA56FC4BB3E08196F14ED692B9422C96686FBFC3AD

虽然Vitali Kremez提到过该样本可能与OSX.Mokes有关（回头我们再来讨论这一点），但目前反病毒社区还没有正式命名该样本。

让我们开始分析这个样本文件。

根据file工具的输出结果，该恶意软件是一个64位的mach-O程序，但体积有点大（13M）：

$ file ~/Downloads/mac 
~/Downloads/mac: Mach-O 64-bit executable x86_64

$ du -h ~/Downloads/mac 

13M ~/Downloads/mac

通过我开发的WhatsYourSign开源工具，可知恶意软件并没有经过签名：

从MachOView的输出结果中，我们还知道恶意软件链接了许多“有趣的”库/框架：

如果想使用终端来分析，可以考虑使用macOS内置的otool工具（加上-L参数）来查看恶意软件链接的库/框架。

我们可以根据这些“有趣的”库/框架，来一窥恶意软件可能包含的功能：

  • IOKit.framework
  • AVFoundation.framework
  • CoreWLAN.framework
  • OpenGL.framework
  • CoreVideo.framework

接下来，我们可以使用内置的strings工具（加上-a参数）来提取其中内置的（ascii）字符串：

$ strings -a ~/Downloads/mac

storeaccountd
com.apple.spotlight
Spotlightd
Skype
soagent
Dropbox
quicklookd
Google
Chrome
accountd
Firefox
Profiles
trustd

User-Agent
Connection
Close

screenshots/
desktop_

jpeg
*.doc
*.docx
*.xls
*.xlsx


transport.museum
nishinomiya.hyogo.jp
is-into-cars.com
...

其中有很多字符串与静态链接库有关（如OpenSSL），这（很有可能）能解释恶意软件体积为什么会这么大。

前面提到过，strings工具有个限制，就是只能提取出ascii字符串。为了提取unicode（或者“宽”）字符串，我们可以使用如下python脚本：strings.py

1def unicode_strings(buf, n=4):
2    reg = b"((?:[%s]x00){%d,})" % (ASCII_BYTE, n)
3    uni_re = re.compile(reg)
4    for match in uni_re.finditer(buf):
5        try:
6            yield String(match.group().decode("utf-16"), match.start())
7        except UnicodeDecodeError:
8            pass

结果表明恶意软件中包含一些有趣的unicode字符串：

$ python ~/Downloads/strings.py ~/Downloads/mac

0x8f0018: :/keys/bot
0x8f01a8: %1/Library/LaunchAgents/%2.plist
0x8f0210: powershell.exe 
0x8f0248: dd*.ddt
0x8f0270: kk*.kkt
0x8f0298: aa*.aat
0x8f02c0: ss*.sst
0x8f02e8: application/octet-stream
0x8f0338: Content-Type
0x8f0378: JPEG
0x8f03c0: auto-file-search
0x8f0400: :/file-search
0x8f0478: search%1
0x8f0910: s://
0x8f0957: keys
0x8f0963: dbot

此外恶意软件中还包含5000多个url，部分url列举如下：

mizunami.gifu.jp saitama.jp kimino.wakayama.jp int.bo cambridge.museum andasuolo.no lardal.no transport.museum nishinomiya.hyogo.jp is-into-cars.com karlsoy.no bungoono.oita.jp int.ci chikujo.fukuoka.jp franziskaner.museum cc.nj.us genkai.saga.jp tysfjord.no ra.it air-traffic-control.aero ina.ibaraki.jp in-the-band.net ainan.ehime.jp oita.oita.jp national-library-scotland.uk …

继续分析，我们可以通过class-dump工具来重构出内置的Objective-C类信息。虽然其中大多数是与QT有关的类，但还有一些有趣的AVFoundation协议，这些协议通常与webcam有关：

$ class-dump ~/Downloads/mac 
//
//     Generated by class-dump 3.5 (64 bit).
//
//     File: ~/Downloads/mac
//
//                           Arch: x86_64
//       Minimum Mac OS X version: 10.7.0
//                    SDK version: 10.9.0

@protocol AVCaptureFileOutputRecordingDelegate 
- (void)captureOutput:(AVCaptureFileOutput *)arg1 didFinishRecordingToOutputFileAtURL:(NSURL *)arg2 fromConnections:(NSArray *)arg3 error:(NSError *)arg4;

@optional
- (void)captureOutput:(AVCaptureFileOutput *)arg1 willFinishRecordingToOutputFileAtURL:(NSURL *)arg2 fromConnections:(NSArray *)arg3 error:(NSError *)arg4;
- (void)captureOutput:(AVCaptureFileOutput *)arg1 didResumeRecordingToOutputFileAtURL:(NSURL *)arg2 fromConnections:(NSArray *)arg3;
- (void)captureOutput:(AVCaptureFileOutput *)arg1 didPauseRecordingToOutputFileAtURL:(NSURL *)arg2 fromConnections:(NSArray *)arg3;
- (void)captureOutput:(AVCaptureFileOutput *)arg1 didStartRecordingToOutputFileAtURL:(NSURL *)arg2 fromConnections:(NSArray *)arg3;
@end

 

0x02 动态分析

现在我们可以在虚拟机中执行恶意软件，观察具体行为。通常我们会观察一些行为，包括：

  • 文件创建
  • 进程创建
  • 网络连接

为了主动观察与恶意软件有关的文件操作事件，我们可以使用macOS内置的文件监控工具：fs_usage

# fs_usage -w -f filesystem | grep mac 

mkdir /Users/user/Library/Dropbox mac.14997

open /Users/user/Desktop/mac
RdData[A] /Users/user/Desktop/mac mac.14997

open /Users/user/Library/Dropbox/quicklookd
WrData[A] /Users/user/Library/Dropbox/quicklookd mac.14997

execve /Users/user/Library/Dropbox/quicklookd

fs_usage会捕捉整个系统的文件操作事件，输出信息可能会非常庞大。

因此，我们建议过滤输出结果，比如只匹配与恶意软件（即mac）有关的事件。

在fs_usage的输出结果中，我们可以看到恶意软件会将自己安装到~/Library/Dropbox/目录中，重命名为quicklookd：

快速对比哈希后，我们可以确认“新的”quicklookd就是恶意软件的副本：

$ shasum -a 1 ~/Desktop/mac ~/Library/Dropbox/quicklookd 
b639bca429778d24bda4f4a40c1bbc64de46fa79  /Users/user/Desktop/mac
b639bca429778d24bda4f4a40c1bbc64de46fa79  /Users/user/Library/Dropbox/quicklookd

在文件监控输出中，可以看到当恶意软件拷贝副本后，会（通过execve）执行这个副本。我们也可以通过ProcInfo进程监控工具来捕捉到这个事件：

procInfo[730:14509] process start:
pid: 733
path: /Users/user/Library/Dropbox/quicklookd
user: 501
args: (
    "/Users/user/Library/Dropbox/quicklookd
)
 signing info: {
    signatureStatus = "errSecCSUnsigned (-67062)";
}

在网络行为方面，我们可以使用免费的开源防火墙LuLu，检测到恶意软件会尝试连接到C&C服务器：185.49.69.210

内置工具lsof也能发现这个连接动作：

lsof -i TCP

COMMAND   PID USER  TYPE      NAME
quicklookd 733 user IPv4 TCP  192.168.0.128:49291->185.49.69.210:http (SYN_SENT)

几秒之后，BlockBlock会告诉我们恶意软件尝试部署驻留机制：

显然，恶意软件会通过启动代理来实现本地驻留。让我们来导出这个启动代理plist（quicklookd.plist）：

$ defaults read  ~/Library/LaunchAgents/quicklookd.plist 
{
    KeepAlive = 1;
    Label = quicklookd;
    ProgramArguments =     (
        "/Users/user/Library/Dropbox/quicklookd"
    );
    RunAtLoad = 1;
}

由于启动代理（quicklookd.plist）中将RunAtLoad键值设置为1，因此每次用户登录时，操作系统都会自动启动/Users/user/Library/Dropbox/quicklookd，这样恶意软件就能实现本地驻留。

此时，我们的动态分析已经提供了关于恶意软件的许多信息，包括：

  • 安装方式
  • 驻留方式（启动代理）
  • C&C服务器地址

让我们进一步研究安装逻辑，其中恶意软件部署了一些“应变机制”，加大检测难度。

在前文提取内置的字符串时，我们看到了恶意软件在安装过程及驻留过程中使用的一些字符串，如quicklookd以及Dropbox（恶意软件会将副本安装到Dropbox目录中的quicklookd）。

在恶意软件程序中，还包含其他一些字符串：

非常有趣的是，当我们将VM恢复到初始状态，（重新）运行恶意软件后，会导致恶意软件在安装和驻留过程中选择其他字符串（比如App Store / storeaccountd）。比如这一次，BlockBlock对驻留操作的警告信息如下（注意这一次安装的副本名为storeaccountd）：

了解恶意软件的安装、驻留机制，提取出（可能的）C&C服务器地址后，接下来我们分析一下恶意软件的功能。

然而首先我们需要了解一下OSX.Mokes，可以借此了解这款恶意软件的功能。

 

0x03 与OSX.Mokes的关联

几天之前，Vitali Kremez发表过一则推文，表示这款恶意软件“很有可能与Backdoor.OSX.Mokes有关”：

根据下文分析，Kremez的推测完全正确。

OSX.Mokes是一个跨平台、全功能的后门，最早由Kaspersky在2016年发现。在一篇研究文章中，Kaspersky详细分析了OSX.Mokes的安装过程、驻留机制、网络行为以及其他比较重要的功能（屏幕截取、音频录制、文档查找及提取等）。

我之前也发表过关于OSX.Mokes的文章，也在几次会议演讲中分析过这款恶意软件：

在2017年的那篇文章中，我提到过：

恶意软件（OSX.Mokes）可能会将自己安装到多个目录中。

除了使用常用的storeuserd名称外，恶意软件还可能安装到如下路径：

~/Library/com.apple.spotlight/SpotlightHelper
~/Library/Dock/com.apple.dock.cache
~/Library/Skype/SkypeHelper
~/Library/Dropbox/DropboxCache
~/Library/Google/Chrome/nacld
~/Library/Firefox/Profiles/profiled

并列对比OSX.Mokes（2016年版）以及今天发现的样本：

虽然某些名称有所出入，但整体还是存在大量重复特征。

这两个样本之间还有许多共同特征，比如在Kaspersky关于OSX.Mokes的那篇文章中，他们曾提到：

这款恶意软件……可以从受害者主机中窃取各种类型的数据（屏幕截图、音频/视频流捕捉、办公文档、键盘记录）。

观察最早的OSX.Mokes样本，我们可以找到硬编码的几个文件搜索特征：

0x0000001C unicode :/file-search
0x0000000E unicode *.xlsx
0x0000000C unicode *.xls
0x0000000E unicode *.docx
0x0000000C unicode *.doc

在今天的这个样本中，就像Vitali Kremez提到过的，我们也可以找到完全相同的文件搜索特征（按字母序）：

0x00000001008f0400 unicode :/file-search
0x00000001008c0fed unicode *.doc
0x00000001008c0ff3 unicode *.docx
0x00000001008c0ffa unicode *.xls
0x00000001008c1000 unicode *.xlsx

Kaspersky还在2016年的文章中提到：

与其他平台上的操作类似，如果C&C服务器不可达，这款恶意软件就会创建多个临时文件，其中包含已收集到的数据：

$TMPDIR/ss0-DDMMyy-HHmmss-nnn.sst （截屏）
$TMPDIR/aa0-DDMMyy-HHmmss-nnn.aat （音频数据）
$TMPDIR/kk0-DDMMyy-HHmmss-nnn.kkt （键盘记录）
$TMPDIR/dd0-DDMMyy-HHmmss-nnn.ddt （其他数据）

同样，在今天的这款样本中，我们也能看到相似的特征，特别是用来存储已收集数据的文件扩展名：

根据其他共同点（如特征字符串、跨平台静态编译库、功能甚至大小（约13M）），我认为今天这款样本是OSX.Mokes的一个新变种。

因此我将其标记为OSX.Mokes.B。

 

0x04 总结

通过Firefox 0day，攻击者针对加密货币交易所员工发起攻击，目的是部署两个驻留型macOS后门。

在前面两篇文章中（Part 1及Part 2），我们讨论了攻击过程，分析了第一款后门（OSX.Netwire.A）。

在本文中，我们分析了第二款后门（SHA1：B639BCA429778D24BDA4F4A40C1BBC64DE46FA79），包括：

  • 安装过程
  • 驻留方法
  • C&C服务器
  • 具体功能

有趣的是，我们（还有其他小伙伴）确认这个后门是OSX.Mokes的一款新变种。

虽然该样本（OSX.Mokes.B）与原始的OSX.Mokes样本（2016年）密切相关，但VirusTotal上没有任何一个AV引擎能检测出恶意行为。

这也从另一方面说明基于恶意行为的检测会比静态分析特征更为有效，Objective-See的工具就能发挥理想的效果，这些工具能够检测并阻止这种先进（且更“新”）的恶意威胁：

  • KnockKnock：可以检测恶意软件部署的启动代理驻留机制，不受具体名称影响
  • BlockBlock：可以检测恶意软件的驻留操作，不受具体名称影响
  • LuLu：可以检测恶意软件与C&C服务器的连接行为
  • OverSight：可以检测恶意软件对音频或视频数据的收集行为

这些工具都是免费开放的，欢迎大家使用。

（完）