Infostealers macOS 2026 : règles YARA pour CrashStealer, PamStealer et les DMG ClickFix

Depuis la fin 2025, Microsoft et Jamf documentent tous les deux la même tendance : les infostealers ciblant macOS ne sont plus un phénomène marginal. Familles comme CrashStealer ou PamStealer, diffusion par faux DMG, chaîne d'infection ClickFix (l'utilisateur copie-colle lui-même une commande dans le Terminal après une fausse alerte de vérification). Le mode opératoire change, mais le point aveugle reste le même dans la plupart des SOC : les règles de détection, les playbooks et les habitudes d'analyse restent massivement pensés pour Windows. Un parc Mac en BYOD, de plus en plus fréquent dans les PME, traverse ce filtre sans y être vu.

Cet article détaille une méthode de détection statique par YARA sur ces menaces, en partant des artefacts réels documentés par les chercheurs, pas d'un simple copier-coller de règle trouvée en ligne.

Le point de départ : le fait, pas la règle recopiée

Avant d'écrire la moindre signature, il faut distinguer deux sources très différentes. D'un côté, les rapports d'incident et advisories publics (Jamf Threat Labs, Microsoft Defender for Endpoint, ou les analyses indépendantes publiées sous licence ouverte) décrivent un comportement observé : tel binaire Mach-O contient telle chaîne, tel script bash décode tel payload en base64. Ce fait technique n'appartient à personne. De l'autre, une règle YARA trouvée sur un dépôt GitHub sans licence explicite est protégée par défaut, la reprendre telle quelle dans un pack commercialisé est un problème de droit, pas seulement une question de qualité.

La bonne pratique est donc de reconstruire la signature à partir du comportement décrit, puis de la valider soi-même sur un échantillon réel ou une reproduction fidèle en laboratoire. C'est ce qui distingue une règle qui tient dans le temps d'une règle qui casse au premier changement mineur de la charge utile.

Les scripts bash obfusqués dans les DMG

Le vecteur d'entrée classique de CrashStealer et de variantes proches est un DMG qui embarque un script shell, souvent encodé en base64 pour échapper aux scans superficiels et compliquer la lecture manuelle. Décodé, ce script lance osascript pour afficher une fenêtre système crédible, puis un appel curl vers l'infrastructure de commande et contrôle pour récupérer la charge finale.

Une règle statique efficace cible la structure de l'obfuscation elle-même plutôt que le contenu exact du payload, qui change à chaque campagne :

rule MacOS_DMG_Base64_OsaScript_Curl_Chain
{
    meta:
        description = "Script shell embarqué dans un DMG : décodage base64 vers osascript puis appel C2"
        family = "generic-macos-dropper"
        confidence = "medium"
 
    strings:
        $b64_marker = /echo\s+[A-Za-z0-9+\/=]{80,}\s*\|\s*base64\s+(-D|--decode)/
        $osascript  = "osascript" ascii
        $curl_out   = /curl\s+(-s|--silent)?\s*-o\s+/
        $curl_pipe  = "curl" ascii nocase
 
    condition:
        filesize < 2MB and
        $b64_marker and
        $osascript and
        1 of ($curl_out, $curl_pipe)
}

Le point clé est la condition combinée : la présence isolée d'osascript ou de curl ne veut rien dire (des milliers d'installeurs légitimes les utilisent), c'est la conjonction du décodage base64 suivi d'un appel réseau qui devient un signal.

Détecter l'accès direct au Keychain hors process Apple

Le cœur de la charge utile d'un infostealer macOS reste l'exfiltration des identifiants stockés dans le Keychain. Un outil légitime passe par les frameworks Apple (Security.framework) avec les entitlements adéquats. Un binaire malveillant, lui, invoque fréquemment directement la commande security find-generic-password en sous-processus, ou lit brutalement les fichiers sous ~/Library/Keychains/ sans passer par l'API prévue.

rule MacOS_Unsigned_Keychain_Direct_Access
{
    meta:
        description = "Accès direct au Keychain (CLI ou chemin fichier) dans un binaire Mach-O non signé Apple"
        family = "generic-macos-stealer"
        confidence = "high"
 
    strings:
        $sec_cmd    = "security find-generic-password" ascii
        $sec_cmd2   = "security find-internet-password" ascii
        $kc_path    = "/Library/Keychains/" ascii
        $kc_path2   = "login.keychain-db" ascii
 
    condition:
        uint32(0) == 0xFEEDFACF and
        2 of ($sec_cmd, $sec_cmd2, $kc_path, $kc_path2)
}

Le seuil 2 of (au moins deux indicateurs sur quatre) évite de déclencher sur un simple mention isolée dans un fichier de log ou de documentation embarquée, tout en restant sensible à la combinaison typique commande plus chemin.

Repérer les prompts ClickFix

La chaîne ClickFix est devenue le vecteur social dominant sur macOS en 2026 : une fausse page ou fenêtre invite l'utilisateur à « vérifier qu'il n'est pas un robot » en copiant une commande, puis à la coller dans le Terminal. Le binaire ou script qui orchestre cette fenêtre via osascript utilise des dialogues système (display dialog, display alert) avec un texte imitant une vérification de sécurité.

rule MacOS_ClickFix_Fake_Verification_Prompt
{
    meta:
        description = "Prompt osascript imitant une fenêtre de vérification (schéma ClickFix)"
        family = "clickfix-macos"
        confidence = "medium"
 
    strings:
        $dialog1 = "display dialog" ascii
        $dialog2 = "display alert" ascii
        $lure1   = /verif(y|ication)/ nocase ascii
        $lure2   = "not a robot" nocase ascii
        $lure3   = "captcha" nocase ascii
        $clip    = "pbcopy" ascii
 
    condition:
        1 of ($dialog1, $dialog2) and
        1 of ($lure1, $lure2, $lure3) and
        $clip
}

La présence de pbcopy (le presse-papiers macOS) associée à un dialogue et à un leurre textuel est un triangle rarement légitime : c'est exactement le mécanisme qui prépare la commande que la victime va coller elle-même dans le Terminal.

Anti faux positifs : whitelister par TeamID, pas par nom

Le piège classique d'une détection Keychain trop large est de bloquer les vrais gestionnaires de mots de passe (1Password, Bitwarden, Dashlane) qui accèdent légitimement au Keychain pour l'intégration système. La bonne pratique n'est jamais d'exclure par nom de processus (trivialement usurpable) mais par TeamID de signature développeur Apple, vérifié en amont du scan YARA, pas dans la règle elle-même.

# Vérification de signature avant scan, en amont du moteur YARA
codesign -dv --verbose=4 "$BINARY" 2>&1 | grep -q "TeamIdentifier=2BUA8C4S2C" && echo "1Password vérifié, exclu du scan"

Cette étape de filtrage se fait dans le pipeline d'orchestration, jamais dans la règle YARA elle-même : une règle ne doit jamais porter de logique métier sur des identités de confiance, seulement sur des artefacts techniques.

Le gate moteur : Mach-O magic et budget de performance

Une règle YARA mal bornée peut ralentir un scan complet d'un parc, surtout avec des regex larges appliquées à des binaires volumineux. La bonne pratique est de gater d'abord sur le magic number Mach-O (0xFEEDFACF pour un binaire 64 bits, 0xFEEDFACE pour un 32 bits historique) avant toute analyse de chaînes, et de limiter le scan aux emplacements à risque réel : le dossier Downloads, les fichiers portant l'attribut de quarantaine Gatekeeper (com.apple.quarantine), plutôt qu'un scan aveugle de l'intégralité du disque.

condition:
    uint32(0) == 0xFEEDFACF or uint32(0) == 0xFEEDFACE

Ce gate initial élimine en une comparaison d'entier la quasi-totalité des fichiers non pertinents avant d'engager le coût des chaînes et des conditions composées, un principe de performance qui vaut sur n'importe quel moteur de scan à l'échelle d'un parc.

Indicateurs comportementaux complémentaires

La détection statique par YARA couvre l'artefact au repos, mais deux signaux comportementaux renforcent la confiance sur incident réel : une persistance ajoutée via un fichier LaunchAgent dans ~/Library/LaunchAgents/ créé dans la foulée d'un montage de DMG, et un processus enfant qui apparaît comme spawné directement depuis le point de montage d'un DMG (/Volumes/) plutôt que depuis /Applications. Ces deux éléments, croisés avec une règle statique qui a matché, transforment un simple avertissement en un cas prioritaire.

Mon parc Mac en BYOD est-il couvert ?

C'est la question concrète que se posent la plupart des RSSI dont l'outillage a été bâti pour Windows : oui, à condition que la couverture de détection ne soit pas un sous-produit accidentel d'une stack pensée pour un autre système d'exploitation. Les artefacts Mach-O, les chemins Keychain, les scripts osascript n'ont pas d'équivalent direct côté Windows, une règle générique EDR-Windows ne les verra jamais. Il faut une verticale macOS explicite, testée sur des échantillons réels, avec son propre budget anti-faux-positifs.

En résumé

La détection d'infostealers macOS demande la même rigueur que n'importe quelle autre plateforme : partir du comportement documenté, pas du code recopié, gater sur la structure du binaire avant les chaînes, prouver l'absence de faux positifs sur les outils légitimes qui touchent au Keychain, et compléter le statique par des indicateurs comportementaux de persistance. C'est cette discipline que nous appliquons dans le pack YARA ThreatClaw : des règles macOS validées sur le moteur réel, priorisées sur les familles actives, prêtes à couvrir un parc BYOD que vos outils Windows ne regardent jamais.