Archives de catégorie : Entreprise

Actualités liées à la sécurité informatique des entreprises, PME, PMI, TPE, association, communes.

Entreprise

Pentest, audit de sécurité, SOC : quels contrôles auraient pu détecter une attaque comme celle de la DGFiP ?

Laisser un commentaire

Une attaque informatique ne commence pas toujours par l’exploitation spectaculaire d’une faille inconnue. Parfois, le pirate emprunte simplement une porte normalement réservée à une personne autorisée. Les accès illégitimes subis par la DGFiP en juin et juillet 2026 illustrent cette difficulté : les intrusions ont été repérées et interrompues, mais l’extraction de données n’a pas été identifiée immédiatement. Face à une telle attaque, le pentest, l’audit de sécurité et le SOC interviennent à des étapes différentes et remplissent chacun une fonction bien précise. Leur efficacité dépend surtout de la façon dont ils se complètent.

L’attaque de la DGFiP révèle plusieurs niveaux de détection

D’après les éléments rendus publics, des identifiants appartenant à un agent et à un tiers habilité ont été usurpés. Les accès obtenus ont permis de consulter et d’extraire des informations relatives à 678 000 particuliers et professionnels, parmi lesquelles figuraient des données fiscales, des coordonnées et certains renseignements cadastraux. Les espaces personnels des contribuables n’ont pas été compromis. Le détail de la méthode employée pour détourner les comptes n’étant pas connu, toute affirmation plus précise sur le point d’entrée resterait hypothétique.

L’incident met surtout en lumière la différence entre la détection d’un accès suspect et celle d’un vol de données. Une entreprise peut donc repérer un compte compromis sans mesurer immédiatement tout ce qu’il a réalisé. Pour évaluer ses propres angles morts, elle peut contacter une entreprise de cybersécurité comme Basom Consulting, qui examinera à la fois les protections préventives, les droits accordés aux utilisateurs et les moyens de surveillance. Cette analyse ne se limite pas à la manière dont un pirate pourrait entrer dans le système. Elle vérifie aussi jusqu’où un compte compromis donne accès aux données et si une activité inhabituelle serait repérée assez rapidement.

Le pentest teste les chemins qu’un attaquant pourrait emprunter

Un pentest, ou test d’intrusion, consiste à confier à des spécialistes la recherche encadrée de moyens permettant de pénétrer dans le système d’information. Ces professionnels se placent dans une situation proche de celle d’un pirate, avec des règles et un périmètre définis à l’avance. Ils essaient notamment de contourner un portail d’accès, d’exploiter une mauvaise configuration ou d’obtenir davantage de privilèges que prévu. Ce travail peut révéler qu’un compte ordinaire ouvre indirectement la voie vers une application sensible ou une base de données mal protégée.

Dans un scénario proche de celui de la DGFiP, le test devrait dépasser la simple recherche de vulnérabilités sur un site internet. Un pentest réalisé avec un compte d’agent ou de prestataire permettrait d’étudier ce qu’une personne malveillante peut accomplir après une connexion réussie. Peut-elle interroger des milliers de dossiers, exporter des fichiers ou passer d’une application à l’autre sans nouveau contrôle ? Le pentest pourrait faire apparaître ces possibilités. En revanche, il ne surveille pas le réseau toute l’année : il fournit une photographie offensive à un moment donné, sur le périmètre réellement testé.

L’audit de sécurité repère les faiblesses moins visibles

L’audit de sécurité couvre un champ plus large que le pentest. Il peut porter sur :

  • l’architecture informatique ;
  • la configuration des équipements ;
  • le code d’une application ;
  • la gestion des accès ;
  • l’organisation interne.

Concrètement, les auditeurs cherchent à savoir si les protections annoncées existent réellement, si elles sont correctement réglées et si les équipes les appliquent. Une politique de sécurité peut, par exemple, exiger la suppression rapide des anciens comptes, alors que plusieurs accès de prestataires restent actifs après la fin de leur mission.

Ce contrôle aurait aussi examiné la séparation entre les services, les applications et les bases de données. Lorsqu’un compte compromis donne accès à un ensemble trop vaste d’informations, le risque ne vient pas uniquement du vol de l’identifiant. Il tient également aux autorisations attachées à ce compte. Un audit des habilitations aurait pu signaler des droits trop étendus, des contrôles insuffisants avant un export ou l’absence de révision périodique des accès. Il aurait également vérifié la conservation des journaux techniques, indispensables pour retracer les consultations et déterminer quelles données ont quitté le système.

Le contrôle des identités doit continuer après la connexion

La double authentification ajoute une preuve au mot de passe, par exemple un code temporaire ou une validation sur un appareil. Elle réduit fortement le risque lié au vol d’un identifiant, sans le faire disparaître. Un faux site peut intercepter une validation en temps réel, une session déjà ouverte peut être détournée et un utilisateur peut approuver une demande trompeuse. C’est pourquoi l’accès ne devrait pas devenir automatiquement fiable dès que les deux étapes ont été franchies. La connexion ne représente que le début du contrôle.

Une protection plus fine tient compte du contexte. Un compte qui se connecte depuis un nouvel appareil, à un horaire inhabituel ou depuis une zone géographique incohérente mérite une vérification supplémentaire. Il en va de même lorsque son comportement change soudainement : recherches répétées, consultation rapide de nombreux dossiers ou téléchargement sans rapport avec ses missions habituelles. Des sessions plus courtes, une nouvelle authentification avant les opérations sensibles et des facteurs résistants à l’hameçonnage compliquent aussi la tâche du pirate. L’objectif consiste à ne jamais confondre identité présentée et confiance définitive.

Le SOC observe les comportements suspects en continu

Le SOC, pour centre opérationnel de sécurité, réunit des analystes, des procédures et des outils chargés de surveiller l’activité informatique. Il reçoit des alertes issues des postes de travail, des serveurs, des applications, des équipements réseau et des services d’authentification. Son intérêt apparaît surtout lorsqu’un attaquant utilise des identifiants valides. Une connexion isolée peut sembler normale. Plusieurs signaux rapprochés peuvent toutefois dessiner un scénario inquiétant, que l’équipe doit reconnaître assez tôt pour limiter les conséquences.

Lors d’une attaque comme celle de la DGFiP, un SOC correctement renseigné aurait pu rechercher des écarts entre l’usage attendu d’un compte et son activité réelle. Un agent consulte habituellement quelques dossiers liés à son service ; son compte en interroge soudain des milliers, avec une cadence inhabituelle. Ce type d’écart doit déclencher une alerte, une suspension temporaire ou une demande de confirmation. Encore faut-il définir les bonnes règles : accumuler des notifications sans priorité finit par masquer les événements véritablement dangereux.

La corrélation des journaux aide à reconnaître une extraction

Chaque composant du système conserve des traces, couramment appelées journaux ou logs. Elles indiquent qui s’est connecté, quelle ressource a été consultée, à quel moment et parfois quelle quantité de données a circulé. Pris séparément, ces éléments paraissent souvent anodins. Une plateforme de corrélation, généralement nommée SIEM, les rassemble afin de faire ressortir des enchaînements suspects. Une authentification inhabituelle, suivie de requêtes nombreuses puis d’un transfert volumineux, devient ainsi plus visible qu’une série d’événements dispersés entre plusieurs applications.

La qualité de ces traces compte davantage que leur simple existence. Si une application enregistre seulement la réussite d’une connexion, l’équipe ne peut pas savoir quels dossiers ont ensuite été ouverts ou exportés. Les journaux doivent donc couvrir les recherches, les téléchargements, les changements de droits et les volumes transmis. Une surveillance du réseau peut compléter cette vue en repérant des flux sortants inhabituels. Des solutions de prévention contre la fuite de données peuvent, quant à elles, bloquer ou signaler le départ d’informations sensibles, même si la personne à l’origine de l’action possède un compte reconnu.

Les habilitations et les quotas réduisent l’ampleur du vol

La détection ne doit pas compenser des droits d’accès excessifs. Le principe du moindre privilège consiste à n’accorder à chaque personne que les autorisations nécessaires à son travail. Il suppose aussi une révision régulière, car les fonctions évoluent, les prestataires changent et certains accès finissent par ne plus avoir de justification. Si un pirate compromet un compte limité, il atteint moins de données et rencontre davantage d’obstacles. Cette réduction du périmètre constitue déjà une protection, même lorsque l’alerte tarde à apparaître.

Des quotas peuvent également encadrer le nombre de dossiers consultés ou exportés sur une période donnée. Leur seuil doit correspondre aux réalités du métier afin de ne pas bloquer les équipes lors d’un pic légitime. Au-delà d’une certaine limite, le système peut ralentir la requête, exiger une validation ou prévenir le SOC. Les applications sensibles gagnent aussi à distinguer la consultation unitaire de l’extraction en masse. Une personne autorisée à vérifier un dossier n’a pas nécessairement besoin de télécharger une base complète. Cette nuance réduit directement les possibilités offertes par un compte usurpé.

L’affaire de la DGFiP rappelle qu’un accès reconnu par le système peut tout de même cacher une activité malveillante. Le véritable enjeu ne consiste donc pas uniquement à empêcher la connexion initiale. Il faut aussi limiter ce que chaque compte peut atteindre, reconnaître les comportements anormaux et conserver assez de traces pour comprendre rapidement l’incident. Le pentest et l’audit préparent le terrain ; le SOC maintient la vigilance au quotidien. Des quotas, des habilitations précises et des journaux exploitables réduisent encore le délai de réaction. La sécurité devient réellement plus solide lorsque ces mesures fonctionnent ensemble et font l’objet de vérifications régulières.

Cybersécurité, Entreprise, Espionnage Spy

Interpol frappe les réseaux cybercriminels de 22 pays

Pendant huit mois, Interpol et les polices de 22 pays ont ciblé les infrastructures, les flux financiers et les intermédiaires soutenant plusieurs réseaux cybercriminels internationaux.

L’opération Jackal IV, conduite entre novembre 2025 et juin 2026, s’est soldée par 58 arrestations et l’identification de plusieurs centaines de suspects. Les enquêteurs ont notamment frappé des réseaux actifs en Argentine, en Afrique du Sud, en Roumanie et en Italie. Leur priorité dépassait les seuls auteurs de fraudes. Interpol a cherché à remonter les circuits financiers, les infrastructures numériques et les services utilisés par les groupes criminels. Les investigations ont également mis en évidence l’essor du Crime-as-a-Service, des escroqueries sentimentales, des fraudes aux cryptomonnaies et de la sextorsion visant parfois des mineurs de 14 ans.

Jackal IV remonte les infrastructures criminelles

La dernière phase de l’opération Jackal s’inscrit dans une campagne internationale engagée depuis plusieurs années contre des organisations cybercriminelles structurées. Entre novembre 2025 et juin 2026, Interpol a coordonné les actions de forces de l’ordre provenant de 22 pays. Les policiers ont recherché les suspects prioritaires, saisi des avoirs, perturbé des circuits de blanchiment et appuyé les autorités nationales pendant les arrestations.

En Argentine, l’enquête a conduit les autorités vers un réseau fonctionnant selon un modèle de Crime-as-a-Service, ou CaaS. Selon Interpol, cette organisation reposait sur 196 personnes. Elle fournissait notamment des noms de domaine destinés à des sites internet ainsi que des prestations de blanchiment d’argent pour des groupes criminels organisés d’Afrique de l’Ouest.

Parmi leurs bénéficiaires figurait Black Axe, une organisation que plusieurs services de police internationaux tentent de démanteler depuis plus de cinq ans. Dix-sept personnes ont été interpellées en Argentine.

Pour Tomonobu Kaya, directeur d’Interpol, le suivi des mouvements d’argent à travers plusieurs juridictions a permis aux enquêteurs d’atteindre « l’un des éléments les plus essentiels de la criminalité organisée ». Cette approche illustre la logique de Jackal IV. Plutôt que de se concentrer exclusivement sur les auteurs visibles des escroqueries, les services de police cherchent également les intermédiaires capables de fournir infrastructures numériques, transferts financiers et mécanismes de dissimulation.

Interpol estime que Black Axe et des organisations comparables représentent une « part importante des fraudes financières utilisant les technologies numériques dans le monde ». Leurs activités comprennent les escroqueries sentimentales, les faux investissements, les fraudes liées aux cryptomonnaies et la compromission de messageries professionnelles, connue sous l’acronyme BEC. Ces structures sont également associées à d’autres infractions graves et violentes.

Des millions saisis et des victimes toujours plus ciblées

En Afrique du Sud, les policiers ont perquisitionné sept sites à Johannesburg. Ils étaient liés à un groupe soupçonné de mener des escroqueries sentimentales et de faux investissements contre des personnes âgées installées dans des pays anglophones.

Ces interventions ont abouti à 39 arrestations. Les autorités ont également saisi des actifs estimés à 2,48 millions d’euros.

La Roumanie a révélé une autre dimension financière de l’opération. Onze personnes ont été arrêtées dans une enquête concernant une fraude aux investissements en cryptomonnaies organisée depuis un centre d’appels. Les enquêteurs ont identifié 166 millions $ (environ 152,72 millions d’euros) provenant de vols et d’opérations de blanchiment. Les fonds étaient conservés dans des portefeuilles électroniques sous le contrôle du groupe.

Les autorités roumaines ont parallèlement saisi environ 348 680 euros, ainsi que plusieurs biens immobiliers et des montres de luxe.

En Italie, les investigations ont conduit à l’identification d’un participant présumé à un dispositif de blanchiment reposant sur des sociétés écrans, des services de transfert d’argent et des retraits en espèces. Cette combinaison montre la coexistence d’outils numériques et de circuits financiers plus traditionnels au sein des mêmes structures criminelles.

Jackal IV a aussi permis à Interpol de relever des tendances jugées préoccupantes. La sextorsion visant les mineurs prend notamment une place croissante. Certaines victimes n’ont que 14 ans. Les criminels les approchent sur les réseaux sociaux ou les plateformes de jeux, instaurent une relation de confiance, obtiennent des images intimes puis exigent de l’argent sous la menace d’une publication.

La pression contre Black Axe se poursuit depuis 2021. En 2024, la troisième phase de Jackal avait déjà conduit à plus de 300 arrestations en Afrique de l’Ouest, en Argentine et dans plusieurs autres régions. En avril, les polices suisse et allemande avaient également arrêté dix membres présumés du groupe lors de perquisitions simultanées.

Au-delà des interpellations, Jackal IV montre que le renseignement financier, l’analyse des infrastructures et la coopération transfrontalière deviennent des leviers centraux contre les écosystèmes cybercriminels. (BC)

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é, 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.

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.