Malware Analysis - Atomic macOS Stealer

Distribution

The victim received a phishing email from a company called Vantage Point Media which had a link to a fake hiring test form made with Google Forms. Accessing the form, the victim was prompted to enter their email address, full name, and responses to a series of interview questions.

On the final page of the form, the victim will then be prompted to install a fake OpenVPN client software from the download URL hxxps://openvpn[.]tech/vpn-download. Analyzing the download URL, it seems that both Windows and macOS users will be redirected to a specific download URL for further distribution of malware.

If the victim was using Windows, accessing the download link will redirect the user to hxxps://openvpn-win.pages[.]dev to automatically fetch and download a MSI installer. However, the scope of this report will only be on macOS for now.

If the victim was using macOS, accessing the download link will redirect the victim to hxxps://utv4fun[.]com/kusaka.php?call=vpn to automatically fetch and download a DMG file.

Note: Notice how a different DMG file was downloaded each time the download link was accessed, this was most likely an evasion technique where it modifies certain parts of its code to avoid static detection. This will be discussed further in the report, but just know that the main function of this malware will remain the same.

Mounting the DMG file on a macOS virtual machine, an on-screen prompt will be shown to instruct the user to execute a Mach-O binary by right clicking and opening it directly. This was a common tactic used to override Apple’s integrated security feature (GateKeeper) and execute unsigned applications.

Upon further analysis, the Mach-O binary was identified to be ad-hoc signed which means that it might be blocked by Gatekeeper as it does not contain any cryptographic proof.

Launching the Mach-O binary, the user will be prompted to input their password. This was most likely to trick the user in providing root privileges for the malware to access certain macOS utilities and files.

Statically analyzing the Mach-O binary with otool, a long hex string can be identified, suggesting that the payload might be encoded in hex.

Coincidentally, a 32-byte hex string can be identified right below the encoded payload, most likely a decryption key.

To identify the encryption method, the Mach-O binary was further decompiled with IDA. At the main function, both hex values and the encryption function sub_1000009A2 can be identified immediately.

Decompiling the encryption function, we can see the a 256-byte array substitution box was initialized and scrambled using the key. Then, the scrambled substitution box created in previous stage was used to generate a keystream.

Later, each byte of payload was XOR’ed with each byte of keystream generated in previous stage. Hence, the encryption algorithm was discovered to be RC4.

Decrypting the payload reveals a malicious AppleScript launched via the osascript utility.

Setup Staging Directory

The payload begins by ensuring the Terminal window stays hidden while it runs in the background to conceal itself from the user.

It then constructs a path to the user’s home directory and creates a staging directory on /tmp to store the collected data. The staging directory name seems to be generated using a random four-digit number in the range of 1000-9999.

Collecting Data

The data collection process begins with the system information including software, hardware, and display configurations using the system_profiler utility. The result of this command is then written to a file named “info” under the staging directory.

The payload constructs a path to the user’s Application Support directory, which is used to locate various application data. It then calls a function to retrieve the user’s password via an authentication prompt using the DSCL utility.

If the password entered was valid, the payload will attempt to retrieve the Chrome password from the macOS keychain and write it to a file named “masterpass-chrome” under the staging directory. If not, the payload enters a loop that will continuously prompt the user for the valid password.

Several mappings were created to define the directory paths for specific Chromium-based browsers and cryptocurrency wallets. The payload then proceeds to recursively read the collected data in the mapped directories to extract Chromium-based browser data and JSON files for specific cryptocurrency wallets.

The payload also collected Safari cookies, Apple Note database and files with the extension of .pdf, .docx, .doc, .wallet and .keys on the Desktop, Documents and Downloads folder. These extracted data are copied and placed within a folder named “FileGrabber” under the staging directory.

Interesting observation: The function seem to only extract files that do not exceed the file size of 10 MB before copying them to the “FileGrabber” folder. This was most likely done to prevent network bandwidth issues, server limitations, and timeouts during data exfiltration to the C2 server.

Data from other sources including Firefox data, keychain database and Telegram data, was also extracted and stored as different files under the staging directory.

Exfiltrate Data to C2

Before being exfiltrated, the staging directory is compressesed into a ZIP archive using the ditto utility. The ZIP archive was then sent via a HTTP POST request to the C2 hxxp://85.209.11[.]155/joinsystem/ using curl. Upon further analysis, the user and BuildID values seem to be different for each payload from other downloaded DMG files. Hence, this was most likely the root cause of having different hashes generated for the DMG file as discussed previously.

Indicator Removal

Finally, the payload removes the staging directory and ZIP archive from the infected machine after exfiltration.