Silver Sparrow and the Mysterious Insu File: Findings From Paranoid Telemetry

​Summary

• In late Summer 2020, the Paranoids identified a novel piece of malware that would later be dubbed Silver Sparrow by managed detection and response firm Red Canary.
• Based on data collected by the Paranoids, the infection count estimates originally published by Red Canary and others are inaccurate. Spoiler alert: it’s most likely much lower, roughly 3,000 infected machines instead of about 30,000.
• A domain — httpx://www[.]standartconnection[.]com — involved in spreading the malware may be a key to ongoing questions about how this Silver Sparrow malware actually spread.

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.

What is Silver Sparrow and why is it important?

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:

​

• Cluster 1 - Infections that took place just weeks prior to Silver Sparrow that share similar techniques or IOCs as reported in the Silver Sparrow reports. This will be the cluster that will provide key answers.
• Cluster 2 - Infections that are linked to both versions of Silver Sparrow — targeting Intel and M1 Chips, respectively
• Cluster 3 - An interesting case in which simultaneous infections took place.

Pre Silver Sparrow activity

During August 2020 we noticed an uptake in malware activity. Two indicators from the Silver Sparrow report stand out for us:

1. The mysterious "insu" file
2. Use of PlistBuddy for Persistence

The mysterious "insu" file

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:

• AssistiveDisplaySearch Vhash 1fc1dd76927be7189977702bc399433e
• StandartConsoleSearch Vhash 687b721f705c19beee56ac646ae281ea
• FindResultsLibrary

​

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?

About PlistBuddy

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.

Why is this pre activity important?

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.

Traffic Analysis

Basic Redirection Flow and Referrals

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.

1. The browser requests a random search term on a domain hosted on a leading CDN (not Verizon’s).
2. Client is redirected to hxxp://www[.]standartconnection[.]com
3. Redirection to amazon hxxps://s3[.]amazonaws[.]com/ takes place. Redirection contains information about who the redirector is
4. View and download click stat information is collected via hxxp://www[.]validfunction[.]com/
5. Malware is downloaded hxxps://update-v3a98x2[.]s3[.]amazonaws[.]com/

​

Infection flow example:

hxxp://CDN/s?q=REDACTED_SEARCH_TERM&_pg=REDACTED_UUID_1
|_302_ hxxp://www[.]standartconnection[.]com/yXQCpciJ3HRVSwysjFqVkFlse?x=3&r=01c4ea67-18ee-48a1-9b56-f9812457c6e8&stu=3c55805
|_302_ hxxp://www[.]standartconnection[.]com/9SYshp5jElgXlUVXovJEJgg?r=01c4ea67-18ee-48a1-9b56-f9812457c6e8&stu=3c55805&d=REDACTED_BASE64_DATABLOB_1&a=2&s=REDACTED_UUID_2&client=chrome&kd=aHR0cDovL3d3dy52YWxpZGZ1bmN0aW9uLmNvbQ%2
53d%253d
|_302_ hxxps://s3[.]amazonaws[.]com/903508/fb07e68c-ee85-4ce9-/g3zkFnUY4UOLneR/oPCDUX5zf?r=01c4ea67-18ee-48a1-9b56-
f9812457c6e8&stu=3c55805&s=REDACTED_UUID_2&client=chrome&kd=aHR0cDovL3d3dy52YWxpZGZ1bmN0aW9uLmNvbQ%253d%253d&h=REDACTED_BASE64_DATABL
OB_2&t=1&u=aHR0cHM6Ly91cGRhdGUtdjNhOTh4Mi5zMy5hbWF6b25hd3MuY29tL3VwZGF0ZXIucGtnP3I9MDFjNGVhNjctMThlZS00OGExLTliNTYtZjk4MTI0NTdjNmU4JnN0
dT0zYzU1ODA1JnM9UkVEQUNURURfVVVJRF8yJmNsaWVudD1jaHJvbWUma2Q9YUhSMGNEb3ZMM2QzZHk1MllXeHBaR1oxYm1OMGFXOXVMbU52YlElMjUzZCUyNTNkCg%
253d%253d
|_____ hxxp://www[.]validfunction[.]com/stats/?TRLP_Event_2,01c4ea67-18ee-48a1-9b56-
f9812457c6e8,REDACTED_UUID_2,View,Mozilla%2F5.0%20(Macintosh%3B%20Intel%20Mac%20OS%20X%2010_15_6)%20AppleWebKit%2F537.36%20(KHTML%2C%20like%
20Gecko)%20Chrome%2F84.0.4147.135%20Safari%2F537.36,Chrome,84
|_____ hxxp://www[.]validfunction[.]com/stats/?TRLP_Event_2,01c4ea67-18ee-48a1-9b56-
f9812457c6e8,REDACTED_UUID_2,DLClick,Mozilla%2F5.0%20(Macintosh%3B%20Intel%20Mac%20OS%20X%2010_15_6)%20AppleWebKit%2F537.36%20(KHTML%2C%20lik
e%20Gecko)%20Chrome%2F84.0.4147.135%20Safari%2F537.36,Chrome,84
|_____ hxxps://update-v3a98x2[.]s3[.]amazonaws[.]com/updater.pkg?r=01c4ea67-18ee-48a1-9b56-
f9812457c6e8&stu=3c55805&s=REDACTED_UUID_2&client=chrome&kd=aHR0cDovL3d3dy52YWxpZGZ1bmN0aW9uLmNvbQ%253d%253d

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.

Picking the Links Apart

Time to do some of that deeper diving and split some hairs.

Starting Search Sites and First Redirect:

CDN domain
search[.]inetprogress[.]com

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.

Second Redirect:

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 URI path was between 5 and 26 alphanumeric characters and we are unsure of their meaning.
• An 'r' or 'g' parameter containing a UUID value that we see recurring across numerous requests as if it is a "campaign" id rather than being tied to any machine. Specifically the 'g' and its UUID were only seen on our sole instance of Safari being the browser.
• An 'stu' or 'lu' parameter that although not being in UUID format, is seeming like a widely applied alphanumeric value seen throughout the infection chain and not unique to a given host.
• An 'x' or 'e' parameter was seen and it was always a value of "3".

The first redirect to standartconnection will redirect back to standartconnection again but with more parameters:

• The URI path for the second connection was between 5 and 27 alphanumeric characters in length and was not unique per session.
• Each of the links was unique overall. The 'r' or 'g' UUID parameter as well as the 'stu' or 'lu' parameters were preserved in the next redirect. The 'd' and 's' parameters appear to be unique per URI. The 's' looks to be another UUID but the 'd' looks to be an encoded blob. The "client" parameter reports either chrome or safari.
• Across all of them we've seen 1 of 4 different parameters (st, kd, lm, rsm) with the same value aHR0cDovL3d3dy52YWxpZGZ1bmN0aW9uLmNvbQ%253d%253d which decodes to hxxp://www[.]validfunction[.]comwhich is a site we've seen hosts reach out to later.
• Across all of these, we've seen two different parameters chosen from this list: a, e, t, x.

The redirection to AWS S3:

The second standartconnection URI will 302 redirect to https://s3.amazonaws.com/ with some of the same parameters carried through.

• The 'r' or 'g' UUID as well as the 'stu' or 'lu' and 'client' parameters carry over.
• The more unique UUID in the 's' parameter is carried over as well.
• The 'a', 'e', 't', 'x' parameter that was present before will have a value of 1 instead of 2.
• The 'st', 'kd', 'lm', or 'rsm' and it's encoded value is carried forward to S3.
• The big change is that the 'd' parameter and it's data blob are no longer present. In it's place there are two new parameters 'h' and 'u'.
• The 'h' parameter contains similar looking encoded data to the 'd' parameter. It appears to be base64 encoded and some substrings are a match between the two but they are not even the same length.
• The 'u' parameter is another base64 encoded string which decodes to the final destination URI in S3 that contains the malware package.

And we have reached our final destination:

The last hop is to the update-v3a98x2[.]s3[.]amazonaws[.]com or updater-i06u9j9[.]s3[.]amazonaws[.]com

• URI where the pkg file is hosted can be decoded from the 'u' parameter in the S3 link above.
• Again we see the 'r', 'stu', 'client', 's', and 'st' (or their equivalents) carry through from the previous standartconnection redirection.

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.

• Sometimes the traffic to this domain was TLS encrypted
• When the traffic was in clear text we observed requests that follow this pattern:
• The URI path is "/stats/"
• The 'r' traces all the way back to the first standartconnection URI
• The 's' from the second standartconnection link is also present
• A URLEncoded browser User-Agent string.
• There are also "View" or "DLClick" values in the examples above which seem to show the progression of infection and suggests that there may be some end user interaction required for infection.
• The Referer Header also points back to the https://s3.amazonaws.com/ further linking this together.

As others have described, after a successful infection the system invokes curl to "phone home" to api[.]mobiletraits[.]com or api[.]specialattributes[.]com.

• We like to call this the "pickle call" because the URI path was "/pkl".
• It contained a fixed "mn=PkgInstall" parameter
• The 'm' which seems to be the machine ID (which we saw in the original search '_pg')
• The 'u' contained the final Amazon S3 url the package was downloaded from.

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

Arkime searches you might want to try:

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]

Appendix: IOCs

search[.]inetprogress[.]com
www[.]standartconnection[.]com
www[.]validfunction[.]com
update-v3a98x2[.]s3[.]amazonaws[.]com
updater-i06u9j9[.]s3[.]amazonaws[.]com
stu=3c55805
lu=m3dj799
01c4ea67-18ee-48a1-9b56-f9812457c6e8
6cb676a3-bcac-4776-9d39-1e51a64576d9
b16a3cd8-855d-4653-b534-6c028009f228
aHR0cDovL3d3dy52YWxpZGZ1bmN0aW9uLmNvbQ

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!