Incident Response : Playbook Ransomware 2026 : Guide Complet

L'incident ransomware qui frappe votre organisation à 3h du matin ne laisse pas le temps de chercher la bonne procédure dans un fichier SharePoint vieux de 18 mois. Les organisations qui s'en sortent en moins de 48 heures ont toutes le même secret : elles ont répété, documenté, et testé leur playbook d'incident response ransomware 2026 bien avant que l'alerte ne sonne. Les autres passent en moyenne trois semaines à reconstruire une infrastructure qu'un confinement précoce aurait préservée. Ce guide opérationnel détaille chaque phase — Préparation, Identification, Confinement, Éradication, Restauration, Leçons apprises — avec les commandes exactes à exécuter, les décisions à prendre sous pression, et les pièges qui transforment un incident gérable en catastrophe médiatique. Structuré selon le référentiel NIST SP 800-61r2 et les recommandations du CERT-FR, il intègre les obligations légales NIS2 et RGPD, la question épineuse du paiement, et le tableau RACI complet pour ne jamais se demander qui doit décider quoi.

Phase 1 — Préparation : le travail fait avant l'incident

La réponse à un incident ransomware commence des mois avant l'attaque. Les organisations qui atteignent un RTO (Return to Operations) inférieur à 24h ont systématiquement une chose en commun : elles ont répété. La préparation couvre quatre domaines indissociables.

L'équipe CSIRT et les contacts d'urgence : définir qui appelle qui à 3h du matin n'est pas une formalité. Votre liste doit inclure : le RSSI (astreinte 24/7), un prestataire PRIS qualifié ANSSI, le DPO, le service juridique, l'assureur cyber (numéro d'astreinte — pas le conseiller habituel), et le CERT-FR ([email protected]). Ces contacts doivent être imprimés et placés dans une enveloppe physique dans le bureau du RSSI, sur le téléphone personnel de chaque responsable IT, et dans le coffre de la salle serveur.

Le forensic toolkit prêt à déployer : assemblez votre kit de réponse avant l'incident. Une clé USB bootable avec Kali Linux, winpmem pour l'acquisition mémoire, KAPE pour la collecte d'artefacts Windows, Velociraptor en mode standalone, et un script d'isolation réseau pré-configuré pour votre environnement. Testez-le trimestriellement — une clé USB corrompue au moment de l'incident, c'est une heure de perdue quand chaque minute compte.

Les exercices tabletop : un exercice de simulation de 3 heures par semestre coûte moins cher que 3 jours d'arrêt de production. Scénario minimal : annonce de ransomware à 9h un lundi, simulation des décisions des premières 4 heures avec la direction et les équipes IT. Chaque exercice révèle des lacunes que les plans écrits ne peuvent pas anticiper.

La stratégie de sauvegarde mérite une attention particulière dans la préparation. La règle 3-2-1-1-0 (3 copies, 2 supports différents, 1 hors site, 1 hors ligne, 0 erreurs aux tests de restauration) est le minimum. Vérifiez que vos sauvegardes sont réellement restaurables : 23% des organisations qui testent leurs backups pour la première fois lors d'un incident constatent que les sauvegardes sont inutilisables.

Phase 2 — Identification : détecter avant le chiffrement

Les ransomwares modernes passent en moyenne 21 jours sur le réseau avant de déclencher leur payload de chiffrement. C'est votre fenêtre. Les groupes comme LockBit 3.0, BlackBasta ou Akira utilisent des techniques ATT&CK bien documentées pendant cette phase de reconnaissance — et elles sont détectables si vous savez quoi chercher.

Signaux d'alerte à surveiller dans votre SIEM :

• Suppression des copies shadow : vssadmin delete shadows /all /quiet ou wmic shadowcopy delete
• Désactivation ou modification de Veeam/Acronis en dehors des fenêtres de maintenance
• Énumération massive de partages réseau (T1135 — Network Share Discovery via net view ou Get-SmbShare)
• Trafic sortant vers Mega, rclone, ou des buckets S3 inconnus (exfiltration pré-chiffrement)
• Connexions RDP ou WMI latérales depuis des postes de travail vers des serveurs
• Désactivation de Windows Defender via PowerShell ou modification des exclusions AV
• Utilisation d'outils de reconnaissance AD (BloodHound, SharpHound) sur le réseau

Pour identifier la souche ransomware, deux ressources indispensables : ID Ransomware (id-ransomware.malwarehunterteam.com) qui identifie 1000+ variantes depuis une ransom note ou un fichier chiffré, et les fiches techniques CERT-FR qui publient les IOC et TTPs des groupes actifs en France. Ne tentez jamais de déchiffrer sans avoir identifié la souche — certains outils de déchiffrement "génériques" corrompent définitivement les données.

Phase 3 — Confinement : isoler sans détruire les preuves

Le confinement est l'étape où la plupart des organisations commettent des erreurs irréversibles. Deux pièges fréquents :

Commandes d'isolation réseau à exécuter en urgence :

# Linux — isolation réseau immédiate (préserver logs locaux)
# Couper toutes les interfaces réseau sauf loopback
ip link set eth0 down
ip link set eth1 down

# Windows PowerShell — isolation via netsh
netsh interface set interface "Ethernet" admin=DISABLE
netsh interface set interface "Wi-Fi" admin=DISABLE

# Windows — bloquer tout trafic sortant via firewall
netsh advfirewall set allprofiles firewallpolicy blockinbound,blockoutbound

# Acquisition mémoire avec winpmem (forensic USB)
winpmem_mini_x64.exe -o D:\forensic\memdump.raw
certutil -hashfile D:\forensic\memdump.raw SHA256 > D:\forensic\memdump.sha256

# Linux — acquisition mémoire avec LiME
insmod /forensic/lime.ko "path=/forensic/memdump.raw format=raw"
sha256sum /forensic/memdump.raw > /forensic/memdump.sha256

# Analyse rapide du dump avec Volatility 3
python3 vol.py -f memdump.raw windows.pstree.PsTree
python3 vol.py -f memdump.raw windows.netstat.NetStat
python3 vol.py -f memdump.raw windows.malfind.Malfind

Une fois le snapshot mémoire acquis, documentez chaque action avec un timestamp précis. Cette documentation sera la colonne vertébrale de votre rapport forensique, de la déclaration CNIL, et du dossier assureur.

Phase 4 — Éradication : nettoyer sans trou dans la raquette

L'éradication sans investigation forensique complète est la cause principale des re-compromissions. Avant de reconstruire quoi que ce soit, répondez à ces quatre questions : quel est le patient zéro ? (vecteur initial — phishing, VPN vulnérable, supply chain), quel est le périmètre exact ? (quels systèmes, quelles données), quelles persistances ont été installées ?, et depuis combien de temps l'attaquant était-il là ?

Hunting des mécanismes de persistance sous Windows — commandes PowerShell pour couvrir les vecteurs les plus utilisés par les groupes ransomware :

# Audit des tâches planifiées suspectes (hors espace Microsoft)
Get-ScheduledTask | Where-Object {
  $_.State -eq "Ready" -and $_.TaskPath -notlike "\Microsoft\*"
} | Select-Object TaskName, TaskPath,
  @{N="Command";E={$_.Actions.Execute}} |
  Export-Csv C:\forensic\scheduled-tasks.csv -NoTypeInformation

# Audit des clés Run/RunOnce du registre
Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" | Format-List *
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" | Format-List *

# WMI Event Subscriptions — persistance favorite des APT
Get-WMIObject -Namespace root\subscription -Class __EventFilter |
  Select Name, Query
Get-WMIObject -Namespace root\subscription -Class __EventConsumer |
  Select Name, CommandLineTemplate

# Services créés ou modifiés dans les 30 derniers jours
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} |
  Where-Object {$_.TimeCreated -gt (Get-Date).AddDays(-30)} |
  Select TimeCreated, @{N="Service";E={$_.Properties[0].Value}} |
  Format-Table -AutoSize

# Comptes locaux actifs (identifier les comptes créés par l'attaquant)
Get-LocalUser | Where-Object {$_.Enabled -eq $true} |
  Select Name, LastLogon, PasswordLastSet | Sort PasswordLastSet -Descending

# GPO modifiées récemment (vecteur de persistance souvent oublié)
Get-GPO -All | Where-Object {
  $_.ModificationTime -gt (Get-Date).AddDays(-30)
} | Select DisplayName, ModificationTime | Sort ModificationTime -Descending

Outils DFIR open-source pour l'investigation forensique complète : Velociraptor pour la collecte d'artefacts à l'échelle (1000 endpoints simultanément), KAPE pour la collecte standardisée Windows, Hayabusa pour l'analyse des Windows Event Logs orientée ATT&CK, et les outils de cloud forensics si votre infrastructure est hybride.

Phase 5 — Restauration : reconstruire sur des fondations saines

La restauration n'est pas une simple opération "restore depuis la dernière sauvegarde". C'est une reconstruction méthodique avec validation à chaque étape. L'ordre de reconstruction conditionne la réussite : restaurer un système compromis sur un réseau non isolé, c'est garantir la re-contamination en moins d'une heure.

Ordre de reconstruction recommandé :

1. Infrastructure de sécurité en premier : SIEM, EDR, outils de monitoring — vous devez surveiller la reconstruction elle-même
2. Active Directory sur instance fraîche : jamais restaurer l'AD compromis tel quel — reconstruction sur une nouvelle instance avec migration sélective des objets
3. PKI et infrastructure d'authentification : renouveler tous les certificats, révoquer les certificats émis pendant la période de compromission
4. Systèmes Tier 1 : ERP, facturation, systèmes de production critiques — sur sauvegardes antérieures à la date de compromission confirmée
5. Systèmes Tier 2 et 3 : seulement après validation complète du Tier 1

Script Python pour inventorier les fichiers chiffrés et identifier les sauvegardes saines avant restauration :

#!/usr/bin/env python3
# Inventaire fichiers ransomware — identifie extensions suspectes
# Usage: python3 ransomware_inventory.py --path /mnt/backup --report out.csv

import os, csv, hashlib, argparse, re
from datetime import datetime
from pathlib import Path

RANSOMWARE_EXT = {
    '.lockbit', '.lockbit3', '.basta', '.akira', '.royal', '.blacksuit',
    '.play', '.clop', '.alphv', '.encrypted', '.enc', '.crypted', '.locked',
    '.crypt', '.crypz', '.cryp1',
}

def scan(path: str, report: str) -> dict:
    stats = {'total': 0, 'encrypted': 0, 'notes': []}
    note_kw = ['readme.txt', 'how_to_decrypt', 'restore_files', '_readme.txt']
    with open(report, 'w', newline='', encoding='utf-8') as f:
        w = csv.writer(f)
        w.writerow(['Path', 'Extension', 'Size_MB', 'Modified', 'Status'])
        for root, dirs, files in os.walk(path):
            dirs[:] = [d for d in dirs if d not in {'Windows', '$Recycle.Bin', '.git'}]
            for fname in files:
                fp = os.path.join(root, fname)
                ext = Path(fname).suffix.lower()
                stats['total'] += 1
                try:
                    st = os.stat(fp)
                    size = round(st.st_size / 1024 / 1024, 2)
                    mod = datetime.fromtimestamp(st.st_mtime).isoformat()
                    if fname.lower() in note_kw or 'decrypt' in fname.lower():
                        stats['notes'].append(fp); status = 'RANSOM_NOTE'
                    elif ext in RANSOMWARE_EXT:
                        stats['encrypted'] += 1; status = 'ENCRYPTED'
                    else:
                        status = 'OK'
                    w.writerow([fp, ext, size, mod, status])
                except (PermissionError, OSError):
                    w.writerow([fp, ext, 0, 'N/A', 'ERROR'])
    return stats

if __name__ == '__main__':
    p = argparse.ArgumentParser()
    p.add_argument('--path', required=True)
    p.add_argument('--report', default='inventory.csv')
    args = p.parse_args()
    s = scan(args.path, args.report)
    pct = s['encrypted'] / max(1, s['total']) * 100
    print(f"[*] {s['total']} fichiers | {s['encrypted']} chiffrés ({pct:.1f}%)")
    print(f"[*] Ransom notes: {len(s['notes'])}")
    if s['notes']: print(f"    -> {s['notes'][0]}")
    print(f"[+] Rapport: {args.report}")

Phase 6 — Leçons apprises : pourquoi le PIR est-il indispensable ?

Le Post-Incident Review (PIR) dans les 72h suivant le retour à la normale est l'investissement le plus rentable de toute la réponse à incident. Pas une session de blame — une analyse factuelle de ce qui s'est passé, pourquoi, et comment l'éviter. Les organisations qui sautent cette étape sont condamnées à reproduire les mêmes erreurs au prochain incident.

Structure du PIR selon les recommandations du NIST SP 800-61 :

• Timeline reconstituée : de la compromission initiale (date estimée forensiquement) à la reprise complète. Cette timeline révèle invariablement des signaux qui auraient pu déclencher une détection plus précoce
• Analyse du vecteur initial : email de phishing ? Credential stuffing sur VPN ? Application exposée non patchée ? Le vecteur initial doit être corrigé en priorité absolue
• Identification des near-misses : qu'est-ce qui a failli se passer et ne s'est pas produit par chance ? Ces quasi-incidents contiennent les enseignements les plus précieux
• Actions correctives priorisées : liste classée par criticité et par délai d'implémentation réaliste, avec un propriétaire nommé pour chaque action

Le rapport PIR doit être partagé avec l'ANSSI si votre organisation est OIV ou OSE. Pour les autres, le partage avec le CERT-FR est volontaire mais recommandé — il contribue à la connaissance collective des TTPs utilisés en France.

Communication de crise : qui dit quoi à qui et quand ?

La communication est souvent le maillon faible d'une réponse à incident bien préparée techniquement. Deux erreurs classiques : communiquer sur les canaux internes compromis (l'attaquant peut lire vos emails Teams si le tenant Microsoft est compromis), et communiquer trop tôt ou trop tard avec les parties prenantes externes.

Règle d'or : activez un canal hors-bande dès la détection. Signal, groupe WhatsApp dédié, ou appels téléphoniques directs. Jamais Teams, Slack, ou email interne pendant les premières heures d'un incident actif.

Chronologie de communication :

• H+1 : activation de la cellule de crise, canal hors-bande opérationnel
• H+4 : information de la direction générale avec premier bilan (périmètre, impact opérationnel estimé)
• H+24 : notification assureur cyber dans les délais contractuels (48-72h selon police)
• H+48 : notification CNIL si données personnelles exposées (délai légal : 72h)
• H+72 max : notification ANSSI pour les OIV/OSE selon NIS2
• J+3 à J+7 : communication vers clients et partenaires impactés (selon évaluation juridique)

La question du paiement : pourquoi NE PAS payer ?

La recommandation officielle de l'ANSSI, du CERT-FR et de la CISA est unanime : ne pas payer. Ce n'est pas une position idéologique — c'est une position statistique et stratégique.

Les chiffres qui argumentent contre le paiement :

• 35% des victimes qui paient ne récupèrent pas la totalité de leurs données (Sophos State of Ransomware 2024)
• 80% des victimes qui paient sont re-ciblées dans les 12 mois — soit par le même groupe, soit par un groupe qui a acheté l'accès
• 40% des outils de déchiffrement fournis après paiement sont défectueux ou corrompent les données
• Le paiement peut constituer une violation des sanctions OFAC si le groupe ransomware est listé (Lazarus Group, Evil Corp, etc.)

Alternatives légales avant toute décision de paiement :

1. Consulter le CERT-FR — un outil de déchiffrement existe peut-être pour votre souche (notamment via No More Ransom)
2. Vérifier si la souche est décryptable via une vulnérabilité connue dans l'implémentation cryptographique
3. Évaluer la viabilité de la restauration depuis les sauvegardes
4. Porter plainte auprès du COMCYBER-MI — cela ouvre l'accès à un soutien technique CERT-FR étendu

Checklist complète phase par phase

Phase 1 — Préparation (avant l'incident)

• Playbook documenté, approuvé par la direction, et accessible hors ligne
• Contacts d'urgence imprimés (PRIS, assureur, CERT-FR, DPO, juriste)
• Forensic toolkit assemblé et testé (winpmem, KAPE, Velociraptor, clé USB bootable)
• Sauvegardes offline testées — restauration complète validée en moins de 4h
• Canal de communication hors-bande défini et testé (Signal ou autre)
• Exercice tabletop organisé dans les 6 derniers mois

Phase 2 — Identification (H0 à H+4)

• Alertes SIEM qualifiées — incident confirmé ou non ?
• Activation canal hors-bande, cellule de crise mobilisée
• Identification de la souche (ID Ransomware, CERT-FR fiches)
• Périmètre initial estimé (systèmes confirmés compromis)

Phase 3 — Confinement (H+1 à H+8)

• Snapshot mémoire acquis AVANT tout reboot ou extinction
• Déconnexion réseau des systèmes compromis (câble ou hyperviseur)
• Credentials suspects révoqués depuis un poste propre hors domaine
• Journalisation maximale activée sur les systèmes sains

Phases 4 et 5 — Éradication et Restauration (H+8 à J+21)

• Patient zéro identifié, vecteur initial confirmé
• Persistence hunting complet (tâches planifiées, registre, WMI, GPO)
• Tous les comptes AD réinitialisés depuis une infrastructure propre
• Sauvegardes antérieures à la compromission identifiées et testées
• Reconstruction dans l'ordre Tier 0 → Tier 1 → Tier 2
• Validation EDR sur chaque système avant reconnexion réseau

Questions fréquentes

Combien de temps dure une réponse à incident ransomware en moyenne ?

Pour une PME (50-500 employés) sans préparation, le RTO moyen est de 15 à 21 jours. Avec un playbook testé et des sauvegardes offline valides, ce délai tombe à 48-72 heures pour les services critiques. Les grandes organisations avec des équipes IR dédiées et un PRIS sous contrat atteignent parfois moins de 24h pour les fonctions vitales. La différence principale n'est pas budgétaire — c'est la préparation opérationnelle.

Doit-on payer la rançon si les sauvegardes sont inutilisables ?

Même dans ce scénario extrême, le paiement doit rester un dernier recours après épuisement de toutes les alternatives : déchiffrement via No More Ransom, récupération partielle de données non chiffrées, reconstruction à partir de données fragmentaires. Consultez systématiquement un avocat spécialisé avant toute décision — le paiement à certains groupes expose à des poursuites pénales. L'ANSSI et le CERT-FR peuvent aider à identifier des options alternatives.

Comment éviter d'être re-compromis après la récupération ?

La re-compromission survient dans 80% des cas où l'éradication a été incomplète. Causes principales : backdoors non détectées dans des GPO ou tâches planifiées, comptes compromis non révoqués, vecteur initial non corrigé. La reconstruction complète des systèmes critiques (pas un "nettoyage") combinée à un password reset universel depuis une infrastructure propre réduit ce risque à moins de 5%.

Quand activer l'assureur cyber et dans quel ordre ?

L'assureur cyber doit être notifié dans les délais contractuels — typiquement 48 à 72h selon la police. Appelez le numéro d'astreinte (pas votre conseiller habituel) dès la confirmation de l'incident. Certains assureurs exigent d'utiliser leur réseau de PRIS agréés pour que la couverture s'applique. Vérifiez ce point avant l'incident, pas pendant.

La notification ANSSI est-elle obligatoire pour toutes les organisations ?

Non. L'obligation concerne principalement les OIV selon la LPM, et les OSE selon NIS2 transposée en droit français. Pour les autres organisations, la notification est volontaire mais recommandée — elle peut débloquer un soutien technique CERT-FR et contribue à la connaissance des menaces nationales. La CNIL, en revanche, doit être notifiée par toute organisation traitant des données personnelles exposées, sans exception de taille ou de secteur.

Conclusion

Un playbook de réponse à incident ransomware ne sert à rien dans un tiroir. Sa valeur se mesure en heures de récupération économisées, en données préservées, et en décisions prises sans panique sous pression. Commencez par le plus simple : un tabletop exercise de 2 heures avec votre équipe dirigeante, en simulant les décisions des premières 4 heures d'un incident. Ce seul exercice révèle systématiquement des lacunes que nul document ne peut anticiper. L'investigation forensique qui suit un incident bien confiné vaut toujours mieux que la reconstruction totale après un incident non maîtrisé. La préparation est l'investissement cyber le plus rentable qui existe.