Using Osquery to Detect OSX/MaMi Malware

Seeing on Twitter that Patrick Wardle (a must follow for macOS security!) may have found his first piece of macOS malware for 2018, I eagerly flipped to his blog. Given that this is “new” malware on macOS, there is likely going to be a window between discovery and protection via A/V software.

As I often do with malware analysis posts, I wondered if this is something that could be found via osquery, because it is so easy to quickly create IOCs with osquery, allowing you to not have to wait for A/V updates before checking your enterprise. And indeed, it looks like it could. Let’s step through how you could do that.

OSX/MaMi (as Wardle has dubbed it) as of writing this (around noon EST on 12-January 2017) is only detected by two A/V engines (out of a possible 58, though some don’t do Mach-O binaries — edit — later in the afternoon, we are up to 12, which means only 46 don’t detect it ;-) ) on VirusTotal. So far, he has identified two fairly solid IOCs on initial analysis — the malware changes the DNS of the host to suspect DNS servers, and also install a certificate in the root certificate store that could be used for Man in the Middle (MITM) attacks and more. Both of these are easy to detect using osquery.

Looking at Patrick’s analysis, we can extract the following:

the DNS Servers that the malware changes the host to using are 82.163.143.135 and 82.163.142.137 and the certificate added to the certificate store is issued for a common name of cloudguard.me there’s various other metadata about the certificate included in the post. For the sake of example, I’ll grab the expiration date: Jul 15 17:25:15 2044 GMT

Ideally, we might want to use better metadata than that, but I don’t have the actual cert myself, so I can’t get a hash of it, and it turns out that unfortunately (?!) osquery doesn’t let you grab the serial number of the cert (which is metadata included in the blog post).

So, how do we go look for these?

I first thought that you could just grab DNS from the macOS preferences table, but that’s a bit of a mess — and the answer is sitting right there in Patrick’s analysis — the malware is modifying the System Configuration plist — so why not just check that?

will do the trick.

EDIT — after some suggestions and discussion in the osquery slack team, I’m going to update this. Thanks to Rodrigo for the suggestion.

After some discussion, it has been suggested that just parsing the plist doesn’t show the actual state of the OS, and is not completely reliable. I still feel that you might want to check the plist to see if it was modified, but a much simpler way of doing this is the dns_resolvers table, which actually reads the current configuration of the host. Using that, you would instead query as follows:

(End Edit)

Then, we look in the macOS certificates table for the bogus certificate. You should be able to find it with just

but if you are concerned that you might have a legitimate certificate for cloudguard.me knocking around, you could include another piece of metadata. Here is where I used the expiration date, Jul 15 17:25:15 2044 GMT which converts to a timestamp of 2352216315

so if you are paranoid, you can change your certificate query to

So, there you have it — in a lot less time than it took to blog about it, you can have two different IOCs that are fairly solid to go check your enterprise for the presence of OSX/MaMi.

caveats — I don’t have a system to run the malware on safely right now, so I tested all of my queries using dummy data (i.e. different DNS servers and certificates). If you run across this in the wild and find something different, please drop me a line! Additionally, I’ll keep an eye and if Patrick or someone turns up something new, I’ll strive to update this.