In this blog post, we’ll describe how we developed social engineering payloads for macOS which can be used to bypass Santa’s application whitelisting.

Traditionally, most of Praetorian’s red team engagements have involved corporate networks based on Active Directory. Networks like this tend to use Windows PCs along with some combination of Linux- and Windows-based servers. However, we’ve seen more and more corporate networks with at least some allocation of end user systems running macOS. Even in networks where macOS represents a small percentage of the installed base, macOS systems can be a good place to operate if the IT security staff tend to focus more on their Windows endpoints.

Consequently, we’ve invested a substantial amount of time and effort into the development of red team tools for macOS environments. Since our clients include challenging targets with mature security programs, we develop our red team tools to evade or bypass contemporary security controls. A good example is Santa, an open source macOS application whitelisting project developed by Google.

Since many of our red team engagements begin with social engineering, application whitelisting can pose a significant obstacle. In this blog post, we’ll describe how we developed social engineering payloads for macOS which can be used to bypass Santa’s application whitelisting. In part two, we examine an example flat PKG installer to understand more about how this mechanism actually works.

When the Praetorian Red Team has operated in macOS heavy environments, we have encountered a number of other issues such as: the limited number of execution TTPs compared to Microsoft Windows, Sandboxing of Microsoft Office applications, and Apple’s Gatekeeper.

When researching and developing phishing payloads for red team engagements there are three important factors to consider:

• Ease of Detection: How well does the technique being used blend into normal activity within the target environment? One example of this is the usage of rundll32.exe versus the usage of something like Microsoft.Workflow.Compiler.exe which only had one instance of execution in the last year during a recent threat hunting engagement for a large Fortune 500 company. It is easy to develop high confidence detections for activities that occur rarely, but difficult to develop detections for binaries that are executed in strange ways even by e.g. SCCM and other software installed on the host.
• Ease of Execution: How easy is it for the user to perform a specific action and how much does it differ from their normal workflow or use of the application? Most people know how to open an office document and it is natural whereas having the user open a terminal and execute commands is not. The other metric we like to use is the number of clicks or dialogs required to execute the payload.
• Pretext/Story: How does the execution technique integrate with the story or pretexts you can use? If you are applying for a position it is natural to send the target a resume, but sending them a one-liner to execute is quite strange. However, if you are impersonating the helpdesk and need them to update a “VPN Certificate” in order to avoid losing access to the network it is more natural to read them a one-liner to execute over the phone or have them execute remote “support” software. If you want to talk to someone on a video conferencing solution (e.g. a sales person) it is common for them to have to install or update web conferencing software.

When developing payload generators for red teams it is often useful to decouple the initial execution TTP being used from the second-stage or loader being used. Decomposing these two factors is useful since it allows for the development of more flexible plugin-based architectures for payload generators. This allows for an operator to have a high degree of control over how a given payload works and allows for payloads to easily be reconfigured to bypass a specific EDR solution/detection.

For example, a VBA macro can be used for an initial execution mechanism, but there are a number of second stage TTPs that can be used to load the malware (e.g. regasm, regsvr32, regsvcs, etc.) as well as different methods which can be used to execute the second stage such as scheduled tasks, wmi, out-of-process COM servers such as ShellWindow, etc.).

What are flat package installers?

Flat package installers are one delivery mechanism that we have used as an initial execution mechanism/delivery mechanism in environments where application whitelisting is in place.

MacOS flat packages have the extension of “.pkg” and the user executes the package by double clicking on the file. When the package is executed it is parsed by the Installer.app application which is signed by Apple. Since application whitelisting solutions, such as Santa, rely on monitoring the execution of applications through things such as execve they do not provide a means for whitelisting pkg files since Installer.app is a whitelisted application.

There does not appear to be a formal specification for flat package files and most of the information obtained online has been obtained through reverse engineering of the format. Flat package files are XAR (eXtensible ARchive format) archives containing the following components:

Distribution: File specifies installation checks which should be performed as well as the individual application bundles or packages which should be installed.

Package Directories (e.g. sample.example.pkg): Contains information on a package to be installed. The package directory contains:

• Bill of Materials (BOM): Used to determine which files to install, remove, or upgrade.
• PackageInfo: An XML document containing information about the package to be installed and other installation parameters.
• Payload: CPIO archive compressed with gzip that contains the files to be installed.
• Scripts: CPIO archive compressed with gzip that contains scripts used by the installer. This includes things such as “preinstall” and “postinstall” installation scripts.

Resources: Contains language pack files and presumably other resources used by the installer.

Because of the lack of documentation on flat package installers our primary approach has been to download and analyze a variety of installers used by commonly used applications to understand more about the file format and what is possible.

Abusing flat package installers to execute arbitrary scripts

One of the neat features of flat package installers is that they allow you to include arbitrary JavaScript code which is executed as an installation check before the application is installed. This JavaScript code is “privileged” (i.e. does not run in a sandbox), and can execute arbitrary commands or scripts such as a Python interpreter on the target system.

Furthermore, the user does not need to be an administrator to run flat package installers which makes it feasible to utilize the payload in high security environments where users do not have administrative privileges on their workstations.

The installation checks are written using InstallerJS. InstallerJS is JavaScript code which is embedded within the Distribution file in the installer archive. This InstallerJS code runs with the same privileges as the user running the installer and can perform actions such as execute arbitrary commands.

Since flat package (pkg) installers are loaded and executed by Installer.app, which is a whitelisted application, this allows for a bypass of Santa. This InstallerJS code can then be leveraged to execute a second stage payload as detailed in the section “Executing Arbitrary Code”.

Analysis of the delivery technique using three key factors

We can apply the three key factors outlined previously to determine the effectiveness of flat PKG installers as a potential delivery mechanism:

• Ease of Detection (Medium): Legitimate software installers use this method to execute installation scripts and perform installation checks. From our testing, EDR solutions such as Carbon Black will log the activities, however, they will not generate any meaningful alert to IT administrators.
• Ease of Execution (Excellent – Very Easy): It takes three clicks to download and run the application. The first click involves clicking on a link to download the application. The second click is for opening the flat package with Installer.app and the third click is a dialog box to confirm execution of installation scripts. Most macOS users are familiar with installing software using this mechanism.
• Pretext/Story (Web Conferencing): This payload type can be used in a variety of different pretexts or stories. It is common for users to have to install applications such as web conferencing software to join a meeting. Combine this with the appropriate target and the appropriate motivation (e.g. sales people regularly interact with external customers using web conferencing software and their salary is primarily based off of commission). Users are familiar with installing software using this mechanism and have done it before.

Examining a Flat PKG Installer

In our next post, we will examine an example flat PKG installer to understand more about how this mechanism actually works and demonstrate how to technically abuse Google’s Santa application whitelisting. Then we will offer recommendations for ways to mitigate and instrument detection around these vectors.

Read: Bypassing Google’s Santa Application Whitelisting on macOS (Part 2 of 2)