A new version of PamStealer is making the rounds, and this one is built so the main payload can only be recovered with help from the attacker's server, which means static analysis alone cannot unwrap it.

Jamf Threat Labs published the analysis, and the short version is that the malware still uses the same JavaScript for Automation dropper mechanism, but both the lure and the delivery method have changed, and the changes make this variant notably harder to study.

Security researcher Thijs Xhaflaire explained that earlier variants embedded their payload key material directly in the JXA source, but this one fetches a purpose-built decryption utility and completes a key exchange with the server before the payload can be unwrapped, so without the server's cooperation, the payload cannot be recovered statically.

Quick Summary

The Lure Has Changed Too

The second major change is the decoy itself, because previous versions seen in July and August 2026 used fake websites masquerading as Maccy, Scoppr, and Nancy Clipboard, but victims are now lured through a bogus website at wavel[.]app advertising a non-existent cryptocurrency wallet service called Wavel.

Clicking the Download for macOS button on the fake site retrieves a disk image file called Wavel.dmg, which contains a compiled AppleScript file, and opening that file launches Apple's built-in Script Editor with instructions to trigger the execution of a JXA dropper.

So the bait has shifted from clipboard utilities to crypto wallets, which is a more tempting target for the kind of user who might not think twice about installing a new wallet app.

What the JXA Layer Does Now

Xhaflaire explained the difference clearly, saying that in Maccy, Scoppr, and Nancy, the JXA source performed RC4 decryption of an embedded payload, made Objective-C framework calls through JXA's bridge to Foundation and NSData, and managed the entire download and staging process.

In Wavel, the JXA source contains none of that, and the entire JXA layer is now just a carrier, because when Script Editor executes the file, it decodes the base64 string and pipes the result into /bin/zsh -s, where zsh reads and executes the decoded bytes from standard input, and the JXA process exits immediately while the zsh dropper continues in the background.

So the JXA is no longer doing the heavy lifting, it is just a delivery mechanism for a shell script, and that shell script is where the real work begins.

What the zsh Script Does

The decoded zsh script carries the infection forward by doing several things, starting with downloading and invoking a decryption utility called pkgunpack from wavel.apple03cloudstore[.]com, then performing the X25519 key exchange, then decrypting and staging the payload bundle.

It also suppresses macOS notifications that alert users when a new background login item is added, which is important because that notification is one of the few visible signs of persistence on macOS.

Then it installs four redundant persistence methods, which include a LaunchAgent, a repair zsh script that restores both the payload bundle and the LaunchAgent if they are not present, and a shell hook appended to ~/.zshrc that triggers the execution of the repair script on every new interactive zsh session.

Finally, it polls for and uploads the staging directory in the form of a ZIP archive, so the stolen data goes back to the attacker.

Why the Server-Side Decryption Matters

Because the server holds the private key that completes the key exchange process, the Data Encryption Key cannot be recovered without it, which prevents the payload from being decrypted, and because a new ephemeral keypair is generated during every execution, a captured DEK value cannot be replayed to extract the contents of the payload.

This renders the encrypted payload effectively useless for static analysis without access to a live command-and-control session, which is a deliberate design choice that shifts control to the server operator.

So if researchers capture a sample without a live C2, they can see the dropper and the persistence mechanisms, but they cannot see what the final payload actually does.

The Git Hook Trick

There is one more persistence method that stands out, because the repair script is copied to post-checkout and pre-commit folders within ~/Library/Application Support/System/.githooks/, and the Git configuration option git config --global core.hooksPath is set to that directory.

As a result, any git checkout or git commit action in any repository on the compromised system will silently activate the repair script, which means the malware gets a fresh chance to run every time the developer interacts with Git.

That is a clever choice, because developers run git commands constantly, so the persistence mechanism is triggered by normal workflow rather than by anything unusual.

The Final Stage: A Swift Stealer

The final stage is the stealer component, which is written in Swift, marking a departure from the predecessor that was implemented in Rust, and despite the change in programming language, the end goal is the same.

It captures the system password by serving a fake crash dialog and cross-checks the entered information using a PAM-based validation approach, then enumerates and retrieves keychain items, and steals credentials from a long list of browsers including Google Chrome, Microsoft Edge, Mozilla Firefox, Brave, Vivaldi, Opera, Opera GX, Arc, Zen, Waterfox, LibreWolf, Yandex Browser, and Cốc Cốc.

It also fingerprints the system and gathers extensive metadata and the user's profile photo, collects user-centric files like .zsh_history, .zshrc, .bash_history, and .gitconfig, and lists running processes and installed applications.

Xhaflaire noted that the inclusion of Arc, Zen, and the less common regional and privacy-focused browsers extends the target list noticeably beyond what is typical in commodity macOS stealers, so this variant is casting a wider net than most.

The Bigger Picture

Xhaflaire said this variant of PamStealer reflects a deliberate investment in delivery infrastructure, because the pkgunpack utility introduces a live key exchange that ties payload decryption to server availability, and without C2 cooperation, the second stage cannot be decrypted.

That design makes static recovery of the payload significantly harder and shifts part of the operational control to the server operator, which means defenders cannot rely on capturing a sample and analyzing it in isolation.

So the practical takeaway is that macOS users should be cautious about installing wallet apps from unfamiliar sites, developers should watch for unexpected git hooks in their global config, and security teams should treat any suspicious LaunchAgent or zsh hook as a potential sign of compromise.

The Bottom Line

PamStealer is back with a server-side decryption chain that makes static analysis much harder, and it now spreads through a fake cryptocurrency wallet site, installs four persistence mechanisms including a git hook trick that triggers on normal developer activity, and finishes with a Swift-based stealer that targets a wider range of browsers than most macOS malware, so if you see Wavel.dmg or a suspicious pkgunpack utility on a Mac, treat it as a serious incident.

Quick Reference

What to Do

• Avoid installing wallet apps from unfamiliar sites
• Check for unexpected git hooks in global config
• Review LaunchAgents and zsh hooks for suspicious entries
• Watch for Wavel.dmg and pkgunpack on macOS systems
• Treat any suspicious persistence as a serious incident
• Rotate credentials if compromise is suspected

FAQ Section

What is PamStealer?

It is a macOS stealer that has been updated with a server-side decryption chain, so the main payload can only be recovered with help from the attacker's server.

How does the new variant spread?

Through a fake cryptocurrency wallet website at wavel[.]app, which delivers a disk image containing a compiled AppleScript that launches a JXA dropper.

Why is the server-side decryption important?

Because the server holds the private key needed to complete the key exchange, so without a live C2 session, the payload cannot be decrypted or analyzed statically.

What persistence methods does it use?

It installs a LaunchAgent, a repair zsh script, a shell hook in ~/.zshrc, and a git hook configuration that triggers the repair script on git checkout or git commit.

What does the final stealer do?

It captures the system password through a fake crash dialog, steals keychain items, browser credentials from many browsers, user files, and system metadata.

What should I do if I suspect infection?

Remove the malware, check for unexpected git hooks and LaunchAgents, rotate credentials, and treat the incident as serious.

Source: The Hacker News