Self-check guide

Is my Mac infected? The mac malware check I wish I'd run.

A persistent Mac infostealer sat on my Mac for roughly two months, based on the available evidence. My Mac's built-in defenses never flagged it — I found it by manual investigation, not because a security tool caught it. Here are the checks that would have surfaced several of the indicators later found in my case — step by step, with the commands and what to look for. An open-source Mac check automates a limited subset of them.

What this is: a self-check for developers and AI builders who suspect their Mac may have an infostealer. Written from a real Mac infostealer infection that went undetected for months. What it isn't: professional security advice or a guarantee. Every command here only reads your system — nothing is changed, nothing requires sudo (unless noted). Read each command before you run it.

1 Check first

Check LaunchDaemons and LaunchAgents

This is where macOS persistence lives. Infostealers install plist files here so they restart automatically after a reboot — and they name themselves to look like Apple.

  1. Start here

    List everything set to auto-start

    Mac infostealers disguise persistence as Apple services — labels like com.apple.accountsd (the label found in the founder's own incident) and other Apple-styled daemon names — masquerading as system processes is a convergent pattern across multiple documented Mac malware campaigns. The label looks like Apple, but the plist points at a hidden script in your home directory or /var/tmp/. See how to tell the real from the fake com.apple.accountsd.

    # List all LaunchDaemons (system-wide, often requires sudo to see contents)
ls -la /Library/LaunchDaemons/

# List user-level LaunchAgents
ls -la ~/Library/LaunchAgents/

# List system-level LaunchAgents
ls -la /Library/LaunchAgents/

    What to look for:

    • Labels that mimic Apple naming (com.apple.*) but were not installed by Apple — open the plist and check the ProgramArguments path. If it points at a hidden dotfile or a script in your home directory, that is not Apple.
    • Plist files created recently or at an unexpected date — check the file modification timestamp.
    • Watchdog loops: a daemon whose sole job is to relaunch another process every few seconds. Look for StartInterval values under 60 in the plist.
    # Read a suspicious plist to see what it actually runs
cat /Library/LaunchDaemons/<suspect-label>.plist

# Check for hidden payload dirs that mimic Apple naming
ls -la ~/Library/Application\ Support/.com.apple.* 2>/dev/null
    Why antivirus misses this: AV may quarantine the active binary, but a system-level LaunchDaemon and hidden relaunch components can remain registered with launchd. 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.

2 Check for dropped files

Hidden files the malware writes near the payload

Documented Mac infostealer variants (AMOS-class and similar) have been reported staging captured credentials and browser data in short hidden files before exfiltration. In my own case this exact artifact was never independently confirmed — but because this was hands-on-keyboard access for two months, I had to assume anything typed on that machine could have been captured. Treat any short hidden file you don't recognize as something to investigate, not ignore.

  1. Look for captured credentials and staging files

    Some documented infostealer variants can stage captured credentials in hidden files — often with a name like .pass, .pw, or something similarly short — for use in privilege escalation. They may also stage browser data (cookies, saved passwords, extensions) before exfiltrating.

    # List hidden files in your home directory
ls -la ~/.[!.]*

# Look for short hidden files that could be captured passwords
find ~ -maxdepth 2 -name ".*" -type f -size -1k -newer /var/log/install.log 2>/dev/null

# Check for hidden dirs that mimic Apple in Application Support
ls -la ~/Library/Application\ Support/.* 2>/dev/null

    What to look for:

    • Short hidden files you did not create — especially anything containing what looks like a password or token.
    • Hidden directories in ~/Library/Application Support/ that mimic Apple naming (e.g. .com.apple.accountsd).
    • Browser data copies (cookies databases, login JSON) outside the normal browser profile path.
    If you find a file that contains your password in plaintext: stop. Do not delete it yet — it is evidence. Change that password immediately from a clean device, then preserve the file to an external drive before removing it.

3 Check running processes

Look for processes running from unexpected paths

Legitimate macOS processes run from /System/, /usr/, or /Applications/. An infostealer's binary runs from /var/tmp/, a hidden directory, or a user-writable path.

  1. Audit process paths

    Look for any process whose binary path is somewhere you wouldn't expect system software to live. /var/tmp/ and hidden dotfile directories are common AMOS staging locations.

    # Show all running processes with full paths
ps aux

# Filter for processes running from suspicious locations
ps aux | grep -E '/var/tmp|/\.\w'

# Check what is currently loaded by launchd
launchctl list | grep -v "com.apple"

    What to look for:

    • Processes running from /var/tmp/, /tmp/, or any hidden directory (path containing /.).
    • Process names that mimic Apple services but run from a user-writable path instead of /System/ or /usr/.
    • Any process with a name you do not recognize — especially if it started recently and uses network connections.
    # Check active network connections for unknown processes
lsof -i -P | grep ESTABLISHED
    Check outbound connections: an infostealer's entire job is to phone your data out. If a process you don't recognize has an established network connection, note the remote IP and the process name. That is the signal.

4 Run the open-source Mac check

Automate a subset of these checks with one script

The open-source Mac check automates a limited subset of the checks above — a separate, read-only open-source tool (not the HardenMac product, and not guaranteed malware detection). It does not identify a malware family, prove a Mac is infected, or prove a Mac is clean. It’s a POSIX script you can audit before running: no network calls, no sudo, no changes to your system.

  1. Download, read, then run the open-source check

    hardenmac-scan checks for a limited set of persistence and system indicators associated with known Mac infostealers — including known launchd label patterns, the watchdog relaunch loop, captured-password files, known command-and-control domains, and processes running from suspicious paths.

    # Download the open-source Mac check
git clone https://github.com/thatswhatworks/hardenmac-scan.git
cd hardenmac-scan

# Read the script before running it — never trust blind
cat scan.sh

# Run it
chmod +x scan.sh
./scan.sh
    • Read-only: the script does not modify your system, does not require sudo, and makes no network calls.
    • Open source: every line is readable before you run it. That is the point.
    • Never pipe a script from the internet into your shell — curl | bash is literally how a lot of these infostealers get installed. Download it, read it, then run it.
    Why a script instead of an app? Because an app that asks for permissions is the same pattern the malware uses. A shell script that reads and reports is the lowest-trust, most-auditable format. You can see exactly what it does.

5 Check shell history

Look for delivery-vector artifacts

The infection started somewhere. Your shell history may still have the evidence — especially if it came in through a curl|bash install or an osascript privilege-escalation trick.

  1. Search history for suspicious patterns

    The ClickFix/Terminal-paste trick — where a website or ad instructs you to paste a command into Terminal — is the single most common Mac infection vector right now. Your history is the evidence trail.

    # Search for curl|bash or curl|sh patterns (the classic pipe-to-shell)
history | grep -iE 'curl.*\|.*(bash|sh|zsh)'

# Search for osascript privilege escalation
history | grep -i 'osascript'

# Check the raw history file for anything your session history doesn't show
grep -iE 'curl.*\|.*(bash|sh)|osascript|sudo.*bash' ~/.zsh_history 2>/dev/null
grep -iE 'curl.*\|.*(bash|sh)|osascript|sudo.*bash' ~/.bash_history 2>/dev/null

    What to look for:

    • curl|bash or curl|sh patterns: any install script piped directly from the internet into a shell. This is the delivery mechanism.
    • osascript commands: AppleScript can pop a fake system dialog asking for your admin password. If you see osascript -e in your history and you don't remember writing AppleScript, investigate.
    • Commands you don't remember running: the malware may have run commands as your user. Anything unfamiliar in your history is worth investigating.

6 If you find something

What to do if any of these checks turned up something suspicious

The priority is not cleaning the machine. The priority is rotating credentials from a device you trust.

  1. Do this now

    Rotate credentials from a different, clean device

    Use your phone or another known-good computer — not the suspect Mac. Anything you type into a compromised machine can be captured again.

    • Password-manager master password — then check its activity log for unfamiliar sign-ins.
    • API keys and developer tokens: GitHub, cloud providers, CI, package registries, AI/LLM keys. Regenerate SSH keys.
    • Apple ID and Google: change passwords, review trusted devices, set a recovery key.
    • Financial accounts and anything with money attached.
    • Sign out of all browser sessions everywhere — stored cookies were stealable, so a password change alone is not enough.

  2. Then follow the full recovery checklist

    The recovery checklist walks through everything after credential rotation: preserving evidence, auditing persistence, the wipe-vs-clean decision, rebuilding clean, and hardening so it cannot sit silently again. If AV already flagged something, read why quarantine alone isn't enough before you trust a clean report.

    FreeThe Mac Infostealer Recovery & Hardening Checklist — full sequence, ungated, no signup→

Common questions

What people ask when they suspect an infection

Based on a real Mac infostealer incident and documented Mac-infostealer behavior. Further reading: Objective-See · Apple Platform Security guide · CISA.

Will antivirus detect an infostealer on my Mac?

Not reliably. Malware families such as AMOS/Poseidon are documented disguising persistence as Apple system processes. In the real Mac infostealer incident this guide is built from, antivirus reported the machine clean while a root LaunchDaemon was still loaded and running. AV may remove the active binary while a system-level LaunchDaemon and hidden relaunch components remained. 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.

What are the signs my Mac has an infostealer?

Check for LaunchDaemons or LaunchAgents with labels that mimic Apple naming (com.apple.accountsd, com.apple.service) but point at hidden scripts in your home directory. Look for short hidden files near the payload (captured credentials), processes running from /var/tmp/ or hidden directories, and curl|bash patterns in your shell history. The open-source Mac check automates these checks.

How do Mac infostealers get installed?

The most common vectors are fake developer tool installers, cloned documentation pages, malvertising in search results, and the ClickFix/Terminal-paste trick where a website instructs you to paste a command into Terminal. Supply-chain attacks via poisoned npm or PyPI packages are also documented. In every case, the malware runs as your user account — everything your account can reach is exposed.

Should I wipe my Mac if I find malware?

When in doubt, wipe. A machine that carried root persistence for any meaningful period cannot be trusted in place. Removing what you can see does not tell you what you cannot. A clean reinstall takes a few hours; trusting a still-dirty machine with your credentials is the more expensive mistake. The one exception: a single clearly identified item caught immediately, where careful manual removal may be sufficient.

What should I do first if I think my Mac is infected?

Rotate credentials from a different, clean device — not the suspect Mac. Anything you type into a compromised machine can be captured again. Change your password-manager master password, API keys, SSH keys, cloud tokens, and sign out of all browser sessions everywhere. Then follow the full recovery checklist.

Referenced tools

Source links only — each goes to the tool's official home, so you install from the original maintainer. Nothing is bundled or redistributed.

hardenmac-scangithub.com/thatswhatworks KnockKnockobjective-see.org BlockBlockobjective-see.org LuLuobjective-see.org
Experience disclaimer: this guide is written from a real Mac infostealer infection. 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. It is an experience-based educational resource, not professional security advice and not a guarantee. No tool or guide makes any machine "unhackable"; the goal is to reduce attack surface, raise the bar, and help you identify indicators of compromise faster. You remain responsible for your own systems and decisions.
Checked your Mac — now close the gaps

The recovery checklist covers what to do next.

If any of the checks above raised a flag, the recovery checklist walks through credential rotation, the wipe-vs-clean decision, rebuilding clean, and hardening so an infostealer cannot sit silently again. Free, ungated, no signup.

Need more than a checklist? The full playbook has the trackers, decision trees, and step-by-step recovery and hardening procedures that do the parts a checklist can't.

Read the recovery checklist