A practical detection guide for security engineers, incident responders, and macOS administrators. All checks use native macOS CLI tools — no third-party agents required.
Last updated: April 2026
Covers: AMOS variants including ClickFix, malext, cracked-app delivery, and OpenClaw supply-chain campaigns
- Detecting Atomic macOS Stealer (AMOS) via CLI
Atomic macOS Stealer (AMOS) is a Malware-as-a-Service infostealer that targets macOS systems. It exfiltrates Keychain passwords, browser credentials, cryptocurrency wallets, Apple Notes, Telegram sessions, and arbitrary files. Distribution methods have evolved from cracked software installers (2023–2025) to ClickFix social engineering, malvertising, and — most recently — supply-chain attacks via poisoned AI agent skills on platforms like OpenClaw.
Persistent variants install a root-level LaunchDaemon, drop hidden binaries in the user's home directory, and maintain a polling loop for C2 communication. This guide documents the forensic artifacts left behind and how to detect them from the terminal.
- Terminal.app or any shell (zsh/bash)
- Some commands require
sudo(elevated privileges) — noted inline - Unified log access (
log show) requires Full Disk Access for Terminal in System Settings → Privacy & Security → Full Disk Access
Tip: Run these commands from a known-clean admin account. If you suspect active compromise, boot into Recovery Mode or use an external boot disk to inspect the filesystem offline.
AMOS drops several hidden files in the user's home directory for persistence and staging. Check for known paths across all user accounts:
# Check current user's home directory
for f in ~/.helper ~/.agent ~/.mainhelper ~/.pass ~/.username; do
[ -e "$f" ] && echo '[!] FOUND: $f (modified: $(stat -f '%Sm' "$f"))'
done# Check all user home directories (requires sudo)
sudo find /Users -maxdepth 2 \
\( -name ".helper" -o -name ".agent" -o -name ".mainhelper" \
-o -name ".pass" -o -name ".username" \) \
-exec echo '[!] FOUND: {}' \; 2>/dev/null# AppleScript payload and staging files in /tmp
ls -la /tmp/starter /tmp/update 2>/dev/null
# Recent zip archives in /tmp (AMOS stages stolen data as zip before exfil)
find /tmp -name "*.zip" -mtime -1 -exec echo '[!] Recent zip: {}' \; 2>/dev/nullWhat you're looking for: Any of the dotfiles listed above existing in a user's home directory is a high-confidence indicator. The .pass file caches the harvested user password and persists across reinfections.
AMOS installs a root-level LaunchDaemon named com.finder.helper that runs /bin/bash ~/.agent with RunAtLoad and KeepAlive set to true, ensuring it survives reboots and process kills.
# Check if the known AMOS LaunchDaemon exists on disk
ls -la /Library/LaunchDaemons/com.finder.helper.plist 2>/dev/null# Check if it is currently loaded
launchctl list | grep "com.finder.helper"# Dump its contents for inspection
plutil -p /Library/LaunchDaemons/com.finder.helper.plist 2>/dev/nullSome variants use randomized plist names. Sweep for any LaunchDaemon referencing hidden dotfiles in user home directories:
# LaunchDaemons referencing hidden files in /Users (requires sudo)
sudo grep -rl '\.\(agent\|helper\|mainhelper\)' \
/Library/LaunchDaemons/ 2>/dev/null
# LaunchAgents (user-level persistence)
grep -rl '\.\(agent\|helper\|mainhelper\)' \
/Library/LaunchAgents/ ~/Library/LaunchAgents/ 2>/dev/null# Broader: any non-Apple LaunchDaemon — review manually
ls /Library/LaunchDaemons/ | grep -v "^com\.apple\."What you're looking for: A plist containing ProgramArguments pointing to /bin/bash and ~/.agent, with KeepAlive and RunAtLoad both true. Ownership should be root:wheel.
AMOS runs an infinite loop via .agent that uses osascript to detect the active console user, then executes .mainhelper (the C2 backdoor) in that user's context.
# Look for AMOS binary or script names in running processes
ps aux | grep -E '\.helper|\.mainhelper|\.agent' | grep -v grep# The specific osascript + stat call AMOS uses for user session detection
ps aux | grep 'stat -f' | grep '/dev/console' | grep -v grep# Any bash process executing a hidden dotfile from a home directory
ps aux | grep -E '/bin/bash.*/Users/.*\.' | grep -v grep# osascript processes running in a loop (general anomaly on most systems)
ps aux | grep 'osascript' | grep -v grepWhat you're looking for: Persistent osascript or /bin/bash ~/.agent processes running under a non-root user. On a clean system, you should not see osascript running as a background daemon.
AMOS fingerprints the victim machine by running system_profiler, sw_vers, uname, and ioreg, then writes the output to a file called Sysinfo.txt. It also checks for VM indicators (VirtualBox, Parallels, Apple Virtual Machine) and terminates if found.
# Search for the AMOS sysinfo staging file
find /tmp ~/Desktop ~/Documents -name "Sysinfo.txt" -mtime -7 2>/dev/null# Check unified log for rapid-fire system_profiler calls (abnormal pattern)
log show --predicate 'process == "system_profiler"' \
--last 1h --style compact 2>/dev/null | head -30# Multiple system_profiler invocations in quick succession are suspicious
log show --predicate 'process == "system_profiler"' \
--last 24h --style compact 2>/dev/null | wc -lWhat you're looking for: More than 2–3 system_profiler invocations within a short window (minutes) is unusual for normal user activity. The presence of Sysinfo.txt in /tmp is a strong indicator.
AMOS uses AppleScript to display a fake system dialog requesting the user's password. It also hides the Terminal window to avoid suspicion.
# Unified log: osascript displaying dialog boxes (fake password prompts)
log show --predicate 'process == "osascript"' \
--last 24h --style compact 2>/dev/null | grep -i "display dialog"# osascript hiding Terminal — known AMOS anti-analysis trick
log show --predicate 'process == "osascript"' \
--last 24h --style compact 2>/dev/null | grep -i "set visible.*false"# Any osascript activity at all in the last hour (review manually)
log show --predicate 'process == "osascript"' \
--last 1h --style compact 2>/dev/nullWhat you're looking for: osascript invoking display dialog with password-related strings, or setting Terminal window visibility to false. On most workstations, background osascript execution is rare and worth investigating.
AMOS copies the Keychain database to a staging directory and uses the open-source tool Chainbreaker to extract stored credentials.
# Keychain files outside their normal location
find /tmp /var/folders ~/Desktop ~/Documents \
\( -name "login.keychain-db" -o -name "*.keychain" \) 2>/dev/null# Check for Chainbreaker tool presence
find /tmp /usr/local/bin ~/.local /var/folders \
-name "chainbreaker" -type f 2>/dev/null
mdfind "kMDItemDisplayName == 'chainbreaker'" 2>/dev/null# Recent access to Keychain files (via unified log)
log show --predicate 'eventMessage CONTAINS "login.keychain"' \
--last 24h --style compact 2>/dev/null | grep -v "com.apple" | head -20What you're looking for: Copies of login.keychain-db in /tmp, /var/folders, or user-accessible directories. The Keychain file should normally only exist under ~/Library/Keychains/.
AMOS compresses all stolen data into a zip archive and exfiltrates it via HTTP POST to its C2 server, often over plaintext HTTP with custom headers and base64-encoded payloads.
# Active connections to known AMOS C2 IPs
lsof -i -nP 2>/dev/null | grep -E '38\.244\.158\.56|199\.217\.98\.33'# Outbound connections from osascript or hidden AMOS binaries
lsof -i -nP 2>/dev/null | grep -E 'osascript|\.helper|\.mainhelper'# Suspicious curl activity from /tmp (payload download or exfil)
log show --predicate 'process == "curl"' \
--last 24h --style compact 2>/dev/null | grep -E '/tmp/|/zxc/'# Outbound HTTP POST from non-browser processes (broad sweep)
log show --predicate 'process == "curl" AND eventMessage CONTAINS "POST"' \
--last 24h --style compact 2>/dev/nullNote: C2 infrastructure rotates frequently. The IPs above are known as of early 2026. For current IOCs, see the Known IOCs section.
Recent AMOS variants (malext, March 2026+) replace legitimate Ledger and Trezor wallet applications with trojanized copies downloaded from the C2.
# Check code signing on Ledger Live (should be signed by Ledger)
codesign -dv --verbose=2 /Applications/Ledger\ Live.app 2>&1 | grep -E 'Authority|TeamIdentifier'
# Check Trezor Suite
codesign -dv --verbose=2 /Applications/Trezor\ Suite.app 2>&1 | grep -E 'Authority|TeamIdentifier'# Verify the signing hasn't been stripped or replaced
codesign --verify --deep --strict /Applications/Ledger\ Live.app 2>&1
# Expected output on a clean app: "valid on disk"
# Tampered app will show: "invalid signature" or "not signed"What you're looking for: Wallet apps that are unsigned, signed by an unknown developer, or whose TeamIdentifier doesn't match the official vendor.
Copy and paste this into Terminal for a fast sweep of the highest-confidence indicators:
echo "========================================" && \
echo " AMOS Quick Scan — $(date)" && \
echo "========================================" && \
found=0 && \
for f in ~/.helper ~/.agent ~/.mainhelper ~/.pass ~/.username \
/Library/LaunchDaemons/com.finder.helper.plist \
/tmp/starter /tmp/update; do \
if [ -e "$f" ]; then echo '[!] FILE FOUND: $f'; found=1; fi; \
done && \
if launchctl list 2>/dev/null | grep -q "com.finder.helper"; then \
echo '[!] LAUNCHDAEMON LOADED: com.finder.helper'; found=1; \
fi && \
ps aux | grep -E '\.helper|\.mainhelper|\.agent' | grep -v grep | \
while read line; do echo '[!] SUSPICIOUS PROCESS: $line'; found=1; done && \
lsof -i -nP 2>/dev/null | grep -E '38\.244\.158\.56|199\.217\.98\.33' | \
while read line; do echo '[!] C2 CONNECTION: $line'; found=1; done && \
if [ "$found" -eq 0 ]; then echo '[OK] No AMOS indicators detected.'; fi && \
echo "========================================"If any indicators fire positive:
-
Do not reboot yet — capture volatile evidence first (running processes, open network connections, loaded LaunchDaemons).
-
Capture state:
# Snapshot running processes ps auxww > /tmp/amos_ir_ps_$(date +%s).txt # Snapshot network connections lsof -i -nP > /tmp/amos_ir_lsof_$(date +%s).txt # Snapshot loaded LaunchDaemons launchctl list > /tmp/amos_ir_launchctl_$(date +%s).txt
-
Kill persistence and remove artifacts:
# Unload and remove the LaunchDaemon sudo launchctl bootout system/com.finder.helper 2>/dev/null sudo rm -f /Library/LaunchDaemons/com.finder.helper.plist # Remove AMOS files rm -f ~/.helper ~/.agent ~/.mainhelper ~/.pass ~/.username rm -f /tmp/starter /tmp/update
-
Rotate credentials immediately:
- Change your macOS user password
- Rotate all passwords saved in browsers and Keychain
- Revoke and regenerate any API keys, SSH keys, or tokens on the machine
- If cryptocurrency wallets were present, transfer assets to a new wallet from a clean device
-
Reinstall affected applications (especially crypto wallets) from official sources.
-
Review unified logs for the exfiltration window to understand what data was sent and to which C2.
IOCs rotate frequently. Always cross-reference with current threat intel feeds.
Filesystem Paths:
| Path | Description |
|---|---|
~/.helper |
Primary stealer binary |
~/.agent |
Polling loop script (bash) |
~/.mainhelper |
Second-stage C2 backdoor |
~/.pass |
Cached user password (persists across reinfections) |
~/.username |
Cached username |
/Library/LaunchDaemons/com.finder.helper.plist |
Root-level persistence plist |
/tmp/starter |
Staging artifact |
/tmp/update |
AppleScript payload |
/tmp/Sysinfo.txt |
System recon output |
Network Indicators (as of early 2026):
| Type | Value | Context |
|---|---|---|
| IP | 38.244.158.56 |
Primary exfil server (malext variant) |
| IP | 199.217.98.33 |
Backup exfil server |
| Domain | malext[.]com |
C2 domain (malext variant) |
| URI path | /zxc/kito |
Second-stage binary download |
| URI path | /zxc/app |
Stealer binary download |
| Header | BuildID |
Custom exfil header |
File Hashes (representative samples):
| SHA-256 | Detection |
|---|---|
7a66c1a25b7caee9b6cc26a3199182379b6cdecc8196ac08be9fe03b4d193d6a |
Trojan.MacOS.AMOS.PFH |
4a33e10c87795e93c10de3d1a59937909d0093cac937e2a09d3242e7b17a36ce |
Trojan.MacOS.AMOS.PFH |
3ecf98f90cb170475eef315dad43e125b14757d7fbfdd213d5221c4e31467ee9 |
Trojan.SH.AMOS.AA |
| Technique ID | Name | AMOS Behavior |
|---|---|---|
| T1566.002 | Phishing: Spearphishing Link | Malvertising, fake app download pages |
| T1204.002 | User Execution: Malicious File | Trojanized .dmg installers |
| T1059.002 | Command and Scripting: AppleScript | Fake password dialogs, credential harvesting |
| T1059.004 | Command and Scripting: Unix Shell | Bash-based polling loop (.agent) |
| T1543.004 | Create or Modify System Process: Launch Daemon | com.finder.helper.plist persistence |
| T1564.001 | Hide Artifacts: Hidden Files and Directories | Dotfiles in $HOME |
| T1555.001 | Credentials from Password Stores: Keychain | Keychain copy + Chainbreaker extraction |
| T1082 | System Information Discovery | system_profiler, sw_vers, uname, ioreg |
| T1497.001 | Virtualization/Sandbox Evasion: System Checks | VM string detection (VirtualBox, Parallels) |
| T1005 | Data from Local System | Desktop, Documents, Notes, browser profiles |
| T1560.001 | Archive Collected Data: Archive via Utility | Zip compression before exfil |
| T1041 | Exfiltration Over C2 Channel | HTTP POST with base64-encoded zip |
- Picus Security — Atomic Stealer: Dissecting 2024's Most Notorious macOS Infostealer
- Trend Micro — MDR Analysis of the AMOS Stealer Campaign
- Trend Micro — Malicious OpenClaw Skills Used to Distribute AMOS
- Iru — Atomic Stealer Returns: ClickFix, Trojanized Crypto Apps, and New Persistence
- SentinelOne — From AMOS to Poseidon: A SOC Team's Guide
- Darktrace — Atomic Stealer Investigation of a Growing macOS Threat
- Microsoft — Hunting Infostealers: macOS Threats
- Detection.FYI — Atomic MacOS Stealer Persistence Sigma Rule
Contributions are welcome. If you have new IOCs, detection logic, or variant-specific artifacts:
- Fork this repository
- Add your findings with source attribution
- Submit a pull request
Please include the AMOS variant name, date observed, and at least one reference link for any new indicators.
This guide is intended for authorized security operations, incident response, and defensive research only. The detection commands documented here use native macOS tools and do not modify system state (except where explicitly noted in the Response Playbook). Always follow your organization's incident response procedures and chain-of-custody requirements when handling potentially compromised systems.
This project is licensed under the Apache License 2.0. See LICENSE for details.