Archives de catégorie : backdoor

backdoor, Cybersécurité

OVHcloud expose le piratage de son outil de commande

OVHcloud a détaillé une attaque visant son outil de commande. Des téléchargements officiels piégés ont exposé les secrets des utilisateurs, déclenchant une réponse publique et documentée.

Une page officielle peut distribuer un logiciel malveillant lorsque sa publication est détournée. OVHcloud en a fait l’expérience avec son interface en ligne de commande, utilisée pour administrer des ressources cloud depuis un terminal. Un compte GitHub compromis a permis de remplacer les fichiers de cinq versions existantes, sans modifier leur code source. L’entreprise européenne a communiqué publiquement, retiré les exécutables concernés et documenté l’incident. L’exposition dépend du téléchargement effectué pendant la fenêtre d’attaque et de l’exécution du programme. Pour les utilisateurs concernés, réinstaller une version saine ne suffit pas : les secrets accessibles sur leur poste doivent également être révoqués.

Des archives officielles remplacées après publication

Le piège reposait sur une confiance quotidienne : télécharger un outil depuis le dépôt de son éditeur. Les utilisateurs retrouvaient le projet attendu, ses versions habituelles et des fichiers portant des noms familiers. Pourtant, certaines archives avaient été remplacées après leur publication initiale.

Cinq versions étaient concernées, de la 0.11.0 à la 0.15.0. Selon la reconstitution d’OpenSourceMalware, l’attaquant a utilisé les accès d’un contributeur disposant des permissions nécessaires pour modifier les fichiers associés aux versions publiées. Le détournement portait sur les exécutables distribués. Le code source et la chaîne de compilation n’avaient pas été altérés.

L’opération s’accompagnait du remplacement de checksums.txt, le fichier contenant les empreintes utilisées pour contrôler les téléchargements. Les nouvelles valeurs correspondaient aux archives piégées. Un utilisateur comparant son téléchargement avec cette référence modifiée pouvait donc obtenir un résultat rassurant. La vérification perdait son utilité puisque le fichier contrôlé et sa référence avaient été remplacés ensemble.

L’alerte est venue d’un client ayant conservé une empreinte SHA-256 attendue dans sa chaîne d’intégration. Lorsque l’archive Linux ARM a changé, le contrôle a échoué. Cette différence a conduit à un signalement public sur GitHub. Une référence enregistrée avant l’attaque a ainsi révélé une modification que les pages de téléchargement ne rendaient pas immédiatement visible.

La chronologie officielle situe la disponibilité des fichiers malveillants le 19 octobre 2026, entre 14 h 47 et 16 h 21, heure de Paris. OVHcloud a retiré les exécutables concernés puis publié la version 0.16.0, accompagnée d’une étiquette signée et de fichiers rendus immuables. Cette configuration empêche leur remplacement ultérieur au sein de la même publication.

La transparence d’OVHcloud se mesure ici à des éléments concrets : échanges publics avec l’auteur du signalement, horaires d’intervention, identification du défaut de configuration et publication d’un avis technique le 20 octobre. Le rapport annoncé dans les premières communications est désormais disponible. L’entreprise y décrit également les corrections appliquées et les mesures de renforcement envisagées.

Des secrets à révoquer sur les postes exposés

Le numéro de version, pris isolément, ne permet pas de déterminer l’exposition. Une copie légitime téléchargée avant le remplacement des archives reste différente d’un exécutable malveillant distribué ensuite sous la même référence. Il faut donc examiner la provenance du fichier et le moment de son acquisition.

Les téléchargements directs depuis GitHub, le script d’installation officiel et Homebrew pouvaient récupérer les archives remplacées. Une chaîne d’intégration automatisée pouvait également les télécharger sans intervention manuelle. Selon OpenSourceMalware, les compilations réalisées depuis le code source, notamment avec go install, échappaient à ce détournement. L’analyse distingue aussi l’image Docker construite en interne des exécutables substitués sur GitHub.

Le danger apparaît lorsque le programme piégé est lancé. L’avis officiel demande de considérer comme compromis les secrets présents sur un ordinateur ayant exécuté une copie concernée. Il recommande de vérifier les empreintes des fichiers suspects sans les lancer. Exécuter ovhcloud version pour obtenir un diagnostic ferait précisément démarrer le programme dont on cherche à établir l’innocuité.

Les accès à examiner dépassent le seul compte OVHcloud. Le texte initial cite notamment les clés d’API, la configuration ovh.conf, les clés SSH et les accès Kubernetes. Un poste d’administration peut concentrer des moyens de connexion à plusieurs environnements. La portée de l’incident dépend donc aussi des secrets effectivement accessibles sur chaque machine.

Depuis un ordinateur sain, les utilisateurs concernés doivent révoquer ou renouveler ces accès, puis remplacer l’exécutable compromis par une distribution propre. Supprimer le fichier malveillant ne retire aucune valeur aux identifiants déjà copiés. Tant qu’un secret reste valide, son détenteur peut tenter de l’utiliser.

L’attribution appelle une précision comparable. OpenSourceMalware rapproche la compromission ancienne du compte de l’écosystème GlassWorm, notamment à partir de traces dans des dépôts personnels et d’un portefeuille Solana connu. Son analyse initiale distingue toutefois ces indices de la preuve qu’un même opérateur aurait conduit toutes les étapes. Cette réserve évite de transformer un rapprochement technique en certitude.

backdoor, Cybersécurité, Mise à jour, Patch, Securite informatique

Ghostpat, la faille qui exposait les images Docker

Une faille critique de Docker Hub permettait d’utiliser les droits d’un autre utilisateur pour manipuler ses images de conteneurs, avec un risque pour la chaîne d’approvisionnement logicielle.

Identifiée sous la référence CVE-2026-105445, la vulnérabilité GhostPat touchait la conversion des comptes personnels Docker Hub en organisations. Un jeton d’accès conservé par un attaquant pouvait être réattribué à un autre utilisateur, donnant accès aux dépôts autorisés pour cette victime. Découverte par Peter Molnar et Krisztian Hozak, cette erreur de gestion des identités a reçu un score de gravité de 9,4 sur 10. Présente pendant plus de deux ans, elle pouvait permettre la publication d’images malveillantes sous une identité légitime.

Un jeton personnel pouvait changer d’identité

Le problème se trouvait dans une opération administrative de Docker Hub. Un utilisateur pouvait transformer son compte personnel en organisation et désigner un autre utilisateur comme propriétaire. Cette transition entraînait également le transfert des jetons d’accès personnels, les PAT, vers le propriétaire choisi.

Or, ce transfert ne s’accompagnait pas d’un renouvellement du secret permettant d’utiliser ces jetons. Leur ancien détenteur conservait donc une information toujours valide. Le nouveau propriétaire, lui, n’avait pas à donner son accord pour cette réattribution. Une opération de gestion de compte devenait ainsi une rupture dans le contrôle des accès.

Un attaquant pouvait exploiter cette combinaison en faisant rattacher à sa victime un jeton dont il connaissait déjà le secret. Docker Hub reconnaissait ensuite ce jeton comme appartenant à l’utilisateur ciblé. L’identité associée à l’accès avait changé, sans que la personne capable de l’utiliser ait perdu cette capacité.

Les conséquences dépendaient de deux éléments, les permissions du jeton et les droits de la victime. Selon leur combinaison, l’attaquant pouvait récupérer des images, en publier ou en supprimer. Le périmètre concernait les dépôts personnels accessibles à l’utilisateur ciblé, ainsi que ceux des organisations auxquelles celui-ci avait accès. La fiche CVE confirme cette possibilité d’agir sur les images au niveau du registre.

La menace dépassait donc la simple consultation non autorisée. Publier une image sous le nom d’un développeur légitime pouvait introduire du contenu malveillant dans une chaîne d’approvisionnement logicielle. L’image aurait été distribuée depuis un emplacement associé à un acteur réel, alors que son contenu pouvait avoir été modifié par un tiers.

Cette possibilité explique la qualification critique de GhostPat. Elle ne signifiait toutefois pas que toutes les fonctions du compte devenaient accessibles. La faille ne permettait pas de se connecter à l’interface web de Docker Hub, de changer le mot de passe, de modifier l’adresse électronique ou de toucher aux paramètres de double authentification. Le risque portait sur les opérations du registre autorisées par le jeton, avec des conséquences potentiellement importantes pour les images concernées.

Une enquête sur deux ans de transferts

Peter Molnar et Krisztian Hozak ont découvert cette vulnérabilité, baptisée GhostPat. Le défaut était resté présent dans le code pendant plus de deux ans. Cette durée imposait de vérifier rétrospectivement les conversions de comptes et les usages des jetons transférés.

Docker affirme avoir examiné l’ensemble de ces conversions sur la période concernée. L’entreprise a également étudié environ 304 000 publications d’images réalisées avec les jetons issus de ce mécanisme. Ce chiffre correspond à des opérations de dépôt dans le registre, et ne constitue pas un décompte d’images compromises ou d’attaques.

Les vérifications ont aussi porté sur les images publiques considérées comme les plus exposées à une éventuelle compromission. Selon Docker, ces investigations n’ont révélé aucun indice d’exploitation de GhostPat. Ce constat doit conserver son attribution, il s’agit du résultat communiqué par l’entreprise à l’issue de ses recherches, et non de la preuve qu’une attaque a eu lieu.

Au début d’octobre 2026, Docker a averti les utilisateurs dont les comptes avaient reçu des jetons provenant d’autres comptes. Les propriétaires des organisations correspondantes ont également été informés. L’enjeu était de permettre aux personnes concernées d’identifier ces accès et d’en vérifier la légitimité.

Le 8 octobre, les jetons potentiellement dangereux ont été désactivés. Une exception a été appliquée à ceux pour lesquels les titulaires avaient expressément demandé le maintien en activité. Docker recommande aux utilisateurs avertis d’examiner leurs jetons personnels et de révoquer ceux qu’ils ne reconnaissent pas ou dont ils n’ont plus besoin.

backdoor, Cybersécurité, Mise à jour, Patch

Ghostscript : un PDF piégé peut compromettre un serveur

Une faille critique de Ghostscript expose les serveurs traitant des PDF à une exécution de code, mais les essais montrent une exploitation dépendante de l’environnement ciblé.

Un document téléversé peut déclencher davantage qu’un simple enregistrement sur disque. Lorsqu’un serveur transforme un PDF en miniature, il peut solliciter Ghostscript, un composant de traitement documentaire touché par la vulnérabilité CVE-2026-39919. Cette corruption de mémoire concerne le traitement de certaines images JPEG 2000 intégrées aux documents. Les chercheurs ont obtenu une exécution de code sur un serveur WordPress préparé pour leurs essais. Cependant, leurs deux fichiers de démonstration n’ont produit aucune exécution de code lors de 10 240 tentatives sur dix autres environnements Linux. Un correctif existe depuis septembre 2026.

Une miniature de PDF comme point d’entrée

Ghostscript travaille souvent en coulisses. Cet interpréteur de documents PDF et du langage PostScript intervient dans le rendu des pages, la production d’aperçus ou l’optimisation des fichiers. Des applications comme ImageMagick, GIMP, Inkscape et Scribus l’utilisent, tout comme certaines configurations du système d’impression CUPS. Sa présence dépasse donc largement le périmètre des sites Internet.

Dans WordPress, la chaîne de traitement peut associer l’extension PHP Imagick, ImageMagick et Ghostscript pour fabriquer une miniature du PDF déposé dans la médiathèque. Le fichier fourni par un utilisateur atteint alors un programme installé sur le serveur. C’est cette opération de conversion qui rend la vulnérabilité accessible, lorsque les conditions techniques nécessaires sont réunies.

Des spécialistes ont découvert le problème le 23 août 2026. Le défaut est un débordement de tampon dans le tas, une zone de mémoire utilisée pendant l’exécution du logiciel. Il apparaît lors du traitement de PDF spécialement conçus contenant une image JPEG 2000.

L’erreur concerne des images dont les composantes présentent des résolutions différentes et utilisent moins de huit bits par valeur. Ghostscript calcule incorrectement l’espace mémoire nécessaire. Dans la démonstration décrite, le programme peut écrire 1 024 octets dans un tampon prévu pour seulement 256 octets. Cette écriture hors limites corrompt la mémoire et ouvre potentiellement la voie à l’exécution de code arbitraire.

Les versions concernées vont de Ghostscript 9.21 à 10.07.1, sous réserve de la présence du chemin de décodage vulnérable et des correctifs éventuellement intégrés par les distributions. Les environnements examinés comprenaient Debian, Ubuntu, Fedora, Alpine, AlmaLinux ainsi qu’un instantané de l’image Docker officielle de WordPress. Tous contenaient le code défectueux au moment des tests.

Cette présence ne signifie cependant pas que chaque installation peut être compromise avec le même document. Les chercheurs ont préparé deux preuves de concept, puis effectué 10 240 tentatives sur dix environnements Linux distincts. Aucune n’a abouti à une exécution de code en dehors de la construction logicielle correspondante.

A noter que les changements de polices, de paramètres linguistiques, de configuration des fontes et d’une bibliothèque système n’étaient pas des prérequis à réunir pour réussir. Les chercheurs ont modifié séparément ces éléments en conservant le même exécutable Ghostscript. L’exploitation restait possible dans les quatre configurations, avec une réussite intermittente. Leurs résultats soulignent surtout l’importance de la construction exacte du programme ciblé.

Des conditions précises et un correctif disponible

Pour WordPress, quatre conditions doivent se cumuler. Un attaquant doit pouvoir transmettre un PDF, anonymement ou depuis un compte disposant de faibles privilèges. Le site doit ensuite produire un aperçu du document. Cette conversion doit effectivement passer par Ghostscript, selon les logiciels installés et leurs politiques de sécurité. Enfin, le programme doit encore contenir le code vulnérable.

WordPress n’autorise pas, par défaut, les visiteurs anonymes à déposer des documents dans sa médiathèque. La présence du logiciel ou d’une image Docker concernée ne suffit donc pas à démontrer une exposition anonyme. Il faut examiner le parcours réel du fichier, depuis son téléversement jusqu’à son éventuel traitement.

Le périmètre dépasse néanmoins cette seule plateforme. Toute application qui transmet des PDF non fiables à une version vulnérable de Ghostscript peut présenter une surface d’exposition. La question opérationnelle porte ainsi sur les conversions réellement effectuées, y compris lorsque l’utilisateur ne voit qu’un formulaire de dépôt ou une miniature.

Artifex a corrigé CVE-2026-39919 avec la version finale 10.08.0, publiée le 8 septembre 2026. Des corrections ont également été reportées dans certaines branches antérieures. Un numéro de version ancien ne permet donc pas, à lui seul, de conclure que le paquet installé reste vulnérable. La révision complète et les informations du fournisseur sont déterminantes.

backdoor, cyberattaque, Cybersécurité, Espionnage Spy

Des opérateurs télécoms ciblés par un faux portail

Des courriels imitant un organisme de traçage des appels cherchent à pousser les opérateurs télécoms vers un logiciel permettant un accès à distance.

L’identité d’un acteur de la lutte contre les appels frauduleux devient un prétexte d’hameçonnage. Des entreprises inscrites dans la Robocall Mitigation Database reçoivent de fausses demandes attribuées à l’Industry Traceback Group (ITG). Le message présente un portail prétendument sécurisé et invoque un délai de vingt-quatre heures pour provoquer une réaction rapide. L’Industry Traceback Group (ITG) est un organisme américain piloté par US Telecom, une association professionnelle du secteur des télécommunications. Il coordonne le traçage des appels suspects, notamment ceux liés aux escroqueries et aux appels automatisés illégaux. Ce n’est pas un service de police.

Concrètement, un appel peut traverser plusieurs opérateurs avant d’atteindre son destinataire. L’ITG demande à chacun d’identifier l’opérateur qui lui a transmis cet appel, puis remonte la chaîne jusqu’à son origine. Cette procédure s’appelle le traceback. Les informations recueillies peuvent soutenir les enquêtes des autorités.

Le lien conduit en réalité vers un dépôt GitHub proposant un logiciel dont l’installation permettrait un accès distant. Cette description documente une tentative de compromission ; elle ne fournit aucun bilan vérifié des entreprises effectivement touchées, des installations réalisées ou des données éventuellement dérobées aux destinataires.

Dans l’affaire évoquée, les attaquants usurpent l’identité de l’ITG pour rendre crédible une fausse demande de traçage et inciter les destinataires à ouvrir un lien piégé. Les attaquants auraient utilisé les coordonnées publiques du registre RMD pour adresser aux professionnels de fausses demandes de traçage. La base sert alors à identifier les personnes à cibler ; cela ne signifie pas qu’elle a été piratée.

La Robocall Mitigation Database (RMD) est un registre public de la FCC, le régulateur américain des télécommunications. Elle recense les opérateurs concernés et les mesures qu’ils déclarent appliquer contre les appels automatisés illégaux, appelés robocalls. Les opérateurs y déposent notamment leur identité et les coordonnées d’un responsable ; leur programme de lutte contre les appels illégaux ou encore leur niveau de déploiement de STIR/SHAKEN, un dispositif d’authentification du numéro présenté lors d’un appel.

L’inscription a une conséquence concrète : les opérateurs soumis aux règles américaines ne doivent pas accepter directement le trafic des fournisseurs absents de cette base. Une radiation peut donc empêcher un fournisseur d’acheminer ses appels vers le réseau américain. L’inscription reste une déclaration réglementaire, pas une garantie que tous ses appels sont légitimes.

Android, backdoor, Cybersécurité, Entreprise, Espionnage Spy, Securite informatique, Smartphone

Midnight Mimosa infecte Android avant le premier démarrage

Des smartphones Android arrivent chez leurs propriétaires avec un logiciel malveillant déjà intégré, capable d’installer des applications discrètement et de détourner leur connexion Internet à des fins frauduleuses.

Midnight Mimosa transforme des téléphones Android à bas prix en supports de fraude publicitaire et, potentiellement, en relais réseau contrôlés à distance. Cette campagne touche des milliers d’appareils dans plus de 150 pays, dont la France. Sa particularité tient à son implantation dans le micrologiciel, le logiciel qui accompagne le matériel et participe au fonctionnement du téléphone. Le propriétaire peut donc recevoir un appareil déjà compromis, sans avoir téléchargé la moindre application suspecte. Les chercheurs décrivent une infection persistante, dotée de privilèges système, dont l’origine exacte dans la chaîne d’approvisionnement reste à établir.

Une infection installée au cœur du téléphone

Le premier téléchargement dangereux n’existe parfois pas. Dans cette affaire, le composant malveillant précède l’utilisateur et bénéficie de droits habituellement réservés au fonctionnement d’Android. Une apparence de service technique suffit ensuite à brouiller les pistes.

Selon les éléments rapportés, le logiciel d’espionnage de téléphone Midnight Mimosa serait actif depuis au moins deux ans. Le Mexique, la France, l’Italie, les États-Unis, l’Allemagne, le Brésil et l’Espagne figurent parmi les pays les plus représentés dans les observations des chercheurs. Ces données décrivent les appareils détectés, sans constituer un recensement exhaustif des victimes.

L’infection concerne notamment des smartphones économiques équipés de plateformes MediaTek, parmi lesquels les Doogee S200 X et Cubot KINGKONG X. Des contrefaçons reproduisant l’apparence de modèles Samsung ou Apple apparaissent également dans les éléments présentés. Cette présence ne permet pas d’attribuer une responsabilité au fournisseur des puces ni aux marques imitées.

Le point d’entrée précis demeure inconnu

L’hypothèse privilégiée est celle d’une introduction au cours de la chaîne d’approvisionnement. Les informations disponibles ne permettent toutefois d’identifier ni l’étape concernée ni les responsables. La découverte d’un composant dans un micrologiciel ne démontre pas, à elle seule, la participation consciente du fabricant.

Le logiciel se présente notamment sous les noms com.android.system.lite et com.android.sys.prot. Ces intitulés évoquent des fonctions internes ordinaires. Derrière cette façade, les composants disposent de signatures et de permissions leur permettant d’agir avec des privilèges élevés. Le gestionnaire d’applications classique ne suffit donc pas à les supprimer. Sur les forums XDA, des propriétaires de téléphones Cubot et Doogee ont signalé le retour d’applications suspectes après leur suppression. Un utilisateur de Doogee Fire 3 Max rapporte une apparition après une mise à jour officielle, suivie d’une disparition après restauration d’un micrologiciel antérieur. Ce témoignage apporte un indice sur son appareil, sans établir un scénario identique pour toute la campagne.

Les capacités décrites dépassent largement l’affichage publicitaire. Midnight Mimosa peut ajouter ou retirer des applications sans solliciter le propriétaire, accorder des autorisations et exécuter du code transmis par ses opérateurs. Le téléphone conserve ainsi un composant capable de renouveler les charges malveillantes.

Publicités invisibles et connexions détournables

Les chercheurs ont recensé environ 32 applications distribuées par ce dispositif. Météo, gestion de fichiers, reconnaissance de texte ou édition audio leur servent de couverture. Ces fonctions familières rendent leur présence moins immédiatement suspecte.

La rémunération repose principalement sur une fraude publicitaire. Les applications utilisent un kit publicitaire légitime pour récupérer de véritables annonces. Leur affichage s’effectue cependant dans des fenêtres invisibles superposées à d’autres applications. Le système publicitaire peut alors comptabiliser une impression sans qu’aucun utilisateur ait réellement vu le contenu.

Certaines variantes automatisent aussi les interactions. Des clics sont produits sans geste du propriétaire, donnant artificiellement de la valeur à une audience inexistante. L’utilisation d’une technologie publicitaire légitime ne rend donc pas légitime l’activité qui l’exploite.

Pour faciliter les installations, le logiciel désactive temporairement l’application Google Play Store, identifiée par com.android.vending, puis la réactive. Bitdefender présente cette séquence comme une tentative de contourner la détection par Play Protect. Certaines variantes falsifient également l’origine déclarée d’une installation pour lui donner l’apparence d’un téléchargement depuis la boutique officielle.

Une autre capacité concerne un proxy TCP, susceptible de faire transiter du trafic extérieur par la connexion du téléphone. L’adresse IP du propriétaire devient alors un point de sortie potentiel pour des activités qu’il ne contrôle pas. L’accès à de tels relais résidentiels peut être commercialisé.

La capacité technique et son exploitation effective doivent être distinguées. Les chercheurs ont confirmé le fonctionnement de l’infrastructure de contrôle associée, sans pouvoir déterminer si les téléphones infectés avaient effectivement relayé du trafic comme proxys.

Treize applications liées à la campagne ont également été repérées sur Google Play avec un code frauduleux similaire. Elles ne disposent cependant pas des privilèges des composants préinstallés. Les assimiler entièrement effacerait une différence essentielle pour comprendre la persistance de l’infection. La suppression nécessite un micrologiciel sain ou une désactivation des composants concernés au moyen d’Android Debug Bridge (ADB). Désactiver ne signifie toutefois pas retirer le code du micrologiciel.

backdoor, Cybersécurité, double authentification, Entreprise, Mise à jour, Securite informatique, Social engineering

EvilTokens industrialise la fraude grâce à l’IA

Microsoft a démantelé une partie d’EvilTokens, une plateforme cybercriminelle exploitant l’intelligence artificielle pour compromettre des messageries, analyser leurs contenus et préparer des fraudes financières ciblées.

EvilTokens illustre une évolution importante de la cybercriminalité assistée par intelligence artificielle. Lancé en février 2026, le service aurait été associé à plus de 12 000 boîtes mail compromises dans plus de 10 000 organisations. Son fonctionnement dépassait la simple génération de messages frauduleux. Une interface conversationnelle analysait les courriels volés, identifiait les relations de confiance, les responsables financiers et les procédures internes. Pas vraiment une nouveauté dans sa forme, ZATAZ avait révélé la découverte de ce type d’outil, voilà trois ans, mis en place par des pirates informatiques brésiliens. Microsoft et ses partenaires ont saisi 50 sites et neutralisé plus de 150 domaines associés. Au Royaume-Uni, deux hommes ont été arrêtés. L’affaire montre comment l’IA peut transformer un accès initial en renseignement exploitable pour préparer rapidement une fraude.

De la messagerie compromise au renseignement financier

EvilTokens permettait d’abord aux opérateurs criminels de prendre le contrôle de comptes de messagerie. Les victimes étaient incitées à saisir un code d’authentification sur la véritable page de connexion de Microsoft. Elles validaient alors, sans communiquer leur mot de passe, un accès exploitable par les attaquants.

Cette méthode présentait une difficulté supplémentaire pour les défenseurs. Une simple réinitialisation du mot de passe pouvait rester insuffisante lorsque les sessions et les jetons d’authentification associés n’étaient pas révoqués.

L’innovation la plus notable intervenait après l’intrusion. Examiner manuellement plusieurs milliers de courriels demande normalement du temps et une compréhension précise des circuits de décision. EvilTokens automatisait une partie de cette phase de renseignement.

Ses outils pouvaient résumer ou traduire les messages, repérer des échanges financiers, cartographier les responsabilités et identifier des relations de confiance. L’intelligence artificielle recherchait aussi des factures, des discussions liées aux virements ou les personnes disposant d’un pouvoir sur les paiements.

Des commandes prédéfinies aidaient notamment les utilisateurs à repérer les responsables manipulant les fonds ou à déterminer quelles identités seraient les plus crédibles à usurper. L’IA ne servait donc pas uniquement à rédiger un courriel convaincant. Elle contribuait à sélectionner une victime, choisir un interlocuteur à imiter et déterminer un scénario de fraude adapté aux informations découvertes.

Usurpation d’un contact connu

Le service pouvait ensuite proposer des messages se faisant passer pour des contacts connus. L’objectif consistait à exploiter les habitudes, les responsabilités ou les autorisations observées dans la boîte compromise afin d’augmenter les chances d’obtenir un paiement ou une autre action sensible.

En quelques mois, Microsoft a relié EvilTokens à plus de 12 000 messageries compromises appartenant à plus de 10 000 organisations. L’activité observée était particulièrement concentrée aux États-Unis, au Canada, au Royaume-Uni, en Australie, en Inde et en France.

Les victimes appartenaient à plusieurs secteurs, dont la distribution, la construction, les services financiers, l’immobilier, l’enseignement supérieur et la santé.

EvilTokens était commercialisé sur Telegram avec un droit d’entrée de 1 500 $ (conversion en euros impossible sans introduire un taux de change absent des informations fournies), puis un abonnement récurrent de 500 $ (conversion en euros non calculable pour la même raison). Cette offre regroupait compromission de comptes, analyse des boîtes, sélection des cibles et préparation des fraudes dans une même interface.

Un modèle criminel intégré, ciblé par une opération internationale

Les enquêteurs ont également trouvé des éléments indiquant qu’une grande partie d’EvilTokens avait été développée selon une approche de « vibe coding », l’intelligence artificielle assistant directement les créateurs dans la programmation de la plateforme. Plusieurs modèles d’IA auraient aussi contribué aux fonctionnalités proposées.

Cette combinaison abaissait les compétences nécessaires à plusieurs étapes. Des techniques relevant auparavant de l’attaque d’identité, des environnements cloud, de l’ingénierie sociale et de la fraude financière étaient réunies dans un service commercial disposant d’abonnements, d’assistance et de tableaux de gestion.

Pour perturber cette infrastructure, Microsoft a associé action judiciaire et coopération opérationnelle. Health-ISAC s’est joint à la procédure comme coplaignant, notamment parce que des acteurs de la santé figuraient parmi les organisations ciblées.

Avec l’autorisation du tribunal fédéral du district Est de Virginie, Health-ISAC a travaillé avec Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, Shadowserver Foundation et TRM Labs. L’opération a permis la saisie de 50 sites utilisés par le service et la désactivation de plus de 150 domaines supplémentaires liés à son infrastructure.

La coopération avec la Metropolitan Police Service a également débouché sur une opération au Royaume-Uni. Le 11 septembre 2026, les policiers ont arrêté deux hommes âgés de 32 et 38 ans, soupçonnés d’infractions liées à l’exploitation présumée d’EvilTokens. Des appareils numériques et d’autres éléments ont été saisis pour examen. Les deux suspects ont ensuite été libérés sous caution policière, avec conditions, pendant la poursuite de l’enquête. Les défenseurs ont eux-mêmes eu recours à l’IA aprés avoir utilisé la rétro-ingénierie et des outils assistés par intelligence artificielle pour analyser les éléments collectés, accélérer les investigations et identifier les infrastructures soutenant le service.

EvilTokens montre surtout qu’une boîte mail compromise peut devenir presque immédiatement une source structurée de renseignement financier, organisationnel et relationnel exploitable par des fraudeurs assistés par IA.

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.