Le ransomware sans chiffrement : pourquoi le pire est devant nous

En 2026, les groupes les plus dangereux ne chiffrent plus rien. Ils volent, menacent, publient. Et c'est précisément ce qui les rend redoutables : on ne peut pas restaurer ce qu'on n'a pas perdu, et on ne peut pas négocier ce qui est déjà publié.

La fin du modèle "pay or restore"

Pendant cinq ans, le ransomware a suivi un schéma stable. L'attaquant pénétrait, se déplaçait latéralement, désactivait les sauvegardes, chiffrait les données, et présentait sa note. La victime avait alors un choix binaire : payer pour la clé, ou restaurer depuis des backups. Tout le débat sécurité s'est construit autour de cette équation : sauvegardes immutables, segmentation, détection précoce, plan de continuité. Et globalement, ça a marché. Les organisations matures ont appris à ne plus payer, à restaurer en quelques jours, à absorber le coup.

En 2026, ce modèle est en train de mourir. Pas parce que les attaquants ont perdu, mais parce qu'ils ont changé de jeu. Quand on regarde les leaks récents — ShinyHunters sur Instructure (275 millions d'utilisateurs), Cushman & Wakefield (500 000 enregistrements Salesforce), Match Group, Adelante en Colombie — un pattern frappe : aucun chiffrement. Juste de l'exfiltration, et la menace de publication.

Ce n'est pas un détail technique. C'est une mutation stratégique qui rend l'ensemble de notre arsenal défensif partiellement obsolète.

Pourquoi les attaquants abandonnent le chiffrement

Le chiffrement, pour un attaquant, c'est cher. Il faut développer (ou louer) un payload résistant aux EDR, bypasser les protections kernel, gérer la propagation latérale, contrôler le timing. C'est aussi détectable : les comportements de chiffrement massif déclenchent énormément d'alertes, les modèles MLs des EDR modernes sont très entraînés là-dessus. Et c'est risqué : si le chiffrement échoue partiellement, la victime restaure, ne paye pas, et l'attaquant a brûlé ses outils pour rien.

L'extorsion-only, c'est l'inverse. L'empreinte technique est minimale : l'attaquant utilise des intégrations légitimes (OAuth, jetons API, comptes de service compromis) pour exfiltrer. Pas de payload, pas de chiffrement, pas de propagation. Côté détection, tout passe par des canaux normaux — Salesforce vers Salesloft, c'est du flux légitime, sauf que les volumes ont explosé. Et côté monétisation, la pression est plus efficace : il n'y a pas de "restauration" possible. Les données sont déjà dehors. Soit la victime paye pour empêcher la publication, soit elle assume la fuite.

Le calcul économique est imbattable pour l'attaquant. Coût marginal d'attaque divisé par cinq, surface de détection réduite, taux de paiement comparable voire supérieur sur certains segments (services financiers, santé, éducation où le risque réputationnel est extrême).

Les défenses traditionnelles deviennent partiellement inutiles

Tout ce qu'on a construit ces dernières années est calibré pour le ransomware classique. Les sauvegardes immutables ? Inutiles si rien n'est chiffré. La segmentation réseau ? Contournée par des canaux SaaS-to-SaaS qui passent par Internet, pas par le réseau interne. Les EDR ? Aveugles sur les jetons OAuth qui s'authentifient légitimement. Les playbooks de réponse à incident ? Construits autour du chiffrement, du PRA, de la communication de crise post-encryption.

Concrètement, j'ai vu des RSSI fiers d'avoir investi 800k€ dans une solution de backup immutable et un PRA testé tous les 6 mois. Ils sont protégés contre le ransomware d'il y a deux ans. Pas contre ShinyHunters de mai 2026. La question n'est pas "combien de temps pour restaurer", mais "comment empêcher l'exfiltration en premier lieu, et comment détecter qu'elle s'est produite avant de voir nos données sur un leak site".

Ce qu'il faut commencer à faire

D'abord, accepter que la chaîne d'attaque a basculé du périmètre vers les identités et les SaaS. Le maillon faible n'est plus le firewall ou le poste utilisateur — c'est le compte Salesforce, le jeton Salesloft, l'intégration OAuth oubliée depuis 2023. Tant qu'on raisonne "réseau interne sécurisé", on rate l'attaque.

Concrètement, ça veut dire :

Inventaire exhaustif des intégrations SaaS-to-SaaS

Combien d'applications OAuth ont accès à votre tenant Microsoft 365, votre Google Workspace, votre Salesforce ? La plupart des organisations sous-estiment ce chiffre d'un facteur 5 à 10. Pour chaque intégration, vérifiez le périmètre de droits accordés, la dernière utilisation effective, et le propriétaire interne. Toute intégration sans propriétaire identifié ou non utilisée depuis 6 mois doit être révoquée.

Surveillance volumétrique des exfiltrations légitimes

Salesforce Shield, Microsoft Purview, Google DLP — les outils existent pour détecter les volumes anormaux d'API calls et de download. Le problème, c'est que personne ne configure les seuils correctement. Une exfiltration ShinyHunters classique télécharge 500 000 à 5 millions d'enregistrements en quelques heures. C'est détectable. Mais seulement si les seuils sont configurés et les alertes routées vers une équipe qui les traite.

Détection de l'abus de jetons OAuth

Les jetons OAuth qui s'authentifient depuis une géographie inhabituelle, ou qui appellent une API peu utilisée auparavant, sont des signaux faibles à exploiter. Microsoft Defender for Cloud Apps, par exemple, le permet de manière native. Encore faut-il l'activer et router les alertes correctement.

Gestion des secrets et rotation des jetons

La compromission de Salesloft Drift en août 2025 a révélé que beaucoup d'organisations utilisaient encore des jetons OAuth créés plusieurs années auparavant, jamais rotés. La rotation périodique des jetons (90 jours maximum) doit devenir une norme, au même titre que la rotation des mots de passe administrateur.

Préparer la communication de crise post-fuite

Le scénario "nos données sont sur un leak site" doit être joué en exercice. Qui prend la parole ? Comment annoncer aux clients, aux salariés, aux régulateurs ? Quelle est la position juridique sur le paiement de la rançon ? Les organisations qui n'ont pas répété ce scénario réagissent mal et amplifient le dommage réputationnel.

L'angle régulatoire qui change la donne

NIS2 et DORA imposent maintenant la déclaration des incidents même sans chiffrement, dès qu'il y a "atteinte à la disponibilité, l'intégrité ou la confidentialité". Les régulateurs commencent à comprendre que l'exfiltration sans chiffrement est aussi grave — voire plus — qu'un chiffrement classique. La CNIL a déjà sanctionné des organisations qui avaient minimisé des fuites de données massives parce qu'il n'y avait "pas de ransomware au sens strict".

Pour les organisations relevant de NIS2 (transposée en France par le décret du 17 octobre 2025), une exfiltration majeure non détectée pendant plusieurs semaines constitue un manquement caractérisé aux obligations de surveillance. Les sanctions vont jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires mondial — autant que le RGPD. Et contrairement au RGPD, NIS2 sanctionne aussi le défaut de mesures techniques préventives, pas seulement le défaut de notification.

Conclusion

Le ransomware sans chiffrement n'est pas une mode passagère. C'est l'aboutissement logique d'une trajectoire que les attaquants ont entamée il y a deux ans, accélérée par la disponibilité des chaînes d'intégration SaaS et par l'industrialisation des compromissions OAuth. ShinyHunters n'est que la version visible de ce qui devient le standard.

La question n'est plus "comment restaurer après chiffrement", mais "comment empêcher que mes données ne soient publiées sur un leak site la semaine prochaine". Les défenses doivent suivre. Et le timing est court : les organisations qui auront fait ce pivot en 2026 absorberont les attaques. Celles qui resteront focalisées sur le périmètre et les sauvegardes paieront — au sens propre comme au sens figuré.