Pendant plusieurs mois, dans le cadre d’une campagne récemment découverte par Microsoft, des cybercriminels ont furtivement utilisé une API légitime d’OpenAI comme canal de commande et de contrôle. Ils ont ainsi contourné les méthodes de détection traditionnelles.
Baptisée SesameOp, cette porte dérobée jusqu’alors inconnue exploite l’API Assistants d’OpenAI pour relayer des commandes et exfiltrer des résultats. Selon les chercheurs de Microsoft, cette campagne était active depuis des mois avant d’être détectée et s’appuyait sur des bibliothèques .NET chargées via l’injection AppDomainManager dans des utilitaires Visual Studio compromis. « Au lieu de s’appuyer sur des méthodes plus traditionnelles, le pirate à l’origine de cette porte dérobée abuse d’OpenAI comme canal C2 afin de communiquer et d’orchestrer discrètement des activités malveillantes au sein de l’environnement compromis », ont déclaré les chercheurs dans un billet de blog. L’exploit ne s’appuie pas sur une vulnérabilité du service d’IA lui-même, mais utilise de manière détournée une API légitime, ce qui complique la tâche des équipes de détection et de défense.
Exploitation de l’API Assistants d’OpenAI
La chaîne d’infection de la porte dérobée commence par l’injection du chargeur « Netapi64.dll » dans un exécutable hôte via l’injection NET AppDomainManager, une méthode furtive utilisée pour échapper aux outils de surveillance conventionnels. Une fois actif, le composant implanté accède à l’API Assistants d’OpenAI à l’aide d’une clé API codée en dur, traitant l’infrastructure Assistants comme une couche de stockage et de relais. « Dans le contexte d’OpenAI, les Assistants font référence à une fonctionnalité de la plateforme du fournisseur qui permet aux développeurs et aux entreprises de créer des agents d’IA personnalisés adaptés à des tâches, des flux de travail ou des domaines spécifiques », ont expliqué les chercheurs. « Ces Assistants sont construits sur les modèles d’OpenAI (comme GPT-4 ou GPT-4.1) et peuvent être étendus avec des capacités supplémentaires. » Le logiciel malveillant récupère les charges utiles de commande intégrées dans les descriptions des « Assistants » (qui peuvent être définies sur des valeurs comme « Sleep », « Payload », « Result »), puis les déchiffre, les décompresse et les exécute localement. Après l’exécution, les résultats sont renvoyés via la même API, un peu comme dans le modèle d’attaque d’exploitation des ressources locales ou LOTL (Living off the land), mais dans un contexte de cloud dédié à l’IA. Les chercheurs ont noté que, comme l’attaquant utilise un service cloud légitime pour les commandes et le contrôle, la détection devient plus difficile. Il n’y a pas de domaine C2, seulement un trafic d’apparence bénigne vers api.openai.com.
Une leçon pour les défenseurs et les fournisseurs de plateformes
Le fournisseur a précisé que la plateforme OpenAI elle-même n’avait pas été piratée ou exploitée, mais que ses fonctions API officielles avaient été détournées pour servir de canal de relais, soulignant ainsi le risque croissant lié à l’intégration de l’IA générative dans les processus opérationnels et de développement des entreprises. Les pirates peuvent désormais détourner les points de terminaison publics de l’IA pour masquer leurs intentions malveillantes, ce qui rend leur détection beaucoup plus difficile. En réponse, Microsoft et OpenAI ont pris des mesures pour désactiver les comptes et les clés liés aux cybercriminels. Les entreprises ont également exhorté les défenseurs à inspecter les journaux à la recherche de requêtes sortantes vers des domaines inattendus comme api.openai.com, en particulier à partir des machines des développeurs.
Selon la firme de Redmond, l’activation de la protection contre la falsification, de la surveillance en temps réel et du mode bloc dans Defender peut faciliter la détection des mouvements latéraux et des modèles d’injection utilisés par SesameOp. « Defender Antivirus détecte cette menace comme « Trojan:MSIL/Sesameop. A (loader) » et « Backdoor: MSIL/Sesameop.A(backdoor) », ont ajouté les chercheurs. Les attaquants continuent de trouver des moyens inventifs pour transformer l’IA en arme. Des révélations récentes ont montré que des agents d’IA autonomes étaient déployés pour automatiser des chaînes d’attaque entières ou que la GenAI servait à accélérer les campagnes de ransomware et que des techniques d’injection rapide étaient utilisées pour enrôler les assistants de codage.
Trois vulnérabilités dans les outils Gemini AI de Google ont exposé Cloud Assist, Search et Browsing à des risques d’injection de prompts mais aussi de manipulation logique et de fuites de données furtives. Elles ont été corrigées.
Les chercheurs en sécurité de Tenable ont révélé trois vulnérabilités distinctes dans les composants Cloud Assist, Search Optimization et Browsing de Gemini. Si elles sont exploitées, ces failles permettent aux attaquants d’injecter des prompts, de détourner la logique de l’IA et de siphonner discrètement les données privées des utilisateurs, en contournant même bon nombre des mesures de sécurité intégrées de Google. L’ensemble de ces failles a été baptisé Gemini Trifecta. « Gemini Trifecta de Tenable confirme que les agents eux-mêmes deviennent des vecteurs d’attaque lorsqu’ils se voient accorder trop d’autonomie sans garde-fous suffisants. Le schéma est clair : les journaux, les historiques de recherche et les outils de navigation sont tous des surfaces d’attaque actives », a déclaré Itay Ravia, directeur d’Aim Labs, l’équipe de cybersécurité qui a été la première à documenter une attaque similaire de type zero clic appelée EchoLeak sur Microsoft 365 Copilot. Google a depuis corrigé le problème, mais les chercheurs ont souligné que cet épisode était un signal d’alarme pour l’ère de l’IA.
D’autres services cloud de Google potentiellement vulnérables
La fonctionnalité Gemini Cloud Assist aide les utilisateurs à résumer et à interpréter les journaux cloud (en particulier dans Google Cloud). Tenable a découvert que ce service pouvait être abusé par un attaquant afin d’intégrer du contenu spécialement formaté, par exemple, via un en-tête HTTP User-Agent manipulé, dans un journal. Le contenu modifié est ensuite intégré dans les journaux, que Gemini ingère et résume par la suite. Dans un PoC partagé dans un billet de blog, les chercheurs ont envoyé des fragments de prompts malveillants via le champ User Agent à un point de terminaison Cloud Function. Lorsque Gemini a ensuite « expliqué » l’entrée du journal, celle-ci comprenait un lien prêt à être utilisé pour le phishing, dérivé de l’entrée manipulée, bien que le prompt complet ait été masqué derrière une section « Détails supplémentaires sur l’invite » réduite. « Comme les journaux sont omniprésents et souvent considérés comme des artefacts passifs, cette manipulation transforme pratiquement tous les points de terminaison cloud accessibles au public en une surface d’attaque », ont mis en garde les chercheurs. De plus, le blog indique que plusieurs autres services Google Cloud, notamment Functions, Run, App Engine, Load Balancing, etc., pourraient être tout autant exploités de manière abusive si les journaux étaient utilisés dans le cadre d’un résumé assisté par l’IA.
Le deuxième vecteur exploite la personnalisation de la recherche de Gemini. Comme le module de recherche Search de Gemini utilise les requêtes passées d’un utilisateur comme contexte, un attaquant pourrait utiliser des astuces JavaScript pour insérer des « requêtes de recherche » malveillantes dans l’historique du navigateur d’un utilisateur. Lorsque Gemini lit cet historique comme contexte, il traite ces invites injectées comme des entrées légitimes. « Le problème sous-jacent était l’incapacité du modèle à faire la différence entre les requêtes légitimes des utilisateurs et les invites injectées provenant de sources externes », ont ajouté les chercheurs. « L’astuce JavaScript permettant d’injecter l’historique de recherche des victimes consistait à bloquer la redirection vers l’API Search de Google, tout en attendant suffisamment longtemps pour qu’elle soit enregistrée dans l’historique de recherche sans pour autant rediriger la page. »
Des moyens de protection mis en place
Même après l’injection de prompt, l’attaquant a besoin d’un moyen d’extraire les données, et c’est ce que permettait la troisième faille affectant l’outil de navigation Browsing Tool de Gemini. Les chercheurs de Tenable ont conçu des invites pour inciter Gemini à récupérer du contenu web externe à l’aide du Browsing Tool, en intégrant les données de l’utilisateur dans la chaîne de requête de cette demande. L’appel HTTP sortant a ainsi transmis les données sensibles de l’utilisateur à un serveur contrôlé par l’attaquant, sans recourir à des liens visibles ou à des astuces de balisage. Cette découverte est remarquable, car Google dispose déjà de mesures d’atténuation comme la suppression du rendu des hyperliens ou le filtrage des balises d’images. L’attaque a contourné ces défenses au niveau de l’interface utilisateur en utilisant l’invocation de l’outil de navigation de Google comme canal d’exfiltration.
Même si Google n’a pas immédiatement répondu à une demande de commentaires, Tenable a déclaré que le géant du cloud avait corrigé tous ces problèmes en nettoyant les sorties de liens dans le Browsing Tool et en mettant en place des protections plus structurelles dans Gemini Cloud Assist et Search. Les attaques par injection d’invites existent depuis l’apparition de l’IA, tout comme d’autres méthodes sophistiquées visant à subvertir ces modèles intelligents, notamment EchoChamber, EchoLeak et Crescendo. « Ces faiblesses sont intrinsèques à la manière de concevoir les agents actuels, et nous continuerons à les voir réapparaître sur différentes plateformes jusqu’à ce que des protections d’exécution soient largement déployées », a fait remarquer M. Ravia.
Avec Data Intelligence for Cybersecurity, Databricks propose une plateforme qui unifie les données de sécurité fragmentées et alimente des agents d’IA contre les attaques automatisées pour répondre plus rapidement aux menaces.
Avec le lancement de Data Intelligence for Cybersecurity, le spécialiste en data store cherche à se tailler une place plus importante dans le domaine de la cybersécurité. L’outil s’intègre directement aux piles de sécurité existantes, offrant aux équipes une base unique et contrôlée pour détecter les menaces plus tôt et réagir plus rapidement. « Avec Data Intelligence for Cybersecurity, Databricks combine données et IA afin d’offrir aux entreprises la stratégie de…
Il vous reste 90% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Avec Data Intelligence for Cybersecurity, Databricks propose une plateforme qui unifie les données de sécurité fragmentées et alimente des agents d’IA contre les attaques automatisées pour répondre plus rapidement aux menaces.
Avec le lancement de Data Intelligence for Cybersecurity, le spécialiste en data store cherche à se tailler une place plus importante dans le domaine de la cybersécurité. L’outil s’intègre directement aux piles de sécurité existantes, offrant aux équipes une base unique et contrôlée pour détecter les menaces plus tôt et réagir plus rapidement. « Avec Data Intelligence for Cybersecurity, Databricks combine données et IA afin d’offrir aux entreprises la stratégie de…
Il vous reste 90% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Pensant télécharger postmark-mcp, un serveur de messagerie Postmark basé sur model context protocol, de nombreux utilisateurs ont été bernés par un paquet npm malveillant. 500 entreprises ont été touchées et plusieurs milliers d’e-mails ont fuité.
Dans une attaque supply chain révélée récemment, un paquet npm « postmark-mcp » a été utilisé pour exfiltrer discrètement des courriels. Cette première utilisation abusive signalée remet en cause la confiance des utilisateurs et pointe l’insuffisance des garde-fous autour du protocole de connecteur d’IA MCP très médiatisé. Le paquet malveillant, téléchargé 1 500 fois par semaine sur le très populaire registre de paquets node.js, se faisait passer pour une version du véritable serveur MCP (Model Context Protocol) afin d’intégrer Postmark, un service de messagerie transactionnelle appartenant à ActiveCampaign, dans des assistants d’IA. « Depuis la version 1.0.16, postmark-mcp copie discrètement tous les courriels sur le serveur personnel du développeur », a écrit Idan Dardikman de Koi Security dans un billet de blog. « Je parle de réinitialisations de mots de passe, de factures, de notes de service internes, de documents confidentiels, de tout. » Selon M. Dardikman, pendant les quinze versions précédentes, postmark-mcp fonctionnait comme un outil légitime, auquel les développeurs faisaient confiance pour intégrer des assistants d’IA aux flux de travail de messagerie électronique. Puis, avec l’ajout d’une simple ligne de code, il a discrètement introduit la porte dérobée.
Un backdoor caché dans un champ Bcc:
Le moteur de risque de Koi a signalé un comportement suspect dans la version 1.0.16, ce qui a conduit ses chercheurs à découvrir une insertion cachée dans le champ Bcc:. L’attaquant avait copié le code source officiel (ActiveCampaign) MCP, puis injecté une seule ligne de duplication de courriels au cœur du code. Une fois la version publiée, chaque fois que l’outil envoyait un e-mail, il transférait également en silence une copie à tophan@giftshop.club, un domaine lié à l’attaquant. Même nom, même fonction, juste une porte dérobée ajoutée. « La porte dérobée postmark-mcp n’est pas sophistiquée, elle est d’une simplicité confondante », a ajouté M. Dardikman. « Mais elle démontre parfaitement à quel point toute cette configuration est complètement défaillante. Un développeur. Une ligne de code. Des milliers et des milliers de courriels volés. » Selon son estimation « prudente », l’accès non autorisé a concerné environ 3 000 à 15 000 courriels par entreprise et par jour, et touché 500 entreprises au total. Les courriels contenaient probablement un ensemble de données commerciales sensibles, notamment des réinitialisations de mots de passe, des factures, des notes de service internes et d’autres correspondances privées. Comme la modification malveillante était minime et presque indétectable dans le cadre d’une utilisation normale, elle aurait pu perdurer très longtemps.
Des risques persistants, même après la suppression du paquet
Les chercheurs en sécurité de Koi n’ont pas reçu de réponse lorsqu’ils ont contacté le développeur (l’attaquant) de la version 1.0.16 pour avoir des éclaircissements sur l’ajout de « Bcc: ». Au lieu de cela, ils ont remarqué que le paquet avait été rapidement supprimé, avant même qu’ils aient pu le signaler à npm. Cependant, la suppression du paquet ne le supprimera pas des machines sur lesquelles il est déjà installé. Même si l’on ne sait pas exactement combien de développeurs ont téléchargé cette version, chacun des « 1 500 téléchargements hebdomadaires en moyenne » est compromis, ce qui a probablement motivé le retrait rapide du paquet par le pirate. Pour limiter les dégâts, Koi recommande la suppression immédiate de postmark-mcp (version 1.0.16), une modification des identifiants qui auraient pu être divulgués par e-mail et des audits approfondis de tous les MCP utilisés. « Ces serveurs MCP fonctionnent avec les mêmes privilèges que les assistants d’IA eux-mêmes (accès complet aux courriels, connexions aux bases de données, autorisations API), mais ils n’apparaissent dans aucun inventaire d’actifs, échappent aux évaluations des risques des fournisseurs et contournent tous les contrôles de sécurité, du DLP aux passerelles de messagerie », a ajouté M. Dardikman. « Lorsque quelqu’un se rend compte que son assistant d’IA envoie discrètement des courriels en copie cachée à un serveur externe depuis des mois, les dégâts sont déjà catastrophiques. » Les professionnels de la sécurité se montrent très réservés à l’égard du MCP depuis son introduction par Anthropic. Au fil du temps, le protocole a rencontré plusieurs obstacles, des fournisseurs tels qu’Anthropic et Asana ayant signalé des failles critiques dans leurs implémentations MCP.
Les recherches de SquareX sur les attaques LMR (Last Mile Reassembly), que l’entreprise de cybersécurité a dévoilées lors de la DEF CON 32, ont enfin reçu la validation qu’elles attendaient. C’est une reconnaissance des risques liés aux malwares trompant les navigateurs.
Après plus d’un an d’alertes, Palo Alto Networks est le premier fournisseur SASE à reconnaître publiquement que les passerelles web sécurisées Secure Web Gateways (SWG) ne peuvent pas arrêter les attaques malveillantes évasives basées sur les navigateurs. Dans un article de blog partagé avant sa publication la semaine dernière, SquareX a défini les attaques LMR (Last Mile Reassembly) comme des techniques qui exploitent les limites des SWG pour faire passer des logiciels malveillants à travers les contrôles, afin de les réassembler à l’intérieur du navigateur sous forme de logiciels malveillants fonctionnels. Début septembre, sans nommer explicitement les attaques LMR comme cas d’usage cibles, Palo Alto Networks a annoncé des fonctionnalités pour contenir les « attaques évasives qui s’assemblent à l’intérieur du navigateur » capables de contourner les protections SWG. « Admettre cela publiquement serait très préjudiciable à leur activité de fournisseur SASE/SSE, d’autant que beaucoup d’entre eux ont des accords de niveau de service (SLA) qui promette une protection à 100 % contre les malwares connus », a expliqué Audrey Adeline de SquareX. « Selon nous, Palo Alto Networks constate que de plus en plus de clients sont victimes d’attaques utilisant des techniques LMR, ce qui est typique des fournisseurs historiques qui sont largement poussés par la forte demande des clients. »
Les défenses par proxy, inefficaces au niveau du navigateur
Les attaques LMR ne sont pas une technique unique, mais un ensemble de plus de 20 contournements qui exploitent des angles morts négligés. Dans l’une des méthodes, le logiciel malveillant est divisé en plusieurs morceaux qui échappent à l’inspection du proxy avant d’être réassemblés en une charge utile opérationnelle une fois à l’intérieur du navigateur de la victime. D’autres variantes utilisent des canaux binaires non surveillés tels que WebRTC ou gRPC, les mêmes canaux qui alimentent les applications de conférence et les flux de travail dans le cloud. Il en résulte un type d’attaques qui contournent les protections SWG dès leur conception. Selon Mme Adeline, cette vulnérabilité est loin d’être théorique, car SquareX la détecte et protège ses clients contre elle. « Le Last Mile Reassembly (LMR) permet aux attaquants d’introduire clandestinement tout script, site ou fichier malveillant, y compris des sites de phishing et des logiciels malveillants connus, qui contournent complètement les SWG », a-t-elle expliqué. « Une fois à l’intérieur du navigateur, les entreprises sont confrontées à des attaques de vol d’identifiants, d’exfiltration de données et de surveillance qui échappent à tout contrôle de leurs outils existants. »
Les chercheurs de SquareX ont étendu ces conclusions aux attaques dites « Data Splicing Attacks », montrant que les attaquants, voire des initiés, peuvent utiliser des techniques similaires pour exfiltrer des données sensibles. Que ce soit par des opérations de copier-coller ou par des sites de partage de fichiers pair-à-pair, les données échappent aux contrôles traditionnels de prévention des pertes de données (DLP) sans être détectées. Selon Mme Adeline, il est difficile de sécuriser des canaux tels que WebRTC et gRPC avec les outils SASE ou SSE traditionnels, qui manquent de visibilité au niveau du navigateur et obligent souvent les entreprises à les bloquer complètement. « La sécurité native du navigateur peut protéger ces canaux au « dernier kilomètre » dans le navigateur en bloquant les téléchargements malveillants, en inspectant les sites de phishing ou les scripts malveillants en temps réel », a-t-elle ajouté.
Palo Alto Networks, premier à briser le silence
Alors que SquareX a directement divulgué la vulnérabilité LMR à tous les principaux fournisseurs, Palo Alto Networks est le premier à la confirmer publiquement. Cette confirmation a pris la forme d’une annonce faite le 4 septembre, dans laquelle Palo Alto Networks a dévoilé les fonctionnalités ajoutées à son navigateur Prisma. Dans cette annonce, le fournisseur a reconnu que Prisma avait été mis à niveau « afin d’intercepter et de neutraliser les attaques cryptées et évasives qui s’assemblent à l’intérieur du navigateur et contournent les passerelles web sécurisées traditionnelles ». Avec cette annonce, l’entreprise a admis les lacunes architecturales des SWG dans la gestion de ces attaques. « Palo Alto Networks est le premier fournisseur SASE/SSE à reconnaître que l’évolution vers les menaces natives des navigateurs et la nécessité d’une sécurité native des navigateurs sont inévitables (d’où son acquisition de Talon pour 625 millions de dollars), mais nous pensons que d’autres fournisseurs SASE/SSE suivront le mouvement », a affirmé Mme Adeline. « Même si cela cannibalise leur activité lucrative actuelle, le navigateur étant le nouveau point d’accès, ils devront bientôt créer, acquérir ou s’associer à une entreprise de sécurité des navigateurs pour rester dans la course », a-t-elle avancé. On ne sait pas si les améliorations apportées au navigateur Prisma visent spécifiquement les attaques LMR, mais la description fournie par l’entreprise correspond étroitement à la définition du LMR donnée par SquareX. Palo Alto Networks n’a pas immédiatement répondu à une demande de commentaires.
Une attaque nommée GhostAction a visé GitHub Actions. Des pirates sont parvenus à détourner des identifiants et et voler 3 325 secrets provenant de centaines de référentiels npm et PyPI.
Dans une vaste attaque de type supply chain contre Github Actions, des pirates sont parvenus à dérober 3 325 secrets à 327 utilisateurs dans 817 référentiels. Les workflows qui ont été visés sont des processus automatisés définis dans un référentiel GitHub répondant à des événements spécifiques. « Les chercheurs en sécurité de GitGuardian ont été alertés en interne de la compromission potentielle d’un référentiel GitHub associé au projet FastUUID », ont déclaré Gaetan Ferry et Guillaume Valadon, chercheurs en sécurité chez l’éditeur, dans un article de blog. « Les investigations ont révélé qu’un fichier de workflow GitHub malveillant avait été injecté dans le projet ». L’utilisateur compromis a poussé des commits malveillants identiques vers d’autres référentiels publics et privés. Des identifiants PyPI, npm, DockerHub ont été volés ainsi que des jetons GitHub et bien d’autres encore. Ils ont été transmis via des requêtes HTTP POST à un point de terminaison contrôlé par l’acteur. La campagne a été détectée et contenue le 5 septembre.
Des jetons CI/CD interceptés
La campagne GhostAction concerne le projet Python FastUUID dans lequel un contributeur identifié par le pseudonyme « Grommash9 » a introduit une modification du workflow le 2 septembre. La modification contenait un code qui extrayait des jetons sensibles, tels que le PYPI_API_TOKEN, et les transmettait via des requêtes HTTP POST à un domaine contrôlé par l’attaquant. « Même si ce jeton aurait dû permettre à l’acteur de compromettre le paquet FastUUID sur PyPI, aucune preuve de publication de paquets malveillants n’a été trouvé pendant la période de compromission », ont déclaré les chercheurs, ajoutant que l’inaction de l’attaquant après la compromission initiale suggérait que FastUUID n’était pas la cible principale.
Dans un deuxième temps, les enquêteurs ont découvert des workflows malveillants similaires dans cinq référentiels publics au moins et une dizaine de référentiels privés. L’attaque était très adaptative, ciblant des secrets spécifiques à l’environnement, depuis des identifiants de registre de conteneurs jusqu’aux clés des fournisseurs de cloud. « Le modèle d’attaque est resté le même pour tous les projets. Le pirate a d’abord répertorié les secrets provenant de fichiers de workflows légitimes, puis a codé en dur ces noms secrets dans des workflows malveillants », ont ajouté les chercheurs. GhostAction a exfiltré des milliers de jetons sensibles qui auraient pu être utilisés pour altérer des paquets, accéder sans autorisation à des infrastructures ou compromettre davantage la chaîne d’approvisionnement.
Une menace maîtrisée en quelques jours
L’équipe de sécurité de GitGuardian a réagi rapidement après la détection, et le paquet FastUUID a été verrouillé en lecture seule par les administrateurs PyPI en quelques minutes. Le commit frauduleux a été annulé peu après. GitGuardian a averti les responsables des dépôts concernés, contactant avec succès 573 projets, tout en alertant les équipes de sécurité de GitHub, npm et PyPI afin qu’elles surveillent les abus. Même si aucun paquet malveillant n’avait encore été publié dans les registres officiels, GitGuardian a signalé que certains paquets étaient potentiellement toujours exposés à des risques. « D’après nos premières investigations, 9 paquets npm et 15 paquets PyPI risquent d’être compromis dans les prochaines heures ou les prochains jours », ont mis en garde les chercheurs. Ces derniers ont publié sur le blog une liste d’indicateurs de compromission, notamment des indicateurs réseau et GitHub Workflow. Pour une protection supplémentaire, ils ont insisté sur l’importance de revoir les workflows des référentiels, de modifier les identifiants exposés et d’adopter des contrôles plus stricts pour GitHub Actions afin d’éviter que des incidents similaires ne se reproduisent à l’avenir.
Les écosystèmes de paquets tels que npm et PyPI restent des cibles fréquentes en raison de leur popularité et de leur large portée au sein de la communauté des développeurs. Au-delà de la publication directe de paquets malveillants, comme la récente campagne de reconnaissance npm, les attaquants ont également utilisé des techniques telles que le typosquatting (qui exploite les fautes de frappe et d’orthographe) ou même l’exploitation de dépendances hallucinées par l’IA pour inciter les développeurs à installer du code compromis.
Une étude menée par Netcraft montre que les URL de marque générées par l’IA sont souvent erronées et pointent parfois vers des sites d’hameçonnage. Les experts préconisent des garde-fous pour valider les domaines.
Les grands modèles de langage (LLM) envoient régulièrement les utilisateurs vers de mauvaises adresses web, y compris des sites non enregistrés, inactifs, voire malveillants, lorsqu’on leur demande où se connecter pour accéder à un contenu de marque spécifique. Dans une dernière étude de Netcraft, les chercheurs ont constaté que lorsqu’ils demandaient à un LLM populaire où se connecter à des marques connues, 34 % des URL qu’ils renvoyaient n’appartenaient pas à ces marques. Pire encore, l’un des liens menait directement à un site de phishing actif. « Cette étude montre à quel point il est important d’être vigilant face aux pirates qui imitent les URL de marques bien connues pour accéder à des informations sensibles et/ou à des comptes bancaires », a déclaré Melinda Marks, analyste principale à l’Enterprise Strategy Group (ESG). « Les entreprises, en particulier les grandes marques établies, devraient protéger leur réputation en communiquant avec leurs clients sur les URL auxquelles ils peuvent faire confiance pour les communications importantes et les transactions sécurisées », a-t-elle ajouté.
La recherche souligne que près de 30 % des URL frauduleuses n’étaient pas enregistrées ou actives, ce qui en fait un terrain de choix pour les acteurs de la menace qui cherchent à créer des sites malveillants. « Les prompts utilisés n’étaient même pas obscurs et reflétaient simplement la façon dont les gens demandent naturellement de l’aide en ligne », a fait remarquer Bilal Rashid, analyste chez Netcraft, ajoutant que le risque est systémique, évolutif et déjà présent dans la nature.
Les plus petites marques davantage frappées par les hallucinations
5 % de ces URL conduisaient à des entreprises sans aucun rapport avec le sujet et, plus troublant encore, l’une d’entre elles renvoyait à un domaine d’hameçonnage. Perplexity, le moteur de recherche alimenté par l’IA, a recommandé une page Google Sites « hxxps://sites[.]google[.]com/view/wells-fargologins/home », qui se faisait passer pour la page de connexion de la Wells Fargo avec un clone convaincant du site réel. « L’URL est apparue directement parce que l’IA pensait qu’elle était à sa place », ont indiqué les chercheurs de Netcraft dans un billet de blog, expliquant ce qui se passe lorsque l’IA donne une mauvaise URL. « Ce sont des conditions parfaites pour les cybercriminels », a déclaré J Stephen Kowski, Field CTO chez SlashNext. « Lorsque les modèles d’IA créent des URL qui pointent vers des domaines non enregistrés, les attaquants peuvent simplement enregistrer ces domaines exacts et attendre que les victimes arrivent ». Pour M. Kowski, cela revient à donner aux attaquants une feuille de route pour leurs futures victimes. « Un seul lien malveillant recommandé peut compromettre des milliers de personnes qui seraient normalement plus prudentes ».
Les conclusions de l’étude Netcraft sont particulièrement préoccupantes, car les marques nationales, principalement dans le domaine de la finance et de la fintech, se sont révélées parmi les plus touchées. Les coopératives de crédit, les banques régionales et les plateformes de taille moyenne s’en sortent moins bien que les géants mondiaux. Les plus petites marques, qui ont moins de chance d’apparaître dans les données de formation des LLM, ont été fortement hallucinées. « Les LLM ne récupèrent pas l’information, ils la génèrent », a expliqué Nicole Carignan, RSSI chez Darktrace. « Et lorsque les utilisateurs considèrent ces résultats comme des faits, ils ouvrent la porte à une exploitation massive ». Mme Carignan souligne également un défaut structurel sous-jacent : selon elle, les modèles sont conçus pour être utiles, pas pour être précis, et à moins que les réponses de l’IA ne soient fondées sur des données validées, elles continueront à inventer des URL, souvent avec des conséquences dangereuses. Les chercheurs ont souligné que l’enregistrement préalable de tous les domaines hallucinés, une solution apparemment viable, ne fonctionnera pas car les variations sont infinies et les LLM en inventeront toujours de nouveaux, ce qui entraînera des attaques dites de Slopsquatting.
GitHub alimenté en dépôts de codes malveillants
Les URL hallucinées ne sont pas toutes involontaires. Dans le cadre d’une recherche sans rapport avec le sujet, Netcraft a trouvé des preuves que des attaquants avaient délibérément empoisonné des systèmes d’IA en alimentant GitHub avec des dépôts de codes malveillants. « Plusieurs faux comptes GitHub partageaient un projet appelé Moonshot-Volume-Bot et étaient répartis sur des comptes dotés de biographies riches, d’images de profil, de comptes de médias sociaux et d’activités de codage crédibles », ont déclaré les chercheurs. « Il ne s’agissait pas de comptes jetables, mais de comptes conçus pour être indexés par des pipelines d’entraînement à l’IA ».
Le projet Moonshot impliquait une API blockchain Solana contrefaite qui réacheminait les fonds directement dans le portefeuille de l’attaquant. « La compromission des corpus de données utilisés dans le pipeline d’entraînement à l’IA met en évidence un risque croissant pour la chaîne d’approvisionnement de l’IA », a déclaré Mme Carignan. « Il ne s’agit pas d’une simple hallucination, mais d’une manipulation ciblée. L’intégrité, l’approvisionnement, le nettoyage et la vérification des données sont essentiels pour garantir la sécurité des résultats du LLM. » Alors que les chercheurs ont recommandé des solutions réactives comme la surveillance et le démantèlement pour s’attaquer au problème, Gal Moyal, Office CTO chez Noma Security, a suggéré une approche plus proactive. « Les garde-fous de l’IA devraient valider la propriété du domaine avant de recommander l’ouverture d’une session », a-t-il préconisé. « Il ne faut pas laisser les modèles « deviner » les URL. Chaque requête contenant une URL doit être vérifiée.
L’entreprise de cybersécurité QiAnXin a établi un lien entre le groupe APT NightEagle basé en Amérique du Nord et l’espionnage à long terme d’industries chinoises de l’IA, des semi-conducteurs et de l’armée, grâce à une faille Exchange zero day.
Inconnu jusque-là, le groupe APT (Advanced Persistent Threat) NightEagle a été découvert en train de cibler le gouvernement chinois et des secteurs critiques via l’exploitation d’une faille zero day non identifiée de Microsoft Exchange. Selon RedDrip, l’unité de renseignement sur les menaces de l’entreprise de cybersécurité chinoise QiAnXin Technology à l’origine de la découverte, le groupe malveillant a compromis les serveurs Microsoft Exchange par le biais d’une chaîne d’exploitation sophistiquée de type zero day pour voler des données confidentielles de boîtes aux lettres.
« Depuis 2023, QianXin suit en permanence un groupe APT de premier plan qui détient une chaîne d’exploitation de vulnérabilité Exchange inconnue et dispose d’un fonds substantiel pour acheter un grand nombre d’actifs réseau, notamment des serveurs dédiés virtuel (Virtual Private Server, VPS) et des noms de domaine », ont déclaré les chercheurs de RedDrip dans un rapport. « Ce groupe a longtemps ciblé des entreprises et des institutions chinoises de premier plan dans les domaines de la haute technologie, des semi-conducteurs, de la technologie quantique, de l’intelligence artificielle, des grands modèles de langage, de l’industrie militaire et d’autres domaines. » Les chercheurs ont baptisé le groupe NightEagle en raison de la rapidité de ses opérations et de son activité constante pendant les heures nocturnes.
Une faille zero day Exchange qui noyaute IIS
Selon l’enquête de RedDrip, NighEagle exploite un trou de sécurité zero day non identifié dans Microsoft Exchange pour récolter la machineKey, ce qui permet une désérialisation non autorisée et un accès shell de base. Les attaquants peuvent ainsi implanter un chargeur .NET dans l’Internet Information Service (IIS) de Microsoft et accéder par la suite à la boîte aux lettres à distance. « Après une analyse complète des activités d’attaque du groupe NightEagle, nous avons pu voir qu’il disposait d’un ensemble complet d’armes inconnues de la chaîne d’exploitation des vulnérabilités Exchange », ont expliqué les chercheurs. « Cependant, à l’heure actuelle, nous avons seulement connaissance du processus par lequel les attaquants obtiennent la clé et volent ensuite les données Exchange, mais leurs moyens nous sont inconnus ».
La machineKey est cruciale dans les applications .NET et ASP.NET comme Exchange, car elle est utilisée pour signer et valider les jetons d’authentification, les cookies et les données cryptées. Une fois la machineKey obtenue, les attaquants ont envoyé une charge utile élaborée qui, lorsqu’elle est désérialisée par le serveur Exchange, conduit à l’exécution de code à distance (remote code execution, RCE). Celle-ci visait principalement à accéder au contenu de la boîte aux lettres et à l’exfiltrer, y compris éventuellement des pièces jointes, des communications internes et de la correspondance commerciale sensible. Les demandes de commentaires envoyées à Microsoft sur l’exploit zero day présumé sont restées sans réponse.
Une tentative de persistance dans la furtivité
Après avoir exploité avec succès cette zero day, les attaquants ont déployé une version Go modifiée de Chisel, un outil de tunneling SOCKS open oource, en programmant son exécution toutes les quatre heures et en établissant des tunnels secrets vers leurs serveurs C2. Ils peuvent ainsi entrer et sortir du réseau quand ils le souhaitent, ce qui leur permet de persister pendant plus d’un an, même après que les infections initiales ont été nettoyées.
« Nous avons découvert, grâce à l’heure de dépôt du logiciel malveillant Chisel et à la durée du trafic d’attaque enregistrée par l’EDR, que l’attaque avait lieu entre 21 heures et 6 heures du matin, heure de Pékin », ont encore expliqué les chercheurs. « Les horaires de travail de ce groupe étaient très fixes, et ils n’ont jamais fait d’heures supplémentaires ni volé de données après les heures de travail. D’après l’analyse du fuseau horaire, nous pensons que le groupe est localisé dans un pays d’Amérique du Nord », ont-ils précisé. « L’enregistrement de domaines par le groupe suggère que les cibles de NightEagle changent en fonction des développements géopolitiques, comme le lancement d’attaques sur des secteurs chinois utilisant de grands modèles d’IA à mesure que les marchés de l’IA du pays se développent », ont indiqué les chercheurs.
Présents dans des versions limitées de Cisco Unified Communications Manager, des identifiants racine codés en dur pourraient permettre à des attaquants de prendre le contrôle total des systèmes de communication de l’entreprise.
Cisco a corrigé une faille de gravité maximale dans ses produits Unified Communications Manager (Unified CM) et Session Management Edition (Unified CM SME) qui pourrait permettre à des attaquants d’entrer directement dans le système en utilisant un login root codé en dur. Selon le géant des communications d’entreprise, ces identifiants statiques uniquement destinés à un usage interne ont été laissés par erreur dans une série de versions logicielles distribuées à quelques clients via des canaux de support officiels. « Cette vulnérabilité est due à la présence d’informations d’identification statiques pour le compte root normalement réservées à une utilisation pendant le développement », a déclaré Cisco dans un avis de sécurité. « Une exploitation réussie pourrait permettre à l’attaquant de se connecter au système concerné et d’exécuter des commandes arbitraires en tant qu’utilisateur root ». Même si le problème est limité à un lot de versions Engineering Special (ES), il n’y a aucun moyen d’atténuer la faille sans appliquer un correctif. Cisco a publié un correctif et recommande vivement à ses clients de procéder immédiatement à une mise à niveau.
Possibilité d’accès root avec une sévérité maximale
La faille référencée CVE-2025-20309 est liée à une erreur de codage. Le compte utilisateur root sur les versions Engineering Special vulnérables était préchargé avec des identifiants de connexion SSH (Secure Shell) par défaut qui ne pouvaient être ni modifiés ni supprimés. Toute personne connaissant ces identifiants (ou faisant de l’ingénierie inverse) peut les utiliser pour accéder à distance au système avec tous les privilèges d’administration, si bien que la faille a été affectée du score CVSS 10 sur 10, soit le niveau de gravité le plus élevé. Les informations d’identification, initialement destinées à des fins de développement uniquement, ont été livrées par inadvertance dans certaines versions ES de Unified CM 15.0.1, en particulier les versions 13010-1 à 13017-1. Ces versions ont été distribuées par le centre d’assistance technique Technical Assistance Center de Cisco et n’étaient pas largement disponibles, ce qui a limité l’exposition, mais pas la gravité. Les produits concernés – Cisco Unified CM et Unified CM SME – sont des composants essentiels de l’infrastructure de téléphonie d’entreprise, largement déployés dans les agences gouvernementales, les institutions financières et les grandes entreprises pour gérer la voix, la vidéo et la messagerie à grande échelle. En exploitant cette faille, des attaquants pourraient compromettre les communications d’une organisation. Ils pourraient notamment se connecter à distance avec des droits d’administration complets pour intercepter les appels, installer des portes dérobées et perturber les services critiques.
Des astuces pour repérer l’exploitation
Selon l’avis de Cisco, il n’y a aucune exploitation de la faille dans la nature, mais l’entreprise a indiqué une méthode pour détecter les compromissions. Les connexions réussies via le compte root laisseraient des traces dans les journaux système situés dans « /var/log/active/syslog/secure ». L’avis inclut même un exemple d’extrait de journal pour montrer à quoi pourrait ressembler la session SSH d’un attaquant. L’entreprise a déclaré que l’exploit ne nécessitait aucune configuration de l’appareil et qu’il n’existait aucune solution pour atténuer le risque, hormis la mise à niveau. Les clients sans contrat de service peuvent toujours demander la correction, à condition de communiquer le numéro de série de leur appareil et un lien vers l’avis. Cette faille, découverte lors d’un test de sécurité interne, est le deuxième bogue de gravité maximale signalé par Cisco en l’espace d’une semaine, le premier étant une faille de validation d’entrée insuffisante affectant les plateformes d’identité et de contrôle d’accès de Cisco, permettant une exécution de code à distance ou RCE (Remote Code Execution) en tant qu’utilisateur root.