PamStealer sur Mac : le faux wallet qui fait taire les alertes

Un faux portefeuille de cryptomonnaies ne cherche pas seulement à voler des actifs numériques. Sur un Mac d’entreprise, il peut ouvrir la porte aux mots de passe, au trousseau, aux sessions navigateur et aux documents accessibles par l’utilisateur. La nouvelle variante de PamStealer analysée par Jamf Threat Labs illustre surtout une évolution plus discrète : le programme malveillant fait dépendre son déchiffrement d’un serveur distant, étouffe une alerte macOS et installe plusieurs mécanismes capables de réparer sa persistance.

Le cas ne signifie ni qu’Apple a été compromis, ni qu’un produit légitime nommé Wavel est en cause. Jamf décrit un site leurre imitant un portefeuille multichaîne et distribuant une image disque malveillante. L’intérêt pour une entreprise est ailleurs : la confiance accordée à un écran familier, à un faux dialogue système ou à un nom ressemblant à un composant macOS peut suffire à transformer une installation volontaire en compromission durable.

L’enjeu n’est donc pas de demander aux utilisateurs d’analyser un binaire Swift. Il consiste à réduire les installations improvisées, rendre les comportements anormaux visibles et savoir isoler un Mac avant de réinitialiser les secrets potentiellement exposés.

Le point de départ est un site convaincant qui se présente comme celui de « Wavel », un portefeuille multichaîne. Son bouton de téléchargement pour macOS fournit un fichier DMG contenant un AppleScript compilé. Le fichier ne porte pas de nom visible, seulement l’extension .scpt ; comme le Finder masque généralement les extensions, il peut ressembler à un document générique.

L’utilisateur est invité à ouvrir ce fichier puis à exécuter son contenu dans Script Editor. Le JavaScript for Automation embarqué ne contient plus toute la logique d’attaque : il décode une longue chaîne en base64 et la transmet à zsh. Le processus se détache ensuite de Script Editor, ce qui rend la filiation des processus moins évidente dans une supervision limitée à l’arbre parent-enfant immédiat.

Ce détail change le message de sensibilisation. Il ne suffit pas de dire « ne désactivez pas l’antivirus ». Une procédure qui demande d’ouvrir Script Editor, d’exécuter un script ou de retirer un attribut de quarantaine n’est pas une installation normale pour un logiciel métier. L’entreprise doit fournir un canal simple pour demander une application absente du catalogue, faute de quoi l’utilisateur cherchera une solution ailleurs.

Les premières variantes de PamStealer embarquaient dans leur code des éléments permettant de retrouver la charge utile. Cette version télécharge à la place un petit outil dédié, pkgunpack, puis réalise un échange de clés avec le serveur. Une paire éphémère est produite à chaque exécution ; le serveur conserve la clé privée nécessaire pour récupérer la clé de chiffrement du paquet.

Une copie du fichier chiffré ne suffit donc pas à reconstituer le second étage lorsque l’infrastructure ne répond plus. Cette architecture ne rend pas la menace invisible : les téléchargements, les processus, les écritures sur disque, la création du LaunchAgent et l’exfiltration restent observables. Elle réduit en revanche la valeur d’une analyse qui s’arrête au hash ou au contenu statique du premier fichier.

Pour une équipe IT, la conséquence est concrète : la conservation des événements compte autant que la conservation du fichier. La chronologie Script Editor → sh → zsh → curl, le retrait de l’attribut de quarantaine, l’application d’une signature ad hoc et les appels à launchctl racontent une histoire qu’un échantillon isolé peut ne plus révéler quelques heures plus tard.

Le second étage est écrit en Swift et fonctionne sur les Mac Intel comme sur les Mac Apple silicon. Il affiche une fenêtre qui imite une demande macOS autorisant des modifications, puis un message affirmant que l’application est endommagée. Le mot de passe saisi n’est pas seulement collecté : PamStealer le valide au moyen de PAM, le système d’authentification modulaire utilisé par macOS.

Cette validation immédiate permet à l’attaquant de savoir si le secret est correct. Le programme tente ensuite d’accéder au trousseau de session et copie sa base de données. Il sauvegarde aussi les bases de navigateurs au moyen des fonctions de sauvegarde SQLite, plutôt que de les copier brutalement pendant leur utilisation. Jamf indique dix-sept cibles navigateur et décrit également la collecte d’extensions, de portefeuilles et de fichiers utilisateur.

Le risque ne se limite donc pas au compte local du Mac. Des cookies de session, mots de passe enregistrés, extensions de portefeuille ou documents synchronisés peuvent ouvrir d’autres accès. Après une suspicion crédible, changer uniquement le mot de passe macOS sur la machine concernée est insuffisant : il faut considérer les identités cloud et les sessions navigateur comme potentiellement exposées.

Un LaunchAgent nommé comme un composant système relance le binaire à l’ouverture de session et toutes les quinze secondes. Ce mécanisme est déjà préoccupant, mais la nouveauté opérationnelle réside dans les couches qui le réparent :

Supprimer un seul fichier .plist n’assainit donc pas nécessairement le poste. Une commande Git ou l’ouverture d’un terminal peut rétablir ce qui vient d’être retiré. L’existence d’une sauvegarde locale permet en outre la réparation sans nouveau téléchargement réseau.

Pour les équipes de développement, le détournement de core.hooksPath mérite une attention particulière. Une configuration Git globale modifiée n’est pas un simple indicateur lié au code source : elle devient ici un déclencheur de persistance sur chaque dépôt utilisé par la personne compromise.

Avant d’enregistrer son LaunchAgent, le dropper suspend les processus macOS liés à la gestion et à l’affichage des éléments en arrière-plan, puis les termine. Jamf précise que cette technique n’était pas présente dans les variantes antérieures. L’objectif est clair : éviter que l’ajout du nouvel élément attire l’attention de l’utilisateur au moment le plus critique.

Apple documente pourtant plusieurs moyens d’inventorier ces éléments sur un parc géré. À partir de macOS 14, le rapport d’état déclaratif des tâches en arrière-plan peut compléter la vue locale disponible dans Réglages Système. La commande sfltool dumpbtm fournit aussi un état utile lors d’une investigation. Ces mécanismes ne prouvent pas à eux seuls qu’un élément est malveillant, mais ils permettent de comparer la situation observée avec la liste des composants réellement approuvés.

La règle à retenir est simple : une notification utilisateur constitue un signal utile, pas une preuve d’intégrité. L’absence d’alerte ne signifie pas qu’aucune persistance n’a été ajoutée. La preuve doit venir de l’inventaire et de la télémétrie centralisée.

Gatekeeper, la notarisation et XProtect forment plusieurs couches complémentaires. Apple peut bloquer un logiciel connu, révoquer un certificat ou diffuser une nouvelle règle XProtect indépendamment d’une mise à jour complète de macOS. Ces protections restent indispensables, mais Apple rappelle que la notarisation porte sur les menaces connues au moment du contrôle.

Le MDM réduit d’abord l’exposition. Il peut imposer les réglages Gatekeeper adaptés, empêcher certains contournements, distribuer les applications approuvées et remonter l’état des éléments en arrière-plan. Il rend surtout le bon chemin plus simple : un catalogue interne et une procédure de demande évitent qu’un collaborateur cherche un wallet, un utilitaire ou un outil de développement sur un site inconnu.

L’EDR apporte la chronologie et le contexte. Les signaux les plus intéressants ne sont pas uniquement un domaine ou un hash, qui peuvent changer :

La combinaison de ces événements est plus robuste qu’une règle isolée. Elle permet aussi de rechercher d’autres Mac présentant le même comportement, y compris après la disparition de l’infrastructure observée par Jamf.

La réponse exacte dépend de la criticité du poste et des données accessibles. L’objectif n’est pas d’appliquer mécaniquement une liste d’indicateurs, mais de traiter l’incident comme une possible compromission d’identité et de session, pas comme un simple fichier indésirable.

Notre article sur le faux installateur Zoom et le RAT Overlord montrait déjà pourquoi l’antivirus seul ne suffit pas : une application attendue peut servir de leurre et un nouvel échantillon peut échapper temporairement aux signatures. PamStealer apporte trois enseignements supplémentaires.

D’abord, l’analyse statique peut être volontairement limitée par une infrastructure qui ne remet la clé qu’au moment de l’exécution. Ensuite, une alerte macOS peut être ciblée directement par la chaîne d’installation. Enfin, la persistance peut se réparer grâce à des actions banales de l’utilisateur, comme ouvrir un terminal ou effectuer un commit Git.

La défense doit donc relier la gestion du cycle de vie des applications Mac, le contrôle des installations, la télémétrie endpoint et une procédure de réponse qui couvre aussi les identités. C’est cette continuité, davantage qu’un produit isolé, qui réduit le délai entre le premier doute et la maîtrise de l’incident.

Une politique utile rend l’installation approuvée plus simple que l’improvisation : catalogue clair, demandes rapides, droits locaux adaptés et canal de signalement sans blâme. Elle conserve aussi assez de télémétrie pour reconstruire une attaque dont la charge utile n’est plus disponible.

BoucheCousue accompagne les entreprises dans la gestion et la sécurisation des flottes Apple avec Jamf, la distribution des applications et la mise en place d’une protection endpoint adaptée. Un audit peut commencer par l’inventaire des installations hors catalogue, des éléments en arrière-plan et des données réellement visibles par l’EDR.