Malware Research - Atomic macOS Stealer (AMOS) Variant

I was given the opportunity to conduct malware analysis on a suspicious program downloaded by one of our employees at work. I was praised for my efforts and dedication in analyzing it which gave me the motivation to keep on learning about malware analysis and CTI. Here is my writeup on the whole incident.

Executive Summary

On 12 September 2024, Cortex XDR flagged a suspicious program downloaded by one of our employees via spear phishing. Upon further analysis, the downloaded program was discovered to be a variant of Atomic macOS Stealer (AMOS) disguising itself as a fake OpenVPN client. AMOS is known to be a common infostealer that primarily targets macOS systems. It’s main functionality is to extracts sensitive information from infected systems and sends them back to the attacker’s C2 server, including:

• System files
• Account passwords
• Browser data
• Session cookies
• Cryptocurrency wallets

Attachment (password is infected)

Technical Analysis

The victim received an email from a company called Vantage Point Media with the email domain vpmediatech[.]com. Inside the email was a Google Form that acted as a hiring test where it prompted the victim to input their email address, full name and answers for a set of interview questions.

On the final page, the victim will then be prompted to download and install a fake OpenVPN client from the download URL https://openvpn[.]tech/vpn-download, which will initiate the download based on the user’s operating system.

If the victim was using Windows, accessing the download link will redirect the user to https://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 https://utv4fun[.]com/kusaka.php?call=vpn to automatically fetch and download a DMG file.

Notice how a different DMG file was downloaded each time the download link was accessed, this was most likely an evasion technique implemented to avoid static detection. This will be discussed further in the report, but just know that the main function of the infostealer 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.

Decompiling 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 can be identified, with the encryption function sub_1000009A2.

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.

The decrypted payload was identified to be a malicious AppleScript executed through osascript. The decrypted payload can be viewed here.

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

It then retrieves the current username to construct a path to the user’s home directory. It also creates a staging directory on /tmp to store the stolen data. The staging directory name seems to be generated using a random four-digit number in the range of 1000-9999.

The data extraction 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 the 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 wallet applications. The payload then proceeds to recursively read the stored data in the mapped directories to extract Chromium-based browser data (cookies, web data, plugins, etc.) and JSON files for specific cryptocurrency wallet applications.

The payload was also extracting 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 FileGrabber 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.

The payload compresses the staging directory into a ZIP file out.zip to be exfiltrated to the C2 server using curl. The ZIP file was sent via a HTTP POST request to http://85.209.11[.]155/joinsystem/ using a predefined user and BuildID.

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 multiple hashes generated for the DMG file as discussed previously.

Finally, the payload covers its track by removing the staging directory and ZIP file from the system after exfiltration.

Indicators of Compromise

Indicators	Type	Description
7f4582259482af646aecd6b1addb50cb283706753376e7dbadb4c33ab3ddff21	SHA256	DMG file
9793fc09d1f18b16cc7e1af52e68957387eda27e904fe44cdad904016fcb55b8	SHA256	Mach-O binary
vpmediatech[.]com	Domain	Email Address Domain
https://docs.google[.]com/forms/d/e/1FAIpQLSdjxyobIi5WKyT9dvL8NgYBk6434oYqhGomOHrCDPSBK1shCw/viewform?usp=sf_link	URL	Malicious Google Form
https://openvpn[.]tech/vpn-download	URL	Initial download link
https://utv4fun[.]com/kusaka.php?call=vpn	URL	Redirected download link (macOS)
https://openvpn-win[.]pages.dev	URL	Redirected download link (Windows)
openvpn[.]tech	Domain	Domain
85.209.11[.]155	IP address	C2 server