MacOS Malware Impersonates The Unarchiver App to Steal User Data
Published on
Published on
Published on
Jul 30, 2024
Jul 30, 2024
Jul 30, 2024
During routine research on Hatching Triage, we discovered a submission for the domain tneunarchiver[.]com. This site, designed to mimic the legitimate theunarchiver[.]com, replicated the web page precisely, except for the altered download button.
The Unarchiver bills itself as "the top application for archives on Mac. It's a RAR extractor, it allows you to unzip files, and works with dozens of other formats."
Upon clicking the "Download" button, the disk image (TheUnarchiver.dmg, SHA-1: 4932e7da6b21e1e37c507c42d40951ba53a83cf4) is saved to the user's computer.
Hatching Triage correctly identifies the domain as probable phishing, but analysis of the file results in a score of 1/10. Seeing such a low score does not necessarily mean the file is benign but could indicate an error/exception occurring during execution.
The file was also not detected as malicious by any of the security vendors in VirusTotal.
According to the above analysis scores, the disk image might be legitimate; however, would anyone register a look-alike domain and copy the web page just to offer the actual application? The short answer is yes, and we've seen this with previous phishing sites, but something feels off here.
Let's dive deeper into TheUnarchiver.dmg to uncover any hidden malicious behaviors that may have slipped through undetected.
This post covers a basic analysis intended to determine the capabilities and intent of the malware.
Disk Image Analysis
Now that we're in a safe environment to dig deeper into the suspicious file, let's first figure out basic data like signing information and then manually mount the disk image using hdiutil.
When paired with the "attach" option, hdiutil will allow us to analyze any files within the disk image without double-clicking/running the file on the system.
The "WhatsYourSign" tool by Patrick Wardle unsurprisingly finds that the disk image is not signed.
Let's move to the mounted file, which, if you're following along in the terminal, can be found in the /Volumes directory.
Before jumping into the binary file you've likely focused on, let's review some essential files and folders that are now accessible.
As the name suggests, the "Contents" folder houses all files and subdirectories of the disk image.
The "_CodeSignature" folder indicates that the binary has code-signing information.
The "MacOS" folder contains the executable binary, which runs when users double-click the app icon, familiar to most as part of the installation process.
The "Info.plist" file is the application's primary configuration file, offering insights into the macOS version on which the potentially malicious file was compiled.
Lastly, if you are a user of The Unarchiver, you likely have realized that the legitimate binary is named after the software and not "CryptoTrade."
Mach-O Analysis
Just like the disk image, not one of the vendors in VirusTotal identified the CrytpoTrade file as malicious.
In the last section, we noted the presence of code-signing information for the CryptoTrade file.
Using the WhatsYourSign tool again, we can gather additional information regarding who/how the file was signed.
We see from the image above that the file uses an ad-hoc signature, which we can grab hashes for, but it is, unfortunately, as far as we can go regarding signing info.
The output above in Figure 7 under "Item Type:" hints that we are dealing with a universal binary capable of running on both Intel and ARM architectures.
We can verify this using the below command in the terminal:
otool -fv CryptoTrade
As previously mentioned, the info.plist file is the main configuration file for the app, but it also contains information that may be interesting to us during file triage.
The first key in the file, BuildMachineOSBuild, includes a key value of 23f79, indicating the malware was compiled on a macOS 14.5 (May 13, 2024) build.
*Hatching Triage offers macOS 10.15 for sandbox analysis. There could be compatibility issues that are to blame for the low detection number.
While interesting, the information we found so far doesn't tell us much about the intent of the malware.
Let's use the command below to obtain a text file of CryptoTrade's shared libraries.
otool -L CryptoTrade > ~/malware_analysis/cryptotrade_libs.txt
Using the terminal or your favorite text editor, we can see multiple references to the Swift programming language, indicating that CryptoTrade is written in Swift.
We could continue using otool to dump method names, disassembly, and more to gather additional information, however, that's best left for another post.
When it comes to file analysis, you can't beat the Strings command or Floss. Quickly scanning through the text file output reveals a new domain and code likely used to capture a user's password.
From the output above, we can theorize that the user is prompted for their password, which is likely part of the malicious installation process.
Even more interesting is a full URL: https://cryptomac[.]dev/download/grabber.zip.
As of the time of this post, the domain and zip file were still available.
Grabber.zip Analysis
I feel repetitive here, but grabber.zip was also not found to be malicious in VirusTotal.
Unzipping the file resulted in 10 separate shell scripts, all named explicitly for their function in stealing user information.
We'll start by looking at main.sh and send.sh then cover a few additional scripts that caught our attention.
main.sh sets the directory path, ' $HOME/Library/Application Support/Google Helper', and deletes it if it already exists. Then, curl is used to get the public IP address, and the results are appended to 'ip.txt'.
grab_docs.sh, grab_keychain.sh, grab_browsers.sh, collect_info.sh, and grab_wallets_extensions.sh are run from their specified path, passing the directory path as an argument.
send.sh switches to the directory path set in the main shell script, and creates a zip file containing the stolen information of the victim.
The zip file is then sent via curl to a separate URL, http://81.19.137[.]179/api/index.php.
The grab_apps.sh file raised suspicions due to the presence of comments in Russian, suggesting the malware author might be from a Russian-speaking region or at least familiar with the language.
Using machine translation, the first comment in English is: "Path to the Telegram folder on your current Mac" and the second, "Copy files and folders."
Conclusion
In this post, we analyzed a malicious disk image that appears to not yet be known to security vendors, but has similar traits to the growing number of stealers targeting MacOS users like Amos, Poseidon, etc.
Impersonating a well-known app like The Unarchiver, the malicious binary written in Swift steals information from victim systems, and exfiltrates that data to infrastructure using a common URL path, /api/index.php.
To stay ahead of emerging threats, contact us to book a free demo today.
During routine research on Hatching Triage, we discovered a submission for the domain tneunarchiver[.]com. This site, designed to mimic the legitimate theunarchiver[.]com, replicated the web page precisely, except for the altered download button.
The Unarchiver bills itself as "the top application for archives on Mac. It's a RAR extractor, it allows you to unzip files, and works with dozens of other formats."
Upon clicking the "Download" button, the disk image (TheUnarchiver.dmg, SHA-1: 4932e7da6b21e1e37c507c42d40951ba53a83cf4) is saved to the user's computer.
Hatching Triage correctly identifies the domain as probable phishing, but analysis of the file results in a score of 1/10. Seeing such a low score does not necessarily mean the file is benign but could indicate an error/exception occurring during execution.
The file was also not detected as malicious by any of the security vendors in VirusTotal.
According to the above analysis scores, the disk image might be legitimate; however, would anyone register a look-alike domain and copy the web page just to offer the actual application? The short answer is yes, and we've seen this with previous phishing sites, but something feels off here.
Let's dive deeper into TheUnarchiver.dmg to uncover any hidden malicious behaviors that may have slipped through undetected.
This post covers a basic analysis intended to determine the capabilities and intent of the malware.
Disk Image Analysis
Now that we're in a safe environment to dig deeper into the suspicious file, let's first figure out basic data like signing information and then manually mount the disk image using hdiutil.
When paired with the "attach" option, hdiutil will allow us to analyze any files within the disk image without double-clicking/running the file on the system.
The "WhatsYourSign" tool by Patrick Wardle unsurprisingly finds that the disk image is not signed.
Let's move to the mounted file, which, if you're following along in the terminal, can be found in the /Volumes directory.
Before jumping into the binary file you've likely focused on, let's review some essential files and folders that are now accessible.
As the name suggests, the "Contents" folder houses all files and subdirectories of the disk image.
The "_CodeSignature" folder indicates that the binary has code-signing information.
The "MacOS" folder contains the executable binary, which runs when users double-click the app icon, familiar to most as part of the installation process.
The "Info.plist" file is the application's primary configuration file, offering insights into the macOS version on which the potentially malicious file was compiled.
Lastly, if you are a user of The Unarchiver, you likely have realized that the legitimate binary is named after the software and not "CryptoTrade."
Mach-O Analysis
Just like the disk image, not one of the vendors in VirusTotal identified the CrytpoTrade file as malicious.
In the last section, we noted the presence of code-signing information for the CryptoTrade file.
Using the WhatsYourSign tool again, we can gather additional information regarding who/how the file was signed.
We see from the image above that the file uses an ad-hoc signature, which we can grab hashes for, but it is, unfortunately, as far as we can go regarding signing info.
The output above in Figure 7 under "Item Type:" hints that we are dealing with a universal binary capable of running on both Intel and ARM architectures.
We can verify this using the below command in the terminal:
otool -fv CryptoTrade
As previously mentioned, the info.plist file is the main configuration file for the app, but it also contains information that may be interesting to us during file triage.
The first key in the file, BuildMachineOSBuild, includes a key value of 23f79, indicating the malware was compiled on a macOS 14.5 (May 13, 2024) build.
*Hatching Triage offers macOS 10.15 for sandbox analysis. There could be compatibility issues that are to blame for the low detection number.
While interesting, the information we found so far doesn't tell us much about the intent of the malware.
Let's use the command below to obtain a text file of CryptoTrade's shared libraries.
otool -L CryptoTrade > ~/malware_analysis/cryptotrade_libs.txt
Using the terminal or your favorite text editor, we can see multiple references to the Swift programming language, indicating that CryptoTrade is written in Swift.
We could continue using otool to dump method names, disassembly, and more to gather additional information, however, that's best left for another post.
When it comes to file analysis, you can't beat the Strings command or Floss. Quickly scanning through the text file output reveals a new domain and code likely used to capture a user's password.
From the output above, we can theorize that the user is prompted for their password, which is likely part of the malicious installation process.
Even more interesting is a full URL: https://cryptomac[.]dev/download/grabber.zip.
As of the time of this post, the domain and zip file were still available.
Grabber.zip Analysis
I feel repetitive here, but grabber.zip was also not found to be malicious in VirusTotal.
Unzipping the file resulted in 10 separate shell scripts, all named explicitly for their function in stealing user information.
We'll start by looking at main.sh and send.sh then cover a few additional scripts that caught our attention.
main.sh sets the directory path, ' $HOME/Library/Application Support/Google Helper', and deletes it if it already exists. Then, curl is used to get the public IP address, and the results are appended to 'ip.txt'.
grab_docs.sh, grab_keychain.sh, grab_browsers.sh, collect_info.sh, and grab_wallets_extensions.sh are run from their specified path, passing the directory path as an argument.
send.sh switches to the directory path set in the main shell script, and creates a zip file containing the stolen information of the victim.
The zip file is then sent via curl to a separate URL, http://81.19.137[.]179/api/index.php.
The grab_apps.sh file raised suspicions due to the presence of comments in Russian, suggesting the malware author might be from a Russian-speaking region or at least familiar with the language.
Using machine translation, the first comment in English is: "Path to the Telegram folder on your current Mac" and the second, "Copy files and folders."
Conclusion
In this post, we analyzed a malicious disk image that appears to not yet be known to security vendors, but has similar traits to the growing number of stealers targeting MacOS users like Amos, Poseidon, etc.
Impersonating a well-known app like The Unarchiver, the malicious binary written in Swift steals information from victim systems, and exfiltrates that data to infrastructure using a common URL path, /api/index.php.
To stay ahead of emerging threats, contact us to book a free demo today.
Related Posts:
Threat Hunting Platform - Hunt.io
Products
Hunt Intelligence, Inc.
Threat Hunting Platform - Hunt.io
Products
Hunt Intelligence, Inc.
Threat Hunting Platform - Hunt.io
Products
Hunt Intelligence, Inc.