Someone double-clicks what they think is Maccy, a clipboard manager, and gets a macOS password prompt: "Maccy wants to make changes." They type it in. Most infostealers would grab whatever you typed and run. This one validates it against PAM first -- the same Pluggable Authentication Modules stack macOS uses to actually authenticate you -- and only keeps it if it's real.
That's PamStealer (Jamf's name; ManageEngine tracks the same campaign as "Fake Maccy Stealer"). Two stages, and the interesting part for practitioners isn't that it exists -- it's how deliberately it routes around the process-based signals most macOS detection keys on. It's quieter than the commodity norm in the places that matter, and loud in a couple of places it can't avoid. Here's the chain, then how to hunt it.
Stage 1: the dropper mostly doesn't shell out
Delivery is the usual macOS pattern with a twist. A compiled AppleScript, Maccy.scpt, ships on a disk image from a lookalike domain (maccyapp[.]com) and opens in Script Editor. Inside is an obfuscated JXA (JavaScript for Automation) payload that does the download.
The twist: it doesn't call curl or zsh. It fetches and stages through NSURLSession and the Objective-C bridge -- native APIs, no shell subprocess for the network stage. That kills the process-spawn signal a lot of behavioral rules lean on.
