About AMOS Stealer

AMOS Stealer, active since 2023, remains a persistent and evolving threat to macOS users. Commonly referred to as Atomic Stealer or Rod Stealer, this malware is known for its sophisticated attack vectors and consistent targeting of Apple devices. One of its primary techniques involves leveraging legitimate macOS applications by injecting malicious code or replacing official download links with those leading to attacker-controlled command-and-control (C2) servers. By impersonating trusted software sources, AMOS effectively deceives users and facilitates unauthorized access to sensitive data.

In this post, the associates of the Amos Stealer are presenting an article explaining the structure of logs generated by the Atomic Stealer. They mention some modifications made to the usual log format and describe them in detail.

The post gives details about the browsers and crypto wallets targeted by the Atomic Stealer. It shows that the stealer collects data like passwords, cookies, and wallet information from several popular apps. One of the people linked to this activity is @Ping3r, as seen in the image. The post was shared in a Telegram group. The most recent post regarding the stealer is shown below.

The post states that each infected system is manually checked for cryptocurrency-related data, such as seed phrases or private keys. They also review files and photos from compromised accounts and extract group and channel data for resale. The post further promotes competitive pricing for Tdata purchases and describes their revenue-sharing model.

This blog explains how Attackers created a fake version of Homebrew, the macOS package manager, to spread the Atomic macOS Stealer malware. Instead of compromising the real site, they built a lookalike to trick users. The malware was spread through a malicious DMG file or a script that silently installed both the malware and the real Homebrew.

Technical Analysis

This section provides an in-depth breakdown of the AMOS Stealer’s behavior, components, and methods of operation. We will analyze how the malware is deployed, the techniques it uses to collect sensitive data from infected macOS systems. The goal is to uncover the technical details behind its execution flow and understand the infrastructure supporting its operations.

Reverse Engineering the code fragments

The program begins its execution from the
start function, which serves as the main entry point.

Early in the execution flow, it calls the function
sub_100064E50 , whose primary role is to handle thread creation. This function spawns a new thread to execute another function named sub_10004C220.

Upon inspecting this function, an error message appears. However, the issue does not lie with the function’s structure itself, but rather with the presence of hidden malicious code. The code is not written in plain text, instead, it is stored as raw byte data, with each character XORed using a specific key. This method of obfuscation is often used to hide the true functionality of the code and avoid detection during static analysis.

After combining all the characters, the following string is revealed:

"osascript -e 'display dialog "To launch the application, you need to update the system settings" with icon caution default answer "GivingUpdator30" with hidden answer'"
This command is used to trigger a deceptive macOS dialog box, prompting the user to enter sensitive information under the guise of a system update.

Upon further analysis, we identified a location where the _system function was invoked. Immediately after this call, several additional functions were executed. For clarity and ease of understanding, we have renamed these functions with descriptive identifiers.
The _system function is typically used when a user-space application needs to execute a command or interact directly with the system performing malicious actions.

Immediately following the system call, the next function opens a file in write mode and uses the sw_vers command. The sw_vers command is a macOS utility that provides detailed information about the current version of the operating system, including the build and product name, which is then saved to the file.

The following functions contain malicious code responsible for stealing login credentials from browsers and cryptocurrency wallets and much more , which we’ll now analyze in sequence.

Features

osascript -e "set base folder pat to home folder as text"

The string was extracted from the program, and it means that the script is using AppleScript to get the current user's home folder path and store it as text in a variable named base folder pat. This is likely done to access or store files in the user-specific directory during execution.

e "make new folder at folder base folder path with properties {name: FileGrabber}"

This AppleScript command creates a new folder named
FileGrabber inside the base folder path. It is likely used by the malware to store the stolen or collected data in an organized manner within the victim's system.

set file grabber folder path to (path to home folder) as text

It uses AppleScript to assign the user's home directory path (converted to text) to a variable named FileGrabberfolder path. This allows the script to access or save files specifically within the user's home directory.

The stealer targets browser autofill information stored in SQLite databases, such as Chrome’s ‘Web Data’ or Firefox’s ‘formhistory.sqlite’, to extract sensitive user details.

The script handles data by storing it in variables, then uses the
open() function to access files and copy data into them. After that, it deletes some of the data by calling the delete operator. This process helps in the manipulation and transfer of sensitive data while remaining hidden from typical detection methods.

Browsers

This stealer is specially targeting browser data stealer targeting multiple web browsers and their sensitive data files. It does by initially querying the user information from Chrome, Arc, Brave, Edge, Vivaldi, Yandex, Opera, and Opera browsers which It does by first identifying browser installation directories, then manually searching for and copying sensitive files including cookies, login data (stored passwords), web data (autofill information).

For each browser, it specifically targets high-value files like "Cookies" (containing authentication tokens), "Login Data" (passwords), "Web Data" (payment information and addresses), and specialized directories like "IndexedDB" and "Local Storage" that may contain additional sensitive information.

The stealer follows a multi-stage process where it creates organized folder structures with random names. This randomization, seen multiple times in the code, helps in storing the stolen data before sending it to the attacker’s C2 server.

Wallets

This malware is designed to steal data from popular cryptocurrency wallets such as Exodus, Electrum, Coinomi, Guarda, Wasabi, Atomic, and Ledger. It scans the system for wallet-related data by checking specific locations under the '/Wallets/' directory.

The stealer then systematically scans user directories (particularly "/Users/" paths on macOS systems) looking for wallet installation folders. When it finds target wallets, it creates corresponding directories in its exfiltration structure and uses functions like mkdir_p, stat_INODE64, and opendir_INODE64 to navigate the file system.

Telegram

AMOS also targets Telegram Desktop data by scanning for the
user_data and emoji directories within the Telegram application folder. It traverses the Telegram directory structure, creating mirror copies of these critical folders and their contents in a destination controlled by the attacker. The user_data directory is particularly valuable as it contains message history, contacts, and authentication information, while the emoji directory contains cached media elements. Once these data is found, it then moves to going ahead with copying all the content to randomly generated folder names.

System Information

The malicious code, after performing several XOR operations on the system data, reveals two key strings: "hardware data type” and "display data type". These strings suggest that the malware is interacting with system-level data, related to the configuration and details of hardware and display settings.

File Stealing

Also with Keychain and different file types, AMOS targets diverse information sources across macOS systems, including Safari browser cookies (es.binarycookies) and Cookie folders for web credentials. It navigates systematically through the filesystem, focusing on Safari directories and home folders using commands like "set homePath" for path manipulation. It explicitly seeks out Apple-specific locations, including group container identifiers (group.com.apple), container groups, and Library paths to maximize its data harvesting capabilities from multiple system locations.

The stealer collect files from the victim’s Desktop, Downloads, and Documents folders, specifically targeting files with extensions such as "txt", "pdf", "docx", "wallet", "key", "keys", and "doc". It also attempts to steal the Keychain database file located at “/Library/Keychains/login.keychain-db”, which may contain saved passwords and other sensitive information.

AMOS also navigates paths to specific folders, referencing a "sourceFilePlder" in its code to locate critical files. Most notably, it explicitly targets the Apple Notes database ("NoteStore.sqlit"), allowing it to extract any sensitive information users might store in their Notes application, such as passwords, account details, or cryptocurrency recovery phrases.

The script downloads a tampered version of Ledger Live, a popular cryptocurrency wallet manager. This modified application acts as a backdoor, potentially allowing attackers to steal sensitive wallet data or credentials once the user interacts with the fake app.

Infrastructure Analysis

As, we can see that AMOS's command and control ( C2) infrastructure implementation in its decompiled code, we can see that the function which we renamed asc2_website constructs a HTTP request by initially constructing the HTTP headers and request parameters for communication with its C2 server, also we can see various other parameters such as-F Build which mentions the build ID of the stealer, overall this function is basically crafting a HTTP header and exfiltrating the stolen information.

Also, while we saw the code which was downloading the backdoor, which was85.28.0.4

On searching, we saw that the malicious IP address has been linked to AMOS Stealer.

Indicators of Compromise (IOCs)

YARA Rule

                rule AMOS_Stealer {
                  meta:
                    description = "YARA Rule to detect AMOS Stealer"
                  strings:
                    $urand_device = "/dev/urandom" ascii wide nocase
                    $sys_info = "sw_vers" ascii wide nocase
                    $telegram = "Telegram" ascii wide nocase
                    $filegrabber = "Grabber" ascii wide nocase
                    $osascript = "osascript" ascii wide nocase
                    $http = "http:" ascii wide nocase
                    $apikey = "apikey" ascii wide nocase
                    $browser_chrome = "Chrome" ascii wide nocase
                    $browser_arc = "Arc" ascii wide nocase
                    $browser_vivaldi = "Vivaldi" ascii wide nocase
                    $browser_edge = "Edge" ascii wide nocase
                    $browser_yandex = "Yandex" ascii wide nocase
                    $wallet_exodus = "Exodus" ascii wide nocase
                    $wallet_electrum = "Electrum" ascii wide nocase
                    $wallet_guarda = "Guarda" ascii wide nocase
                    $wallet_ledger = "Ledger" ascii wide nocase
                    $malicious_ip = "85.28.47"
                  condition:
                    $urand_device and $sys_info and $telegram and $filegrabber and $osascript and $http and $apikey and 
                    (any of ($browser*) or any of ($wallet*))
                    and $malicious_ip
                }
                  

MITRE ATT&CK Mapping