PamStealer rende il recupero del payload per macOS dipendente dal server di comando

Un falso wallet Wavel diffonde la nuova catena d’infezione

Jamf Threat Labs ha identificato una variante di PamStealer che modifica sia il modello di protezione del payload sia la strategia di persistenza su macOS. Invece di includere localmente tutto il necessario per decrittare il malware principale, la campagna richiede uno scambio attivo con un’infrastruttura controllata dagli aggressori.

L’operazione sfrutta wavel[.]app, un sito fraudolento che promuove un finto wallet di criptovalute chiamato Wavel. Il pulsante «Download for macOS» scarica Wavel.dmg, che contiene un file AppleScript compilato.

Quando viene aperto, il file avvia Script Editor di Apple e mostra le istruzioni per eseguire un dropper in JavaScript for Automation, o JXA. Questa tecnica di ingegneria sociale punta a indurre la vittima a eseguire del codice, invece di sfruttare una vulnerabilità di macOS resa pubblica.

La campagna segue le precedenti attività di PamStealer osservate a luglio e agosto 2026. In quelle operazioni venivano usati siti contraffatti che imitavano le applicazioni Maccy, Scoppr e Nancy Clipboard. L’esca Wavel mantiene JXA, ma gli assegna un ruolo più circoscritto nel processo d’infezione.

Secondo quanto riportato nell’analisi di Jamf Threat Labs, il malware finale è ora scritto in Swift. La versione precedente era stata sviluppata in Rust.

JXA cede l’esecuzione a un processo zsh in background

Le prime varianti di PamStealer usavano JXA per svolgere diverse funzioni essenziali. Lo script decrittava un payload incorporato tramite RC4, interagiva con i framework Objective-C attraverso il bridge JXA per Foundation e NSData, scaricava contenuti aggiuntivi e preparava il malware all’esecuzione.

La versione diffusa tramite Wavel suddivide queste responsabilità.

L’AppleScript compilato avvia un componente JXA che contiene una stringa codificata in Base64. JXA decodifica i dati e invia lo script risultante a:

/bin/zsh -s

Il processo JXA termina, mentre il processo zsh avviato continua a operare in background. In questo modo JXA diventa un semplice vettore iniziale e le successive operazioni di rete, decrittazione e preparazione vengono eseguite dallo script shell.

La fase zsh contatta wavel.apple03cloudstore[.]com e scarica un’utility di decrittazione chiamata pkgunpack. Lo strumento partecipa a uno scambio di chiavi X25519 con il server degli aggressori, quindi decritta e prepara il bundle del payload.

Questa architettura complica l’analisi offline del malware. Avere a disposizione l’immagine disco, il codice JXA, lo script shell o il payload cifrato potrebbe non bastare per ricostruire l’eseguibile finale.

La decrittazione assistita dal server ostacola il recupero statico

Il server di comando e controllo conserva la chiave privata necessaria per completare lo scambio X25519 e derivare la Data Encryption Key, o DEK. Ogni esecuzione della catena d’infezione genera una nuova coppia di chiavi effimera.

Di conseguenza, una DEK acquisita durante un’esecuzione non può essere semplicemente riutilizzata per un’altra. Per recuperare il secondo stadio cifrato, i ricercatori hanno bisogno di una sessione C2 funzionante e della collaborazione del server, finché questo resta raggiungibile.

Questo design offre agli operatori diversi vantaggi sul piano difensivo. Possono limitare la distribuzione in base a criteri definiti lato server, interrompere il recupero del payload mettendo offline l’infrastruttura e rendere più difficile l’analisi retrospettiva dopo la raccolta di un artefatto dall’endpoint.

Crea però anche una dipendenza per gli aggressori. Se i difensori bloccano wavel.apple03cloudstore[.]com, oppure se il server non è disponibile prima che la decrittazione sia completata, la catena d’infezione non può derivare la chiave necessaria attraverso il flusso previsto.

L’analisi disponibile non specifica eventuali regole di filtraggio lato server. Non è inoltre noto se l’infrastruttura limiti le richieste in base alla posizione geografica, alle caratteristiche dell’host, al numero di esecuzioni o ad altri fattori.

Quattro meccanismi di persistenza si rafforzano a vicenda

Una volta installato, PamStealer cerca di nascondere le notifiche di macOS che normalmente avviserebbero l’utente della registrazione di un nuovo elemento di login in background. Quindi attiva quattro meccanismi di persistenza collegati tra loro.

Il primo è un LaunchAgent che avvia il malware a intervalli regolari. I nomi esatti dei file LaunchAgent e i percorsi dei relativi file property list non sono stati resi noti.

Il secondo componente è uno script zsh di ripristino. Verifica che il bundle del payload e il LaunchAgent siano ancora presenti e li ripristina se uno dei due manca. Eliminare un solo componente visibile potrebbe quindi non bastare: gli artefatti rimasti sul disco potrebbero consentire al malware di ripristinarsi.

PamStealer aggiunge anche un hook shell a ~/.zshrc. A ogni nuova sessione zsh interattiva può essere avviato lo script di ripristino, trasformando il normale uso del terminale in un’occasione per ripristinare il malware.

Il quarto meccanismo sfrutta gli hook di Git. Lo script di ripristino viene copiato nei percorsi post-checkout e pre-commit all’interno di:

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

Il malware modifica quindi l’impostazione globale core.hooksPath di Git, facendola puntare a quella directory. Di conseguenza, un checkout o un commit in qualsiasi repository sul Mac compromesso può eseguire la logica di ripristino.

Questa tecnica riguarda in particolare gli sviluppatori. Anche dopo aver rimosso il LaunchAgent o il bundle del payload, le normali attività con Git o l’apertura di una nuova shell possono ripristinare i componenti eliminati.

Lo stealer per Swift prende di mira password, portachiavi e dati dei browser

Il payload finale è un malware per il furto di informazioni scritto in Swift. Raccoglie credenziali, file locali, dettagli di sistema e informazioni utili a profilare l’host compromesso.

PamStealer mostra una falsa finestra di errore per chiedere la password di sistema dell’utente. Convalida poi le credenziali inserite tramite PAM, così da distinguere le password corrette da quelle non valide.

Il malware elenca e recupera anche gli elementi del portachiavi di macOS. Il furto delle credenziali dai browser riguarda un’ampia gamma di applicazioni diffuse, attente alla privacy, regionali e basate su Chromium:

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

Il supporto per Arc, Zen e browser meno diffusi amplia il potenziale bacino di vittime oltre le applicazioni più spesso prese di mira dai malware per il furto di credenziali su macOS.

Il malware raccoglie inoltre metadati di sistema e l’immagine del profilo dell’utente. Acquisisce anche diversi file relativi alla shell e allo sviluppo, tra cui:

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

La cronologia dei comandi può rivelare nomi host interni, strutture di directory, comandi di sviluppo, token inseriti direttamente dalla riga di comando o indizi sugli ambienti cloud e di controllo del codice sorgente. Lo stealer censisce anche i processi in esecuzione e le applicazioni installate.

Non sono stati forniti né una valutazione formale della gravità né un punteggio CVSS. In genere CVSS è pensato per le vulnerabilità software, non per le campagne malware; tuttavia, la combinazione di acquisizione delle password, accesso ai portachiavi, furto di dati dai browser e persistenza resiliente rappresenta un rischio significativo per gli utenti infetti.

Cosa controllare sui sistemi macOS

Al 26 settembre 2026, non sono state comunicate procedure di rimozione ufficiali né indicazioni autorevoli per la bonifica. Non è disponibile una patch, perché la campagna descritta non sfrutta una vulnerabilità software identificata.

I difensori dovrebbero innanzitutto bloccare i due domini noti e cercarli nei registri di rete storici:

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

Sugli endpoint è opportuno cercare anche Wavel.dmg, l’utility pkgunpack, LaunchAgent inattesi ed elementi di login in background sconosciuti. Una corrispondenza non dimostra da sola che sia stata completata l’intera sequenza d’infezione, ma richiede ulteriori verifiche.

Le modifiche a ~/.zshrc meritano particolare attenzione, soprattutto se contengono aggiunte che richiamano script da percorsi insoliti. Gli investigatori dovrebbero inoltre controllare la configurazione globale degli hook di Git con un comando adatto, ad esempio:

git config --global --get core.hooksPath

Un valore che punta alla directory seguente è un indicatore segnalato:

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

Gli analisti dovrebbero esaminare la directory alla ricerca di hook post-checkout e pre-commit inattesi. Rimuovere solo questi hook non è sufficiente se lo script di ripristino, il LaunchAgent o il bundle del payload sono ancora presenti altrove.

Poiché la decrittazione richiede uno scambio di chiavi in tempo reale, l’analisi statica potrebbe individuare gli script iniziali senza rivelare il payload Swift finale. La telemetria di rete, i log di esecuzione della shell, gli eventi di creazione dei file e le modifiche alla persistenza e alla configurazione di Git sono quindi elementi importanti dell’indagine.

Se la compromissione è confermata, le credenziali inserite nella finestra fraudolenta o archiviate nei browser e nei portachiavi presi di mira devono essere considerate esposte. Le password vanno cambiate e le sessioni revocate da un dispositivo sicuro, dopo aver isolato il Mac compromesso e rimosso completamente la catena di persistenza.