Pour une entreprise dotée d'une infrastructure numérique, un incident cybernétique grave n'est pas une menace abstraite. Une attaque peut débuter par la fuite d'une clé API, une tentative de hameçonnage, l'exploitation d'une vulnérabilité, la compromission d'un sous-traitant ou l'utilisation d'identifiants volés. Mais la situation devient particulièrement complexe lorsque, après s’être introduits dans le système, les cybercriminels exigent une rançon pour la restauration des systèmes ou la promesse de ne pas divulguer les informations.

À ce stade, l’entreprise n’est plus seulement confrontée à un problème technique. Les maîtres chanteurs jouent sur la peur, imposent des délais serrés, formulent des exigences exagérées et entretiennent l’incertitude quant au volume des données volées. L’objectif principal est de reprendre le contrôle des décisions et de distinguer les faits avérés des menaces.

Ce que révèlent les incidents PWN-ALL

D’après les analyses internes de PWN-ALL, parmi les causes identifiées de compromission figuraient des fuites de clés API et d’autres clés d’accès chez des tiers (28,3 %), des mots de passe faibles ou par défaut (18 %) et l’exploitation de vulnérabilités logicielles (7 %). Parmi les autres scénarios, on peut citer le phishing, les infostealers et la compromission de comptes.

1. « Vous avez 72 heures » : jouer sur l’urgence

Dans un courrier adressé à la direction ou au service de sécurité informatique, les ravisseurs peuvent fixer un délai de 72 à 120 heures. Passé ce délai, ils promettent de publier les données, d’augmenter le montant réclamé ou de contacter les clients et les journalistes. Généralement, ces menaces s’accompagnent d’une description des conséquences financières, réputationnelles et juridiques présumées.

Ce compte à rebours est un moyen de pression, et non une preuve en soi de l’ampleur de l’attaque. Il doit être pris en compte lors de la réaction, mais ne doit pas remplacer le processus décisionnel. De plus, l’attaquant est capable de publier les informations avant même son propre délai.

Première prise de contact : une vérification, pas une reconnaissance

La réception d’une demande n’oblige pas l’entreprise à entamer immédiatement une correspondance. Si un contact s’avère néanmoins nécessaire, il est préférable de le faire par l’intermédiaire d’un spécialiste formé à la réponse aux incidents (Incident Response) ou d’un négociateur, avec la participation de l’équipe juridique. La boîte mail personnelle du directeur ou les réponses individuelles des collaborateurs constituent une mauvaise base pour un processus maîtrisé.

« Nous avons bien reçu votre message et vérifions actuellement les allégations qui y sont formulées. Des éléments justificatifs sont nécessaires pour évaluer l’accès revendiqué et la nature des données. La réception de ce message ne signifie en aucun cas une reconnaissance de l’étendue de la compromission alléguée ni un accord de paiement. »

Il s’agit là d’un exemple illustrant une position possible, et non d’un modèle de réponse universel. La décision d’envoyer ou non un message, et sous quelle forme, doit tenir compte des circonstances de l’incident, des recommandations juridiques et des exigences de l’assureur.

La communication permet parfois de gagner du temps, mais ne garantit pas un report de la publication et ne suspend pas les délais légaux obligatoires. Parallèlement, il est nécessaire de limiter l’accès du pirate, de conserver les preuves et de vérifier les copies de sauvegarde.

2. « Nous avons tout volé » : la manipulation du volume de données

Les attaquants affirment souvent avoir dérobé l’ensemble de la documentation, du code source, des bases de données clients ou des dizaines de téraoctets d’informations. À l’appui de leurs dires, ils montrent la structure des répertoires, les noms de projets et quelques fichiers. Mais la liste des éléments ne prouve pas encore l’existence de leur contenu.

Accès, lecture et exfiltration : des situations différentes

Un compte ou une clé API compromis peut disposer de droits limités. Par exemple, list certains services permettent de voir les noms des objets et les métadonnées sans accéder au contenu. Une opération read peut renvoyer les données elles-mêmes et permettre ainsi leur copie. Certaines opérations download ou export ne sont pas disponibles dans tous les systèmes.

Il n’existe pas de hiérarchie universelle des droits de type « list → read → download ». Il convient d’évaluer la plateforme concernée, les autorisations attribuées et les requêtes effectivement exécutées. La possibilité de lire un fichier ne prouve pas pour autant qu’il a effectivement été téléchargé, et l’absence d’une autorisation distincte de téléchargement n’exclut pas la copie via la lecture.

Vérification des preuves en cas de journaux incomplets

L’équipe IR doit avant tout utiliser des sources indépendantes : journaux d’authentification et d’API, audit du cloud, EDR/XDR, événements de connexions réseau, modifications des droits d’accès et informations sur une éventuelle préparation et exfiltration de données. Il convient de déterminer quelles ressources étaient accessibles, quelles données ont effectivement été lues et quels indices d’exfiltration subsistent.

Si les journaux sont incomplets, on ne peut affirmer automatiquement ni l’absence de fuite, ni la véracité des déclarations du maître chanteur. Cette incertitude doit être clairement mentionnée dans l’évaluation des risques.

Un échantillonnage contrôlé parmi l’ensemble déjà déclaré par l’attaquant peut constituer un moyen de vérification supplémentaire. Par exemple, l’équipe IR sélectionne des fichiers au hasard parmi plusieurs projets indiqués par le cybercriminel et vérifie s’il est en mesure de prouver qu’il détient leur contenu actuel, et pas seulement leurs noms. La procédure doit être convenue à l’avance : il ne faut pas révéler à l’attaquant une structure de répertoires qui lui est inconnue, ni lui envoyer des informations confidentielles supplémentaires, ni provoquer un nouveau vol de données.

Une telle vérification a ses limites. La présentation de cinq fichiers sélectionnés ne confirme pas la possession de cinq millions de fichiers. À l’inverse, le refus ou l’incapacité à présenter un seul échantillon ne prouve pas que les autres données n’ont pas été copiées.

Pour l’analyse, il est utile de distinguer quatre conclusions :

  1. L'attaquant a accédé au système.
  2. Il a pu consulter certains objets ou leurs métadonnées.
  3. Il a effectivement obtenu le contenu de fichiers spécifiques.
  4. Il dispose d’une copie de l’ensemble des données déclarées.

Chaque affirmation suivante nécessite des preuves supplémentaires. L’attaquant ne doit pas être à la fois la seule source de preuves et le principal évaluateur des dommages.

3. Les millions de dollars mentionnés dans la lettre ne constituent pas encore le montant définitif

La demande initiale reflète la position du maître chanteur. Il ne s’agit ni d’un prix fixé ni d’une valeur objective de la restauration. Dans les cas anonymisés connus de PWN-ALL, on a constaté un écart significatif entre la somme demandée et celle effectivement versée :

Demande initiale Paiement effectif Réduction
50 000 000 $15 000 000 $70 %
1 000 000 $75 000 $92,5 %

Dans le troisième exemple fourni, l’entreprise a versé 10 000 $ en échange de la promesse de supprimer les données. Le simple fait du paiement ne permet pas de confirmer la suppression effective des données.

Il s’agit d’exemples isolés et anonymisés fournis par notre entreprise. Ils ne permettent pas de calculer le résultat moyen des négociations, la probabilité d’un paiement ou une « remise » garantie.

À titre de comparaison : selon le rapport 2026 Unit 42 Global Incident Response Report, la réduction médiane de la demande initiale dans les cas ayant fait l’objet de négociations en 2025 s’élevait à 61 %. Il s’agit là du résultat d’un autre échantillon, qui ne peut être directement comparé aux cas individuels de PWN-ALL.

Une réduction significative de la demande ne rend pas le paiement sans risque. La décision doit s’appuyer sur la capacité à se rétablir de manière autonome, la valeur réelle des informations compromises, le coût de l’indisponibilité, les conséquences possibles pour les clients et les alternatives légales disponibles. Moins l’organisation dépend des promesses de l’attaquant, plus sa position est solide.

4. Risques juridiques : sanctions, assurance et accompagnement

L’affirmation selon laquelle « il est autorisé de payer les maîtres chanteurs » n’est pas universellement valable. Les règles applicables dépendent des juridictions de l’entreprise, des divisions concernées, du secteur d’activité, du destinataire des fonds, de l’itinéraire du paiement et des restrictions en vigueur. Pour certaines organisations ou certains bénéficiaires, le paiement peut être interdit.

En particulier, l’OFAC américain met en garde contre les risques de sanctions liés aux paiements de rançon. L’OFSI britannique indique également que le transfert de fonds ou de crypto-actifs à une personne soumise à des sanctions peut entraîner de graves conséquences. Le fait d’être victime d’un crime ne dispense pas automatiquement une organisation des exigences en matière de sanctions.

Avant tout examen d’un paiement, il est nécessaire de procéder à une vérification juridique des adresses connues, du bénéficiaire présumé, des entités liées et des restrictions applicables. La vérification d’un seul portefeuille de crypto-monnaie ne garantit pas à elle seule la légalité du transfert.

Les juristes doivent intervenir dès le premier jour

L’équipe juridique accompagne l’incident à chaque étape : elle identifie les obligations envers les régulateurs et les clients, coordonne la communication externe, aide à conserver les preuves, vérifie les restrictions liées aux sanctions et documente les motifs des décisions. Il est trop tard de faire appel à des juristes uniquement juste avant le paiement.

Il convient de définir à l’avance les modalités de préparation des rapports techniques, d’accès à la correspondance interne et de transmission des documents à des tiers. Dans certaines juridictions, certaines communications peuvent être protégées par le secret professionnel ou le « legal privilege ». Cependant, le recours à un avocat ne rend pas automatiquement confidentiels tous les documents et les résultats de l’enquête : l’applicabilité de ce régime nécessite une évaluation juridique distincte. Voir les explications de l’American Bar Association.

Si vous disposez d’une assurance cyber, vérifiez immédiatement votre police

L'assureur ou le courtier doit être informé en temps utile de l'incident, conformément aux conditions du contrat. Certaines polices prévoient des prestataires de services de gestion des incidents (IR) agréés, des conseillers juridiques, ainsi que des exigences en matière de notification et d’accord préalable pour certaines dépenses ou actions.

Il ne faut pas promettre de rançon de son propre chef, faire appel à un négociateur ou engager des dépenses importantes sans avoir vérifié si l’accord de l’assureur est nécessaire. Cela dit, la nécessité d’un tel accord ne doit pas empêcher la prise de mesures urgentes pour contenir l’attaque et préserver les preuves. Le NCSC souligne l’importance d’informer rapidement l’assureur.

Les forces de l’ordre et l’I-GRIP

Le service juridique doit, en collaboration avec la direction et l’équipe d’intervention en cas d’incident (Incident Response), organiser en temps utile la saisine des forces de l’ordre compétentes. Si les fonds ont déjà été transférés, il est particulièrement important de conserver les coordonnées bancaires, les identifiants des opérations, les adresses des portefeuilles, les montants, les horaires et les échanges de messages.

L’un des mécanismes de coopération internationale est l’INTERPOL Global Rapid Intervention of Payments (I-GRIP). Il aide les forces de l’ordre à coordonner rapidement leurs actions visant à endiguer les flux financiers illicites, y compris ceux liés aux actifs virtuels. Toutefois, I-GRIP s’applique avant tout dans le domaine de la fraude financière ; la possibilité de l’utiliser dans le cadre d’un incident spécifique lié à un rançongiciel est évaluée par les autorités compétentes.

L’entreprise ne déclenche pas directement I-GRIP, et son utilisation ne garantit pas le blocage ni le remboursement de la rançon. Il ne faut pas attendre la fin des négociations pour faire appel à ce dispositif. Pour plus de détails, consultez le document d’INTERPOL du 9 juillet 2026.

5. La correspondance et les contacts avec les clients comme moyens de pression supplémentaires

Les ravisseurs peuvent exiger d’un employé qu’il reconnaisse la fuite avant la fin de l’enquête, puis utiliser cette déclaration pour menacer de s’adresser à l’autorité de régulation, aux partenaires ou à la presse. Ils peuvent également écrire directement aux clients, appeler les employés ou menacer de publier la correspondance interne.

Dans le rapport 2026 de l’Unit 42, de telles méthodes de harcèlement ont été relevées dans 10 % des cas de chantage survenus en 2025 au sein de l’échantillon étudié. Il ne s’agit pas d’une estimation portant sur l’ensemble des cyberincidents dans le monde.

L’entreprise doit utiliser un canal de négociation convenu, consigner l’heure et le contenu des messages, limiter le cercle des représentants habilités et préparer à l’avance un plan de communication avec les collaborateurs, les clients et la presse. Il ne faut pas faire passer des suppositions pour des faits avérés, mais il ne faut pas non plus dissimuler un incident avéré pour préserver sa position dans les négociations.

Le délai imposé par l’attaquant ne correspond pas aux délais prévus par la loi

Par exemple, dans le cadre de l’application du RGPD, le responsable du traitement des données à caractère personnel est tenu d’informer l’autorité de contrôle compétente sans retard injustifié et, si possible, au plus tard 72 heures après avoir pris connaissance de la violation de la sécurité des données à caractère personnel, à moins que cette violation ne présente qu’un faible risque pour les droits et libertés des personnes.

En cas de risque élevé probable, il existe une obligation distincte d’informer les personnes concernées sans retard injustifié, sous réserve des exceptions prévues par la loi. Le moment où l’on prend connaissance de la violation est déterminé par un degré raisonnable de certitude quant à l’existence de celle-ci, et non par la formulation de la réponse adressée au maître chanteur. Si tous les détails ne sont pas encore établis, la notification, lorsqu’elle est obligatoire, peut être complétée par étapes. Voir les explications du Comité européen de la protection des données.

D'autres exigences et délais peuvent s'appliquer dans d'autres pays, secteurs d'activité et relations contractuelles. Les négociations avec l'attaquant ne suspendent pas en soi l'obligation de notification.

6. Même après le paiement, il n’y a aucune garantie

Le paiement ne garantit pas la suppression des données, l’obtention d’un décrypteur fonctionnel ou la fin des menaces. Le cybercriminel peut conserver des copies, les transmettre à ses complices, exiger davantage d’argent ou publier les informations malgré ses promesses.

Ceci est également confirmé par d’autres enquêtes réelles. À la suite d’une opération contre LockBit, la National Crime Agency britannique a indiqué avoir découvert, sur l’infrastructure du groupe, des données appartenant à des victimes qui avaient déjà payé la rançon. En d’autres termes, le paiement n’a pas garanti la destruction des informations promise. Source : NCA, 20 février 2024.

Le paiement échelonné ne protège pas contre la publication

Le fractionnement de la rançon en tranches n’apporte aucune garantie technique supplémentaire. Les données peuvent être publiées après le premier versement, avant le suivant ou même après le versement de la totalité de la somme. Même la démonstration de la « suppression » des fichiers ne prouve pas l’absence de copies détenues par d’autres membres du groupe ou stockées sur d’autres supports.

Il est donc plus juste de parler d’un paiement en échange d’une promesse de suppression des données, et non d’un achat confirmé d’une « suppression complète ». De même, une clé de déchiffrement, même si elle fonctionne, ne prouve pas que la vulnérabilité initiale a été corrigée ni que l’accès du pirate à l’infrastructure a été bloqué.

7. Alternative au rançonnage : restauration et évaluation indépendante

Avant d’envisager tout paiement, il convient d’évaluer la possibilité d’une restauration à partir de sauvegardes vérifiées, d’une reconstruction des systèmes et de l’utilisation des outils de décryptage disponibles. Par exemple, No More Ransom publie des décrypteurs gratuits pour certaines familles de logiciels de rançon. La compatibilité de l’outil doit être vérifiée dans un environnement sécurisé ; le déchiffrement en lui-même ne remplace pas la résolution des causes de la compromission.

Selon une évaluation interne de l’entreprise publiée sur la page PWN-ALL Ransomware Recovery, dans environ 94 % des incidents de ransomware auxquels PWN-ALL a participé entre 2024 et 2026, une restauration complète ou partielle a pu être obtenue sans paiement de rançon — grâce à des sauvegardes, à l’étude des moyens de décryptage ou à une reconstruction partielle des données.

Il s’agit d’un indicateur issu de la pratique interne de PWN-ALL, et non d’une statistique auditée de manière indépendante. Cet indicateur ne garantit pas un résultat identique aux futurs clients et ne reflète pas la probabilité de publication des informations déjà détournées.

Dans un autre article de PWN-ALL consacré à la gestion des incidents, nous avons décrit une situation dans laquelle un cybercriminel a commencé à extraire des données d’un stockage AWS à peine six minutes après avoir obtenu la clé. Ce cas particulier illustre pourquoi la conservation des journaux, la restriction rapide des accès et la collaboration entre l’équipe IR, les juristes et la direction sont d’une importance cruciale.

Cependant, le rétablissement de la disponibilité des systèmes n’exclut pas une éventuelle violation de la confidentialité. Les questions relatives à la restauration, à l’exfiltration, aux notifications et à la protection ultérieure doivent être examinées séparément.

Alors, est-il sûr de payer les maîtres chanteurs ?

Non. Le paiement peut être envisagé comme l’un des scénarios possibles dans le cadre d’un incident complexe, s’il est légalement admissible, mais il ne saurait être considéré comme un moyen sûr de « régler l’affaire ».

Il faut agir sur plusieurs fronts simultanément : vérifier les allégations, limiter la compromission, conserver les preuves, évaluer les dommages, faire appel à des juristes et à l’assureur, remplir les obligations de notification, saisir les forces de l’ordre si les motifs le justifient et examiner les possibilités de restauration. La décision concernant un éventuel versement est prise séparément, sur la base d’une évaluation concertée des risques.

C’est non pas lorsque l’entreprise sait négocier qu’elle se trouve dans la position la plus forte, mais lorsqu’elle peut se permettre de ne pas payer.

La question principale n’est pas « dans quelle mesure peut-on réduire la demande d’indemnisation », mais « quels risques subsisteront après le paiement et existe-t-il une alternative moins risquée ? »

Ce document est fourni à titre informatif et ne constitue ni un avis juridique ni une recommandation de procéder à un paiement. La légitimité du paiement, les obligations de notification, les conditions de couverture d’assurance et le recours aux forces de l’ordre doivent être évalués avec l’aide de conseillers qualifiés en droit applicable.

Vous avez reçu une demande de rançon ? Ne prenez pas de décision sous la pression.

Si votre entreprise est victime d’un cyberchantage, d’une menace de publication de données ou d’une compromission de son infrastructure, l’équipe PWN-ALL vous aidera à vérifier les affirmations des attaquants, à déterminer l’ampleur de l’incident, à conserver les preuves, à évaluer les options de restauration et à organiser une réponse aux incidents (Incident Response) maîtrisée.

Fiez-vous à des faits avérés, et non à une date limite ni aux promesses de l’attaquant.

Obtenir l'aide de PWN-ALL en cas d'attaque par chantage →