AppleScript

Gaining execution on macOS can be noisy. When binaries are dropped to disk, there is ample opportunity for defenders to respond, be it via traditional static-based detection or more modern process-centric behaviors. It’s for this reason that adversaries tend towards a “Living off the Orchard” (LOOBin) approach, which assumes the host has only factory software installed. Native Open Scripting Architecture (OSA) languages like AppleScript offer immensely powerful system automation and Objective-C bridging functionality that enables execution, defense evasion, and more. In fact, the prevalence of adversaries abusing OSA was pressing enough that it prompted us to chat about it for an entire hour with our friends from Jamf and MITRE.

How do adversaries leverage AppleScript?

AppleScript, like any other scripting language, offers capabilities like variables, control flow, commands, and more. However, where it and other OSA-based languages really shine is in the ability to automate the system and call native APIs. This is why adversaries are drawn to the language, along with the defense evasion properties associated with in-memory execution and run-only scripts. We’ve seen adoption across malware families ranging from adware to remote access trojans (RAT).

Adversaries have several distinct variations to enable AppleScript execution, each with their own distinct characteristics:

• Use of the osascript binary or shell scripts: This is by far the most common example and the easiest to detect. This variation is simply the user executing AppleScript in-line or through a file or inter process communication (IPC) at the command line via the /usr/bin/osascript LOOBin.
• The NSAppleScript/NSUserAppleScriptTask APIs and OSAKit framework: The programmatic execution of AppleScript code, which occur in more advanced use cases largely for defense evasion from an agent payload.
• Applets: These are becoming a more frequent alternative to traditional Objective-C, Swift, Go, and other compiled payloads. Simply put, applets are “compiled” OSA code, a thin Mach-O wrapper, and an application bundle structure. For an in-depth look at applets themselves, read our blog on Application Bundle Manipulation, which explores their use by the authors of XCSSET malware.

Next, we’ll go through some examples of adversaries leveraging each of these variations.

Variation 1: osascript

This first variation is characterized by executing AppleScript code in-line or from a file or IPC via the /usr/bin/osascript LOOBin. It typically happens early in the attack for staging or persisting resources. Importantly, adversarial use of AppleScript here is relatively easy to detect.

In the most simple case, if an adversary needs to grab the user’s login password, for example, they might do something similar to MacStealer’s implementation. Here they leverage osascript to execute AppleScript code in-line, generating a basic dialog box.

Or in the case of Pirrit adware, the adversary leverages AppleScript to manipulate (restart in this case) Firefox, Chrome, or Safari for their changes to take effect.

Later on in its intrusion cycle, Pirrit leverages AppleScript to inject JavaScript into the user’s browser (here you can see Safari and Chrome samples doing this). This will be executed via /usr/bin/osascript in script form as well.

Furthermore, OSX.DarthMiner (a RAT) leverages AppleScript to download and install EmPyre, persist as a Launch Agent, install XMRig, and install a man-in-the-middle (MitM) certificate.

The flexibility and power offered by AppleScript has also extended to red teamers with the Apfell and Poseidon Mythic agents (just to name a couple). For example, Apfell’s entire implementation is in JavaScript for Automation (JXA)—another OSA language and sister language to AppleScript—which we also discussed at length in our webinar.

Variation 2: NSAppleScript and OSAKit

Here we’re referring to the programmatic execution of AppleScript via the NSAppleScript/NSUserAppleScriptTask API and OSAKit framework. The functions you’ll largely be concerned with include:

NSAppleScript

• executeAndReturnError

• executeAppleEvent

OSAKit

• executeAndReturnError
• executeAppleEvent

NSUserAppleScriptTask

• execute(withAppleEvent:completionHandler:)

In 2017, the Snake trojan abused AppleScript’s ability to execute code as the root user. By abusing the do shell script’s with administrator privileges parameter, Snake was able to display a generic dialog requesting authentication. In this case, the ./install.sh script will run with root privileges.

Additionally, Patrick Wardle pointed out that the authors of OSX/Dok progressed things a bit further by persisting via a login item. AppleScript’s simplicity and power shines through here yet again, showcasing essentially in one line how to persist using Apple’s latest BTM (Background Task Management) service.

The Poseidon Mythic Agent (written in Go) also has the ability to execute OSA code (albeit JXA) via OSAKit’s executeAndReturnError function.

Variation 3: Applets

Applets, for all intents and purposes, are “apps.” Simply put, they’re “compiled” OSA code, a thin Mach-O wrapper, and an application bundle structure. This makes them an ideal candidate in which to conceal malicious code. We’ve explored this variation in-depth with our research on application bundle manipulation. However, the key point to understand is demonstrated by XCSSET’s procedures.

In the following example, you can see that the authors compile a “run only” applet with osacompile -x. Compiling an applet in this way, as “run only,” is a form of obfuscation that helps to evade static analysis. We’ll point the reader to the aevt_decompile tool developed by SentinelOne’s Phil Stokes if you happen to come across any examples.

The RustBucket malware discovered by Jamf Threat Labs (and thought to be connected to the BlueNoroff threat actor) was distributed as an unsigned applet named Internal PDF Viewer.app. This technique, masquerading as a PDF viewer, can trick the user into executing the malware and unwittingly compromising their machine.

A list of in-the-wild examples of malware abusing AppleScript

Visibility

Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.

Process monitoring

When looking to gain visibility into the adversarial use of AppleScript, Endpoint security will be your best friend. In particular, a lot of insight can be gained from enriched EXEC (process execution) event telemetry alone: ES_EVENT_TYPE_NOTIFY_EXEC / ES_EVENT_TYPE_AUTH_EXEC.

Module monitoring

However, in more advanced cases visibility into MMAP (memory mapping) events will provide the highest resolution: ES_EVENT_TYPE_AUTH_MMAP / ES_EVENT_TYPE_NOTIFY_MMAP.