Update, May 19:After having a conversation with Red Canary and MalwareBytes on the data provided in this post, we determined that our results differed from theirs because of how we defined our clusters.
When using an activity cluster approach, like Red Canary, the infection numbers reported by news organizations would not change. When using a malware cluster approach, like we do here, which is based on the samples Red Canary found and our telemetry, the infection numbers would be much lower.
Based on our data, it is our belief that the activity cluster is too broad because of the inclusion of ._insu file behavior. As you’ll see in the rest of the post, we don’t believe that including the ._insu file in the cluster is sound.
Internally, we called this malware cluster Pickle. Following news reports and for the purposes of this blog post, we call the malware cluster Silver Sparrow.
As Verizon Media’s internal security team, the Paranoids have invested heavily into cyber defense in part by building a countermeasures team that actively deploys detections and proactively blocks malware. We are constantly on the lookout for unusual signals that could be signs of malicious activity across our systems and services.
In early August 2020, during one of our routine threat hunting operations, we noticed a mysterious uptick in malware activity in our internal telemetry data. We identified the introduction of a new persistence mechanism leveraging PlistBuddy —a program provided with MacOS that can be used to create or edit .plist files. We sprang into action and mitigated this threat.
We weren’t the only ones to notice it, however. Roughly six months later, Red Canary, a managed detection and response vendor, publicly disclosed the inner workings of the malware we found. The researchers atRed Canary called it Silver Sparrow. (You should read Red Canary’s blog post. It is excellent.)
Silver Sparrow is a mystery. From what we can tell, Silver Sparrow is designed to install other software. Neither the Paranoids nor outside industry vendors have identified any secondary infection resulting directly from Silver Sparrow. It seems to serve as a mechanism to install further malicious payloads, and deletes itself if it recognizes the existence of a particular file that it does not create or modify itself.
Of course, we were intrigued by the Silver Sparrow’s puzzling behavior. Given the ongoing discussions surrounding the malware, we decided to review our telemetry data. We’re publishing our findings in the hopes that what we’ve found will be of value to our industry peers and the general security community.
In particular, we believe the reported infection count estimates are inflated due to the misattribution of an indicator of compromise (IOC) that the original report attributed to infection by Silver Sparrow.
On Feb 18th 2021, Red Canary released research regarding new MacOS malware that targeted both Intel and ARM processor devices. Silver Sparrow was the first Mac Malware to gain public notoriety due to its capability to target both Intel and M1 Chips. It also hints at a larger ecosystem of malware and its accompanying supply chain through a potential pay-per-install scheme.
Since there are many great reports out there, we won’t dive into the malware details. Instead we’ll provide extra context and additional data that aims to address some of the mysteries surrounding the malware.
For our review we created three clusters of malware activity:
During August 2020 we noticed an uptake in malware activity. Two indicators from the Silver Sparrow report stand out for us:
One of the most interesting aspects of Silver Sparrow is determining the purpose of the mysterious ~/Library/._insu file. The ._insu file is an artifact often left behind by other malware.
This empty file gets created during infection and, according to our telemetry, this file first appeared in what we called our “Insu” cluster on August 14th 2020. Below is sample of some of application names used by this cluster:
As you can see this cluster has one thing in common, the interesting files all have the word “Search” in their names.
The cluster has been active for months; however, we only found ~/Library/._insu activity from August 14th to October 9th.
It is our opinion that this file has been misattributed to Silver Sparrow. The only connection to Silver Sparrow is the check done to confirm its presence. If the file exists, Silver Sparrow will remove itself, otherwise it will proceed with the infection.
This item is significant because previously published reports pin the number of Silver Sparrow infections at beyond 30k assets. For example, according to Malwarebytes Silver Sparrow report, 38k+ detections are attributed to this file:
However, we saw the _.insu file before Silver Sparrow activity, which suggests that it is a bad indicator for determining Silver Sparrow infections. Using the data provided by Malwarebytes, the resulting number of infections would drastically drop to about 3k infections (updater.app + tasker.app) after removing counts based on the existence of the _.insu file.
This fact creates an interesting question: Was the _.insu file an artifact of another serious mass pay-per-install adware scheme stopped at the right time?
One of the key characteristics of some of the malware seen during this time frame involved the use of a unique persistence technique: PlistBuddy
PlistBuddy is a program provided with MacOS that can be used to create or edit plist files.
While plenty of software leverages PlistBuddy without any malicious intent, there are a few operations in PlistBuddy that can, with a high level of confidence, signal abnormal activity.
In a future post we will dive further into PlistBuddy for adversary emulation and red teaming. Defenders should key-in into PlistBuddy -c "Add :RunAtLoad” for detection opportunities.
RunAtLoad has been observed to be used primarily for malicious persistence.
The use of PlistBuddy is significant because prior to August 2020 we don't have any telemetry indicating its use for malicious purposes.
Prior to August 2020, we were able to identify adware leveraging the “King Cluster” technique: PlistBuddy Persistence. This cluster is very interesting and will be a subject in future posts. However, before the end of August the PlistBuddy activity on this cluster stopped. In parallel we saw the technique reappear as Silver Sparrow began its activities.
Around this time we shared some detection telemetry with industry partners. We're emboldened to see how it has been used to help uncover Silver Sparrow.
Because we saw the <strong>._insu</strong> file indicator in our telemetry before we saw Silver Sparrow activity, we can confirm that the number of infections reported is likely too high.
Before we dive too deeply into analyzing the requests and parameters, here's the flow of the URLs for one specific instance. Some of the info has been redacted.
hxxps://s3[.]amazonaws[.]com/takes place. Redirection contains information about who the redirector is
Infection flow example:
The chain from CDN domains down through s3.amazonaws.com are linked through 302 redirects while the requests to validfunction and the S3 bucket with the Silver Sparrow pkg file are new requests. The latter is TLS encrypted so we don't have visibility into the transaction but the former 2 requests to validfunction do have referer headers pointing back to the s3.amazonaws.com URI at the end of the 302 chain.
Time to do some of that deeper diving and split some hairs.
There may be more than these handful of sites and it would be interesting to find out if these are all related in some way but that is beyond the scope of this post. The 'q' parameter is the search string that the user entered. The '_pg' parameter is a UUID that will reappear further down the chain of events and serves as a machine identifier. We've seen it parsed from the output of an ioreg command just before Silver Sparrow phones home to signal its installation.
hxxp://www[.]standartconnection[.]com/yXQCpciJ3HRVSwysjFqVkFlse?x=3&r=01c4ea67-18ee-48a1-9b56-f9812457c6e8&stu=3c5580522 (seen with Chrome)
hxxp://www[.]standartconnection[.]com/BkFIhAbD5nbIN8omI04r7CMcBt?lu=m3dj799&e=3&r=6cb676a3-bcac-4776-9d39-1e51a64576d90 (seen with Chrome)
hxxp://www[.]standartconnection[.]com/jRXZs?stu=3c55805&x=3&g=b16a3cd8-855d-4653-b534-6c028009f228 (seen with Safari) feed.chunckapp.com (search query terms included)
search.funsafetabsearch.com (search query terms included)
Some searches were optionally redirected to other sites, but the ones of most interest to us redirected to
standartconnection. Those had the following attributes:
The first redirect to
standartconnection will redirect back to
standartconnection again but with more parameters:
aHR0cDovL3d3dy52YWxpZGZ1bmN0aW9uLmNvbQ%253d%253dwhich decodes to
hxxp://www[.]validfunction[.]comwhich is a site we've seen hosts reach out to later.
standartconnection URI will 302 redirect to
https://s3.amazonaws.com/ with some of the same parameters carried through.
The last hop is to the
At this time we’re not sure what the full role of the
www[.]validfunction[.]com host is but it appears to receive some telemetry stats in subsequent requests.
standartconnectionlink is also present
https://s3.amazonaws.com/further linking this together.
As others have described, after a successful infection the system invokes curl to "phone home" to
Thanks to an amazing retention period in our network forensics tool Arkime, we can say that we haven't seen anything POST to "/pkl" on any site in the last year that wasn't related to Silver Sparrow activity. We really love Arkime, this was as easy as putting the following in the search field:
http.method == POST && http.uri.path == /pkl
URI Query String Parameter Values of interest
http.uri.value == [3c55805, m3dj799, 01c4ea67-18ee-48a1-9b56-f9812457c6e8, 6cb676a3-bcac-4776-9d39-1e51a64576d9, b16a3cd8-855d-4653-b534-6c028009f228, aHR0cDovL3d3dy52YWxpZGZ1bmN0aW9uLmNvbQ%253d%253d]
Looking for those indicators in any URI
http.uri == [*stu=3c55805*, *lu=m3dj799*, *01c4ea67-18ee-48a1-9b56-f9812457c6e8*, *6cb676a3-bcac-4776-9d39-1e51a64576d9*, *b16a3cd8-855d-4653-b534-6c028009f228*, *aHR0cDovL3d3dy52YWxpZGZ1bmN0aW9uLmNvbQ*]
Looking for things redirecting to standartconnection or the two package loctions
http.location == [*update-v3a98x2.s3.amazonaws.com*, *updater-i06u9j9.s3.amazonaws.com*, *www.standartconnection.com*]
Redirects to the S3 links containing two of the indicators
http.location == [*s3.amazonaws.com/*3c55805*, *s3.amazonaws.com/*m3dj799*]
URIs with the indicators, redirects with the indicators, or requests to the malware buckets.
http.uri == [*stu=3c55805*, *lu=m3dj799*, *01c4ea67-18ee-48a1-9b56-f9812457c6e8*, *6cb676a3-bcac-4776-9d39-1e51a64576d9*, *b16a3cd8-855d-4653-b534-6c028009f228*, *aHR0cDovL3d3dy52YWxpZGZ1bmN0aW9uLmNvbQ*] || http.location == [*stu=3c55805*, *lu=m3dj799*, *01c4ea67-18ee-48a1-9b56-f9812457c6e8*, *6cb676a3-bcac-4776-9d39-1e51a64576d9*, *b16a3cd8-855d-4653-b534-6c028009f228*, *aHR0cDovL3d3dy52YWxpZGZ1bmN0aW9uLmNvbQ*] || host.http == [update-v3a98x2.s3.amazonaws.com, updater-i06u9j9.s3.amazonaws.com]
About the Authors
The Paranoids’ Forensic Engineering and Incident Response, or FIRE, team authored this blog post. The group conducts threat hunting operations and deals with anything that has to do with incident response at Verizon Media. P.S. We're hiring!