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:
//build path to source (General.rtf)
__sprintf_chk(pathSrc, 0x0, 0x400, “%s/Resources/General.rtf”, …);//build path to destination (kernel_service)
__sprintf_chk(pathDest, 0x0, 0x400, “%s/Library/kernel_service”, …);
//read in source file
rbx = fopen(pathSrc, “rb”);
var_1448 = fread(r12, 0x1, r13, rbx);
//write it out to destination
r14 = fopen(pathDest, “wb+”);
fwrite(r12, var_1448, 0x1, r14);
//set it to executable
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:
recursive_task(“/Users”, _encrypt_entry, _putReadme);//encrypt /Volumes
recursive_task(“/Volumes”, _check_ext_encrypt, _putReadme);
//build path to ‘.kernel_complete’
sprintf_chk(0x0, 0x0, 0x400, “%s/Library/.kernel_complete”…);
//write to file
rbx = fopen(0x0, “w”); fwrite(“do not touch this\n”, 0x12, 0x1, rbx);
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:
$ cat /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist
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:
//exec downloaded python
sprintf(var_430, “/tmp/%s”, rbx);
sprintf(var_830, “python %s”, var_430);chmod(var_430, 0x1c0);