Calendar Alerts：macOS上的一种持久化技术-安全客

0x00 前言

在本文中，我们详细分析了如何利用日历警报实现macOS上的持久化。本文以Andy Grant在NCC上发表的一篇文章为基础，深入分析了如何从攻击者角度来实现该技术的武器化应用。我们进行了多项研究，包括逆向分析Automator.app，发现了一个未公开的API来实现该技术，也公布了用来实现持久化的JavaScript for Automation（JXA）代码。

0x01 Calendar.app

Andy在之前的文章中曾提到过，macOS内置的Calendar应用中包含许多功能，其中一个功能是可以针对某个事件，以警报方式来执行应用。用户可以通过GUI来配置该功能，创建新事件时的操作界面如下图所示：

Andy已经详细分析过这方面内容，包括研究代码的执行方式以及数据窃取方式（强烈建议大家先看一下那篇文章，写的非常精彩），然而我比较关注的是其中提到的持久化内细节。Andy提到他在实现持久化方面遇到一些困难，比如难以通过编程方式、使用AppleScript来插入事件，另外Calendar应用也会直接忽视他的请求等。我们也可以采用其他方法，比如修改支撑该应用的SQLite数据库。这种方法很好，我们可以为所有后续事件设置默认的告警行为，然而在实际环境中，这种技术很难应用。

0x02 技术分析

在测试该技术的过程中，我顺带研究了一下Automator.app，这是Apple提供的一种拖放式（drag-and-drop）应用构建解决方案，可以用来执行重复任务。Automator中就包含构建日历警报的模板。

逐步通过GUI操作，保存workflow（工作流）后，我们可以看到日历中添加了一个新的事件，并且附带了能够以新应用来执行我们workflow的警报。这是个不错的开头，我们有可能通过编程来自动完成该任务。

我开始深入研究Apple Developer文档中的EventKit，这是负责与日历事件交互的一个框架。然而在官方文档中，我并没有找到允许用户添加警报、执行应用的API。因此，我决定深入分析Automator，了解实现该过程的原理。

首先我使用Objective See的FileMonitor和ProcessMonitor分析工具，初步了解了Automator的处理流程。该应用并没有修改Calendar的数据库，也没有修改其他感兴趣的文件。因此，我使用了LLVM调试器lldb来分析。在剔除一些EventKit函数后，最后我找到了一个函数：[AMICalPluginWorkflowPersonality finishSavingWorkflow:forOperation:atURL:error:]。观察该函数的反汇编代码后，我们可以看到一系列EventKit函数，这些函数与Apple官方文档中提供的函数非常类似。

<+735>:  movq   0x58d6ff62(%rip), %rdi    ; (void *)0x00007fff90b872b0: AMEventKitSoftLinking
<+742>:  movq   0x58d6eb8b(%rip), %rsi    ; "EKEvent"
<+749>:  callq  *%r14
<+752>:  movq   0x58d6ec69(%rip), %rsi    ; "eventWithEventStore:"
<+759>:  movq   %rax, %rdi
<+762>:  movq   %r12, %rdx
<+765>:  callq  *%r14
<+768>:  movq   %rax, %rdi
<+771>:  callq  0x7fff37e3e744            ; symbol stub for: objc_retainAutoreleasedReturnValue
<+776>:  movq   %rax, %rbx
<+779>:  movq   0x58d6898e(%rip), %rsi    ; "setTitle:"
<+786>:  movq   %rax, %rdi
<+789>:  movq   -0x98(%rbp), %rdx
<+796>:  callq  *%r14
<+799>:  movq   0x58d6ec42(%rip), %rsi    ; "setStartDate:"
<+806>:  movq   %rbx, %rdi
<+809>:  movq   %r15, %rdx
<+812>:  callq  *%r14
<+815>:  movq   0x58d6ec3a(%rip), %rsi    ; "setEndDate:"
<+822>:  movq   %rbx, %rdi
<+825>:  movq   %r15, -0xd0(%rbp)
<+832>:  movq   %r15, %rdx
<+835>:  callq  *%r14

如上所示，这段反汇编代码会使用EKEvent类来创建一个新的事件，设置事件标题、开始以及结束日期。然而有一部分我不是特别熟悉，其中包含一个有趣的函数：[EKAlarm procedureAlarmWithBookmark]，该函数无法在Apple的官方文档中找到。涉及这个未公开函数的部分反汇编代码如下所示：

<+876>:  movq   0x58d6ec05(%rip), %rsi    ; "bookmarkDataWithOptions:includingResourceValuesForKeys:relativeToURL:error:"
<+883>:  xorl   %r12d, %r12d
<+886>:  movl   $0x200, %edx              ; imm = 0x200 
<+891>:  xorl   %ecx, %ecx
<+893>:  xorl   %r8d, %r8d
<+896>:  movq   %r13, %r9
<+899>:  callq  *0x58cd7f17(%rip)         ; (void *)0x00007fff723f3800: objc_msgSend
<+905>:  movq   %rax, %rdi
<+908>:  callq  0x7fff37e3e744            ; symbol stub for: objc_retainAutoreleasedReturnValue
<+913>:  movq   %rax, %r15
<+916>:  movq   (%r13), %rdi
<+920>:  callq  *0x58cd7f12(%rip)         ; (void *)0x00007fff723f36d0: objc_retain
<+926>:  movq   %rax, %r13
<+929>:  testq  %r15, %r15
<+932>:  je     0x7fff37e1138a            ; <+1034>
<+934>:  movq   0x58d6fe9b(%rip), %rdi    ; (void *)0x00007fff90b872b0: AMEventKitSoftLinking
<+941>:  movq   0x58d6ebcc(%rip), %rsi    ; "EKAlarm"
<+948>:  callq  *%r14
<+951>:  movq   0x58d6ebca(%rip), %rsi    ; "procedureAlarmWithBookmark:"
<+958>:  movq   %rax, %rdi
<+961>:  movq   %r15, %rdx
<+964>:  callq  *%r14

可以看到，Automator会创建一个新的书签，该书签是指向磁盘上特定文件的一个数据结构。随后，Automator会创建EKAlarm类的一个新实例，调用该类中的procedureAlarmWithBookmark函数，传入书签数据作为参数。太棒了，这正是我们寻找的目标。

0x03 具体实现

此时我们已经找到了所有线索，可以通过编程方式实现持久化目标。我将这些要点都融入JXA代码中，方便通过Mythic（也就是Apfell）来执行攻击代码。下面我将举个例子，通过这种攻击方式，最终将新的日历事件添加到特定的日历中。这并不是实现该技术的唯一方式（或者不是最隐蔽的方式），此外我的JXA代码还可以通过已有的事件来植入后门，或者修改用户的日历。大家可以查看GitHUb了解更多细节。

在开始操作前，我们先要设置Mythic，准备好Apfell载荷。Mythic提供了很好的官方文档，大家可以根据文档步骤来操作。接下来，我们需要使用jsimport命令，将我们的功能导入到Apfell中。

此时，我们的脚本已经载入Apfell载荷中，然后开始调用其中的函数。首先我们需要枚举用户的日历，可以使用list_calendars函数完成该任务，这个操作需要用户授予日历（有时候是联系人）的进程执行代码权限。

这里我们选择Automator日历，记录下对应的UID。接下来，我们使用JXA中的persist_calalert函数来创建新的事件。该函数调用方式如下所示：

persist_calalert(
    "My Event",                            // Title
    "/Users/rookuu/Library/Apfell.app",    // Target App
    60,                                    // Delay in seconds
    "daily",                               // Frequency of recurrence
    1,                                     // Interval of recurrence
    3,                                     // Number of events
    "711CE045-7778-4633-A6FA-27E18ADD0C17" // UID of the calendar
)

现在进程会创建新的事件，将其插入日历中。函数调用中的Delay in seconds参数用来指定第一个事件的发生时间，后续参数分别为持久化操作触发的频率、间隔以及事件数。在本例中，我们将每天创建一个新的事件，持续3天，当事件触发时，将会启动我们的恶意应用。

在Apfell中开始攻击后，我们可以在日历中看到操作结果。首次事件将在2020年10月9日 18:53触发，执行指定的app。在这个测试用例中，我们最终将执行Apfell载荷，并且在指定的时间段内，我们可以拿到回连shell，完成持久化任务。

0x04 macOS沙箱

在本文撰写过程中，Calum Hall（@_chall）曾提醒到，我没有考虑到系统上的沙箱机制，这样即使应用被成功执行，效果也不完美，除非我们能在Calendar沙箱外执行代码。

出乎我意料的是，事实证明我们并不需要关心沙箱逃逸问题，因为我们一开始就没有在沙箱中。虽然Calendar是一个沙箱化进程，但通过警报方式执行的应用并没有被沙箱化处理。如上图所示，我们执行的应用CalendarAlarmSandboxTest并没有在沙箱中。

0x05 检测机制

对这种攻击技术的检测方式很大程度上取决于具体的环境、可用的感知技术以及攻击技术的具体实现或者执行方式。

异常文件访问事件

对于这种攻击技术，我们可以重点关注在/Users/{USER}/Library/Calendars/路径下创建或修改日历事件文件的异常应用是关键的检测指标。更具体一些，我们需要关注是否有脚本进程（比如Python、osascrit、ruby等）发起了这类文件创建或者修改操作。当使用脚本来创建或者修改事件时，就会在该路径下创建或者编辑ICS文件。

进程关系

除了文件访问事件之外，防御方还可以考虑借助可以进程关系来检测。通常情况下，与日历事件有关的进程可以提供Calendar应用本身与被执行的程序或者payload之间的关系。然而，受限于macOS上进程间通信的工作方式，launchd进程通常是大多数执行进程的父进程，导致防御方无法准确绘制出父子进程关系以及进程树。Jaron Bradley之前在The Truetree Concept中已经详细讨论过这方面内容，也分析了如何利用未公开的API和XPC服务来获取“Responsible”及“Submitted by”进程标识符。在本例中，我们最终执行的“payload”应用由CoreServicesUIA提交。

可疑的osascript进程

持久化技术的检测并不一定很简单，防御方最好将检测重点集中在攻击链的早期阶段。我们在本文中讨论的PoC使用了Apfell的JXA payload，因此可以通过ESF监控osascript进程来检测。此外，osascript的执行在macOS系统以及整个环境中非常常见的一种行为。为了提高检测准确率，防御方需要收集丰富的数据，比如可以在命令行参数或者系统功能上查找是否存在如下特征：