SANS says the Macfinger ClickFix payload is not the AMOS stealer
Victoria Shinder2 min readThe macOS information stealer spread by the Macfinger ClickFix campaign is probably not a variant of Atomic macOS Stealer (AMOS), as it was first reported. Brad Duncan of the SANS Internet Storm Center reached that conclusion on 25 September after running a fresh infection on a physical Mac with macOS 27.0 the day before. His list of differences covers data collection, exfiltration, persistence and packaging, and he says plainly that he does not yet know what to call the malware.
The chain starts like every ClickFix lure: a fake CAPTCHA page puts a command on the clipboard and asks the visitor to paste it into Terminal. That command pulls a shell script which checks uname -m and downloads either an arm64 or an x86_64 Mach-O binary. AMOS ships one universal installer for both architectures. The binary talks to its server over websocket as well as HTTP POST, identifies itself as Go-http-client/1.1, and reports each stage - download, exec_start, exec_ok - before uploading data to an /api/credentials path. Persistence is a LaunchAgent named com.apple.softwareupdated.plist pointing at a copy under Library/Caches/com.apple.softwareupdate/. Three copies found on the host differed slightly in size and hash, which defeats a single-hash block.
Before stealing anything, the malware triggered a run of standard macOS consent prompts: Terminal asking for the Documents, Desktop and Downloads folders, the photo library and Apple Music, "bash" asking to control Notes, and finally dialogs asking for the administrator password and the Keychain password. The diary publishes the indicators, including the loader and C2 addresses and SHA-256 hashes.
What it means
The naming question is not academic. Detections, threat-intelligence feeds and incident playbooks are often keyed to a family name; if this is a separate family, signatures written for AMOS will miss the persistence path and the websocket channel, and a responder who "knows AMOS" will look in the wrong places. Treat the published file paths and network patterns as the indicators, not the label.
The defensive lesson is the same one ClickFix keeps teaching. The attack works because the victim runs the first command themselves, and every later step is a legitimate operating-system prompt they have learned to approve. Blocking Terminal from being the parent of curl | sh style chains, alerting on new LaunchAgents whose names imitate Apple services, and telling staff that no website ever needs a Terminal command to prove they are human all address the actual mechanism. Watching for a filename or a hash does not, because the samples change from copy to copy.