Extorsion SaaS : vos intégrations tierces, vecteur numéro un

Zara via Anodot-Snowflake, 7-Eleven via Salesforce, Vercel via Context.ai : en quinze jours de mars 2026, les trois compromissions médiatisées les plus spectaculaires reposent toutes sur le même schéma. Ce n'est plus votre SI qui tombe, c'est un SaaS tiers qui vous porte préjudice par ricochet. Les groupes d'extorsion ont terminé leur mutation : ils ne sont plus des hackers qui cassent des portes, ils sont des gestionnaires de risques inversés qui cherchent le maillon de votre stack dont la surveillance est la plus faible. Et très concrètement, la plupart des RSSI que je rencontre n'ont pas la cartographie pour s'en défendre. Pas faute de budget, pas faute d'intention — faute de méthode et d'un référentiel qui intègre la dépendance SaaS comme un vecteur d'attaque de premier rang. Cet article déconstruit le schéma, chiffre le risque, et vous donne trois actions concrètes que vous pouvez lancer cette semaine.

Le SaaS tiers est devenu le vecteur numéro un : les chiffres le prouvent

En 2025, selon le rapport Verizon DBIR, les compromissions via des tiers représentaient déjà 15 % des brèches analysées. En 2026, les premières estimations croisées entre CrowdStrike et Mandiant suggèrent que ce chiffre a grimpé à plus de 25 % pour les incidents impliquant des données sensibles. Ce n'est pas une mode : c'est une logique économique implacable.

Les groupes d'extorsion comme ShinyHunters, Scattered Spider et leurs successeurs ont réalisé avant la plupart des RSSI que la vraie surface d'attaque d'une grande entreprise n'est plus dans son infrastructure interne — elle est dans son écosystème SaaS. Marketing automation, CRM, data warehouse, observabilité, plateformes d'analytics, connecteurs iPaaS : chaque outil intégré est potentiellement une porte vers vos données. Le calcul est trivial : un seul pivot technique chez un éditeur SaaS, et c'est potentiellement plusieurs dizaines de clients finaux compromis en cascade. Pour ShinyHunters, c'est un multiplicateur de victimes qui transforme un effort d'intrusion unique en une opération d'extorsion industrielle.

L'exemple Snowflake de 2024 reste le cas d'école. Via des credentials volés chez des clients et des partenaires de Snowflake (notamment via des malwares infostealer sur les machines de DBA), le groupe a accédé aux environnements Snowflake d'AT&T, de Santander et de dizaines d'autres entreprises. Pas une seule ligne de code Snowflake n'a été touchée. Pas une seule faille CVE exploitée. Juste des credentials réutilisés, une MFA absente, et des tokens OAuth à durée de vie trop longue. En 2026, les successeurs de ce schéma sont devenus encore plus méthodiques.

Ce qui était autrefois du supply chain attack réservé aux APT sponsorisées — SolarWinds, 3CX, XZ Utils — est devenu le mode opératoire standard des groupes criminels. Le ROI est évident : vous frappez un maillon dont la surveillance est nécessairement inférieure à celle d'une grande entreprise, vous récupérez des tokens OAuth à durée de vie trop longue, et vous vendez ensuite les accès par lots sur votre forum préféré.

Anatomie technique d'une compromission SaaS tierce : comment ça marche réellement

Pour comprendre pourquoi vos défenses actuelles ne suffisent pas, il faut décomposer le schéma d'attaque. Il suit systématiquement le même enchaînement en cinq étapes que j'observe en analyse post-incident.

Étape 1 — Reconnaissance passive des intégrations. L'attaquant n'a pas besoin d'accéder à votre SI pour savoir quels SaaS vous utilisez. Les offres d'emploi mentionnent les outils (« maîtrise de Snowflake et dbt »), les sites commerciaux listent les partenaires technologiques, les badges de certification ou de partenariat sont publiquement affichés. En 24 heures, un attaquant motivé peut dresser une cartographie approximative de votre stack SaaS à partir de sources ouvertes uniquement.

Étape 2 — Ciblage du maillon faible. Parmi vos intégrations SaaS, l'attaquant identifie celles dont la posture de sécurité est la moins rigoureuse. Ce sont généralement les startups qui ont grandi vite, les éditeurs niche rachetés par un plus grand groupe mais dont l'infrastructure n'a pas encore été harmonisée, ou les plateformes open-source auto-hébergées par des équipes sans expertise sécurité dédiée.

Étape 3 — Compromission de l'éditeur ou du connecteur. L'attaque cible soit l'éditeur directement (via une faille de son infrastructure, un insider, ou un prestataire), soit le connecteur lui-même (une intégration mal configurée qui expose un webhook ou une API sans authentification adéquate). Dans les cas Anodot et Context.ai, les investigations suggèrent des compromissions via des credentials de développeurs récupérés sur des dépôts publics ou via infostealer.

Étape 4 — Pivotage vers les clients. Une fois dans l'infrastructure de l'éditeur, l'attaquant exploite les tokens OAuth, les API keys ou les sessions persistantes pour accéder aux environnements clients. Les accès sont souvent scoped trop largement — un connecteur analytics qui a accès en lecture à l'intégralité du datawarehouse alors qu'il n'a besoin que d'un sous-ensemble de tables.

Étape 5 — Exfiltration et extorsion. Les données sont exfiltrées, le client est notifié de la compromission avec une demande de rançon. La pression est double : les données personnelles de vos clients sont en jeu, et la notification RGPD (72 heures) aggrave la pression temporelle. L'attaquant sait que vous avez moins de trois jours pour contenir l'incident avant que la machine réglementaire ne s'emballe.

Trois incidents réels documentés en 2025-2026

Cas 1 — Snowflake et la cascade de victimes (2024-2025). L'incident Snowflake n'est pas une faille de Snowflake. C'est une exploitation systématique de credentials clients volés via des malwares infostealer (principalement LummaC2 et Raccoon Stealer). Sur 165 clients identifiés comme touchés selon Mandiant, la quasi-totalité avait des comptes Snowflake sans MFA activée et des tokens à durée de vie illimitée. La leçon : un éditeur SaaS sécurisé n'empêche pas la compromission si les pratiques d'authentification côté client sont défaillantes. AT&T a reconnu l'exfiltration de données d'appel pour 110 millions de clients. La facture réglementaire est en cours.

Cas 2 — Cloudflare via un fournisseur SSO (novembre 2023). Cloudflare a révélé en 2024 que des attaquants liés à un État avaient accédé à ses systèmes internes via des tokens Okta compromis lors de l'incident Okta de 2023. Là encore, la chaîne : compromission d'un fournisseur de SSO → accès à des dizaines de clients enterprise. Cloudflare avait fait le minimum : pas tous leurs tokens ont été révoqués après l'incident Okta. Ce délai de quelques semaines a suffi.

Cas 3 — Change Healthcare via ConnectWise ScreenConnect (2024). L'une des attaques les plus coûteuses de l'histoire de la santé américaine — plus d'un milliard de dollars de pertes estimées — a utilisé ConnectWise ScreenConnect comme vecteur initial. CVE-2024-1709, un auth bypass CVSS 10.0, exploitée quelques jours après disclosure. Change Healthcare utilisait ScreenConnect pour la télémaintenance. L'accès au réseau interne de UnitedHealth Group a suivi, avec le ransomware ALPHV en payload final. Les données de 190 millions d'Américains ont été exfiltrées.

Ce que les SOC ne regardent pas — et pourquoi

Quand j'audite un SI en 2026, on parle encore d'EDR, de SIEM, de MFA sur Active Directory. La question clé que peu d'équipes se posent : combien de vos tiers ont un accès OAuth permanent à vos données, et qui les révoque ? Dans neuf organisations sur dix, la réponse est : personne.

Les intégrations accumulées depuis cinq ans restent actives même lorsque l'outil n'est plus utilisé. Les tokens émis par les anciens admins survivent à leur départ. Les service principals Azure et les service accounts GCP créés pour des POC oubliés continuent de tourner. J'ai audité récemment une ETI de 800 personnes qui avait 47 connecteurs OAuth actifs sur Google Workspace, dont 23 correspondaient à des applications que l'entreprise n'utilisait plus depuis au moins deux ans. Onze de ces applications n'avaient plus de mainteneur identifiable.

La visibilité SaaS côté client est souvent dramatique. On découvre en audit des connecteurs Snowflake actifs chez des fournisseurs qui ont eux-mêmes été revendus à deux reprises depuis la signature du contrat. On découvre des portées OAuth Salesforce accordées à des apps tierces qui ne sont plus maintenues. Ce sont exactement ces zones grises que les groupes comme ShinyHunters exploitent.

Pourquoi les SOC ne voient pas ces accès ? Parce que les outils SIEM classiques collectent les logs des systèmes que vous maîtrisez — Active Directory, firewalls, EDR. Ils ne collectent pas nativement les logs d'activité OAuth de vos SaaS tiers. Quand un connecteur Snowflake exfiltre 200 Go de données de votre datawarehouse via une session OAuth légitime, votre SIEM ne voit rien. La requête est authentifiée, le token est valide, le comportement est indiscernable d'un accès légitime à moins d'avoir mis en place une baseline comportementale préalable sur ces accès.

Implications pratiques pour les RSSI et équipes sécurité

La première implication, c'est l'inventaire. Vous ne pouvez pas défendre ce que vous ne connaissez pas. Cet inventaire doit couvrir plusieurs dimensions : quels SaaS sont connectés à quelles sources de données internes, via quels mécanismes d'authentification (OAuth, API key, webhook, IP whitelist), avec quel scope de permissions, depuis combien de temps, et quel est le propriétaire métier et technique de chaque intégration.

La deuxième implication concerne le cycle de vie des accès. L'approche « provisioning facile, déprovisioning jamais » est le péché originel du SaaS enterprise. Il faut implémenter des processus de revue périodique (trimestrielle au minimum) de tous les accès SaaS, avec révocation automatique des accès inactifs depuis plus de 90 jours. Certains outils de SSPM (SaaS Security Posture Management) comme Obsidian Security, AppOmni ou Grip Security automatisent une partie de ce travail, mais l'inventaire initial reste un effort manuel.

La troisième implication, souvent négligée, est contractuelle. Vos contrats SaaS actuels laissent probablement votre fournisseur libre de communiquer à son rythme en cas d'incident. C'est inacceptable pour un fournisseur qui a accès à vos données sensibles. Exigez des clauses de notification sous 24 heures, des droits d'audit de sécurité annuels, et des engagements sur les délais de patch pour les vulnérabilités critiques. Ces clauses sont négociables — surtout avec les éditeurs de taille moyenne qui ont besoin de vos contrats.

Ce que je recommande concrètement : la liste technique

Premièrement, lister tous les tokens OAuth actifs sur vos SaaS majeurs (Microsoft 365, Google Workspace, Snowflake, Salesforce, GitHub) et les confronter à la liste des prestataires encore sous contrat. Toute intégration non justifiée par un contrat actif doit être révoquée dans la semaine. Cela dépoussière en général 30 à 60 % des accès.

Deuxièmement, imposer une durée de vie maximale aux tokens — 90 jours est raisonnable, 7 jours est idéal pour les intégrations critiques — et forcer le renouvellement via un workflow validé. C'est inconfortable pour les équipes métier, mais cela tue net 80 % des scénarios d'extorsion par tiers.

Troisièmement, déployer une solution de SSPM pour les SaaS critiques. Ces outils analysent en continu les configurations de sécurité de vos SaaS (MFA activée, sessions longues, accès excessifs) et alertent sur les dérives. Ce n'est pas un remplacement de l'inventaire manuel initial, mais c'est un filet de sécurité indispensable pour maintenir la posture dans le temps.

Quatrièmement, intégrer les logs d'activité SaaS dans votre SIEM. Les API d'audit de Salesforce, Snowflake, GitHub et Okta exposent des logs d'activité détaillés. Collecter ces logs et créer des règles de détection comportementale (exfiltration volumétrique hors des plages horaires habituelles, accès depuis de nouvelles IP géographiques, scope d'accès inhabituellement large) permet de détecter une compromission SaaS avant que le dégât soit irréversible.

Cinquièmement, et c'est le plus négligé : exiger contractuellement de vos SaaS critiques qu'ils vous notifient sous 24 heures tout incident impactant leurs infrastructures. La plupart des contrats standards laissent l'éditeur libre de communiquer à son rythme, ce qui transforme les 24 premières heures — les plus précieuses — en zone aveugle. Pour les fournisseurs qui accèdent à des données de santé ou à des données financières, cette clause doit être un prérequis non négociable.

Conclusion

ShinyHunters n'a pas inventé le modèle de l'extorsion via SaaS tiers, mais il l'a industrialisé au point d'en faire la norme. Les deux prochaines années vont voir une multiplication des cas où une PME ou une ETI française se retrouve en fuite de données non parce qu'elle a été piratée directement, mais parce que son fournisseur analytics, son plugin Slack, son module de gestion des congés ou son SSO partenaire l'a été.

La bonne nouvelle, si on peut appeler ça comme ça : le risque est adressable avec des moyens organisationnels plus que technologiques. L'inventaire des accès OAuth, la révocation systématique des tokens inactifs, les clauses contractuelles de notification — tout cela est à votre portée dès cette semaine. Ce qui manque dans la plupart des organisations, c'est la décision de le faire, pas les outils pour l'exécuter.

Anticiper, c'est d'abord cartographier. Et cette cartographie commence maintenant, pas à la prochaine ligne budgétaire.