Archives quotidiennes :

Cybersécurité, Entreprise

DarkMoon automatise le pentest avec des agents IA

DarkMoon veut transformer le pentest ponctuel en contrôle continu, grâce à des agents IA capables de raisonner, exploiter et documenter chaque vulnérabilité dans un environnement maîtrisé.

DarkMoon est une plateforme open source de pentest autonome conçue par Mehdi Boutayeb. Son ambition : automatiser une évaluation de sécurité complète, depuis la reconnaissance jusqu’au rapport final, en exigeant une preuve avant chaque vulnérabilité confirmée. L’architecture sépare le raisonnement du modèle IA de l’exécution des outils offensifs grâce au Model Context Protocol. Plus de 50 agents spécialisés peuvent intervenir sur le web, les API, Active Directory, Kubernetes, le cloud ou l’IoT. Le projet ajoute une Privacy Gateway destinée à masquer localement les informations sensibles avant leur traitement par un modèle externe. Son objectif est de rendre le pentest continu, reproductible et exploitable dans des infrastructures sensibles.

De la toolbox personnelle au pentest autonome

DarkMoon trouve ses racines bien avant l’arrivée des agents IA. Mehdi Boutayeb explique avoir commencé à développer ses propres outils très jeune. « Lorsque j’avais 13 ans, je bricolais déjà un émulateur pour le plaisir de comprendre la machine de l’intérieur, et cette habitude de fabriquer mes propres outils ne m’a jamais quitté. »

Cette logique donnera d’abord naissance à une distribution GNU/Cygwin utilisée comme boîte à outils de développement. En 2023, Boutayeb réoriente le projet vers la sécurité offensive. Toujours basée sur Cygwin, cette nouvelle version accueille plusieurs outils de pentest initialement conçus pour Linux. Les difficultés de compatibilité finissent toutefois par imposer une nouvelle architecture. Le développement migre vers WSL. Ce changement permet d’intégrer davantage d’outils, puis un serveur MCP et une interface TUI destinée au pilotage des agents IA.

« C’est cette évolution, de la toolbox portable au moteur autonome, qui a donné le Darkmoon d’aujourd’hui. Le fil est le même depuis le début : construire les outils que j’aurais voulu avoir, aller au fond de la machine, et les ouvrir. » explique l’auteur à DataSecuritybreach.fr

Cette histoire personnelle rejoint une problématique professionnelle. Mehdi Boutayeb et Aurélien travaillent comme pentesters dans l’entreprise qu’ils dirigent. Boutayeb revendique également une expertise d’architecte cybersécurité auprès de clients tels qu’Airbus. Sur le terrain, il décrit un écart persistant entre les scanners automatisés et les audits humains.

Les premiers, qu’il s’agisse de SAST, d’analyse de dépendances ou de scanners dynamiques, produisent rapidement une quantité importante de signaux. Leur limite tient à l’interprétation de ces résultats. Un outil SAST peut détecter un motif suspect. Un scanner de dépendances peut identifier une CVE dans un composant qui, en pratique, ne sera jamais appelé. La découverte reste alors à qualifier.

Selon Boutayeb, cette accumulation transfère une partie essentielle du travail vers les analystes. Ils doivent hiérarchiser, reproduire, écarter certains résultats et identifier les vulnérabilités réellement exploitables. La fatigue liée aux alertes devient ainsi un problème opérationnel à part entière. À l’autre extrémité se trouve le test d’intrusion humain. Celui-ci sait enchaîner plusieurs faiblesses, explorer un chemin d’attaque et confirmer concrètement qu’une vulnérabilité peut être exploitée.

Son principal défaut est temporel.

Un audit effectué une ou deux fois par an reste une photographie du système à une date donnée. Lorsque le développement avance en continu, l’environnement examiné peut déjà avoir changé lors de la livraison du rapport. « Dans un SI qui livre en continu, un audit ponctuel est structurellement en retard. Bref, un outillage rapide qui fait du bruit, une expertise lente qui fait de la preuve, et rien qui donne les deux au rythme des changements. » confie l’auteur à Data Security breach.

C’est précisément cet espace que DarkMoon cherche à occuper.

L’objectif du projet consiste à automatiser une partie de l’approche offensive sans abandonner la méthodologie du pentester, la collecte de preuves, la traçabilité de l’exécution ni la possibilité de contrôler les résultats. Le choix de l’open source répond également à une contrainte de souveraineté technique. DarkMoon peut fonctionner en local, une caractéristique présentée comme essentielle pour les infrastructures dont les données ne peuvent pas être transmises à un service d’intelligence artificielle distant.

Boutayeb cite notamment les banques, les établissements hospitaliers, les opérateurs d’importance vitale et la défense.

Son raisonnement est simple : ces organisations doivent pouvoir utiliser des capacités de raisonnement automatisé sans exposer leur système d’information à un modèle hébergé à l’extérieur de leur périmètre. Cette volonté explique une partie de l’architecture de DarkMoon. Le modèle chargé de réfléchir ne commande pas directement le système. Un orchestrateur, OpenCode, dialogue avec le LLM, détermine les prochaines étapes et transmet les actions à une couche de contrôle fondée sur le Model Context Protocol.

Le serveur MCP n’expose qu’une liste prédéfinie d’outils et de workflows. Chaque action passe par le serveur MCP. L’exécution intervient dans un conteneur Docker isolé comprenant de nombreux outils de sécurité. Parmi ceux cités figurent Nuclei, sqlmap, BloodHound et NetExec. DarkMoon découvre les ports et services accessibles, identifie les technologies, établit une représentation de la surface d’attaque, puis mobilise les agents adaptés.

Chaque résultat peut modifier la suite de l’évaluation.

Un WordPress identifié pendant la reconnaissance peut provoquer l’intervention d’un agent spécialisé dans les CMS. Une interface GraphQL découverte plus tard peut réorienter une partie des investigations vers un autre agent.

Les méthodologies revendiquées s’appuient notamment sur ISO 27001, NIST SP 800-115 et MITRE ATT&CK.

Le périmètre autorisé est fourni au lancement sous forme de cibles, domaines, applications ou plages IP. L’orchestrateur doit travailler à l’intérieur de cette frontière.

Ajouter une nouvelle capacité nécessite également une intervention explicite. L’outil doit être installé, enregistré dans MCP et rendu accessible à l’orchestration.

Privacy Gateway, preuves et agents spécialisés

Pour Mehdi Boutayeb, qualifier DarkMoon de système autonome ne revient pas à parler d’un scanner traditionnel auquel une interface conversationnelle aurait été ajoutée.

La différence revendiquée tient au raisonnement et surtout à la validation.

Les agents énumèrent une cible, établissent une hypothèse, tentent de l’exploiter et ne valident un résultat qu’après obtention d’une preuve. L’objectif n’est donc pas seulement d’indiquer qu’une faiblesse pourrait exister. DarkMoon cherche à démontrer un chemin d’attaque exploitable.

Cette distinction rejoint le principe employé pour le reporting.

Les simples réponses HTTP 200, les charges réfléchies ou les indicateurs jugés ambigus sont classés « Unconfirmed ». Une vulnérabilité confirmée doit conserver les commandes exécutées, les sorties brutes, les couples requêtes-réponses HTTP et les traces d’exécution correspondantes. Le modèle sert donc à raisonner sur les observations et à planifier les étapes. La validation repose sur ce que les outils ont effectivement observé ou obtenu sur la cible.

Depuis les premières versions décrites du projet, DarkMoon a également intégré un dispositif que Boutayeb présente comme l’une de ses principales différences : la Privacy Gateway. Son rôle est d’empêcher que des valeurs sensibles soient directement transmises au modèle. Avant l’envoi d’informations au LLM, cette passerelle remplace localement les éléments identifiés comme sensibles par des jetons déterministes. Sont concernés les adresses IP internes, noms d’hôtes, identifiants, secrets, chemins ou portions de code.

Le modèle peut donc recevoir des représentations telles que « IP_PRIVATE_001 » ou « HOST_INTERNAL_001 » à la place des données originales.

Le principe consiste à conserver la structure nécessaire au raisonnement sans communiquer les vraies valeurs.

Lorsque l’un des outils doit agir, DarkMoon réinjecte localement les informations réelles au moment de l’exécution. Les résultats sont ensuite de nouveau masqués avant un éventuel passage par le modèle.

Selon l’auteur, une implémentation correcte de ce mécanisme est compatible avec des environnements air-gap et évite de créer un chemin d’exfiltration.

L’utilisation d’un modèle à poids ouverts exécuté sur une infrastructure locale permet d’aller plus loin. Dans cette configuration, raisonnement, données sensibles et actions restent à l’intérieur du même environnement. Cette capacité répond directement aux contraintes réglementaires, contractuelles ou opérationnelles qui peuvent empêcher certaines organisations d’envoyer des informations internes vers un LLM hébergé dans le cloud.

DarkMoon mise également sur la spécialisation des agents.

Boutayeb évoque désormais plus de 50 agents consacrés à différents domaines : web, API, Active Directory, Kubernetes, AWS, Azure, GCP, CI/CD, bases de données, IoT et firmware.

Le point essentiel n’est pas uniquement leur nombre. Ils partagent un contexte commun et peuvent se transmettre une investigation.

C’est cette continuité que le projet cherche à exploiter pour reconstruire des scénarios dépassant une seule technologie.

Un secret retrouvé dans l’historique Git peut, par exemple, permettre d’obtenir un rôle dans le cloud. Une SSRF peut conduire vers un service de métadonnées. Un registre incorrectement configuré peut exposer un jeton. Un appareil IoT compromis peut offrir un accès au réseau interne, puis conduire vers Active Directory.

Pris séparément, chacun de ces éléments peut sembler relever d’un outil ou d’une équipe différente.

Pris ensemble, ils constituent un chemin d’attaque. Cette lecture transversale correspond davantage au fonctionnement réel d’une compromission. L’intérêt d’un système agentique est alors de conserver le contexte et les preuves lorsque l’investigation passe d’une technologie à une autre. Le projet affirme également disposer de plus de 80 outils offensifs, parmi lesquels NetExec, BloodHound et Impacket.

Chaque commande est explicitement exécutée, encadrée et journalisée. La méthodologie employée par chaque agent reste contenue dans un playbook Markdown lisible et modifiable. DarkMoon est proposé sous licence GPLv3, avec une édition Community gratuite et open source. Le projet revendique l’absence de prompts cachés et de mécanisme propriétaire de notation. Cette transparence doit permettre à un utilisateur d’examiner le comportement du système au lieu de déléguer l’évaluation à une boîte noire.

Le reporting suit la même logique.

Une découverte confirmée est accompagnée de la requête utilisée, de la sortie obtenue et de l’accès éventuellement acquis. L’idée est de diminuer le temps consacré à reproduire les vulnérabilités et à trier les faux positifs. Le rapport cherche ainsi à répondre simultanément aux besoins du pentester, qui doit pouvoir rejouer la preuve, et à ceux du RSSI, qui doit décider rapidement d’une correction ou d’une acceptation du risque.

La continuité constitue l’autre volet du projet

DarkMoon peut être intégré à GitHub Actions afin de déclencher une évaluation depuis un pipeline. Le scénario envisagé n’est plus uniquement un pentest trimestriel ou annuel. Une organisation pourrait lancer des contrôles après des changements significatifs.

Boutayeb cite plusieurs cas : des secrets oubliés dans un historique Git, une configuration Infrastructure as Code accordant trop de privilèges, une image de conteneur contenant une porte dérobée ou un runner CI dont les identifiants permettent d’atteindre la production.

L’ambition est de rapprocher le rythme du pentest de celui des changements apportés au système d’information.

Le coût dépend toutefois du modèle choisi.

Selon Boutayeb, un test typique d’application web avec Claude Opus représente environ 10 $ de frais d’API. La conversion en euros ne peut être calculée rigoureusement à partir des seules informations communiquées, puisqu’aucun taux de change n’est fourni.

Les évaluations portant sur Active Directory ou plusieurs machines consomment davantage de ressources, le modèle devant continuer à analyser les nouvelles informations et planifier des chemins d’attaque.

DarkMoon prend en charge OpenAI, Anthropic et OpenRouter. Une utilisation locale est également proposée avec Ollama ou llama.cpp.

Boutayeb estime que Claude offre actuellement un bon compromis concernant le raisonnement, la stabilité de planification et la gestion de longs contextes.

Le comportement des mécanismes de sécurité intégrés aux modèles reste toutefois une variable importante pour les usages offensifs autorisés.

Dans les essais rapportés par le projet, Claude Opus 4.8 a rencontré des limitations pendant une évaluation. Claude Opus 4.6 aurait exécuté la mission jusqu’à son terme sans interruption. Le projet présente donc Opus 4.6 comme un choix plus stable et mentionne le Cyber Verification Program d’Anthropic pour les organisations susceptibles d’y accéder. Les modèles de petite taille situés dans les gammes de paramètres inférieures ne sont pas pris en charge pour ces missions autonomes. Une exécution entièrement locale peut, à l’inverse, éviter les coûts liés aux API. « En résumé, son utilisation peut être entièrement gratuite si vous exécutez tout en local, ou coûter quelques dollars par évaluation si vous souhaitez bénéficier de la qualité de raisonnement supérieure d’un modèle de pointe. Chaque utilisateur choisit son propre équilibre entre coût et performances. » Résume à DataSecuritybreach.fr l’instigateur du projet.

Le fonctionnement concret reste volontairement accessible. DarkMoon s’installe sur l’infrastructure de l’utilisateur, à partir du dépôt Git ou avec Docker Compose. Le système est ensuite dirigé vers une cible autorisée ou vers un laboratoire conçu pour l’entraînement. L’orchestrateur utilise MCP pour coordonner les agents. Chaque spécialiste applique son playbook Markdown. Le LLM assure la planification et le raisonnement, tandis que la Privacy Gateway intervient avant les échanges contenant des valeurs sensibles. Les vraies données sont réinjectées localement uniquement lorsqu’elles deviennent nécessaires à l’outil.

Chaque étape laisse un artefact : commande, résultat brut et éléments de raisonnement. Le rapport final est construit à partir de ces preuves. Pour tester légalement le système, Boutayeb cite OWASP Juice Shop pour les applications web et les API, GOAD (Game of Active Directory) pour les environnements Active Directory et Kubernetes Goat pour les infrastructures conteneurisées.

Il avance également un résultat obtenu sur Juice Shop : DarkMoon aurait identifié 57 vulnérabilités réelles, chacune associée à un exploit fonctionnel.

Reste la question qui dépasse DarkMoon : l’intelligence artificielle donnera-t-elle d’abord l’avantage aux attaquants ou aux défenseurs ? Medhi Boutayeb refuse une réponse définitive. « Honnêtement, je n’ai pas de réponses tranchées. L’IA abaisse le coût de l’offensive, et les attaquants l’utilisent déjà pour le phishing, la reconnaissance ou l’adaptation d’exploits. »

Selon lui, cette évolution impose toutefois une réaction symétrique côté défense. Si les attaquants automatisent certaines tâches, les équipes de sécurité doivent elles aussi pouvoir absorber davantage de volume. L’IA ne constitue pas, à ses yeux, un remplacement de l’opérateur. Elle automatise surtout les tâches répétitives.

Le jugement humain reste nécessaire pour interpréter, hiérarchiser et décider.

Son analyse porte donc davantage sur la méthode que sur la puissance brute du modèle. L’avantage reviendrait à ceux capables de déployer l’IA avec discipline, tout en conservant la possibilité de vérifier chacune de ses conclusions. L’attaquant bénéficie d’une asymétrie : il peut expérimenter rapidement sans processus d’autorisation interne. Le défenseur doit au contraire agir dans un cadre contrôlé, documenté et reproductible. La réponse passe donc par un outillage capable d’absorber le volume tout en fournissant des preuves.

DarkMoon matérialise cette vision : faire travailler des agents à la vitesse de l’automatisation sans leur accorder une confiance aveugle, et conserver derrière chaque conclusion une chaîne technique qu’un humain peut inspecter, reproduire et contester.

Sources

backdoor, Cybersécurité, Espionnage Spy

Les États-Unis bloquent les nouveaux onduleurs étrangers

Washington ferme l’accès aux nouveaux onduleurs étrangers connectés, invoquant un risque de piratage capable d’affecter à distance des infrastructures électriques critiques américaines.

La Federal Communications Commission (FCC) durcit la surveillance des équipements électriques connectés aux États-Unis. Son Public Safety and Homeland Security Bureau a ajouté certains onduleurs électriques produits à l’étranger à la Covered List, ce qui bloque immédiatement les nouvelles autorisations d’équipements concernés. La décision vise les modèles disposant de fonctions de communication, de transmission de données ou de mise à jour distante. Les appareils étrangers déjà titulaires d’une autorisation FCC restent importables, commercialisables et installables. Au cœur du dossier figure une menace cyber précise : la possibilité qu’un acteur étranger exploite la connectivité d’un onduleur pour modifier son fonctionnement, déployer un firmware ou interrompre une production électrique.

Une interdiction centrée sur les nouveaux modèles connectés

La mesure annoncée par le bureau chargé de la sécurité publique et intérieure de la FCC concerne les futures demandes d’autorisation. Un modèle fabriqué hors des États-Unis et dépourvu d’un FCC ID obtenu auparavant ne peut donc plus recevoir automatiquement l’autorisation nécessaire à sa commercialisation.

Cette distinction réduit considérablement l’impact immédiat sur les chantiers déjà engagés. Les modèles étrangers précédemment validés restent admissibles à l’importation, à la vente et à l’installation. Selon les précisions réglementaires rapportées dans le texte source, une large part des projets solaires commerciaux et industriels proches de leur mise en service utilise précisément des références déjà autorisées.

La décision cible surtout les équipements connectés. Les onduleurs sans fonctions de commande distante, ainsi que ceux reposant sur une architecture totalement isolée du réseau, restent hors du périmètre décrit. La question de sécurité ne repose donc pas uniquement sur l’origine physique du matériel. Elle porte également sur la capacité d’un équipement à recevoir des instructions, transmettre des informations ou accepter des mises à jour logicielles.

Cette logique intervient après une analyse du Department of Energy datée de janvier 2026. L’examen de 30 onduleurs chinois n’avait identifié aucune preuve de matériel malveillant dissimulé. L’approche retenue ensuite par le conseil interagences de la Maison-Blanche déplace le risque vers la couche numérique. Selon cette analyse, un adversaire étranger pourrait exploiter les fonctions sans fil d’un onduleur intelligent pour pousser une mise à jour de firmware et arrêter à distance des installations photovoltaïques.

La provenance industrielle devient parallèlement un critère déterminant. La restriction vise le lieu de fabrication finale, indépendamment de la nationalité de la marque. Un fabricant américain assemblant un modèle à l’étranger peut ainsi être concerné. À l’inverse, une entreprise étrangère réalisant l’assemblage final dans une usine américaine peut demander une autorisation si son processus respecte les seuils fédéraux applicables aux composants.

La cybersécurité rencontre les contraintes du réseau électrique

Les conséquences pourraient devenir plus sensibles lors du renouvellement des gammes. Les données du Department of Energy citées dans le document indiquent que les producteurs américains couvrent seulement 7 % du marché national des onduleurs solaires. Le déficit théorique atteint donc 93 %, calculé par différence entre 100 % de la demande et 7 % d’approvisionnement domestique.

Cette dépendance intervient alors que les développeurs prévoient de raccorder plus de 58 000 MW de nouvelles capacités solaires et de stockage durant l’année suivante. Les nouveaux modèles nécessitant une autorisation FCC pourraient rencontrer un obstacle si leur production demeure étrangère et si leurs fonctions de communication les placent dans le champ de la Covered List.

Changer de fournisseur n’est pas nécessairement neutre. Les accords d’interconnexion sont associés aux caractéristiques techniques d’un modèle d’onduleur précis. Le remplacement d’une référence étrangère par un équipement domestique différent peut être considéré comme une « Material Modification ». Cette qualification peut imposer une nouvelle étude technique et retarder la procédure auprès du gestionnaire de réseau.

Le dossier touche aussi la stratégie américaine autour de l’intelligence artificielle. Selon l’America’s AI Action Plan cité dans le texte, la croissance des centres de données de nouvelle génération entraîne une forte hausse de la demande électrique. Les entreprises technologiques comptent notamment sur le solaire et le stockage pour soutenir ces besoins sans accroître excessivement la pression exercée sur les réseaux locaux.

Une voie dérogatoire existe pour certains équipements fabriqués à l’étranger. Le Department of Homeland Security ou le Department of Defense peut intervenir dans une procédure de Conditional Approval. Une autorisation conditionnelle peut être accordée lorsqu’une administration compétente estime que l’appareil, ou sa catégorie, ne présente pas un niveau de risque inacceptable.

L’Annex A mentionné par la FCC prévoit également un mécanisme destiné aux fournisseurs étrangers acceptant un calendrier contraignant de transfert de l’assemblage vers les États-Unis. Les fabricants concernés doivent alors exposer leur chaîne d’approvisionnement et leur architecture logicielle aux contrôles fédéraux afin de démontrer que leurs produits ne peuvent pas être manipulés à distance. Brev ! Un « espionnage » industriel décidé par la loi. Un classique !

backdoor, Cybersécurité, Entreprise, Espionnage Spy, Mise à jour, Securite informatique, Social engineering

RingCentral : 1,6 million de comptes exposés

La cyberattaque contre RingCentral change d’échelle : 1,6 million de comptes exposés et attribue l’intrusion au groupe cybercriminel ShinyHunters.

L’incident de sécurité reconnu par RingCentral fin juillet 2026 concerne désormais environ 1,6 million d’adresses électroniques uniques identifiées dans les données diffusées. Le corpus contient également des noms, numéros de téléphone et adresses postales. Aucun mot de passe ne figure parmi les catégories d’informations actuellement confirmées. RingCentral indique avoir stoppé l’activité malveillante et affirme que sa plateforme principale n’a pas été affectée. ZATAZ confirme également l’implication de ShinyHunters dans cette intrusion. Le groupe revendique l’exfiltration de 623 Go de données.

Une « portion limitée » qui atteint 1,6 million

Fin juillet, RingCentral avait reconnu une campagne d’ingénierie sociale ayant permis un accès non autorisé à certains de ses systèmes. La société évoquait alors une « portion limitée » de sa clientèle, sans communiquer d’estimation chiffrée sur le nombre de personnes concernées.

Les données désormais disponibles donnent une autre mesure de l’incident. Leur analyse fait apparaître environ 1,6 million d’adresses mails uniques. Ce nombre représente des comptes identifiés dans le corpus diffusé par les pirates et ne correspond donc pas nécessairement à 1,6 million d’entreprises clientes différentes.

Cette distinction est importante pour mesurer correctement l’impact. RingCentral fournit des services de téléphonie, de communication cloud et de collaboration à des organisations pouvant compter de nombreux utilisateurs. Plusieurs adresses rattachées à une même entreprise peuvent ainsi figurer dans la fuite.

Les informations exposées comprennent des noms, des adresses électroniques, des numéros de téléphone et des adresses postales. Aucun mot de passe n’est présent.

Ce type d’assemblage conserve pourtant une forte valeur opérationnelle pour un attaquant. Une identité associée à une adresse professionnelle, un téléphone et une localisation physique facilite la préparation de scénarios crédibles d’ingénierie sociale. Un pirate peut personnaliser davantage un courriel, un appel téléphonique ou une tentative d’usurpation en utilisant plusieurs informations exactes sur sa cible.

Les utilisateurs professionnels constituent une population particulièrement intéressante dans ce contexte. La connaissance de leur environnement de communication peut faciliter des tentatives visant à obtenir des informations complémentaires, provoquer une réinitialisation de compte ou convaincre une victime de suivre une procédure frauduleuse.

RingCentral affirme avoir interrompu l’activité malveillante après sa découverte. L’entreprise indique également avoir fait appel à une société spécialisée dans l’investigation numérique. Selon ses déclarations, aucune nouvelle activité non autorisée n’a été observée après la mise en œuvre des mesures correctives. Ce qui n’empéche pas les centaines de Go de données volées a être diffusés ! La plateforme principale n’aurait pas été compromise et les services seraient restés opérationnels durant l’incident.

ShinyHunters derrière l’intrusion selon ZATAZ

L’autre évolution concerne l’identité des attaquants. ZATAZ confirme que ShinyHunters est bien impliqué dans l’opération visant RingCentral. ShinyHunters affirme avoir dérobé environ 623 Go de données avant d’en publier une partie après l’échec d’une tentative d’extorsion. La chronologie permet également de comprendre pourquoi l’affaire prend aujourd’hui une dimension différente. L’incident s’est produit en juillet 2026. RingCentral a rendu publique la compromission le 28 juillet. Les données ont ensuite fait l’objet d’une diffusion, avant que l’ampleur d’environ 1,6 million de comptes soit détaillée publiquement le 14 août.

backdoor, Cybersécurité, Entreprise, Mise à jour, OS X, Patch, Securite informatique

Des Mac compromis via une faille Screen Sharing

Une faille de Screen Sharing corrigée par Apple est désormais exploitée activement, avec accès root et installation de mineurs Monero sur plusieurs Mac exposés.

La vulnérabilité CVE-2026-65400 affectant Screen Sharing sur macOS est désormais associée à des compromissions réelles. Le NCSC néerlandais rapporte plusieurs machines exposant le port 5900 sur Internet sur lesquelles des attaquants ont obtenu des privilèges root avant d’installer un mineur Monero. Apple avait publié des correctifs le 6 août 2026 pour macOS Tahoe 26.6.1, Sequoia 15.7.9 et Sonoma 14.8.9. Aucun vol de données ou d’identifiants n’est confirmé à ce stade. L’accès root ouvre toutefois un champ d’action beaucoup plus large, notamment sur les fichiers, sessions, secrets applicatifs et ressources accessibles depuis les postes compromis.

 

 

Une authentification contournée jusqu’au niveau root

L’alerte change de dimension depuis que l’exploitation de CVE-2026-65400 ne relève plus d’un risque théorique. Le NCSC-NL indique avoir reçu des signalements concernant plusieurs systèmes macOS dont le service Screen Sharing était directement accessible depuis Internet sur le port 5900. Dans chacun des cas observés, l’attaquant avait réussi à obtenir un accès root. Ce niveau de privilège correspond au contrôle le plus élevé sur un système Unix comme macOS. Les compromissions documentées ont ensuite conduit à l’installation d’un mineur de cryptomonnaie Monero. Apple avait pourtant corrigé la vulnérabilité dès le 6 août 2026. Les mises à jour concernées sont macOS Tahoe 26.6.1, macOS Sequoia 15.7.9 et macOS Sonoma 14.8.9. Le constructeur décrit CVE-2026-65400 comme un défaut d’authentification affectant Screen Sharing. Un attaquant présent sur le réseau peut, selon cette description, parvenir à s’authentifier auprès du service sans disposer d’identifiants valides. Cette caractéristique explique le risque particulier pesant sur les machines dont Screen Sharing est exposé directement sur Internet. Un service destiné à l’administration ou à l’assistance distante devient alors un point d’entrée potentiel vers le système lui-même.

Qu’est-ce que Screen Sharing ?

Screen Sharing est la fonction de partage d’écran intégrée à macOS. Elle permet d’afficher et de contrôler à distance l’écran d’un Mac depuis une autre machine. Elle peut servir à l’assistance technique, à l’administration d’un poste ou à l’accès distant à son propre ordinateur. Lorsqu’elle est activée et accessible depuis Internet, cette fonction devient aussi un service exposé aux tentatives de connexion. Dans le cas de CVE-2026-65400, la faille permet précisément de contourner l’authentification normalement nécessaire pour accéder à ce service.

Le 12 août, le NCSC-NL a ajouté la mention « exploitation active connue » à son bulletin. De nouvelles alertes publiques ont suivi le 15 août 2026. Cette chronologie place les organisations face à un scénario classique en cybersécurité : un correctif existe, tandis que des systèmes non mis à jour ou toujours exposés restent exploitables. Le nombre exact de victimes n’est pas communiqué. Le NCSC néerlandais confirme seulement plusieurs compromissions. Des recherches indépendantes recensent parallèlement plusieurs dizaines de milliers de services Screen Sharing accessibles depuis Internet. Ce volume ne peut pas être assimilé à un nombre de machines vulnérables. Une exposition du service n’implique ni que la version de macOS soit affectée, ni que l’exploitation ait réussi.

L’accès root élargit fortement le risque opérationnel

L’impact observé est pour l’instant concret et limité à ce qui a été confirmé : contrôle root sur les Mac compromis et déploiement de logiciels de minage Monero. Aucun vol de données, aucune extraction d’identifiants et aucune fuite d’informations ne sont documentés dans les cas rapportés. L’absence de preuve de vol ne réduit toutefois pas la portée technique d’un accès root. Une machine contrôlée à ce niveau peut potentiellement exposer ses fichiers locaux, les sessions ouvertes, les secrets utilisés par des applications et les ressources auxquelles le poste dispose déjà d’un accès. Ces possibilités relèvent du potentiel offert par la compromission, pas d’actions secondaires actuellement attribuées aux attaquants. Cette distinction reste essentielle pour évaluer la menace sans extrapolation. Les faits établis décrivent une exploitation active, une élévation jusqu’au niveau root et l’installation d’un cryptomineur. Les scénarios de récupération de secrets ou de rebond vers d’autres ressources sont techniquement plausibles, sans être démontrés dans les incidents signalés. Les postes administrés à distance constituent un cas particulièrement sensible. Lorsqu’un service Screen Sharing écoute directement sur Internet, l’attaquant n’a plus besoin d’un accès préalable au réseau interne pour atteindre la surface exposée. La faille d’authentification devient alors une porte d’entrée située au périmètre même du système. La chronologie renforce également l’enjeu de réaction. Apple a distribué ses correctifs le 6 août. Six jours plus tard, le NCSC-NL signalait officiellement une exploitation active connue. Le 15 août, de nouvelles alertes publiques confirmaient que la vulnérabilité devait désormais être considérée comme une menace opérationnelle et non comme une simple faiblesse corrigée sur le papier. Pour les équipes de sécurité, CVE-2026-65400 illustre ainsi le risque créé par l’association de trois facteurs : un service d’administration exposé, une faille permettant de contourner l’authentification et des machines n’ayant pas encore reçu le correctif disponible.