Removing AMOS-Class Malware From a Mac

Removing an infostealer is two jobs, not one. The first is getting the software off the machine. The second is ending the access it already handed to someone else. Most removal guides stop after the first, which is why people follow them, see a green result, and lose an account a week later.

This page covers both, in the order that keeps the most.

What is AMOS-class malware?

"AMOS" — Atomic macOS Stealer — is the name given to a family of macOS infostealers sold to other criminals as a service. Related and overlapping names include Atomic, Poseidon and various rebrands; variants appear constantly and different vendors attribute the same sample differently. Naming in this corner of the field is genuinely unreliable.

Which is why this page says AMOS-class. It describes behaviour rather than asserting an exact family, because the behaviour is what determines what you have to do, and the behaviour is consistent:

Delivery is social. A fake installer or updater, a cracked application, a "driver fix" from a search advertisement, a job-interview or crypto-support script — or, increasingly, an instruction to paste a command into Terminal to solve a problem you were just told you have.
It runs as you. No exploit needed. It has your permissions because you gave them, usually including an admin password prompt that looked routine.
It collects fast. Browser profiles and stored passwords, cookies and session data, keychain material, notes, documents, wallet files, developer keys and configuration files.
It uploads over an ordinary connection, then may delete itself or install a launch item to persist.

If you are not sure whether anything ran at all, start with how to check a Mac for infostealer signs instead.

Why removing it is not the same as recovering

This is the part that changes outcomes, and it is the part almost nobody explains.

Your password is one credential. It is not the only one. A session cookie is a second: the piece of browser state that tells a service "this browser already signed in, don't ask again". An OAuth token is a third: a long-lived key that an app or service holds on your behalf so it can act for you without your password. Both are separate credentials. Both were designed to survive so you are not re-prompted constantly. Both were designed to skip the two-factor prompt, because you already passed it once.

So when an infostealer copies your browser profile, what leaves the Mac is not only "your passwords". It is a working, already-authenticated set of sessions. Someone can load those cookies into their own browser and be inside your mail with no password and no second factor — and deleting the malware from your Mac does not sign them out, because they are not on your Mac.

Removing the malware is not the same as getting your accounts back. The malware is on your machine. The access is somewhere else.

Practical consequence: the revoke-and-rotate work below is not the cleanup after removal. It is the more urgent of the two jobs, and if you only have an hour, spend it there.

How to remove an AMOS-class infostealer from a Mac

Read the whole sequence before starting step 1. Manual removal is not reliably complete — you can only remove what you find — which is why step 6 exists.

Disconnect the Mac from the network. Wi-Fi off, Ethernet unplugged. This stops anything still running from sending more, and stops it fetching a replacement for whatever you remove.
Write down what you know before you delete anything. What you installed or pasted, when, from where, what prompted you for a password. Screenshots that don't reveal secrets. This is the difference between a decision and a guess later, and deletion is one-way.
Move to a different device for anything involving accounts. Do not use the affected Mac to sign in and "just check" — that is how a fresh session gets captured.
Find persistence. Look in System Settings > General > Login Items & Extensions (both Open at Login and App Background Activity), then list the launch item folders from Terminal:
```
ls -la /Library/LaunchAgents /Library/LaunchDaemons ~/Library/LaunchAgents
```
Also check System Settings > General > Device Management, which only appears if a configuration profile is installed. If you did not install one, that is worth attention.
Read what an unfamiliar item actually launches before touching it, rather than judging by name — names are the cheapest thing to fake:
```
defaults read /Library/LaunchAgents/<name>.plist
```
The Program or ProgramArguments values tell you what really runs. A binary in your home folder, /tmp, or a hidden directory is a strong signal; a path inside /System is Apple's own. Legitimate third-party items live here too — backup agents, security tools, updaters — so unexplained is the test, not merely present.
Decide: clean in place, or rebuild. See the conditions below. If in doubt, this is not a coin-flip — rebuild is the higher-confidence answer.
If cleaning in place: unload the launch item, remove the plist, remove the payload it points to, empty the trash, restart, then repeat step 4 and confirm it has not come back. Something that returns after a restart means you removed a symptom, not the cause.
Re-check after the restart, not before. The restart is the test.

You can also run the free open-source Mac check to look for a defined set of indicators. Read it before you run it — it is a short shell script, and its own README tells you not to pipe it from the internet into a shell. It cannot prove your Mac is clean, and it does not claim to.

The part removal does not do — revoke and rotate

Do this from the other device, whether or not you found anything, and whether or not you decide to wipe.

For each important account: review active sessions and devices, sign out all other sessions, remove unknown devices, revoke connected apps and third-party access, review two-factor methods, passkeys, backup codes, recovery email and recovery phone — and then change the password.
Work in order of control: primary and recovery email first, then password manager, then Apple Account or identity provider, then banking and payment, then domain, DNS, hosting and work-admin, then cloud storage and backups, then developer and deployment platforms, then AI tools and automations, then social.
Rotate machine credentials as well as human ones: API keys, access tokens, app passwords, SSH keys, and anything sitting in a .env file the Mac could read.

The free First-Response Checklist is this in printable form; the Mac Security Checklist is the full six-stage sequence around it. The paid HardenMac Safety & Recovery Protocol is the long version, with the decision trees and the selective-restore guidance — out now for $29 (founder’s price) via the front page.

Should you erase and reinstall?

A rebuild is more strongly favoured when any of these are true:

You entered an admin password for something you now doubt.
A launch item, daemon or configuration profile was involved.
Behaviour came back after you removed something.
You cannot explain what ran, or for how long.
The Mac could reach high-value accounts, client data, financial assets, wallets or developer keys.
You simply do not trust the machine any more. That is a legitimate reason on its own.

If you do erase: restore documents, not machine state. A full migration can carry the launch items, browser profiles, Library contents and shell profiles straight back onto the clean install, which is the most common way a "clean rebuild" quietly isn't one.

Common questions about AMOS removal

Will antivirus remove AMOS-class malware from a Mac?

A reputable tool may well remove the components it recognises, and that is worth doing. Two limits: variants are produced faster than signatures for them, so "nothing found" is a weak result; and no removal tool can revoke the sessions and tokens that already left the machine. Removal and recovery are different problems.

How do I know it is really gone?

You can build confidence — nothing returns after a restart, no unexplained launch items, no unexplained outbound connections — but you cannot prove absence on a machine you already do not trust. That asymmetry is the honest argument for rebuilding when the stakes are high.

Do I have to wipe my Mac?

Not always. Wipe when the conditions above point that way. When the event was limited and explainable, a careful clean plus the full revoke-and-rotate pass is a defensible choice.

I changed all my passwords. Am I done?

No — that is the single most common mistake here. Password changes do not reliably end existing sessions and do not revoke connected-app access. Sign out other sessions and review connected apps as well, and check that recovery email and phone are still yours.

Is AMOS the same thing as Atomic or Poseidon?

They are overlapping names in the same neighbourhood, with a long history of rebranding and forking. Treat family names as a rough label. What matters for your response is the behaviour class, not the badge a vendor put on it.

What did it actually take?

Assume worst case for anything the Mac could reach: stored passwords, cookies and sessions, keychain-adjacent material, documents, wallet files, and any keys or tokens on disk. You will rarely get a definitive inventory, so plan against reach rather than against proof.

Sources

Apple — Change Login Items & Extensions settings (macOS Tahoe 26); the Open at Login and App Background Activity section names.
Apple — Protect your Mac from malware (macOS Tahoe 26).
hardenmac-scan — the free, open-source, read-only Mac check, including its own statement that a clean result "does not prove the Mac is clean".
Terminal commands on this page were run on macOS 26.6.1 (build 25G76) on 2026-08-11.

HardenMac is experience-based guidance, not professional advice, and not antivirus or incident response. It does not scan this Mac, its accounts, files or network, and it cannot detect or rule out a problem. Menu names vary by macOS version; if a setting has moved, search for its name inside System Settings.