Mi-août 2025, la faille Salesloft Drift a été signalée, impactant des géants comme Palo Alto Networks, Salesforce, Cloudflare et leurs clients. Les attaquants ont volé et détourné des centaines de jetons OAuth pour accéder aux environnements Salesforce et extraire des données sensibles, démontrant ainsi des conséquences à grande échelle avérées et potentielles.
En lisant les rapports, j'ai résisté à l'idée de les classer comme une nouvelle « attaque de la chaîne d'approvisionnement ». Cette attaque était différente.
C'était lié à vol d'identités non humaines et une rupture de confiance avec un mouvement latéral TTP sous stéroïdes, autrement connu sous le nom de mouvement latéral inter-fournisseurs. Il s'agissait d'une attaque interentreprises. Ou, pour le dire de manière beaucoup plus scientifique, d'une (B2)ⁿ AttaqueCette chaîne de confiance brisée rend très difficile pour les victimes de l’attaque de se protéger.
Penses-y: Attaquant → Dérive → Salesloft → Salesforce → Le client → Client du client.
Chaque saut étendait la surface d'attaque, et une fois Jetons OAuth Les attaquants disposaient d'un chemin d'accès sécurisé à chaque fournisseur. L'impact avéré comprend déjà des centaines d'organisations touchées, des dossiers volés et plus de 100 jetons d'API exposés, avec un potentiel de compromission bien plus vaste si les pirates exploitent ces données pour récupérer des clés cloud et d'autres identifiants.
Les grandes organisations entretiennent des milliers de partenariats et d'intégrations, sans pour autant disposer d'un modèle d'intégration véritablement sécurisé. Cette chaîne d'intégration engendre une relation plus que individuelle. Comment pouvons-nous alors prévenir, détecter ou réagir plus rapidement à ce type d'attaques, et nous protéger des effets domino ?
Évidemment, cela soulève également une question plus vaste : devons-nous faire pression pour un modèle de sécurité partagé pour les fournisseurs SaaS, pas seulement pour les géants de l’infrastructure cloud comme AWS, Microsoft et Google Cloud, qui ont passé des appels similaires en 2020 ? Dans cet article, j'expliquerai où se situe le véritable problème et comment les fournisseurs et les RSSI peuvent créer un cadre de responsabilité partagée qui tienne compte de toutes les dépendances et réduit en fin de compte risque de mouvement latéral.
Ça vous intéresse ? Continuez à lire. Si cela vous semble utile, n'hésitez pas à me faire part de vos commentaires.
Plus de détails sur la violation
Selon différentes sources (mentionnées ci-dessous), en août 2025, des attaquants identifiés comme UNC6395 ont volé des jetons d'actualisation OAuth depuis l'intégration Drift de Salesloft avec Salesforce. Ces jetons ont permis à Drift d'interroger des instances Salesforce pour le compte de plus de 700 clients. Une fois connectés, les attaquants ont exporté des données de contact, des dossiers et même des clés API intégrées à des tickets ou des pièces jointes.
Parmi les entreprises impactées figuraient des acteurs de premier plan comme Cloudflare, Proofpoint et Palo Alto Networks. Cloudflare a révélé que 104 jetons d'API et des données de cas sensibles avaient été compromis. Salesforce et Salesloft ont réagi en révoquant les jetons Drift et en supprimant l'application d'AppExchange. Les clients finaux ont également désactivé cette intégration en guise de contre-mesure. Pour certains, il était trop tard, car leurs données, y compris leurs secrets d'accès, avaient déjà fuité.
Une analyse plus approfondie a révélé que les attaquants avaient accès aux dépôts GitHub de Salesloft, permettant une reconnaissance plus approfondie et facilitant potentiellement le vol de jetons. Google a également signalé une utilisation abusive limitée des jetons OAuth de Drift Email dans les environnements Google Workspace. Pire encore, les pirates ont recherché les clés AWS, les jetons Snowflake et d'autres identifiants dans les données volées, multipliant ainsi l'impact potentiel.
Alors que de nombreux articles publiés ces dernières semaines évoquent cette cyberattaque comme une violation de données « classique », une exploitation SaaS, voire une compromission d'un agent d'IA, cet incident est différent. Il illustre parfaitement ce phénomène. plateformes IAM La complexité, ou, pour le dire simplement, le désordre total de l'IAM (et non du maillage) auquel nous sommes tous confrontés à l'ère du SaaS, de l'IA et de l'explosion des identités non humaines (NHI). Le chatbot Drift est une application logicielle conçue pour automatiser les conversations. Il n'agit donc pas de manière autonome ni ne prend de décisions indépendantes. Il fonctionne plutôt selon des flux de travail et des intégrations prédéfinis. Le protocole OAuth utilisé pour l'intégration est une NHI (identité non humaine).
Ce que nous pouvons apprendre
En tant que clients, nous ne sommes pas prêts à nous protéger contre (B2)ⁿAttaques contre l'assurance maladie nationale (NHI)
Il n'est pas facile de répondre à la question fondamentale : « Lesquels de nos fournisseurs ont été impactés ? » et « Quelles données et quels accès détenaient-ils dans Salesforce à notre sujet ? » Ce genre de questions mouvements latéraux Les attaques qui révèlent l'interconnexion de nos systèmes numériques soulignent qu'il est plus difficile que nous le pensons d'arrêter les pirates informatiques, car nous sommes souvent les derniers à être conscients de l'impact tout au long de la chaîne alimentaire.
Le risque B2B2B est réel et nous avons besoin d’un modèle de responsabilité partagée
Il ne s'agissait pas seulement de Drift → Salesforce → clients. Il s'agissait de Drift → Salesforce → données SaaS clients → services cloud. Chaque saut élargissait le rayon d'action. Les fournisseurs doivent tenir compte des fournisseurs de leurs fournisseurs.
Les jetons sont des identités et doivent être gérés comme tels, quelle que soit la distance B2B
Les jetons OAuth ne sont pas seulement un « colle technique ». Ce sont des identités non humaines qui doivent être traitées avec la même rigueur que les comptes humains : éphémères, limitées, soumises à une rotation et surveillées. Ce sont des identités que tout le monde (y compris les attaquants) peut prendre si elles ne sont pas correctement sécurisées.
Vos secrets et vos informations d’identification résident également dans les données – pas seulement les vôtres, mais aussi celles de vos partenaires
Les notes de cas et les pièces jointes contiennent souvent des clés ou des configurations sensibles. Une fois piratés, les CRM et les systèmes d'assistance deviennent des mines d'or en matière d'identifiants. L'analyse et la suppression des secrets des données SaaS doivent devenir une pratique courante.
Les kill-switchs centralisés sont importants
La capacité de Salesforce à révoquer les jetons Drift à l'échelle mondiale a contribué à contenir la propagation. Toutes les plateformes devraient pouvoir activer la révocation d'urgence à grande échelle.
Au-delà de la chaîne d'approvisionnement : comprendre (B2)ⁿ
Il est tentant de qualifier cela simplement d'attaque de la chaîne d'approvisionnement ou de risque tiers. Mais cette définition est trop large et masque les mécanismes spécifiques.
Ce que nous avons vu ici est plus proche d'une attaque croisée (B2)ⁿ, une forme de mouvement latéral entre vendeurs.
En substance, cela ressemble à ceci :
- Un client, par exemple Palo Alto Networks, utilise une plateforme SaaS, telle que Salesforce.
- Pour améliorer la valeur, Palo Alto Networks connecte un réseau 3rd application de fête – Salesloft vers Salesforce.
- Salesloft acquiert Drift, qui détenait des jetons OAuth permettant l'accès de Saleloft à Salesforce au nom de Palo Alto Networks.
- Si les données Salesforce de Palo Alto Networks contiennent des secrets intégrés (comme des clés API), les attaquants qui violent Drift peuvent exploiter les données de Salesforce pour accéder davantage à l'environnement d'un autre fournisseur.
Il s'agit d'une confiance fédérée, ainsi que d'une confiance implicite, se transformant en risque fédéré. Chaque intégration semble anodine prise isolément, mais lorsqu'elles sont enchaînées, elles créent un chemin d'accès pour les attaquants à travers plusieurs organisations. D'où l'idée de (B2)ⁿ : les liens interentreprises se multiplient, aggravant l'exposition.
Construire un modèle de responsabilité partagée pour (B2)ⁿ Intégrations SaaS
Dans le tableau ci-dessous, vous verrez où chaque partie de la chaîne assume la responsabilité de prévenir les attaques de mouvement latéral entre fournisseurs :
La voie à suivre grâce à la responsabilité partagée
En attendant un accord mutuel sur un nouveau modèle de sécurité partagé, pour chaque intégration ou jeton/clé/certificat/identité créé pour un tiers ou un quatrième acteur, les RSSI et les responsables IAM devraient exiger de leurs fournisseurs qu'ils leur fournissent une visibilité sur le cycle de vie du jeton, son volume d'utilisation, une surveillance de base des anomalies d'utilisation, etc. À minima, ils devraient collaborer avec les fournisseurs pour confirmer la disponibilité d'un bouton d'arrêt d'urgence ou d'actualisation.
Et pour les fournisseurs eux-mêmes, assurons-nous de donner à nos partenaires d'intégration et à nos clients finaux cette visibilité, et dans le cadre du paywall, dans le cadre des packages de base.
Références
Groupe d'analyse des menaces Google : mises à jour UNC6395 –
https://cloud.google.com/blog/topics/threat-intelligence/unc6395-drift-attack
Avis de Salesforce sur la suppression de l'application Drift
https://help.salesforce.com/s/articleView?id=005134951&language=en_US&type=1
Analyse de l'unité 42 de Palo Alto Networks
https://unit42.paloaltonetworks.com/threat-brief-compromised-salesforce-instances/
Divulgation de Cloudflare sur les jetons compromis
https://blog.cloudflare.com/response-to-salesloft-drift-incident/
Enquête Mandiant sur la compromission de Salesloft sur GitHub –
https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift
