SANS Digital Forensics and Incident Response Blog

Mac OS Forensics How-To: Simple RAM Acquisition and Analysis with Mac Memory Reader (Part 2)

In Part 1 of this post, I showed you how to acquire the contents of physical RAM of a Mac OS X computer using ATC-NY's Mac Memory Reader, and did some simple analysis using strings and grep searches. Today I'll provide a few more examples of what evidence can be found in a Mac OS X memory dump and how to extract it using file carving techniques.

Using a Hex Editor I could also find the output of some of the commands I had previously run on a terminal before acquiring the contents of my Mac's RAM:

Figure 1 — Output of Netstat

Output of netstat

In order to see what kind of evidence is left in memory, I decided to have a play with HellRaiser, a basic Trojan horse that gives control of a Mac OS X system to an attacker, allowing to transfer files to and from the infected computer, pop up chat messages on the infected system, display pictures, speak messages, and even remotely restart or shut down the infected machine. By default, the server component of the Trojan horse listens for incoming connections on port 24745.

A further search using 0xED revealed the username and password that I chose to control the infected Mac:

Figure 2 — Username (HellRaiser) and Master Password (helenapasswd) used to control HellRaiser

Username and passwordUsername and password

Plist extraction with Foremost

Basically you can say that Property Lists are to Mac OS what the Registry is to Windows. Plist files store system, user and application settings in ASCII (rarely used these days), XML and Binary (default since Mac OS X 10.4) format and there are thousands of those in a typical Mac OS installation scattered all over the disk. Some of the information that can be extracted by analyzing these files include applications that are run at startup, recent accessed items, preferred network connections, recent contacted hosts, mounted devices, Internet history, etc.

In my analysis I tried to focus on the following files:

/Users/<username>/Library/Preferences/com.apple.recentitems.plist (binary)

/Users/<username>/Library/Preferences/com.apple.loginitems.plist (binary)

/Library/Preferences/com.apple.loginitems.plist (binary)

/Library/Preferences/SystemConfiguration/com.apple.airport.preferences.plist (XML)

/Library/Preferences/SystemConfiguration/com.apple.network.identification.plist (XML)

/Users/<username>/Library/Safari/History.plist (binary)

/Users/<username>/Library/Preferences/com.apple.iPod.plist (binary)

/Users/<username>/Library/Preferences/com.apple.finder.plist (binary)

In order to recover and analyze their content I used Foremost to carve them from the memory dump, using the following signatures:

plist y 4096

#XML header

\x3C\x3F\x78\x6D\x6C\x20\x76\x65\x72\x73\x69\x6F\x6E\x3D\x22\x31\x2E\x30\x22\x20\x65\x6E\x63\x6F\x64\x69\x6E\x67\x3D\x22\x55\x54\x46\x2D\x38\x22\x3F\x3E\x0A\x3C\x21\x44\x4F\x43\x54\x59\x50\x45\x20\x70\x6C\x69\x73\x74

#XML footer

\x3C\x2F\x70\x6C\x69\x73\x74\x3E

plist y 4096 \x62\x70\x6C\x69\x73\x74\x30\x30 #Binary header

I quickly realized that while it was easy to define a header and a footer for the XML files by just looking at the XML tags, it wasn't trivial to define a footer for the binary version (the header here corresponds to the "magic number" bplist00), as their length is variable according to Apple's specifications. That means that you'll have to choose how many bytes to carve out once the header is found. In this case I've used 4 KB, which should be enough.

Next I run Foremost against my memory image using the signatures shown above plus some other htm and pdf ones:

($) foremost -c foremost.conf -i memory.img -o plist_output -v

...

23444 FILES EXTRACTED

htm:= 257

pdf:= 144

plist:= 10237

plist:= 12806

As you can see Foremost carved a large number of files, and in this case, most of them related to Safari browsing history. Something you have to bear in mind is that while the XML/Text format can be read by any standard text utility or xml viewer, the binary version requires that you either open the file with a specialized viewer (I used PlistEdit Pro) or convert the binary file into XML output.

To analyze if my system was connected to a particular wireless network I run a search for the keyword 'KnownNetworks' in Foremost's output directory (note that I've limited the search to a manageable number of files using a wildcard, in this case files starting with '02'):

($) find 02* -exec grep -H "KnownNetworks" '{}' \; -print

02711320.plist: <key>KnownNetworks</key>

02711320.plist

The contents of this file are shown in the following Figure.

Figure 3 — Viewing the contents of a Plist file recovered from a physical memory dump with PlistEdit Pro.

PListEdit ProPListEdit Pro

We can see that the Mac was connected to SSID "Apple Network bff904" (which is the default SSID on most Apple Airport Extreme or Express routers where bff904 correspond to the last 6 digits of the router's MAC address) on July 26 2010 at 08:57 GMT. It was also running open with no security.

Undoubtedly you will find some duplicates and false-positives in Foremost's results, however an in-depth investigation of these files will result in more potential evidence being found.

Kudos to ATC-NY and hope this is just the start to a lot more research and new tool releases in the Mac Memory analysis field.

Ah, and don't forget to register for the new 6-day class FOR408 - Computer Forensic Investigations - Windows In-Depth running next month at Barcelona!

Additional Reading

Ismael Valenzuela (CISSP, CISM, GCFA, GCIA, GPEN, GWAPT, GCWN, 27001 Lead Auditor & ITIL Certified) is a Community SANS Instructor and Global IT Security Manager for iSOFT Group Ltd., one of the world's largest providers of healthcare IT solutions. Since he founded one of the first IT Security consultancies in Spain, Ismael Valenzuela has participated as a security professional in numerous international projects across EMEA, India and Australia in the last 10 years. Ismael has also authored several articles that are freely available at http://blog.ismaelvalenzuela.com / Mr. Valenzuela can be followed on twitter at @aboutsecurity

1 Comments

Posted February 5, 2011 at 8:41 PM | Permalink | Reply

Magnus Trouw

Was waiting for part 2. Nice details on getting actual info out of RAM.