Analysis and Evolution of MacDefender OS X Fake AV Scareware

Over the last month, a new fake AV scareware variant has been circulating for OS X which has been gaining a lot of attention. Mac security developments tend to be hot news whenever announced and this case has been a shining example of the rule. There's a fair share of overhyping at play too, of-course. But rest assured, this isn't the first outbreak of mac-specific malware and it won't be the last.

I suppose by writing this blog post, we're throwing our hat into the cat and mouse game too. (Wait... I forget. Are we the cats or the mice, again?)

We're not in the AV business, but it's always good to keep tabs on new malware developments since we do get involved in a lot of incident response and forensics work. Our research team has been tracking development of the MacDefender malware going back to its earliest known variants. My teammate Rodrigo Montoro and I have been gathering and analyzing samples of the malware as well as reviewing security event alerts tied to infections in the wild.

The MacDefender family of malware itself is not all particularly unique or threatening but it is the first known fake AV attack known to target Mac OS X. As others have pointed out, it is probably more accurate to label this 'scareware' than 'malware'. However, the MacDefender outbreak still bears a lot in common with other modern 'crimeware' campaigns.

Also, analyzing this campaign may serve as an early look at what types of techniques and tricks we can expect from future Mac crimeware campaigns.

This outbreak also serves as yet another clear milestone that Apple's honeymoon of being relatively untouched by Mac malware has come to a fairly concise end. You can officially consider your OS to be susceptible to viruses and other malware when it is deemed worthy of its own fake anti-virus scareware scam!

Since the first variants appeared under the name 'MacDefender' on May 1st, 2011 there have been at least 12 new versions developed in the span of about a month. As of writing we have observed several subtle changes in the name of the crimeware, its design, communications protocols, deployment, and anti-reversing techniques. This rapid speed of evolution is a direct response to Apple's and AV vendors' attempts to detect and curtail the malware. This has become commonplace when dealing with modern crimeware, but it is still quite noteable to see it happening in this outbreak of Mac-based malware.

The Mac Fake AV Scareware Campaign

One thing that has remained constant along the entire MacDefender campaign is that the authors are highly motivated, most likely by financial profits. The campaign has been run in an efficient and professional manner.

Brian Krebs has written some prettyinterestingarticles on his blog investigating and tracking ongoing developments with a specific Russian-based online payment processor allegedly involved in or even behind the scam campaigns. This processor is said not only to be behind the the MacDefender OS X fake AV campaign, but several campaings targeting Windows as well. Based on our own analysis of MacDefender samples as well as Windows based fake AV campaigns, there are definitely several things in common in terms of deployment, communication protocols, and payment processing. There are also strong indications of Russian origin. Beyond that, we'll leave it to others to point fingers.

The campaign supports a fairly robust affiliate program which lets the folks behind it manage payment processing of purchased registration numbers with several affiliates based on an affiliate ID number. Each instance of the software distributed via malicious links contains an 'affiliate ID' which is used for calling home and in payment processing when victims fall for the 'Buy Now' scam being run.

As we'll see later, we can obtain and correlate samples with affiliates fairly easily once we know how to extract them from the configuration files included with the software.

Behavior

The behavior of the scareware has stayed more or less the same since its release. When installed the, fake AV software pops up several alerts about malicious files and in general tries to make it look like 'bad things are happening' which the victim should purchase the software to remedy.

One of the more annoying features of the malware is a routine which is designed to periodically open adult sitse using the default browser in an attempt to make the user think something shady is going on. It is shady, obviously. But it's the fake AV doing this itself. Here's a list of the 'shady URLs' that are opened this way:

hxxp://gay.porn.com
hxxp://buy-viagra-now.net
hxxp://fitish.com
hxxp://www.gay.com
hxxp://www.porn.com
hxxp://www.freebdsmgalleries.com

Behind the scenes, the malware also makes a single call home as soon as it is started. It sends notification of the infection via an URL back to a server which the attackers control. Initially only the affiliate ID was sent home this way, but as of version 2, the build number of the malware and a unique identifier for the host it is running on.

Timeline

Out of the 12 versions apparently developed at the time of writing, we have analyzed eight, starting from what is probably the first variant released. This is where the name 'MacDefender' came from. One thing to note off the bat is that current variants don't use this name and they haven't since version 2. The attackers change the names of the software frequently as new variants are released.

Below is a list of the samples we have collected and analyzed. The MD5 hashes are for the actual executable binary included in the OS X ".app" package once the scareware has is installed and running (The executable is found under "*.app/Contents/MacOS"):

• Version 1: MacDefender.app (2f357b6037a957be9fbd35a49fb3ab72)
  - Origin around May 1 12:48, 2011
  
  
• Version 2: MacSecurity.app (88cee1ab72fc09c99deaff33f8699f74)
  - Origin around May 5 10:51, 2011
  
  
• Version 3: MacSecurity.app (434ef1a9c9fdaacca840565b714c922b)
  - Origin around May 6 14:09, 2011
  
  
• Version 4: MacProtector.app (1f8e9cd3f0717a85b96f350e4f4a539a)
  - Origin around May 6 15:07, 2011
  
  
• Version 6: MacProtector.app (2d99a11cf2edde3613dac6f37ce70b75)
  - Origin around May 11 09:13, 2011
  
  
• Version 8: MacProtector.app (11bc0e8e7820790c565be8631effddf1)
  - Origin around May 13 16:33, 2011
  
  
• Version 10: MacGuard.app (9788c7452fd30626612875d852d26b0d)
  - Origin around May 24 12:07, 2011
  
  
• Version 12: MacShield.app (bfcd4fcfce956b802d6fed18683ead54)
  - Origin around Jun 2 07:15, 2011

Also around the May 24 timeframe, and coinciding with the release of the MacGuard variant, new downloaders emerged used for deploying the malware in a more modular manner by the attackers. We have seen three versions of the downloader so far.

Again the MD5 checksums below are based on the executable file located under the "*.app/Contents/MacOS" directory:

• avRunner.app (aka avSetup.pkg) (0754612c131b6429f5a2ac86f5e51503)
  - Origin around May 24 15:21, 2011
  
  
• mdDownloader.app (aka mdInstall.pkg) (5d84fbbbb5f8e3113eb78b9576f114e6)
  - Origin around May 31 17:20, 2011
  
  
• msInst.app (aka mshSD.pkg) (3c7a4fce301285a454babc93ba9bc064)
  - Origin around Jun 3 12:20, 2011

Common Characteristics

• The malware is a well designed professional-grade OS X application in its own right. The authors definitely have a solid grasp of OS X programming and the development technologies and methodologies used in developing Apple-based applications. The look of the tools is fairly polished. It poses pretty well as a legitimate software application by it's look and feel.

• All samples encountered have been written using Cocoa with objective-C and a smattering of C/C++ helper functions thrown in. The development environment is almost certainly Xcode. This includes the newer 'downloaders' which we will discuss more later as well.

• The code is probably of Russian origin. Earlier variants were built using Russian localization settings even though they contained only english language content. This was determined by observing the presence of ru.lproj localization directories under the app Resources. However, newer versions they have switched over to English.lproj, probably specifically to better mimic legitimacy.

Deployment

Several malicious servers are used throughout deployment of the original dropper and installers, to downloading the fake AV, to registering successful installation, to accepting payments for registering the fake AV software.

Over the past month as older servers have been identified and shut down, new ones begin to pop up in their place. The attackers show no sign of letting up and if anything have diversified their base of malicious servers. We have seen individual affiliate and C&C configurations go from including only a single IP address, to 2, to 3, and now 4 in the latest variants. More on this later when we describe the configuration files.

Earlier versions all used the same deployment technique until as late as May 24th. As a victim visited a malicious page they were presented with a popup window in their browser which would ultimately attempt to push down a zip file containing a "mpkg" package onto their computer. The attackers relied partly on insecure browser settings, especially in Safari which will automatically extract and open files considered 'safe'. Whoever deemed mpkg or pkg files "safe" file formats, probably should have looked closer at the scripting capabilities they support via Info.plist. At least your browser does let you turn off this "open safe files feature" feature, but it is turned on by default.

If the mpkg was allowed to be downloaded and opened, the fake av software is installed and immediately run in the /Applications directory on the victim's computer. The dropped mpkg file works just like pretty much any other OS X mpkg, it contains a 'pkg' which in turn contains an Archive.pax.gz file containing the components to be installed.

We can extract the 'pax' contents by decompressing the Archive.pax and running the 'pax' command available from Apple:

        $ pax -rvf Archive.pax

The mpkg package also includes a postflight 'pkg' to run scripted tasks after the app is installed. In this case the postflight script simply launches the fake AV application after it has been installed in /Applications.

Here's an example from MacProtector version 8:

#!/usr/bin/env bash

RESULT=`/usr/bin/open '/Applications/MacProtector.app'`

exit 0

As of as late as about May 24th, a newer deployment technique using an intermediate downloader began being used. This evolution of the 'downloader' technique is a common pattern seen with crimeware. At some point as their campaigns grow, it becomes easier for the attackers to begin using intermediate downloaders instead of direct deployment or file droppers.

As of as late as about May 24th, a newer deployment technique using an intermediate downloader began being used. This evolution of the 'downloader' technique is a common pattern seen with crimeware. At some point as their campaigns grow, it becomes easier for the attackers to begin using intermediate downloaders instead of direct deployment or file droppers.

The downloaders are distributed and pushed similarly to the original "mpkg" dropper. But instead of including the application to be installed, the pkg runs and downloads it from an malicious webserver. Not only can the file be updated more easily by the authors as new variants are devised, but only a small configuration file needs to be changed for different affiliates.

The timing of this downloader's appearance also seemed to coincide with Apples growing involvement in actively attempting to stamp out the malware. As Apple began developing their own countermeasures to detect and remove MacDefender infections, it makes sense that the malware authors would make this move. The malware authors probably switched to a more modular and robust downloader based deployment scheme to stay more nimble than their adversaries in the cat and mouse game that now ensues.

The other (more significant) change that the downloader introduced was that it was no longer necessary for the victim to supply admin credentials (assuming they were an 'admin' user on their own Mac, the default). Several early analysis reports and recommendations suggest that you can avoid infection by hitting 'cancel' at the credentials prompt. This is no longer the case. As soon as a fake AV package is opened, the software will be installed automatically without further user interaction.

Changing Characteristics

• Version 1: MacDefender.app (2f357b6037a957be9fbd35a49fb3ab72)
  • Origin around May 1 12:48, 2011
  • First version, pretty rudimentary compared to later variants.
  • Hardcoded urls for C&C and buy page are located in the binary.
  • The only variable parameter in the callback and buy page urls is an affiliate ID (or ?affid=nnnn).
  • Installation requires admin credentials to be supplied via the mpkg installer.
  • Product license/registration codes are hardcoded in the binary and visible with 'strings'.

• Version 2: MacSecurity.app (88cee1ab72fc09c99deaff33f8699f74)
  • Origin around May 5 10:51, 2011
  • The code is cleaned up a bit and call-home and buy page IP configuration info is separated from the binary to be stored in a config file.
  • The configuration file affid.txt which now contains affiliate ID and IP addresses is now obfuscated using a basic single-byte xor key (0x5c is the key).
  • A 'versioning scheme' of sorts is introduced. A file called ksms.txt contains a 'build number'. This is where we derived our version numbers for this report. The build number is added to 1000 when it is sent on the wire for some reason.
  • The urls used for callback changed format in this version. Now in addition to affid, the build number and a unique host identifier are sent to the webserver.

• Version 3: MacSecurity.app (434ef1a9c9fdaacca840565b714c922b)
  • Origin around May 6 14:09, 2011
  • Small cosmetic changes and addition of logging info (probably for troubleshooting).
  • Minor change to product registration.

• Version 4: MacProtector.app (1f8e9cd3f0717a85b96f350e4f4a539a)
  • Origin around May 6 15:07, 2011
  • Minor change to product registration was reverted.
  • Name change and changes to a few cosmetic aspects to match.

• Version 6: MacProtector.app (2d99a11cf2edde3613dac6f37ce70b75)
  • Origin around May 11 09:13, 2011
  • Several changes were made to make the app more robust with regards to product registration, look and feel, visual effects, and other features.
  • Added a secondary buy page backup incase the first was unavailable.
  • Valid license registration codes are still hardcoded, but they are now obfuscated with xor(0x55) to keep them from being discovered trivially using strings.

• Version 8: MacProtector.app (11bc0e8e7820790c565be8631effddf1)
  • Origin around May 13 16:33, 2011
  • The configurations are no longer stored in affid.txt. To further obfuscate and hide configurations, they are added to the end of a png file included in the Resources directory named 'CC-Back.png'.
  • New code was added to extract the configuration data from this file while letting CC-Back.png still appear as a valid PNG image file for the UI.

• Version 10: MacGuard.app (9788c7452fd30626612875d852d26b0d)
  • Origin around May 24 12:07, 2011
  • A backup address for the C&C call home at startup was added to the configuration file along with some code refactoring to support the new secondary address and some other miscellaneous features.
  • Some more logging code was added, presumably to help troubleshoot problematic issues with the new code and some other functions.
  • Name change and changes to a few cosmetic aspects to match.

• Version 12: MacShield.app (bfcd4fcfce956b802d6fed18683ead54)
  
  • Origin around Jun 2 07:15, 2011
  • Additional product registration checking and related code was added on startup and several and splash window popups (i.e. nag screens).
  • And... another name change.

Anti Reversing

Over time, the authors have begun to make small modifications in an attempt to hinder analysis and reverse engineering. Although, all in all, MacDefender is still pretty trivial to reverse engineer and detect by comparison to its Windows fake AV counterparts, let alone more sophisticated malwares such as SpyEye, Zeus, TDL, etc.

The only significant effort placed into anti-reversing so far has been to obfuscate affiliate ID and C&C server configuration information. The binaries and packaged files themselves remain free of packers, anti-debugging, and other techniques typically associated with anti-reversing. For our part, we're grateful. The less obfuscation and anti-reversing there is, the easier it is and theres generally more we can discern about the design and motivations by the attackers. Of course, by admitting all this, I probably just shot myself in the foot for the next version released...

Configuration Files

In the first variant (MacDefender), the affiliate ID was stored in cleartext in a file called 'affid.txt' in the .app's Resources directory. The URLs used for C&C and payment processing were hard-coded. The original C&C and payment server IPs were hardcoded as well:

Version 1: (MacDefender)

hxxp://nn.nn.214.53/mac.php?affid=[affid read from affid.txt]
hxxp://nn.nn.214.54/i.php?affid=[affid read from affid.txt]

The obfuscation of configuration information began as early as version 2. The configuration file obfuscation still isn't all that hard to break. It's just an 'xor' using a single-byte key.

In version 2 (dubbed MacSecurity instead of MacDefender), the attackers kept the configuration file 'affid.txt' but begain including IP information in it as well. This was apparently done to aid in diversifying deployment onto multiple hosts as detections would cause their C&C and payment processing sites to get blocked or even get taken down.

The urls now look something like this:

hxxp://nn.nn.nn.nn/i.php?v=<ver>&affid=<affid>&data=<hostid>
hxxp://nn.nn.nn.nn/mac.php?v=<ver>&affid=<affid>&data=<hostid>

The affid and two ip's in the new version 2 configuration were included in affid.txt and the whole file was now obfuscated using a simple scheme of xor(0x5c). Below is what the format looked like and what we learned the parameters are for based on code analysis.

Version 2 - ~4 (maybe 5): (MacSecurity and early MacProtector variants)

affid ; C&C ip ; buy page ip
affid.txt: nnnnn ; x.x.55.5 ; x.x.217.30

With version 6, we saw another IP appear in the affid.txt configuration. Bear in mind we didn't have a version 5 sample. Another IP was included which is a secondary IP for the buy page URL if the first was unavailable. It seems our friends like making very sure they get paid.

Version ~6+: (MacProtector variants)
affid ; C&C ip ; buypage ip ; backup buypage ip
affid.txt: nnnnn ; x.x.55.5 ; x.x.217.30 ; x.x.241.200

As of version 8 (still called MacProtector), an interesting development began. We see the malware embed configurations at the end of a png image, one of many included in the .app package's Resources directory. The config now resides at the end of CC-Back.png. It is still encrypted the same way, but it's padded onto the end of this png. What's more, there seem to be old affid configurations padded in front of it. The way they're tacked onto the end, it appears the authors may have been reusing a file which had several old configurations in it. Whoops!

In Conclusion

So there you have it. A (probably overly-comprehensive) view of how MacDefender has progressed over the past month or so. The biggest takeaway from this analysis seems to be that the campaign is still quite active and, if anything, momentum by the responsible parties has seemed to pick up! The primary reason for this is most certainly because the campaign remains profitable. The Mac 'market' for malware is apparently quite lucrative after all.

It will be interesting to see how this malware progresses, but even more so to see what sorts of future Mac OS X malware and campaigns will look like.