A month ago, we discovered some cracked apps circulating on pirating websites and infected with a Trojan proxy. The malicious actors repackaged pre-cracked applications as PKG files with an embedded Trojan proxy and a post-install script initiating the infection. We recently caught sight of a new, hitherto unknown, macOS malware family that was piggybacking on cracked software. The threat proved far more potent than an unauthorized proxy server installation.
The samples we found could be successfully run on macOS Ventura 13.6 and later, suggesting that the operators were targeting only users of the newer operating system versions on both Intel processors and Apple silicon machines. The compromised disk images contain a program named "Activator" and the application that the user is looking to install. Opening/mounting the image brings up a window with installation instructions.
Window with installation instructions
The instruction tells the user to copy the app to /Applications/ and then launch Activator. The latter looks fairly unsophisticated: just a PATCH button that displays a password prompt when clicked.
Activator window and password form
A look under the hood revealed an interesting fact right away: the application in the Resources folder somehow contained a Python 3.9.6 installer and an extra Mach-O file with the nametool. The main Fat Mach-O file, tellingly namedGUI, essentially implemented the PATCH button, clicking which launched two events:
Once running, tool checked the system for an installed copy of Python 3, and if it did not find one, it installed that which it had previously copied to**/tmp/**. Next, it "patched" the downloaded app:tool compared the first 16 bytes of the modified executable with a sequence hardcoded inside Activator and removed them in the case of a match:
Checking the first 16 bytes of the executable
The app amusingly started working and appeared to have been cracked. The trick was that the malicious actors had taken pre-cracked application versions and added a few bytes to the beginning of the executable, thus disabling it to make the user launch Activator.
A completed "patching" kicked off the main payload, with the sample reaching out to its C2 for an encrypted script. The program obtained the C2 URL by stringing together words from two hardcoded lists and adding a random sequence of five letters as a third-level domain name. With this URL, the sample made a request to a DNS server as an attempt to get a TXT record for the domain. This was a fairly interesting and unusual way of contacting a command-and-control server and hiding activity inside traffic, and it guaranteed downloading the payload, as the response message came from the DNS server. TXT records could contain miscellaneous domain details that the application might require, so a request like that looked perfectly normal per se.
We tried every possible combination of the hardcoded words, which were the same for every sample we studied, to find only one functional domain name: imohub[.]net. The exact third-level domain name was irrelevant as long as it was part of the request. The response from the DNS server contained three TXT records, which the program later processed to assemble a complete message. Each record was a Base64-encoded ciphertext fragment whose first byte contained a sequence number, which was removed during assembly. The ciphertext wasAES-encrypted inCBC mode. The decrypted message contained the following Python script.
Decrypted script
Before running the script, tool went through the following steps:
Killing NotificationCenter processes
Launch agent code
As you can see from the decrypted script, it reached out to apple-health[.]org every 30 seconds and tried to download and execute the following script. The script was given 14,400 seconds to run, after which the process was killed and a new version of the script was downloaded.
At first we thought the downloaded Python script was out of date, as apple-health[.]org C2 server was not responding to our requests. However, after some time, we managed to obtain a payload in the form of another Python script. That finally revealed the malware operators' goals: the main function of the script was to execute arbitrary commands it received from the server. Judging by the command processing code, these came in the form of further Base64-encoded Python scripts.
Code that executes received commands
Besides executing commands, the script harvested and sent to the server the following information:
At the time of our investigation, the server notably returned no commands and later stopped responding altogether. So, we downloaded the third-stage Python script again, only to find that the new version contained changes. In particular, the developers had changed the "metadata" stored at the beginning of the program and containing the C2 server IP address and domain name, and the program GUID and version. These were apparently updated automatically inside the script as soon as the server IP address changed, which happened approximately every 10β20 minutes. There were also updates to the functional code that had to be made by humans (see the images below).
Three versions of the script side by side (left to right: the first version 18c564a5cc4b7414df8345a8bdce7418, and the two subsequent versions f4282d7e32c7e8ab4e075c572ac43803 and 352f0d288e612e4f66c50aaf9214a81d)
This suggested the malware campaign was still a work-in-progress. The commands we had been trying to get from the server simply might not have been written yet.
In addition to the aforementioned features, the script contained two more notable functions: check_exodus_and_hash() andcheck_btccore_and_hash().
Code that downloads an infected Exodus wallet
Both featured the domain apple-analyser[.]com, which served as the host for further payloads. The two functions had a similar purpose: checking if the device contained a relevant cryptowallet application, and if so, replace it with one downloaded fromapple-analyser[.]com. Besides the application, the server also stored a clean version of the Electron framework for launching a "new" version of Exodus, as well asExodus.scpt, which you can see in the screenshot above and which is only needed for running the following Shell command whenExodus.app starts.
do shell script "~/electron/Electron.app/Contents/MacOS/Electron ~/exodus"
quit
Were the malware operators indeed so kind as to help their victims with updating their wallets as compensation? Alas, it was naive to hope for the best: both wallets proved infected.
The malicious actors had infected Exodus by embedding their brainchild right at the beginning of the application: the filemain/index.js, which was the first to start when the application was launched.
Snippet of main/index.js containing the malicious implant
The code in the screenshot told us that the application sent into the channel with the name 334b4425988b47a5b67c92518f9815c6 some data, which subsequently went to22[.]imohub[.]workers[.]dev. Well, all we had to do now is find the exact piece of the code that sent the data, and this wasβ¦ drumrollβ¦wallet/index.js. As the code had no line breaks or indents, we gave it proper formatting and checked to see what was happening there.
Contents of wallet/index.js
The malicious actors had added to the wallet unlock handler a call to a function that simply sent an entered seed phrase to the C2 through the channel. There were no other new features.
Bitcoin-Qt was no JavaScript file, but rather a full-fledged Mach-O. As we searched the code for the C2 fromExodus, we soon realized thatBitcoin-Qt had a similar modus operandi: this application stole the wallet unlock password along with the wallet, its name, and the balance.
Code that sends the data to the C2
Thus, even in the absence of incoming commands from the C2, the program was still capable of inflicting significant damage on the user by stealing their cryptowallets.
The aforementioned cracked applications are one of the easiest ways for malicious actors to get to users' computers. To elevate their privileges, they just need to ask for the password, which typically causes no suspicions with users during software installation. That said, some of the things that the authors of the malware campaign had come up with, like placing the Python script inside a domain TXT record on the DNS server, were seriously ingenious. The script was later added to startup agents to download and execute the next-stage payload in an infinite loop, which enabled the malware operators to deliver updates to the infected machine. The final payload was a backdoor that could run any scripts with administrator privileges, and replace Exodus and Bitcoin cryptowallet applications installed on the machine with infected versions that stole secret recovery phrases the moment the wallet was unlocked.
MD5
C2 addresses
imohub[.]net
22[.]imohub[.]workers[.]dev
apple-analyser[.]com
apple-health[.]org