Digital forensic analyst Sarah Edwards presents an extensive review of tools and approaches applicable for reverse engineering Mac malware at B Sides event
Hi! A real quick introduction first: I’m Sarah Edwards; I’m a senior digital forensic analyst with a government contractor. I work in the Northern Virginia area, D.C., doing computer intrusions research, a little bit of malware analysis, counter terrorism, counter intelligence – secret-squirrel gov stuff.
I’m embedded fulltime with federal law enforcement; general forensics nerd; definitely a Mac fan girl, more than most people should ever like Macs. I’ll also be author and instructor for the new SANS class, SANS FOR518, it’s all about Mac forensic analysis. We’re just getting started with that in April and I’m super-excited to be teaching it. If you like the class down here, I would love to come back during really good weather time.
A little bit about the scope and agenda for this presentation. This is not a hardcore reversing class. This is purely a basic Mac malware reverse engineering class, so we are going to do basics. There are going to be no screenshots of assembly, I promise you this. That would be a whole other presentation for something else to deal with, because I don’t want to look at it and I’m sure a lot of you do not want to look at it either. So it’s about 20% static, 80% dynamic, and I’ve got a little bit of the agenda right there.
So, getting to the static analysis, this is working with the binary itself, with the application, with PKG file – what kind of information can we find out without running the actual executable? I did a whole other presentation “When Macs Get Hacked”, look it up, it’s online. It’s basically all about locating Mac malware, doing intrusion forensic analysis of a Mac intrusion. I know Macs are not supposed to get hacked, but in fact they do. It’s rare but it does happen. Even at work, I work primarily on Windows intrusions; for obvious reasons they get hacked all the time. But I have gotten a couple of Macs in: Macs, iPhones, things like that. So I’m really excited. I just don’t want to get hacked myself.
What kind of malware file are we going to be looking at? The three that we are going to be looking at today are application bundles, PKG files and Mach-O executables. But be aware that there’re also your normal office documents, JAR files, ZIP files, anything else you might see.
So, the application bundle. Who here knows that it’s not just a singular file? It’s actually a directory of files. The application bundle, if you look in Terminal and do either a ‘tree’ command or ‘ls -laR’ command, you can see that there’s a whole tree structure. Up on the screenshots here we got one for Safari.app and one for Dashboard.app. These are obviously not malicious or not malware; these are what normal applications might look like. Two required items, Info.plist – contains a lot of configuration data, bundle name, things like that; and the executable – this might be located anywhere in there. A couple of other directories you might find are Resources, code signing directories – you might see those if you download a Mac application from Mac App Store.
I got an example here, it’s Crisis. Crisis came out maybe two years ago. It makes a really great example. You can tell on the right side here – this just looks bad. You might as well just say ‘Evil.app’. So up here we got Info.plist, which I extracted down here, and using Xcode you can actually do the ‘Plist’, and it’s in a human-readable format. Most of the time we got binary file format, and it’s not very human-friendly. So here we have the executable file name, IZsROY7X.-MP, and most importantly we have a bundle identifier, com.apple.mdworker. A lot of the things in Mac are named in reverse-DNS format, for example com.apple, com.microsoft. com.google, so be aware of that. That basically just tells you the company name and the maker of the software.
PKG files – a lot of these files are going into one called logKext. Has anybody used logKext before? It makes a really great presentation example. You can download it off of Google Code, it’s an open-source keylogger. It runs on Mac wonderful. It makes a really good example. So, a PKG file is eXtensible ARchive, XAR, if you are really interested in it. It’s one of the more obscure archive formats. Flashback used a PKG file actually called “FlashPlayer-11-macos.pkg”, I’m showing the screenshot there. This is supposed to, obviously, look like a Flash Player update that gets the user to click it. It actually asked for credentials, the user puts in the credentials – and they are so owned. Flashback came out a couple of years ago, and this was national news. 600,000 systems were infected, which is nothing compared to Windows malware, nothing. But for Mac malware – holy crap! It was a game changer.
PKG files are kind of a pain in the butt to work with, to extract the actual executable. There are multiple layers of archive we need to get through. On the screenshot here I’m using the XAR tool, which is native to Mac OS X to show the list of contents of the package files. So we have the distribution of Resources, license, Payload, Scripts – these are directories I want to look at. How do we get to those directories? In the next slide I’ll get to that. So, ‘unar’ – have you ever used The Unarchiver? It’s a really great Mac utility, knows just about any archive you may think of, even the most obscure ones. Great utility to have.So, ‘unar’ is the command line version for this tool, so you can script it and it makes it really easy to do some unarchiving.
The unarchiving we need to go through has at least two steps. The first step up here – we can see that it has Bom, PackageInfo, Payload, Scripts directory. These are ‘gzip’, so we have to use ‘unar’ – I like that because it’s one command – or you can use gunzip or whatever other utility you might want to use to extract the first time. When you extract these, you get Cpio archives, so it’s one more layer of archive to extract. Again, I used ‘unar’ because one tool gets the job done and it extracted these at the bottom. You can see ‘Scripts-1’ is the first layer of scripts. ‘-1-1’ – it’s the default unarchiving system.
Just another look at it: first level is a gzip, second level is cpio. On this screenshot you can see that first payload is gzip, second one is cpio archive, and we finally get down to directory. Most importantly, this directory of scripts actually has the Mach-O executable that we’re looking for.
Read next part: Reverse Engineering Mac Malware 2 - Mach-O Binaries