The mystery of the Silver Sparrow Mac malware

Cyber security company Red Canary published findings last week about a new piece of Mac malware called Silver Sparrow. This malware is notable in being one of the first to include native code for Apple’s new M1 chips, but what is unknown about this malware is actually more interesting than what is known!


We know that the malware was installed via Apple installer packages (.pkg files) named update.pkg or updater.pkg. However, we do not know how these files were delivered to the user.

These .pkg files included JavaScript code, in such a way that the code would run at the very beginning, before the installation has really started. The user would then be asked if they want to allow a program to run “to determine if the software can be installed.”

Silver Sparrow's installer telling the user, "This package will run a program to determine if the software can be installed."

This means that, if you were to click Continue, but then think better of it and quit the installer, it would be too late. You’d already be infected.

Malware life cycle

The malicious JavaScript code installs a launch agent plist file for the current user, which is designed to launch a script named once per hour. This script has several functions.

First, it will contact a command & control server formerly hosted on Amazon AWS. The data it gets back looked something like this at the time of analysis:

{ "version": 2, "label": "verx", "args": "upbuchupsf", "dls": 4320, "run": true, "loc": "~/Library/._insu", "downloadUrl": "" }

Next, the malware will check for the file ~/Library/._insu. From Malwarebytes data, it appears that this is a zero-byte file, and the malware simply uses it as a marker to indicate that it should delete itself. In this case, the script does exactly that, then exits.

Finally, it will try to determine whether there is a newer version of the malware (which will always be the case if the final payload is not yet installed), and if so, it will download the payload from the URL provided in the downloadUrl parameter in the data from the command & control server.

However, as can be seen from the data, at the time of analysis, the download URL was blank. Although we know that the script will store the payload at /tmp/verx, we have yet to see any instances of this payload on any infected machines.

If the payload were actually downloaded, it would be launched with the args data as the arguments.

Separate from the files dropped by the JavaScript, the .pkg file also installs an app into the Applications folder. This app is named either “tasker” or “updater,” depending on the version of the .pkg file. Both of these apps appear to be very simplistic placeholder apps that don’t do anything interesting.

Silver Sparrows in the wild

Malwarebytes researchers collaborated with Red Canary researchers on their find, and have collected significant data about the infection at this point. At the time of this writing, we’ve seen 39,080 unique machines with components of Silver Sparrow detected by Malwarebytes.

Those detections are primarily clustered in the US, with more than 25,000 unique machines having Silver Sparrow detections. This, of course, is affected by Malwarebytes’ heavily US-based customer base, but the malware does appear to be quite widespread, with detections in 164 different countries.

Country Detections
United States 25,331
United Kingdom 2,785
Canada 2,389
France 2,218
Germany 920
Italy 636
Australia 509
Spain 368
India 306
Mexico 196
Silver Sparrow detections by country

The paths detected show a rather interesting pattern. The vast majority of “infections” are actually represented by the ._insu file, and machines that have that file present do not have any of the other components (as expected).

Path Detections
~/Library/._insu 38,869
/Applications/ 1,627
/Applications/ 763
~/Library/Application Support/verx_updater 731
~/Library/LaunchAgents/init_verx.plist 707
/tmp/version.plist 649
/tmp/version.json 568
/tmp/ 86
Malwarebytes Silver Sparrow detections


At this time, we have yet to see the /tmp/verx payload. None of the infected machines have it installed. This means that, as Red Canary said, we have little information on what the intent of this malware is.

The args value in the data from the command and control server (upbuchupsf) looks similar to an affiliate code, often used by adware. However, we can’t make assumptions based on a single ten-character string, as such assumptions could very easily be wrong. After all, malware that is sold to, and used by, multiple people may very well include some kind of “customer code.”

The fact that the ._insu file has been seen in such high numbers is interesting. Since this file signals that the malware should delete itself (though we don’t know how the file gets created), that is a strong indicator that these are probably formerly infected machines.

Thus, it’s highly likely that this infection may have been present at some point in the recent past, but the operators sent out a silent “kill” command to cause the malware to delete itself. This could correspond to the first appearance of the newest malicious installer being uploaded to VirusTotal, which would be an indicator to the creator that the malware had been spotted, or it could have been prompted by some other event.

It’s unlikely that these machines were infected for a very long time, as the two command and control server domains were registered in August and December of 2020, per Red Canary findings.

Malwarebytes detects these files as OSX.SilverSparrow.