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:
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.).
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:
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.
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.
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".
We can apply the three key factors outlined previously to determine the effectiveness of flat PKG installers as a potential delivery mechanism:
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.