Une extension Visual Studio Code rudimentaire mais capable de chiffrer des fichiers et de voler des données a réussi à contourner les contrôles de Microsoft sur sa place de marché VSCode pour développeurs.
La marketplace VSCode de Microsoft est-elle sécurisée ? La question se pose après la découverte d’une étrange extension pour l’éditeur de code open source adoptant un comportement proche de celui d’un ransomware. Elle a pu être publiée sans aucun problème et le ou les auteurs n’ont pas été identifiés. Selon les conclusions de Secure Annex, société spécialisée dans la sécurité des extensions qui a mené l’enquête, ce code malveillant publié sur la place de marché était clairement codé sans être très élaboré. « Il ne s’agit pas d’un exemple sophistiqué, car le code du serveur de commande et de contrôle a été accidentellement (?) inclus dans le package de l’extension publiée, avec des outils de décryptage », a déclaré John Tuckner fondateur de Secure Annex, ajoutant que l’extension comprenait une description « manifestement malveillante » sur la boutique. Malgré les signaux d’alerte évidents, le code a échappé aux filtres de vérification de Microsoft et reste disponible même après avoir été signalé, a déclaré M. Tuckner. Le code malveillant comprend des fonctionnalités de chiffrement et de vol de fichiers.
Selon le dirigeant, l’extension nommée susvsex (pour suspicious VSX) et publiée sous le pseudonyme tout aussi révélateur « Suspicious publisher » cache sa charge utile à la vue de tous. Visible sous le nom « suspublisher18.susvsex », elle comprend un fichier « package.json » qui s’active automatiquement à chaque événement, même pendant l’installation, tout en offrant une palette d’utilitaires pour « tester les fonctions de commande et de contrôle ». À l’intérieur du point d’entrée « extension.js », les chercheurs ont trouvé des variables codées en dur, notamment l’URL du serveur, les clés de chiffrement, les destinations C2 et les intervalles d’interrogation. La plupart de ces variables comportent des commentaires indiquant que le code a été généré par l’IA. Une fois déclenchée, l’extension lance la compression et le chiffrement des fichiers contenus dans un répertoire désigné, puis les télécharge vers un serveur de commande distant. M. Tucker a noté que le répertoire cible était configuré à des fins de test, mais qu’il pouvait facilement être remplacé par un véritable chemin d’accès au système de fichiers lors d’une future mise à jour ou par commande à distance. L’extension contenait deux décrypteurs, l’un en Python et l’autre en Node, ainsi qu’une clé de décryptage codée en dur, éliminant ainsi toute possibilité d’intention malveillante.
L’extension a pointé vers un C2 basé sur GitHub
Les chercheurs en sécurité de Secure Annex ont identifié une infrastructure de commande et de contrôle (C2) assez inhabituelle basée sur GitHub, au lieu de s’appuyer sur des serveurs C2 traditionnels. L’extension utilise un référentiel GitHub privé pour recevoir et exécuter des commandes. Elle vérifie régulièrement les derniers commits dans un fichier nommé « index.html », exécutait les commandes intégrées, puis réécrivait la sortie dans « requirements.txt » à l’aide d’un jeton d’accès personnel GitHub (PAT) intégré à l’extension. Outre le fait de faciliter l’exfiltration des données de l’hôte, ce comportement C2 a exposé l’environnement de l’attaquant, dont les traces ont conduit à un utilisateur GitHub à Bakou, dont le fuseau horaire correspondait aux données système enregistrées par le logiciel malveillant lui-même. La société de sécurité qualifie cela d’exemple type de développement de logiciel malveillant assisté par l’IA, avec des fichiers source mal placés (y compris des outils de décryptage et le code C2 de l’attaquant) et un fichier README.md qui décrit explicitement sa fonctionnalité malveillante. Mais M. Tuckner soutient que la véritable faille réside dans le système d’examen du marché de Microsoft, qui n’a pas signalé l’extension.
Microsoft a déclaré avoir retiré l’extension du marché. Chaque page d’extension du marché contient un lien « Signaler un abus », et la société enquête sur tous les signalements, a-t-elle déclaré ; lorsque la nature malveillante d’une extension est vérifiée, ou lorsqu’une vulnérabilité est détectée dans une dépendance de l’extension, celle-ci est retirée du marché, ajoutée à une liste de blocage et automatiquement désinstallée par VS Code, a-t-elle ajouté. Les entreprises qui souhaitent empêcher l’accès à la boutique peuvent le faire en bloquant des points de terminaison spécifiques, précise l’éditeur. Des incidents récents ont montré que les extensions malveillantes ou négligentes deviennent un problème récurrent dans l’écosystème Visual Studio Code, certaines divulguant des identifiants et d’autres volant discrètement du code ou minant des cryptomonnaies. Outre une liste d’IOC (indices de compromission) partagés, Secure Annex met en avant Extension Manager, un outil conçu pour bloquer les extensions malveillantes connues et inventorier les modules complémentaires installés dans une organisation.
Suite à la compromission de la solution de sauvegarde cloud de SonicWall, des identifiants et données de configuration de pare-feux sont tombés dans les mains de pirates. Huntress a identifié plus de 100 comptes SSL VPN piratés dans plus d’une quinzaine d’entreprises sans toutefois à ce stade établir de lien direct entre ces deux compromissions
Toutes les conséquences de l’incident de sécurité affectant tous les utilisateurs du service de sauvegarde cloud de SonicWALL ne sont pas encore connues. Des dernières investigations de Huntress indiquent que plus de 100 comptes SSL VPN de ce fournisseur dans plus d’une quinzaine d’entreprises ont été compromis sans toutefois établir de lien direct entre ces deux campagnes malveillantes. « Au 10 octobre, Huntress a observé une compromission généralisée de terminaux SSL VPN SonicWall dans plusieurs environnements clients », a expliqué le fournisseur dans un billet de blog. « Les auteurs de ces menaces s’authentifient rapidement sur plusieurs comptes à partir des appareils compromis. La rapidité et l’ampleur de ces attaques suggèrent que les pirates semblent contrôler des identifiants valides plutôt que d’utiliser la force brute. »
SonicWall a averti que l’exploitation de la faille critique dans ses firewalls avait permis à une partie non autorisée d’accéder aux fichiers de sauvegarde de configuration, y compris aux identifiants chiffrés et aux données de configuration. Pour l’heure le fournisseur n’a pas confirmé que les deux incidents sont liés de près ou de loin.
Les pirates se connectent, ils ne s’introduisent pas
La divulgation de SonicWall le 17 septembre dernier concernait une violation de son service de sauvegarde cloud MySonicWall, impliquant un accès non autorisé à des fichiers de configuration. Après avoir indiqué que celle-ci affectait moins de 5 % des clients le fournisseur a finalement indiqué que tous les utilisateurs de sa solution étaient concernés. Depuis le 4 octobre dernier, Huntress a observé des connexions massives aux terminaux SSL VPN de SonicWall à partir d’adresses IP contrôlées par des pirates, dont une notamment tracée à 202.155.8[.]73. De nombreuses sessions de connexion ont été brèves, mais d’autres ont impliqué une reconnaissance plus approfondie du réseau et des tentatives d’accès à des comptes Windows internes, suggérant des tentatives de mouvement latéral.
« Nous n’avons aucune preuve permettant d’établir un lien entre cet avis (de SonicWall) et la récente recrudescence des compromissions que nous avons constatée », a fait remarquer Huntress, ajoutant qu’« il n’existe probablement aucun élément nous permettant de discerner cette activité de notre point de vue ». Même si les auteurs de la menace avaient réussi à décoder les fichiers compromis lors de la violation de septembre, ils auraient vu les identifiants sous forme cryptée, comme l’a noté l’avis de SonicWall. En d’autres termes, ceux qui se connectent actuellement aux terminaux SonicWall n’ont probablement pas obtenu leurs clés à partir de ces fichiers de sauvegarde.
Ce à quoi les défenseurs doivent faire attention
Huntress a souligné que, dans quelques cas, une authentification SSL VPN réussie était suivie d’un trafic de reconnaissance interne ou de tentatives d’accès aux comptes administratifs Windows. De plus, les connexions provenant d’une seule adresse IP publique récurrente peuvent suggérer une campagne coordonnée plutôt qu’une réutilisation aléatoire des identifiants. En plus des mesures décrites dans l’avis de SonicWall, le blog de Huntress proposait des mesures de défense supplémentaires pour les entreprises utilisant des appareils SonicWall. Il exhortait les administrateurs à restreindre les interfaces de gestion à distance, à réinitialiser tous les identifiants et mots de passe, à examiner les journaux SSLVPN à la recherche de signes d’authentifications inhabituelles et à activer l’authentification multifactorielle (MFA) dans la mesure du possible.
Les équipements SonicWall restent une cible récurrente pour les groupes malveillants, qui ont récemment mené des attaques en exploitant des pare-feux mal corrigés. Le groupe de ransomware Akira a exploité des failles connues dans le contrôle d’accès (CVE-2024-40766) des appareils SonicWall. Plus tôt dans l’année, les clients ont également été avertis d’un contournement critique de l’authentification et de portes dérobées de type rootkit ciblant les appareils SonicWall.
Des chercheurs en sécurité ont réussi à exploiter une faille dans Agentforce de Salesforce donnant la capacité à des pirates de dissimuler des commandes malveillantes dans des formulaires pour extraire des données CRM sensibles.
Une vulnérabilité critique récemment découverte dans la plateforme Agentforce de Salesforce pouvant inciter un agent IA à divulguer des données CRM sensibles par le biais d’une injection de prompt a été corrigée. Les chercheurs de Noma Security, qui ont identifié cette faille sous le nom « ForcedLeak », ont expliqué qu’elle pouvait être exploitée par des pirates insérant des instructions malveillantes dans un formulaire client. Si l’éditeur a corrigé le problème après sa divulgation, les chercheurs enjoignent les entreprises à ne pas le sous-estimer.
La méthode d’attaque révélée par Noma était d’une simplicité désarmante. En insérant du texte frauduleux dans le formulaire web-to-lead de Salesforce, couramment utilisé à des fins de prospection marketing, les chercheurs ont découvert qu’un agent IA chargé d’examiner les données de prospection client qui lui sont soumises pouvait être amené à exécuter des prompts malveillants. Le champ de description des formulaires, avec 42 000 caractères autorisés, offrait suffisamment d’espace pour déguiser des charges utiles en demandes commerciales inoffensives. Une fois qu’un employé interagit avec Agentforce, l’agent IA les traite mais exécute en même temps un script camouflé par l’attaquant. Pire encore : la politique de sécurité du contenu de Salesforce incluait un domaine expiré qui figurait toujours sur sa liste blanche. En réenregistrant le domaine pour seulement 5 $, les chercheurs ont pu créer un canal d’exfiltration de données en apparence légitime, transformant une négligence mineure en une faille de sécurité majeure. « L’injection de prompt indirecte est essentiellement de type cross-site scripting, mais au lieu de tromper une base de données, les attaquants utilisent l’IA en ligne pour le faire », explique Andy Bennett, responsable de la sécurité des systèmes d’information chez Apollo Information Systems. « C’est comme un mélange d’attaques scriptées et d’ingénierie sociale. L’innovation est impressionnante et les répercussions sont potentiellement stupéfiantes. »
Une faille corrigée par Salesforce
Noma Security a découvert et rapporté cette faille le 28 juillet 2025 à Salesforce qui l’a prise en considération trois jours plus tard. Le 8 septembre, l’éditeur a annoncé des améliorations de sécurité pour Agentforce et Einstein AI et la vulnérabilité a été rendue publique jeudi dernier. La correction a été faite en appliquant des « listes d’autorisation d’URL fiables ». Bien que la société n’ait pas directement crédité Noma pour cette découverte, elle a inclus une description connexe. « Nos services sous-jacents qui alimentent Agentforce appliqueront la liste blanche d’URL fiables afin de garantir qu’aucun lien malveillant ne soit appelé ou généré par une injection potentielle », a-t-elle alors déclaré. Un porte-parole de Salesforce a déclaré : « Le paysage de la sécurité en matière d’injection reste un domaine complexe et en constante évolution, et nous continuons à investir dans des contrôles de sécurité rigoureux et à travailler en étroite collaboration avec la communauté des chercheurs afin de protéger nos clients lorsque ce type de problèmes survient. »
Alors que Salesforce a réagi plutôt rapidement en proposant un correctif, les experts s’accordent à dire que les agents IA constituent une surface d’attaque fondamentalement plus large. Les vecteurs de compromission des agents combinent à la fois mémoire, capacité de prise de décision et exécution d’outils et peuvent servir à propager très rapidement les attaques. « Il est conseillé de sécuriser les systèmes autour des agents IA utilisés, notamment les API, les formulaires et les middlewares, afin que les injections de prompt soient plus difficiles à exploiter et moins nuisibles en cas de réussite », a fait savoir Chrissa Constantine, architecte senior en solutions de cybersécurité chez Black Duck. Elle a souligné que pour une véritable prévention, il ne suffit pas d’appliquer des correctifs, mais qu’il faut « maintenir la configuration et mettre en place des garde-fous autour de la conception des agents, de la chaîne d’approvisionnement logicielle, des applications web et des tests d’API ».
Considérer les agents IA comme des systèmes de production
Les chercheurs de Noma ont fait écho à cet appel, exhortant les entreprises à traiter les agents IA comme des systèmes de production, en les inventoriant, en validant les connexions sortantes, en nettoyant les entrées avant qu’elles n’atteignent le modèle et en signalant tout accès à des données sensibles ou toute sortie Internet. « Nettoyez les entrées externes avant que l’agent ne les voie », a suggéré Elad Luz, responsable de la recherche chez Oasis Security. « Traitez le texte libre des formulaires de contact comme une entrée non fiable. Utilisez une couche de médiation des entrées pour extraire uniquement les champs attendus, supprimer/neutraliser les instructions, les liens et les balises, et empêcher le modèle d’interpréter le contenu utilisateur comme des commandes (résilience à l’injection de prompt). »
Cette vulnérabilité intervient un peu plus de trois mois après qu’un acteur malveillant ait utilisé l’hameçonnage vocal (vishing), pour compromettre les données organisationnelles des clients de Salesforce pour les extraire.
Des chercheurs en sécurité ont détecté une vulnérabilité dans Entra ID, la solution de gestion des accès basés sur l’identité de Microsoft. La faille a été corrigée mais les entreprises doivent bien s’assurer que d’anciennes configurations héritées ne présentent plus aucun risque.
Des chercheurs en sécurité ont prévenu d’un grave problème de sécurité dans Entra ID (ex Azure Active Directory) de Microsoft servant à assurer le contrôle d’accès basé sur l’identité. Cette vulnérabilité, signalée pour la première fois par le hacker éthique Dirk-jan Mollema, combine deux éléments. D’abord l’impersonnalisation non documentée d’actors tokens, des jetons utilisés par Microsoft dans son backend pour la communication de service à service (S2S). Et aussi une faille critique CVE-2025-55241 dans l’API Azure AD Graph qui ne validait pas correctement l’instance d’origine, permettant ainsi à ces jetons d’être utilisés pour accéder à d’autres instances.
La vulnérabilité donnait la possibilité à des pirates de se faire passer pour n’importe quel utilisateur – y compris un administrateur – sans déclencher d’authentification multifacteurs (MFA), d’accès conditionnel, d’alertes ou traces de connexion. Le vecteur d’attaque concerne les instances hébergées utilisant Entra ID. Selon M. Mollema, l’actor token agit comme un autre utilisateur dans l’instance hébergée lorsqu’il communique avec Exchange Online, SharePoint ou, comme dans le cas présent, Azure AD Graph. Selon une analyse approfondie de l’exploit réalisée par le spécialiste forensics Mitiga, la vulnérabilité est apparue parce que l’API héritée n’a pas validé la source de l’actor token. « Une fois qu’ils se faisaient passer pour un administrateur principal, ils pouvaient créer de nouveaux comptes, s’octroyer des autorisations ou exfiltrer des données sensibles. » Le trou de sécurité a été signalé à la firme de Redmond en juillet dernier qui a confirmé quelques jours plus tard qu’un correctif avait été développé et déployé à l’échelle mondiale sans nécessiter l’intervention des utilisateurs.
Un token pour les gouverner tous
Au cœur de ce problème se trouve une combinaison du mécanisme des jetons actor et d’une API mal configurée. Les jetons actor accordent aux services d’agir au nom des utilisateurs ou d’autres services au sein de l’infrastructure Microsoft. M. Mollema a découvert qu’une API d’Azure AD Graph ne vérifiait pas l’instance d’un jeton actor, ce qui signifie qu’il était possible de créer un jeton dans sa propre instance de test ou à faible privilège et de l’utiliser pour usurper l’identité d’un utilisateur aux privilèges d’administrateur dans un autre instance distincte. Azure AD Graph est une API REST héritée que Microsoft a introduite il y a plusieurs années pour interagir par programmation avec Entra ID.
Selon Mitiga, un jeton d’acteur pouvait être créé à l’aide des valeurs d’identifiant de l’instance et ceux du réseau des utilisateurs cibles, accessibles via des comptes invités, des journaux divulgués ou même par force brute. Une fois créé/demandé, ce token – dont Azure AD Graph ne vérifie pas la source – pouvait ensuite être utilisé pour usurper l’identité d’un administrateur principal. « Cela aurait entrainé une compromission totale de l’instance avec un accès à tous les services utilisant Entra ID pour l’authentification, tels que SharePoint Online et Exchange Online », a révélé M. Mollema dans son billet de blog. « Cela aurait donné également un accès complet à toutes les ressources hébergées dans Azure, car ces ressources sont contrôlées au niveau de l’instance et les administrateurs principaux peuvent s’octroyer des droits sur les abonnements Azure. »
Le correctif est appliqué, mais le risque persiste
Alors que la CVE-2025-55241 avait initialement reçu une note de gravité maximale de 10, Microsoft l’a réévalué le 4 septembre à 8,7. La firme a déployé un correctif à l’échelle mondiale quelques jours après le rapport initial, ajoutant que sa télémétrie interne n’avait révélé aucune preuve d’exploitation jusqu’à ce moment-là. Le correctif a empêché la demande de jetons actor pour les appels API Azure AD Graph et a introduit des mesures d’atténuation supplémentaires pour empêcher toute usurpation d’identité. En outre, le fournisseur a publié un blog sur la suppression des pratiques héritées non sécurisées de son environnement, bien que M. Mollema se soit plaint de l’absence de détails sur le nombre de services qui utilisent encore ces jetons.
« Cette vulnérabilité a déjà été entièrement corrigée », a déclaré la société dans son avis. « Les utilisateurs de ce service n’ont aucune mesure à prendre. » L’équipe Mitiga souligne que ce problème met en évidence une catégorie plus large de risques : la confiance cachée au cœur des systèmes d’identité cloud. « Microsoft a corrigé le problème, mais le manque de visibilité historique signifie que les défenseurs ne peuvent toujours pas être sûrs qu’il ait été utilisé dans le passé », a ajouté l’équipe. « Cette incertitude est le point crucial : les attaquants continuent de rechercher des voies invisibles. Les défenseurs ont besoin de visibilité partout, avant, pendant et après l’exploitation.
Une variante d’un malware de minage de cryptomonnaie ciblant des instances Docker comprend désormais des techniques de persistance et de portes dérobées. Elle bloque également l’accès aux API exposées à d’éventuels logiciels malveillants concurrents.
Améliorer l’existant, c’est ce que vient de découvrir l’équipe de chercheurs d’Akamai sur une souche inédite d’un malware de cryptomining ciblant Docker découvert en juin 2025 par Trend Micro. « La souche a été observée pour la dernière fois en août 2025 dans l’infrastructure de honeypots d’Akamai », a déclaré Yonathan Gilvarg, chercheur senior en sécurité au sein de l’équipe sécurité d’Akamai dans un blog. « La variante découverte ne dépose pas de cryptomineur, mais un fichier contenant d’autres outils précédemment utilisés ainsi que des capacités d’infection plus efficaces que celles de la souche d’origine », note l’expert. Il diffère tant par ses charges utiles binaires que de ses méthodes d’accès initial avec des techniques de persistance et de protection contre les autres malwares.
Les principaux vecteurs d’infection sont ici les API Docker mal configurées exposées sur Internet, généralement sur le port 2375. Les pirates les utilisent pour lancer un conteneur (souvent à l’aide de l’image Linux « alpine » légère), monter le système de fichiers hôte, puis exécuter des scripts encodés en Base64 récupérés via Tor. Dans un premier temps ces scripts installent des outils tels que curl, tor, et de scan de masse, puis téléchargent et exécutent des composants malveillants. Une fois installé, le malware met en place plusieurs mesures de persistance et d’évasion : ajout d’une clé SSH publique malveillante aux clés autorisées de l’utilisateur root, configuration de tâches cron, et montage de répertoires hôtes pour conserver de la visibilité et du contrôle.
Une persistance et une protection contre les autres malwares
« L’analyse du script (utilisé dans la souche) indique qu’il effectue plusieurs étapes de persistance et de contournement de défense, notamment en refusant tout accès futur à l’instance exposée, ce que nous n’avions pas observé dans les déclinaisons précédentes », poursuit M. Gilvarg. Les pratiques courantes qui peuvent exposer publiquement les API Docker comprennent l’exécution de l’API sans protection de la couche de transport (TLS) pour des raisons de commodité, une adresse IP 0.0.0.0 non routable au lieu d’une en boucle (localhost), des déploiements cloud avec des règles de pare-feu faibles, et l’utilisation d’outils d’orchestration ou de surveillance tiers nécessitant un accès constant à l’API Docker.
Ce qui distingue cette variante, c’est qu’elle empêche d’autres malwares d’accéder à la même API Docker exposée, monopolisant ainsi efficacement sa surface d’attaque. Elle tente même de modifier les paramètres du pare-feu (iptables, nft, firewall-cmd, etc.) via une tâche cron pour supprimer ou rejeter les connexions entrantes sur le port 2375. Une tâche cron est une tâche planifiée sur les systèmes Linux qui s’exécute automatiquement à des heures ou à des intervalles spécifiés. « Le fichier crontab se trouve sur l’hôte lui-même, car l’attaquant l’a monté lors de la création du conteneur », a ajouté M. Gitvarg. « Il s’agit d’une autre section du code que nous n’avons pas vue dans les variantes précédentes et qui n’est actuellement pas détectée dans VirusTotal ». De plus, le logiciel frauduleux comprend une logique (même si elle n’est pas encore pleinement active) permettant de rechercher et d’exploiter potentiellement d’autres services, par exemple Telnet (port 23) et le port de débogage à distance de Chrome (9222). Cela pourrait permettre le vol d’identifiants, l’exfiltration de données ou le détournement de sessions de navigation à distance. Akamai avertit que, même si cette capacité n’est pas encore pleinement exploitée, elle suggère que ce malware pourrait évoluer vers un botnet plus complexe.
En exploitant la fonction d’exécution automatique de l’éditeur de code à base d’IA Cursor, des pirates mettent en danger les systèmes des développeurs et les données sensibles des entreprises.
Oasis Security a découvert une faille dans Cursor, un IDE à base d’IA de premier plan, largement utilisé et alimenté par l’IA, qui permet à des référentiels malveillants d’exécuter discrètement du code dès qu’un développeur les ouvre. Selon une information partagée avec CSO avant sa publication, le problème vient du fait que ce logiciel autorise certains paramètres de projet à déclencher l’exécution automatique de tâches dès l’ouverture d’un…
Il vous reste 91% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Une dernière campagne malveillante donne la capacité à des pirates de contourner l’authentification multifacteurs en se servant du kit de phishing Salty2FA. Les appels à multiplier les stratégies de sécurité sans mots de passe se multiplient.
Une campagne de phishing récemment découverte a été associée à Salty2FA, un framework de phishing as a service conçu pour contourner l’authentification multifacteurs (MFA). Selon la société de cybersécurité Ontinue, cette opération malveillante se sert de ce kit pour contourner les protections MFA. Comment ? En interceptant les méthodes de vérification, en procédant à la rotation des sous-domaines de session et en se dissimulant au sein de plateformes de confiance telles que Turnstile, une solution de Cloudflare qui se présente comme une alternative aux captcha. Dans un avis partagé avec CSO avant sa publication mardi, Ontinue a déclaré que la campagne employait des « innovations techniques notables », notamment des tactiques d’évasion jamais vues auparavant avec l’utilisation de ce kit.
« Salty2FA nous rappelle une fois de plus que le phishing est désormais une pratique courante dans le monde de l’entreprise, avec des tactiques d’évasion avancées et de contournement MFA convaincantes », a déclaré Brian Thornton, ingénieur commercial senior chez Zimperium. « En exploitant des plateformes de confiance et en imitant les portails d’entreprise, les pirates brouillent les frontières entre le trafic réel et le trafic frauduleux ». Observé pour la première fois mi-2025, Salty2FA a déjà été utilisé dans plusieurs campagnes visant les utilisateurs de Microsoft 365 à travers le monde.
Le MFA n’est plus le bouclier qu’il était
Dans le cadre de cette offensive, les pirates ont mis en place une infrastructure en plusieurs étapes, commençant par une redirection malveillante hébergée sur un compte « aha[.]io » nouvellement enregistré. Les victimes étaient acheminées via une passerelle Cloudflare Turnstile afin de filtrer les analyses automatisées avant d’atterrir sur la page finale de collecte des identifiants. Là, Salty2FA simulait plusieurs flux MFA, notamment des SMS, des applications d’authentification, des notifications push et même des tokens physiques, tout en appliquant un marquage dynamique du nom de leur entreprise basé sur son domaine de messagerie électronique.
L’attaque montre comment les pirates sapent le MFA, une pratique de sécurité autrefois considérée comme le moyen le plus sûr de protéger les comptes. Le kit utilise l’appariement de domaines, l’obfuscation et la manipulation de Turnstile pour créer des portails de phishing presque impossibles à distinguer des pages de connexion officielles. Shane Barney, responsable de la sécurité des systèmes d’information chez Keeper Security, a qualifié cela de « phishing 2.0 » et « d’attaques conçues pour contourner les mesures de sécurité auxquelles les entreprises faisaient autrefois confiance ». La rotation des sous-domaines de session et le blocage par géolocalisation pour une évasion avancée sont utilisés. Chaque victime obtient un sous-domaine unique, contournant ainsi les listes noires de domaines, tandis que le trafic provenant des fournisseurs de sécurité et cloud est bloqué, de sorte que seuls de véritables utilisateurs accèdent à la page de phishing.
Un appel à la mise en place de défenses multicouches et adaptatives
Les experts du secteur s’accordent à dire que pour contrer Salty2FA, il faudra peut-être aller au-delà des mots de passe et des contrôles traditionnels. Darren Guccione, CEO de Keeper Security, estime que les clés d’accès et l’authentification sans mot de passe devraient faire partie de la stratégie. « Ces technologies complètent les mesures de sécurité existantes en réduisant la dépendance aux mots de passe traditionnels, qui restent une cible privilégiée pour le phishing », a-t-il déclaré. Les chercheurs d’Ontinue ont conseillé de passer des contrôles statiques, que Salty2FA contourne facilement, au sandboxing et à l’inspection temps réel des domaines suspects. Ils soulignent également que la sensibilisation des utilisateurs reste essentielle, car les portails de phishing imitent si fidèlement les sites légitimes que les contrôles techniques seuls ne peuvent pas les arrêter de manière fiable.
Shane Barney a fait écho à cette préoccupation et a fait valoir que les techniques de détection statiques sont inadéquates dans cet environnement. Selon lui, les défenseurs doivent plutôt surveiller les anomalies de domaine, les exécutions JavaScript inhabituelles et d’autres indices comportementaux subtils. Il a également souligné l’importance cruciale des méthodes résistantes au phishing, telles que les jetons Fido2 et WebAuthn, qui rendent les codes volés inutilisables. La gestion des accès à privilèges, un framework zero trust et une formation continue sont recommandés comme éléments clés pour limiter les conséquences du vol d’identifiants. « Les entreprises doivent faire preuve d’une adaptabilité similaire en combinant la détection comportementale, la visibilité en temps réel et l’authentification résistante au phishing pour faire face à une nouvelle génération de menaces », a ajouté M. Barney.
Une mauvaise configuration par défaut dans MCP Inspector d’Anthropic ouvre la voie à de l’exécution de commandes arbitraires à distance. Avec à la clé de sérieux risques pour les développeurs travaillant sur des projets d’intelligence artificielle.
Un bogue critique d’exécution de code à distance (RCE) dans Model Context Protocol Inspector d’Anthropic pourrait permettre à des cyberattaquants d’exécuter des commandes arbitraires sur les postes de travail des développeurs lorsqu’ils visitent un site web malveillant. Cet outil aide les codeurs à tester et à déboguer les interactions des agents d’intelligence artificielle en utilisant MCP (Model Context Protocol) d’Anthropic, un standard ouvert qui permet aux agents d’intelligence artificielle de communiquer avec des outils et des sources de données externes.
La vulnérabilité critique affecte tous les déploiements par défaut qui se lient à toutes les interfaces réseau. Cela ouvre la porte à un large éventail d’attaques, y compris la falsification des requêtes intersites (CSRF), l’exécution de code à distance (RCE) et l’accès non autorisé. « Avec l’exécution de code sur le terminal d’un développeur, les attaquants peuvent voler des données, installer des portes dérobées, se déplacer latéralement à travers les réseaux, ce qui met en évidence des risques sérieux pour les équipes d’IA, les projets open-source et les entreprises qui s’appuient sur MCP », a déclaré Avi Lumelsky, chercheur en sécurité chez Oligo security, la société de cybersécurité qui a découvert et signalé la vulnérabilité à Anthropic, dans un billet de blog. Anthropic a corrigé la vulnérabilité (CVE-2025-49596 au score CVSS de 9.4) dans la version 0.14.1 d’Inspector MCP.
Une version non sécurisée d’Inspector MCP dans des projets open source
Pour soutenir l’écosystème MCP, les développeurs s’appuient sur des outils tels que MCP Inspector qui offrent une visibilité en temps réel des flux de messages et des comportements des agents régis par le protocole. « L’outil MCP Inspector est lancé par défaut lorsque la commande mcp dev est exécutée », explique M. Lumelsky. Il agit comme un serveur HTTP qui écoute les connexions, avec une configuration par défaut qui n’inclut pas de mesures de sécurité suffisantes comme l’authentification ou le cryptage. Cette mauvaise configuration introduit une surface d’attaque majeure, permettant à n’importe qui sur le réseau local, ou même sur l’Internet public, d’accéder potentiellement au serveur exposé et de l’exploiter.
Inspecor MCP est un outil essentiel pour les codeurs qui travaillent avec des systèmes d’IA complexes, y compris des acteurs majeurs comme Microsoft et Google pour leurs environnements IA et cloud. Une vulnérabilité affectant les déploiements open source pose de sérieux risques pour ces systèmes d’entreprise, a ajouté M. Lumelsky. À mesure que l’adoption des MCP s’accélère, des failles de sécurité commencent à apparaître, comme le bogue dans le connecteur MCP AI d’Asana qui a exposé les données de l’entreprise via des systèmes hôtes. L’incident, découvert un mois seulement après le lancement, souligne la nécessité de réévaluer le protocole expérimental avant de le déployer à plus grande échelle dans les entreprises.
Un vecteur d’attaque combinant deux vulnérabiltés
Oligo a démontré que le vecteur d’attaque combine deux failles indépendantes. Les attaquants peuvent enchaîner la faille « 0.0.0.0-day » du navigateur, qui permet aux pages web d’envoyer des requêtes à l’adresse 0.0.0.0 que les navigateurs traitent comme l’hôte local, à une attaque de type CSRF exploitant le point d’extrémité vulnérable « /sse » du proxy Inspector qui accepte des commandes via des chaînes de requêtes sur stdio. L’attaque CSRF peut se transformer en RCE lorsque l’attaquant utilise la faille pour envoyer des requêtes malveillantes. « Lorsqu’un attaquant peut créer une requête à l’inspecteur MCP à partir d’un contexte JavaScript du domaine public, cette requête peut déclencher des commandes arbitraires sur l’ordinateur de la victime, ce qui lui permet d’en prendre le contrôle », a déclaré M. Lumelsky.
L’étude d’Oligo souligne que les configurations par défaut peuvent exposer involontairement les serveurs MCP à des attaques, ce qui pourrait permettre aux acteurs de la menace de s’introduire dans les terminaux des développeurs. Alors que le jour 0.0.0.0 n’a toujours pas été corrigé dans Chromium et Firefox un an après sa découverte, la faille MCP a été rapidement corrigée par Anthropic, en raison de sa gravité critique. Un avis du Nist (référentiel américain des failles) invite les utilisateurs à mettre à jour immédiatement toutes les versions vulnérables (inférieures à 0.14.1).
Des pirates utilisent du typo-squatting, de l’obfuscation et des faux comptes pour glisser des logiciels malveillants basés sur Python dans des projets open source sur GitHub. Une situation qui montre que la sécurité de la chaîne d’approvisionnement des logiciels libres est loin d’être préservée des attaques.
Un groupe de cybercriminels surnommé Banana Squad, actif depuis avril 2023, a inséré plus de 60 dépôts GitHub corrompus dans le cadre d’une campagne en cours, proposant des kits de piratage basés sur Python avec des charges utiles malveillantes. Découverts par ReversingLabs, les dépôts publics malveillants imitent chacun un outil de piratage bien connu pour paraître légitimes, mais injectent une porte dérobée cachée. « À première vue, ils semblent être des outils de piratage écrits en Python, mais il s’agit en fait de sosies trojanisés d’autres dépôts portant le même nom », a fait savoir Robert Simmons, chercheur principal en logiciels malveillants, dans un billet de blog.Les dépôts ont été découverts en travaillant à rebours à partir des indicateurs d’URL malveillantes dans l’ensemble de données de renseignements sur les menaces du réseau de ReversingLabs. M. Simmons note que cette campagne représente une évolution des contrefaçons flagrantes de npm/PyPI vers une exploitation plus subtile de plates-formes telles que GitHub.
Chacun des 67 dépôts empoisonnés trouvés se faisait passer pour un utilitaire légitime, comme un voleur d’identifiants, un scanner de vulnérabilités ou d’autres outils de sécurité informatique. Mais ces versions contiennent du code malveillant furtivement intégré dans des chaînes massives de caractères, des espaces blancs, ou chiffré. « Il y a beaucoup d’espaces sur la ligne de code trojanisée, ce qui fait que même sur un grand écran à 4K avec une fenêtre maximisée, le code malveillant n’est pas visible », a déclaré M. Simmons. « Cependant, l’affichage du fichier dans la fonction de prévisualisation de Spectra Analyze montre clairement le contenu. » Les auteurs de l’attaque ont regroupé les codes Python nuisibles sur une seule ligne trop longue pour être lue, en espérant que les utilisateurs ne fassent jamais défiler la page assez loin pour s’en apercevoir. Banana Squad a déjà diffusé des centaines de logiciels malveillants pour Windows dans l’écosystème du code source ouvert, notamment dans les systèmes de contrôle de version et les gestionnaires de paquets PyPI et npm, sous de multiples pseudonymes. Ces paquets, repérés en avril 2023, volaient des données sensibles, notamment des détails du système et des portefeuilles de crypto-monnaie, et ont été téléchargés près de 75 000 fois avant d’être retirés.
Des indicateurs de compromission partagés
ReversingLabs a observé plusieurs signes révélateurs concernant les dépôts qui peuvent aider à attraper l’infection à la source. « Pour la majorité des dépôts malveillants, le propriétaire n’a qu’un seul dépôt répertorié sous son compte GitHub », explique M. Simmons. « Cela indique que ces types de comptes d’utilisateurs sont presque certainement faux et créés dans le but exprès d’héberger un dépôt malveillant. Les noms des dépôts se sont avérés identiques à un ou plusieurs autres dépôts non trojanisés, ce qui indique qu’une forme de typo-squatting est à l’œuvre. En outre, la section « À propos » de ces dépôts était truffée de mots-clés de recherche liés au thème du dépôt original et comportait souvent un emoji, généralement une flamme ou une fusée, ce qui laissait supposer l’utilisation de l’IA.
ReversingLabs a partagé une liste d’indicateurs de campagne, notamment des domaines, des URL et des noms de fichiers, ainsi que les 67 dépôts signalés, afin que les développeurs puissent s’en méfier. « Pour les développeurs qui s’appuient sur ces plateformes open source (GitHub), il est essentiel de toujours vérifier que le dépôt que vous utilisez contient réellement ce que vous attendez », a averti M. Simmons. « Cependant, la meilleure façon d’éviter cette menace est de comparer le dépôt souhaité à une version précédente, connue et bonne, du logiciel ou du code source. »
Une mauvaise implémentation d’OAuth dans la fonction File Picker de OneDrive donne un accès complet à l’ensemble des fichiers d’un ordinateur.
Rien de plus anodin que de passer par OneDrive pour télécharger un fichier sur ChatGPT, Slack ou Zoom. Enfin presque : plusieurs experts en sécurité ont alerté que les applications utilisant le sélecteur de fichiers (File Picker) du service de stockage cloud de Microsoft peuvent, dans certaines circonstances, obtenir un accès complet en lecture à un compte, en plus d’un accès en écriture.
« Le problème principal est lié au sélecteur de fichiers OneDrive de Microsoft, qui demande un accès étendu à l’ensemble du compte d’un utilisateur, même lorsque ce dernier essaie simplement de télécharger un seul fichier », explique Vijay Dilwale, consultant principal en matière de sécurité chez Black Duck. « L’expérience utilisateur donne l’impression que seul le fichier sélectionné est partagé, mais en réalité, l’application obtient souvent un accès complet en lecture (et parfois en écriture) à l’ensemble du contenu ». File Picker est un outil fourni par Microsoft qui propose aux sites web et aux applications web de s’intégrer au compte OneDrive d’un utilisateur pour lui permettre de télécharger, de parcourir et de sélectionner des fichiers de cette solution directement à partir de l’application.
Un piège OAuth aux privilèges trop élevés
Cet accès étendu découle d’une limitation de l’implémentation OAuth de Microsoft dans File Picker, que les chercheurs décrivent comme « un manque d’étendue des permissions à granularité fine ». Jason Soroko, senior fellow chez Sectigo, qualifie cet oubli de piège OAuth à privilèges excessifs. « Le sélecteur de fichiers OneDrive de Microsoft encourage les applications web tierces à demander des fichiers de grande taille », a-t-il déclaré. « Une fois émis, ces jetons à longue durée de vie sont souvent mis en cache dans localStorage ou dans des bases de données dorsales sans aucun chiffrement, ce qui permet potentiellement aux attaquants de parcourir les données d’une instance entière. » L’implémentation OAuth de OneDrive File Picker n’est pas assez fines au niveau des fichiers, ne permettant pas aux utilisateurs et aux développeurs de restreindre l’accès aux seuls fichiers explicitement sélectionnés.
Selon une étude menée par Oasis Security, toutes les versions de File Picker demandent des autorisations qui lisent l’intégralité du OneDrive de l’utilisateur pour le processus de téléchargement et écrivent n’importe où sur l’espace de stockage pour ce processus. Cependant, la version 7.0 du sélecteur de fichiers demande des autorisations de lecture et d’écriture pour le processus de téléchargement. « Le manque de précision des champs d’application pour le cas d’utilisation du sélecteur de fichiers empêche les utilisateurs de faire la distinction entre les applications malveillantes qui ciblent tous vos fichiers et les applications légitimes qui demandent des autorisations excessives simplement parce qu’il n’y a pas d’autre option sécurisée », ont prévenu les chercheurs d’Oasis Security dans un billet de blog.
Les fournisseurs d’applications web pas tirés d’affaire
Selon Eric Schwake, directeur de la stratégie de cybersécurité chez Salt Security, cela pourrait être une mauvaise nouvelle pour les équipes de sécurité. « Les secrets sensibles requis pour cet accès sont souvent stockés par défaut de manière non sécurisée », explique-t-il. Tout en ajoutant, « cette situation représente un défi majeur en matière de sécurité des API pour les équipes de sécurité, et avec des services tels que ChatGPT qui dépendent fortement des API pour accéder aux données des utilisateurs et les traiter, le risque est encore plus grand. » Une application web tierce qui se retrouve avec des données utilisateur « involontaires » à cause de cette situation devient une cible pour les acteurs de la menace et pourrait potentiellement enfreindre les règles de conformité rien qu’en ayant ce niveau d’accès.
Oasis Security note que des applications telles que ChatGPT (qui utilise File Picker v8.0), ClickUp, Trello, Zoom et Slack sont potentiellement concernées. Même des applications comme Phenome, un outil de recrutement, pourraient involontairement exposer des fichiers confidentiels si les utilisateurs téléchargent des CV à partir de comptes d’entreprise. « Les fournisseurs qui développent des applications Web sont en danger, car les incidents de sécurité pourraient avoir de graves conséquences, en faisant fuir un grand nombre de fichiers d’un grand nombre de leurs utilisateurs », notent les chercheurs d’Oasis qui ont prévenu Microsoft.
En attendant la réponse de Microsoft, remonter la vigilance
La firme de Redmond a reconnu le problème et indiqué qu’il pourrait envisager d’apporter des améliorations à l’avenir. Dans l’intervalle, Oasis Security a recommandé quelques mesures d’atténuation pour les applications web, notamment la suppression de l’option de téléchargement de fichiers à l’aide de OneDrive via OAuth jusqu’à ce que Microsoft corrige le bug, et l’exploration de solutions de contournement plus simples, comme la prise en charge des liens de fichiers partagés « en mode lecture uniquement » à partir de OneDrive.
Oasis Security a également noté que les solutions File Picker sur d’autres services d’hébergement de fichiers tels que Google Drive et Dropbox peuvent être utilisées comme alternative car elles ne souffrent pas de ce problème. « Les utilisateurs doivent partir du principe que chaque plug-in SaaS qu’ils autorisent possède les clés de leurs joyaux personnels ou de l’entreprise, sauf preuve du contraire », a déclaré M. Soroko. Les équipes de sécurité doivent appliquer le « consentement de l’administrateur » ou des politiques d’accès conditionnel qui bloquent les applications demandant tout ce qui va au-delà de Files.Read. M. Schwake a ajouté qu’une gouvernance plus forte des API pour s’assurer que toutes les permissions des API sont gérées méticuleusement, ce qui inclut le respect du moindre privilège et la gestion sécurisée des jetons, est nécessaire pour éviter une exposition importante des données.