Une faille macOS exploitée pour miner du Monero : 2 heures à scanner notre parc, 3 Mac exposés

Lundi 17 août, le centre national de cybersécurité néerlandais signale l’exploitation active d’une vulnérabilité touchant la fonction de partage d’écran d’Apple. Le lendemain matin, nous avons lancé un balayage sur les parcs que nous supervisons. Deux heures plus tard, nous avions trois machines à traiter en urgence — et une conclusion qui n’a rien à voir avec macOS.

Les faits : CVE-2026-65400, exploitation confirmée

La vulnérabilité est référencée CVE-2026-65400 et porte un score CVSS de 7,1. Elle réside dans un problème de gestion d’état du service de partage d’écran de macOS. Un attaquant capable de l’exploiter obtient les privilèges root, soit le niveau d’accès le plus élevé du système.

Les versions concernées sont macOS Tahoe, Sequoia et Sonoma. Apple a publié des mises à jour de sécurité couvrant les trois. La condition d’exploitation est en revanche très spécifique : la fonction de partage d’écran doit être activée, et le port TCP 5900 doit être joignable depuis Internet.

Le NCSC néerlandais a confirmé plusieurs attaques réelles, menées contre des Mac directement accessibles depuis Internet. La charge utile observée après compromission est un logiciel de minage de Monero.

Ce que le balayage de 214 postes a montré

Nous avons vérifié deux choses sur chaque machine supervisée : l’état du service de partage d’écran, et l’accessibilité du port 5900 depuis l’extérieur. Voici la répartition réelle.

Sur les trois machines exposées, aucune trace de compromission n’a été trouvée : pas de processus de minage, pas de connexion sortante anormale, pas de fichier récent suspect dans les emplacements de persistance habituels. Les trois ont tout de même été mises à jour, le partage d’écran désactivé et la règle de redirection de port supprimée sur la passerelle.

Pourquoi un mineur de Monero est un signal, pas un soulagement

La réaction spontanée, quand on découvre que la charge utile est un mineur de cryptomonnaie, est un soulagement : ce n’est « que » du vol de puissance de calcul. Cette lecture est dangereuse pour deux raisons.

Première raison : le minage est un test de rentabilité. Un attaquant qui déploie un mineur sur des machines compromises mesure, très concrètement, la valeur de son accès. Une campagne de minage sur un parc de postes est fréquemment la première phase d’une opération dont la seconde consiste à revendre les accès les plus intéressants à un autre acteur.

Seconde raison : un accès root est un accès root. La charge utile constatée aujourd’hui ne limite en rien ce que l’attaquant pouvait faire. Sur une machine de dirigeant, un accès root donne les sessions authentifiées, les jetons de messagerie, les clés SSH et l’accès aux dossiers synchronisés. Le fait que l’opérateur ait choisi de miner ne dit rien sur ce qu’il a également copié.

La conséquence pratique : une machine compromise par cette faille ne se traite pas en supprimant le processus de minage. Elle se traite comme une compromission complète, avec rotation des identifiants et des clés qui y étaient présents.

Le plan de vérification en 5 points, dans l’ordre

1. Chercher le port avant de chercher la version. Un balayage externe du port 5900 sur vos plages d’adresses publiques donne la liste des machines réellement à risque en quelques minutes. C’est plus rapide et plus utile qu’un inventaire de versions macOS.

2. Vérifier l’état du partage d’écran sur l’ensemble du parc. Via votre outil de gestion de flotte. Le service peut être actif sans que le port soit exposé : ces machines ne sont pas urgentes, mais elles constituent votre file d’attente de la semaine.

3. Appliquer les mises à jour de sécurité Apple pour Tahoe, Sequoia et Sonoma. Sur les machines exposées, en priorité absolue et sans attendre la fenêtre de maintenance.

4. Chercher les traces sur les machines qui étaient exposées. Processus consommant durablement le processeur, connexions sortantes vers des pools de minage, éléments de démarrage récents, comptes locaux créés. En cas de doute, traitez comme une compromission complète.

5. Reprendre la liste de vos règles de redirection de port. C’est l’étape qui a le plus de valeur à long terme et celle que tout le monde saute. Chaque règle doit avoir un propriétaire et une date d’expiration. Nous détaillons cette logique de périmètre dans notre méthode d’audit de périmètre NIS2.

Ce que ça change pour une entreprise française

Trois conclusions opérationnelles, au-delà du correctif lui-même.

Intégrez les Mac au périmètre de supervision, pas seulement à l’inventaire. Un poste présent dans un tableur mais absent de l’outil de gestion de flotte n’est pas supervisé. La question de l’inventaire réel rejoint directement les obligations de recensement des actifs prévues par la directive NIS2 pour les entités concernées.

Donnez une date d’expiration à chaque exception réseau. Aucune règle de redirection de port ne devrait survivre plus de quatre-vingt-dix jours sans revalidation explicite par son demandeur. C’est une mesure gratuite qui aurait supprimé les trois expositions constatées.

Mesurez votre délai réel entre publication et application. Le bon indicateur n’est pas « sommes-nous à jour ? » mais « combien d’heures nous faut-il pour l’être ? ». Le même raisonnement s’applique aux forges et aux chaînes d’intégration continue, un sujet que nos confrères de D-Open documentent régulièrement côté développement, et aux plateformes d’IA internes, couvertes par Plug-Tech.