Digita Security

Cybersecurity solutions for the

  • modern
  • mobile
  • independent
  • innovative
  • enterprising

macOS workforce

June 20, 2019

Burned by Fire(fox)

a firefox 0day drops a macOS backdoor (part 1)
by Patrick Wardle

At Digita, we don’t rely on known malware signatures in order to detect malicious behavior. To limit the impact of 0days, we provide consistent defense for the enterprise even as the anatomy of malware evolves.

Digita’s enterprise security offering, GamePlan, leverages an advanced library of behavioral heuristics and Apple’s game engine to create a powerful platform that translates malware research into the detection of attacker techniques. As we will demonstrate in this blog, GamePlan’s real time monitoring of the macOS fleet is capable of detecting OSX.Netwire.A behaviors without relying on the now-known signature. With the power of GamePlan, we can flag the fact that an unsigned binary had persisted (twice!)

For more info, checkout: “Leveraging Apple’s Game Engine for Advanced Threat Detection

If you would like to see a demo, you can request one on the homepage of our website.


A little over a week ago, I received an email from a user who stated:

“Last week Wednesday I was hit with an as-yet-unknown Firefox 0day that somehow dropped a binary and executed it on my mac (10.14.5)

Let me know if you would be interested in analysing the binary, might be something interesting in there wrt bypassing osx gatekeeper.”

Of course, given our mission at Digita, I was inherently intrigued and ready to get to work 😅

📝 👾 Want to play along?

I’ve shared the OSX.NetWire.A sample (password: infect3d)

…please don’t infect yourself!

A Firefox 0day

When the user contacted me, there wasn’t much information about the Firefox 0day exploit used in the attack. However now, more information is readily available!

First, I was able to obtain an email that (said user claimed) was related to the attack.

Dear XXX,

My name is Neil Morris. I'm one of the Adams Prize Organizers.

Each year we update the team of independent specialists who could assess 
the quality of the competing projects: http://people.ds.cam.ac.uk/nm603/awards/Adams_Prize

Our colleagues have recommended you as an experienced specialist in this 

We need your assistance in evaluating several projects for Adams Prize.

Looking forward to receiving your reply.

Best regards,
Neil Morris

Even if an attacker has a browser 0day exploit, they still have to find a way to deliver it to the target.

When individuals are targeted, the delivery mechanism of choice is often an email that contains links to a malicious site (which will “throw” the exploit when the user visits said site).

Unfortunately the link (people.ds.cam.ac.uk/nm603/awards/Adams_Prize) currently returns a 404 Not Found:

$ curl http://people.ds.cam.ac.uk/nm603/awards/Adams_Prize
<title>404 Not Found</title>
<h1>Not Found</h1>
<p>The requested URL /nm603/awards/Adams_Prize was not found on this server.</p>
<address>Apache/2.4.7 (Ubuntu) Server at people.ds.cam.ac.uk Port 80</address>

Of course it’s possible that the site will only serve up (“throw”) the exploit if the user browses to the site via a vulnerable version of Firefox, or perhaps from a certain IP address, etc. More than likely though, the attacker has moved on, and taken down the exploit site.

Though I don’t have access to the exploit code, the user was able to provide me with persistent malware the exploit installed on the system (named Finder.app). Woohoo!

The remainder of this blog will cover the analysis of this malware (hash: 23017a55b3d25a2597b7148214fd8fb2372591a5).

$ shasum -a 1 ~/Attack/Finder.app/Contents/MacOS/Finder 
23017a55b3d25a2597b7148214fd8fb2372591a5  Finder

Interestingly, a security researcher at Coinbase, Philip Martin, posted an interesting thread on twitter:

Note that the hash mentioned by Phil, 23017a55b3d25a2597b7148214fd8fb2372591a5 matches malicious file which the user sent me. Moreover the user confirmed that he was “involved with a cryptocurrency exchange until fairly recently.” Thus it seems reasonable to assume we’re all talking about the same Firefox 0day.

This 0day, has now been patched as CVE-2019-11707, and covered in various articles such as:

However, the details of the persistent malware used in the attack are scant (non-existent?). The hash was first uploaded on 6-6-2019, so though this issue is patched via firefox there is plenty to uncover to further contribute to the behaviors of malware within the macOS architecture, so let’s dive into that now!

A Persistent Mac Backdoor (OSX.NetWire.A!?)

As noted, the infected user was kind enough to send me the malware (Finder.app) that the attacker persistently installed on the system (via the Firefox 0day).

Within the enterprise, Digita’s GamePlan would quickly detect this applications and flag it as “unsigned”.If you are looking for a tool to run on your personal machine, you can use the open-source “WhatsYourSign” utility to quickly determine it’s an unsigned application:

Searching for the hash (23017A55B3D25A2597B7148214FD8FB2372591A5) on VirusTotal found a exact match and shows that the file was submitted on 2019-06-06 but currently is only detected by one AV engine (Tencent). The behavior of this application being unsigned alone should raise an eyebrow. This is the importance of understanding the malicious or unwanted behaviors versus relying on known-sigantures:

The full application bundle, Finder.app, was just submitted to VirusTotal today.

It is similarly only detected by one AV engine.

Interestingly the engine detecting the malware flags it as OSX.Netwire.

OSX.Netwire (or OSX.Wirenet) was first discovered in 2012(!) by Dr Web. In their writeup “Wirenet: The Password-Stealing Trojan Lands on Linux and OS X” they state that it is “the first Trojan in history to steal Linux and Mac OS X passwords.”

Passwords were stolen via keylogger logic and/or directly from files on disk (i.e. saved browser logins):

$ strings malware/2012/OSX.Netwire



%s/Library/Application Support/Firefox



select *  from moz_logins

But that was OSX.Netwire from 2012. Is this new sample really (still) OSX.Netwire!? I personally had not heard anything about OSX.Netwire since 2012, so decided to poke around.

First, via simple “string” matching, it’s easy to confirm the 2012 sample and the 2019 are in someway related.

For example, note the string: "\x03\x04\x15\x1A\r\nexit\r\n\r\nexit\n\n" in both the 2012 sample:

esi = "/bin/sh";
if(access(esi) != 0x0) {
   esi = "/bin/bash";


eax = write$UNIX2003(*0x140d0, "\x03\x04\x15\x1A\r\nexit\r\n\r\nexit\n\n", 0x15);

and in the 2019 sample:

if(stat("/bin/sh", edi) != 0x0) {
   ebp = "/bin/bash";

write$UNIX2003(ebx, "\x03\x04\x15\x1A\r\nexit\r\n\r\nexit\n\n", 0x15)

…other rather unique strings are also found in both samples.

Whilst chatting about this with one my close (security researcher) friends he noted that this new sample was (already) detected by XProtect.

XProtect is Apple’s rudimentary anti-malware system, baked in to macOS.

For a good overview, see “XProtect Explained: How Your Mac’s Built-in Anti-malware Software Works

I was rather skeptical of this claim (as I didn’t recall any recent XProtect updates for OSX.Netwire), but turns out he was absolutely right!

In 2016, Apple added a Yara signature to detect something called OSX.Netwire.A. The signature (found in /System/Library/CoreServices/XProtect.bundle/Contents/Resources/XProtect.yara) is presented below:

rule NetwireA
        description = "OSX.Netwire.A"
        $a = "exitexit"
        $b = "User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like GeckoAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"
        all of them

Digita’s UXProtect utility can graphically display this signature as well:

We can also utilize UXProtect to confirm this signature (from 2016) still detects the malware used in the Firefox 0day attack:

Wow! kudos to Apple for writing a signature that (IMHO) rather surprisingly detects this “new” threat!

Interestingly Apple’s signature does not detect the sample from 2012 (as it does not contain the User-Agent: Mozilla... string). This is first (of many) indicator that these samples, while somehow related are unsurprisingly not the same.

I’m personally not aware of any (public) details related to this new sample.

Interestingly Intego, in 2016, wrote a brief article about Apple’s XProtect: “Apple Updates XProtect Malware Definitions for NetWeirdRC”.

However, they (and others) all reference or link back to the 2012 sample, which (as already noted) is not detected by Apple’s OSX.Netwire.A YARA signature.

As is often the case, Apple tends to know things which don’t become common knowledge 😭

Or atleast, common knowledge to me:

While the sample from 2012 and 2019 are clearly related, they are also very different. We’ll get into this more in part two of this blog post, when we dive into the capabilities of the (new) malware sample. However in short, the 2012 and 2019 samples have totally different objectives. If I had to guess, they are both written by the same author (or team), but serve unique purposes (i.e. the 2012 sample is only concerned with stealing passwords).

Before we wrap up part one of this post, let’s look at how the new sample, OSX.NetWire.A, persists.

A quick peek at the malware’s disassembly reveals an embedded launch agent plist:

memcpy(esi, "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!DOCTYPE plist PUBLIC \"-//Apple Computer//DTD PLIST 1.0//EN\n\t\"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">\n<plist version=\"1.0\">\n<dict>\n    <key>Label</key>\n    <string>%s</string>\n    <key>ProgramArguments</key>\n<array>\n        <string>%s</string>\n    </array>\n    <key>RunAtLoad</key>\n    <true/>\n    <key>KeepAlive</key>\n    <%s/>\n</dict>\n</plist>");
eax = getenv("HOME");
eax = __snprintf_chk(&var_6014, 0x400, 0x0, 0x400, "%s/Library/LaunchAgents/", eax);

eax = __snprintf_chk(edi, 0x400, 0x0, 0x400, "%s%s.plist", &var_6014, 0xe5d6);

Seems reasonable to assume the malware will persist as launch agent.

However, it also appears to contain logic to persist as a login item (note the call to the LSSharedFileListInsertItemURL API):

eax = __snprintf_chk(&var_6014, 0x400, 0x0, 0x400, "%s%s.app", &var_748C, &var_788C);
eax = CFURLCreateFromFileSystemRepresentation(0x0, &var_6014, eax, 0x1);

eax = LSSharedFileListCreate(0x0, **_kLSSharedFileListSessionLoginItems, 0x0);

eax = LSSharedFileListInsertItemURL(eax, **_kLSSharedFileListItemLast, 0x0, 0x0, edi, 0x0, 0x0);

Hopping into a VM and running the malware, turns out it persists twice! First as launch agent (com.mac.host.plist), and then as a login item.

$ cat ~/Library/LaunchAgents/com.mac.host.plist
    KeepAlive = 0;
    Label = "com.mac.host";
    ProgramArguments =     (
    RunAtLoad = 1;

As the launch agent (com.mac.host.plist) has the RunAtLoad is set (to 1), the OS will automatically launch the specified binary, .defaults/Finder.app/Contents/MacOS/Finder each time the user logs in.

The login item will also ensure the malware is launched. Login items however show up in the UI, clearly detracting from the malware’s stealth:

Is persisting twice better than once? Not really, especially if you are using GamePlan and detecting on both persistence attempts by monitoring launch items and login items.

If you are not an enterprise and would like to defend against these attacks personally, we’re big fans of the Objective-See tools! KnockKnock & BlockBlock which will detect both persistence attempts and can also reveal the infection (after the fact).

For details on persisting as a login item (and the role of backgroundTaskManagementAgent), see my recent blog post on “Block Blocking Login Items” over at Objective-See’s blog page.

Maybe the malware author wanted to be extra extra sure about gaining and/or maintaining persistence!?


In today’s post, we discussed the persistent payload of a rather sophisticated targeted attack against cryptocurrency exchange(s). Via a Firefox 0day, the attackers persistently deployed a macOS binary.

Rather interestingly this malware was OSX.NetWire.A, which bares some relation to a 2012 specimen of the same name. Similarly intriguingly we showed how a signature deployed by Apple in 2016 would detects this malware. Or would it?

Recall that in his original email, the infected user noted that the malware bypassed Gatekeeper. This is actually unsurprising as the malware was delivered by a remote 0day exploit. Gatekeeper only scans applications that have a quarantine attribute set. This is added by the application (i.e. browser) or OS only when the application is downloaded via normal means (i.e. by the user). Exploit code that downloads a payload (such as malicious application) will not set a quarantine attribute (or can remove it), thus will not trigger Gatekeeper!

I highlighted this (well known) fact in a 2016 presentation, “Gatekeeper Exposed; Come, See, Conquer“:

XProtect similarly only operates on files that have the quarantine bit set.

However, this may be changing in macOS 10.15 (Catalina).

Thus, thanks to the infection vector (a Firefox 0day), neither Gatekeeper nor XProtect would protect the user. At Digita Security, we’re proud to be able to detect such infections within the enterprise and help further the privacy efforts being made in Cupertino to enhance the security of the macOS platform.