La plupart des articles sur les rançongiciels Mac commencent soit par balayer le sujet (« les Mac n’attrapent pas de rançongiciel »), soit par le gonfler (« les attaques explosent »). Aucune des deux positions n’est honnête. L’historique documenté est court, précis et mérite d’être lu de près, parce qu’il dit exactement à quoi sert chaque couche d’une défense. Cet article parcourt cet historique, puis les couches, et dit explicitement laquelle un pare-feu couvre et lesquelles il ne couvre pas.
Ce qui s’est réellement passé sur macOS
KeRanger, mars 2016. L’Unit 42 de Palo Alto Networks rapportait le 6 mars 2016 qu’un installeur compromis du client BitTorrent Transmission, téléchargé depuis le site officiel du projet, embarquait le premier rançongiciel pleinement fonctionnel pour OS X. Il était signé avec un certificat développeur valide, ce qui lui permettait de passer Gatekeeper. Son comportement est ce qu’il faut retenir : selon l’Unit 42, il attendait trois jours, se connectait ensuite à ses serveurs de commande et de contrôle via le réseau Tor, et ne commençait à chiffrer les fichiers qu’après. Apple a révoqué le certificat et mis à jour XProtect en quelques jours.
ThiefQuest, aussi appelé EvilQuest, juin 2020. L’Objective-See de Patrick Wardle publiait sa première analyse le 29 juin 2020, décrivant un échantillon diffusé par des installeurs piégés de logiciels piratés et persistant via des agents et démons de lancement. ThreatDown (alors Malwarebytes) précisait le lendemain que ces installeurs piratés incluaient Little Snitch et Mixed In Key. Le chiffrement était presque accessoire : l’échantillon embarquait aussi un enregistreur de frappe et ouvrait un shell inversé vers un serveur de commande et de contrôle, ce qui a poussé les chercheurs à le rebaptiser. C’était un voleur de données déguisé en rançongiciel.
LockBit, avril 2023. BleepingComputer rapportait le 16 avril 2023 la découverte de chiffreurs compilés pour macOS au nom de LockBit, l’une des plus grosses opérations de rançongiciel à la demande de l’époque. Les chercheurs qui ont examiné ces versions ont conclu qu’il s’agissait très probablement de builds de test, avec des références à des systèmes incompatibles et des pans de fonctionnalités propres à macOS manquants, et qu’elles n’étaient pas prêtes pour de vraies attaques. L’affaire compte moins pour ce que le build faisait que pour ce qu’elle signalait : une grande organisation criminelle avait décidé que le Mac valait un budget d’ingénierie.
Trois cas en sept ans, ce n’est pas une épidémie. Mais chacun est entré par une voie qui existe toujours aujourd’hui : un téléchargement de confiance discrètement remplacé, un logiciel piraté, et une chaîne criminelle industrialisée. Une défense en couches se construit autour de ces voies, pas autour d’un chiffre à la une.
Couche un : empêcher le code non fiable de s’exécuter
La documentation de sécurité des plateformes Apple décrit la protection de macOS contre les programmes hostiles en trois étapes : empêcher leur lancement (l’App Store, Gatekeeper et la notarisation), les empêcher de s’exécuter (les mêmes outils plus XProtect), et remédier après exécution (XProtect encore). C’est la couche qui a arrêté KeRanger en quelques jours une fois le certificat révoqué par Apple. C’est aussi la couche que le logiciel piraté existe pour contourner : chaque victime de ThiefQuest avait délibérément passé outre Gatekeeper pour installer une application crackée. Le contrôle anti-rançongiciel le plus efficace sur un Mac n’est donc pas un produit. C’est une règle de conduite : rien de cracké, rien venant d’un torrent, et pas de « clic droit, Ouvrir » pour forcer un avertissement Gatekeeper à moins de savoir exactement pourquoi il est apparu.
Couche deux : surveiller le réseau, parce qu’un rançongiciel parle
Le chiffrement est la dernière étape, pas la première. MITRE ATT&CK le classe sous « Data Encrypted for Impact » (T1486), une technique de la phase d’impact, et les phases précédentes passent par le réseau. Un échantillon récupère une clé ou des instructions auprès d’un serveur de commande et de contrôle ; il peut exfiltrer des fichiers avant de les chiffrer pour que la rançon menace aussi d’une publication, ce qu’ATT&CK recense comme « Exfiltration Over C2 Channel » (T1041) ; ThiefQuest faisait même tourner un shell inversé. KeRanger est resté silencieux trois jours avant d’établir sa première connexion sortante via Tor. Cette première connexion est ce qu’un pare-feu par application est placé pour voir.
C’est là que FireAI intervient, et son rôle est étroit mais réel. FireAI ne détecte pas le chiffrement. Il ne surveille pas les modifications de fichiers, n’analyse ni les processus ni la mémoire, et ne peut rien déchiffrer. Ce qu’il fait, c’est traiter chaque connexion sortante comme une décision. Un binaire qui ne s’est jamais connecté déclenche une demande d’autorisation, avec la raison donnée par le modèle embarqué ; ce même modèle peut de lui-même bloquer ou signaler une connexion d’une app inconnue vers une destination suspecte. Les flux de renseignement sur les menaces que FireAI applique en local incluent la liste des nœuds de sortie Tor, abuse.ch, Spamhaus, FireHOL et des listes d’hameçonnage, si bien qu’une première connexion vers une infrastructure criminelle connue est bloquée par règle plutôt que par jugement. Et si vous soupçonnez que quelque chose tourne, le coupe-circuit coupe l’accès à internet tout en conservant le réseau local, ce qui rompt le lien de commande et de contrôle sans débrancher une machine dont vous pourriez avoir besoin pour l’analyse.
Soyons clairs sur les cas d’échec. Un échantillon qui chiffre sans jamais se connecter, avec une clé embarquée dans son propre code, est invisible pour un pare-feu. Un échantillon qui passe par une application déjà autorisée, un navigateur par exemple, pour joindre son serveur se fond dans le trafic permis. Un pare-feu réduit les chances que l’attaque soit silencieuse et complète ; il ne rend pas le chiffrement impossible.
Couche trois : des sauvegardes hors de portée de l’attaquant
Qu’un chiffrement soit un mauvais après-midi ou une semaine fatale pour l’entreprise se décide entièrement à cette couche. Le guide #StopRansomware de la CISA la place en tête de ses mesures de préparation : conserver des sauvegardes hors ligne et chiffrées des données critiques, les tester régulièrement, et envisager un stockage immuable qui protège les données sans exiger un environnement séparé. Le mot qui fait tout le travail, c’est hors ligne. Un disque Time Machine branché en permanence est un volume monté, et un volume monté est une cible ; un dossier de synchronisation cloud n’est pas une sauvegarde du tout s’il réplique fidèlement les versions chiffrées de vos fichiers par-dessus les originaux.
Sur un Mac, la version pratique est simple. Le guide d’Apple sur Time Machine couvre la mise en place de sauvegardes automatiques vers un disque externe ou un volume réseau pris en charge. Faites tourner deux disques et gardez-en un débranché, ou au minimum éjectez le disque entre deux sauvegardes. Conservez une seconde copie quelque part où les fichiers sont versionnés plutôt que répliqués, pour que la version saine d’hier survive à l’écrasement d’aujourd’hui. Puis testez la restauration d’un vrai fichier, depuis le disque débranché, pour savoir que la procédure fonctionne avant d’en avoir besoin sous pression. FireAI n’a aucun rôle dans cette couche, et il faut le dire : aucun pare-feu ne sauvegarde quoi que ce soit.
Couche quatre : limiter ce qu’un seul Mac peut atteindre
En entreprise, un rançongiciel fait l’essentiel de ses dégâts sur le stockage partagé, et un Mac avec un partage monté peut chiffrer tout ce sur quoi il a le droit d’écrire. N’accordez aux personnes l’écriture que sur les partages qu’elles utilisent vraiment, et donnez aux comptes de service leurs propres identifiants pour qu’une seule connexion compromise n’ouvre pas tout le serveur de fichiers. Sur le Mac lui-même, les règles par application de FireAI vous laissent décider quelles applications peuvent joindre votre NAS, vos serveurs de stockage cloud ou tout simplement votre réseau de bureau : un binaire inconnu qui tente d’atteindre le serveur de fichiers sur le port 445 doit franchir une règle qu’on ne lui a jamais accordée. Les modes de sécurité les plus stricts, Paranoïaque et Sous attaque, vont plus loin et refusent purement et simplement l’accès réseau aux apps non signées.
Si cela arrive malgré tout
- Déconnectez d’abord le Mac du réseau. Le coupe-circuit de FireAI le fait en gardant le réseau local disponible ; débrancher le câble le fait plus radicalement.
- Ne payez pas avant d’avoir vérifié vos sauvegardes. Le guide de la CISA détaille l’isolement, le tri et le signalement avant toute décision concernant une rançon.
- Préservez la machine. L’effacer détruit les preuves qui disent comment l’échantillon est entré et ce qu’il a envoyé.
- Signalez. En France, Cybermalveillance.gouv.fr et un dépôt de plainte ; aux États-Unis, la CISA ou le FBI ; ailleurs, votre CERT national.
- Restaurez depuis la copie hors ligne sur une installation propre, pas sur le système compromis.
Ce que « défense complète » veut honnêtement dire
Aucun outil isolé n’est une défense contre les rançongiciels, et tout éditeur qui prétend le contraire vend une couche pour quatre. Gatekeeper et votre propre discipline de téléchargement empêchent la plupart du code hostile de s’exécuter. Un pare-feu par application oblige le code qui s’exécute malgré tout à demander avant de parler, et bloque les destinations déjà connues comme criminelles. Les sauvegardes hors ligne rendent le chiffrement survivable. Le moindre privilège sur les partages empêche qu’un seul Mac défaillant devienne un incident pour tout le bureau. Les couches se recouvrent à dessein, parce que chacune a un trou que les autres comblent. Voilà à quoi ressemble une défense qui tient : pas impénétrable, mais construite pour qu’aucune défaillance isolée ne soit fatale.
Le rôle de FireAI et de HisnLabs
Les deux familles de rançongiciels Mac les mieux documentées, KeRanger et ThiefQuest, ont toutes deux parlé à un serveur avant ou pendant le chiffrement — et guetter cette conversation, venant d’un binaire qui ne s’est jamais connecté auparavant, est la seule part de la défense qu’un pare-feu par application comme FireAI peut honnêtement revendiquer.
FireAI est le produit de HisnLabs : un pare-feu IA embarqué pour Mac. Il montre en langage clair chaque connexion faite par vos applications et vous laisse décider ce qui sort de votre Mac — son IA fonctionne en local, votre trafic ne nous est jamais envoyé, ni à personne d’autre. L’équipe de recherche en sécurité de HisnLabs est celle qui garde ces décisions fiables : elle recense les domaines de simple télémétrie face à ceux d’un vrai service, suit le pays et le réseau derrière une connexion, et entraîne le modèle embarqué (la fonction Autopilot) sur du trafic réel, sans que rien ne quitte votre Mac.
Vous pouvez lire les choix techniques qui s’y trouvent, ou essayer FireAI pendant 17 jours, sur FireAI, par HisnLabs.