macOS-ir: Prototype Tool To Help With Incident Response - Part 1

Over summer last year, I picked up a fantastic book from Jaron Bradley, OS X Incident Response: Scripting and Analysis, which covers the development of an incident response (ir) tool for macOS. Originally I was thinking about developing something to reverse engineer iOS apps, but in all honesty I’m not the best at RE so…¯\_(ツ)_/¯

So macOS-ir is a very prototype tool to collect data from a compromised macOS device and analyse it. It’s written in bash and requires no tools to be installed to collect the information 1.

Once the data has been collected, it can be transferred using one of the following methods:

  • Save directly to USB drive
  • Save to a local disk image
  • Transfer over network using netcat

Of course, the data is encrypted (using OpenSSL) so if the USB is lost, for example, then any sensitive data that is collected, well nobody is getting it.

The analysis script is designed to install any required tools. This prompts to install Xcode tools and installs Homebrew along with required tools using an included Brewfile2.

And bam. Give it the name of the USB drive, path to the .dmg on the disk image or start listening with netcat and it’ll start doing it’s stuff. The analysis isn’t (at this stage) designed to say “Hey, this is malicious” or “You know you have this malware installed” but it aims to summarise data and look for items that aren’t as they should be and highlight them.

The output of this tool is a range of PDF files. A main PDF file (stored in \tmp\[Compromised device hostname]\[hostname].pdf) contains the summary of the data. Within the same folder a series of other secondary PDF files are generated which contain the rest of the data. For example, .apps that are unsigned are shown in the main PDF, but all the others are contained in a secondary. It normally goes, if the data is too large or can’t be narrowed down, it’s in a secondary PDF.

And that is that. A very brief overview of macOS-ir (I’m trying to think of a shorter name, but I’m stuck). I’m thinking about writing more, breaking down the collection and analysis stages further. Maybe smaller posts including interesting things that I came across, maybe break it down function by function. I don’t know. But hey, this is a start.

  1. Although it does benefit if XCode tools is installed. Notarization of .apps can be checked. 

  2. Tools can be installed without any analysis with the -i flag.