Skip to content

PamStealer macOS Malware: Wavel Lure, Live C2 Decryption Explained

PamStealer macOS Malware: Wavel Lure, Live C2 Decryption Explained

A fake crypto wallet site now delivers a version of PamStealer that can't be fully decrypted offline — and adds four ways to survive a reboot.

Stylized illustration of a fake 'Wavel' crypto wallet download page next to a padlocked box representing an encrypted malware payload
Conceptual illustration — not an actual screenshot of the Wavel site or malware interface. Source: Generated by UnpanicTech.

Fake crypto wallet apps have become one of the more reliable ways to get a Mac user to run something they shouldn't. Cybersecurity researchers have now flagged a new version of PamStealer that ensures its main payload can only be recovered through a live, server-side decryption chain [1]. That single design decision, more than any single new feature, is what makes this update worth paying attention to: earlier variants could be picked apart on a static file alone, and this one largely can't.

What changed since the first PamStealer sighting

PamStealer isn't new. Jamf Threat Labs first documented it in July 2026 as a macOS infostealer distributed through a fake site impersonating Maccy, a real and popular clipboard manager, and named it for its habit of validating a victim's password through macOS's Pluggable Authentication Modules (PAM) before exfiltrating it [3]. That original version was a two-stage chain: a compiled AppleScript dropper, followed by a Rust-based stealer that handled credential theft, browser data collection, persistence, and exfiltration [3].

Between July and August 2026, the group behind it rotated through decoys impersonating Maccy, Scoppr, and Nancy Clipboard [1]. The latest wave drops that clipboard-utility disguise entirely. Victims are now pointed to "wavel[.]app," a fake site advertising a multichain crypto wallet that doesn't actually exist [1]. Clicking "Download for macOS" pulls down a disk image, Wavel.dmg, containing a compiled AppleScript file. Opening it launches Apple's built-in Script Editor with instructions telling the victim to trigger the script [1] — the same social-engineering trick Jamf described in July, just wearing a different costume.

How the infection chain actually works

What's technically interesting here isn't the lure — fake download buttons are old news — it's what the AppleScript no longer does. In the Maccy, Scoppr, and Nancy versions, the JXA (JavaScript for Automation) source handled RC4 decryption of an embedded payload directly and made calls into Objective-C frameworks through JXA's bridge to Foundation and NSData [1]. In the Wavel version, according to Jamf researcher Thijs Xhaflaire, none of that logic lives in the JXA layer anymore — it's reduced to a carrier. When Script Editor runs the file, it decodes a large base64 blob and pipes the result into /bin/zsh -s, so zsh reads and executes the decoded bytes from standard input, and the JXA process exits almost immediately while the zsh dropper continues running in the background [1].

Flow diagram showing the PamStealer Wavel infection chain: fake site, disk image, AppleScript carrier, zsh dropper, X25519 key exchange with the C2 server, and the resulting Swift-based stealer
The infection chain as described by Jamf Threat Labs. The key-exchange step is what blocks static analysis of the payload. Source: Generated by UnpanicTech, based on reporting in [1].

Once running, the decoded zsh script downloads a purpose-built decryption utility Jamf calls "pkgunpack" from a domain the researchers identified as wavel.apple03cloudstore[.]com, then performs an X25519 key exchange with that server before the payload can be unwrapped [1]. Xhaflaire put it plainly: without the server's cooperation, the payload can't be recovered statically [1].

The mechanics matter for anyone trying to analyze a captured sample later. Because the server holds the private key needed to complete the exchange, the Data Encryption Key can't be reconstructed without it — and because a fresh ephemeral keypair gets generated on every run, even a DEK captured during one infection can't be replayed to unlock a different payload copy [1]. In practical terms, an incident responder who pulls the encrypted payload off a disk after the fact, without a live C2 session to talk to, is stuck. That's a meaningful shift from a malware family that, in its earlier form, decrypted everything locally with an embedded RC4 key.

Four ways to survive a reboot

The zsh dropper also handles persistence, and it's more elaborate than the original PamStealer setup. Jamf's analysis describes the dropper suppressing the macOS notification that would normally alert a user when a new background login item is added, then installing what amounts to four redundant mechanisms so the infection survives cleanup attempts [1].

Mechanism What it does
LaunchAgent Standard login-time launch entry, notifications suppressed during install
Repair zsh script Restores the payload bundle and the LaunchAgent if either is removed
Shell hook in ~/.zshrc Runs the repair script automatically on every new interactive zsh session
Git hooks (core.hooksPath) Repair script placed in a global hooks directory, triggered by any git checkout or commit on the machine

The git-hooks piece is the one worth dwelling on. Setting git config --global core.hooksPath to a controlled directory is a legitimate, documented Git feature [5] — it's meant for teams that want shared hook scripts across repositories. Here it's repurposed so that any ordinary git checkout or git commit on the infected machine — something a developer might do dozens of times a day — quietly re-triggers the repair script [1]. It's a reasonable bet that a Mac running Wavel-flavored bait is more likely than average to belong to someone who uses git regularly, which makes this a fairly well-targeted persistence choice rather than a generic one.

A language switch, and a wider net on browsers

The final-stage stealer has also changed under the hood. Where the original PamStealer payload was written in Rust, this one is Swift [1]. The goals are unchanged from the July version: capture the system password through a fake crash dialog, cross-check it via PAM, enumerate keychain items, and pull credentials out of browser data stores [1].

The browser list has grown noticeably. Beyond the usual Chrome, Edge, and Firefox, Jamf lists Brave, Vivaldi, Opera, Opera GX, Arc, Zen, Waterfox, LibreWolf, Yandex Browser, and Cốc Cốc as targets [1]. Xhaflaire noted that including Arc, Zen, and less common regional or privacy-focused browsers extends the target list noticeably beyond what's typical in commodity macOS stealers [1] — a sign the operators are actively trying to widen their reach rather than coasting on a Chrome-only build. The stealer also grabs system metadata, the user's profile photo, running processes, installed applications, and files like .zsh_history, .zshrc, .bash_history, and .gitconfig [1].

What's still unverified

There's no CVE here and nothing to check against CISA's KEV catalog — this is social-engineering-driven commodity malware, not a software vulnerability. It's also worth being precise about what hasn't been independently confirmed: the scale of the Wavel campaign, how many people have actually been infected, and full attribution of the operators aren't addressed in the available reporting. The claims in this piece describe what Jamf found in the samples it analyzed, not the size of the active campaign.

What actually helps

None of this requires exotic defenses. The lure only works if someone runs a downloaded script by hand, so the practical advice hasn't really changed since July: install software from the developer's own site or the App Store, be suspicious of any "app" that opens in Script Editor instead of just launching, and don't type your Mac password into a dialog you weren't expecting. If you've run anything from a site claiming to be Wavel, rotating your saved browser passwords, checking Keychain for unfamiliar entries, and reviewing git config --global --list for an unexpected core.hooksPath value are reasonable first steps. Security teams watching for this specifically can look for outbound connections to newly spawned processes descended from Script Editor, and for zsh processes that outlive their parent osascript/Script Editor session — the "severed ancestry" trick Jamf describes is unusual enough to stand out in process-tree monitoring.

Sources & References

  1. The Hacker News — "PamStealer macOS Malware Adds Live C2 Payload Decryption and Multi-Layer Persistence" (Sep 25, 2026)
  2. Jamf Threat Labs — Wavel/PamStealer analysis by Thijs Xhaflaire
  3. The Hacker News — "PamStealer Uses Fake Maccy Sites and PAM Checks to Steal Mac Login Passwords" (Jul 3, 2026)
  4. Jamf Threat Labs — original PamStealer AppleScript/Rust writeup (Jul 2, 2026)
  5. Git SCM official documentation — githooks
NK

Naseem Khan (Technical Editor)

Cybersecurity Researcher & Technical Editor

UnpanicTech is supported by a dedicated team of cybersecurity specialists and writers. All research and articles are comprehensively reviewed and published by our Technical Editor, Naseem Khan, covering vulnerability analysis, defensive security, incident response, cloud security, and practical security engineering.

Technical Discussion & Feedback

Leave a Comment (Authenticated Users)