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!
Installation
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.”
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 verx.sh 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 |
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/updater.app | 1,627 |
| /Applications/tasker.app | 763 |
| ~/Library/Application Support/verx_updater | 731 |
| ~/Library/LaunchAgents/init_verx.plist | 707 |
| /tmp/version.plist | 649 |
| /tmp/version.json | 568 |
| /tmp/agent.sh | 86 |
Conclusions
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.
Yes, Malwarebytes protects your Mac from Silver Sparrow.
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.
The post The mystery of the Silver Sparrow Mac malware appeared first on Malwarebytes Labs.
