Cas d'école IAM
Token OAuth compromis, compte de service détourné, habilitation trop large, privilège persistant, comportement anormal passé sous les radars… Les mécanismes changent, mais l'identité est souvent au centre de la chaîne d'attaque. Ariovis analyse ici des incidents documentés pour identifier les contrôles IAM qui auraient pu les prévenir ou en réduire l'impact.
Comprendre notre approche pour prévenir les fuites de donnéesUne analyse cyber classique cherche d'abord le vecteur d'entrée : la vulnérabilité exploitée, le message piégé, le service exposé. C'est nécessaire, mais insuffisant pour comprendre pourquoi un incident a produit une fuite de données de cette ampleur. Nous complétons cette lecture par les questions d'identité et d'habilitation qui viennent juste après l'intrusion.
Chaque cas est adressable directement par son ancre pour être cité ou partagé.
SaaS / supply chain · Mars – août 2025
Plus de 700 organisations affectées par des tokens OAuth volés associés aux intégrations Drift. Une application de confiance, un credential valide, et l'authentification humaine n'est plus la barrière pertinente.
Secteur : SaaS / supply chain · Période : Mars – août 2025
Plus de 700 organisations ont été affectées par une attaque supply-chain exploitant des tokens OAuth volés associés aux intégrations Drift. L'incident illustre un angle mort encore fréquent de l'IAM : les applications disposent elles aussi d'une identité, de droits et d'un cycle de vie qu'il faut gouverner.
Mars à juin 2025 — selon l'investigation Mandiant publiée par Salesloft, l'acteur malveillant a eu accès au compte GitHub de Salesloft, téléchargé le contenu de plusieurs repositories, ajouté un utilisateur invité et mis en place des workflows. Des activités de reconnaissance ont ensuite été observées dans les environnements Salesloft et Drift.
L'investigation a ensuite établi un accès à l'environnement AWS de Drift, depuis lequel l'attaquant a obtenu des tokens OAuth associés aux intégrations technologiques de clients.
8 au 18 août 2025 — ces credentials OAuth ont été utilisés pour accéder à des environnements clients via les intégrations Drift et exfiltrer des données. Salesloft documente cette fenêtre ; FINRA recommande également d'y rechercher les accès anormaux.
Précision de méthode : certaines publications initiales évoquaient des tokens obtenus lors de campagnes antérieures de phishing ou de social engineering. Nous retenons ici la chronologie postérieure et plus précise établie par l'investigation, et nous ne présentons pas les deux hypothèses comme démontrées simultanément.
Une attaque de la relation de confiance
Aucune étape de cette chaîne ne suppose qu'un utilisateur humain se reconnecte.
Le problème IAM : l'identité qui accédait aux données n'était pas humaine. Lorsqu'une personne se connecte, on peut lui demander un mot de passe, un facteur supplémentaire, une authentification adaptative, un terminal conforme, un contexte cohérent.
Une intégration OAuth fonctionne autrement. Une fois la relation de confiance établie et un credential délivré, l'application appelle les API dans la limite des autorisations qui lui ont été accordées. L'attaquant n'avait donc pas besoin de refaire le parcours d'un utilisateur humain : FINRA indique que les tokens volés permettaient d'usurper l'application Drift de confiance et de contourner le parcours traditionnel de MFA.
Le token est le credential de cette identité applicative, pas son identité. C'est cette distinction qui déplace le sujet : de l'authentification humaine vers la gouvernance de l'identité applicative, de ses credentials, de ses autorisations et de son comportement.
Le MFA n'a pas échoué
Il protégeait une autre étape de la chaîne. Une fois un credential OAuth valide compromis, le problème se déplace de l'authentification humaine vers la gouvernance de l'identité applicative, de ses credentials, de ses autorisations et de son comportement.
L'intégration SaaS est une identité
Une identité non-humaine peut être une application, une intégration SaaS, un compte de service, un workload, un bot ou un agent IA. Elle possède elle aussi :
Le fait qu'aucune personne physique ne se connecte ne retire pas le sujet du périmètre IAM : c'est précisément ce qui en fait un sujet de gouvernance des identités non-humaines. Précision utile : « identité non-humaine » ne signifie pas nécessairement flow OAuth client_credentials.
FINRA indique que la campagne a touché plus de 700 organisations et que les attaquants ont notamment accédé à des environnements Salesforce, Google Workspace et, dans certains cas, Slack. Les données exposées pouvaient inclure contacts, comptes, opportunités et cases, mais aussi des API keys, des credentials cloud, des mots de passe et des tokens présents dans les contenus.
Cloudflare, qui a publié sa réponse, explique que son environnement Salesforce contenait des informations issues des tickets de support susceptibles d'embarquer des tokens ou des mots de passe. L'entreprise a identifié 104 tokens API Cloudflare dans les données concernées et les a tous fait tourner, sans avoir identifié d'activité suspecte associée à ces tokens.
C'est là que la notion de blast radius devient concrète : la donnée volée peut devenir le credential de l'attaque suivante. Une intégration compromise donne accès au CRM, le CRM contient un token, ce token ouvre potentiellement un troisième système. Le rayon d'action dépasse alors largement le SaaS initialement concerné.
Les contrôles orientés utilisateur — mot de passe, MFA, authentification adaptative — encadraient une étape que l'attaquant n'avait pas besoin de franchir : il disposait d'un credential déjà accordé à une application de confiance.
À partir de là, seuls des contrôles portant sur l'identité applicative pouvaient encore agir : périmètre des autorisations accordées, durée de validité du credential, capacité de révocation, et surveillance de l'usage réel de l'intégration.
Aucun contrôle isolé n'aurait nécessairement empêché l'incident. L'enjeu est de réduire la marge de manœuvre à chaque étape.
Prévenir
Limiter
Détecter
Réagir
Ce ne sont pas « cinq erreurs commises » : les sources ne permettent pas d'affirmer que ces contrôles étaient absents. Ce sont les enseignements IAM que nous tirons du cas.
1 — Gouverner l'intégration comme une identité
Une intégration sensible doit avoir un propriétaire métier, un propriétaire technique, une finalité, un fournisseur, une liste des ressources accessibles, des permissions documentées, une procédure de révocation, une fréquence de revue et un événement de fin de vie.
C'est exactement le cycle de vie que l'on applique aux humains : onboard, modify, review, offboard.
Une identité non-humaine sans propriétaire doit être traitée comme une anomalie.
2 — Appliquer le moindre privilège à l'application
La question n'est pas seulement « cette application a-t-elle accès au CRM ? », mais « pour faire exactement quoi, sur quelles données et avec quelle profondeur ? ».
Concrètement : scopes OAuth, permission sets, objets accessibles, opérations autorisées, séparation des usages, droits réellement nécessaires. FINRA recommande explicitement le moindre privilège pour les applications tierces.
Une compromission ne peut pas toujours être empêchée. Son rayon d'action, lui, peut être conçu à l'avance.
3 — Gouverner les credentials dans le temps
Le credential d'une application a lui aussi un cycle de vie : émission, stockage, rotation lorsqu'elle est pertinente, expiration lorsqu'elle est supportée, révocation, procédure de rotation d'urgence, retrait lorsque l'intégration n'est plus utilisée.
Nous ne fixons pas de durée arbitraire : la bonne politique dépend du protocole et de la plateforme.
4 — Regarder ce que l'identité fait réellement
Un credential valide ne veut pas dire que son usage est normal. Il faut comparer le droit théorique à l'usage observé : nombre d'appels API, fréquence, volume de données, exports massifs, objets consultés, plages horaires, adresses IP, User-Agent, changement brutal de comportement. FINRA recommande précisément de rechercher les exports inhabituels et les patterns d'accès anormaux.
Une intégration CRM qui synchronise habituellement quelques centaines d'objets n'est plus dans son comportement normal lorsqu'elle parcourt soudainement des volumes massifs de données. Même si son token est parfaitement valide.
C'est ici que se rencontrent identité, autorisation, comportement et volumétrie.
5 — Ne pas considérer l'autorisation initiale comme éternelle
Sur une API ou une application maîtrisée par l'entreprise, la décision peut aller plus loin que « token valide = accès autorisé » : le point d'application demande une décision, le moteur de politique évalue identité, ressource, action, contexte et risque, puis autorise ou refuse.
Une intégration peut avoir le droit de lire une donnée, sans avoir le droit de lire cette catégorie de données, à ce volume, depuis ce contexte, à cet instant, ou après un signal de risque. Nous ne prétendons pas qu'un moteur d'autorisation aurait protégé cette architecture précise : c'est une capacité supplémentaire sur les ressources que l'organisation maîtrise, pas une remédiation universelle au SaaS tiers.
Une identité compromise ne devrait pas pouvoir extraire librement toutes les données auxquelles elle a théoriquement accès.
Voir comment Ariovis conçoit la prévention des fuites de donnéesAriovis vous aide à cartographier les identités humaines et non-humaines, leurs droits, leurs usages réels et les contrôles permettant de réduire le risque d'exfiltration.
