Yesterday lots of antivirus labs got a sample of the new antivirus program targeting MAC OS X users. This sample named Backdoor.OSX.Morcut was distributed using social engineering techniques via a JAR file with the name AdobeFlashPlayer.jar and allegedly signed by VeriSign Inc.

Notification from the JAVA virtual machine about the launch of the untrusted applet

Two days ago we intercepted a new APT campaign using a new MacOS X backdoor variant targeted at Uyghur activists.

But before we go into details, let’s start with a quiz:

- The Dalai Lama walks into an Apple Store. Why?

A possible answer is, “to buy one of the new MacBook Pro’s with the Retina display!” (speaking of which, I would very much like to buy one of those as well, but it’s kind of difficult to justify the hit to the family budget)

Joke aside, actually Dalai Lama is a well known Mac user. Here’s a photo of him using a Mac during a conf call:

Market share! It’s an easy answer, but not the only one.

In 2011, Apple was estimated to account for over 5% of worldwide desktop/laptop market share. This barrier was a significant one to break - Linux maintains under 2% market share and Google ChromeOS even less. This 15 year peak coincided with the first exploration by the aggressive FakeAv/Rogueware market targeting Apple computers, which we discovered and posted in April 2011 and later in May 2011, which no longer seem to be such an odd coincidence. Also, the delay in Apple malware until now most likely was not because Apple exploits were unavailable, or because the Mac OS X system is especially hardened. The 2007 "Month of Apple Bugs" demonstrated that the Mac OS X and supporting code is full of exploitable flaws. Safari, Quicktime, and other software on Apple devices is regularly exploited during pwnage contests, but widespread cybercrime attention hadn’t caught on until this past year.

At this point, we still don't know who is behind Flashfake, so we don’t know for sure that they were the same Mac OS X FakeAv/Rogueware group. Speculating that eastern euro-cybercrime is behind the botnet would be a pretty confident way to go right now. There are known groups from the region that have succeeded at wringing ad revenues from traffic hijacking. We don't believe that other sensitive data has been targeted. And the exploit distribution URLs that we are aware of have only targeted mac users. These factors limit the operational and technical needs of a financially motivated cybercrime gang.

In a sense, it would appear that their activity was somewhat similar to the Koobface or Tdss gangs. They haven't commited large unique financial crimes to attract the attention of law enforcement, and their malware contains hooks and other code to perform more sophisticated banking crime than search traffic hijacking, but they most likely were looking to make a multitude of small financial gains. On the other hand, thankfully, Apple hasn't given these guys ample notice to make their run. There can be plenty of money in that business - it is estimated that the Koobface guys ran off with millions after Facebook "outted" their operation under investigation. But based on the domain registrations we have examined, the individuals are not quite so public and they are hiding their identities while they hijack search engine traffic. The malware itself injects a number of hooks into running applications, much like the Zeus, SpyEye, and other spyware. If these were used for financial crimes, the group operating this botnet would need to organize money mules and accomplices to launder their stolen money, which would grow the group and attract the attention of other authorities.

On the technology side, Java is a big part of the puzzle. Although the Trojan is called Flashfake because users were being convinced to install the malware as an Adobe Flash update, more recent versions of the malware were being installed via client-side Java exploitation.

Three vulnerabilities were targeted with client-side exploits, none of them were 0day, which seem to have become much more difficult to come by. Besides, this set worked just as well for these operators. It is interesting to note the duration of time from the original Oracle Java security update to the Apple Java security update, and when in that timeframe the release offensive security research publicly appeared. And, when were Metasploit open source exploit modules were released targeting the related Java vulnerabilities? The windows of time may be alarming – these are not 0day exploits, but Apple simply hasn’t released patches, leaving their customers exposed to the equivalent of known 0day exploits.

CVE-2012-0507

2012-02-15 Oracle patches Atomic Reference Array vulnerability

2012-03-10 First Itw exploits targeting the vuln

2012-03-30 Metasploit developers add Java atomicreferencearray exploit module

2012-04-03 Apple patches their code

CVE-2011-3544

2011-05-12 Reported to vendor

2011-11-18 Oracle patched their Java SE

2011-11-30 Metasploit developers add "Rhino exploit" module

2011-11-30 Krebs reports operational Blackhole site with the new Java exploit

2012-3-29 Patched by Apple

CVE-2008-5353

"Deserializing Calendar objects"

2008-08-01 Reported to Sun with first instance of the vulnerability

2008-12-03 Sun patches their code (Sun link down)

2009-05-15 Apple patches MacOSX code

2009-06-16 Metasploit developers add Java deserialization exploit

Also on this list is a lame exploit described as a signed applet social engineering trick.

I'd prefer to call it the "the terribly confused user presented with the Java 'do you want to trust this applet?' dialog and will run anything you present them" gamble. It first became a part of the Metasploit exploit module list on 2010-01-27. Basically, these guys present the user with a file that the user thinks is a JavaUpdate provided by Apple Inc themselves, which they grant trust to perform any action on their machine. The downloader will then communicate with a couple of sites to register and download new Flashfake components. These components in turn, collect the system UUID and timestamp, then auto-generate with a crypto algorithm a set of C2 domains, along with maintaining a list of hard coded domains. A couple of the newer components inject into running processes on the system hooking software functionality and hijacking traffic, much like past TDS malware.

Late last week, we found evidence of a possible link between a Mac OS X backdoor trojan and an APT attack known as LuckyCat. The IP address of the C&C to which this bot connects (199.192.152.*) was also used in other Windows malware samples during 2011, which made us believe we were looking at the same entity behind these attacks.

For the past two days, we have been monitoring a “fake” infected system - which is a typical procedure we do for APT bots. We were extremely surprised when during the weekend, the APT controllers took over our “goat” infected machine and started exploring it.

On Friday Apri 13, port 80 on the C&C server located at rt*****.onedumb.com and hosted on a VPS in Fremont, U.S. was closed. Saturday, the port was opened and bot started communicating with the C&C server. For the entire day, the traffic was just basic handshakes and exchanges, nothing more.

On the morning of Sunday April 15, the traffic generated by the C&C changed. The attackers took over the connection and started analysing our fake victim machine. They listed the contents of the root and home folders and even stole some of the goat documents we put in there!

Earlier this week, Dr.Web reported the discovery of a Mac OS X botnet Flashback (Flashfake). According to their information, the estimated size of this botnet is more than 500, 000 infected Mac machines.

We followed up with an analysis of the latest variant of this bot, Trojan-Downloader.OSX.Flashfake.ab.

It is being distributed via infected websites as a Java applet that pretends to be an update for the Adobe Flash Player. The Java applet then executes the first stage downloader that subsequently downloads and installs the main component of the Trojan. The main component is a Trojan-Downloader that continuously connects to one of its command-and-control (C&C) servers and waits for new components to download and execute.

The bot locates its C&C servers by domain names, and these names are generated using two algorithms. The first algorithm depends on the current date, and the second algorithm uses several variables that are stored in the Trojan’s body and encrypted with the computer’s hardware UUID using RC4 cipher.

We reverse engineered the first domain generation algorithm and used the current date, 06.04.2012, to generate and register a domain name, "krymbrjasnof.com". After domain registration, we were able to log requests from the bots. Since every request from the bot contains its unique hardware UUID, we were able to calculate the number of active bots. Our logs indicate that a total of 600 000+ unique bots connected to our server in less than 24 hours. They used a total of 620 000+ external IP addresses. More than 50% of the bots connected from the United States.

Geographical distribution of active Flashfake bots

We cannot confirm nor deny that all of the bots that connected to our server were running Mac OS X. The bots can be only identified by a unique variable in their User-Agent HTTP header named “id”, the rest of the User-Agent is statically controlled by the Trojan. See example below:

"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0.1; sv:2; id:9D66B9CD-0000-5BCF-0000-000004BD266A) Gecko/20100101 Firefox/9.0.1"

We have used passive OS fingerprinting techniques to get a rough estimation. More than 98% of incoming network packets were most likely sent from Mac OS X hosts. Although this technique is based on heuristics and can’t be completely trusted, it can be used for making order-of-magnitude estimates. So, it is very likely that most of the machines running the Flashfake bot are Macs.

Approximate distribution of OSes used to connect to our server

At Virus Bulletin 2011, we presented on the exploding level of delivered Java exploits this year with "Firing the roast - Java is heating up again". We examined CVE-2010-0840 exploitation in detail, along with variants of its most common implementation on the web and some tools and tips for analysis. Microsoft’s security team presented findings for 2011 that mirrored ours in relation to Java exploit prevalence on the web – it is #1! At the same time, aside from the recent, well-known BEAST Java implementation, it is striking that it has been very uncommon to see Java backdoors, Trojans and spyware. But that lack of Java malware variety is beginning to change. My colleague, malware analyst Roman Unucheck, identified a new Java bot with some interesting characteristics that we named "Backdoor.Java.Racac".

A few days ago I published a blog post regarding the reverse engineering of the Mac OSX Rogue AV registration routine. The goal was to see if the product was acting like a legitimate one once registered. The product behaved normally, and pretended to clean the machine like their windows counterpart. It was also possible to gather intelligence on the technical support once registered.

So today, I had a look at a newer variant to see whether the registration algorithm was similar or not.

The serials are no longer in plain text, but it’s still very easy to break. Here is how.

The registration function is still the same: __RegEngine_CheckKey__.

Let’s have a look into it and see how different it is now.

The Virus Lab recently came across a very interesting sample – a downloader containing two drivers and which downloads fake antivirus programs developed for both PC and Mac platforms. The malicious program is downloaded and installed using the BlackHole Exploit Kit. The latter contains exploits targeting vulnerabilities in JRE (CVE-2010-0886, CVE-2010-4452, CVE-2010-3552) and PDF.

Both drivers are standard rootkits with rich functionality. One of them is a 32-bit and the other a 64-bit driver. The 64-bit driver is signed with a so-called testing digital signature. If Windows – Vista and higher – was booted in ‘TESTSIGNING’ mode, the applications can launch the drivers signed with a testing signature. This is a special trap-door which Microsoft has left for driver developers so they can test their creations. Cybercriminals have also made use of this loophole: they execute the command ‘bcdedit.exe –set TESTSIGNING ON’ which allows them to launch their driver without a legitimate signature.

The following description refers to both rootkits because, apart from the platforms, their functionality is identical. Once the driver is successfully loaded and running on the system, it’s difficult to get rid of it. The rootkit blocks the launch of drivers belonging to anti-rootkit and antivirus products. This is done by using lists of file names for specific drivers and strings for which the rootkit searches the Security section of the DataDirectory array of the image being loaded. If the rootkit detects an “untrusted” driver being loaded, the bytes at the entry point of the image are changed, preventing it from loading correctly.

Fragment of the rootkit containing search strings used to block antivirus drivers

The rootkit protects the “main” application by hooking ZwOpenProcess / ZwOpenThread in SDT (only on 32-bit versions of Windows) and using object manager callbacks to access “trusted” applications. The file system is also monitored by connecting to file system stacks and the registry – by using registry callbacks.

This rootkit is yet more proof (after TDSS) that it’s unnecessary to bypass Patch Guard-а in order to implement rootkit functionality on 64-bit platforms.

The downloader is written in C++ and is itself not protected. Its main task is to install and launch the relevant driver (32- or 64-bit), then download and launch a list of files from URLs. Interestingly, one link leads to Hoax.OSX.Defma.f which we recently wrote about. Most importantly, the rootkit tries to run it…under Windows! It appears that the developers of the latest rogue AV program for MacOS are actively distributing it via intermediaries, who don’t really understand what it is they are supposed to install on users’ computers.

Fragment of the malicious code that downloads and launches the file

Kaspersky Lab products successfully detect and neutralize both Trojan-Downloader.Win32.Necurs.a and Rootkit.Win32.Necurs.a / Rootkit.Win64.Necurs.a.

My colleagues Fabio Assolini and Vicente Diaz wrote two blog posts recently regarding the Rogue AVs for MAC OSX. After executing it on a test machine, and playing with it, I noticed there was some hidden information in the About Window as can be seen below:

I was interested by the “Support” information, but it’s only available to registered customers. I also wanted to confirm a few things such as the “cleaning” of the fake threats once registered, and to see if the “infected” popups would stop.

When my colleague Fabio wrote about a Rogueware campaign targeting MAC users, I investigated a bit into the origin of these campaigns. It was interesting how different researchers were getting those samples through searching images on Google. However, different searches always arrive at the same result, leading to the question: How many search terms have been poisoned?

That was an interesting question. But the answer came reading another very interesting research from Unmask Parasites. I recommend you read the post, but in essence it explains how thousands of sites have been infected with a very effective schema that allows the criminals to poison image search results. Could it be that this schema was connected to the fakeAV for MAC?