Stopping macOS infostealers before credentials leave the device.

What is a macOS infostealer?

An infostealer is malware with one job: copy the data that lets an attacker become you, then send it home. On a Mac, that means browser cookies and saved passwords, the login keychain, SSH keys, cloud and developer credentials, crypto wallets and chat history.

It doesn’t need to persist or spread. A stealer runs, collects, uploads and is usually gone within a minute, often deleting its own binary on the way out. That makes it the dominant malware threat to macOS fleets today. Families like AMOS, Poseidon and Banshee are rented out as a service, and open-source kits like Paradox are free for anyone to fork.

Why a single infection matters

• Minutes from secret to impact. Stolen logs now go straight into automated tooling. An AI agent can take a fresh cloud key or GitHub token, work out what it can reach, enumerate the account and act on it, adapting to whatever access it finds. That used to take a skilled operator days.
• Session cookies skip MFA. A stolen browser session is already signed in. The attacker imports it and lands in email, SaaS consoles and source control as your user, with no password or second-factor prompt.
• Developer machines hold the keys to production. One laptop’s ~/.aws/credentials, ~/.npmrc and SSH keys can open cloud accounts, package registries and every server that trusts that key.
• The haul is resold. Stealer logs are traded in bulk, so whoever eventually uses your access may not be the person who stole it, and it may happen weeks later.

How infostealers work

Families differ in the details, but almost every macOS stealer follows the same four steps.

Delivery: the user runs it

Stealers rarely exploit a vulnerability. Someone is persuaded to run them:

• ClickFix lures. A fake CAPTCHA or “fix” asks the user to paste a command into Terminal. How ClickFix works.
• Fake and cracked apps. A disk image for “free” software, with instructions for getting past the Gatekeeper warning.
• Developer supply chain. A malicious IDE extension or npm package runs code as soon as it’s installed. In November 2025, a Solidity extension at the top of Open VSX did exactly this.

Execution: Apple’s own tools do the work

The first stage is usually a script that downloads the real payload, makes it executable and strips the quarantine flag that would otherwise trigger Gatekeeper. Everything it calls is signed by Apple.

chmod +x "$TMPDIR/xoxoxoxxx"
xattr -d com.apple.quarantine "$TMPDIR/xoxoxoxxx"
"$TMPDIR/xoxoxoxxx"

Collection: ask for the password, then take everything

Most stealers start with a fake system dialog. Whatever the user types is checked against the real account before the stealer moves on, because that password unlocks the login keychain.

osascript -e 'display dialog "<fake System Settings prompt>" … with hidden answer'
dscl /Local/Default -authonly "$USER" "<captured password>"

For years the next step was to copy ~/Library/Keychains/login.keychain-db alongside the browser databases and decrypt everything offline. macOS 26.4 stopped a copied keychain from being decrypted off the machine, so current builds have adapted rather than given up. Recent AMOS samples check the OS version first and, on 26.4 or later, ask the keychain directly for the browser’s encryption key while still on the Mac. The user sees a genuine Apple keychain prompt, and often approves it.

sw_vers -productVersion
security find-generic-password -ga "Chrome"   # Chrome Safe Storage key, on 26.4+

That key decrypts every cookie and saved login in the browser profile. Browser sessions are only half the haul, though. Developer machines carry plaintext secrets that need no key at all: cloud credentials, package registry tokens, Git and GitHub CLI tokens, kubeconfigs and SSH keys, all readable by anything running as the user. One of those is enough to publish a poisoned package, push to production or walk into a cloud account. These are the paths stealers go after:

Cloud credentials

~/.aws/credentials~/.config/gcloud/*~/.azure/*~/.kube/config

Source control and SSH

~/.git-credentials~/.config/gh/hosts.yml~/.ssh/*

Package registry tokens

~/.npmrc~/.pypirc~/.docker/config.json~/.terraform.d/credentials.tfrc.json

Browser sessions and saved logins

~/Library/Application Support/Google/Chrome/*Safari, Edge, Brave, Arc, Opera, Firefox

Keychain and wallets

~/Library/Keychains/login.keychain-dbCrypto wallet extensions and apps

Exfiltration: one archive, one upload

Everything is compressed into a single archive and sent to the attacker over HTTPS, often to the same domain that served the payload. By the time anyone looks, the process has exited.

Why signatures alone fall short

New builds every week

Stealer kits are repackaged constantly. A hash list is always a step behind the next build.

Living off the land

Payloads lean on curl, osascript and other Apple-signed binaries that every Mac already trusts.

The user lets them in

ClickFix lures and fake installers get the user to run the first stage themselves, sidestepping Gatekeeper and notarization.

How Phorion stops infostealers

No single control catches every stealer, so Phorion puts an independent one at each step. A miss at one stage is caught at the next.

File access is the backstop

A stealer can be brand new, unsigned and unknown to every threat feed, but it still has to read the files it came for. Phorion locks browser data, keychains, SSH keys and developer credentials to the processes that legitimately use them, and checks each one’s code signature. Chrome can read Chrome’s cookies. A binary in a temp folder can’t, and the process is stopped the moment it tries.

Those rules ship with locked-down defaults and exclusions for the apps that genuinely need access, so turning them on doesn’t break anyone’s day. See how file access decisions are made.

Every attempt is logged with the full process tree, signing identity and network activity behind it. Responders can see exactly which machine, which user and which lure, then isolate the device in one click while they investigate.