Fake Maccy Stealer

Maccy est un gestionnaire de presse-papiers open source très utilisé, distribué depuis maccy.app et GitHub, développé et signé par Alexey Rodionov (Team Identifier MN3X4648SC). L'attaquant a enregistré maccyapp[.]com comme domaine quasi identique et l'a optimisé afin qu'il apparaisse dans les résultats de recherche à côté de la fiche du projet légitime. Le domaine malveillant prétend distribuer Maccy version 2.7.3, un numéro de version auquel ne correspond aucune balise GitHub dans le référentiel authentique.

La charge utile est fournie sous la forme maccy.dmg. Le projet Maccy officiel n'a jamais distribué de DMG ; toutes les versions légitimes sont publiées sous forme de Maccy.app.zip sur GitHub. Cette différence de format constitue le premier signal détectable. Le SHA-256 de l'image disque malveillante (45bd0e321aa85b63b5dee4e87465e4088546eea5da6efb9c96847023384c48c9) ne correspond au hachage d'aucune version légitime de Maccy. Les binaires Maccy authentiques sont signés avec un Apple Developer ID, notariés avec ticket incorporé et validés par Gatekeeper sans avertissement. La charge utile malveillante est signée ad hoc, sans Team Identifier, et est explicitement rejetée par spctl --assess.

Le choix du leurre est délibéré. Les gestionnaires de presse-papiers sont utilisés de manière disproportionnée par les développeurs, les administrateurs IT et les professionnels de la sécurité, qui copient et collent régulièrement des données sensibles : jetons d'API, clés SSH, phrases de récupération, mots de passe temporaires et codes 2FA. Sur un tel hôte, le presse-papiers forme un cache structuré de secrets récemment utilisés. La campagne vise à compromettre l'outil auquel ses cibles confient précisément ces données.

Lorsque la victime monte le DMG, un fichier JXA .scpt compilé s'ouvre automatiquement dans l'Éditeur de scripts de macOS. La partie visible du script contient un bloc de configuration court et plausible, faisant référence à l'URL officielle de Maccy dans l'Apple App Store, ainsi que des instructions demandant d'appuyer sur ⌘ + R ou de cliquer sur le bouton Exécuter. L'URL de l'App Store constitue un signal de confiance délibéré, mais ne joue aucun rôle fonctionnel. La véritable charge utile est une routine JXA fortement obscurcie, masquée sous la fenêtre visible de l'éditeur par un remplissage d'espaces.

Pourquoi l'Éditeur de scripts contourne les protections macOS : il s'agit d'une application Apple propriétaire bénéficiant de la confiance totale du système. Les protections contre le collage dans Terminal de macOS Tahoe 26.4 ciblent la surface d'attaque précise où les victimes sont invitées à coller des commandes dans Terminal. Ces contrôles n'ont aucun effet sur du code exécuté en cliquant sur Exécuter dans l'Éditeur de scripts. macOS affiche bien un avertissement « développeur non identifié » lorsque le script s'exécute, mais il s'agit de la même invite que les utilisateurs ont été conditionnés à ignorer pendant des années, et le leurre est conçu pour les amener à faire exactement cela.

L'obscurcissement du script JXA repose sur trois techniques superposées. Inversion des chaînes : les constantes sont stockées à l'envers et assemblées à l'exécution. Arithmétique XOR sur les codes de caractères : chaque caractère est dérivé d'opérations arithmétiques appliquées à des nombres entiers. Constructeurs Function() encodés en URI : l'instruction Function('return decodeURIComponent(\'%69%6d%70%6f%72%74\')')() produit 'import' à l'exécution. Le résultat est un dropper dont le texte source ne contient aucune URL C2 ni aucun chemin de fichier lisible.

Le script JXA importe trois frameworks macOS via le pont Objective-C : Cocoa (interface utilisateur, NSWorkspace, NSFileManager), IOKit (énumération du matériel) et CoreFoundation (requêtes de fuseau horaire et de paramètres régionaux). Ces imports servent de base aux quatre contrôles de géorestriction exécutés avant le téléchargement de toute charge utile.

Avant de télécharger ou d'installer quoi que ce soit, le dropper JXA exécute quatre contrôles indépendants afin d'interrompre l'exécution sur les machines associées à la Russie ou à dix autres pays alignés sur la CEI. Ce modèle est cohérent avec le comportement d'opérateurs MaaS russophones cherchant à éviter de créer des victimes susceptibles de déposer une plainte dans leur propre pays, une pratique documentée dans plusieurs familles d'infostealers macOS actives dans le même écosystème.

• Contrôle du fuseau horaire :NSTimeZone.localTimeZone.name comparé à 12 identifiants CEI, notamment Europe/Moscow, Asia/Almaty, Europe/Minsk et des zones apparentées.
• Contrôle du code pays :CFLocaleCopyPreferredLanguages comparé à l'expression régulière RU|BY|KZ|AM|AZ|KG|MD|TJ|UZ|TM|GE.
• Contrôle de la source de saisie du clavier :TISCreateInputSourceList énuméré par rapport à une liste d'identifiants de langue de clavier de la CEI.
• Contrôle de l'architecture :sysctlbyname("hw.optional.arm64") indique ARM64 ou x86_64 au C2, ce qui permet au serveur de fournir le binaire approprié. Ce contrôle confirme que le ciblage principal porte sur Apple Silicon.

L'URL C2 est stockée dans le script JXA sous forme de blob chiffré avec RC4, distinct du chiffrement ChaCha20-Poly1305 utilisé dans le binaire Rust. La clé de déchiffrement RC4 est dérivée des résultats des quatre contrôles de géorestriction concaténés dans une empreinte système de 32 octets. De ce fait, l'URL C2 se déchiffre en une valeur différente sur chaque machine ; un chercheur qui extrait le blob chiffré du code source du script ne peut pas récupérer l'URL sans exécuter les contrôles sur un hôte admissible. L'extraction statique de l'URL C2 à partir du seul script du dropper est impossible.

Une fois les contrôles de géorestriction validés, le dropper JXA télécharge le binaire Rust depuis l'URL C2 déchiffrée au moyen de NSURLSession et construit sur le disque la structure suivante :

~/Library/Application Support/com.apple.finder.monitor/
<!-- mimic Apple reverse-DNS naming convention -->
└── Finder.app/
    ├── Contents/
    │   ├── Info.plist          (LSUIElement=true · LSBackgroundOnly=true)
    │   ├── MacOS/
    │   │   └── F8C06C86        (944,464 bytes — Rust ARM64 infostealer)
    │   └── Resources/
    │       └── AppIcon.icns    (copied from /System/Library/CoreServices/Finder.app)
    ├── .config                 (34 bytes — C2 URL plaintext: https://avengerflow.com/api/sync)
    ├── .lock                   (0 bytes — single-instance mutex)
    └── .Maccy                  (0 bytes — clipboard monitoring marker)

Trois aspects de cette structure sont spécifiquement conçus pour éviter la détection. Le nom de répertoire com.apple.finder.monitor imite la convention DNS inversée utilisée par Apple pour ses propres services en arrière-plan. Le paquet s'appelle Finder.app et utilise une copie de l'icône authentique d'Apple Finder récupérée dans le chemin système, ce qui crée dans le Moniteur d'activité un second processus visuellement identique au véritable Finder. Le nom de l'exécutable qu'il contient se compose de huit caractères hexadécimaux dérivés de l'hôte et semble varier à chaque installation, empêchant le partage des IOC de hachage binaire au niveau du nom de fichier.

Le Info.plist définit LSUIElement=true (aucune icône dans le Dock) et LSBackgroundOnly=true (aucune interface), de sorte que le processus s'exécute de manière entièrement invisible. Après avoir écrit le paquet, le dropper auto-signe le binaire au moyen de codesign -fs - --deep (signature ad hoc), ce qui entraîne un rejet par Gatekeeper lors d'une évaluation avec spctl --assess. Cependant, le binaire a déjà été autorisé lorsque l'utilisateur a approuvé le script dans l'Éditeur de scripts ; Gatekeeper ne le réévalue donc pas à ce stade.

La persistance est enregistrée simultanément au moyen de deux API : l'ancienne LSSharedFileList (LSSharedFileListInsertItemURL sur kLSSharedFileListSessionLoginItems) et la nouvelle SMAppService de ServiceManagement.framework. L'élément d'ouverture obtenu apparaît dans Réglages Système → Général → Ouverture sous le nom « Finder », avec l'icône authentique d'Apple Finder. La base de données Background Task Manager (BTM) l'enregistre sous 2.com.apple.finder.monitor avec l'état [enabled, allowed, visible, notified].

Le choix d'utiliser les éléments d'ouverture plutôt que LaunchAgents ou LaunchDaemons est important sur le plan opérationnel. La couverture de détection de ~/Library/LaunchAgents/*.plist et /Library/LaunchDaemons/*.plist est bien établie dans les outils de sécurité macOS. La persistance via LSSharedFileList et SMAppService bénéficie d'une surveillance nettement moindre, et l'entrée de la base de données BTM n'est pas examinée par défaut dans la plupart des inventaires d'outils de sécurité.

Le binaire Rust s'exécute silencieusement, toutes les entrées et sorties étant redirigées vers /dev/null. Il fonctionne entièrement dans le contexte de la session utilisateur et ne tente aucune élévation de privilèges. Les données auxquelles il peut accéder dans ce contexte sont néanmoins nombreuses.

Identifiants du Trousseau : le binaire appelle SecItemCopyMatching avec kSecClassGenericPassword, kSecAttrService, kSecReturnData et kSecReturnAttributes. Cette chaîne d'API extrait les entrées de mots de passe génériques du trousseau de session, notamment les mots de passe Wi-Fi et applicatifs ainsi que les identifiants stockés par les gestionnaires de mots de passe et les navigateurs utilisant le Trousseau comme backend.

Identifiants des navigateurs : un accès SQLite direct via libsqlite3.dylib cible les bases Login Data et Cookies de Chrome, les fichiers logins.json et key4.db de Firefox ainsi que les éléments du Trousseau Safari. Les cookies de session sont capturés en conservant leurs indicateurs de sécurité, ce qui permet le détournement de session sans devoir casser un second facteur d'authentification.

Contenu du presse-papiers :NSPasteboard.generalPasteboard capture tout ce que l'utilisateur copie pendant l'exécution du processus. Il s'agit précisément des données qu'un utilisateur de gestionnaire de presse-papiers s'attend à retrouver : mots de passe, jetons, phrases de récupération et codes de récupération copiés dans le cadre du travail habituel.

Interception PAM : le binaire est lié à libpam.2.dylib, la bibliothèque Pluggable Authentication Module. Il peut ainsi intercepter des événements d'authentification système et éventuellement capturer les mots de passe saisis dans des invites sudo ou des boîtes de dialogue de sécurité du système après l'installation.

Les données collectées sont chiffrées avec ChaCha20-Poly1305, variante IETF conforme à la RFC 8439. La présence de la chaîne expand 32-byte k dans les chaînes du binaire confirme la constante sigma de ChaCha20 issue du crate Rust chacha20poly1305. Chaque blob chiffré présente la structure suivante : [version : 1 octet = 0x02] [nonce : 12 octets] [texte chiffré : N octets] [balise Poly1305 : 16 octets]. Le corps de la balise utilise le format MacOSapp1{"data":"<blob chiffré>"}, confirmé dans la propre base de données cache SQLite du logiciel malveillant, qui a enregistré un contact C2 le 2026-06-26 07:38:02 UTC avec https://avengerflow.com/api/sync.

Le canal C2 est bidirectionnel. Une réponse C2 capturée contenant un blob chiffré confirme que le serveur renvoie des commandes à l'implant. Un hôte compromis doit être traité comme un implant actif, et non comme une fuite ponctuelle d'identifiants. Tous les identifiants doivent être considérés comme exposés et renouvelés, et toutes les sessions actives doivent être invalidées.