PamStealer Makes macOS Payload Recovery Depend on Its Command Server

Fake Wavel wallet delivers the new infection chain

Jamf Threat Labs has identified a PamStealer variant that changes both its payload-protection model and its persistence strategy on macOS. Instead of embedding everything needed to decrypt the main malware locally, the campaign requires an active exchange with attacker-controlled infrastructure.

The operation uses wavel[.]app, a fraudulent website promoting a fictitious cryptocurrency wallet named Wavel. Its “Download for macOS” button serves Wavel.dmg, which contains a compiled AppleScript file.

When opened, that file launches Apple’s Script Editor and presents instructions telling the user to run a JavaScript for Automation, or JXA, dropper. This social-engineering step relies on the victim executing code rather than exploiting a disclosed macOS vulnerability.

The campaign follows earlier PamStealer activity observed in July and August 2026. Those operations used counterfeit sites impersonating the Maccy, Scoppr, and Nancy Clipboard applications. The Wavel lure retains JXA but assigns it a narrower role in the infection process.

According to reporting on Jamf Threat Labs’ findings, the final malware is now written in Swift. The previous implementation used Rust.

JXA hands execution to a background zsh process

Earlier PamStealer variants used JXA to perform several core functions. The script decrypted an embedded payload with RC4, interacted with Objective-C frameworks through JXA’s bridge to Foundation and NSData, downloaded additional content, and staged the malware.

The Wavel version separates those responsibilities.

Its compiled AppleScript starts a JXA carrier containing a Base64-encoded string. JXA decodes that data and sends the resulting script to:

/bin/zsh -s

The JXA process then terminates, while the spawned zsh process continues in the background. This transition reduces JXA to an initial carrier and places subsequent network, decryption, and staging operations inside the shell script.

The zsh stage contacts wavel.apple03cloudstore[.]com and downloads a decryption utility called pkgunpack. That tool participates in an X25519 key exchange with the attacker’s server before decrypting and staging the payload bundle.

This architecture complicates offline malware analysis. Possession of the disk image, JXA code, shell script, or encrypted payload is not necessarily sufficient to reconstruct the final executable.

Server-assisted decryption blocks simple static recovery

The command-and-control server holds the private key required to complete the X25519 exchange and derive the Data Encryption Key, or DEK. A fresh ephemeral key pair is created each time the infection chain runs.

Consequently, a DEK captured during one execution cannot simply be reused for another. Researchers attempting to recover the encrypted second stage need a functioning C2 session and cooperation from the server while it remains reachable.

This design provides the operators with several defensive advantages. They can restrict delivery based on server-side criteria, discontinue payload recovery by taking infrastructure offline, and make retrospective analysis harder after an endpoint artifact has been collected.

It also creates a dependency for the attackers. If defenders block wavel.apple03cloudstore[.]com, or if the server becomes unavailable before decryption completes, the infection chain cannot derive the required key through its intended workflow.

The available analysis does not disclose the precise server-side filtering rules, if any. It is also unknown whether the infrastructure limits requests by location, host characteristics, execution count, or other conditions.

Four persistence paths reinforce one another

Once installed, PamStealer attempts to hide the operating system notifications that would ordinarily alert a user to a newly registered background login item. It then establishes four connected persistence mechanisms.

The first is a LaunchAgent responsible for recurring execution. Exact LaunchAgent filenames and property-list paths have not been disclosed.

The second component is a zsh repair script. It checks whether the payload bundle and LaunchAgent remain present and restores them when either is missing. Deleting only one visible component may therefore leave the system vulnerable to reinfection from artifacts that remain on disk.

PamStealer also appends a shell hook to ~/.zshrc. Each new interactive zsh session can invoke the repair script, turning routine terminal use into a recovery trigger for the malware.

The fourth mechanism abuses Git hooks. The repair script is copied into post-checkout and pre-commit locations beneath:

~/Library/Application Support/System/.githooks/

The malware then changes Git’s global core.hooksPath setting to point at that directory. A checkout or commit in any repository on the compromised Mac can consequently execute the repair logic.

This arrangement is particularly relevant to developers. Even after removing the LaunchAgent or payload bundle, ordinary Git activity or opening a new shell may restore deleted components.

Swift stealer targets passwords, keychains, and browser data

The final payload is an information stealer implemented in Swift. Its collection scope covers credentials, local files, system details, and information useful for profiling the compromised host.

PamStealer displays a counterfeit crash dialog to request the user’s system password. It then validates submitted credentials through PAM, allowing the malware to distinguish a correct password from an unsuccessful entry.

It also enumerates and retrieves macOS keychain items. Browser credential theft covers a broad mix of mainstream, privacy-focused, regional, and Chromium-derived applications:

• Google Chrome
• Microsoft Edge
• Mozilla Firefox
• Brave
• Vivaldi
• Opera
• Opera GX
• Arc
• Zen
• Waterfox
• LibreWolf
• Yandex Browser
• Cốc Cốc

Support for Arc, Zen, and less-common browsers widens the potential victim pool beyond the applications most frequently targeted by macOS credential stealers.

The malware also gathers system metadata and the user’s profile image. It collects several shell and developer-related files, including:

~/.zsh_history
~/.zshrc
~/.bash_history
~/.gitconfig

Command histories may expose internal hostnames, directory structures, development commands, tokens entered directly on the command line, or clues about cloud and source-control environments. The stealer additionally inventories running processes and installed applications.

No formal severity rating or CVSS score has been provided. CVSS is generally designed for software vulnerabilities rather than malware campaigns, but the combination of password capture, keychain access, browser theft, and resilient persistence represents a substantial risk to infected users.

What defenders should inspect on macOS systems

As of September 26, 2026, no vendor-issued remediation or authoritative removal procedure has been disclosed. There is no patch because the reported campaign does not depend on a named software vulnerability.

Defenders should begin by blocking and searching historical network records for the two known domains:

wavel[.]app
wavel.apple03cloudstore[.]com

Endpoints should also be examined for Wavel.dmg, the pkgunpack utility, unexpected LaunchAgents, and unfamiliar background login items. A match does not by itself establish the complete infection sequence, but it warrants deeper investigation.

Changes to ~/.zshrc deserve close scrutiny, especially additions that invoke scripts from unusual locations. Investigators should also check Git’s global hooks configuration with an appropriate command such as:

git config --global --get core.hooksPath

A value pointing to the following directory is a reported indicator:

~/Library/Application Support/System/.githooks/

Analysts should inspect that location for unexpected post-checkout and pre-commit hooks. Removing only those hooks is insufficient if the repair script, LaunchAgent, or payload bundle remains elsewhere.

Because decryption requires a live key exchange, static scanning may find the initial scripts without exposing the final Swift payload. Network telemetry, shell execution records, file-creation events, persistence changes, and Git configuration modifications are therefore important parts of the investigation.

If compromise is confirmed, credentials entered into the fake dialog or stored in targeted browsers and keychains should be treated as exposed. Password changes and session revocation should be performed from a known-clean device after the affected Mac has been contained and the persistence chain fully removed.