The trend for malware that targets Mac OSX has been steadily growing over the past couple years. Although the number of malware variants have grown, the initial infection vector seems to remain the same. Malware is usually distributed inside or outside of the App store, or through phishing. When malicious and unsigned applications are downloaded from the internet, they are promptly given the quarantine flag by gatekeeper. When the user attempts to open any executable with the quarantine flag set, depending on the GateKeeper setting, the executable will be allowed to run or blocked. However, this setting can be modified by navigating to Settings -> Security & Privacy. They will see a prompt that allows them to run the executable as seen below:
UPDATE: In the newest version of OSX (10.12-Sierra) the option to allow files downloaded from “Anywhere” to execute has been removed. However, apps from “identified developers” (i.e. anyone with an Apple developer ID) and from the app store are still permitted by default.
When phishing, you should provide some solid pretext to entice the user to execute your payload. GateKeeper is a major deterrent for malicious applications delivered outside of the app store. However, the human element will always play a significant role in getting initial access to a target environment via phishing.
There are a few legitimate (and illegitimate) OSX file-types that serve as excellent payloads for phishing. One of them being package installers. Pkg files are OSX installation packages that can be used to deploy new applications or updates. An excellent overview of the package directory structure can be seen here. Of the three package file structures, a flat package with install files is best format to serve our malicious purpose. The contents of a PKG installer consists of the Payload, Scripts, Bom (Bill-Of-Materials), and PkgInfo file. The payload file is a cpio compressed file consisting of the files/application you wish to copy to the file system. The scripts file is also a cpio compressed file comprised of either a pre-install or post-install bash script. Pre-install scripts are executed at the start of the installation process. While post-install scripts are executed at the end of the installation process. The Bom file details the contents of the package. To weaponize this, we would ideally want to use an Empire application bundle as the payload and have the post-install script execute the application. However, we can mix it up by storing the Empire launcher in the post-install script and use the application as a decoy. There is a great guide available here for creating a package installers for OSX on Linux. This entire process is now automated in Empire! Let’s briefly review the stager options:
The noteworthy options are the AppName and AppIcon. The AppName will be the name of the application bundle that will be copied to the Applications directory. The main function of the application does not contain any actual code and will not run if the user attempts to open it. The AppIcon option will set the icon for the decoy application. This is not necessary but may help to make the application look more legitimate.
Here is a short video showing execution of the malicious package installer:
Another interesting payload is a jar file. You’re probably familiar with jar files already, but I’ll provide a brief description. Jar files or Java Archives contain java class files and any required resources, libraries, or dependencies. This allows for easy transport/distribution of java applications. The Empire jar file consists of a single java class. Upon opening the jar file, a system command to launch Empire will be executed, followed by a message box indicating that the application failed to open.
The caveat to this payload is the Java needs to be installed on the target system and Java is not installed by default on OSX. For more information on creating jar files, please look here.
Lastly, a particularly interesting payload has already been used by a new variant of OSX malware. The OSX.Keydnap malware delivers its main executable through the use of a simple macho binary. Additional details about this malware can be found here. What’s interesting is how Keydnap masquerades this binary as a harmless word document, text, or image file. The filename includes a space at the end so that the file extension is ignored by the operating system and the application will open in terminal by default. This could prove as an effective technique to fool victims into running the payload. It’s difficult to spot the whitespace at the end of the filename unless you look closely. Let's explore how this payload is created.
We can start with a simple empire bash script. We can rename the bash script to “launcher.docx ”. Note that we included a space at the end so OSX will ignore the extension and open the file in terminal.
Now the essence of this payload involves changing the files’ icon. This can be done by creating an icon in a resource fork. Resource forks define additional attributes for a file. For additional information on resource forks, please review information posted here. There are few python scripts available to accomplish this programmatically. The best solution I’ve found so far is referenced in this blog post. The python script takes an icns or png image and a file as arguments. Once the icon is set, the payload is ready and looks legitimate. There is one last hurdle to climb over when using this payload for phishing. The resource fork is not kept when attaching our file to an email. Mail clients like Outlook will actually pull the resource fork out and create a second attachment. The best way I’ve found to preserve the resource fork is to package it up in a zip file. Please note that the application used to extract the zip file plays a role as well. Archiving applications like “Keka”, will not preserve the resource fork when extracting the file, but OSX’s built in Archive Utility will. Here is a short clip demonstrating what happens when this payload is executed.