Thomas Read, a self-trained Apple security expert who also had a Mac before it was cool to have one, receive a message from a Twitter user going by the name @beatsballert. @beatsballert alerted Thomas to an apparently malicious Little Snitch installer available for download on a Russian forum, dedicated to sharing torrent links after learning about it. A post offered a torrent download for Little Snitch. It soon had numerous comments that the download included malware. But it was not only malware that Thomas discovered, it was also a new Mac ransomware spreading via piracy.
RUTracker post showing magnet link to malicious installer
During an analysis of this installer it was apparent that there was something unusual going on. But firstly, the legitimate Little Snitch installer is packaged well looking both attractive and professional. Secondly, it’s a well-made custom installer that is properly code signed. On the other hand, it was a simple Apple installer package that just advertised a generic icon. And poorly and pointlessly distributed inside a disk image file.
Malicious Little Snitch installer
Further scrutiny of this installer revealed that it would install:
- legitimate Little Snitch installer and uninstaller apps
- executable file named “patch”, into the /Users/Shared/ directory
After the installation process is completed, we find that the installer also contained a postinstall script that is implemented. Similarly, it is quite normal for the installer to contain preinstall and/or postinstall. It’s needed for preparation and clean up. Most importantly, the script in this case was used to:
- load the malware
- launch the legitimate Little Snitch installer
Firstly, the script manages to rename the process to CrashReporter by moving the patch file into a location that appears to be related to LittleSnitch. Secondly, the name Crash Reporter is a legitimate process that is part of macOS so it blends in well if its seen in Activity Monitor. Moreover, it can copy the /Users/Shared/ folder and remove the old one while launching the new copy. Finally, the Little Snitch installer is launched.
Consequently, the practice didn’t end up working very well. To clarify the malware did get installed But, then the attempt to run the Little Snitch installer was stalled indefinitely. Eventually giving up Thomas forced it to quit. In addition, even after Thomas had some decoy documents in position as willing victims, the malware didn’t ever start encrypting anything, regardless of letting it run for a while.
He waited and waited for the malware to do something—anything!
It needs more investigation, he thought! It did turn up an additional malicious installer;
- DJ software called Mixed In Key 8
- As well as hints that a malicious Ableton Live installer also exists (although such an installer has not yet been found).
- Thomas believe there are other installers as well, they just have not been seen as yet.
Meanwhile, the Mixed In Key installer had only a slightly different file names and postinstall script, so it turned out to be quite similar.
This simply dropped the Mixed In Key app into the Applications folder directly so it did not include code to launch a legitimate installer.
The malware began spreading itself quite liberally around the hard drive, once the infection was triggered by the installer. Both variants installed copies of the patch file at the following locations:
It also set up persistence via launch agent and daemon plist files:
The group of files /private/var/root/ is likely due to a virus within the code that creates the files in the user folder. It actually- leads to a creation of the files in the root user’s folder. And the root user or account as it’s also known is the one that by default has access to all commands and files on a Linux or other Unix-like operating system. But it’s rare for anyone to log in as root, so this in fact doesn’t serve any real purpose or concern.
Strangely, the malware also copied itself to the following files:
The first file was modified in a very strange way/Users/user/Library/.ak5t3o0X2 while the last file was identical to the original patch file. The first one strangely contained a copy of the patch file, with a second copy of the data from that file appended to the end, followed by an additional 9 bytes: the hexidecimal string 03705701 00CEFAAD DE. What the purpose of these files or this additional appended data is for, it’s not yet known.
Oddly and still unexplainable is the fact that the malware also modified the following files:
The above files are commonly found due to having Google Chrome installed on the machine and part of GoogleSoftwareUpdate. As a result, these files had the content of the patch file adjoined to them. In other words, the malicious code would run when any of these files is started. But Chrome notice that the files have been changed. Certainly, then Chrome will replace the modified files with clean copies as soon as it runs. So, it’s not very clear what the purpose here is either.
Likewise, the malware installed via the Mixed In Key installer was similar to LittleSnitch in that, starting the encryption of files was also inhibited. Thomas found that even after leaving it to run on a real machine for some time., there were no results. So, he then started playing with the system clock. But only after some mucking around did it finally begin to encrypt files. Thomas ended up having to set the clock to three days ahead and then disconnecting it from the network, and then restarting the computer a couple times, before it finally began.
Above all, Thomas found the malware wasn’t particularly smart about what files it encrypted. For example, it appeared to encrypt a number of settings files and other data files, like keychain files. When logging in post-encryption, it resulted in an error message.
Error displayed after the keychain was encrypted by the ransomware.
There were other apparent indications of error.
- Dock resetting to its default appearance.
The Finder also began showing signs of trouble,
- with spinning beachballs frequently appearing when selecting an encrypted file.
- freezes could only be managed by force quitting the Finder
Also, other apps would freeze repeatedly.
According to Thomas others encountered issues such as;
- a file is created with instructions on paying the ransom
- alert shown
- text-to-speech used to inform the user they have been infected with ransomware
But Thomas despite waiting quite a while for the ransomware to finish was unable to duplicate any of these issues.
Screenshot of encryption message posted to RUTracker forum
Included in the malware was some anti-analysis techniques, which are common with malware. These anti-analysis techniques found in functions named is_debugging and is_virtual_mchn. In other words, a malware researcher is analyzing it by having a debugger attached to the process or being run inside a virtual machine. So malware will typically not display its full capabilities in this case.
Patrick Wardle in a blog post on Objective-See, outlined the details of how these anti-analysis techniques routines work.
Firstly, the is_virtual_mchn function tries to catch a VM in the process of adjusting time, it does not actually appear to check to see if the malware is running in a virtual machine. Also, delays are not unusual for malware. For instance, a three-day delay happened when the first ever Mac ransomware, KeRanger, first infected the system to when it began encrypting files. That’s to say, malicious behavior may not be immediately associated with a program installed three days before. So, this helps determine the source of the malware that’s come in under disguise.
Secondly, the malware includes functions with names like ei_timer_create, ei_timer_start, and ei_timer_check. Meaning the malware could potentially run on a time delay. But experts are unsure about what the delay is.
Patrick also identifies that since there the presence of calls to the system routine CGEventTapCreate, the malware appears to include a keylogger. CGEventTapCreate allows for monitoring of events like keystrokes. But it is unknown, as to just what the malware does with this capability. It also opens a reverse shell to a command and control (C2) server.
A number of questions will still need to be answered. And only by further analysis. For instance,
- what kind of encryption does this malware use?
- Is it secure, or will it be easy to crack (as in the case of decrypting files encrypted by the FindZip ransomware)?
- Will it be reversible, or is the encryption key never communicated back to the criminals behind it (also like FindZip)?
As we can see by these questions, there’s still so much more to learn.
You’ll want to get rid the infection as soon as possible, if end up getting this malware. On Malwarebytes for Mac OSX.ThiefQuest is how it will appear. The infection will be detected and then removed with this software.
Experts are just not sure how bad the situation is if your files get encrypted. It all dependant on the encryption and how the keys are handled. A method for decrypting files is possible with further research but no guarantee.
Above all, maintain a good set of backups. This is the best defence in avoiding the consequences of ransomware. For example, keep at least two backup copies of all- important data, without them being attached to your Mac at all. (Ransomware may try to encrypt or damage backups on connected drives.)
Having multiple hard drives for backups is good practice. There are different types to maintain backups such as Time Machine and Carbon Copy Cloner. Thomas puts one of his backups in a safe deposit box at the bank, swapping them regularly. So this ensure that in a worse- case scenario, he has recent data stored in a very safe location.
Ransomware is no threat to you, as long as you have good backups. You can simply erase the hard drive and restore from a clean backup. Certainly these backups have other protective measures against situation such as drive failure, theft, and destruction of your device as some examples.
This new Mac ransomware variant spreading via piracy is just another example of the deepening cybercrime.