PamStealer macht die Wiederherstellung der macOS-Nutzlast vom C2-Server abhängig

Gefälschte Wavel-Wallet verbreitet neue Infektionskette

Jamf Threat Labs hat eine Variante von PamStealer identifiziert, die sowohl den Schutz der Nutzlast als auch die Persistenz auf macOS verändert. Statt alle zur Entschlüsselung der Haupt-Malware benötigten Komponenten lokal einzubetten, setzt die Kampagne einen aktiven Austausch mit einer von den Angreifern kontrollierten Infrastruktur voraus.

Die Angreifer nutzen wavel[.]app, eine betrügerische Website, die für eine fiktive Kryptowährungs-Wallet namens Wavel wirbt. Über die Schaltfläche „Download for macOS“ wird Wavel.dmg bereitgestellt, das eine kompilierte AppleScript-Datei enthält.

Beim Öffnen startet die Datei Apples Script Editor und zeigt Anweisungen an, nach denen der Nutzer einen JavaScript for Automation-Dropper (JXA) ausführen soll. Dieser Social-Engineering-Schritt setzt darauf, dass das Opfer den Code selbst ausführt, statt eine bekannte macOS-Schwachstelle auszunutzen.

Die Kampagne knüpft an frühere PamStealer-Aktivitäten an, die im Juli und August 2026 beobachtet wurden. Damals kamen gefälschte Websites zum Einsatz, die sich als Anbieter der Anwendungen Maccy, Scoppr und Nancy Clipboard ausgaben. Auch bei der Wavel-Kampagne wird JXA verwendet, allerdings mit einer enger gefassten Aufgabe innerhalb des Infektionsprozesses.

Laut Berichten zu den Erkenntnissen von Jamf Threat Labs ist die finale Malware inzwischen in Swift geschrieben. Die vorherige Version war in Rust implementiert.

JXA übergibt die Ausführung an einen zsh-Prozess im Hintergrund

Frühere PamStealer-Varianten nutzten JXA für mehrere zentrale Aufgaben. Das Skript entschlüsselte eine eingebettete Nutzlast mit RC4, griff über die JXA-Schnittstelle zu Foundation und NSData auf Objective-C-Frameworks zu, lud zusätzliche Inhalte herunter und bereitete die Malware für die Ausführung vor.

Die Wavel-Version verteilt diese Aufgaben auf mehrere Komponenten.

Das kompilierte AppleScript startet einen JXA-Träger, der eine Base64-kodierte Zeichenfolge enthält. JXA dekodiert die Daten und übergibt das daraus resultierende Skript an:

/bin/zsh -s

Anschließend wird der JXA-Prozess beendet, während der gestartete zsh-Prozess im Hintergrund weiterläuft. JXA dient damit nur noch als anfänglicher Träger; die anschließenden Netzwerk-, Entschlüsselungs- und Bereitstellungsschritte laufen im Shell-Skript ab.

Die zsh-Stufe stellt eine Verbindung zu wavel.apple03cloudstore[.]com her und lädt ein Entschlüsselungsprogramm namens pkgunpack herunter. Dieses Tool führt mit dem Server der Angreifer einen X25519-Schlüsselaustausch durch, bevor es das Nutzlastpaket entschlüsselt und bereitstellt.

Diese Architektur erschwert die Offline-Analyse der Malware. Der Besitz des Disk-Images, des JXA-Codes, des Shell-Skripts oder der verschlüsselten Nutzlast reicht nicht unbedingt aus, um die finale ausführbare Datei zu rekonstruieren.

Serverseitige Entschlüsselung verhindert einfache statische Rekonstruktion

Der Command-and-Control-Server verfügt über den privaten Schlüssel, der für den Abschluss des X25519-Austauschs und die Ableitung des Data Encryption Key (DEK) benötigt wird. Bei jedem Durchlauf der Infektionskette wird ein neues kurzlebiges Schlüsselpaar erzeugt.

Ein bei einer Ausführung erfasster DEK kann daher nicht einfach bei einer anderen wiederverwendet werden. Wer die verschlüsselte zweite Stufe rekonstruieren will, benötigt eine funktionierende C2-Verbindung und die Mitwirkung des Servers, solange dieser erreichbar ist.

Dieses Design verschafft den Betreibern mehrere Vorteile: Sie können die Auslieferung anhand serverseitiger Kriterien einschränken, die Wiederherstellung der Nutzlast durch das Abschalten der Infrastruktur unterbinden und die nachträgliche Analyse erschweren, sobald ein Artefakt vom Endgerät gesichert wurde.

Gleichzeitig entsteht dadurch eine Abhängigkeit für die Angreifer. Wenn Verteidiger wavel.apple03cloudstore[.]com blockieren oder der Server ausfällt, bevor die Entschlüsselung abgeschlossen ist, kann die Infektionskette den benötigten Schlüssel nicht wie vorgesehen ableiten.

Die verfügbare Analyse nennt keine konkreten serverseitigen Filterregeln, sofern solche überhaupt zum Einsatz kommen. Ebenfalls unbekannt ist, ob die Infrastruktur Anfragen nach Standort, Host-Merkmalen, Ausführungszahl oder anderen Kriterien begrenzt.

Vier Persistenzmechanismen greifen ineinander

Nach der Installation versucht PamStealer, die Systembenachrichtigungen zu unterdrücken, die Nutzer normalerweise über ein neu registriertes Hintergrund-Anmeldeobjekt informieren würden. Anschließend richtet die Malware vier miteinander verknüpfte Persistenzmechanismen ein.

Der erste ist ein LaunchAgent, der für die wiederholte Ausführung zuständig ist. Die genauen Dateinamen der LaunchAgents und die Pfade zu den Property-List-Dateien wurden nicht veröffentlicht.

Die zweite Komponente ist ein zsh-Reparaturskript. Es prüft, ob das Nutzlastpaket und der LaunchAgent noch vorhanden sind, und stellt sie wieder her, falls eines der beiden fehlt. Wird nur eine sichtbare Komponente gelöscht, kann das System daher weiterhin über auf der Festplatte verbliebene Artefakte erneut infiziert werden.

PamStealer fügt außerdem einen Shell-Hook zu ~/.zshrc hinzu. Bei jeder neuen interaktiven zsh-Sitzung kann dadurch das Reparaturskript ausgeführt werden. Die gewöhnliche Nutzung des Terminals wird so zum Auslöser für die Wiederherstellung der Malware.

Der vierte Mechanismus missbraucht Git-Hooks. Das Reparaturskript wird in die Verzeichnisse post-checkout und pre-commit unter folgendem Pfad kopiert:

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

Anschließend ändert die Malware Git-Einstellung core.hooksPath global, sodass sie auf dieses Verzeichnis verweist. Dadurch kann ein Checkout oder Commit in jedem Repository auf dem kompromittierten Mac die Reparaturlogik ausführen.

Das ist besonders für Entwickler relevant. Selbst wenn der LaunchAgent oder das Nutzlastpaket entfernt wurde, können gewöhnliche Git-Aktivitäten oder das Öffnen einer neuen Shell gelöschte Komponenten wiederherstellen.

Swift-basierter Stealer zielt auf Passwörter, Schlüsselbunde und Browserdaten

Bei der finalen Nutzlast handelt es sich um einen in Swift implementierten Infostealer. Er sammelt Anmeldedaten, lokale Dateien, Systeminformationen und Daten, die zur Profilierung des kompromittierten Hosts dienen können.

PamStealer zeigt einen gefälschten Absturzdialog an, um das Systempasswort des Nutzers abzugreifen. Anschließend überprüft die Malware die eingegebenen Zugangsdaten über PAM und kann so feststellen, ob das Passwort korrekt war.

Außerdem durchsucht PamStealer macOS-Schlüsselbunde und ruft darin gespeicherte Einträge ab. Der Diebstahl von Browser-Zugangsdaten betrifft eine breite Auswahl gängiger, datenschutzorientierter, regionaler und Chromium-basierter Anwendungen:

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

Die Unterstützung für Arc, Zen und weniger verbreitete Browser erweitert den potenziellen Opferkreis über die Anwendungen hinaus, auf die es macOS-Infostealer am häufigsten abgesehen haben.

Die Malware erfasst außerdem Systemmetadaten und das Profilbild des Nutzers. Zudem sammelt sie mehrere Dateien, die mit Shells und der Softwareentwicklung zu tun haben, darunter:

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

Befehlshistorien können interne Hostnamen, Verzeichnisstrukturen, Entwicklungsbefehle, direkt in die Kommandozeile eingegebene Tokens oder Hinweise auf Cloud- und Versionskontrollumgebungen enthalten. Darüber hinaus erfasst der Stealer laufende Prozesse und installierte Anwendungen.

Eine offizielle Schweregradbewertung oder ein CVSS-Score wurde nicht veröffentlicht. CVSS dient in der Regel der Bewertung von Softwareschwachstellen und nicht von Malware-Kampagnen. Die Kombination aus Passwortdiebstahl, Zugriff auf Schlüsselbunde, Browser-Datendiebstahl und robuster Persistenz stellt für infizierte Nutzer jedoch ein erhebliches Risiko dar.

Worauf Verteidiger macOS-Systeme untersuchen sollten

Mit Stand vom 26. September 2026 wurden weder eine vom Hersteller veröffentlichte Gegenmaßnahme noch ein verbindliches Verfahren zur Entfernung der Malware bekannt gegeben. Da die gemeldete Kampagne keine konkret benannte Softwareschwachstelle ausnutzt, gibt es keinen entsprechenden Patch.

Verteidiger sollten zunächst die beiden bekannten Domains blockieren und historische Netzwerkprotokolle nach ihnen durchsuchen:

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

Auf den Endgeräten sollte außerdem nach Wavel.dmg, dem Hilfsprogramm pkgunpack, unbekannten LaunchAgents und ungewöhnlichen Hintergrund-Anmeldeobjekten gesucht werden. Ein Treffer belegt für sich genommen zwar nicht den vollständigen Infektionsablauf, sollte aber Anlass für weitere Untersuchungen sein.

Änderungen an ~/.zshrc sollten genau geprüft werden. Besonders verdächtig sind Einträge, die Skripte an ungewöhnlichen Speicherorten aufrufen. Außerdem sollte die globale Git-Hook-Konfiguration mit einem geeigneten Befehl überprüft werden, zum Beispiel:

git config --global --get core.hooksPath

Ein Eintrag, der auf das folgende Verzeichnis verweist, ist ein bekannter Indikator:

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

Analysten sollten dieses Verzeichnis auf unerwartete post-checkout- und pre-commit-Hooks untersuchen. Es reicht nicht aus, nur diese Hooks zu entfernen, wenn das Reparaturskript, der LaunchAgent oder das Nutzlastpaket an anderer Stelle verblieben ist.

Da die Entschlüsselung einen aktiven Schlüsselaustausch voraussetzt, kann eine statische Analyse zwar die ersten Skripte finden, ohne jedoch die finale Swift-Nutzlast offenzulegen. Netzwerk-Telemetrie, Shell-Ausführungsprotokolle, Dateierstellungsereignisse sowie Änderungen an Persistenzmechanismen und der Git-Konfiguration sind daher wichtige Bestandteile der Untersuchung.

Wird eine Kompromittierung bestätigt, sollten Passwörter, die in den gefälschten Dialog eingegeben wurden oder in den betroffenen Browsern und Schlüsselbunden gespeichert waren, als offengelegt gelten. Passwörter sollten geändert und Sitzungen widerrufen werden – von einem nachweislich sauberen Gerät aus und erst, nachdem der betroffene Mac isoliert und die gesamte Persistenzkette entfernt wurde.