Operationalising Calendar Alerts: Persistence on macOS

Throughout the following blog post we provide insights into calendar alerts, a method of persisting on macOS. Building on the work of Andy Grant over at NCC (https://research.nccgroup.com/2020/05/05/exploring-macos-calendar-alerts-part-1-attempting-to-execute-code/), this post takes deeper look into weaponising the feature for use in offensive operations. This includes reversing Automator.app to find an undocumented API that enables the technique. We’re also releasing the JavaScript for Automation (JXA) code to perform the persistence along with this article, this can be found here, along with a quick getting started guide. However, please read on further if you’re interested in taking a closer look into how this all comes together.

As detailed by Andy, one of the many features of the macOS inbuilt calendar application, is the ability to execute an application as an alert for an event. This can be configured in the GUI when creating a new event as shown below.

This is discussed by Andy in-depth, including research into code execution and data exfiltration (take a look if you haven’t already, it’s an awesome read). However, the part that caught my eye was regarding persistence. He talks about the issues he encountered with attempting to programmatically insert an event to perform this task using AppleScript, and that the calendar application simply ignored his requests to do so. Another route was to modify the SQLite database that powers the app - this is awesome, and lets you set the default alert for all upcoming events as an added bonus. However, this method proved difficult to operationalise.

Whilst having a play with the technique, I came across Automator.app, Apple’s solution to building drag-and-drop applications that perform repetitive tasks. Included within Automator is a template to build a calendar alarm.

Stepping through the GUI and saving the workflow - results in a new event being added to the calendar, with an alert that executes our workflow as a new application! Alright this is a good step, so it must be possible to do this programmatically.

I started digging into the Apple Developer documentation for EventKit - the framework responsible for interaction with calendar events, but found no mention of the API that would allow me to add the alert that would execute my application. So, I figured it would be worth taking a closer look into Automator to see how it’s achieving this.

I first used Objective See’s FileMonitor and ProcessMonitor to get some insight into what Automator was doing under the hood. It wasn’t modifying the calendar database, nor was it really modifying any other files of interest. So, I then turned to the LLVM debugger, lldb. Pivoting off a few of the EventKit functions, I ended up in the function [AMICalPluginWorkflowPersonality finishSavingWorkflow:forOperation:atURL:error:]. Taking a look at the disassembly of this function shows a series of EventKit functions that look similar to the documentation provided by Apple.

We can see that the disassembly above creates a new event using the EKEvent class, and sets the title, start and end dates. However, one section wasn’t quite as familiar, and contained an interesting function that I couldn’t find any information about on the Apple docs, [EKAlarm procedureAlarmWithBookmark]. Below is a section of the disassembly leading up to this undocumented function.

We can see that Automator creates a new bookmark, which is a data structure that points to a specific file on disk. It then creates a new instance of the EKAlarm class, and calls procedureAlarmWithBookmark on that class, with the bookmark data as an argument. Sweet, this was exactly what we were looking for.

At this point we have all the pieces to action our persistence programmatically. I’ve put this together in JXA so that it can be easily executed using Mythic (formerly Apfell). The scenario I’m going to walk through below results in a new calendar event series being added to a specific calendar. This isn’t the only (or the stealthiest) way of performing this technique, and the included JXA contains the necessary functionality to backdoor existing events or otherwise manipulate the user’s calendars. Check out the GitHub repository to learn more.

Before we do anything, we need to setup Mythic, and get ourselves an Apfell implant. The Mythic docs are great, and you can follow the steps here to get started. Next, we need to import our functionality into Apfell, using the jsimport command.

At this point, our script is loaded into the Apfell implant and we can start calling functions from it. To kick off the technique, we first need to enumerate the user’s calendars. We use the list_calendars function for this. This will prompt the user to grant permissions to the calendar (and sometimes contacts) for the process executing the code.

We’re going to choose the Automator calendar, and we note down its UID. Next, we use the persist_calalert function included in the JXA to create the new events. The function call looks like this;

The process will now create the new events and insert them into the calendar. The “Delay in seconds” argument specifies how far into the future the first event should be, and how often the persistence fires is governed by the frequency, interval and number of events parameters. In this case, we will create a new event every day for 3 days, that when triggered, will launch our malicious application.

Kicking this off in Apfell, and we see the following result in the calendar. When each event starts, the first being at 18:53 09/10/2020, for 3 days, the specified app will execute. In our case we’re executing an Apfell payload as an application, and all the specified times, we receive the connect back from our shell. Persistence achieved!

Whilst preparing this post, Calum Hall (@_chall) rightly pointed out that I’d failed to consider sandboxing, and that even though the app is executed, it’s not going to be useful unless I’m executing code outside of the Calendar sandbox.

To my complete surprise, it turns out that we don’t need to worry about escaping the sandbox, since we were never in it in the first place. Whilst Calendar is a sandboxed process, it seems that the applications executed via alerts are not. In the screenshot above, we can see that our executed appication, CalendarAlarmSandboxTest, does not sit within a sandbox.

Detection of this technique will largely depend on your environment, the telemetry which you have available and the exact way the technique is implemented or executed. 

Calendar alerts are a neat trick to gain persistence on macOS devices, go have a play with the CalendarPersist.js JXA and Mythic/Apfell. Finding undocumented APIs is a good time, and there is loads more to discover in this area. Any questions, shoot them over to me on Twitter @rookuu_.