New PamStealer macOS Malware Uses Clever Tradecraft To Remain Stealthy (arstechnica.com) 21
An anonymous reader quotes a report from Ars Technica: Researchers have found a never-before-seen piece of macOS malware that combines a series of clever tradecraft to infect Macs with stealthy, custom-developed credential-stealing code. The malware is delivered in two stages. The first is distributed in a disk image that masquerades as Maccy, a clipboard manager for Macs. It's compiled as AppleScript that is notable for the way it delivers the second stage. The malware is named PamStealer because the Rust-written infostealer uses the Pluggable Authentication Modules interface built into macOS to validate the target's login password before sending it to an attacker-controlled server.
[...] PamStealer shows a native password prompt designed to resemble a system authorization request. Text that appears with the prompt says: "Maccy wants to make changes. Enter your password to allow this." As noted earlier, once a target complies, the malware validates it locally through the PAM API. "This check is done entirely through PAM: there is no call out to dscl, security, osascript or any spawned process to verify the password, as many commodity macOS stealers do," [said Jamf, a security firm for macOS users]. "The result is a quieter routine that keeps only a verified password, and one fewer process chain for defenders to detect on."
If the validation fails, PamStealer displays the prompts again until it receives the correct one. Once the target enters the correct password, PamStealer displays a message stating that the file is damaged and can't be installed. This is designed to be a decoy to prevent the target from suspecting anything is amiss. The malware uses tactics to maximize the information it can steal. One tactic is to request the target grant full disk access to the fake Maccy app. It also contains code designed to access ethereum accounts. The various techniques -- particularly the Script Editor lure, a self-contained JXA dropper, a Rust-based second stage, and local validation of credentials through PAM are all noteworthy.
[...] PamStealer shows a native password prompt designed to resemble a system authorization request. Text that appears with the prompt says: "Maccy wants to make changes. Enter your password to allow this." As noted earlier, once a target complies, the malware validates it locally through the PAM API. "This check is done entirely through PAM: there is no call out to dscl, security, osascript or any spawned process to verify the password, as many commodity macOS stealers do," [said Jamf, a security firm for macOS users]. "The result is a quieter routine that keeps only a verified password, and one fewer process chain for defenders to detect on."
If the validation fails, PamStealer displays the prompts again until it receives the correct one. Once the target enters the correct password, PamStealer displays a message stating that the file is damaged and can't be installed. This is designed to be a decoy to prevent the target from suspecting anything is amiss. The malware uses tactics to maximize the information it can steal. One tactic is to request the target grant full disk access to the fake Maccy app. It also contains code designed to access ethereum accounts. The various techniques -- particularly the Script Editor lure, a self-contained JXA dropper, a Rust-based second stage, and local validation of credentials through PAM are all noteworthy.
Happy to see... (Score:5, Funny)
Re: (Score:3)
It's memory safe!
Re: (Score:2)
Exactly. For once, the attackers show the world how it is done!
Bypassing notarization (Score:2)
Re: (Score:2)
What has AppleScript to do with that?
Same problem if it was a Bash script or a compiled C program ...
Re: (Score:3)
This has nothing to do with AppleScript. It has to do with the boneheaded decision to have Mac OS X and its successor constantly prompting users for passwords to do "admin" things, even if they're logged in as an admin. This has been a flaw since 10.0, and I was complaining about it in the 10.2 days, and getting told I shouldn't worry my pretty little head about it and that nobody would ever write malware that puts up something that looks like a system request for your password, such a fraud would be unposs
Re: Bypassing notarization (Score:3)
Not even adminy stuff, why TF do I need to enter a password just to run the lldb debugger as me on one of my own binaries??
Sounds more like PamAsker. (Score:2)
Lol (Score:2)
Same sort of technique I used back in secondary school, lol ;) We had a programming class (in Basic on DOS), and it was painfully trivial, so I'd always complete the assignments in like 5 minutes and then spend the rest of class messing around. So one thing I wrote was a program that mimick
Must be a slow news day (Score:2)
Re: (Score:2)
Thank God Mac OS X hasn't been training people to enter their admin password whenever they install anything or do anything adminy using an easily replicated dialog since 2001. Otherwise people might fall for this!
Re: (Score:2)
Like sudo?
Re: (Score:2)
It's asking for the root password. How can Sudo help? Maybe you can hack the installer to use your jailed account? I'm not sure how this fixes anything. If you were doing the install from the command line, sure. But not a hard coded script app.
Re: (Score:2)
They’re saying linux does the exact same thing.
Always Worry (Score:2)
Every time I install a 3rd party app, I worry about typing my password for anything. I mean I guess I could change root, install the app, and change root back. That is the number one reason I do NOT hate the walled garden. It can be annoying, but the odds are that your apps are safe.
Re: Always Worry (Score:2)
the older and dumber i get, the more i appreciate the walled garden, all its glaws notwithstanding.