infection:

"[we] encountered a post in one of the leading, closed Russian cybercrime message boards. The author of the thread announced a RAT dubbed Proton, intended for installation exclusively on MAC OS devices. The author offered this product in one of the leading underground cybercrime markets."

Variant 'C' of Proton propagated in a similar way. Specifically the attacker gained unauthorized access to 'Eltima' and trojanizing several applications. It should be noted that for this variant, the attacker's signed the trojanized applications with a 'valid' Apple developer ID, meaning macOS malware mitigations such as Gatekeeper would be 'bypassed' (well, more specifically, avoided). Luckily (now) the certificate is now revoked:


The final variant of Proton seen in 2017, variant 'D' targeted Mac users in a less elegant way. As discovered by @noarfromspace, for this variant the attackers created a fake website that attempted to masquerade as a Symantec blog:

More details on this can be found in MalwareByte's blog post titled, "OSX.Proton spreading through fake Symantec blog":



Proton persists itself as a Launch Agent. Thought (AFAIK) all variants persist in a similar manner, let's take a closer look at variant B.

Firing up my open-source macOS process monitor (on github: ProcInfo) and executing the infected Handbrake application, results in the following 'process' events:
From this ProcInfo output, we can see that the infected Handbrake application:

1. unzips Contents/Resources/HBPlayerHUDMainController.nib to /tmp/HandBrake.app
. This 'nib' is a password protected zip file who's password is: qzyuzacCELFEYiJ52mhjEC7HYl4eUPAR1EEf63oQ5iTkuNIhzRk2JUKF4IXTRdiQ


2. launches (opens) /tmp/HandBrake.app

Once the /tmp/HandBrake.app is launched, it displays a (fake) authentication popup - which is how the malware attempts to elevate its privileges:



If the user is tricked into providing a user name and password the malware will install itself (/tmp/HandBrake.app) persistently as: 'activity_agent.app'.

It does this by creating a Launch Agent plist file (fr.handbrake.activity_agent.plist). Dumping this file, we can see the malware has set the RunAtLoad key to true, which will ensure that it is automatically started each time the user logs in:
As noted, other variants persist in similar manner, although the name of the Launch Agent plist is different. For example, when executing variant 'C' BlockBlock detects a persistence attempt, noting that the malware is attempting to persist via /Library/LaunchAgents/com.Eltima.UpdaterAgent.plist:


Variant 'D' persists via a plist file named com.apple.xpcd.plist also within the /Library/LaunchAgents/ directory.

The original SixGill blog post contains a screencapture of the advertised features of Proton:


We can gain more insight into the malware's features by reversing its core binary. Specifically, we determine that the malware (here, variant 'B') will somewhat 'stealthily' build a path to an encrypted file named '.hash' in its resources directory (/tmp/HandBrake.app/Contents/Resources/.hash):

This file is loaded into memory by the malware and then decrypted via a call to [RNDecryptor decryptData:withPassword:error:]. The decryption password is '9fe4a0c3b63203f096ef65dc98754243979d6bd58fe835482b969aabaaec57e':
And what is in this encrypted file? A massive list of commands and configuration values.
Reading those these commands confirms the advertised capabilites (e.g. screencapture, etc.) We can also see that it will collect and exfiltrate sensitive user data such as 1Password files, browser login data, keychains, etc:

As Proton persists as Launch Agent, it's trivially to manually remove from an infected system. A slight complication arises as each variant uses a different file name (for both the Launch Agent plist list, and persistent binary). A tool such as KnockKnock, which displays persistently installed software, can be used to identify the malware's Launch Agent plist. For example below, KnocKKnock has detected variant 'C', (/Library/LaunchAgents/com.Eltima.UpdaterAgent.plist):


Once the malicious Launch Agent plist has been determined, one can remove the malware from an infected system via the following steps (here, file naems are specific to variant 'C'):

1. Unload the malware's persistent launch agent via the 'launchctl unload' command
   $ launchctl unload /Library/LaunchAgents/com.Eltima.UpdaterAgent.plist
   


2. Remove the malicious launch agent plist file com.Eltima.UpdaterAgent.plist


3. Remove the malware's persistent binary: /Library/.rand/updateragent.app

XAgent:

XAgent
found:	Feburary, BitDefender/PaloAlto Networks
infection:	via OSX/Komplex
features:	fully-featured backdoor with a propensity for 'intel-related' data (e.g. iOS backups, etc.)
disinfection:	kill process (and remove OSX/Komplex)
writeups:	"XAgentOSX: Sofacy's XAgent macOS Tool" (PaloAlto Networks) "OSX/Proton.B, a brief analysis, at 6 miles up" (P. Wardle/Objective-See) "Dissecting the APT28 Mac OS X Payload" (BitDefender)

OSX/XAgent is APT28/Fancy Bear's fully-featured 2^nd-stage macOS implant, installed via a 1^st-stage implant, OSX/Komplex.

In late 2016, PaloAlto Networks discovered a new macOS backdoor, OSX/Komplex, that was "associated with the Sofacy group [APT28]". In their writeup titled, Sofacy's 'Komplex' OS X Trojan they described it's infection vector, persistence, and features, noting amongst other things: "it is capable of downloading additional files...".

I discussed Komplex both in the Objective-See "Mac Malware of 2016" blog post, as well as in an RSA talk on the same topic:


During my presentation, I noted that it seemed reasonable to assume that Komplex (which is rather a basic piece of malware), was simply a 1^st-stage implant that likely downloaded and executed a 2^nd-stage (more feature-complete), implant on targets of interest. With the discovery of XAgent, this was largely confirmed! Specifically BitDefender who performed a rather indepth analysis on XAgent state:

PaloAlto Networks also echos this noting: "We believe it is possible that Sofacy uses Komplex to download and install the XAgentOSX tool to use its expanded command set on the compromised system."

Thus in other words, XAgent may not have an independent infection vector, but instead relies on OSX/Komplex infections.

As of yet, I have not uncovered anything that indicates that XAgent actually persists. None of the analysis reports (from the AV companies) mentions persistence, and reversing the malware's binary doesn't reveal any (apparent) persistence logic. Could this means its persistence mechanism just hasn't been figured out yet? Possibly. However, I think there may be a more plausible answer, that involves XAgent's relationship with Komplex

Recall that XAgent is downloaded and executed by Komplex. That is to say, it is dependent on Komplex, at least in terms of getting onto macOS systems. Now, Komplex is persistent, via the Launch Agent ~/Library/LaunchAgents/com.apple.updates.plist file:
As the RunAtLoad key is set to true, each time an infected system is rebooted, Komplex (/Users/Shared/.local/kextd), will be automatically (re)executed by the OS. Once Komplex is running, it will check in with it's command & control servers. Depending on the configuration of these servers or tasking from the remote attackers, a command to restart XAgent could perhaps be issued. Or, Xagent could be fully (re)downloaded and (re)executed. This approach would minimize the footprint of XAgent, as persistence events (i.e. the creation of a Launch Agent plist file) is both 'noisy' and trivial to detect.

Another scenario that could explain the lack of persistence may be that the attackers did not need (nor want) XAgent to persist. Running it once (via Komplex), collecting all data of intelligence value, then (possibly) issuing a command to delete the XAgent binary would certainly reduce the likelyhood of its detection. As 2^nd-stage implants such as XAgent usually represent a significant development effort (both in terms of time and cost), attackers will often take steps (such as uploaded/execute/delete) to prevent their detection and ensure their longevity!

XAgent is a fully-featured macOS backdoor, with a propensity for the collection of data that may hold intelligence value. For example, dumping the Objective-C class information via jtool, we see classes and methods responsible for keylogging, app injection, screen capturing, password stealing, and even discovery of iOS backups:
Taking a peak at the malware's decompilation for the 'checkBackupIosDeviceFolder' method reveals it invoking popen to execute ls -la ~/Library/Application\ Support/MobileSync/Backup/. This will, as its name suggests, check (or list) and iOS backups stored on the infected Mac. Obviously iOS backups contain an (unparalled?) wealth of data and information!
Note: for an interesting connection between XAgent and the Italian HackingTeam, see Objective-See's blog post, From Italy With Love? Finding HackingTeam Code in Russian Malware.

In terms of other features, as shown in BitDefender's report, "Dissecting the APT28 Mac OS X Payload", XAgent unsurprisingly also supports more prosaic commands:



As XAgent does not appear to persist itself, removing it simply involves terminating the backdoor and deleting its binary. Unfortunately, the malware contains logic to generate a random path and name for itself, so figuring out the location of the backdoor at first, seems complicated. Below is the decompilation of the generateRandomPathAndName method, which is responsible for implementing this logic:
As can be seen, the malware will randomly generate a (sub)directory and name for itself. However as the path is not fully randomized (i.e. it starts with ~/Library/Assistants/.local/), one can simply look for a running process who's path is prefixed with that directory.

Since ~/Library/Assistants/.local/ is a non-standard directory created by the malware, if one is infected there should only be a single running process running out of this directory:
Kill this process (e.g. kill -9 666), and delete the ~/Library/Assistants/.local/ directory to cleanup an XAgent infection.

As noted though, XAgent is dependent Komplex. Thus, if an XAgent infection is found, check for Komplex as well (details here).

FileCoder (FindZip/Patcher):

FileCoder (FindZip/Patcher)
found:	Feburary, ESET
infection:	Fake 'Patcher' Applications
features:	file encryption for ransom
disinfection:	terminate application
writeups:	"New crypto-ransomware hits macOS" (ESET)

This poorly coded piece of macOS ransomware, encrypts all user files with (pseudo)randomly generated encryption key that is neither saved, nor transmitted to the remote attacker. Fortunately a 'known plaintext attack' can decrypt ransomed files!

It's a well known 'security mantra' that running apps related to pirating software is a terrible idea! And FileCoder (FindZip/Patcher) is a perfect example of why. Distributed via BitTorrent distro sites, this malware masquerades as software able to crack (or patch) popular applications, such as Adobe Premiere Pro and Microsoft Office.

In their report, "New crypto-ransomware hits macOS", ESET researchers provide the following screen shot of the malware ("ostensibly an application for pirating popular software"):


If the user downloads and attempts to run the application (for example to crack Adobe or Microsoft products), Gatekeeper should block the malware. This is due to the fact, that though the malware is signed it is done so 'ad-hoc' - meaning it is not signed by Apple (or by an Apple Developer ID). This can be seen via jtool:
Or, if one prefers a UI application to view signing information, my WhatsYourSign Finder extension, will display this information as well:


Now, if the user disables Gatekeeper, or explicitly agrees to allow the malicious application to execute, they will become infected.

As is often the case with ransomware, which has no need to persist (it simply encrypts users' files, then exits), FileCoder makes no effort to install itself persistently. From the malware author's point of view, avoding the need to persist simplifies the malware creation process.

FileCode does one thing; encrypt user files for ransom. When executed it display a window with a 'START' button:


Clicking this button executes the function, sub_100001f50. Extracting strings from this massive function reveals its likely purpose; encrypting user files:
Running a process monitor (such as my open-source ProcInfo tool), confirms the malware's malicious behavior. Specifically we can see it executing the built-in find utility to, well, find user files, then executing the zip utilty, with the -P flag create a password protected zip file (password here, gpcwPophFOZQjMDUnfQoqv9Ry):
Once the ransomware as encrypted user files (under /Users and /Volumes), a README!.txt can be found on the desktop. Opening this, reveals the ransom instructions:


As the key generated to encrypt the user files is generated (pseudo)randomly and neither stored or transmitted to the remote attacker, the file won't be 'decryptable' even if the user pays the bitcoin ransom.

Luckily, Sophos describes a trivial method to decrypt the ransomed files! In short, the encryption scheme used by zip to create password protected archives, is suspectible to a known plaintext attack. Since the malware 'depends' on zip to encrypt the user files, the whole ransoming scheme falls apart. Win one for the users!

As the malware doesn't persist, there really isn't much to do to disinfect a system besides terminate and delete the ransomware:
Of course by this time, (if the ransomware is already running) it's likely too late!

Dok (Retefe)
found:	April, CheckPoint
infection:	emails campaign with malware attached
features:	web traffic MitM (to steal banking info)
disinfection:	remove login item or launch agent(s)
writeups:	"OSX Malware is Catching Up & wants to Read Your HTTPS Traffic" (CheckPoint) "New OSX.Dok malware intercepts web traffic" (MalwareBytes)

A macOS port of Windows 'Retefe' banking trojan, this malware installs a malicious proxy server to Man-in-the-Middle (MitM) all web traffic in order to sniff out victims' bank credentials and manipulate traffic to gain access to financial accounts.

As noted by the security researchers at CheckPoint who originally discovered OSX/Dok (read their writeup here), Dok targets users via an email: "[Dok] is the first major scale malware to target OSX users via a coordinated email phishing campaign."

Below is a screen-capture of one such phishing email, targeting German users (image credit CheckPoint):


Attached to the malicious emails, is a zip file (Dokument.zip), that contains the malware. Users that naively believe the instructions in the email and unzip Dokument.zip, will find a single file named Dokument:


By using a (rather pixelated) icon that mimics Apple's 'Preview' application, that attacker clearly hopes to trick the user to opening this file. By using WhatsYourSign we can see this file is not a document, but in fact a signed application (though now Apple has revoked the certificate):


If the user opens the application, and clicks thru the standard "is an application downloaded from the Internet. Are you sure you want to open it?" warning dialog, they will become infected.

Somewhat interestingly, OSX/Dok persists in two phases. First as a Login Item, then as Launch Agents.

When Dok is (naively) launched by the user, it will executed logic to persist as a Login Item. As their name implies, Login Items will execute an application when the user logs in. Apple describes how to create a Login Item both manually and programmatically.

To persist itself as a Login Item, Dok will invoke the AddLoginScript method:
As can be seen in the AddLoginScript decompilation, Dok utilizes AppleScript to create the Login Item. This approach is somewhat simpler than adding a Login Item purely via APIs (such as SMLoginItemSetEnabled).

The installed Login Item will show up in the UI (image credit CheckPoint):


In order to elevate its privileges to persist its payload (described below), Dok displays a fake (full-screen) update window that contains a single 'Update All' button. When this button is clicked, the malware will display an authorization dialog:


It's likely that the user will enter their credentials at some point, since as noted by Thomas Reed: "[the screen will] remain stubbornly on the screen and will come back on restart".

Armed with the user's credentials the malware will perform various nefarious actions, including the creation of two persistent Launch Agents property lists: com.apple.Safari.pac.plist and com.apple.Safari.proxy.plist. The code for this can be found in the InstallTor method:
Dumping either of these plists, we can see the malware has persisted socat (a well-known proxy):
As the RunAtLoad key in the plists has been set to true, socat will be automatically started each time the system is rebooted and the user logs in.

Thomas Read, who also analyzed OSX/Dok, describes the malware's main goal:
Installing a proxy to MitM traffic is a common technique found in Windows banking trojans - who try to steal users' banking credentials. As previous noted, Dok appears to be a Mac port of the Windows banking trojan 'Retefe.'

Let's take a closer look at how the malware is able to proxy all web traffic on an infected host.

First the malware kills all running browsers, by executing the CloseAllBrowsers method: It then installs a new root certificate, "which allows the attacker to intercept the victim’s traffic using a Man in The Middle (MiTM) attack" (Checkpoint). In order to install this certificate, the malware simply executes the security command, with the add-trusted-cert flag. Looking at the InstallCert method we can see this logic:
Here's the installed certificate (image credit: CheckPoint):


Once the attacker's certificate has been installed, the malware invokes the InstallTor method. Unsurprisingly, this installs tor. In order to install this (and other utilities most notable the proxy, socat), the malware first downloads and installs Homebrew:
This methods also installs the aforementioned Launch Agent plist files, which ensure the proxy, socat, is always running.

Finally, the malware modifies the infected host's network settings in order to set up a proxy who's address is (dynamically) specified via a remote proxy auto-configuration (PAC) file. This is accomplished by decoding then executing a base64-encoded string (which turns out to be a script which re-configures network settings):
One can see this malicious network reconfiguration via the Network pane in System Preferences (image credit: CheckPoint):

Once the malware has installed the attacker certificate, installed tor and socat, and reconfigured the infected host's network settings, all the user's traffic will be proxied thru the attacker's infrastructure. This is perhaps more eloquently stated by the CheckPoint researchers:
So why redirect the user's traffic? Well, any number of reasons. However, as OSX/Dok is a port of a Windows banking trojan (Retefe), its main goal is to extract user's banking credentials from the redirected traffic, or manipulate traffic in order to gain access to financial accounts. For more information on this methodology, check out CheckPoint's follow-up report: OSX/Dok Refuses to Go Away and It's After Your Money.

Fully cleaning up a OSX/Dok infection is somewhat difficult due to the multitude of changes it makes to an infected system. (As Thomas Reed notes, "there are many leftovers and modifications to the system that cannot be as easily reversed.").

First, if it still exists, remove the malware's initial Login Item ('AppStore').

Then, delete the two Launch Agents"

1. Unload the malware's persistent launch agent via the 'launchctl unload' command:
   $ launchctl unload ~/Library/LaunchAgents/com.apple.Safari.pac.plist
   $ launchctl unload ~/Library/LaunchAgents/com.apple.Safari.proxy.plist
   


2. Remove the malicious launch agent plist files: ~/Library/LaunchAgents/com.apple.Safari.pac.plist
   ~/Library/LaunchAgents/com.apple.Safari.proxy.plist

Next, remove the attacker's certificate that was added to the system, using the Keychain Access application (certificate name: COMODO RSA Extended Validation Secure Server CA 2).

Finally remove tor and socat via HomeBrew (i.e. $ brew rm FORMULA). If didn't have HomeBrew already installed - meaning the malware installed it, that can be removed as well.

Honestly, if infected with OSX/Dok it's suggested you just fully re-install macOS!

Snake
found:	May, Fox-IT
infection:	trojanized Flash Installer
features:	currently in development, but likely 'standard' cyber-espionage capabilities
disinfection:	remove launch daemon
writeups:	"Snake: Coming soon in Mac OS X flavour" (Fox-IT) "Snake malware ported from Windows to Mac" (MalwareBytes)

An in-progress port of the highly sophisticated Windows 'Snake' cyber-espionage persistent implant, the Mac version has yet to be seen (publicly) wild nor is fully-featured....yet!

Fox-IT, the company that originally discovered the Mac version of Snake, note the following:
Since (at the time of discovery), the macOS version of Snake is likely not yet operational, it is not surprising that has yet to be seen infecting Mac users in the wild.

What we do know, is that Snake is packaged in a trojanized Adobe Flash installer:


This infected installer application is (re)signed, to ensure that it won't be blocked by Gatekeeper (in its default setting):
As shown by WhatsYourSign, this certificate was revoked by Apple:


Since the format of the trojaned application bundle is rather unstandard (i.e. it's missing the Contents/MacOS/ directory) it is not immediately clear what binary will be executed when the application is launched. However, by dumping the application's Info.plist file, and looking at the value of the CFBundleExecutable key, we can see it's a binary named Install:
The Install is a simple binary whose main job is to execute a script, install.sh, via the "do shell script [script] with administrator privileges" AppleScript command:
Executing this AppleScript command will first cause the system to display a standard authentication prompt (due to the "with administrator privileges"):


As installers, such as Flash, typically display such authentication prompts, it's likely the user will naively enter their credentials. At this point, the install.sh script will be executed with elevated privileges.

Let's dump the install.sh script:
Easy to see it:

• copies several files (queue, installdp, etc.), to the /Library/Scripts directory
• persists the com.adobe.update file as a Launch Daemon
• executes the installd.sh script
• kicks off the legitimate Flash installer, Install Adobe Flash Player

The persistent part of the infection, is the com.adobe.update Launch Daemon. As it's a binary plist file, dump its contents with the plutil utility (using the -p commandline flag):
As the KeepAlive key has been set to 1 (true), the Launch Daemon will be automatically started everytime the infected system is rebooted. Looking at the ProgramArguments array, we can see persisting the installd.sh script:
As noted by the Fox-IT researchers, this "script checks if installdp is already running, if not it will start with /Library/Scripts/queue#1 n." In other words, the installdp binary -which is the malware's main component, will be automatically started whenever the OS is initialized.

This macOS port of Snake appears to be a test (or debug) build. The Fox-IT write up highlights various strings embedded within the installdp that backup this claim:
They also note that though Snake binaries contain obfuscated strings (possibly commands or config data?), in the macOS version there are only "placeholders that are yet to be replaced by the actual values, which is another indication that this Snake binary is not yet ready to deploy to targets."

So what does the Snake actual do? This is a good question! First, if we look at the Windows version (which has been well studied by the anti-virus industry), holy $h!t its legit! Seriously, go read the reports about this malware and it's operations:

• "The Epic Turla Operation" (Kaspersky)
• "Satellite Turla: APT Command and Control in the Sky" (Kaspersky)
• "The Snake Campaign" (BAE Systems)

0days, successful penetration of classified networks, C&C via satellite link hijacking....in a way, stunningly beautiful!

in Back to Mac version though...honestly it's tough to know the extent of it's capabilities.

First, as already noted, it does not appear to be ready to deploy. Thus it's possible that features or capabilities have not yet been implemented or configured in the macOS version. For example, the malware contains a function named, hide_module. Looking at it's disassembly however, we can see it's not (yet?) implemented:
Second, as Snake is part of a incredibly sophisticated cyber-espionage operation, we've seen operators (on the Windows side of the house), utilize capabilities in a modular fashion. Looking at function names within the installdp binary, it appears to support a similar modular-based plugin architecture:


This means that analyzing any single component of malware individually (i.e. just the installdp binary), may be akin to looking at a single piece of a complex puzzle. Rather hard to get a full understanding.

Finally, the Fox-IT report states that:
And while the macOS sample does contain such a queue file, I am not sure how to decrypt or understand it fully. Note that the Fox-IT researchers dump some its content and extract "transport chains":
However, we can still get some insight into the malware's features. For example there are various functions in the malware (name: snake_cmd*), that appear to support standard backdoor features or capabilities such as reading/writing files, executing commands, listing running processes, and surveying an infected system:


Taking a closer look, say at the snake_cmd_kill command, we can see that invokes the kill API to terminate a process:
The implant also appears to support more advanced features, such as the ability to execute libraries directly from memory, via the NSCreateObjectFileImageFromMemory and NSLinkModule APIs:
For more info on directly executing binaries from memory, see: "Running Executables on macOS From Memory"

Finally, if you're still doubting the potential of this malware, note that it "car-service.effers.com" is the domain (as pointed out by Fox-IT) which the macOS version of Snake is configured to utilize for HTTP network transport. Why is this interesting? Because "the resolving IP belongs to a Satellite communications provider" ... did somebody say satellite-based C&C?

As this version of OSX/Snake simply persists as a Launch Daemon, it's trivial to removed from an infected system.

1. Unload the malware's persistent Daunch Daemon via the 'launchctl unload' command:
   $ launchctl unload /Library/LaunchDaemons/com.adobe.update
   


2. Remove the malicious Launch Daemon plist file /Library/LaunchDaemons/com.adobe.update


3. Remove the malware's persistent script (installd.sh), and binary (installdp), and queue file (queue), from the /Library/Scripts directory

Honestly though, if you're infected with OSX/Snake - due to the sophistication of the actors associated with this malware, you should at a minimum fully re-install macOS! Better yet, just burn everything down and start over.

MacSpy
found:	June, Catalin Cimpanu (@campuscodi)
infection:	n/a
features:	fully-featured backdoor, with the ability to collect keystrokes, screenshots, audio, & more.
disinfection:	remove launch agent
writeups:	"MacSpy: OS X RAT as a Service" (AlienVault) "New Mac Malware-as-a-Service offerings" (MalwareBytes)

MacSpy is (AFAIK) the first 'Malware-as-a-Service' (MaaS) for macOS. Offered on the 'dark web' it's a fairly standard backdoor (RAT), though does support a wide range of features such as collecting keystrokes, screenshots, audio, clipboard data, and more.

As MacSpy is offered by the author as a pre-built binary (i.e. 'Malware-as-a-Service'), it is up to the consumer of the malware to find a way to infect target computers. As noted in AlienVault's writeup, the malware author suggests manually copying it to target mac, then manually executing it:


Using WhatsYourSign, we can see this malware's binary image is not signed:


As such, Gatekeeper should block the malware from executing - unless the user (or attacker locally installing the malware) explicitly agrees to allow the unsigned malicious code to execute.

MacSpy persists as a LaunchAgent. When executed, the malware will dynamically build the launch agent plist (see sub_10008c510):
This plist is saved to ~/Library/LaunchAgents/com.apple.webkit.plist. As the RunAtLoad key is set to true, the value in Program key will be executed automatically whenever the user logs in. The value of this key is set to ~/Library/.DS_Stores/updated, which is a persistent copy of the malware:

MacSpy claims to be the "most sophisticated Mac spyware":


However Thomas Reed notes that in reality "MacSpy is fairly simple spyware, which gathers data into temporary files and sends those files periodically back to a Tor command & control (C&C) server via unencrypted http."

One thing is for sure, MacSpy does supports a decent set for features designed to 'spy' or collect data about infected systems. Its author kindly documented its features:


A paid version of the malware apparently contains even more features, such as full exfiltration capabilities, ransomware abilities, and access to social media data:



Other 'features' of the MacSpy include anti-debugging and anti-VM logic. As AlienVault notes in their writeup, this includes:

• invoking ptrace with PT_DENY_ATTACH to prevent debuggers (such as lldb) from attaching


• invoking sysctl with KERN_PROC and KERN_PROC_PID, then checking if the P_TRACED flag is set, to detect runtime debugging


• checking to make sure it's executing on a system with at more than one CPU, and least 4GB of memory (on most default virtual machine images, this check will fail).


• checking to make sure it's executing on a machine with a model contain 'Mac'. On a virtual machine, this check will fail:

    $ sysctl hw.model
    hw.model: VMware7,1

In terms of exfiltration, MacSpy utilizes Tor. The malware ships with various legitimate Tor binaries (named webkitproxy and libevent-2.0.5.dylib) that allow it to connect to the Tor network. Specifically it sets up a local Tor proxy and utilizes curl in order to route all it's traffic to it's Tor-based C&C server.

Here's an example of MacSpy exfiltrating various survey data (stored by the malware in ~/Library/.DS_Stores/data/tmp/SystemInfo):

MacSpy can easily be removed from an infected system, via the following steps:

1. Unload the malware's persistent launch agent via the 'launchctl unload' command:

     $ launchctl unload ~/Library/LaunchAgents/com.apple.webkit.plist
   



2. Remove the malicious launch agent plist file ~/Library/LaunchAgents/com.apple.webkit.plist


3. Remove the directory, /Library/.DS_Stores/updated, created by the malware that contains it's persistent backdoor and other components.

MacRansom
found:	June, Fortinet
infection:	n/a
features:	persistent ransomware
disinfection:	remove launch agent
writeups:	"MacRansom: Offered as Ransomware as a Service" (Fortinet) "MacRansom: Analyzing the Latest Ransomware to Target Macs" (Objective-See)

MacRansom is the the first 'Ransomware-as-a-Service' for macOS, that aims to encrypt (ransom) all user's files. Likely created by the same author who coded up MacSpy, it was similarly offered on the 'dark web' for download.

MacRansom is offered by the author, on Tor, as a pre-built binary (i.e. 'Malware-as-a-Service'):


It is up to the consumer of the malware to find a way to infect target computers.

The Fortinet researchers corresponded with the malware author who noted that in order to infect a victim that malware should be run (manually) off a USB stick:


Rather lame...but of course 'consumers' of the malware could deploy it in other manners (e.g. email attachments, etc.).

MacRansom persists as a LaunchAgent. It does this by:

1. Copying itself to ~/Library/.FS_Store


2. Decoding an embedded plist and writing it out to ~/Library/LaunchAgents/com.apple.finder.plist:
   cat ~/Library/LaunchAgents/com.apple.finder.plist
   
   <plist version="1.0">
   <dict>
     <key>Label</key>
     <string>com.apple.finder</string>
     <key>StartInterval</key>
     <integer>120</integer>
     <key>RunAtLoad</key>
     <true/>
     <key>ProgramArguments</key>
     <array>
       <string>bash</string>
       <string>-c</string>
       <string>! pgrep -x .FS_Store && ~/Library/.FS_Store</string>
     </array>
   </dict>
   </plist>
   

As the 'RunAtLoad'' key is set to 'true' the malware will be automatically started whenever the user logs in. Specifically the OS will execute the value of the 'ProgramArguments' key: bash -c ! pgrep -x .FS_Store && ~/Library/.FS_Store. This command will first check to make sure the malware isn't already running, then will start the malware (~/Library/.FS_Store).

Lucky for Objective-See users, BlockBlock will alert you about this persistent attempt:


As the malware first attempts to persist before encrypting any files, clicking 'Block' on the BlockBlock alert will stop the malware before it's done any damage :)

As it's name suggest, MacRansom will ransom (encrypt) users files. Once up and running it checks to see if it's hit a 'trigger' date. That is, it checks if the current time is past a hard-coded value. According to the Fortinet report, this is set by the malware author (part of the 'ransomware as a service'). If the current time is before this date, the malware will not encrypt (ransom) any files, and instead will exit:


However, if the trigger date has been hit, ransoming commences! Specifically at address 0x000000010b4eb5f5, the malware executes the following, via system to begin encrypting the user's files:
What does this command do?
First, returns a list of user files that are readable and bigger than 8 bytes. Then these files will be passed (to a new instance) of the malware, in order to be encrypted! We can observe this encryption via a utility such as fs_usage:
The actual encryption routine of the malware begins at 0x0000000100002160. This function is invoked indirectly via a call to 'pthread_create()':


As noted by Fortinet, the encryption is not some RSA-based scheme, but rather uses a symmetric cryptographic algorithm. Unfortunately (for users) though there is a static key (0x39A622DDB50B49E9), Joven and Chin Yick Low state that for each file the key is "permuted with a random generated number." Moreover, this random permutation is not saved nor conveyed to the attacker.

Thus it appears that once encrypted, the files are pretty much gone for good (save for a perhaps a brute force decryption attack).

Good news, RansomWhere? can generically detect at block this attack:



MacRansom can easily be removed from an infected system, via the following steps:

1. Unload the malware's persistent launch agent via the 'launchctl unload' command:

     $ launchctl unload ~/Library/LaunchAgents/com.apple.finder.plist
   



2. Remove the malicious launch agent plist file ~/Library/LaunchAgents/com.apple.finder.plist


3. Remove the directory, /Library/.FS_Store/. This directory was created by the malware and contains it's persistent binary and other components.

Pwnet
found:	August, SentinelOne
infection:	trojanized 'CS:GO hack'
features:	cryptocurrency miner
disinfection:	remove launch daemon and miner
writeups:	"Osx.Pwnet.A - CS: GO hack and sneaky miner" (SentinelOne)

Arnaud Abbati (@noarfromspace) who uncovered Pwnet, describes it as a, "trojan that could mine CryptoCurrencies without user consent" embedded in a hack for Counter-Strike: Global Offensive.

Arnaud notes that the infection vector for Pwnet begins at vlone.cc. Though this portal now appears offline, in the past users could login in to download a hack for the popular game, 'Counter-Strike Global Offensive'.

The main binary, (vhook) is not signed:


...and must be run with root privileges:
In the background, Arnaud states that, "vHook also sneaky downloads and extracts https://vlone.cc/abc/assets/asset.zip as fonts.zip to /var/, changes directory to /var and runs sudo ./helper &."

This binary, helper downloads yet more components (such as com.dynamsoft.WebHelper), which in turn download still more items. (For details see Arnaud's writeup: "Osx.Pwnet.A - CS: GO hack and sneaky miner"). The end result is OSX/Pwnet being persistently installed.

The final action of the installer, is to download a binary named WebTwainService (from https://www.vlone.cc/abc/assets/d.zip), is persisted as a launch daemon via com.dynamsoft.WebTwainService.plist:
As the 'RunAtLoad' key is set to true, the value in the 'ProgramArguments' (/var/.log/WebTwainService), will be automatically executed by the OS each time the infected computer is restarted.

The main goal of Pwnet is to mine cryptocurrency via an official minergate command line tool.

First, the malware's persistent daemon, WebTwainService, executes the com.dynamsoft.webhelper binary:
As Arnaud notes in his writeup, com.dynamsoft.webhelper, performs various actions including executing the minergate cli (which Pwnet names: 'com.apple.SafariHelper'):
When the miner 'com.apple.SafariHelper' is executed, it eats up all CPU cycles in order to mine XMR (Monero).

To remove OSX/Pwnet, first unload and remove its persistent launch daemon plist:

Then delete all installed components, which are stored in various 'hidden' directory in under/var/ such as:

• /Library/LaunchDaemons/com.dynamsoft.WebTwainService.plist
• /var/.log/
• /var/.trash/
• /var/.old

Finally if the miner binary ('com.apple.SafariHelper') is running, terminate it!

CPUMeaner
found:	November, SentinelOne
infection:	trojanized pirated applications
features:	cryptocurrency miner
disinfection:	remove launch agent and miner
writeups:	"OSX.CPUMeaner: New Cryptocurrency Mining Trojan Targets Macos" (SentinelOne)

OSX/CPUMeaner is a cryptocurrency miner that targets macOS users. Arriving in pirated applications, it mines Monero.

Arnaud Abbati (@noarfromspace) who uncovered CPUMeaner, provides an in-depth technical writeup on the malware.

Arnaud notes that the infection vector for CPUMeaner can come from a variety of sources.


At this time, Apple has revoked the certificate used to sign (at least some instances of) the malware:



When the user runs the malicious installer (.pkg), it will execute the package's 'post install' script. Using the neat 'Suspicious Package' application, we can statically examine this script:


In short, it persists CPUMeaner as a launch agent via the /Library/LaunchAgents/com.osxext.cpucooler.plist file. As the 'RunAtLoad' key is set to true, whenever the system is rebooted and the user logs in, whatever is specified in Program key will be automatically executed by the OS. Examining this key, we can see it's set to /Library/Application Support/CpuCooler/cpucooler:

The main goal of CPUMeaner is to mine cryptocurrency. Arnaud determined that cpucooler is a "custom builds of XMRig version 2.3.1, an open-source Monero CPU miner"

Though the author added some extra functionality to obfuscate strings, Arnaud wrote a deobfuscation python script:
These deobfuscated strings (plus binary analysis) confirm that binary, cpucooler is a cryptominer, which will "mine on MinerGate XMR pool for jeffguyen@mail.com."

Besides pegging your CPU to mine cryptocurrency, CPUMeaner also pings a remote server, jumpcash.xyz with some installation data. This may include infected system's serial number - as grabbed by the output of the (deobfuscated) ioreg command:

To remove CPUMeaner, first unload and remove its persistent launch agent plist:
Then delete the miner binary, /Library/Application Support/CpuCooler/. Finally if the miner binary (cpucooler) is running, terminate it!


Thanks
I briefly want to thank the following fellow malware analysts/macOS reversers! Their research and assistance has been paramount to my own research, conference talks, and the advancement of my macOS knowledge:

• @0xAmit
• @Morpheus______
• @noarfromspace
• @osxreverser
• @theJoshMeister
• @thomasareed