{ "id": "0a367f72-aa26-43db-b6c3-e5a2a678bb14", "created_at": "2026-04-06T00:21:34.6719Z", "updated_at": "2026-04-10T03:30:33.222204Z", "deleted_at": null, "sha1_hash": "b360b1f1b6439d395246f5583ba2f98df036d4bb", "title": "Burned by Fire(fox)", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1906027, "plain_text": "Burned by Fire(fox)\r\nArchived: 2026-04-05 19:12:14 UTC\r\nBurned by Fire(fox)\r\npart i: a firefox 0day drops a macOS backdoor (osx.netwire.a)\r\nJune 20, 2019\r\nOur research, tools, and writing, are supported by \"Friends of Objective-See\"\r\nToday’s blog post is brought to you by:\r\n📝 👾 Want to play along?\r\nI’ve shared the OSX.NetWire.A sample (password: infect3d)\r\n…please don’t infect yourself!\r\nBackground\r\nA little over a week ago, I received an email from a user who stated:\r\n“Last week Wednesday I was hit with an as-yet-unknown Firefox 0day that somehow dropped a binary\r\nand executed it on my mac (10.14.5)\r\nLet me know if you would be interested in analysing the binary, might be something interesting in there\r\nwrt bypassing osx gatekeeper.”\r\nOf course I was intrigued! …though at the time, was wrapping up our “Objective by the Sea” v2.0 (which you can\r\nread all about here).\r\nNow that the dust has cleared from the conference I wanted to dig into this attack, and analyze the persistent\r\nmalware.\r\nA Firefox 0day\r\nWhen the user contacted me, there wasn’t much information about the Firefox 0day exploit used in the attack.\r\nHowever now, more information is readily available!\r\nFirst, I was able to obtain an email that (said user claimed) was related to the attack.\r\nhttps://objective-see.com/blog/blog_0x43.html\r\nPage 1 of 11\n\n---\ntitle: 404 Not Found\n---\nDear XXX,\nMy name is Neil Morris. I'm one of the Adams Prize Organizers.\nEach year we update the team of independent specialists who could assess\nthe quality of the competing projects: http://people.ds.cam.ac.uk/nm603/awards/Adams_Prize\nOur colleagues have recommended you as an experienced specialist in this\nfield.\nWe need your assistance in evaluating several projects for Adams Prize.\nLooking forward to receiving your reply.\nBest regards,\nNeil Morris\nEven if an attacker has a browser 0day exploit, they still have find a way to deliver it to the target.\nWhen individuals are targeted, the delivery mechanism of choice is often an email that contains links to a\nmalicious site (which will “throw” the exploit when the user visits said site).\nUnfortunately the link ( people.ds.cam.ac.uk/nm603/awards/Adams_Prize ) currently returns a 404 Not Found :\n$ curl http://people.ds.cam.ac.uk/nm603/awards/Adams_Prize\n\n# Not Found\n\nThe requested URL /nm603/awards/Adams_Prize was not found on this server.\n\n---\nApache/2.4.7 (Ubuntu) Server at people.ds.cam.ac.uk Port 80 Of course it’s possible that the site will only serve up (“throw”) the exploit if the user browses to the site via a\nvulnerable version of Firefox, or perhaps from a certain IP address, etc. More than likely though, the attacker has\nmoved on, and taken down the exploit site.\nThough I don’t have access to the exploit code, the user was able to provide me with persistent malware the\nexploit installed on the system (named Finder.app ). Woohoo!\nThe remainder of this blog will cover the analysis of this malware (hash:\n23017a55b3d25a2597b7148214fd8fb2372591a5 ).\nhttps://objective-see.com/blog/blog_0x43.html\nPage 2 of 11\n\n$ shasum -a 1 ~/Attack/Finder.app/Contents/MacOS/Finder\r\n23017a55b3d25a2597b7148214fd8fb2372591a5 Finder\r\nInterestingly, today a security researcher at Coinbase, Philip Martin, posted an interesting thread on twitter:\r\nNote that the hash mentioned by Phil, 23017a55b3d25a2597b7148214fd8fb2372591a5 matches malicious file\r\nwhich the user sent me. Moreover the user confirmed that he was “involved with a cryptocurrency exchange until\r\nfairly recently.” Thus it seems reasonable to assume we’re all talking about the same Firefox 0day.\r\nThis 0day, has now been patched as CVE-2019-11707, and covered in various articles such as:\r\n“Mozilla patches Firefox zero-day abused in the wild”\r\n“Mozilla Patches Firefox Critical Flaw Under Active Attack“\r\nHowever, the details of the persistent malware used in the attack are scant (non-existent?), so let’s dive into that\r\nnow!\r\nA Persistent Mac Backdoor ( OSX.NetWire.A !?)\r\nhttps://objective-see.com/blog/blog_0x43.html\r\nPage 3 of 11\n\nAs noted, the infected user was kind enough to send me the malware ( Finder.app ) that the attacker persistently\r\ninstalled on the system (via the Firefox 0day).\r\nVia my open-source “WhatsYourSign” utility we can quickly see it’s an unsigned application:\r\nSearching for the hash ( 23017A55B3D25A2597B7148214FD8FB2372591A5 ) on VirusTotal found a exact match and\r\nshows that the file was submitted on 2019-06-06 but currently is only detected by one AV engine (Tencent):\r\nThe full application bundle, Finder.app, was just submitted to VirusTotal today.\r\nhttps://objective-see.com/blog/blog_0x43.html\r\nPage 4 of 11\n\nIt is similarly only detected by one AV engine.\r\nInterestingly the engine detecting the malware flags it as OSX.Netwire .\r\nOSX.Netwire (or OSX.Wirenet ) was first discovered in 2012(!) by Dr Web. In their writeup “Wirenet: The\r\nPassword-Stealing Trojan Lands on Linux and OS X” they state that it is “the first Trojan in history to steal Linux\r\nand Mac OS X passwords.”\r\nPasswords were stolen via keylogger logic and/or directly from files on disk (i.e. saved browser logins):\r\n$ strings malware/2012/OSX.Netwire\r\n%s/Library/Opera/wand.dat\r\n%s/.Library/Opera/wand.dat\r\nSeaMonkey\r\nThunderbird\r\n%s/Library/Application Support/Firefox\r\n%s/signons.sqlite\r\nNSS_Init\r\nPK11_GetInternalKeySlot\r\nPK11_Authenticate\r\nNSSBase64_DecodeBuffer\r\nselect * from moz_logins\r\nBut that was OSX.Netwire from 2012. Is this new sample really (still) OSX.Netwire !? I personally had not heard\r\nanything about OSX.Netwire since 2012, so decided to poke around.\r\nFirst, via simple “string” matching, it’s easy to confirm the 2012 sample and the 2019 are in someway related.\r\nFor example, note the string: \"\\x03\\x04\\x15\\x1A\\r\\nexit\\r\\n\\r\\nexit\\n\\n\" in both the 2012 sample:\r\nesi = \"/bin/sh\";\r\nif(access(esi) != 0x0) {\r\n esi = \"/bin/bash\";\r\n}\r\n...\r\neax = write$UNIX2003(*0x140d0, \"\\x03\\x04\\x15\\x1A\\r\\nexit\\r\\n\\r\\nexit\\n\\n\", 0x15);\r\nand in the 2019 sample:\r\nhttps://objective-see.com/blog/blog_0x43.html\r\nPage 5 of 11\n\nif(stat(\"/bin/sh\", edi) != 0x0) {\r\n ebp = \"/bin/bash\";\r\n}\r\n \r\n...\r\nwrite$UNIX2003(ebx, \"\\x03\\x04\\x15\\x1A\\r\\nexit\\r\\n\\r\\nexit\\n\\n\", 0x15)\r\n…other rather unique strings are also found in both samples.\r\nWhilst chatting about this with one my close (security researcher) friends he noted that this new sample was\r\n(already) detected by XProtect.\r\nI was rather skeptical of this claim (as I didn’t recall any recent XProtect updates for OSX.Netwire ), but turns out\r\nhe was absolutely right!\r\nIn 2016, Apple added a Yara signature to detect something called OSX.Netwire.A . The signature (found in\r\n/System/Library/CoreServices/XProtect.bundle/Contents/Resources/XProtect.yara ) is presented below:\r\nrule NetwireA\r\n{\r\n meta:\r\n description = \"OSX.Netwire.A\"\r\n strings:\r\n $a = \"exitexit\"\r\n $b = \"User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like GeckoAccept: text/html,\r\n condition:\r\n all of them\r\n}\r\nDigita’s UXProtect utility can graphically display this signature as well:\r\nhttps://objective-see.com/blog/blog_0x43.html\r\nPage 6 of 11\n\nWe can also utilize UXProtect to confirm this signature (from 2016) still detects the malware used in the Firefox\r\n0day attack:\r\nWow kudos to Apple for writing a signature that (IMHO) rather surprisingly detects still detects this “new” threat!\r\nInterestingly Apple’s signature does not detect the sample from 2012 (as it does not contain the User-Agent:\r\nMozilla... string). This is first (of many) indicator that these samples, while somehow related are unsurprisingly\r\nnot the same.\r\nWhile the sample from 2012 and 2019 are clearly related, they are also very different. We’ll get into this more in\r\npart two of this blog post, when we dive into the capabilities of the (new) malware sample. However in short, the\r\n2012 and 2019 samples have totally different objectives. If I had to guess, they are both written by the same author\r\n(or team), but serve unique purposes (i.e. the 2012 sample is only concerned with stealing passwords).\r\nBefore we wrap up part one of this post, let’s look at how the new sample, OSX.NetWire.A , persists.\r\nhttps://objective-see.com/blog/blog_0x43.html\r\nPage 7 of 11\n\nA quick peek at the malware’s disassembly reveals an embedded launch agent plist:\r\nmemcpy(esi, \"\u003c?xml version=\\\"1.0\\\" encoding=\\\"UTF-8\\\"?\u003e\\n\u003c!DOCTYPE plist PUBLIC \\\"-//Apple Computer//DTD PLIST\r\n \r\n...\r\neax = getenv(\"HOME\");\r\neax = __snprintf_chk(\u0026var_6014, 0x400, 0x0, 0x400, \"%s/Library/LaunchAgents/\", eax);\r\n...\r\neax = __snprintf_chk(edi, 0x400, 0x0, 0x400, \"%s%s.plist\", \u0026var_6014, 0xe5d6);\r\nSeems reasonable to assume the malware will persist as launch agent.\r\nHowever, it also appears to contain logic to persist as a login item (note the call to the\r\nLSSharedFileListInsertItemURL API):\r\neax = __snprintf_chk(\u0026var_6014, 0x400, 0x0, 0x400, \"%s%s.app\", \u0026var_748C, \u0026var_788C);\r\neax = CFURLCreateFromFileSystemRepresentation(0x0, \u0026var_6014, eax, 0x1);\r\n...\r\neax = LSSharedFileListCreate(0x0, **_kLSSharedFileListSessionLoginItems, 0x0);\r\n...\r\neax = LSSharedFileListInsertItemURL(eax, **_kLSSharedFileListItemLast, 0x0, 0x0, edi, 0x0, 0x0);\r\nHopping into a VM and running the malware, turns out it persists twice! First as launch agent\r\n( com.mac.host.plist ), and then as a login item.\r\n$ cat ~/Library/LaunchAgents/com.mac.host.plist\r\n{\r\n KeepAlive = 0;\r\n Label = \"com.mac.host\";\r\n ProgramArguments = (\r\n \"/Users/user/.defaults/Finder.app/Contents/MacOS/Finder\"\r\n );\r\n RunAtLoad = 1;\r\n}\r\nAs the launch agent ( com.mac.host.plist ) has the RunAtLoad key set (to 1 ), the OS will automatically\r\nlaunch the specified binary, .defaults/Finder.app/Contents/MacOS/Finder each time the user logs in.\r\nThe login item will also ensure the malware is launched. Login items however show up in the UI, clearly\r\ndetracting from the malware’s stealth:\r\nhttps://objective-see.com/blog/blog_0x43.html\r\nPage 8 of 11\n\nIs persisting twice better than once? Not really, especially if you are running Objective-See’s lovely tools such as\r\nBlockBlock which detects both persistence attempts:\r\nhttps://objective-see.com/blog/blog_0x43.html\r\nPage 9 of 11\n\nFor details on persisting as a login item (and the role of backgroundTaskManagementAgent), see my recent blog\r\npost: “Block Blocking Login Items“\r\nKnockKnock can also reveal the infection (after the fact), by detecting the malware’s (2x) persistence:\r\nMaybe the malware author wanted to be extra extra sure about gaining and/or maintaining persistence!?\r\nConclusion\r\nIn today’s post, we discussed the persistent payload of a rather sophisticated targeted attack again cryptocurrency\r\nexchange(s). Via a Firefox 0day, the attackers persistently deployed a macOS binary.\r\nRather interestingly this malware was OSX.NetWire.A , which bares some relation to a 2012 specimen of the same\r\nname. Similarly intriguingly we showed how a signature deployed by Apple in 2016 would detects this malware.\r\nOr would it?\r\nRecall that in his original email, the infected user noted that the malware bypassed Gatekeeper. This is actually\r\nunsurprising as the malware was delivered by a remote 0day exploit. Gatekeeper only scans applications that have\r\na quarantine attribute set. This is added by the application (i.e. browser) or OS only when the application is\r\ndownloaded via normal means (i.e. by the user). Exploit code that downloads a payload (such as malicious\r\napplication) will not set a quarantine attribute (or can remove it), thus will not trigger Gatekeeper!\r\nI highlighted this (well known) fact in a 2016 presentation, “Gatekeeper Exposed; Come, See, Conquer“:\r\nXProtect similarly only operates on files that have the quarantine bit set.\r\nHowever, this may be changing in macOS 10.15 (Catalina).\r\nhttps://objective-see.com/blog/blog_0x43.html\r\nPage 10 of 11\n\nThus, thanks to the infection vector (a Firefox 0day), neither Gatekeeper nor XProtect would protect the user.\r\nClearly it’s never wise to leave security soley to Cupertino 😅\r\nSource: https://objective-see.com/blog/blog_0x43.html\r\nhttps://objective-see.com/blog/blog_0x43.html\r\nPage 11 of 11", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://objective-see.com/blog/blog_0x43.html" ], "report_names": [ "blog_0x43.html" ], "threat_actors": [ { "id": "75108fc1-7f6a-450e-b024-10284f3f62bb", "created_at": "2024-11-01T02:00:52.756877Z", "updated_at": "2026-04-10T02:00:05.273746Z", "deleted_at": null, "main_name": "Play", "aliases": null, "source_name": "MITRE:Play", "tools": [ "Nltest", "AdFind", "PsExec", "Wevtutil", "Cobalt Strike", "Playcrypt", "Mimikatz" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434894, "ts_updated_at": 1775791833, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/b360b1f1b6439d395246f5583ba2f98df036d4bb.pdf", "text": "https://archive.orkl.eu/b360b1f1b6439d395246f5583ba2f98df036d4bb.txt", "img": "https://archive.orkl.eu/b360b1f1b6439d395246f5583ba2f98df036d4bb.jpg" } }