On April 16th, Twitter user @malwrhunterteam tweeted details of a sample of the LockBit ransomware compiled for Apple’s macOS arm64 architecture. LockBit claims to be “the oldest ransomware affiliate program on the planet”, and news that one of the major cybercrime outfits in the ransomware landscape was now targeting macOS devices has predictably raised concerns about the ransomware threat on Mac devices.
In this post, we explore both the details of the LockBit sample uncovered and the larger question of how real is the risk of ransomware on macOS endpoints.
The sample of LockBit ransomware for Mac was discovered on VirusTotal on April 16th, and according to @vxunderground may have been compiled as early as 17th November 2022.
A further sample was uploaded to VirusTotal on the 8th December, 2022.
The macOS samples are compiled solely for the Apple ARM M1/M2 (aka Apple silicon) architecture. No macOS Intel sample is known at this time.
Importantly for concerned users, no occurrences of LockBit for Mac have yet been reported in the wild, no victims claimed, and no distribution method is known to be associated with the malware. However, early claims that the sample was non-functional were incorrect.
LockBit 3.0 typically requires a unique password to execute; in the case of the Mac sample, the hardcoded password is “test” – one of several clues as to the current state of development of the threat.
The Mac variant is a direct descendant of the LockBit for Linux variant first spotted in Jan 2022, and contains much the same code.
The ransomware functions as intended to encrypt targeted files, which are subsequently appended with the .lockbit
extension. The locker also deposits a rather lengthy ransom note in the parent folder with the name !!!-Restore-My-Files-!!!
.
The ransom note gives a clear indication of the intended victims.
LockBit is known for attacking and extorting organizations rather than random individuals on the internet, and the aim of the developers is to make large profits from locking and stealing business data.
The Mac sample does not appear to implement any functionality for exfiltrating the data it locks, nor does it have any method of persistence: more clear signs that this is a “work in progress” and not a genuine payload intended for use in the wild.
Despite the underdeveloped nature of the samples, it is clear that the authors are experimenting with similar functionality seen in lockers for other platforms. The malware is intended to be executed by a human operator or configuration file and offers a number of different encryption options. These mirror those seen in the Linux version noted above.
These can be seen reflected in the methods seen in the code.
Although there is a list of hardcoded extension names, many of which are not applicable to macOS, the locker is not restricted to encrypting only files with those extensions. As noted above, an operator may specify a particular destination and attempt to encrypt all files in that destination, partially or entirely.
Much of the code and methods apply to non-macOS platforms such as Windows, ESXi and Linux, indicating that the samples were likely compiled from the same cross-platform source code.
On execution on an Apple M1 or M2 device, the LockBit ransomware queries for the model name via sysctl hw.model
, likely as part of anti-analysis measures.
Encryption takes advantage of the publicly available library Mbed TLS. Interestingly, there appear to be no cross-references to the functions intended to decrypt locked files.
According to one media report, the public-facing representative of LockBit, known as LockBitSupp, said that the Mac encryptor is “actively being developed”. Perhaps, more complete samples may be over the horizon with the missing functionality.
Due to the rampant nature of the ransomware threat on other platforms, it is only natural to wonder how safe Macs are from ransomware actors. While some security vendors have incorrectly made much of it in the past, the reality is that there is no publicly recorded case of any business ever paying a ransom demand as a result of macOS ransomware. This is not surprising when you look at the history of attempts to build ransomware on macOS to date.
The most recent known Mac ransomware prior to the LockBit sample found this week was EvilQuest (aka ThiefQuest). SentinelLabs analysis of the threat and subsequent publication of a decryptor revealed that the actual ransomware component was unfit for purpose. Despite garnering headlines like “New Mac Ransomware Is Even More Sinister Than It Appears”, not only was the encryption weak, the ransom note did not include a way for intended victims to contact the threat actors to exchange their money for a decryption key: It merely included a crypto wallet address and a demand for the princely sum of $50.
Unsurprisingly, that wallet remains empty today, having never received a single transaction. Though EvilQuest was certainly a real threat and continued to infect devices over the following 12 months or so, its infostealing and keylogging capabilities were likely the real reward for the threat actors: As ransomware, it failed entirely.
Prior to 2020, the next most recent macOS ransomware attempt was Patcher, discovered by ESET in 2017. Patcher (aka FindZip) was distributed in cracked apps on torrent sites and, much like EvilQuest, never recorded a single transaction to its bitcoin address.
Patcher was preceded in 2016 by KeRanger, a functional ransomware distributed through a trojanized version of the popular Transmission bittorrent client. KeRanger appears to have been precisely $3.02 more successful than either EvilQuest or Patcher ransomware: Its bitcoin wallet shows exactly one transaction – not necessarily from a victim – of that value.
We have to go back to 2014 to find the next occurrence of macOS ransomware. FileCoder was discovered on VirusTotal and was said to have been lying around on the site for two years. Unfinished and unworkable, FileCoder was a POC that did not actually encrypt the user’s files but demonstrated encryption and decryption of a sample file included with the malware. It is thought to be the precursor to the Patcher/FindZip malware discussed above.
In short, the history of ransomware on macOS to date shows that there has yet to be a viable threat or any ransomware that has financially impacted any individuals or organizations.
At the present time, SentinelOne does not consider LockBit a serious threat for macOS endpoints. As noted above, the known samples are very much a Proof-of-Concept and not suitable for deployment by threat actors in their current state. However, news outlets have reported that LockBit developers do consider a Mac file locker an active project, meaning that this situation may change in the near future.
As a precaution, the SentinelOne agent detects LockBit for Mac and protects macOS endpoints from executing the sample.
macOS security teams whose organizations are not protected by SentinelOne may refer to the Indicators of Compromise below for threat hunting and detection.
Are the big game hunters coming to a macOS endpoint near you? Not yet, but that doesn’t mean they won’t. The development of a Mac-specific ransomware variant suggests that the thought has obviously occurred to some threat actors sufficiently to invest time in producing a test sample, but that sample is far from ready for use against real targets. More importantly, from a threat actor’s point of view, locking files on Macs is not really a viable use case, though it may create some headlines, since service disruption in many cases is not likely to be severe – few organizations use Mac servers for essential services. In addition, worming from one Mac to another in the way Windows malware often does is exponentially more difficult on Macs. Consequently, the return on investment for a ransomware actor in deploying file locking malware on a Mac endpoint is likely to be substantially lower than similar attacks on Windows and Linux servers
Stealing data, however, is very much a viable use case for threat actors targeting Macs. As ransomware actors in general have transitioned to extorting enterprises to prevent stolen data being leaked, it should not come as a surprise if LockBit and other cybercrime outfits begin turning their attention to ways to achieve the same on macOS. Indeed, infostealers are very much a concern on the platform and security teams are advised to review our recent publications on these and on how threat actors can compromise Macs in the enterprise. If LockBit and other ransomware actors are coming for enterprises with macOS devices, it is the theft of data rather than the locking of files that will provide them with the most lucrative rewards.
File name | SHA1 |
locker_Apple_M1_64 | 2d15286d25f0e0938823dcd742bc928e78199b3d |
locker_Apple_M1_64 | 864f56b25a34e9532a1175d469715d2f61c56f7f |
!!!-Restore-My-Files-!!! | ef958f3cf201f9323ceae9663d86464021f8e10d |
private rule Macho { meta: description = "private rule to match Mach-O binaries" condition: uint32(0) == 0xfeedface or uint32(0) == 0xcefaedfe or uint32(0) == 0xfeedfacf or uint32(0) == 0xcffaedfe or uint32(0) == 0xcafebabe or uint32(0) == 0xbebafeca } rule LockBit_for_Mac { meta: author = "Phil Stokes, @philofishal" description = "Rule to detect LockBit sample with Arm64 architecture for Apple M1" date = "18 April 2023" sha1_a = "2d15286d25f0e0938823dcd742bc928e78199b3d" sha1_b = "864f56b25a34e9532a1175d469715d2f61c56f7f" ref = "https:/s1.ai/LockBit-Mac" strings: $ransom = { 58 5b 55 5c 19 4b 58 57 4a 56 54 4e 58 4b 5c 19 } // encrypted ransom note string $sysctl = { 4a 40 4a 5a 4d 55 19 51 4e 39 5e 4b 5c 49 19 51 } // encrypted sysctl hw grep string $label = "bSelfRemove" condition: Macho and all of them }