L’essentiel en 30 secondes
- La double extorsion vole les données avant de chiffrer, puis menace de les publier.
- Les sauvegardes traitent le chiffrement, mais elles ne rendent pas les données volées.
- L’étape à tester en priorité est donc l’exfiltration : avec des leurres, et en continu pour voir quand un contrôle régresse.
La double extorsion est une forme d’attaque par rançongiciel où l’attaquant vole des données avant de chiffrer le système d’information, puis menace de les publier si la rançon n’est pas payée. Le chiffrement bloque l’activité, la menace de divulgation fait pression sur la réputation, les clients et la conformité. Des sauvegardes saines permettent de redémarrer, mais elles ne rendent pas les données volées : l’étape à tester en priorité est donc l’exfiltration.
Pourquoi la double extorsion change la question posée au RSSI
Pendant des années, la réponse au rançongiciel tenait en un mot : sauvegarde. Des copies hors ligne, testées, immuables, et l’entreprise pouvait refuser de payer. Ce raisonnement reste juste pour la disponibilité. Il ne dit rien de la confidentialité.
Avec la double extorsion, l’attaquant dispose de deux leviers. Le premier, le chiffrement, se traite par la restauration. Le second, la copie des données hors de votre périmètre, ne se traite par rien d’autre que la prévention. Une fois les fichiers sortis, aucune restauration ne les fait revenir. Vous gérez alors une fuite de données, avec ses obligations de notification, ses échanges avec les personnes concernées et ses conséquences commerciales.
41 %
des victimes de rançongiciel ont subi des menaces sur leur réputation : publication ou fuite dans les médias.
Source : IBM, Cost of a Data Breach Report 2026, juillet 2026.
44 %
des cas de rançongiciel : c’est l’attaquant qui a prévenu la victime.
Source : Mandiant, M-Trends 2026.
La question utile n’est donc plus « pouvons-nous restaurer ? » mais « un attaquant installé dans notre réseau pourrait-il faire sortir des volumes significatifs de données sans être bloqué ni détecté ? ». C’est une question de preuve, pas de configuration.
Schéma · deux leviers, deux réponses
Ce que les sauvegardes couvrent, et ce qu’elles ne couvrent pas
| Conséquence de l’attaque | Les sauvegardes aident ? | Contrôle à vérifier |
|---|---|---|
| Systèmes chiffrés, activité arrêtée | Oui, si elles sont isolées et testées | Plan de reprise, restauration régulière |
| Données copiées vers l’extérieur | Non | Filtrage sortant, DLP, détection SOC |
| Menace de publication | Non | Capacité à prouver ce qui est sorti ou non |
| Notification réglementaire | Non | Inventaire des données exposées, traçabilité |
Le tableau résume un point souvent mal compris en comité de direction : un budget sauvegarde bien dépensé laisse intacte la moitié du risque. L’autre moitié dépend des contrôles qui encadrent la sortie de données.
L’exfiltration, l’étape où l’attaque est la plus visible
Dans une attaque à double extorsion, l’exfiltration intervient généralement avant le chiffrement. L’attaquant doit déplacer des volumes importants, souvent sur plusieurs heures ou plusieurs jours. C’est un moment où il s’expose : trafic sortant inhabituel, connexions vers des services de stockage externes, usage d’outils de synchronisation légitimes détournés.
Le référentiel MITRE ATT&CK regroupe ces comportements dans la tactique Exfiltration, que nous détaillons dans notre article sur la tactique TA0010 expliquée aux défenseurs. Pour un défenseur, l’intérêt est simple : chaque technique décrite correspond à un canal qu’il est possible de surveiller et de tester.
Concrètement, les canaux à interroger sont connus :
- les flux web chiffrés vers des services de stockage ou de partage, où l’inspection TLS laisse souvent des exceptions (voir les angles morts de l’inspection TLS) ;
- les protocoles d’infrastructure autorisés par défaut, comme le DNS ;
- les comptes cloud personnels et les outils collaboratifs ;
- les connexions directes depuis des serveurs qui ne devraient jamais parler à Internet.
Si l’un de ces chemins laisse passer des données sensibles sans alerte, vous avez trouvé l’endroit où une double extorsion réussirait chez vous.
Un scénario concret, vu du côté défense
Prenons une ETI industrielle. Les sauvegardes sont exemplaires, restaurées chaque trimestre. Une DLP est déployée sur les postes et la messagerie. Le pare-feu filtre les catégories web à risque.
Un jeudi soir, un attaquant ayant obtenu un accès via un compte de prestataire commence à rassembler les répertoires du bureau d’études sur un serveur de fichiers. Il compresse les archives et les envoie vers un service de stockage grand public, depuis ce serveur, en HTTPS. La DLP endpoint n’est pas installée sur les serveurs. La catégorie du service est autorisée, car un service métier l’utilise. Le SOC reçoit une alerte de volume, mais la règle est classée en sévérité basse et traitée le lundi.
Comment tester l’étape d’exfiltration sans exposer de donnée réelle
Tester ce que ferait un attaquant ne signifie pas déplacer vos vraies données. La bonne pratique consiste à travailler avec des leurres : des fichiers factices qui ressemblent à vos données sensibles (formats, marqueurs de classification, motifs détectables par la DLP) sans en contenir aucune. Le sujet est développé dans notre article sur les données factices en production.
Les étapes de préparation
- Choisir les données qui comptent. Celles dont la publication ferait le plus de dégâts : données personnelles clients, plans, contrats, données RH.
- Cartographier les points de départ. Postes utilisateurs, mais aussi serveurs de fichiers, bases, environnements cloud et applicatifs, là où un attaquant rassemblerait les données.
- Lister les canaux de sortie. Web, DNS, messagerie, stockage cloud, outils collaboratifs.
- Définir le résultat attendu pour chaque scénario. Bloqué, détecté, ou les deux, et dans quel délai.
- Prévenir les bonnes personnes. Le SOC doit pouvoir traiter les alertes sans déclencher une crise, mais pas assez informé pour fausser la mesure de détection.
Ce que vous devez obtenir à la fin
- pour chaque scénario d’attaque, un statut clair : bloqué, détecté, ou passé inaperçu ;
- le délai entre la sortie des données factices et l’alerte au SOC ;
- une liste d’actions correctives classées par impact, pas un rapport de plusieurs dizaines de pages.
La hiérarchisation compte autant que le constat. Corriger une exception de proxy qui ouvre un canal vers tous les serveurs vaut mieux que dix ajustements de règles sur les postes. Notre article sur la hiérarchisation de la remédiation DLP détaille la méthode.
Et chez vous ?
Vos données sortiraient-elles avant le chiffrement ?
Une démo guidée de 30 minutes, sur des jeux de résultats préétablis, pour voir comment une campagne restitue ce qui sort par chaque chemin de sortie.
Pourquoi un test unique ne suffit pas
Un test annuel donne une photographie. Or votre posture bouge chaque semaine : nouvelle exception de filtrage pour un projet, migration d’une application vers le cloud, mise à jour d’un agent, nouveau prestataire. Chaque changement peut rouvrir un chemin fermé.
Les groupes pratiquant la double extorsion ne testent pas votre réseau une fois par an. Ils cherchent la faille du moment. Rejouer les scénarios en continu permet de voir quand un contrôle régresse, et de le corriger avant qu’il serve.
Questions fréquentes
Qu’est-ce que la double extorsion en cybersécurité ?
C’est une attaque par rançongiciel en deux temps : vol des données, puis chiffrement des systèmes. La victime subit une double pression, payer pour récupérer l’accès et payer pour éviter la publication des données volées.
Des sauvegardes immuables protègent-elles contre la double extorsion ?
Elles protègent la disponibilité, pas la confidentialité. Vous pouvez redémarrer sans payer, mais les données déjà copiées restent entre les mains de l’attaquant. Seule la prévention de l’exfiltration réduit ce second risque.
Peut-on tester l’exfiltration sans risque pour les données réelles ?
Oui, à condition d’utiliser exclusivement des données factices conçues pour déclencher vos règles de détection : aucune donnée réelle ne quitte le système d’information pendant le test. Le test n’est pas neutre pour autant : il déclenche des alertes chez le SOC ou le MSSP et sollicite les postes testés. Nous le cadrons par écrit, avec un SOC prévenu 48 h avant et un arrêt possible en moins de 5 minutes.
Qui doit piloter ce type de test ?
Le RSSI en général, avec le SOC pour la partie détection et le DPO pour le choix des données sensibles à simuler. Dans une ETI sans RSSI dédié, la DSI peut le porter.