The false-assurance problem
A green dashboard is not a clean machine.
When antivirus "removes" an infostealer, it typically quarantines the active binary — the file doing the stealing. That is the visible layer. Underneath it, AMOS installs root-level persistence that most AV products do not touch.
Here is what happened in my case: antivirus detected and quarantined the AMOS payload. The dashboard turned green. "Threat removed." But a root LaunchDaemon — installed in /Library/LaunchDaemons/ with an Apple-like name — was still loaded and running. Its job was to relaunch the payload binary on a tight loop. Remove the binary, and the daemon downloads or recreates it. Remove the daemon without removing the binary, and it is already running.
The problem is not that antivirus is useless. The problem is that "threat removed" means something narrower than most people hear. It means: we found a known-bad file and quarantined it. It does not mean: we audited every persistence mechanism on your system and confirmed nothing will bring it back.
What AMOS persistence looks like
Three layers, designed to survive partial removal.
AMOS does not rely on a single file. It installs a multi-layer persistence model where each layer reinstalls or relaunches the others. Removing one piece leaves the rest intact.
The three-layer AMOS persistence model
-
Root LaunchDaemon — a plist in
/Library/LaunchDaemons/(e.g.,com.apple.accountsd.plist) that runs a hidden binary as root. It is set toKeepAlive: true, meaning macOS itself relaunches it automatically if the process dies. This is the layer that survives most AV removal — it runs as root and uses Apple-like naming to blend in. -
User LaunchAgent (watchdog) — a plist in
~/Library/LaunchAgents/that runs as your user account. Its job is to monitor the root daemon and relaunch the payload from user context if the daemon is interrupted. This creates a two-way recovery loop: the daemon relaunches the agent, and the agent relaunches the daemon. -
Companion files — your captured login password stored at a hidden path (e.g.,
~/.passor~/.pw), plus the payload binary itself in a hidden directory. The password file lets the malware elevate to root and unlock Keychain without prompting you. These are the files AV is most likely to catch — but without removing Layers 1 and 2, they get recreated.
All three layers use Apple-like naming conventions — com.apple.accountsd, com.apple.service.agent, com.finder.helper — to look like legitimate system processes. That is by design: a user or tool scanning LaunchDaemons will see Apple-sounding names and assume they are safe. If you have seen com.apple.accountsd in your process list and are not sure whether it is the real Apple service or an AMOS impersonator, see how to identify the real vs. fake accountsd.
This is why "remove the file" does not work. You can delete the binary, and the root daemon recreates it. You can unload the daemon, and the watchdog agent reinstalls it. You can remove the agent, and the daemon is still running as root. The only path that works is removing all three layers simultaneously — or wiping the machine entirely.
# Check for persistence layers (read-only — these commands only look)
sudo launchctl list | grep -i "com.apple"
ls -la /Library/LaunchDaemons/
ls -la ~/Library/LaunchAgents/
# Check for captured-password files
ls -la ~/.pass ~/.pw 2>/dev/null
# Check common AMOS payload hiding spots
ls -la ~/Library/Application\ Support/.com.apple.* 2>/dev/nullsudo, no changes to your system. Download it, read it, then run it.The real recovery path
What to actually do after AMOS — not just "remove the file."
The order matters. Start by securing what the malware already stole, then deal with the machine itself.
-
Run the free scanner from a terminal
Before you touch anything, get a picture of what is on the machine. Run the step-by-step Mac malware check first to confirm what is present — it walks through the same read-only Terminal commands used to surface AMOS indicators, with no installs and no network calls. If you want a single automated script instead, hardenmac-scan covers the same ground in about 10 seconds. Read any script before you run it. Never pipe an install straight into a shell.
-
Rotate every credential from a different, clean device
Use your phone or another known-good computer — not the suspect Mac. Anything typed into a compromised machine can be captured again. Rotate: Mac login, password manager master, Apple ID, Google, all API keys, SSH keys, financial accounts, and any browser sessions. Follow the full sequence in the recovery checklist.
-
Follow the full recovery checklist
The free recovery checklist covers the complete sequence: first-hours triage, evidence preservation, persistence audit, the wipe-or-clean decision, clean rebuild, and hardening to close the gaps. It is free, ungated, and written from the same infection this page describes.
-
Seriously consider a clean wipe
If the infection achieved root persistence and dwelled for any length of time, a full erase and macOS reinstall is the recommended path. Removing what you can see does not tell you what you cannot. A rebuild takes a few hours. Trusting a machine that carried root-level malware with your credentials is the more expensive mistake. The checklist walks through exactly how to wipe and rebuild.
Common questions
What people ask about AMOS removal
Based on a real AMOS/Poseidon-class infection and documented behavior. Further reading: Objective-See threat research · Apple Platform Security guide.
Will Malwarebytes remove AMOS from my Mac?
Malwarebytes and other AV tools may detect and quarantine the active AMOS binary, but they typically do not remove the full persistence scaffolding. AMOS uses a multi-layer model: a root LaunchDaemon, a user-level LaunchAgent watchdog, and companion files like a captured login password. AV focuses on the payload — the binary doing the stealing — not the root-level daemon that relaunches it. In this real infection, antivirus reported the machine clean while a root LaunchDaemon was still loaded and running. After AV quarantine, you still need to audit all persistence layers manually and rotate every credential the machine could reach.
Do I need to wipe my Mac after an AMOS infection?
If the infection achieved root persistence and dwelled for any meaningful period, yes — a full erase and macOS reinstall is the recommended path. Removing what you can see does not tell you what you cannot. A rebuild takes a few hours; trusting a machine that carried root-level malware with your credentials is the more expensive mistake. The narrow exception: a single clearly-identified item caught immediately, where careful manual removal of all three persistence layers may be sufficient. Any uncertainty: wipe.
What data did the infostealer steal?
AMOS (Atomic macOS Stealer) targets: Keychain passwords (every saved password on your Mac), browser sessions and cookies (active logged-in sessions, not just passwords), cryptocurrency wallets (Exodus, MetaMask, Phantom, and others), SSH keys and API tokens (cloud providers, GitHub, CI systems, AI/LLM keys), files from Desktop and Documents, and your Mac login password (captured to a hidden file and used to unlock Keychain programmatically). Treat every credential the infected machine could reach as already exfiltrated. Rotate from a different, clean device.
How do I check if AMOS is still on my Mac after antivirus?
After AV reports clean, check manually for the persistence layers AV typically misses. Run sudo launchctl list and look for labels mimicking Apple naming (com.apple.accountsd, com.apple.service.agent) that point to hidden binaries. Check /Library/LaunchDaemons/ and ~/Library/LaunchAgents/ for plist files you do not recognize. Look for hidden files: ls -la ~/.pass ~/.pw — common AMOS credential-capture locations. The free hardenmac-scan script automates these checks — read-only, no network calls, no sudo required.
Can I remove AMOS manually without wiping?
Possible but risky, and only advisable if you caught it immediately and can identify all three persistence layers: the root LaunchDaemon in /Library/LaunchDaemons/, the user LaunchAgent watchdog in ~/Library/LaunchAgents/, and the payload binary plus companion files. You must remove all three — removing one leaves the others to reinstall it. Use sudo launchctl bootout to unload each before deleting the plist and binary. Even after successful manual removal, rotate every credential the machine touched. If any layer is unclear, the safe path is a full wipe.
What does AMOS persistence look like on a Mac?
AMOS uses a three-layer persistence model. Layer 1: a root LaunchDaemon plist in /Library/LaunchDaemons/ with an Apple-like name (e.g., com.apple.accountsd.plist) running a hidden binary as root. Layer 2: a user-level LaunchAgent in ~/Library/LaunchAgents/ acting as a watchdog that relaunches the payload from user context. Layer 3: companion files including a captured login password at a hidden path like ~/.pass, used to elevate privileges without prompting. All three use Apple-like naming to blend in with legitimate system processes.
The checklist is free. The scanner is free. Start there.
Everything on this page is experience-based — written from a real AMOS infection and rebuild, not from a vendor brochure. The recovery checklist covers the full sequence: triage, credential rotation, persistence audit, the wipe-or-clean decision, clean rebuild, and hardening. The scanner checks for the indicators described above in about 10 seconds.
If you want the scripts, prebuilt firewall rules, decision trees, and the decoded real incident — the parts that do the work for you — the full playbook is on the main site.
Read the free recovery checklist →