The latest version of PamStealer shows how quickly macOS information-stealing malware is evolving from relatively straightforward credential theft into a more carefully engineered delivery and persistence platform. The malware still pursues the same basic objective of stealing passwords, browser credentials, Keychain information, and other valuable data, but its operators have substantially redesigned how the payload reaches the victim and how it survives once installed.

The most important development is the introduction of a live server-side key exchange. Earlier PamStealer variants contained enough cryptographic material inside the initial malware to allow researchers to recover and analyze the next-stage payload offline. The latest version changes that model completely. It downloads a dedicated decryption utility called pkgunpack, generates a fresh ephemeral key pair, communicates with the attacker-controlled server, and obtains the information required to decrypt the next-stage payload only during that live session.

Without cooperation from the command-and-control infrastructure, the encrypted payload cannot simply be extracted and decrypted later in a laboratory. This is a significant defensive complication because security researchers often rely on static malware samples, cached downloads, or sandbox artifacts to reconstruct an infection after the attack infrastructure has disappeared.

The new design effectively makes the attacker's server part of the decryption process.

The fake Wavel application replaces earlier clipboard-manager lures

PamStealer was originally documented in July 2026 when it impersonated the legitimate Maccy clipboard manager. Subsequent campaigns used additional clipboard-related lures such as Scoppr and Nancy Clipboard.

The latest campaign has shifted tactics and now impersonates a nonexistent cryptocurrency wallet application called Wavel.

Victims are directed to a convincing fake website advertising the supposed wallet and encouraged to download Wavel.dmg. The disk image contains a compiled AppleScript file. Because macOS hides filename extensions by default, the .scpt file may appear to an ordinary user as a generic document rather than executable script content.

When opened, macOS Script Editor displays instructions encouraging the victim to execute the script. That begins the PamStealer infection process.

This is another example of attackers exploiting a familiar macOS workflow rather than relying on a software vulnerability. The victim is persuaded to execute the malicious content voluntarily.

The initial JXA stage has been deliberately simplified

Previous versions of PamStealer placed much of their download, decryption, and staging logic directly inside JavaScript for Automation, or JXA.

The new version strips most of that functionality out.

The JXA component now largely acts as a carrier for a Base64-encoded shell script. Once triggered, it decodes the content and pipes it directly into /bin/zsh.

The JXA process then exits while the malicious zsh process continues running in the background.

This separation has an important side effect: it breaks the obvious process relationship between Script Editor and the later malicious activity. Basic process-tree monitoring may therefore provide less immediate context about where the suspicious shell execution originated.

The attack sequence becomes roughly:

fake Wavel site → DMG → compiled AppleScript → JXA → zsh dropper → live key exchange → decrypted payload → credential theft and persistence

Live key exchange significantly complicates malware analysis

The most technically interesting component is pkgunpack, a small Mach-O binary specifically built to perform the cryptographic operations required to unlock the malware.

It supports both Intel and Apple Silicon systems and uses X25519 for key exchange together with AES-256-GCM for authenticated encryption.

On every execution, the malware creates a fresh ephemeral key pair. The public portion is sent to the attacker's server together with a nonce. The server responds with an encrypted Data Encryption Key, or DEK.

The malware then combines its temporary private key with a server public key to derive the material needed to decrypt that DEK. The resulting key is finally used to decrypt the encrypted PamStealer payload.

The critical part is that the attacker retains the server-side private key.

Without it, analysts cannot independently reproduce the key exchange.

A previously captured decryption response is also of limited value because the malware generates new ephemeral keys on every execution.

This makes the encrypted payload effectively dependent on live attacker infrastructure.

The technique gives the operator much greater control

This design is useful to attackers for several reasons.

First, researchers who obtain the encrypted payload may be unable to examine it if the C2 infrastructure has already been taken offline.

Second, the operator can selectively decide which requests receive valid decryption material.

That potentially allows the infrastructure to refuse requests from suspected security sandboxes, researchers, automated analysis systems, or regions the attacker does not want to target.

Third, the payload stored on infrastructure becomes less useful on its own. Even if defenders acquire the encrypted archive, the cryptographic key required to unlock it is generated dynamically through the live exchange.

The attacker's server is therefore no longer simply a file host. It becomes an active participant in determining whether the infection proceeds.

The payload now moves from Rust to Swift

PamStealer's second-stage malware has also been rewritten.

The original version documented by Jamf was developed in Rust. The latest variant uses Swift, Apple's native application-development language.

The programming-language change does not substantially alter the malware's objectives, but it shows that the operators are willing to rebuild major components rather than merely make superficial changes to existing code.

The Swift malware is packaged as an application that ultimately masquerades as:

Finder.app

inside:

~/Library/Application Support/System/

This gives the malicious application a name that resembles a fundamental macOS component, potentially making casual inspection less suspicious.

Password theft still relies on PAM validation

PamStealer retains the technique that originally gave the malware its name.

It displays a convincing macOS-style authentication dialog asking the user to enter their password. Instead of blindly accepting whatever the user provides, the malware validates the password through macOS Pluggable Authentication Modules, or PAM.

If the password is wrong, the attacker knows immediately.

If it is correct, the malware now possesses a verified macOS account password.

This small detail makes the credential theft significantly more reliable than malware that merely records whatever characters a victim happens to type into a fake password dialog.

Afterwards, PamStealer can display another fake macOS message claiming the application is damaged or cannot be opened, creating a plausible explanation for why the expected software did not start.

Keychain access significantly increases the impact

The malware also targets the user's macOS Keychain.

Jamf found that the new Swift payload attempts to unlock the login Keychain and modifies its access controls before enumerating and collecting stored entries. It also copies the login Keychain database into its staging directory.

This substantially increases the potential value of an infection because macOS Keychain may contain website passwords, application credentials, certificates, Wi-Fi credentials, API secrets, and other authentication material.

Once an attacker has both the user's verified login password and access to Keychain data, the compromise can extend far beyond the infected Mac.

Browser credential targeting has expanded considerably

The latest PamStealer variant targets credentials from a broad list of browsers.

These include Chrome, Edge, Firefox, Brave, Vivaldi, Opera, Opera GX, Chromium, Arc, Zen, Waterfox, LibreWolf, Yandex Browser, and Cốc Cốc, among others.

The inclusion of privacy-focused and regional browsers shows that the operators are attempting to capture credentials from a wider population rather than limiting themselves to the most common browser installations.

The malware also terminates browser helper processes before collecting databases. That can release file locks and allow credential stores to be copied reliably.

The technique is another example of the operators improving operational reliability rather than merely adding more target names to a list.

Persistence is now deliberately redundant

The latest PamStealer variant also adds several persistence mechanisms designed to restore one another.

The primary mechanism is a LaunchAgent masquerading as:

com.apple.finder.agent

It launches the malware when the user logs in and periodically restarts it.

But the attackers do not rely on that mechanism alone.

A separate repair script checks whether the malicious Finder application and LaunchAgent still exist. If either disappears, the script can restore them from a local backup without needing to contact the command-and-control server.

The malware additionally modifies the user's .zshrc, causing the repair script to run whenever a new interactive zsh session starts.

The result is a self-repairing persistence structure. Deleting one malicious component may accomplish little if another component recreates it moments later.

Git hooks provide an especially interesting persistence mechanism

One of the more unusual additions involves global Git hooks.

PamStealer creates malicious post-checkout and pre-commit hooks and changes Git's global core.hooksPath configuration to point to the attacker's directory.

That means operations such as:

git checkout

or:

git commit

can silently trigger the PamStealer repair script.

This is particularly relevant because Macs are widely used by developers.

A developer may remove the obvious LaunchAgent or application bundle and believe the system has been cleaned, only to trigger malware restoration later when working normally inside a Git repository.

It is a clever persistence technique because it hides inside a legitimate development workflow rather than an obviously malicious startup mechanism.

The malware also suppresses visible macOS warnings

The new variant attempts to interfere with macOS processes responsible for notifying users when background login items are added.

Before registering its LaunchAgent, the malware pauses components associated with background-task notifications and Notification Center.

After persistence is established, those processes are terminated so they later restart normally.

This reduces the chance that the victim receives a visible alert at exactly the moment the malicious background item is installed.

The technique indicates that the malware authors are paying close attention not just to security controls but also to the user-facing signals that might expose the infection.

Developer systems are particularly valuable targets

The malware collects files including .zsh_history, .zshrc, .bash_history, and .gitconfig.

That is noteworthy because shell histories and Git configurations can reveal server addresses, developer identities, internal repository locations, commands used for deployments, and occasionally credentials accidentally entered on the command line.

A compromised developer Mac may also contain access to GitHub, GitLab, AWS, Kubernetes, SSH systems, package registries, CI/CD infrastructure, and production environments.

PamStealer should therefore not be viewed merely as consumer credential-stealing malware.

In an enterprise environment, one infected developer workstation could become an entry point into much more valuable infrastructure.

The malware even collects the user's profile photograph

Jamf also found unusual collection of the victim's macOS account profile picture.

The malware retrieves the JPEG image directly from macOS Open Directory and places it in the collection archive alongside credentials and other system information.

The precise operational reason is unclear. It may improve victim profiling, assist social engineering, or simply reflect increasingly aggressive data collection.

Either way, it illustrates the level of host reconnaissance built into the malware.

Detection needs to focus on behavior rather than only hashes

The rapid evolution of PamStealer makes static indicators relatively fragile.

The lure has already changed from Maccy to Scoppr, Nancy Clipboard, and now Wavel. The stealer has moved from Rust to Swift. The payload-delivery process has been completely redesigned.

Defenders should therefore monitor behavioral patterns including unusual Script Editor activity followed by shell execution, zsh decoding data from standard input, removal of quarantine attributes using xattr, ad-hoc signing of downloaded binaries, unexpected LaunchAgents, modification of global Git hook configuration, suspicious .zshrc changes, and browser processes being terminated immediately before large-scale credential-file access.

The presence of an application called Finder.app outside Apple's normal system locations should also attract immediate attention.

Live C2 decryption creates a wider defensive challenge

The most important lesson from this variant is the move toward server-assisted payload concealment.

Security products and researchers often depend on recovering payloads from malicious infrastructure and analyzing them later.

PamStealer deliberately undermines that workflow.

An encrypted payload obtained today may become largely useless tomorrow if the attacker disables the key-exchange server.

That creates additional pressure for defenders to collect network telemetry and runtime behavior while the attack is active.

Dynamic analysis becomes increasingly important when static artifacts intentionally lack enough information to reveal their contents.

The broader cybersecurity lesson

PamStealer's evolution demonstrates that macOS malware operators are investing in much more than credential-stealing features.

The latest variant combines social engineering, live cryptographic key exchange, anti-analysis design, password validation, Keychain theft, broad browser targeting, notification suppression, multiple self-repairing persistence mechanisms, and developer-focused Git hooks.

No single technique is revolutionary.

The significance comes from how deliberately they have been combined.

The attack now progresses from a fake cryptocurrency application into a delivery architecture where the server decides whether the payload can even be decrypted, while the infected host receives several overlapping mechanisms designed to keep the malware alive.

That evolution should challenge the lingering assumption that macOS stealers are mostly crude malware aimed at cryptocurrency users.

PamStealer is showing considerably more engineering discipline.

The most important development is not that PamStealer steals more data. It is that the operators are making the malware harder to analyze, harder to remove, and more dependent on infrastructure they control in real time.

That is the difference between simply improving a stealer and investing in a malware platform.

Cybersecurity researchers have flagged a new version of PamStealer that ensures that the main payload can only be recovered using a server-side decryption chain. The latest artifacts, per Jamf Threat Labs, continue to rely on the same JavaScript for Automation (JXA) dropper mechanism, but modify the lure and the delivery method. "Where earlier variants embedded their payload key material

Source: PamStealer macOS Malware Adds Live C2 Payload Decryption and Multi-Layer Persistence via The Hacker News — published 25 Sep 2026.