Affiliate Disclosure
If you buy through our links, we may get a commission. Read our ethics policy.

Mysterious malware infecting Apple Silicon Macs has no payload - yet

Last updated

More malware affecting Apple Silicon Macs has been uncovered, but researchers have spotted that it is lacking a malicious payload, for the moment.

It seems that there may be more malware aimed at Apple's M1-based Macs than previously thought. Following the initial reports of the first M1 malware found in the wild, it seems that there are more infections of malware, but of a particularly toothless variety.

Early in February, researchers from Red Canary discovered a strain of macOS malware that used LaunchAgent to make its presence, much like some other forms of malware. What was of interest to the researchers was that the malware behaved differently from typical adware, due to how it used JavaScript for execution.

The malware cluster, named by the researchers as "Silver Sparrow," also involved a binary compiled to work with M1 chips. This made it malware that would potentially target Apple Silicon Macs.

Further research from researchers at VMware Carbon Black and Malwarebytes determined it was likely that Silver Sparrow was a "previously undetected strain of malware." As of February 17, it had been detected in 29,139 macOS endpoints across 153 countries, with the bulk of infections residing in the US, the UK, Canada, France, and Germany.

At the time of publication, the malware hasn't been used to deliver a malicious payload to victim Macs, though that could change in the future. Due to the compatibility with M1, the "relatively high infection rate" and the operational maturity of the malware, it was deemed to be a serious enough threat that is "uniquely positioned to deliver a potentially impactful payload at a moment's notice," prompting a public disclosure.

Two versions of the malware were discovered, with one version's payload consisting of a binary affecting Intel-based Macs only, while the other was a binary that was compiled for both Intel and M1 architectures. The payload is seemingly a placeholder, as the first version opens a window that literally says "Hello, World!" and the second states "You did it!"

An example of the included binary [via Red Canary] An example of the included binary [via Red Canary]

If it were malicious malware, the payload could potentially allow the same or similar payload instructions to affect both architectures from a single executable.

The mechanism for the malware worked around files titled "update.pkg" and "updater.pkg," taking the guise of installers. They take advantage of the macOS Installer JavaScript API to execute the suspicious commands.

This is a behavior that is sometimes seen with legitimate software and not malware, which usually uses preinstall or post-install scripts for command execution.

Once successful, the infection attempts to check a specific URL for a downloadable file, which could contain further instructions or a final payload. A week of monitoring the malware resulted in no visible final payload being made available, which could still change in the future.

There are multiple questions left unanswered to the researchers about Silver Sparrow. These include where the initial PKG files came to be used for infecting systems, and elements of the malware's code that seems to be part of a wider toolset.

"The ultimate goal of this malware is a mystery," Red Canary admits. "We have no way of knowing with certainty what payload would be distributed by the malware, if a payload has already been delivered and removed, or if the adversary has a future timeline for distribution."

There is also the question of the inclusion of the "Hello World" executables, as the binary won't run unless a victim actively searched for it and ran it, rather than running automatically. The executables suggest this could be an under-development malware, or that an application bundle was needed to make the malware seem legitimate to other parties.



14 Comments

OutdoorAppDeveloper 15 Years · 1292 comments

Javascript: Second only to Flash as a vector for malware and viruses. Wasn't it supposed to be ultra secure? I could have sworn that was the reason given for why it was created in the first place.

sejmann 12 Years · 4 comments

Every article about how M1 is now a malware target is stupid clickbait. In none of these cases is the M1 chip exhibiting a vulnerability, other than macOS’ ability to cause code to be run upon it. It’s macOS that’s suffering the vulnerability, the same macOS that also runs on Intel. A compiler target architecture is not remotely the same thing as a exploitable hardware target. It’s just a command line flag. It can’t possibly be news that a malware author changed a compiler flag — xCode practically begs all developers to also target Apple Silicon. Apple never implied the M1 would be in any way more resistant to malware than Intel processors, and they bent over backward to make sure Intel code could run along side natively compiled M1 code to make the processor as irrelevant as possible. Please be responsible journalists and just write a single article stating the M1 is no more or less vulnerable to malware, and leave these “Apple Silicon vulnerability“ framings to less reputable blogs.

sejmann 12 Years · 4 comments

Javascript: Second only to Flash as a vector for malware and viruses. Wasn't it supposed to be ultra secure? I could have sworn that was the reason given for why it was created in the first place.

JavaScript isn’t the issue here. It’s an incidental bystander to the crime. The installer package happens to (reasonably) allow scripts to be run as part of the install/cleanup process. Crucially, it could have been Apple Script or a bash script and done the exact same thing. The user that runs the .pkg installer file is the weak link, the insecurity, as they allowed an unsafe application to have control of their system. An installer is a foreign executable, regardless of the language in which it’s code is written. At no point is the JavaScript doing something it wasn’t permitted to do by the user or the system.

Flash had myriad exploitable vulnerabilities, where unauthorized code could break free of Flash’s constraints, escalate privilege and run on the native system. This isn’t like that. Particular JavaScript virtual machines/interpreters may have similar vulnerabilities, but this isn’t one of those cases. This is more like welcoming the bad guys in directly.

bonobob 13 Years · 395 comments

Thanks to the author for not including any info on how to detect if one is compromised.  That's certainly not something anyone here would care about.

commentzilla 10 Years · 777 comments

bonobob said:
Thanks to the author for not including any info on how to detect if one is compromised.  That's certainly not something anyone here would care about.

Exactly. After scaring the shit out of everyone it would be great if AI would provide clear information on how to detect and remove it. Even over at Ars Techinca they’re being lazy by just pointing to the research’s website, which may be too technical for most people to wade through.