Introducing Mystikal

Addressing the pain of macOS initial access payloads

Introduction

A common pain point in offensive macOS operations is initial access. Those who have gone through this process are familiar with how easy it is to make mistakes that block execution. Additionally, it isn’t easy to analyze these methods without looking at past malware samples/reports from a defensive perspective. To address these pain points, I’ve developed Mystikal.

This post serves as a usage guide for Mystikal, an overview of a few initial access payloads, and discusses the artifacts left behind these initial access methods for detections.

Mystikal

Mystikal is a macOS payload generator integrated with Mythic. Mystikal leverages Mythic scripting to log in and creates the necessary payload for the selected initial access method. Mystikal creates an Apfell or Leviathan payload depending on the chosen initial access method. As development continues, I plan to add additional initial access methods.

The remainder of this post goes through a few usage examples as well as the related detections.

Installer Packages w/ JavaScript Functionality

Background

A common payload used for initial access is the installer package. These packages are eXtensible ARchiver (XAR) archives that conform to a specific folder structure and have a .pkg file extension. The easy comparison to Windows would be Windows installers which typically have the .msi file extension. As with Windows installers, installer packages execution typically results in an install wizard presented to the end-user for installation.

Installer Package (.pkg) Example

For offensive use, typical installer package execution relies upon preinstall and postinstall scripts, which are simple bash scripts that execute during the installation process. An alternative method depends upon the abuse of JavaScript within distribution Extensible Markup Language (XML) files using InstallerJS. Apple’s InstallerJS is an Application Programming Interface (API) leveraged in distribution XML files to perform installation checks.

Within the InstallerJS API is the system.run tag, which can execute system commands. The Silver Sparrow malware recently used this method. By abusing the distribution XML file, attackers can perform the same tasks typically within preinstall / postinstall scripts. The benefit of this method is that it makes it slightly harder to see what actions the installer package is performing. Additionally, due to the invocation time of the distribution XML file, the installer package does not need to finish the installation process for execution to occur.

Usage

For Mystikal payload creation, you first must update the MythicSettings.py file found at Settings/MythicSettings.py to match your Mythic server.

Then to create this payload, you select option 1 for Installer Packages.

Main Menu for Mystikal

Note: This post does not cover all of the methods shown above. For more information regarding Mobile Configuration Profiles in which the Leviathan payloads come into play, I highly recommend reviewing Xorrior’s blog. For coverage of Malicious Disk Images, I recommend Patrick Wardle’s blog.

Next, from the submenu, select option 4 for Installer Package with JavaScript Functionality.

Selected Option 4 for Installer Package w/ Distribution XML

Lastly, select from the submenu option 1 for execution embedded in the distribution XML file.

Selected Option 1 to Place Execution within Distribution XML File

Mystikal will go through the build process by first creating the Apfell payload. This Apfell payload is made based on the information within the Settings/MythicSettings.py file (callback host information) and the Modules/Installer_JS.py file (selected payload commands). Next, Mystikal modifies the template distribution XML file and saves the installer package as JSPackage.pkg by default.

Output Message for Payload Option

Execution

Depending on the method used to get the payload onto the target machine (e.g., browser download, email attachment, etc.), you will probably be subject to Gatekeeper. For a detailed look at Gatekeeper, I highly recommend Howard Oakley’s blog on the topic. As a quick overview, Gatekeeper is Apple’s mechanism to prevent untrusted code from running on macOS devices. Due to that, the target will probably see the following prompt when double-clicking the application.

Double Clicking the Installer Package, Downloaded through Chrome

This prompt does not give us the option the execute the application. Legitimate applications occasionally run into this as well. So as with legitimate applications, an attacker can remedy this with a pretext stating how to open the application. For example, simply right-clicking (or Control-click if you have an Apple Magic Mouse) and opening the application results in the following prompt, which gives us the option to run the package.

Right Clicking the Installer Package Downloaded through Chrome

Note: An attacker could go down the route of getting the package signed and notarized to minimize these prompts, but that comes with the risk of burning your Apple developer program certificates. Obtaining these certificates involves a long authorization process that costs $99/yr.

Before discussing artifacts, it’s worth noting an additional prompt generated on Big Sur. It appears checks are performed on the application to determine if preinstall actions are attached to the installer package.

The following message gets displayed when either install scripts or distribution XML files are attached to an installer package to give end-users another pause before execution. This message did not occur on my Catalina Virtual Machine.

A Message Indicating Preinstall Actions within the Package

Detection

Crescendo, a real-time event viewer for macOS, leverages Apple’s Endpoint Security Framework (ESF) and helps capture process and file events. Using Crescendo, I could easily trace the execution of the bash command within the distribution.xml file. The installer process spawned the child of bash, which resulted in the other processes involved in the payload. In this case, those were curl & osascript.

Bash Execution Pulling Down and Running Apfell payload

As you can see, the bash PID 4133 has the parent of installer PID 4131.

TrueTree displays the process tree for currently running processes. Using TrueTree, I could trace the running process of osascript that had the parent process of the installer application.

TrueTree Excerpt Showing Running Apfell PayloadApfell Agent in Mythic Running in the osascript PID 4135

A popular tool to inspect installer packages before execution is SuspiciousPackage. Although it is excellent for identifying install scripts, it has difficulty with distribution XML files. However, since these files are XAR archives, you can use xar -xvf JSPackage.pkg to expand the file. You can also use pkgutil --expand JSPackage.pkg save/to/path to view the contents of the package. There is an installation log at /var/log/install.log, but the entries there will not indicate information regarding the distribution XML file.

Microsoft Office Macros

Background

Execution through Microsoft Office documents (Word, PowerPoint, Excel) is an established and popular execution method. The folks at F-Secure recently held a great webinar breaking down execution and detection of the traditional form of macros on macOS. Patrick Wardle has a great blog that also covers this method. An interesting item within the blog was covering Stan Hegt’s research which uses the old file format SYmbolic LinK (.slk) and the old macro programming language Excel 4.0 Macro (XLM), the predecessor to Visual Basic for Applications (VBA). Using this method, we can get the same execution as the traditional method but use the .slk or .csv file extensions.

Usage

To create this payload, you select option 5.

Selected Option 5 for XLM Macros in SYLK Files

The contents of the macro.slk file is a simple XLM macro based on Patrick’s example, which invokes curl and osascript to pull down and execute an Apfell payload from our Mythic server.

Contents of the macro.slk File

Execution

As expected, double-clicking the file results in a warning prompt:

Prompt when Double-Clicking the Excel File

As stated previously, you could also use .csv file extension, but this results in an additional prompt shown below.

Additional Warning Prompt for .csv

Detection

Using TrueTree, we can trace that the running osascript process PID 12982 is spawned from the Microsoft Excel process PID 12958, which is abnormal behavior.

TrueTree Excerpt Showing Running Apfell PayloadApfell Agent in Mythic Running in the osascript PID 12982

Using Crescendo, we can capture the contents of the bash execution, which was kicked off by Microsoft Excel PID 12958

Bash Execution Pulling Down and Running Apfell Payload

Armed PDFs

Background

While looking into initial access payload options, I came across a blog from tokyoneon about creating a fake PDF trojan with AppleScript. This method creates an application that appears to be a typical Portable Document Format (PDF) file by downloading and opening a legitimate PDF and executes our Apfell payload to hide our true intent from the end-user

Usage

To create this payload, select option 7.

Selected Option 7 for Armed PDFs

Mystikal builds the application with a ..app in the filename in a simple effort to hide the actual file extension.

Output Message for Payload Option

Execution

Again depending on the method used to get the payload onto the target, you will likely be subject to Gatekeeper. The target will likely see the following prompt when double-clicking the fake PDF application.

Double-Clicking the Fake PDF Downloaded through Chrome

Again, an attacker can deliver some instructions to coerce the target to right-click and open the file possibly. If successful, they will be presented the following prompt with the open option.

Right Clicking the Installer Package Downloaded through Chrome

Detection

Using Crescendo, I traced the execution of the command within the fake PDF (application posing as PDF). The application process applet spawned the child of bash resulting in the other processes involved to execute. In this case, those were curl & osascript

Fake PDF Application ExecutingBash Execution Pulls Down Fake PDF, Opens the PDF, Pulls Down, and Runs the Apfell Payload

The above command is cutoff; below is the simple AppleScript file that Mystikal creates and compiles into the fake PDF application.

Contents of AppleScript that Compiles into the Application

This snippet shows that the application pulls down (curl) and opens (Preview.app) the actual PDF we want the target to open. Next, it pulls downs the Apfell payload (curl) and executes it in the background (osascript).

Using TrueTree, I could trace the running process of osascript, which had the parent of the Fake PDF application (Doomfist.pdf..app).

TrueTree Excerpt Showing Running Apfell PayloadApfell Agent in Mythic Running in the osascript PID 633

Conclusion

The purpose of this post was to introduce Mystikal (INSERT LINK) while highlighting some lesser-known initial access methods on macOS and the artifacts they create. The Mystikal project is still in the early stages and in active development. If you have any thoughts on improvements/additions, I am always open to pull requests . I hope this post sheds light on initial access methods for macOS and provides a brief introduction to the artifacts they create to aid detection efforts.

References / Resources:

Introducing Mystikal was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

Article Link: https://posts.specterops.io/introducing-mystikal-4fbd2f7ae520?source=rss----f05f8696e3cc---4