INSIGHTS MacOS Forensics DIY Style

“I have to be really careful about what I install or click, MacOS is not virus-proof” — no MacOS user ever.

After a short conversation, you suspect that it might be a RAT (remote administration tool). Damn, what if other computers in the company are infected as well? You need answers and you need them fast.

The problem is: you have no forensic tools for MacOS, no idea how to take an image or where to collect artifacts (important pieces of information). On top of that, this is actually the first time you’re doing forensics on a Mac device.

If you can imagine yourself in such a situation, welcome to this material. This article is written by someone who is not an expert in forensics for people who are also not experts in forensics, but they would be the first responders to an incident if something was to go wrong. Hopefully, I can save you hours of research when those hours will be critical for you.

Part 1: Introduction.

Before we dig into the forensic analysis process, we need to first understand some key concepts about Mac computers and technologies.

APFS (Apple File System) is a proprietary filesystem developed by Apple and used in many Apple software products, including MacOS. APFS is fully supported in MacOS High Sierra (10.13) and above. It has a limited support in MacOS Sierra (10.12).

FileVault is MacOS full volume encryption solution. FileVault volumes can be decrypted or unlocked with a local administrator’s password or a recovery key which is created when FileVault is originally enabled.

T2 Security Chipset. In newer Macs, Apple added the T2 security chipset as an additional level of protection for the data contained on a Mac device.

Firmware Password. A firmware password prevents your Mac from starting up from any internal or external storage device other than the startup disk you’ve selected.

Target Disk Mode. If you have two Mac computers with FireWire or Thunderbolt ports, you can connect them so that one of them appears as an external hard disk on the other.

MacOS Recovery boot. MacOS Recovery is part of the built-in recovery system of a Mac. You can start up from MacOS Recovery and use its utilities to recover from certain software issues or take other actions on your Mac.

Part 2: Imaging.

In this part I will try to outline ways to obtain an image from a MacOS device for further analysis of files. The bad news is — after a lot of research, trial and error, I was not able to find a 100% effective way to take a forensically sound image of a Mac device without specialised expensive tools. If you, after reading this article can point me to something I did wrong in my steps, you are more than welcome to drop me a message and I will update this section.

First of all, why would you even want to take an image instead of analysing directly on the target device? While it’s much faster to start your analysis on the machine you’re investigating, there are many downsides to that. Let me list just a few of them:

1. Any changes to the target machine can impact the results of the investigation. You can either unintentionally overwrite valuable files, logs, etc. Also, you would probably want to install some tools on the machine to make your analysis easier, which inevitably leads to more changes on the target system.
2. If you are investigating a potential malware infection, you definitely DO NOT want to keep the system running and even more — give it internet connection.
3. MacOS has a retention period for some log files, so the longer you keep the machine running, the higher are the chances that valuable logs will be overwritten.

As you can see, winning a few hours to start your analysis is just not worth it. Some investigations might last a few days, especially when you’re just a beginner. You probably also want to keep a backup of things just in case you make a mistake and have to start over.

So let’s down to business. As I mentioned before, I was not able to find a solution that worked perfectly, but I can definitely list the things I tried and what I ended up doing in the end. There are a few items that can make the imaging process more difficult and you’d have to find your way around them, like: FileVault encryption, firmware password, T2 security chip. To battle these things, I can recommend the following things before you start the imaging process:

1. Find out the firmware password if it was set up. Your IT team should help you with that or the laptop owner.
2. Ask the target laptop admin user’s password. It’s really helpful to be able to log in to the system as a user that you’re trying to analyse. Alternatively, you can create a local admin user on that machine, but this leads to changes on the target system, which you want to avoid.
3. Use the same OS version and MacBook model for analysis as the target machine. I know it’s hard to achieve, but it makes things easier.

When performing my first investigation, I found a great series of articles about MacOS forensics on the website http://www.computerpi.com. One specific guide I can recommend as a starting point is this one, especially if you have a Mac device without a T2 chip. The basic idea of that guide is to boot the target Mac into the target disk mode and take the image with the dd tool. After trying it out, I managed to obtain the image, but I was not able to mount it on my analysis machine, even though all prerequisites were satisfied.

I tried 2 different approaches with the dd tool:

1. Boot the target device into Recovery Mode → connect an external drive to the target device → take an image with dd and choose the external drive as the destination.
2. Boot the target device into Target Disk Mode → connect it to the analysis Mac → take an image with dd (run from the analysis Mac).

If I remember correctly, the first option produced an image that my analysis machine could not even recognise as an APFS volume. The second method made an image that was recognised as a valid APFS volume, but I did not manage to mount it for analysis. I am not completely sure what was the problem in the end, it could be FileVault or the T2 chip or me not doing it right. In any case, I think you should try these methods out and shoot me a message in case it works :).

Also, when trying it yourself, don’t forget that tools like diskutil and hdiutil on MacOS are more powerful than UI options provided by the Disk Utility.

What worked out in the end?

After battling with dd images for hours, I decided it was time to give up. I connected the target machine to my Mac in the Target Disk Mode and just copied all files over to an external drive.

Why this is not optimal:

1. You can’t carve out deleted files from the file system.
2. You lose a lot of important metadata from files. On my analysis machine, the creation time of all files appeared as the time I copied them. As a result, building a timeline of file changes on the machine is not possible with this method.

But even if this method is not perfect, it’s still better than running analysis directly on the target machine and you can collect many important artifacts.

I also briefly looked into commercial tools available for MacOS imaging and forensic analysis:

1. Sumuri Recon ITR.
2. Macquisition by BlackBag technologies.

I will not share any insights about these tools at the moment, because my evaluation of them is not over yet.

Part 3. Analysis.

The first step of your analysis should be to understand what do you want to achieve with your investigation and to prioritise which artifacts you will look into first. Artifacts you can choose from include, but are not limited to:

1. MacOS logs.
2. Browser history.
3. OS update history.
4. Downloaded files.
5. Installed applications.
6. .plist files.
7. Browser extensions.
8. Startup items.
9. etc.

After you’ve made a list, you should note down some system information: MacOS system and build version, user name, serial number, etc. I highly recommend logging as many of your actions as possible, because it will be very valuable in case another person has to take over the investigation.

Software-related artifacts

As my case was a potential RAT, the first thing I did was to research a little about RATs on MacOS: [1], [2], [3], [4]. As with all kinds of malware, a RAT needs: to be installed, escalate privileges, stay persistent in the system. Based on this information, I decided the order in which I had to analyse different artifacts.

As I was dealing with MacOS Mojave, I first looked into the TCC (Transparency Consent and Control) database, which contains all the settings for privacy controls, including the “allow” lists which are displayed in the Privacy tab of the Security & Privacy pane. The TCC DB can be found in:

1. /Library/Application Support/com.apple.TCC/TCC.db
2. ~/Library/Application Support/com.apple.TCC/TCC.db

Also, I looked into the file that shows whether a user was prompted with a question to allow or deny access to a certain app:

• ~/Library/Preferences/com.apple.universalaccessAuthWarning.plist

Tip: you can read .plist files with plutil -p file.plist.

Next, I looked into installed applications:

• ~/Applications
• /Applications

Things you want to look out here for are: irregularities, applications with weird names or apps that pretend to be legitimate apps, etc.

Persistence artifacts

thanks Pham Duy Phuc for help

As any malware wants to stay persistent, I started looking into persistency containers on MacOS. At the moment of writing, I am able to list the following ones.

Persistence through cron:

• /etc/crontab
• /usr/lib/cron/tabs
• /private/etc/crontab

Persistence through launchd:

• $HOME/Library/LaunchAgents
• /Library/LaunchDaemons
• /Library/LaunchAgents
• /System/Library/LaunchDaemons
• /System/Library/LaunchAgents
• /Library/StartupItems
• /Library/Preferences/com.apple.loginwindow.plist
• /Library/Preferences/loginwindow.plist
• /Library/Preferences/ByHost
• /Library/PrivilegedHelperTools

Persistence through Unix startup stuff:

• /etc/rc.*
• /etc/profile
• .bashrc
• .profile
• .login
• /etc/lauchd.conf

Kernel extensions:

• /System/Library/Extensions
• /Library/Extensions

Browser artifacts

After checking the persistence containers, I would recommend looking into browser artifacts, mainly: browsing history, extensions and downloads. Malicious web sites are quite a common way to spread malware, so going through user’s web history can bring good results.

1. Google Chrome

The data you are interested in is located under the following folder:

• ~/Library/Application\ Support/Google/Chrome/Default
• ~/Library/Application\ Support/Google/Chrome/Profile N , where N is a number

Most of the interesting and valuable files are saved as SQLite 3 databases. There are dozens of tools that can help you read these. I personally used Liya, which offers a nice UI and is available in AppStore.

It is true that a user can install malware trough Chrome extensions, so it is absolutely worth it to look into them. All extensions are located in the Extensions folder of the Chrome base directory mentioned above. When you cd into this folder, you will see something like this:

Every folder name is a unique ID assigned to an extension. You can grab that ID and inspect the extension in the Google Chrome store:

• https://chrome.google.com/webstore/detail/

To save you some time, I can recommend checking out this web page, which lists all default / trustworthy extension IDs.

2. Safari

Relevant Safari files can be found in the directory below:

• /Users//Library/Safari

Email artifacts

If a user was using Apple Mail, you can find all emails and attachments under these folders:

• /Library/Mail
• ~/Library/Mail

General file-related artifacts

After looking into browser-related stuff, you probably want to look into general user files on the system: downloads, personal files, etc. These can be found all over the home directory of a user. What you probably want to do, is to run all the files through an anti-virus. Then, I can totally recommend uploading them to VirusTotal.

After that you can do some other things. For instance, after observing a whole bunch of semi-successful phishing attacks I noticed two most common malware delivery methods:

1. Encrypted archives in email attachments, which cannot be scanned for malware by your email provider.
2. MS Word files with macros.

So what you can do is to try to find all encrypted archives and files with MS macros on the target system and take a closer look at them. I wrote 2 small scripts for this purpose. They are not perfect, but a good starting point for you.

How to find all encrypted archives:

#!/bin/bash

root_dir="/path/to/folder"

find $root_dir -name "*.zip" | while read x

do

    echo $x

    7z l -slt "$x" | grep "Encrypted"

done

Find files with macros:

1. Run the script below:

#!/bin/bash

root_dir="/path/to/folder"

i=0

find $root_dir -name "*.xls*" | while read x

do

    echo $x

    unzip "$x" -d "out_dir/dir_$i"

    ((i++))

done

2. Then run find out_dir -name "vbaProject.bin"

3. You can then extract the macro with sigtool --vba vbaProject.bin, which comes with clamAV (brew install clamav). Also check this article for practical advice on analysing malicious macros.

Miscellaneous artifacts

Mac OS logs:

• /Users/username/Library/Logs/
• /private/var/log/

Part 4. Conclusion

As you have seen through this article, performing forensic investigations on MacOS is not easy if you have limited time and budget. Compared to Windows, there are almost no free-to-use tools for imaging and analysis, but it’s not because the open-source community is lazy. Every year Apple changes something in MacOS that might or does break the workflow of tools, so it’s really hard for the community to keep up with this pace of changes without financial support.

Also, at the moment MacOS is still not that popular as a target among malware developers. But the market share of Apple computers is growing, and so will the number of malware samples. Hopefully, by the time this happens, the security community of the world will be ready to face the challenge.

As always, I hope you learned something new and enjoyed the reading. If you would like to add something or noticed a mistake, I’m always open for a discussion. This article is not and will never be monetised, so you can be sure that by making a suggestion you are giving back to the community.

Yours truly,

Vladyslav Cherednychenko