Un incident cybernétique commence rarement par un message du type « vous avez été piraté ». En général, le premier signe est une connexion suspecte à un compte d’entreprise, une règle de transfert d’e-mails inattendue, un agent EDR désactivé, un serveur inaccessible ou la plainte d’un collaborateur concernant une demande inhabituelle d’authentification multifactorielle.

À ce stade, l’entreprise ignore encore l’ampleur de l’attaque. Or, ce sont précisément les premières décisions qui déterminent si l’incident restera un problème local ou s’il se transformera en une crise de plusieurs semaines entraînant l’arrêt des activités, la perte de données et une atteinte à la réputation.

Le temps disponible pour prendre ces décisions ne cesse de diminuer. Dans les cas les plus rapides étudiés par Unit 42, il a fallu 72 minutes aux cybercriminels pour passer de l’accès initial au déchargement confirmé des données. C’est environ quatre fois plus rapide qu’un an auparavant. Il ne s’agit pas ici d’une moyenne pour l’ensemble des attaques, mais des cas les plus rapides ; ce chiffre illustre toutefois bien à quel point la marge de manœuvre des défenseurs s’est réduite. Dans le cadre de nos propres enquêtes, nous avons pu observer des attaques menées en moins de 10 minutes contre l’infrastructure AWS. Dès qu’il obtenait la clé, le cybercriminel commençait immédiatement à extraire les données. Il ne lui a fallu que 6 minutes pour commencer à extraire des données du compartiment de stockage de l’entreprise.

En 2026, une réponse adéquate ne consistera pas en une intervention héroïque de l’équipe de garde. Il s’agit d’un processus préparé à l’avance et maîtrisé, qui permet de limiter rapidement les actions de l’attaquant, de préserver les preuves, de maintenir les opérations critiques et de remettre les systèmes en service sans nouvelle compromission.

Ce qui aura changé d’ici 2026

Une attaque ne se limite plus à un seul système

Un cybercriminel moderne peut exploiter simultanément l’infrastructure locale, un compte cloud, la messagerie d’entreprise, des applications SaaS et les accès d’un sous-traitant.

Même après l’isolation d’un ordinateur portable infecté, il peut encore disposer :

  • une session cloud active ;
  • un jeton de rafraîchissement ;
  • une autorisation OAuth ;
  • une clé API ;
  • un compte de service compromis ;
  • un accès administratif délégué ;
  • un canal de gestion de secours via un service cloud légitime.

Selon Unit 42, dans 87 % des incidents étudiés, il a fallu recouper des preuves provenant d’au moins deux sources différentes pour établir ce qui s’était passé, et dans les cas les plus complexes, de dix sources. Cela signifie que l’enquête ne peut plus se limiter à un seul ordinateur ou à un seul journal d’événements : il est nécessaire d’analyser simultanément les données d’identification, les terminaux, le réseau, le cloud et les services SaaS. (Unit 42)

Le modèle consistant à « trouver un fichier malveillant, le supprimer et réinstaller l’ordinateur » n’assure plus une protection complète.

Les identités et les vulnérabilités sont tout aussi importantes

Un incident moderne ne présente pas de vecteur d’intrusion unique et universel.

Selon Unit 42, 65 % des intrusions initiales recensées dans ses enquêtes étaient liées à des techniques basées sur l’identité : vol d’identifiants, manipulation de l’authentification multifactorielle (MFA), détournement de session, usurpation de l’identité d’un employé du service d’assistance ou abus d’un accès à distance légitime. (Unit 42)

Parallèlement, le rapport DBIR 2026 de Verizon désigne l’exploitation des vulnérabilités logicielles comme le principal vecteur d’intrusion initial dans son échantillon : elle était en cause dans 31 % des fuites et a, pour la première fois, dépassé les identifiants volés.

Conclusion pratique : il ne faut pas choisir entre la protection des identités et la gestion des vulnérabilités. Un programme de réponse mature doit couvrir ces deux aspects. L’équipe doit être capable à la fois de révoquer les jetons et les sessions, d’analyser les accès privilégiés, de fermer les services externes vulnérables et de déterminer quel chemin précis l’attaquant a emprunté.

Les fournisseurs font désormais partie de la surface d’attaque

Selon le rapport DBIR 2026 de Verizon, des tiers ont été impliqués dans 48 % des fuites, soit 60 % de plus que l’année précédente. Un éditeur de logiciels, un MSP, un intégrateur, un service cloud ou un sous-traitant disposant d’un accès légitime peut servir de point d’entrée.

L’organisation doit savoir à l’avance :

  • qui est en mesure de fournir les journaux du fournisseur ;
  • à quelle vitesse son accès peut être révoqué ;
  • combien de temps les données de télémétrie sont conservées ;
  • quelles actions sont autorisées par le contrat ;
  • qui est responsable de la communication ;
  • comment conserver des preuves au sein d’une infrastructure tierce.

Si ces questions se posent pour la première fois au cours d’une attaque, l’équipe perd déjà un temps précieux.

Le chantage ne nécessite plus de chiffrement

Le chiffrement de l’infrastructure reste une menace sérieuse, mais il ne constitue plus un élément obligatoire du chantage. Les cybercriminels peuvent dérober des données et passer immédiatement à la menace de publication ou de vente, sans déclencher les événements de chiffrement à grande échelle auxquels les mesures de protection sont traditionnellement préparées.

Les ransomwares étaient présents dans près de la moitié des fuites examinées dans le rapport DBIR 2026 de Verizon. Cependant, l’absence de serveurs chiffrés ne signifie pas que l’incident est mineur : un accès non autorisé à la messagerie, au CRM, au stockage de fichiers ou à un environnement cloud peut entraîner des conséquences financières et réputationnelles tout aussi importantes.

L’IA accélère les deux camps

L’IA aide les attaquants à analyser plus rapidement la surface d’attaque, à adapter leurs techniques d’ingénierie sociale, à rechercher des vulnérabilités et à créer du code malveillant. Le rapport DBIR 2026 de Verizon recense 15 techniques d’attaque qui sont déjà renforcées par l’IA générative.

Les défenseurs, quant à eux, utilisent des modèles pour corréler les événements, établir des chronologies, regrouper les alertes et préparer des requêtes pour la recherche de menaces.

Mais l’automatisation ne remplace pas un processus vérifiable. Une conclusion hâtive et erronée en situation de crise peut s’avérer tout aussi dangereuse qu’une réaction trop lente.

Un nouveau cadre : la réaction commence avant l’incident

En avril 2025, le NIST a publié la norme SP 800-61 Révision 3, qui a remplacé le guide de 2012.

Le principal changement réside dans le fait que la réponse aux incidents n’est plus considérée comme un processus linéaire distinct qui se déclenche après une alerte. Elle est intégrée au modèle global de gestion des cyberrisques NIST CSF 2.0 et est liée à l’ensemble de ses six fonctions :

Gouverner, Identifier, Protéger, Détecter, Réagir et Récupérer.

La gestion des rôles, l’inventaire des actifs, la segmentation, la sauvegarde, les contrats avec les fournisseurs et la journalisation ne sont pas des mesures auxiliaires, mais font partie intégrante de la préparation aux incidents. (Centre de ressources sur la sécurité informatique du NIST)

Le 11 juin 2026, le NIST a également publié l’IR 8374 Révision 1 — un profil actualisé de gestion des risques liés aux ransomwares basé sur le CSF 2.0. Ce document relie la préparation, la protection, la réaction et la reprise au sein d’un cycle unique de gestion des risques. (Centre de ressources sur la sécurité informatique du NIST)

La conclusion principale est simple :

Une réponse adéquate commence bien avant la première alerte.

Avant même qu’un incident ne se produise, l’organisation doit définir les rôles et les responsabilités, mettre en place un canal de communication hors réseau, garantir une conservation suffisante des journaux, sécuriser les sauvegardes et vérifier les procédures de restauration. Des plans d’action spécifiques sont également nécessaires pour les attaques par ransomware, la compromission de la messagerie d’entreprise, le piratage de comptes cloud, le vol de données et les attaques par l’intermédiaire d’un sous-traitant.

Les exercices revêtent une importance particulière. Un plan qui n’existe que sur le papier et qui n’a jamais été testé dans des conditions de contrainte de temps reste une hypothèse et non un outil de protection.

Les 60 premières minutes : ne pas intervenir à l’aveuglette

Au début d’un incident, l’équipe dispose presque toujours d’informations incomplètes.

À ce stade, ce ne sont pas seulement les actions de l’attaquant qui sont dangereuses, mais aussi les décisions impulsives des défenseurs : arrêt massif des serveurs, nettoyage prématuré des systèmes, changement chaotique des mots de passe ou restauration immédiate à partir d’une sauvegarde non vérifiée.

1. Désignez un responsable de l’incident

Une enquête sérieuse ne peut pas se mener à travers des appels téléphoniques désordonnés, des messages privés et des dizaines de discussions parallèles.

Il est indispensable de disposer d’un « response bridge » centralisé et d’un responsable désigné : l’Incident Commander.

Il n’est pas tenu d’effectuer personnellement les opérations d’investigation numérique. Sa mission consiste à gérer le processus :

  • maintenir un plan unique ;
  • désigner les responsables des tâches ;
  • résoudre les conflits de priorités ;
  • consigner les décisions ;
  • synchroniser les flux techniques et managériaux ;
  • mettre régulièrement à jour le statut validé ;
  • contrôler la coordination des actions critiques.

Le spécialiste le plus compétent sur le plan technique ne doit pas nécessairement diriger l'ensemble de la gestion de l'incident. Les analystes enquêtent sur l'attaque, tandis que le commandant des opérations veille à ce que l'enquête ne se transforme pas en une série d'actions non coordonnées.

2. Passez sur un canal de communication sécurisé

Si la messagerie d’entreprise, le système d’authentification ou la messagerie instantanée risquent d’être compromis, il ne faut pas discuter de l’enquête via ces canaux.

Utilisez un canal hors bande préparé à l’avance. Il ne faut pas transmettre via des systèmes potentiellement compromis :

  • les plans d’isolation ;
  • les hypothèses d’enquête ;
  • les nouveaux mots de passe ;
  • les clés et les jetons ;
  • les preuves recueillies ;
  • informations sur les communications avec l'attaquant ;
  • les décisions internes de la direction.

L'attaquant, qui observe les actions de l'équipe, a ainsi la possibilité de modifier sa tactique, d'effacer ses traces et de préparer à l'avance des canaux d'accès alternatifs.

3. Confirmez l’incident et déterminez son ampleur initiale

Il n’est pas nécessaire d’attendre d’avoir une vue d’ensemble pour commencer à réagir.

L'évaluation initiale doit répondre au moins à cinq questions :

  1. Qu’est-ce qui a été détecté exactement ?
  2. Quels utilisateurs, appareils et services pourraient être affectés ?
  3. L'activité de l'attaquant se poursuit-elle ?
  4. Y a-t-il un risque d'interruption d'un processus critique ?
  5. Y a-t-il des signes de vol de données, de destruction de sauvegardes ou de compromission d’un accès privilégié ?

La classification peut évoluer au fur et à mesure de l’enquête. L’essentiel est de formuler une hypothèse de travail et de définir des priorités le plus tôt possible.

Il est utile de distinguer d’emblée les faits avérés, les conclusions probables, les hypothèses non vérifiées et les circonstances inconnues. Cela réduit le risque qu’une supposition d’un analyste ne serve de base à une décision managériale désastreuse.

4. Isolez les preuves, mais ne les détruisez pas

Isoler et mettre hors service ne sont pas la même chose.

Un hôte compromis doit généralement être déconnecté du réseau à l’aide d’EDR, de NAC, d’un VLAN, d’un commutateur ou d’une politique cloud. Mais il ne faut pas, sans raison valable, :

  • l'éteindre ou le redémarrer ;
  • supprimer des fichiers ;
  • lancer un nettoyage antivirus ;
  • réinstaller le système d'exploitation ;
  • remettre l'appareil en service après une vérification superficielle.

La mémoire vive peut contenir des clés de chiffrement, des connexions réseau actives, des processus infiltrés, des jetons d’accès, des commandes non enregistrées et des traces laissées par les outils du pirate.

Des exceptions sont possibles lorsque la poursuite du fonctionnement du système représente une menace inacceptable pour les personnes, les infrastructures critiques ou l'activité. Mais une telle décision doit être prise en toute connaissance de cause et consignée dans le journal des incidents.

5. Établissez une chronologie unique

Consignez chaque événement significatif :

  • l'heure du premier signal ;
  • la source de la détection ;
  • le changement d'état des systèmes ;
  • les instructions des administrateurs ;
  • l'isolation des appareils ;
  • le blocage des comptes ;
  • exportation des journaux ;
  • la création de snapshots ;
  • les décisions prises ;
  • les responsables et les personnes ayant approuvé les actions.

Utilisez un fuseau horaire unique, de préférence l’UTC. Conservez les journaux d’origine séparément des copies de travail, calculez les sommes de contrôle des fichiers collectés et consignez qui a manipulé les preuves et à quel moment.

Sans chronologie, l’enquête se transforme rapidement en un ensemble de souvenirs contradictoires.

6. Protégez vos sauvegardes

Lors d’un incident de ransomware, les systèmes de sauvegarde sont souvent l’une des premières cibles de l’attaquant.

Ne lancez pas de restauration à grande échelle tant que vous n’avez pas déterminé :

  • si le pirate a accès à la console de sauvegarde ;
  • si les comptes des opérateurs ont été compromis ;
  • si les instantanés ont été supprimés ;
  • si les politiques de stockage ont été modifiées ;
  • quand l'intrusion initiale a vraisemblablement eu lieu ;
  • si la copie sélectionnée ne contient pas de mécanisme de verrouillage ;
  • si des copies isolées ou immuables ont été conservées.

Le statut « réussi » de la dernière tâche de sauvegarde confirme uniquement que la copie a été créée. Il ne garantit pas qu’elle soit intacte et apte à une restauration sécurisée.

En cas d’incident en cours, l’équipe DFIR de PWN-ALL peut prendre en charge la coordination technique : confinement initial, préservation des preuves, évaluation de l’ampleur de la compromission et élaboration d’un plan de restauration sécurisé. L’entreprise intervient dans les domaines suivants : ransomware, vol de données, BEC, piratage de comptes et compromission d’environnements cloud.

La réponse doit s’effectuer selon plusieurs axes parallèles

Une erreur courante consiste à mener d’abord l’enquête technique à son terme avant de faire intervenir la direction, les juristes, l’assureur et les dirigeants de l’entreprise.

Dans un incident réel, ces volets doivent être menés simultanément.

Volet technique

L’équipe doit localiser l’attaquant, identifier le vecteur d’attaque initial probable, déterminer les actifs et les identités affectés, repérer les mécanismes d’implantation, évaluer l’exfiltration potentielle et préparer une restauration sécurisée.

Flux de gestion

La direction et les responsables des processus doivent évaluer l’impact sur l’activité, établir les priorités de reprise, définir la durée d’indisponibilité acceptable et coordonner les mesures susceptibles d’interrompre les processus critiques.

Voie juridique et de communication

Parallèlement, il est nécessaire d’identifier les propriétaires des données concernées, de vérifier les obligations contractuelles, de déterminer les exigences applicables en matière de notification, de contacter l’assureur et de préparer les communications internes et externes.

Les exigences spécifiques varient en fonction du secteur d’activité, des contrats et des juridictions. C’est pourquoi l’évaluation juridique ne doit pas attendre le rapport d’expertise numérique définitif.

La mission de l’équipe DFIR consiste à fournir à ce flux des faits techniques vérifiables : chronologie, liste des actifs concernés, indicateurs confirmés, évaluation de l’accès initial et informations sur une éventuelle exfiltration. La qualification juridique définitive revient aux conseillers spécialisés de l’organisation.

Reconquête des identités : reprendre le contrôle des identités

Dans une infrastructure hybride, la restauration d’un serveur ne suffit pas. L’organisation doit d’abord s’assurer qu’elle contrôle à nouveau son propre système d’identification.

Les éléments suivants doivent être vérifiés :

  • les comptes privilégiés et d'urgence ;
  • les sessions actives et les jetons de rafraîchissement ;
  • les méthodes d'authentification multifactorielle (MFA) nouvelles ou modifiées ;
  • les applications OAuth et les autorisations accordées ;
  • les entités de service et les identités de charge de travail ;
  • les règles de fédération ;
  • les politiques d'accès conditionnel ;
  • l'accès administratif délégué ;
  • clés API, certificats et secrets CI/CD ;
  • règles de transfert de courrier ;
  • les appareils enregistrés ;
  • l'accès des sous-traitants.

La modification d’un mot de passe ne met pas toujours fin à une session cloud en cours. C’est pourquoi la rotation des identifiants doit s’accompagner de la révocation des jetons, de la fermeture des sessions et de la vérification des applications de confiance.

Il est particulièrement dangereux d’effectuer une rotation massive à partir d’un environnement administratif compromis.

On commence par créer une zone de travail propre avec des appareils vérifiés, un canal de communication dédié, des comptes contrôlés et une journalisation autonome. Ce n’est qu’ensuite que commence la récupération coordonnée des identités.

Le cloud et le SaaS nécessitent une approche distincte

Un incident dans le cloud ne peut pas être enquêté comme une infection classique d’un poste de travail.

Une partie des preuves n’existe que dans les journaux du fournisseur et peut n’être conservée que pendant une durée limitée. Au cours des premières heures, il convient de conserver :

  • les journaux de connexion et d’audit ;
  • l’historique des modifications IAM ;
  • les journaux du plan de contrôle ;
  • les événements liés à la messagerie et à la collaboration ;
  • les modifications apportées aux politiques et aux règles réseau ;
  • les informations relatives à la création de clés et de jetons ;
  • les instantanés des disques et des configurations ;
  • les données des applications SaaS connectées via SSO ou OAuth.

Il convient également de vérifier la création de nouveaux administrateurs, les modifications apportées à la fédération, l’émission de jetons à durée de vie prolongée, les autorisations OAuth, la désactivation des politiques de sécurité, le lancement de nouvelles ressources cloud et l’exportation de données.

La procédure d’escalade d’urgence auprès du fournisseur, les prérogatives des parties et la procédure de conservation des données de télémétrie doivent être définies à l’avance.

PWN-ALL utilise des processus distincts pour enquêter sur les compromissions de Microsoft 365, de Google Workspace, de l’infrastructure cloud et des comptes d’entreprise. Cela permet d’analyser les actions qui n’auraient peut-être pas laissé de traces sur les terminaux traditionnels.

Comment utiliser l’IA lors d’une enquête

L’IA peut accélérer :

  • la normalisation des événements ;
  • le regroupement des alertes ;
  • la création d’une chronologie ;
  • la préparation des requêtes pour la recherche de menaces ;
  • la mise en correspondance des indicateurs ;
  • la recherche d'anomalies ;
  • l'analyse de grands volumes de journaux ;
  • la préparation de rapports intermédiaires.

Cependant, le modèle ne doit pas prendre de manière autonome des décisions susceptibles d’entraîner des dommages importants.

Un processus sécurisé implique l’utilisation d’un environnement contrôlé, la réduction au minimum des données sensibles, la journalisation des requêtes et des réponses, la vérification des conclusions par un analyste et le recoupement de chaque hypothèse avec les données télémétriques d’origine.

Sans accord supplémentaire, on ne peut pas confier au modèle la désactivation d’un segment critique, la suppression de comptes, la rotation massive des secrets, la destruction d’artefacts, la publication de messages aux clients ou la conclusion définitive quant à l’absence d’exfiltration.

L’IA peut suggérer une piste d’enquête. La responsabilité de la conclusion incombe à l’humain.

La restauration n’est pas un retour à l’état antérieur

La phrase la plus dangereuse à prononcer lors d’un incident :

« On va simplement tout restaurer à partir de la sauvegarde. »

Si l’on restaure l’architecture d’origine avec ses anciennes vulnérabilités, ses secrets compromis et ses erreurs de configuration, l’attaquant peut revenir.

Une restauration sécurisée s’effectue par étapes :

  1. Un environnement administratif vierge est créé.
  2. On reprend le contrôle des identités.
  3. Le vecteur d’intrusion initial est bloqué.
  4. Les mécanismes d'ancrage sont supprimés.
  5. Les secrets, clés, jetons et certificats sont renouvelés.
  6. Les sauvegardes sont vérifiées.
  7. Les dépendances critiques sont rétablies.
  8. Les systèmes sont connectés par groupes contrôlés.
  9. À chaque étape, la sécurité et le bon fonctionnement sont vérifiés.
  10. Une surveillance renforcée se poursuit après le lancement.

Le responsable métier confirme le bon fonctionnement du service, tandis que l’équipe de sécurité s’assure de l’absence de signes connus indiquant une compromission persistante.

La disponibilité du système ne signifie pas pour autant que l’incident est clos.

Dans le cadre de la restauration, PWN-ALL évalue les sauvegardes intactes, la possibilité de reconfigurer les systèmes, les options disponibles de déchiffrement et de récupération des clés, puis établit les priorités pour la remise en service de l’infrastructure. Le résultat dépend de la famille de ransomware, de l’état des systèmes, des preuves conservées et de la qualité des sauvegardes ; par conséquent, le déchiffrement complet ou la récupération de toutes les données ne peuvent être garantis.

Si l’organisation envisage de payer la rançon

Une approche professionnelle face à un rançongiciel ne doit pas reposer sur le principe selon lequel le paiement est exclu en toutes circonstances.

Il arrive parfois que la direction envisage cette option en raison d’une menace pour la vie ou la sécurité des personnes, de l’arrêt de processus critiques, de l’absence de sauvegardes exploitables, du risque de perte irréversible d’activité ou du coût extrêmement élevé d’une interruption prolongée.

Les recommandations officielles ne soutiennent pas le paiement : celui-ci ne garantit pas le rétablissement de l’accès aux données, l’élimination de la présence malveillante ou la suppression des informations volées. De plus, l’organisation qui a payé peut à nouveau devenir une cible.

Le paiement n’est toutefois pas une mesure technique, mais une décision de gestion exceptionnelle prise en situation de crise.

Il convient tout d’abord d’examiner les alternatives

Avant de prendre une décision, il convient d’évaluer :

  • l'état des sauvegardes ;
  • la possibilité d’une restauration partielle ;
  • la reconstruction des services critiques ;
  • les processus manuels temporaires ;
  • la disponibilité de décrypteurs ;
  • la possibilité de restaurer les données à partir d'autres sources ;
  • la durée admissible du mode de secours.

L’affirmation du cybercriminel selon laquelle le paiement est la seule issue ne doit pas être acceptée sans une vérification technique indépendante.

PWN-ALL peut évaluer l'état réel de l'infrastructure et des sauvegardes, étudier la possibilité de déchiffrer ou de récupérer les clés, et fournir à la direction une comparaison des scénarios envisageables. La décision finale revient aux représentants habilités de l'organisation victime.

Il est nécessaire d’évaluer les conséquences réelles

Il ne suffit pas de comparer uniquement le montant de la rançon et le coût de la restauration.

Il convient de prendre en compte l’impact sur les personnes, la durée de l’indisponibilité, la résilience des processus temporaires, les conséquences pour les clients et les partenaires, le risque de divulgation des données, le coût d’une restauration sécurisée et l’atteinte à la réputation.

La décision doit s’appuyer sur des faits avérés, et non pas uniquement sur les promesses et les délais imposés par le cybercriminel.

Les restrictions juridiques et les sanctions sont évaluées séparément

Le destinataire, le groupe associé, l’intermédiaire ou l’infrastructure de paiement utilisée peuvent être soumis à des sanctions ou à d’autres restrictions.

Les autorités officielles chargées des sanctions mettent explicitement en garde contre les risques encourus par les entreprises qui facilitent le paiement de rançons. C’est pourquoi les restrictions applicables doivent être vérifiées par des conseillers juridiques et en matière de sanctions qualifiés avant toute action.

PWN-ALL prend en charge l’aspect technique du processus : elle recueille des données sur l’infrastructure de l’attaquant, vérifie ses déclarations, documente les communications et fournit les éléments nécessaires à l’assureur et aux conseillers spécialisés. L’évaluation juridique et la décision relative à la transaction incombent à l’organisation et à ses conseillers mandatés.

La communication avec l’attaquant doit être contrôlée

Une correspondance directe avec le maître chanteur peut révéler la vulnérabilité de certains systèmes, la situation interne de l’organisation ou les limites de ses capacités.

Sous réserve d’un accord préalable, PWN-ALL peut accompagner cette communication contrôlée en aidant à :

  • vérifier si l’attaquant dispose effectivement des données qu’il prétend détenir ;
  • demander un décryptage à titre d’essai ;
  • d'évaluer le bon fonctionnement du déchiffreur ;
  • déterminer la faisabilité technique des exigences ;
  • gagner du temps ;
  • conserver l'historique complet des messages et des décisions.

Ce type d’accompagnement ne remplace pas une vérification juridique, ne constitue pas une recommandation de paiement et ne confère pas à l’équipe DFIR le droit de prendre des décisions au nom du client.

Les déclarations de l’attaquant doivent être vérifiées

Avant toute décision définitive, il peut être demandé un décryptage à titre d'essai d'un ensemble limité de fichiers, la preuve de l'accès aux données déclarées et la confirmation du bon fonctionnement de l'outil proposé.

Mais même une vérification réussie ne garantit pas une restauration complète.

L’attaquant peut fournir un décrypteur instable, ne décrypter qu’une partie des données, conserver les informations volées, les transmettre à d’autres participants ou revenir en profitant de l’accès qu’il a conservé.

Les outils obtenus doivent être analysés et testés dans un environnement isolé.

Les négociations n’interrompent pas l’enquête

La communication avec l’attaquant ne remplace pas la réaction.

En parallèle, il est nécessaire de poursuivre :

  • la localisation de la menace ;
  • la recherche du vecteur d'attaque initial ;
  • la résiliation des sessions compromises ;
  • la rotation des secrets ;
  • la protection des sauvegardes ;
  • la collecte de preuves ;
  • vérification de l'environnement cloud ;
  • recherche de mécanismes de verrouillage ;
  • la préparation d’une restauration sécurisée.

Une fois le rançon versée, l’incident n’est pas considéré comme clos. Il faut tout de même nettoyer ou reconfigurer les systèmes, remplacer les données d’accès compromises et supprimer les mécanismes de verrouillage.

Le paiement peut modifier un aspect de la crise, mais il n’élimine pas la compromission et ne remplace pas une restauration sécurisée.

Ce qu’il ne faut pas faire pendant un incident en cours

Mettre hors tension l’ensemble de l’infrastructure sans plan

Cela peut détruire des preuves volatiles, compliquer l’analyse et interrompre des processus non affectés. L’isolation doit être ponctuelle ou par segment et reposer sur une évaluation des risques.

Réinstaller les systèmes avant la collecte des données

Un formatage rapide efface les traces de l’accès initial, de l’implantation et des déplacements de l’attaquant.

Célébrer la victoire après la suppression du logiciel malveillant

Un fichier malveillant peut n’être qu’un outil parmi d’autres. Il est nécessaire de vérifier les identités, les sessions cloud, les jetons, l’accès à distance, les règles de messagerie, les applications SaaS et l’infrastructure de gestion.

Considérer le changement de mot de passe comme une mesure de protection suffisante

L’attaquant peut conserver des sessions actives, des jetons de rafraîchissement, des autorisations OAuth ou des méthodes alternatives d’authentification multifactorielle (MFA).

Utiliser des canaux de communication compromis

L'attaquant peut lire les messages de l'équipe, adapter ses tactiques et effacer ses traces.

Prendre contact de son propre chef avec le maître chanteur

Une communication non préparée peut affaiblir la position de négociation, révéler la vulnérabilité des systèmes ou créer des risques juridiques et opérationnels supplémentaires.

Restaurer les systèmes avant de fermer le point d’entrée

Sinon, la restauration se transforme en un nouvel incident.

Considérer l’absence de chiffrement comme l’absence de fuite

Le vol de données peut se produire via des services cloud légitimes et des sessions utilisateur actives, sans générer les événements caractéristiques d’un ransomware.

Faire confiance à une sauvegarde sans la vérifier

La copie doit être vérifiée non seulement pour s'assurer de sa lisibilité, mais aussi de son intégrité, de sa propreté et de l'absence de mécanismes de verrouillage enregistrés.

Publier des conclusions non confirmées

Il ne faut pas garantir l’absence de fuite tant que cela n’a pas été confirmé par une enquête.

Déclarer l’environnement « propre » en raison de l’absence de nouvelles alertes

L'absence d'événements peut signifier non pas l'absence d'attaquant, mais une visibilité insuffisante.

Comment mesurer la préparation

Le nombre d’alertes clôturées ne dit pratiquement rien sur la capacité d’une organisation à résister à une attaque grave.

Des indicateurs plus utiles :

  • le délai avant la confirmation de l'incident ;
  • le délai avant la désignation d’un commandant des opérations ;
  • le délai avant la première mise en quarantaine ;
  • le délai avant la résiliation des sessions compromises ;
  • le délai de réception des journaux cloud ;
  • le délai de vérification d’une sauvegarde intacte ;
  • pourcentage de systèmes critiques disposant d’une télémétrie suffisante ;
  • l'exhaustivité de la chronologie ;
  • le délai de neutralisation du vecteur d'attaque initial ;
  • la proportion de mesures mises en œuvre à la suite de l’analyse post-incident.

Il est important de mesurer non seulement la rapidité, mais aussi la qualité des décisions :

  • le nombre d’actions menées sans responsable désigné ;
  • combien de modifications n’ont pas été consignées dans le journal ;
  • quelles preuves ont été perdues ;
  • combien de systèmes ont dû être restaurés à plusieurs reprises ;
  • quelles hypothèses du plan d'intervention en cas d'incident (IR) se sont révélées erronées.

Après un incident, ce n’est pas un document formel indiquant qu’« un entretien a eu lieu » qui est nécessaire, mais un plan concret de changements précisant les responsables, les délais et les critères de vérification.

Niveau minimal de préparation de l’organisation en 2026

Avant l’incident, l’entreprise doit disposer :

  • un plan de réponse aux incidents (IR) approuvé ;
  • une matrice des rôles et des responsabilités ;
  • un canal de communication hors réseau ;
  • des guides d'intervention spécifiques pour les principaux scénarios ;
  • une cartographie des systèmes critiques et de leurs interdépendances ;
  • une durée de conservation suffisante des journaux ;
  • des copies de sauvegarde inaltérables et vérifiables ;
  • une procédure de conservation des preuves ;
  • un environnement administratif propre ;
  • coordonnées de l'équipe DFIR externe ;
  • des modèles de communications internes et externes ;
  • procédure de traitement des demandes du rançonneur ;
  • des exercices théoriques et techniques réguliers.

Il ne faut pas se contenter de tester l’équipe technique. La direction, le service informatique, le service de sécurité, les responsables des processus métier, les services juridiques et de communication, l’assureur, les fournisseurs clés et le partenaire DFIR externe doivent tous participer aux exercices.

Un plan qui n’a jamais été testé dans des conditions de temps limité n’est qu’une hypothèse, et non un moyen de protection.

La réaction consiste à gérer l’incertitude

Lors d’une attaque, il est rare d’obtenir immédiatement toutes les réponses.

Une équipe solide n’attend pas d’avoir une certitude absolue, mais n’agit pas non plus à l’aveuglette. Elle distingue les faits des hypothèses, prend des décisions réversibles lorsque cela est possible, coordonne les mesures de neutralisation, préserve les preuves, gère un calendrier unique et gère en parallèle les risques techniques et métier.

On ne peut pas rendre un incident totalement prévisible.

Mais on peut rendre prévisible le travail de l’équipe.

Quand une équipe d’intervention externe est nécessaire

PWN-ALL intervient dans les incidents où la rapidité, la préservation des preuves et une restauration maîtrisée sont essentielles :

  • les ransomwares et les chantages sans chiffrement ;
  • vol et publication de données ;
  • les attaques BEC et la compromission de la messagerie d'entreprise ;
  • piratage de comptes ;
  • compromission de Microsoft 365 et Google Workspace ;
  • attaques contre l'infrastructure cloud ;
  • piratage d'applications web et de serveurs ;
  • incidents impliquant des fournisseurs et des sous-traitants.

Le travail peut inclure des mesures d’urgence, la criminalistique numérique, l’évaluation de l’ampleur de la compromission, la collecte et la conservation des preuves, l’étude des options de déchiffrement, la vérification des sauvegardes, l’accompagnement technique des communications contrôlées, la restauration sécurisée, la préparation de rapports et le renforcement ultérieur de la sécurité. Pour les incidents en cours, PWN-ALL dispose d’un processus de réaction dédié, opérationnel 24 heures sur 24.

En cas d’incident en cours :

N’éteignez pas les systèmes affectés, ne supprimez pas les traces, ne répondez pas vous-même à l’attaquant et ne lancez pas de restauration à grande échelle avant l’évaluation initiale.

La première priorité est de limiter les actions de l’attaquant sans détruire les informations nécessaires à l’enquête, à la prise de décision et à la reprise en toute sécurité des activités.