攻击者如何利用AppleScript绕过防御机制

概述

当我们分析macOS安全性和攻击者所使用的工具时，无论是野外发生的真实攻击，还是红队演习过程中的真实工具，我们都会联想到类似于Python脚本、Shell脚本、恶意文档、可疑扩展之类的内容，当日，还包括伪造、篡改或木马等方式。尽管AppleScript的存在时间与Python一样早，并且比macOS 10本身早了8-9年，但AppleScript（一种内置的macOS技术）在安全领域却很少被关注到。

正如我在这篇文章中要展示的那样，攻击者目前正在广泛使用AppleScript。其中包括攻击者在广告软件中的使用，也包含其在持久化、反分析、浏览器劫持、欺骗等任务中的使用。令人担忧的是，由于安全研究社区中对于AppleScript的关注不足，研究人员往往没有注意到AppleScript中一些最为强大或独特的功能，我们将在本篇文章中介绍其中的一些功能，希望可以引起研究人员的关注和后续分析。

开发者：为什么不喜欢AppleScript？

与Bash和其他Shell语言不同，同时也与Python这样的广泛被采用的语言不通，AppleScript时macOS所特有的语言。我们不仅不能在Windows和Linux等操作系统上使用这种语言，甚至还不能在iOS和iPadOS的其他Apple操作系统上使用这种语言。

作为一种语言，AppleScript以其古怪、缓慢、难以使用、只能编写简单脚本而闻名。它之所以怪异，是因为它尝试使用“自然语言”，但语法完全是由人工定义，通常情况时不一致的，看上去比较不直观，同时也非常冗长。假设要完成计算/usr/bin目录中项目数量的简单任务，我们来比较一下不同语言的代码实现。其中，Shell脚本永远是最为简洁的：

ls -l /usr/bin | wc -l

Python比较冗长，但看上去也非常整洁和熟悉：

#!/usr/bin/python
import os
path, dirs, files = next(os.walk("/usr/bin"))
print len(files)

但是，AppleScript编写的代码却完全不同。

tell application "System Events"
    set theFiles to name of every file of folder "bin" of folder "usr" of startup disk
    count of theFiles
end tell

AppleScript的执行速度也很慢，因为除其他外，底层技术都通过一个名为Apple Event Manager的过时接口构造和发送Apple Events，该接口是为Apple的System 7操作系统（1991年发布）所编写的，甚至在当时没有针对性能进行优化。

从历史上来看，如果使用AppleScript开发脚本将会非常困难，并且开发该脚本的大多数用户都会尝试使用免费内置的（Apple）Script Editor.app，该脚本几乎缺少开发人员通常期望和需要的所有功能——没有调试器、没有自省变量、没有代码片段或有效的代码自动完成功能，这还是其中缺少的一部分功能。

在当时，Script Editor的唯一第三方替代产品的价格维持在200美元，并且仅有20天的限时试用期。

简而言之，开发者如果要生产一个只能在macOS系统中使用的产品，所花费的时间、精力和金钱上的投入无疑在性价比上是非常低的。实际上，AppleScript在几乎所有开发者选择工具时都会排在最后，开发者们往往倾向于使用高效的编程语言。最终就导致了，这种语言尽管存在了30年之久，但大多数Mac管理员、Mac开发人员或Mac最终用户几乎都没有使用AppleScript。确实，AppleScript可能是有史以来最不受喜爱的编程语言。

攻击者：为什么喜欢AppleScript？

AppleScript是为自动化和应用程序之间的通信而设计的，其目标是允许普通用户将重复性的任务连接到一起，并在无需进一步进行用户交互的前提下执行。例如，我们可以让mail.app在收到来自特定发件人的电子邮件时，或者是在收到主题行或内容中带有特定关键字的电子邮件时自动触发脚本，从电子邮件中提取所需的详细信息，然后使用所需的信息在Excel或Numbers中填充数据库，并在数据输入过程中即时化地对其进行格式化和排序。一旦脚本编写完成，用户就无需再参与其中。

事实证明，自动化应用程序间通信和避免用户交互，也是广大攻击者所持续追逐的一个目标。他们可以在无需用户参与的情况下，按照自己的想法来运行流行的应用程序（例如：电子邮件客户端、Web浏览器和Microsoft Office组件）。

因此，尽管对于开发人员来说，这种编程语言缺乏吸引力，但的确有一部分攻击者正在广泛使用AppleScript，即使这部分攻击者的开发技术不是特别熟练，但也存在一定的威胁因素。我们来看一些具体的样本。

macOS恶意软件中AppleScript的最新样本

最近，有攻击者针对Safari浏览器进行劫持，在浏览器中安装了一个隐藏的LaunchAgent，通过Sehll脚本加载、编译和执行AppleScript。

首先，从DMG中打包的Shell安装程序脚本开始，该脚本中本应包含一个名为“PDFConverter4u”的应用程序。但实际上，在磁盘映像的隐藏.assets文件夹中，包含第一阶段的Shell脚本：

5f198e82c0cf9a9f7d7a8d01273a6ad75a17a95960d8996dcdd028922b3d97bc

这将会解压缩，并执行第二阶段的Shell脚本：
55529224e9f70f5cab007e2ca98f6aec5cf31eb923fdfc09f60c01cc45c80666

最终会生成隐藏的启动代理，该启动代理执行另一个Shell脚本，其中包含通过osascript启动的AppleScript代码。

cdaa2121d79031cf39159198dfe64d3695a9c99ff7c3478a0b8953ade9052ecc

AppleScript的目的是使用攻击者提供的Shell脚本，替换用户在搜索引擎（例如：Google、Bing、Yahoo!）中输入的搜索内容。这是攻击者通过点击流量实现收入的一种快速而简便的方法，同时也会影响受害者用户的工作效率。

尽管这个特定的样本打包在单独的文件中，但其他许多恶意样本都使用纯文本字符串或经过混淆后的Base64或类似编码，将AppleScript直接写入MachO二进制文件中。

从Bundlore安装程序中提取的以下字符串表明，该代码试图强制在Google Chrome浏览器中启用JavaScript执行，然后使用AppleScript在浏览器前置窗口的活动标签中执行该代码。

来自41e0d31d52cb93f6a5020a278e8f360a6e134e6cc7092b4a5e575ac8b96a8d74的字符串

接下来展示的恶意样本，是Pirrit恶意软件的变种。

21331ccee215801ca682f1764f3e37ff806e7510ded5576c0fb4d514b4cf2b7c

恶意软件的作者使用了纯文本AppleScript和Base64编码后的AppleScript，针对Safari、Chrome和Firefox浏览器进行攻击。

以下是针对Firefox的一些Base64解码后的内容，尝试执行自动击键，以将当前URL复制到用户剪贴板，然后将URL替换为攻击者指定的URL。

如何在没有Apple Events的情况下使用AppleScript

提到Base64，下一个样本中展示了许多普通用户和开发人员所忽略的AppleScript功能，但是攻击者却注意到了这一点。这个功能就是，我们可以使用AppleScript执行任何其他类型的脚本，包括Python这样的脚本，在下面的恶意样本中，该代码投放了Empire漏洞利用套件。

实际上，AppleScript可以调用Python、Perl、Bash，甚至可以调用所有命令行工具，并且可以将其功能带入到AppleScript，并与其他实用程序相结合。

以上所有示例，都使用了我们所说的“vanilla AppleScript”。自从平台诞生以来，就一直使用AppleScript本地语言。但是从Yosemite版本（10.10）开始，直至现在最新版本的macOS，AppleScript开始通过访问Cocoa框架而获得了越来越强大的功能，这为创建功能更为强大的程序和应用程序提供了可能，而AppleScript本身就是如此。通过AppleScript执行的Objective C，在速度方面与在MachO二进制文件中执行的Objective C相差不多。

尽管到目前为止，我们还没有看到威胁行为者利用这些强大的功能，但至少有两个优势，可能会让攻击者后续选择利用这种语言。首先是这种语言可以避免检测，其次是这种语言较为容易得到一个良好的开发环境。

使用AppleScript逃避检测

在执行过程中避免被检测，是所有恶意软件（甚至包括勒索软件）的主要目标。而AppleScript为这类攻击者提供了多种执行方式。除了简单地执行.scrpt文件之外，还可以从邮件规则、Shell程序脚本、内存中、命令行、MachO中、纯文本、未编译的文件、Automator工作流程、文件夹操作、Finder服务或日历事件中执行恶意软件。

由于AppleScript具有无需编译二进制文件就可以执行Objective C代码的能力，因此新增了很多攻击的可能性。使用AppleScript，可能还会绕过macOS Catalina 10.15中新引入的kextless安全框架的绕过检测工具的功能。

在Cedric Owens的一篇文章中，Owens使用了三个最新开发的第三方安全工具，利用Apple Endpoint Security框架，来测试哪些可以被检测到、哪些不可以被检测到。Owens发现的最值得关注的事件之一，是如果我们通过osascript和vanilla AppleScript捕获用户的剪贴板，那么这样的活动很容易被他测试的所有工具检测到。

osascript -e 'the clipboard'

但是，当使用本地Cocoa API NSPasteboard时，Owens测试的所有Endpoint Security框架支持的工具似乎都无法捕获这样的活动。当然，我们现在也可以从AppleScript本地执行NSPasteboard。

我们原本非常简单的一行osascript，现在已经变成了14行外观复杂的AppleScript-ObjC。很少有人会尝试在脚本编辑器中构造这种代码。

但是，开发复杂的AppleScript，现在或多或少已经成为了过去。前面已经提到，第三方替代产品现在已经有了长期的免费试用版本，并且零售价格是以前价格的一半。更重要的是，它还允许我们将大量的示例代码拖放到脚本中，例如上面展示的脚本中所使用的示例代码。它提供了对开发人员友好的功能，例如代码自动完成和API查找，这些功能确实减轻了开发AppleScript代码的繁琐程度。

我们接下来看另一个样本。对于许多攻击者来说，都希望能够避免运行特定软件。Little Snitch就是其中的一个例子，而各类虚拟机软件是另一个例子。我们可以通过名称，轻松地获取到正在运行的应用程序列表，然后通过NSWorkspace直接带哦用Cocoa API来对其进行测试。

如果我们只想对特定应用程序的存在进行正确或错误的测试，可以将应用程序名称放在列表中国，并在第一次命中时返回true。

换而言之，通过利用AppleScript的Cocoa框架钩子，我们可以执行本地代码，而无需构建MachO二进制文件或MachO应用程序的开销。我们可以以无文件的方式来执行这个操作，这样我们就不会被新的“kextless”工具所发现，并且与macOS上可用的任何其他类型代码相比，我们可以以更多的方式执行该代码，包括Shell脚本、Python脚本或本地macOS Bundle。

总结

时至今日，开发者以前之所以不选择AppleScript的原因，已经不再成立。但是，攻击者逐渐发现利用AppleScript所具有的优势，因此我们可以做出合理假设，攻击者很有可能会在以后更加深入地研究这种语言所提供的功能。得益于Objective C的本地挂钩、强大的Cocoa框架、各种执行方法以及出色的免费IDE，AppleScript已经逐渐成为功能强大、功能丰富且易于开发的工具。

攻击者总是会不断尝试被防御者忽略的东西，而AppleScript就是其中之一。在一些地方，我们甚至会将AppleScript称为是“macOS的PowerShell”。而现在，我们是时候应该停止将AppleScript视为是有史以来最不受欢迎的编程语言，实际上，它有可能是会统治一切的macOS编程语言。