I will preface this by saying that I think that the hype about Silver Sparrow has been overblown. All the headlines make it seem scary, but the truth is that the malware doesn’t actually have a payload. Additionally, Mac’s Gatekeeper and XProtect services jumped on the malware very quickly, preventing it from running. That being said, it could have been much worse and it is always a good idea to examine security policies in the wake of events like this.
Detecting Silver Sparrow
We first learned of Silver Sparrow through news articles and this fantastic breakdown by Red Canary. Threads appeared on Jamf Nation (such as this one) and Slack discussing the malware and how to detect it. The files to look for, it seemed, were these:
"/Applications/tasker.app"
"/tmp/agent.sh"
"/tmp/version.json"
"/tmp/version.plist"
"/tmp/agent"
"/tmp/verx"
"/Users/$user/Library/._insu"
"/Users/$user/Library/Application Support/agent_updater/agent.sh"
"/Users/$user/Library/Application Support/verx_updater/verx.sh"
"/Users/$user/Library/Application Support/verx_updater"
"/Users/$user/Library/Launchagents/agent.plist"
"/Users/$user/Library/Launchagents/init_agent.plist"
"/Users/$user/Library/Launchagents/verx.plist"
"/Users/$user/Library/Launchagents/init_verx.plist"I created an Extension Attribute that looked for the existence of these files, not really expecting to find anything. I was pretty shocked to find that one computer reported the existence of two of the files.
Why was this a shock? Well, we keep things pretty nailed down around here:
- All users are standard, not admins.
- Users are not permitted to mount DMG files
- Users cannot install to the applications folder
- The App Store is blocked
- Most System Preferences are blocked
- All software is installed through jamf policies
- We have configuration profiles in place that will ONLY allow applications to launch that we have explicitly allowed. This means that by default, everything is blocked until it is added to the list.
These restrictions have been a headache to maintain over the years, but we have always had some peace of mind that they were doing their job to protect computers from malicious software. And they were, until now.
Investigating
So how did this happen? I started by logging into this computer to see if anything was amiss and immediately got a popup showing that the application “agent” was trying to run:
Sure enough, this was our “/Users/$user/Library/Application Support/agent_updater/agent.sh” file attempting to launch as the “/Users/$user/Library/Launchagents/agent.plist” was running when they logged in. But how did it get here?
I noticed that the files were dated from October of 2020. I recalled that around that same time, this user was having some trouble accessing curriculum websites and had put in a support ticket about it. They reported getting a popup in the browser and asked if this had anything to do with the trouble and included a helpful screenshot:
We solved the site access problem another way, told them to ignore the popup and forgot about the whole thing. Apparently they did not ignore the popup since there was a PKG named updater (1).pkg in the Downloads folder with around the same date and time as the support ticket.
Curious, I double-clicked on the PKG just to see what would happen. The computer was already infected, so YOLO, right? No surprise here – Apple has revoked the signing certificate so the file can’t be opened any more.
I transferred the files to my own computer to open them up and see what was inside. I like the Suspicious Package application for diving into installer applications so I opened it up there and got 2 messages that something was off. The first was about the certificate being revoked. The other was about the PKG file containing a script that would run without an administrator password. There it was!
Other blog posts had gone into this, but I didn’t entirely understand what they meant until I saw it popped up right there on my screen – Silver Sparrow was using what is known as a distribution file to put files onto the computer.
A distribution file (or script) is an XML file that is read by the Installer application when it opens up to get information about how to perform the install. Suspicious Package has a great writeup on what they are actually intended for on their site. I also dove into my copy of Packaging for Apple Administrators for more information. Generally, these distribution files exist for customizing the installer – they are there so that the installer can make sure it is even able to be run before beginning or by including custom choices or UI options. If you have ever seen a popup telling you that a package will run a program to determine if it can be installed, you have seen what a distribution file is meant to do:
Normally, distribution files are harmless. Most users have gotten used to clicking on Continue when this prompt appears. Suspicious Package doesn’t even show them when inspecting a package by default. This is what made Silver Sparrow so insidious. By using Javascript from within the distribution’s XML, it was able to spawn bash processes that created files on the disk.
This means that by the time our user clicked Continue on the prompt above, the damage was already done. A normal PKG would have required admin credentials to install anything, but Silver Sparrow got around that by using the distribution file. All of our allowed application lists meant nothing when the application doing damage was good old Installer.
Lessons Learned
The Good:
- Our allowlist did keep agent.sh from running. I want to reiterate again that the script didn’t actually do anything harmful, but if it had, it would have been very good to know that the process was blocked.
- I learned a lot about how packages work while going through all of this. I knew what distribution packages were but I had never done this deep of a dive into them.
- We were able to detect the files very quickly and remove them thanks to our Extension Attribute.
- Our user was smart enough to send us a screenshot of the popup they were getting and know that something was up.
The Bad:
- Our user clicked on the popup despite us telling them not to. We have to do better about educating users not to try to install things that we don’t allow.
- The Installer process should not be able to be run as a user. There is no reason for our teachers to ever run an installer application on their own. We use jamf for all software installation.
The Ugly:
- Our user was getting a popup for months that a program was trying to run and they never told us. The dark side of restricting application use the way that we do is that all things are blocked by default. Users get tired of seeing popups about blocked applications and stop reporting them.
While Silver Sparrow wasn’t necessarily the big scary monster the media made it out to be, it did wake us up to some things that we could be doing better in our environment.