Archives mensuelles : août 2026

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.

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

SAP Commerce Cloud : une faille critique déjà exploitée

Trois jours après son correctif, une faille critique de SAP Commerce Cloud fait déjà l’objet de tentatives d’exploitation visant des plateformes exposées sur Internet.

La vulnérabilité CVE-2026-58231 place SAP Commerce Cloud sous surveillance étroite. Corrigée par SAP le 11 août 2026, cette faille affichant un score CVSS de 10.0 permettrait une exécution de code sans authentification ni action préalable de l’utilisateur. Des chercheurs ont détecté des tentatives d’exploitation dès le 14 août, alors qu’aucune activité hostile n’était encore signalée deux jours auparavant. Plus de 4 200 systèmes présentant une empreinte SAP Commerce Cloud seraient accessibles depuis Internet, principalement en Europe et en Amérique du Nord. Leur vulnérabilité effective reste inconnue. Une intrusion réussie pourrait ouvrir l’accès à des services métiers connectés, notamment ERP, CRM, stocks et commandes.

Du correctif aux premières attaques en trois jours

La chronologie resserrée constitue le principal signal d’alerte autour de CVE-2026-58231. SAP a publié son correctif le 11 août 2026 dans la note de sécurité 3771065. Le 12 août, aucune exploitation active n’était encore rapportée. Dès le 14 août, des chercheurs observaient cependant des tentatives contre des environnements SAP Commerce Cloud. De nouvelles publications spécialisées ont relayé l’alerte le 15 août.

La faille concerne le Data Hub Adapter des branches COM_CLOUD 2211 et 2211-JDK21. Son score CVSS maximal, 10.0, traduit une combinaison particulièrement défavorable pour les défenseurs. L’attaque ne requiert aucune authentification et aucune interaction d’un utilisateur. Une exploitation réussie peut permettre l’exécution de code arbitraire et compromettre des composants internes accessibles depuis l’instance concernée.

Cette rapidité entre publication du correctif et activité offensive réduit fortement la fenêtre disponible pour les entreprises. Une vulnérabilité publique devient rapidement exploitable lorsque suffisamment d’informations techniques permettent à des attaquants de comprendre le mécanisme défaillant et de rechercher des cibles accessibles.

Le signal doit toutefois être interprété avec précision. L’existence de la vulnérabilité et son niveau critique sont confirmés par SAP ainsi que par le NVD. En revanche, l’exploitation active repose actuellement sur des observations réalisées par des chercheurs et reprises par plusieurs sources spécialisées. SAP ne l’a pas encore officiellement qualifiée comme exploitation active.

Aucune victime identifiée publiquement ni campagne de vol massif de données n’est confirmée à ce stade. L’enjeu immédiat concerne donc davantage l’exposition et la capacité d’intrusion que les conséquences documentées d’attaques déjà réussies.

Les systèmes métiers derrière la vitrine e-commerce

SAP Commerce Cloud ne constitue pas seulement une interface de vente exposée aux internautes. Dans une architecture d’entreprise, une plateforme de commerce électronique peut communiquer avec plusieurs briques internes nécessaires aux stocks, commandes, comptes clients ou traitements administratifs.

Une compromission de l’instance peut ainsi transformer un service accessible depuis Internet en point d’entrée vers des ressources moins directement exposées. Selon l’architecture déployée, les attaquants pourraient atteindre des services reliés à un ERP, un CRM, des systèmes de gestion des stocks, des traitements de commandes ou d’autres composants internes.

Aucune catégorie précise de données volées n’est actuellement confirmée. Il serait donc prématuré d’affirmer que des informations clients, financières ou commerciales ont déjà été exfiltrées. Le risque porte sur les données et services que l’instance compromise serait autorisée à consulter ou solliciter, ainsi que sur les relations de confiance établies avec les systèmes voisins.

L’ampleur potentielle de la surface exposée ajoute une dimension particulière à l’incident. Shadowserver aurait identifié plus de 4 200 systèmes accessibles depuis Internet présentant une empreinte associée à SAP Commerce Cloud. La majorité se situerait en Europe et en Amérique du Nord.

Ce chiffre ne correspond toutefois pas au nombre de serveurs vulnérables. Une empreinte détectable indique la présence apparente de la technologie, sans démontrer que la version concernée par CVE-2026-58231 est utilisée ni que le correctif du 11 août n’a pas été appliqué. Assimiler les 4 200 systèmes à autant de cibles exploitables conduirait donc à surestimer l’exposition réelle.

Pour les équipes de sécurité, la priorité réside dans la vérification des versions et l’application de la note SAP 3771065 sur les environnements concernés. La surveillance doit aussi porter sur les systèmes connectés à Commerce Cloud, puisque la valeur d’un accès initial dépend souvent des privilèges, flux applicatifs et relations internes disponibles après l’intrusion.

La séquence observée illustre enfin une dynamique désormais centrale du renseignement cyber : entre divulgation d’une faille critique et premières tentatives offensives, la fenêtre de réaction peut se mesurer en quelques jours.

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

ChocoPoC cible les chercheurs en vulnérabilités

Des chercheurs français en cybersécurité ont identifié une campagne sophistiquée utilisant de faux exploits CVE pour infecter les environnements des pentesters avec un cheval de Troie Python.

Une enquête menée par YesWeHack et Sekoia révèle une attaque de chaîne d’approvisionnement visant directement les chercheurs en vulnérabilités. Depuis fin 2025, des acteurs malveillants diffusent de faux dépôts GitHub proposant des preuves de concept pour des failles critiques. Sept dépôts piégés ont été identifiés. Leur installation déclenche des dépendances Python malveillantes capables de déployer ChocoPoC, un RAT conçu pour voler des fichiers, récupérer des identifiants et exécuter des commandes.

Des exploits CVE transformés en pièges

L’affaire débute le 25 juin 2026. Après la publication d’un modèle Nuclei consacré à Joomla JCE, l’équipe de YesWeHack reçoit une suggestion concernant deux preuves de concept associées à une vulnérabilité critique Joomla. L’un des dépôts, consacré à CVE-2026-48908, attire rapidement l’attention.

Son fichier de dépendances réclame un paquet Python inconnu nommé « frint ». Celui-ci installe à son tour « skytext », publié récemment sur PyPI. Le paquet se présente comme une bibliothèque destinée à produire rapidement des couleurs dans un terminal. Son contenu réel est beaucoup moins décoratif.

Skytext distribue des extensions compilées pour Linux et Windows. L’analyse de la version Windows révèle du code obfusqué, une exploration du Process Environment Block, des fonctions résolues dynamiquement et plusieurs blocs chiffrés. Le programme vérifie également son environnement avant d’exécuter son activité malveillante.

Cette précaution complique fortement l’analyse automatisée. Le code recherche notamment la présence d’un fichier portant un nom précis, comme « EXPLOIT_POC.py ». Sans ce contexte, aucune charge utile ne se déclenche. Un échantillon isolé dans un bac à sable peut ainsi sembler inoffensif.

Lorsque les conditions attendues sont réunies, l’extension déchiffre plusieurs composants et modifie l’environnement Python. Elle installe une version détournée du paquet _distutils_hack ainsi que des fichiers .pth. Ces éléments sont ensuite chargés lors du démarrage d’un nouvel interpréteur Python.

Cette persistance permet de lancer choco.py, le téléchargeur intermédiaire de ChocoPoC. Celui-ci récupère une nouvelle charge utile grâce à un jeu de données hébergé chez Mapbox. Les requêtes DNS peuvent passer par DNS-over-HTTPS, notamment via AliDNS ou Cloudflare, afin de contourner certains mécanismes locaux de filtrage.

Le trafic conserve par ailleurs l’apparence d’une connexion légitime vers l’API Mapbox. Cette infrastructure sert de point mort pour récupérer le RAT et échanger des informations, réduisant la visibilité du canal de commande.

Une campagne pensée pour les outils offensifs

Le dernier étage de l’infection est un RAT (logiciel espion) écrit en Python. ChocoPoC peut collecter des données issues de Chrome, Brave, Edge et Firefox, notamment les mots de passe, cookies, historiques et informations de remplissage automatique.

Il recherche également certains fichiers locaux, des bases de données, des historiques de commandes shell, des informations réseau et la liste des processus actifs. L’opérateur peut lancer des commandes système, exécuter dynamiquement du code Python, récupérer des fichiers ou modifier la fréquence des communications avec le serveur de contrôle.

L’enquête a permis d’identifier au moins sept dépôts GitHub malveillants associés à des vulnérabilités très médiatisées. Les leurres visaient notamment FortiWeb, React2Shell, MongoBleed, PAN-OS, Ivanti Sentry, Checkpoint VPN et Joomla SP Page Builder.

Deux chaînes de dépendances apparaissent. En 2025, plusieurs dépôts utilisaient les paquets « slogsec » et « logcrypt.cryptography ». En 2026, les opérateurs ont privilégié « frint » et « skytext ». Malgré ces changements, YesWeHack et Sekoia relèvent plusieurs caractéristiques communes, dont le même identifiant de fonctionnalité Mapbox, des contrôles environnementaux similaires et des mécanismes identiques contre les relances récursives.

Ces éléments conduisent les chercheurs à attribuer avec une forte confiance les deux périodes d’activité au même acteur. Selon leur analyse, l’opérateur aurait régulièrement changé de comptes GitHub, PyPI et Mapbox pour limiter les blocages et compliquer le suivi de son infrastructure.

Les adresses électroniques utilisées pour certaines publications semblent également liées à des comptes compromis. Des identifiants concernant deux des quatre adresses étudiées figuraient dans des bases de données de fuites, dont l’une probablement issue d’une infection par infostealer.

Les statistiques de téléchargement renforcent l’inquiétude sans démontrer, à elles seules, une compromission. Le paquet skytext aurait enregistré environ 2 400 téléchargements sur Linux et Windows, avec une majorité sous Linux. Plusieurs hausses coïncident avec la divulgation ou l’exploitation publique de vulnérabilités importantes.

Le risque dépasse donc la seule machine d’un chercheur. Un pentester compromis peut manipuler des identifiants clients, des rapports confidentiels, des données techniques sensibles ou des informations concernant des systèmes vulnérables.

ChocoPoC illustre ainsi une évolution préoccupante du renseignement cyber : le code visible peut rester crédible tandis que l’infection se déplace vers les dépendances, transformant l’urgence autour des nouvelles CVE en véritable surface d’attaque.

backdoor, Banque, Cybersécurité, Espionnage Spy, Securite informatique, Social engineering

WindRelay et SpyNote, le relais NFC passe à l’attaque

Un malware Android inédit combine contrôle à distance, fraude au crédit et relais NFC, permettant à des escrocs de détourner une carte bancaire pendant un appel.

WindRelay, un malware Android conçu pour transmettre en temps réel les échanges NFC d’une carte bancaire. Associé au cheval de Troie d’accès distant SpyNote, il s’intègre dans une fraude mêlant ingénierie sociale, prise de contrôle du smartphone, usurpation d’identité et paiement sans contact détourné. Dans un cas analysé, l’opération complète s’est déroulée durant un appel de seulement 13 minutes. Les chercheurs ont relié 23 échantillons de WindRelay, soumis entre novembre 2025 et juillet 2026, à plusieurs campagnes observées notamment en Tchéquie, Slovaquie et Slovénie. L’étendue réelle des victimes reste inconnue.

Treize minutes pour prendre le contrôle du téléphone

Le scénario étudié par la société Group-IB (Group-IB, société de cybersécurité fondée en Russie en 2003 et désormais basée à Singapour, après avoir quitté le marché russe en 2023.) illustre l’intégration croissante entre manipulation téléphonique et outils malveillants Android. L’attaque commence par un appel frauduleux destiné à gagner la confiance de la cible. La victime est ensuite conduite à installer SpyNote, dans une version personnalisée portant son propre nom. Cette personnalisation constitue un indice important sur la préparation de l’opération. Les fraudeurs disposaient au minimum d’informations permettant d’identifier précisément leur cible, notamment son nom et son numéro de téléphone. Les éléments disponibles ne permettent toutefois pas de déterminer l’origine de ces données personnelles. Il suffit de voir les alertes de ZATAZ pour comprendre la problématique de la fuite de données, aujourd’hui.

Une fois SpyNote installé, les attaquants obtiennent un accès à distance au terminal Android. Dans le cas documenté, cette compromission leur permet d’installer un second programme, WindRelay, puis d’accéder à l’environnement bancaire de la victime.

La fraude ne s’arrête pas à la prise de contrôle du smartphone. Les opérateurs utilisent l’accès obtenu pour souscrire un crédit au nom de la personne ciblée. Celle-ci peut ainsi se retrouver avec une dette contractée frauduleusement avant même que la phase NFC ne débute.

L’étape suivante exploite directement la carte bancaire physique. Toujours guidée pendant l’appel, la victime est invitée à approcher sa carte de son téléphone. WindRelay transmet alors en temps réel les communications NFC vers une infrastructure contrôlée par les escrocs. Ceux-ci peuvent exploiter le relais depuis un autre terminal afin de réaliser une transaction.

L’ensemble de cette séquence, installation du RAT, déploiement du second malware, accès bancaire, crédit frauduleux et relais NFC, a été réalisé durant un appel de 13 minutes !

SpyNote dispose par ailleurs de fonctions de collecte plus étendues. Les informations fournies ne permettent pas d’affirmer que toutes ont été employées au cours de cette attaque précise. L’analyse doit donc distinguer les capacités techniques du logiciel des actions effectivement observées.

Le relais NFC devient une chaîne de fraude complète

23 échantillons WindRelay ont été découverts dans plusieurs campagnes detectées. Ces fichiers ont été soumis à l’analyse entre novembre 2025 et juillet 2026. Quatre infrastructures de commande associées ont également été identifiées. Ces 23 échantillons ne représentent pas 23 victimes. Ils constituent des artefacts techniques associés à l’activité détectée. Le nombre total de personnes visées ou compromises reste inconnu au moment de la divulgation, publiée le 12 août 2026.

Les échantillons et campagnes sont principalement associés à la Tchéquie, à la Slovaquie et à la Slovénie. Cette implantation s’inscrit dans un contexte régional où plusieurs formes de fraude NFC avaient déjà été observées. Le rapport 2025 du European Payments Council cite le relais NFC et la technique dite « Ghost Tap » parmi les menaces émergentes contre les paiements. Selon ce document, ces attaques peuvent se combiner avec des escroqueries utilisant l’accès à distance et conduire à des transactions non autorisées ainsi qu’à une perte de contrôle sur les fonds.

Les données communiquées par Kaspersky indiquent pour leur part une hausse de 188 % des attaques NFC visant Android pendant les quatre premiers mois de 2026 par rapport à la même période de 2025. L’entreprise affirme avoir bloqué 35 600 attaques sur cette période, contre plus de 12 300 un an auparavant.

ESET avait auparavant relevé une multiplication supérieure à 35 des attaques liées au NFC durant le premier semestre 2025, comparé au second semestre 2024. Les premiers usages documentés d’une version modifiée de l’outil open source NFCGate remontent, selon les sources fournies, à fin 2023 en Tchéquie.

D’autres recherches montrent également une diversification des infrastructures. Zimperium indique avoir suivi des campagnes couvrant notamment la Pologne, la Tchéquie et la Slovaquie, avec plus de 70 serveurs de commande et points de distribution identifiés. Des attaquants ont aussi imité la Banque nationale de Slovaquie afin de rendre leurs applications frauduleuses plus crédibles et d’obtenir les autorisations NFC nécessaires.

Des opérations chinoises de Fraud-as-a-Service diffusant des malwares Android compatibles NFC via Telegram avaient été documentés, l’année derniére. Cette précédente enquête mentionnait plus de 54 échantillons et au moins 355 000 $ de transactions frauduleuses confirmées entre novembre 2024 et août 2025 pour un seul fournisseur de terminaux de paiement. WindRelay apporte une évolution distincte : le relais NFC n’est plus seulement une technique isolée. Associé à SpyNote, il devient l’un des maillons d’une chaîne réunissant renseignement préalable sur la cible, contrôle du téléphone, fraude à l’identité, crédit frauduleux et détournement de la carte physique.

APT, Cybersécurité, Entreprise, Espionnage Spy, Securite informatique

City-Forum aspire Salesforce et ServiceNow sans faille

Une campagne active extrait des données de portails Salesforce et ServiceNow exposés aux visiteurs anonymes, en exploitant des permissions excessives plutôt qu’une vulnérabilité logicielle.

Depuis au moins mars 2025, une infrastructure associée au domaine city-forum cible des organisations internationales via Salesforce Experience Cloud et ServiceNow Service Portal. Cette cyber attaque est attribuée à un même acteur utilisant un outil dédié, capable d’automatiser l’énumération de données accessibles aux comptes invités. Télécoms, banques, services financiers, éditeurs logiciels, entreprises de cybersécurité, acteurs de la protection des données et organismes publics figurent parmi les secteurs visés. La campagne, divulguée le 12 août 2026, reste active. Aucun groupe n’est attribué de façon fiable. L’enjeu tient surtout à l’exploitation industrielle de mauvaises configurations SaaS permettant des extractions massives sans authentification préalable.

Des permissions invité transformées en canal d’exfiltration

La campagne, baptisée « City-Forum » par la société Reco, repose sur un principe simple : exploiter ce que les portails SaaS autorisent déjà à consulter. Aucun défaut logiciel n’est nécessaire. Lorsque les droits accordés aux visiteurs anonymes sont trop larges, l’attaquant peut interroger les services disponibles et collecter les informations ainsi exposées.

Selon la configuration de chaque organisation, ces données peuvent comprendre des fiches de comptes, des contacts, des dossiers, des fichiers ou d’autres objets accessibles au profil invité. Aucune liste consolidée n’a été diffusée par l’entreprise. Pas d’informations sur ce qui est dérobée ni identité des organisations concernées.

Les observations convergent vers une infrastructure unique. Les requêtes proviennent de l’adresse IP 158.220.87.79, hébergée chez Contabo, et utilisent presque systématiquement l’agent utilisateur Go-http-client/1.1. Ce dernier correspond au client HTTP utilisé par défaut dans Go. Sa présence constante sur des portails conçus pour des navigateurs suggère une automatisation au moyen d’un programme compilé.

Cette même adresse IP dessert city-forum. Les données DNS passives citées par Reco relient ce domaine à l’infrastructure depuis mars 2025. L’équipe précise ne pas pouvoir dater précisément le début des scans. Elle peut uniquement établir que le serveur est contrôlé depuis cette période. Le volume observé traduit une activité soutenue. Sur la cible la plus sollicitée étudiée, plus de 560 000 événements ont été enregistrés. Ce chiffre ne correspond pas à 560 000 victimes ou personnes compromises. Il mesure les opérations d’énumération détectées sur cette cible.

L’activité progresse actuellement. Les secteurs touchés couvrent plusieurs catégories sensibles, notamment les télécommunications, la finance, les logiciels professionnels, la cybersécurité, la protection des données et le secteur public. Les organisations ne sont pas nommer pour ne pas caractériser individuellement les victimes (et potentiellement ses clients !).

Un outil commun pour Salesforce et ServiceNow

L’intérêt cyber-renseignement de City-Forum tient surtout à son outillage. Le même opérateur semble avoir conçu un programme capable d’interroger deux grands environnements SaaS avec plusieurs techniques complémentaires.

Sur Salesforce, l’acteur emploie l’énumération Aura déjà documentée dans d’autres campagnes visant des comptes invités trop permissifs. Il ajoute toutefois une méthode moins couramment observée : l’accès aux sites Lightning Web Runtime par l’interface UI API et GraphQL.

Les requêtes repérées parcourent successivement différentes versions de l’API, de v56.0 jusqu’à v66.0. L’acteur sonde également des chemins liés à l’auto-inscription, notamment SiteRegister et CommunitiesSelfReg.

Sur ServiceNow, le programme sollicite intensivement le mécanisme natif de recherche du Service Portal via l’endpoint /api/now/sp/search. Les chercheurs décrivent une cadence incompatible avec une utilisation humaine normale. Dans un cas analysé, les volumes sont passés de dizaines de requêtes quotidiennes à plusieurs centaines. Les journaux ServiceNow permettent d’identifier les requêtes, leur provenance, l’utilisateur « guest », l’agent utilisateur et la quantité de données renvoyée. Ils ne conservent toutefois pas le corps des requêtes POST. Une organisation peut donc confirmer un balayage du moteur de recherche et mesurer les réponses obtenues sans nécessairement reconstruire les termes recherchés.

Sur Salesforce, la détection dépend notamment des journaux Event Monitoring. Reco recommande de rechercher l’adresse IP identifiée, Go-http-client/1.1, les volumes anormaux de requêtes Aura ainsi que les appels invités vers les chemins webruntime de LWR.

La campagne présente certaines ressemblances avec des opérations précédemment associées à ShinyHunters, notamment l’énumération de données Salesforce accessibles aux visiteurs. Mais SH n’est pas le seul malveillant à avoir des idées tordues.

Un autre élément distingue City-Forum : la stabilité opérationnelle observée. La même adresse IP et le même domaine sont utilisés depuis au moins mars 2025, sans rotation détectée pendant cette période. Cette caractéristique constitue un signal comportemental, pas une preuve d’identité.

La conclusion technique est plus solide que toute hypothèse attributive : un même outil en Go semble avoir ciblé Salesforce via Aura et LWR, puis ServiceNow depuis une infrastructure commune. Pour la CTI, City-Forum illustre surtout comment des permissions SaaS mal maîtrisées peuvent devenir une interface d’exfiltration industrialisée, sans exploitation d’une vulnérabilité classique.

Cybersécurité, Entreprise, Securite informatique

Hexposure cartographie le risque cyber des PME

Après plusieurs années de réflexion et des mois de développement, Hexposure ouvre sa bêta privée avec une promesse : rendre le risque cyber externe exploitable par les PME.

Hexposure part d’un constat issu du terrain : une exposition critique naît souvent de plusieurs faiblesses apparemment secondaires. Un environnement de préproduction oublié, une clé d’API intégrée dans du JavaScript ou une interface dépourvue d’authentification peuvent, une fois combinés, ouvrir un accès étendu aux données. La plateforme québécoise veut reconstituer ces chaînes d’attaque plutôt que produire des centaines d’alertes isolées. Sans agent ni accès interne, elle cartographie les actifs visibles depuis Internet, analyse plus de 250 contrôles et utilise plus de 30 techniques de reconnaissance. L’objectif consiste à hiérarchiser les problèmes selon leur impact réel, puis à fournir aux PME, startups et MSP des correctifs compréhensibles et vérifiables. Attention, il ne s’agit pas d’un article sponsorisé ou autre placement de produit. Le projet est sexy et je voulais vous en parler.

Reconstituer les chemins d’attaque plutôt qu’empiler les alertes

L’origine d’Hexposure tient à une expérience répétée au fil des mandats de cybersécurité offensive. Pris séparément, certains constats peuvent sembler peu préoccupants. Un sous-domaine de préproduction subsiste en ligne. Une clé d’API apparaît dans un bundle JavaScript. Une interface applicative reste accessible sans mécanisme d’authentification.

Chacun de ces éléments peut être classé comme un signal relativement faible. Leur combinaison change pourtant la lecture du risque. En les reliant, un attaquant peut parfois progresser jusqu’à une exposition complète de données clients.

C’est précisément cette logique que veut traiter Hexposure et son faondateur, Patrick. Les outils de balayage traditionnels peuvent générer des centaines d’alertes, jusqu’à 765 dans l’exemple présenté par son créateur, sans nécessairement expliquer lesquelles forment ensemble une trajectoire exploitable. La charge d’analyse reste alors entre les mains de l’entreprise ou de son prestataire.

Son idée adopte une approche différente. La plateforme cherche d’abord à dresser la carte de ce qu’une organisation rend accessible sur Internet. Cette surface comprend notamment les sous-domaines, les adresses IP, les services actifs, les points d’accès applicatifs et les certificats. Elle couvre également les fichiers exposés, les secrets divulgués et les domaines imitant ceux de l’entreprise.

L’analyse ne s’arrête pas à l’inventaire

Chaque exposition est classée selon son impact potentiel sur l’activité. Le système rapproche ensuite les observations afin de reconstruire le parcours qu’un attaquant pourrait suivre.

Cette méthode vise à transformer une accumulation de signaux techniques en scénario compréhensible. Une faiblesse isolée peut ainsi changer de priorité dès lors qu’elle fournit une étape utile vers une seconde ressource exposée.

La plateforme fonctionne sans agent, sans installation locale et sans accès au réseau interne. Son point d’observation reste donc l’extérieur, dans une logique proche de celle d’un attaquant réalisant une phase de reconnaissance sur une cible accessible publiquement.

Hexposure annonce plus de 30 techniques de reconnaissance et plus de 250 vérifications lors de chaque analyse. Le processus est relancé chaque mois. Les corrections apportées entre deux analyses sont également revalidées automatiquement afin de vérifier que les expositions identifiées ont réellement disparu.

Sa première cohorte bêta privée est désormais ouverte, avec un nombre de places annoncé comme limité. Elle cible particulièrement les personnes responsables du risque externe dans les PME, les startups et les fournisseurs de services gérés, notamment les MSP.

Bref, derrière cette bêta, l’enjeu de renseignement cyber est clair : identifier ce qu’un adversaire peut voir, comprendre comment il peut relier ces informations et réduire les chemins d’attaque avant qu’ils ne soient exploités.

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

MyPhoto : une base de 16 272 clients exposée

Une base de données attribuée au site MyPhoto aurait exposé commandes, photos, salariés et données logistiques, créant un risque concret de phishing ciblé et d’ingénierie sociale.

Selon un message publié le 7 août 2026 par un pirate informatique, une base Firebase Realtime Database liée à MyPhoto Inc. aurait été accessible sans authentification. L’auteur revendique l’extraction de 158 Mo de données contenant 16 272 adresses électroniques, 171 047 lignes de commandes et 21 126 associations entre clients et photographies. Des informations internes concernant 41 salariés, 794 affectations de postes de travail ainsi que plusieurs données d’expédition figureraient également dans l’ensemble. Au-delà d’une simple fuite commerciale, cette exposition fournirait aux attaquants un contexte précis pour construire des campagnes de phishing, d’usurpation et de manipulation ciblée.

Une base de production décrite comme ouverte

La publication affirme que la base concernée utilisait Firebase Realtime Database et autorisait une lecture anonyme. Selon exfilar, aucun compte, jeton ou contrôle de provenance n’aurait été nécessaire pour consulter son contenu. L’accès en écriture n’aurait pas été testé.

Le pirate décrit 33 catégories principales couvrant plusieurs étapes de la chaîne de production. Elles concerneraient notamment les stations actives, les commandes, les articles, les employés, les expéditions, les inventaires, les étiquettes d’images et les numéros de suivi.

Les chiffres détaillés présentent 171 047 éléments de commandes, 207 commandes de production et 21 126 enregistrements associant une adresse électronique à une photographie ou à une commande. Exfilar évoque également 39 correspondances de numéros de suivi, sept expéditions finalisées et 169 documents internes liés au traitement des commandes.

La publication distingue 16 272 adresses électroniques collectées et 14 636 adresses uniques associées à des commandes photographiques. Gmail représenterait 7 490 occurrences, Yahoo 2 630 et Hotmail 844. Les autres fournisseurs totaliseraient 5 308 entrées.

L’auteur du message affirme également avoir identifié 41 salariés avec leurs fonctions, leur organisation et leur statut professionnel. Les rôles décrits couvrent les ressources humaines, les opérations, la production, l’impression numérique, le contrôle qualité, l’expédition et la préparation des commandes.

Un matériau directement exploitable pour le phishing

L’enjeu cyber principal réside dans la combinaison des informations. Une adresse électronique isolée possède une valeur limitée. Associée à une référence de commande, une date, une photographie, un transporteur ou une étape logistique, elle peut devenir un puissant élément de crédibilisation.

Exfilar souligne précisément ce scénario. Un attaquant pourrait envoyer un faux message signalant un incident sur une commande connue, puis demander au destinataire de confirmer une adresse de livraison ou d’ouvrir une page frauduleuse. La connaissance préalable du contexte réduit les signes habituels permettant d’identifier une tentative de phishing générique.

Les données internes sur les salariés créent un second risque. Connaître les fonctions d’une équipe, les responsabilités opérationnelles et l’organisation d’un site facilite la préparation d’appels frauduleux, d’usurpations d’identité ou de demandes prétendument urgentes.

La cartographie revendiquée de 794 affectations de postes de travail ajoute une dimension de renseignement organisationnel. Elle donnerait une représentation détaillée du fonctionnement de la production, depuis le traitement des commandes jusqu’à l’expédition.

Le message affirme que des sociétés de travail temporaire, dont Manpower et TempJoy, apparaissent également dans les données en raison de personnels affectés à MyPhoto. Aucune compromission indépendante de leurs propres systèmes n’est démontrée par les éléments fournis.

Le pirate insiste sur le caractère non sophistiqué de l’accès revendiqué. Selon son récit, la faiblesse proviendrait essentiellement de règles Firebase autorisant la lecture publique de la base. Cette configuration transformerait une erreur de contrôle d’accès en exposition massive de données opérationnelles.

L’auteur rattache cette fuite à une opération présentée comme une campagne de recherche de bases exposées. Il revendique 32 bases découvertes, cinq projets dépassant 100 Mo et 117 projets distincts. Ces chiffres proviennent uniquement de ses déclarations et ne constituent pas, à eux seuls, une validation indépendante.

Le même message indique qu’un outil lié à cette activité est commercialisé pour 50 000 $ (46 080 euros). Cette revendication renforce l’hypothèse d’une démarche structurée visant à industrialiser la détection puis l’exploitation de configurations cloud insuffisamment protégées.