Red Hat Helps Pave Road to Open Hybrid Cloud for APAC Enterprises
June 25, 2019
See how your code actually executes with Stackdriver Profiler, now GA
June 26, 2019
Last week was a busy week for macOS malware. Along with a Gatekeeper POC being deployed in the wild only days after being published and a hulking 2.5GB cryptominer on the loose stealing resources from those tempted by pirate software, there was also the big reveal of two Firefox zero-days being used in the wild to deliver at least two different kinds of malware. These both turned out to be new variants of old friends: OSX.Netwire/Wirenet and OSX.Mokes, a backdoor that contains code indicative of recording user behaviour and exfiltrating it to a server in encrypted form.
In this post, we’ll review how the two Firefox zero days were used to achieve remote code execution, discuss the malware dropped by threat actors leveraging these zero days in the wild, and reveal six unpublished IOCs used by one of the backdoors.
FireFox 0-Days Used in Targeted Attacks
On April 15, Samuel Gross, a researcher from Google’s Project Zero, reported a zero day vulnerability in the Firefox browser that could lead to a remote code execution (RCE) exploit. It seems Mozilla didn’t get around to fixing the bug until the Coinbase security team reported it being actively exploited in an attack against their network on June 17.
According to Mozilla, CVE-2019-11707 was fixed on June 18, 24 hours after Coinbase’s report, noting that they were aware of “targeted attacks” occurring in the wild.
Interestingly, Gross had noted that any threat actor trying to exploit the Array.pop type confusion to achieve remote code execution would still need a separate sandbox escape if they wanted to do anything more ambitious than universal cross-site scripting (UXSS). However, a second Firefox zero-day achieving exactly such a sandbox escape was also seen by Coinbase during the attack on their servers. Firefox subsequently released a second update two days later to also address that.
The sandbox escape leverages the fact that browsers are typically not themselves sandboxed, but rather run web pages as separate processes in a sandbox container as seen in the following image.
This means that attackers should not be able to run malicious code from a website to do things like read, write or execute files on the local disk as the webcontent is effectively separated both from the parent process and the machine at large.
However, the sandbox escape using Prompt:Open exploits a flaw in the IPC messaging between the parent and child processes, effectively allowing the child process to instruct the non-sandboxed parent to open content of the child’s choosing. Combined with CVE-2019-11707, this allows attackers to achieve arbitrary code execution.
Exploiting these vulnerabilities, the threat actors targeting Coinbase dropped two separate pieces of malware, as revealed by Coinbase researcher Philip Martin.
The second of the two hashes
23017a55b3d25a2597b7148214fd8fb2372591a5
is a variant of Netwire.A/Wirenet.C, and surprisingly is still detected by reputation agents, including macOS’s built-in XProtect, using signatures created back in 2016.
The first one, however, is far more interesting. This 13MB binary is a cross-platform backdoor utilitizing the Qt framework and appearing to target both macOS and Windows devices.
Due to its close similarities to the Mokes.A malware, first discovered by Kaspersky in 2016, researchers have dubbed this sample Mokes.B. Let’s take a closer look at it.
VirusTotal Doesn’t Tell You Everything
The discovery of Mokes.B seemed to cause quite a stir as not only was it dropped by two zero days, but its own reputation was initially unknown on VirusTotal. When we first looked at it, none of VirusTotal’s detection engines recognized it.
VirusTotal show the detection status of a number of engines running on their own servers, and screenshots like this can be real attention grabbers on social media. However, it’s important to understand that what such an image shows is not what is often believed. Specifically, the lack of detections on VT does not necessarily mean no security solutions are detecting the malware in the wild.
What it does show is that the signature-based engines supplied to VirusTotal by AV vendors did not recognize the malware. AI-powered behavioral engines like those used in SentinelOne, however, are not available to VirusTotal and the detection status on VT does not represent how SentinelOne works on a real endpoint.
In fact, we tested OSX.Mokes.B very early on and found that our behavioral engine immediately alerted on the executable, reported on the persistence agent it dropped and revealed further IOCs that, to our knowledge, have yet to be recorded by other researchers.
How We Detect OSX.Mokes.B
Here is how the attack appears in the SentinelOne management console, along with relevant links to MITRE ATT&CK framework, Recorded Future and VirusTotal.
On the agent side, running the attack code produces a notification alert for the end user, but the really interesting details are provided in the console for the IT admin or security team. The raw log reveals that aside from the executable and persistence agent, another file is dropped in the User’s ~/Library/Application Support folder.
This turns out to be a zero byte file with a hardcoded MD5 hash for a file name. The purpose of this file seems to be to track which of the six hardcoded malware names have already been used in the infection. To see how this works, let’s take a closer look at the behavior.
As other researchers have noted, both the original Mokes.A and the new Mokes.B variant use six hardcoded sets of names for the malware and its persistence agent.
These sets consist of one or more folder names and a file executable name dropped in the ~/Library folder. The executable name is also the same as the name of the ~/Library/LaunchAgents plist item used for persistence.
1. ~/Library/App Store/storeaccountd 2. ~/Library/com.apple.spotlight/Spotlightd 3. ~/Library/Skype/soagent 4. ~/Library/Dropbox/quicklookd 5. ~/Library/Google/Chrome/accountd 6. ~/Library/Firefox/Profiles/trustd
However, what does not appear to have been noted by previous researchers is that as the malware is dropped, a zero byte tracking file is also dropped in ~/Library/Application Support folder. The name of the tracking file depends on which of the six set of malware names has been dropped.
The empty tracking files have md5 hash strings for names and are correlated with the malware names as follows:
1. ~/Library/Application Support/c8030abb9b95ba961a1c8ebcab43c862 # written when App Store/storeaccountd is used 2. ~/Library/Application Support/e5d4af62734babc54f43d8a11f640be2 # written when com.apple.spotlight/Spotlightd is used 3. ~/Library/Application Support/ece82aa35ebd3223504634661d07bd41 # written when Skype/soagent is used 4. ~/Library/Application Support/bfad2737fe8ea987c1cc5f8f38031677 # written when Dropbox/quicklookd is used 5. ~/Library/Application Support/474d33349c808c86f0039d6130eb1c3e # written when Google/Chrome/accountd is used 6. ~/Library/Application Support/c494e0efe766d657a55a1fd37f5d94c1 # written when Firefox/Profiles/trustd is used
However, the hash string used in the name of the tracking file is not related to the md5 hash of either the plist or the executable dropped and appears to be arbitrary.
We noted that these tracking files are only written once, when the malware is first dropped, and are not rewritten by the persistence agent if they are deleted.
What Does Mokes.B Actually Do?
Mokes.B is a backdoor that has functions related to exfiltrating user data, keylogging, and capturing screenshots from the victim’s device.
Mokes.B reaches out to the following IP address, which belongs to a server located in Germany. The location is shown in the SentinelOne management console:
185.49.69.210
Using netcat, we can see that the server is up and running. However, we weren’t able to initiate any communication from the server to our infected machines. Given the recent media attention, it is unsurprising that the attackers are no longer interested in responding.
Conclusion
The use of recently discovered and hitherto unpublished Firefox zero days along with cross-platform malware indicates a threat actor with some expertise and resources. With that in mind, it seems reasonable to conclude that this won’t be the last we hear of them. Given that the only known use of this attack in the wild was against a cryptocurrency exchange, we can also speculate that the perpertrators were more likely criminal than political (although the two are not necessarily mutually exclusive).
All Firefox users are urged to update to the latest version, and enterprise users should ensure they have a capable next-gen security solution in place. As our analysis has shown, SentinelOne’s behavioral AI can not only detect these kinds of attacks without relying on reputation, it can also reveal further IOCs that other solutions may miss. If you’re not already protected by SentinelOne, try a free demo to see how we can protect your organization.
Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.
