A cumulative analysis of new OS X malware
Due to sheer volume, Windows malware generally dominates the malicious code and news scene. Of course, Macs are susceptible to malware as well and 2016 saw a handful of new malware targeting Apple computers.
In this blog, I wanted to discuss all Mac malware that appeared this year. While each sample has been reported on before (i.e. by the AV company that discovered it), this blog aims to cumulatively cover all in one place. Moreover, for each, we’ll identify the infection vector, persistence mechanism, features/goals, and describe disinfection.
If you want to play along, all samples can be downloaded from Objective-See’s malware page.
OSX/KeRanger is the first fully-functional, in-the-wild ransomware for OS X!
› infection vector
This malware was unusual for a variety of reasons. First, its infection vector is somewhat (for Mac Malware) unique. In order to surreptitiously infect Mac users, the OSX/KeRanger authors hacked the official website for a popular OS X bittorrent application, ‘Transmission’
With access to the website, the malware authors then infected the legitimate Transmission application with OSX/KeRanger. Specifically, they added a new mach-O binary to application bundle (General.rtf).
The main function of the Transmission.app was modified to execute this malware’s binary:
Finally the malware authors re-signed the (now) infected application so that GateKeeper (in its default settings) would not prevent the malware from executing:
Thus, any time an unsuspecting user downloaded and executed the Transmission application (again, from the official Transmission website) the malware would compromise their Mac. Yikes!
As far as I know, OSX/KeRanger does not contain any logic nor code to persist itself. Thus if the user reboots their system, or kills the malware’s process, kernel_service, the malware will not be restarted…unless the user re-runs the infected Transmission application.
Another unique aspect of OSX/KeRanger was its payload or goal. In short it attempted to encrypt for ransom, user files. Yes, OSX/KeRanger was the first, fully-functional in-the-wild piece of ransomware targeting Apple computers.
Reversing the malware reveals its ransomware logic:
As shown in the pseudo-code snippet, OSX/KeRanger will encrypt all files under /Users/* as well as all files under /Volumes that match certain extensions (PaloAlto Network’s report noted about 300, including .docs, .jpgs, .zips, .cpp, etc).
For each directory where the ransomware encrypts files, it creates a plaintext ‘read-me’ file the contains instructions to the user how to pay the ransom in order to recover their files:
One final, interesting aspect of OSX/KeRanger is that some researchers have convincingly claimed it is a rewrite or Mac version of the ‘linux.encoder’ ransomware. Their reasoning is quite compelling and seems to confirm that oftentimes malware authors are quite keen on expanding their potential targets by porting the malicious creations to OS X.
Since (AFAIK) OSX/KeRanger does not persist, it is trivial to remove:
- kill the kernel_service process
- remove ~/Library/kernel_*
- upgrade to version 2.93+ of Transmission.app
It should be noted that currently Mac users should be protected anyways, as Apple revoked the signing certificate (ID Z7276PX673), as well as updated their XProtect signatures:
OSX/Keynap is fairly standard backdoor for OS X with a propensity for stealing credentials, and uses Tor for its communications.
› infection vector
The original infection vector for OSX/Keynap was never discovered. Eset states that, “It is still not clear how victims are initially exposed to OSX/Keydnap. It could be through attachments in spam messages, downloads from untrusted websites…”
What is known is that it was distributed in a zip archive which contained a binary named screenshot.jpg . Since the filename contained a space at its end (i.e. “.jpg “) when a user double-clicked it, it would be executed by Terminal.app. In other words, the malware would be run.
Later, it was discovered that the official Transmission website (transmissionbt.com), was hacked again ðŸ™„ …this time, to distribute Keydnap. Just as they had with OSX/KeRanger, the malware authors infected the legitimate Transmission application, by adding an extra binary (License.rtf) then modifying the application’s code to execute it. The infected Transmission application was then (re)signed, with another stolen or fraudulently obtained Apple developer ID: Shaderkin Igor (836QJ8VMCQ):
Thus for a time, any user that downloaded and ran Transmission.app would be infected with OSX/Keydnap.
â€¨ In order to persist, OSX/Keydnap creates two launch agents, com.apple.iCloud.sync.daemon and com.geticloud.icloud.photo:
The first launch agent plist (com.apple.iCloud.sync.daemon) tells the OS to execute a binary named icloudsyncd. This binary is the backdoor component of the malware.
The second launch agent plist (com.geticloud.icloud.photo) contains a path to the malware’s command and control mechanisms. Named icloudproc, this binary is simply a copy of Tor2Web proxy.
As mentioned, icloudsyncd is the main component of the malware. It provides ‘standard’ backdoor or remote ‘administrative’ capabilities such ability to download and execute a file, including a python scripts:
OSX/Keydnap also contains logic to elevate its privileges, albeit in very unsophisticated method; just asking:
Perhaps the most interesting feature of the malware, is its ability to dump credentials and other sensitive information from the keychain. It does this via code from the open-source keychaindump project. (note however, AFAIK, this would generate an “icloudsyncd wants to access the keychain” alert that the user would have to allow):
OSX/Keydnap uses a Tor2Web proxy for command and control. An installed launch agent, icloudproc, is automatically started by the OS, and listens on 127.0.0.1:9050. As noted by ESET, the main backdoor component (icloudsyncd) uses this proxy for communication purposes: “Keydnap is using the onion.to Tor2Web proxy over HTTPS to report back to its C&C server.”
OSX/Keydnap can be removed from an infected system, via the following steps:
- Via the ‘launchctl unload’ command, unload the backdoor and Tor proxy
- Remove the launch agent plist files /Library/LaunchAgents or ~/Library/LaunchAgents com.apple.iCloud.sync.daemon.plist and com.geticloud.icloud.photo.plist
- Remove the launch agent binaries & files:â€¨
- a) ~/Library/Application Support/com.apple.iCloud.sync.daemon/â€¨
- b) ~/Library/Application Support/com.geticloud/â€¨
Apple has also revoked the Apple developer ID that was used to sign the infected Transmission application:
OSX/Eleanor is another basic, albeit ‘feature-complete’ backdoor (php) for Mac computers.
› infection vector
Similar to other OS X malware of 2016, OSX/Eleanor was distributed in an applications via the internet. However, it appears that the malware authors simple (re)created an abandoned application (“EasyDoc Convertor”), as opposed to hacking the official website of a legitimate application.
The malicious, fake EasyDoc Convertor application was hosted on the popular app sharing website Mac Update. Thus, any user that downloaded and ran this application would be infected with Eleanor.
OSX/Eleanor installs three(!) launch agents in order to persist its various components. Obviously stealth was not something the malware authors cared about at all 😛 The three launch agents are:
- com.getdropbox.dropbox.integritycheck.plist → conn
- com.getdropbox.dropbox.timegrabber.plist → check_hostname
- com.getdropbox.dropbox.usercontent.plist → dbd
mv $DIR/com.getdropbox.dropbox.integritycheck.plist ~/Library/LaunchAgents/com.getdropbox.dropbox.integritycheck.plist
launchctl load ~/Library/LaunchAgents/com.getdropbox.dropbox.integritycheck.plist
mv $DIR/com.getdropbox.dropbox.timegrabber.plist ~/Library/LaunchAgents/com.getdropbox.dropbox.timegrabber.plist
launchctl load ~/Library/LaunchAgents/com.getdropbox.dropbox.timegrabber.plist
The first launch agent, com.getdropbox.dropbox.integritycheck.plist, executes a binary name conn. This simply sets up a hidden Tor service. The second launch agent, com.getdropbox.dropbox.timegrabber.plist executes a bash script name check_hostname. This script publishes name of the hidden Tor service to pastebin. The final launch agent,com.getdropbox.dropbox.usercontent.plist executes a binary named dbd, which is actually a copy of Apple’s PHP binary:
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
A rather unique feature of Eleanor is that it essentially turns an infected host into a remotely accessible hidden Tor service. The command and control logic for this is implemented with the conn binary. Via Objective-See’s TaskExplorer utility, it is easy to see the malware listening on both port 9060 and 9061:
The malware gets these port values from one of its Tor configuration files, ~/Library/.dropbox/sync/storage:
GeoIPv6File /Users/user/Library/.dropbox/sync/data/list6HiddenServiceDir /Users/user/Library/.dropbox/sync/hs
HiddenServicePort 80 127.0.0.1:9991
HiddenServicePort 22 127.0.0.1:9992
The malware also contains a bash script named check_hostname, which, as previously mentioned, is persisted as a launch agent. The purpose of this script is to encrypt the name (address) of the hidden Tor service that was setup by the first launch agent, and then publish that to pastebin. This of course allows the attacker to ‘find’ and connect to the infected host.
The core backdoor logic of OSX/Eleanor, is actually implemented in PHP – this is why the malware has a copy of Apple’s PHP binary. Specifically the malware contains a copy of the b374k shell (v 3.2.3) which is available online at github.com/b374k.
The PHP shell affords the attacker complete over an infected remote computer:
To further extend the features, or capabilities of the malware, it ‘ships’ with several utilities such as netcat and wacaw. The latter, wacaw, is available online where it is described as “a little command-line tool for Mac OS X that allows you to capture both still pictures and video from an attached camera“. Thus an attacker could record the user of an infected Mac.
To remove OSX/Eleanor from a system, simply unload then delete the three aforementioned launch agents. Following this, delete the ‘hidden’ ~/Library/.dropbox directory and the malicious EasyDoc Convertor application.
Apple has also updated XProtect with a signature to block Eleanor:
Fake File Opener
OSX/FakeFileOpener is a rather silly piece of adware, though it does have a unique persistence mechanism.
› infection vector
OSX/FakeFileOpener is installed along with other annoying OS X adware when a user is tricked into believing a fake security alert originating from ‘AdvancedMacCleaner.com’
If the user clicks ‘Install Security Upgrade Now’ button and executes the downloaded adware installer package, they will infect themselves. As the OSX/FakeFileOpener adware application, ‘Mac File Opener.app’ was signed, Gatekeeper (in its default settings) would allow it to execute:
Thomas Reed (@thomasareed), the malware reverser who originally analyzed the sample noted that, “even more intriguing, this app didn’t have any apparent mechanism for being launched. It hadn’t been added to my login items. There wasn’t a new launch agent or daemon designed to load it. It simply seemed to be sitting there, doing nothing.”
Digging deeper, he discovered that this malicious application (by means of its Info.plist file) registers itself as the ‘document handler’ for a myriad of file types. In his words:
“Essentially, what this app had done is set itself up as an app that can open most files that are at all likely to be on the typical user’s system. Worse, if there is no other app to open a specific file, this app would be the default. It turns out that this is exactly what that app wants, and it takes full advantage of that fact.”
Since this mechanism requires a user launch an application that previously didn’t have a default ‘document handler’ and matches one that ‘Mac File Opener’ registered for, this is somewhat of a ‘unreliable’ persistence mechanism. However, the upside to this method is that it will ‘bypass’ tools such as BlockBlock that monitor for true persistence mechanisms (i.e. ones that require no user interaction, instead are automatically executed each time the system is rebooted or the user logs in).
It’s rare to find novel persistence mechanisms in OS X malware. As such, I previously dedicated an entire blog post, titled, “Click File, App Opens” that digs into the technical details of this persistence and how, at the OS level, such document handlers work.
OSX/FakeFileOpenor is part of a fairly standard run-of-the-mill OS X adware package. It appears that its goal is simply to get the user to install more adware. Specifically, whenever the Mac File Opener.app is launched (when the user tries to open any file it has registered a document handler for), it will display a popup with a ‘Search Web’ button. If the user clicks this button, it will load www.macfileopener.org in a browser window.
This website will often display other adware-related popups and alerts to trick the user into downloading and installing even more malware. As Thomas Reed notes; “these pages will download other junk PCVARK apps, such as Mac Adware Remover or Mac Space Reviver.”
To remove OSX/FakeFileOpenor, simply delete the Mac File Opener application. Behind the scenes this will cause the OS to also unregister its document handlers:
open com.apple.LaunchServices-134501.csstore lsd.31116
WrData[AT2] com.apple.LaunchServices-134501.csstore lsd.31116
WrData[AT2] com.apple.LaunchServices-134501.csstore lsd.31116
/Support/lsregister -dump | grep “Mac File Opener” | wc
0 0 0
While OSX/Mokes does support a wide range of features, at its core, it’s still a fairly standard OS X backdoor.
› infection vector
How user are become infected by OSX/Mokes is still unknown. Kaspersky, the AV company that discovered it, stated, “…we can only speculate how this malware makes it to the victim machine. All vectors are possible: exploits, installation via another previously installed malware and of course via social engineering.”
Launch Agents are the preferred method of persistence for OS X malware. OSX/Mokes conforms to this trend installing itself launch agent via the storeuserd.plist in ~/Library/LaunchAgents/. Looking at its disassembly, its easy to find the embedded template the malware uses for the launch agent:
Besides basic features such as download and execute, OSX/Mokes supports a fairly wide range of other capabilities as noted by Kaspersky: “This malware…is able to steal various types of data from the victim’s machine (Screenshots, Audio-/Video-Captures, Office-Documents, Keystrokes).” One can confirm this by reversing the malware’s binary. For example, below are several hard-coded file search constants:
The malware also monitors for removable media (e.g. USB sticks). To record the user, the malware utilizes the QT. This cross-platform framework contains OS X-specific webcams recording code:
Removing OSX/Mokes is a touch complex, as the malware may install itself into multiple locations. Once the malware is detected though, simply unload its launch agent (e.g. launchctl unload ~/Library/LaunchAgents/storeuserd.plist) then delete its binary (e.g. storeuserd).
Besides the standard storeuserd name, the malware may install itself to:
Russian cyber-operations were a popular topic in 2016. OSX/Komplex is one of the Russian’s (APT 28/Fancy Bear’s) OS X implants.
› infection vector
OSX/Komplex is a Mac application that is distributed via email (as an attachment). When executed, it will infect the system, but also display an PDF document in a (lame) attempt to hide the infection. The antivirus company Intego, notes that:
“The person who receives the email may think they are opening a PDF file with future plans for the Russian aerospace program, but in fact, it is a Trojan that will install files on the system and connect to a remote command & control (c&c) server.”
Looking at the disassembly of the malware’s main function shows the malware opening the embedded PDF, via the Preview application:
How does this malware persist? If you guessed launch agent, you are right! OSX/Komplex persists via ~/Library/LaunchAgents/com.apple.updates.plist. This persistent launch agent plist, points to a malware’s binary which is located in /Users/Shared/.local/kextd.
<?xml version=”1.0″ encoding=”UTF-8″?>
When executed, OSX/Komplex first checks if it is being debugged or executed on a system that is not connected to the internet:
OSX/Komplex implements only few basic features. However, these are sufficient to allow a remote attacker to completely control an infected host. These features include:
- download a file
- delete a file
- configure the backdoor
- executing a file
- executing a shell command
0000000100001e60 T FileExplorer::executeFile(char const*, unsigned long)
0000000100001b90 T FileExplorer::getFileName()
0000000100001b70 T FileExplorer::setFileName(char*)
0000000100001e00 T FileExplorer::setParameters(char*)
0000000100001bd0 T FileExplorer::executeShellCommand()
0000000100001e20 T FileExplorer::setRemove()
Besides the Russia connection, OSX/Komplex is rather interesting as the PaloAlto researchers note it may have actually been spotted before. In 2015, BAE systems released a report title “New Mac OS Malware Exploits Mackeeper.” In this report they describe a new (unnamed) piece of malware that exploited a remote vulnerability in the infamous MacKeeper software in order to infect Mac users. The PaloAlto researchers noted a lot of similar code, leading them to state, “these overlaps suggest that the Trojan delivered by the MacKeeper vulnerability was in fact the Komplex Trojan.”
It is trivial to remove OSX/Komplex. First simply unload the malware’s launch agent (~/Library/LaunchAgents/com.apple.updates.plist). Then delete both the launch agent plist and binary:
$ rm /Users/Shared/.local/kextd
Well that’s a wrap! In this blog we discussed (all?) Mac malware that emerged in 2016. Hopefully 2017 will bring us lots of new malware to play with 🙂