1 The legitimate service
com.apple.accountsd is Apple's Internet Accounts daemon
It is a normal, expected part of macOS. Understanding what it does helps you spot when something is pretending to be it.
accountsd is the background daemon that manages credentials and authentication tokens for system-level account integrations: Mail, Calendar, Contacts, Messages, and any third-party app that uses Apple's Internet Accounts framework (the "Internet Accounts" pane in System Settings).
It runs on every Mac, all the time. You will see it in Activity Monitor and in launchctl list output. That is normal.
Where the real service lives
- Binary:
/System/Library/Frameworks/Accounts.framework/Versions/A/Support/accountsd - LaunchDaemon plist:
/System/Library/LaunchDaemons/com.apple.accountsd.plist - Signed by: Apple, with System Integrity Protection (SIP) enforcing that nothing can modify or replace it
Because it lives under /System/Library/, it is covered by SIP. No process running as your user — and no malware — can modify the real accountsd binary or its plist. The real service is safe.
2 The infostealer disguise
AMOS uses the same name to hide in plain sight
The AMOS/Poseidon infostealer family creates a fake LaunchDaemon with an Apple-like label so it blends into the list of system services.
When AMOS installs persistence on a Mac, it drops a plist into /Library/LaunchDaemons/ — note the missing /System prefix — with a label like com.apple.accountsd or com.apple.acc. That plist points at a binary the malware dropped elsewhere on disk, often in a hidden directory under ~/Library/Application Support/.
This is a documented persistence technique in the AMOS/Poseidon family, reported by Objective-See and other macOS threat researchers. It works because:
- The real
accountsdis always running, so a second entry with a similar name blends into the noise. - Administrators and some antivirus tools skip items that look like Apple's own services.
- The fake plist in
/Library/LaunchDaemons/gives it root-level persistence — it survives reboots and user logouts.
Real vs. fake: side by side
| Real Apple service | AMOS fake | |
|---|---|---|
| Plist location | /System/Library/LaunchDaemons/ | /Library/LaunchDaemons/ |
| Binary path | Inside /System/Library/Frameworks/ | A dropped binary elsewhere (often a hidden dir) |
| Code signature | Apple-signed, SIP-enforced | Unsigned or ad-hoc signed |
| Modifiable | No (SIP blocks changes) | Yes (installed by malware with elevated privileges) |
| Behavior | Manages Mail, Calendar, Contacts tokens | Launches infostealer payload, often on a relaunch loop |
3 How to check your Mac
Three commands to tell the difference
These commands only read your system — they do not change anything.
1. List loaded services matching "accountsd"
# Show every loaded launchd service with "accountsd" in the label
launchctl list | grep accountsdYou should see the real Apple entry. If you see two entries, or an entry with a PID pointing at an unexpected binary, investigate further.
2. Check for a plist outside /System
# The real plist lives in /System/Library/LaunchDaemons/
# A fake one would be in /Library/LaunchDaemons/ (no /System prefix)
ls -la /Library/LaunchDaemons/ | grep -i accountsd
ls -la /Library/LaunchDaemons/ | grep -i "com.apple.acc"If either command returns a result, that file is not the real Apple service. The legitimate plist only exists under /System/Library/LaunchDaemons/.
3. Inspect the binary path
# If you found a suspicious plist, read it to see what binary it launches
sudo cat /Library/LaunchDaemons/com.apple.accountsd.plist 2>/dev/null
# The real binary path will contain /System/Library/Frameworks/
# A fake one will point somewhere else entirelyaccountsd will break Mail, Calendar, Contacts, and other account integrations on your Mac.4 If you found the fake
What to do if the malware version is on your Mac
If you confirmed a com.apple.accountsd plist in /Library/LaunchDaemons/ pointing at a non-Apple binary, treat the machine as compromised:
- Rotate all credentials immediately from a different, clean device. Anything typed into the compromised Mac can be captured again. Prioritize: password manager master password, Apple ID, email, cloud/API keys, financial accounts, SSH keys.
- Run the free scanner to check for other AMOS indicators — the fake accountsd is rarely the only persistence item. Or run the full self-check covering all persistence layers manually, step by step.
- Strongly consider a full erase and macOS reinstall. A machine that carried root-level persistence should not be trusted in place. Removing what you can see does not tell you what you cannot. Read why AV quarantine isn't enough and what the real AMOS removal path looks like.
- Follow the recovery and hardening checklist for the full sequence: evidence preservation, clean rebuild, and closing the gaps that let it dwell.
Common questions
com.apple.accountsd FAQ
Based on the real infection and documented AMOS/Poseidon-class behavior. Further reading: Objective-See threat research · Apple Platform Security guide.
Is com.apple.accountsd a virus?
No. The real com.apple.accountsd is a legitimate Apple system daemon that manages account credentials for Mail, Calendar, Contacts, and other services. It is present on every Mac and is a normal part of macOS. However, the AMOS infostealer creates a fake LaunchDaemon with the same name to disguise its persistence. The way to tell them apart is by checking the plist location and binary path — the real one lives under /System/Library/, and the fake does not.
Can I safely remove com.apple.accountsd?
You should not remove the real Apple service — doing so will break Mail, Calendar, Contacts, and other system account integrations. If you found a fake com.apple.accountsd.plist in /Library/LaunchDaemons/ (not /System/Library/), that copy is the malware's persistence and can be removed. But if the malware achieved root persistence, removing one plist is unlikely to be sufficient — a full erase and reinstall is the safer path.
Why is com.apple.accountsd using high CPU or network?
The legitimate accountsd can spike briefly when syncing accounts (refreshing Mail tokens, updating Calendar, signing into a new service). If it stays at high CPU or generates sustained network traffic, check whether there are two processes with similar names running — one could be the real service and the other could be a malware payload. Run launchctl list | grep accountsd and check the binary paths to distinguish them.
Does antivirus catch the fake com.apple.accountsd?
Not reliably. The AMOS/Poseidon family specifically uses Apple-like naming to evade detection. In the real incident this site is built from, antivirus reported the machine clean while a root LaunchDaemon — disguised with Apple naming — was still loaded and running. A green AV dashboard means no new detections, not a clean machine. Manual persistence auditing (or a targeted scanner like hardenmac-scan) catches what generic antivirus misses.