Recently we were involved in an engagement where we expected to see a large number of Macs in the target environment. As an element of the engagement we decided to investigate options for delivery of malware to these devices. The following outlines one of the methods we were able to explore and use.
Note: This is not a new technique by any means. It is an adaptation of the method that Carlos Perez describes at:
Unfortunately, it appears that Apple dropped support for Package Maker in recent versions of XCode and it can no longer be installed as an add-on to the XCode environment. After doing some research I stumbled across the following blog post describing development of payload free packages using the OSX pkgbuild utilities.
The valuable element of this post is that we can create a shell script called postinstall without requiring a package payload and generate a “pkg” file which will run a wizard style installer executing our script at the end.
Armed with this knowledge, it immediately occurred to us that EmPyre would be the perfect tool to generate the contents of our postinstall script. Selection and generation of the EmPyre “bash” stager module outputs a bash script that includes a base64 encoded stager which executes and deletes itself as seen below.
The shell script output by EmPyre is then copied into a file called postinstall and marked as executable. This file is then placed inside our package folder (it can be named anything) within the scripts directory. In the example below, we simply created a folder called Malware_Package which contained the scripts directory. Within that directory you can see our postinstall shell script.
At this point we could create our package which would launch our payload on the target computer. However, running an installer, driving through the wizard, and not having the expected software installed may appear suspicious to an end user. To fix this, we can modify our payload script to include a couple of useful popup messages that might deter targeted users from investigating any further. The following modified shell script will output such a popup message.
With the calls to “osascript” at the end of our shell script, the popup message will appear after our malicious payload has executed.
After completing these simple tasks, we are prepared to build our final package for delivery. We can accomplish this using the pkgbuild utility as seen below. The interesting elements of the command invocation are the –nopayload and –scripts folder arguments. The final product is the “pkg” file which can be delivered to the target.
The wizard installer that we just created executes as seen below:
Launch the introduction to the wizard…
Select the location to install the package…
The application then prompts for permission to install. The user supplies root level credentials to continue the install process (and execute our agent as root).
One of our popup messages indicating that the package will communicate with the internet (our agent in reality).
Oh, no…an error…
Ahh…the installation was successful…
Back at our C2 server we see the following…
This is just the tip of the iceberg. With a full blown installer environment we can make installer packages that look extremely realistic and mimic the behaviors of their legitimate cousins. Yet another reason to train users with the ability to install software to check signatures and only execute software from truly legitimate sources.
With the majority of mail filters and proxies focusing on Windows and office automation infection vectors, would a malicious “pkg” file make it into your environment?