|
|
Apple’s little known malware removal tool gets a signature update. But what is this new malware family MACOS.35846e4? Find out on this journey inside MRT
We’ve noted before that Apple’s built-in security technologies have been missing some updates of late, and we weren’t the only ones. So, when Apple dropped a couple of updates to MRT and XProtect last week, the macOS community raised a collective eyebrow of interest. With XProtect having hardly seen a significant update since March of 2018, there were high hopes that Apple were finally playing catch-up with the rounds of macOS malware that have appeared since XProtect’s last update.
As it turned out, the updates were underwhelming on the one hand and curious on the other. XProtect merely received a bump for the minimum Flash player plug-in (now, minimum required version is 32.0.0) but otherwise added no new malware families, while MRT only added a single new malware family to its search-and-remove definitions, an item Apple designated MACOS.35846e4.
The addition to MRT caused some consternation among macOS security enthusiasts as this nomenclature is unfamiliar to the wider macOS research community: what is the mysteriously named MACOS.35846e4? Were Apple discovering new malware and keeping the details from the wider security community? It wouldn’t be the first time they’ve been accused of such.
We decided to take a look at the MRT.app and find out for ourselves.
Inside MRT.app
The Malware Removal Tool (MRT.app) is an Apple application that lives in the CoreServices folder located in /System/Library, rather than the Applications or Utilities folders where user level programs are typically located. Despite taking the form of an application bundle, MRT is not supposed to be launched by users.
However, it does possess some command line options which allow it to be invoked either as an agent or daemon, and interestingly also may generate an error message related to the mysterious new malware family:
The error message doesn’t give us any clue as to what MACOS.35846e4 is though. Figuring out what MRT looks for requires a couple of different approaches. The first thing we need to do is grab a copy of the binary to play with. Even though we don’t plan to write to the binary and it’s protected by System Integrity Protection (which is designed to prevent modifications), working with a copy of a binary during analysis is just a habit that you should always adopt when reverse engineering. We can grab a copy of the binary by executing ditto to write a copy of the binary to the Desktop.
sudo ditto MRT ~/Desktop/MRT_COPY
Pulling Strings
The first step in reverse engineering an executable file is usually to dump the plain text ASCII characters embedded in the file. Simply dumping the strings from the binary will often reveal hardcoded file paths. There’s a couple of ways to achieve this, but the built-in macOS utility, conveniently called strings, is probably the easiest. The strings utility contains a stub by default that actually installs the full utility the first time you use it. Pass the -a flag and the path to the file name, and output the strings to a new file:
strings -a ~/Desktop/MRT_COPY > ~/Desktop/MRT_Strings.txt
You can scroll and search through the new file in a text editor of your choice. Note that the output is just a dump of every string in the binary, and there’s no way to automatically determine from this which strings are actually malware definitions and which are just strings used for other purposes in the binary. That said, many are obvious given a little experience, but it’s important to treat the output with caution until or unless you can verify a file path is related to malware from further checks.
Aside from the fact that there’s no intrinsic way to distinguish the strings from one another, there’s another problem: the strings don’t contain all of the definitions. And although we can search through the strings for the family name MACOS.35846e4, the output doesn’t give us any clear indication of the malware that it refers to.
It’s time to dive a bit deeper.
Static Code Analysis
For this, you need a disassembler like Cutter or Hopper. In this example, we’ll use Hopper because it gives a slightly cleaner and easier to read output.
We begin by searching for references to the string 35846e4 in Hopper’s strings section.
From here, we find a reference to the string being loaded into the rdi register. That’s interesting! One of the uses of the rdi register is to hold the first argument in a call to an Objective-C function. Switching to Hopper’s pseudocode view shows us that the string is being loaded into the register from within another function sub_1000ca9a0, where we find a treasure trove of ASCII characters hidden in byte code. This image shows one collection of 13 characters found in the function, each held in a separate variable:
We can do a quick-and-dirty check to see if they’re interesting on the command line:
The string turns out to be sendLogEvent:, which looks like an Objective-C method call due to the presence of the colon on the end. That’s enough to peek our interest. Scanning through the rest of the method, we see lots more individual variables holding hex values that map to ASCII character codes. To see what they hold, we’ll just dump the whole function into a text file and do some text manipulation to isolate and translate the hex values. This results in the following strings:
We recognize some of these as classic adware strings, so it seems that MACOS.35846e4 is some form of new adware. Let’s check out VirusTotal and see if we get any matches.
Old Adware, New Variant
Fortunately for us in this case, we get a bunch of hits:
This is a family of adware that’s been around a long time but was updated after the release of macOS 10.14 Mojave to take into account Apple’s implementation of new user protections. The adware appears to users under various names like “MacSecurityPlus” and “MacOSDefender”.
There’s a hidden folder at ~/Library/Application Support/.dir that contains an application called “CompanyUpdater”. A persistence agent in the user’s Library LaunchAgents folder executes a process called “Dock” to ensure the infection is reinstalled if removed. The adware will also try to install browser extensions in Chrome, Firefox and Safari, typically called something like “AnySearch” or “DefaultSearch”.
Conclusion
In this post, we’ve gotten to the bottom of the mystery of Apple’s update to Malware Removal Tool, though not to why Apple tried to obscure this particular detection. It also remains a mystery why Apple are continuing to update MRT while leaving XProtect practically moribund. For users and endpoints, given the amount of new malware that has arisen in the last year that neither XProtect nor MRT recognizes, it remains a wise choice to ensure you have a more robust security solution installed on your Mac computers.
