AMOS removal guide

Your antivirus said "threat removed." The root daemon was still running.

If you're searching for how to remove AMOS, Atomic Stealer, or a Poseidon-class infostealer from your Mac, the honest answer is harder than the one antivirus gives you. AV quarantines the visible binary. Underneath it, a system-level LaunchDaemon and hidden relaunch components can remain. Here's what that means, what to actually do, and why "remove the file" is not enough.

Written from a real infection. I ran a persistent Mac infostealer for roughly two months, based on the available evidence, without knowing. My antivirus reported the machine clean. A root LaunchDaemon was still loaded, relaunching the payload roughly every five seconds. This page is what I learned the hard way about what "removal" actually requires. This page discusses AMOS as a known Mac infostealer. It was informed by the founder's real Mac infostealer incident, but the specific family involved in that incident was not independently confirmed.

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 infostealer 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. If the payload remains available, the persistence mechanism may relaunch it. Removing only one layer can leave another layer active.

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.

The gap: AV focuses on known-bad files. AMOS persistence uses Apple-like process names and standard macOS auto-start mechanisms (LaunchDaemons, LaunchAgents) that are also used by legitimate software. AV cannot simply remove every LaunchDaemon — it would break the machine. So a system-level LaunchDaemon and hidden relaunch components remain.

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 can relaunch the others. Removing one piece can leave the rest intact.

The three-layer AMOS persistence model

  1. Root LaunchDaemon — a plist in /Library/LaunchDaemons/ (e.g., com.apple.accountsd.plist) that runs a hidden binary as root. It is set to KeepAlive: 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.
  2. 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.
  3. Companion files — your captured login password stored at a hidden path (e.g., ~/.pass or ~/.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 if Layers 1 and 2 remain active, the persistence mechanism may relaunch the payload and restore them.

All three layers use Apple-like naming conventions — names like com.apple.accountsd (the label in the founder's own incident) and other Apple-styled daemon labels documented across Mac-infostealer campaigns — 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. If the payload remains available, the persistence mechanism may relaunch it — removing only one layer, whether that's the binary, the daemon, or the watchdog agent, can leave another layer active. 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/null
Automate the check: hardenmac-scan is a free, read-only POSIX script that checks for a limited set of persistence and system indicators associated with known Mac infostealers — launchd labels mimicking Apple naming, watchdog-style relaunch loops, captured-password files, and known C2 destinations. No network calls, no sudo, no changes to your system. Download it, read it, then run it. It does not identify a malware family, prove a Mac is infected, or prove a Mac is clean.

The real recovery path

What to actually do after AMOS — not just "remove the file."

The order matters. Start by securing what the infection could have exposed, then deal with the machine itself.

  1. Run the open-source Mac check 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 that check for a limited set of persistence and system indicators associated with known Mac infostealers, 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. It does not identify a malware family, prove a Mac is infected, or prove a Mac is clean. Read any script before you run it. Never pipe an install straight into a shell.

  2. 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.

  3. 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.

  4. 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.

The honest framing: the malware was the event. The rebuild is the fix. "Removing" the visible files without rotating credentials and rebuilding trust in the machine is treating the symptom, not the problem. Your passwords, keys, sessions, and files have to be treated as potentially exposed — rotating them is not optional, regardless of what you do to the Mac itself.

Common questions

What people ask about AMOS removal

Based on a real Mac infostealer incident and documented Mac-infostealer 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 can leave persistence layers behind. 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. Removing or quarantining a detected binary does not necessarily establish that every persistence component is gone. A no-detection result reflects the tool's checks and scope; it does not prove the Mac is clean. 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?

Infostealers in the AMOS/Poseidon class are documented targeting Keychain passwords (saved passwords), 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 the Mac login password. In my own case the specific family was never confirmed and a captured-password file was not something I could verify — so assume anything typed on that machine could have been captured. Treat the credentials the infected machine could reach as potentially exposed. 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 can miss. 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. It does not identify a malware family, prove a Mac is infected, or prove a Mac is clean.

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. If the payload remains available, the persistence mechanism may relaunch it — removing only one layer can leave another layer active. 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.

What to do next

The checklist is free. The open-source Mac check is free. Start there.

Everything on this page is experience-based — written from a real Mac infostealer 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 open-source Mac check looks for the indicators described above in about 10 seconds.

If you want the trackers, decision trees, recovery and hardening procedures, 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 →
Experience disclaimer: this page is written from a real Mac infostealer infection — a well-documented category of macOS malware with known behavior. It is an experience-based educational resource, not professional security advice and not a guarantee. No tool or checklist makes any machine "unhackable"; the goal is to reduce attack surface, raise the bar, and help you recover faster. You remain responsible for your own systems and decisions. Mac-infostealer behavior documented by Objective-See, Apple Platform Security, and CISA.