macOS: cover launchctl bootstrap, add AMOS LaunchDaemon install and wallet replacement rules

[raimurokko]

Summary

Four changes to macOS coverage, from reverse engineering the payload of a ClickFix chain in August 2026. The payload decrypted to AMOS, and diffing it against the two existing Atomic-MacOS-Stealer rules showed what they already cover and where the gaps are.

I want to be explicit that most of the behaviour here is not a new discovery — the LaunchDaemon persistence, the wallet replacement and the /zxc/ paths are documented by Moonlock and IRU, and the existing rules by Gen Digital already cover part of it. What is new is a variant whose labels have moved, and two behaviours with no rule attached yet.

1. launchctl bootstrap is not matched (rules/macos/)

proc_creation_macos_launchctl_execution.yml matches submit, load and start. It does not match bootstrap, which is the modern replacement for load and what the sample uses (launchctl bootstrap system <plist>).

This is not AMOS-specific, which is why the change is in rules/ rather than emerging-threats. modified: bumped, author untouched.

2. AMOS persistence rule pins a label that has changed

file_event_macos_malware_amos_persistence.yml matches the literal /Library/LaunchDaemons/com.finder.helper.plist. Samples from 2026-08 imitate genuine Apple service names instead:

com.apple.accountsd.helper	real service is com.apple.accountsd, no .helper
com.apple.metadata.mds.worker	real service is com.apple.metadata.mds, no .worker

Generalised to a startswith on the directory plus a list of known suffixes, and extended with the dot-prefixed staging directories the same builds use (~/Library/Application Support/.com.apple.accountsd/, .com.apple.metadata.mds/). Original author and date: preserved, modified: added.

3. New — proc_creation_macos_malware_amos_launchdaemon_install.yml

Covers the escalation step rather than the artefacts, so it survives the label churn in point 2.

AMOS phishes the password with a fake "System Preferences" dialog, validates it with dscl . authonly, then pipes it into sudo -S to copy the payload, chown root:wheel it and bootstrap it. The piped credential is the durable observable — tooling that legitimately installs a LaunchDaemon already holds the privileges and does not feed a password to sudo -S on stdin.

Complements the file_event rule rather than replacing it; both are worth running.

4. New — proc_creation_macos_malware_amos_wallet_app_replacement.yml

No equivalent upstream that I could find. AMOS does not only read wallet data — it terminates Ledger Wallet, Trezor Suite and Exodus, deletes the bundles as root and unpacks attacker-supplied builds into /Applications with ditto.

The archive names app.zip, apptwo.zip, appex.zip under a /zxc/ path have been constant across at least three unrelated hosts since 2025-11 (isnimitz[.]com, wusetail[.]com, and the host in our case), so the path segment is matched independently of the domain.

The distinction is operational: a user who enters a seed phrase after this has entered it into the operator's code. The wallet is lost, not exposed — different advice to the victim than "rotate your credentials".

Testing

tests/test_rules.py — 11 tests, OK. Schema validator — clean.

Related

Analysis, IOCs and the emulation tooling used to decrypt the payload: stage4_payload.md. Sample on MalwareBazaar.

Separate from #6205, which covers the delivery chain rather than the payload. No file overlap between the two.

🤖 Generated with Claude Code