05 recover from ransomware

Runbook 05 — Récupération après ransomware / compromission

1. AVERTISSEMENT — DO NOT PANIC, READ FIRST

Ce runbook est différent des autres : restaurer aveuglément dans le même environnement compromis va re-déclencher le ransomware sur les données fraîches. La séquence ci-dessous est obligatoire dans cet ordre :

1. ISOLER (couper réseau, geler l’état)
2. PRÉSERVER (sauver les indices forensiques avant tout)
3. NOTIFIER (CSIRT-FR, CNIL, assurance, clients)
4. RECONSTRUIRE (nouvelle infra, jamais l’ancienne)
5. RESTAURER (depuis backups versionnés / immutables)
6. VALIDER (intégrité Ed25519 + scan IOC)
7. POST-INCIDENT (rapport, RETEX, durcissement)

Ne pas payer la rançon. Position contractuelle SnakySec + position ANSSI (décret octobre 2024 + LOPMI 2023) : le paiement est légal mais expressément déconseillé, et conditionne certaines indemnisations cyber-assurance.

2. Quand activer ce runbook

Indicateur	Activation
Notification de rançon affichée sur le dashboard ou un terminal	OUI immédiat
Fichiers .{xtbl,locked,encrypt,...} dans des volumes Docker	OUI immédiat
Sentry détecte un volume anormal d’erreurs ENCRYPT ou permission denied	OUI triage
Compte Entra Global Admin compromis (login depuis IP inconnue)	OUI (compromission ≠ ransomware mais procédure similaire)
Backdoor ou shell étranger détecté dans un container	OUI (compromission silencieuse)
GitLab détecte un push depuis une SSH key inconnue	OUI (potentiellement supply-chain)
Hausse soudaine de trafic sortant suspect (exfiltration)	OUI (data breach)

3. Objectifs

• RPO : 24 heures maximum (snapshots immutables versioned dans buckets)
• RTO : 8-12 heures (vs 4h sur scénario non-malveillant)
• WRT : 2-4 heures (validation forensique exhaustive avant remise en service)

L’allongement du RTO est délibéré : on ne réduit pas la phase forensique pour aller vite. Une remise en service sur infra encore compromise est pire qu’une indisponibilité prolongée.

4. Étape 1 — ISOLER (T+0 → T+15min)

4.1 Couper le réseau public du VPS

ssh [e-mail]   # SI ENCORE accessible

# Bloquer tout sauf SSH depuis IP forensique connue
sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow from <NICOLAS_HOME_IP> to any port 22
sudo ufw enable

Si SSH ne répond plus :

1. OVH Manager → VPS → snakysec → "Reboot in rescue mode"
2. SSH dans rescue mode (clés temporaires fournies par OVH)
3. Monter le disque en read-only pour préservation

4.2 Stopper la stack Docker

cd /opt/mssp/app/platform
make prod-down

Si docker daemon compromis (containers re-spawn malgré stop) :

sudo systemctl stop docker
sudo systemctl mask docker  # empêche restart au reboot

4.3 Désactiver les comptes externes pivotables

• OVH : désactiver tokens API (manager.ovh.com → Identifiants → Révoquer)
• GitLab : révoquer tous les tokens (GitLab → User Settings → Access Tokens → Revoke all)
• Entra Global Admin Nicolas : changer le mot de passe + générer nouveaux MFA factors
• Compte break-glass Entra : NE PAS toucher (c’est précisément le compte de secours)

5. Étape 2 — PRÉSERVER (T+15min → T+1h)

5.1 Créer un snapshot disque OVH AVANT tout autre changement

1. OVH Manager → VPS → snakysec → "Snapshots" → Create snapshot
2. Nom : "incident-YYYYMMDD-pre-investigation"
3. Cocher "Include data volumes"
4. Conservation : 90 jours minimum (preuve juridique)

Pourquoi : ce snapshot est la preuve forensique. Toute investigation ultérieure (analyste cyber, expertise judiciaire, assureur) en aura besoin.

5.2 Capture de l’état mémoire (si VPS encore vivant)

# Container postgres : capture mémoire (peut révéler clés en RAM)
docker exec mssp-postgres ps auxf > /tmp/forensic-postgres-ps.txt
# (limité — l'idéal serait `gcore` ou `lime`, hors scope V1)

# Tous les containers : logs récents
docker compose logs --tail=10000 > /tmp/forensic-logs-$(date +%Y%m%dT%H%M%SZ).log

Compresser et copier hors VPS :

sudo tar czf /tmp/forensic-bundle-$(date +%Y%m%dT%H%M%SZ).tar.gz \
  /tmp/forensic-*.txt /tmp/forensic-*.log \
  /var/log/auth.log /var/log/syslog \
  /etc/passwd /etc/group /etc/sudoers.d/

# Sur poste de travail Nicolas
scp [e-mail]:/tmp/forensic-bundle-*.tar.gz ~/Documents/incidents/

5.3 Lister les indicateurs de compromission (IOC)

À documenter immédiatement (dans un fichier sur poste local, pas sur VPS) :

• Heure de la première anomalie observée
• IP source des connexions suspectes (si visible dans logs)
• User-agents anormaux dans les logs Traefik
• Fichiers chiffrés / extensions étranges
• Notes de rançon (texte intégral, hash MD5/SHA256)
• Wallets crypto demandés (Bitcoin / Monero adresses)
• Adresses email / TOR onion contacts

6. Étape 3 — NOTIFIER (T+1h → T+4h)

6.1 Notification CSIRT-FR (sous 24h, le plus tôt possible)

Suivre docs/dr/incident-response/02-csirt-fr-notification.md.

Tags spécifiques ransomware dans la notif :

• Type d’incident : ransomware ou unauthorized_access
• Gravité : significant ou major
• Données potentiellement exfiltrées : oui / non / inconnu
• Demande d’assistance CSIRT-FR : oui (bénéficier de leur expertise)

6.2 Notification CNIL (sous 72h si data perso impactée)

Suivre docs/dr/incident-response/03-cnil-rgpd-notification.md.

Pour MSSP : presque toujours data perso impactée (au minimum les UPN des clients, les emails dans les audits Entra).

6.3 Notification assurance cyber (Stoik / Acheel) sous 4h

Téléphoner immédiatement à la hotline cyber assurance :

• Stoik : [numéro hotline contractuel]
• Acheel : [numéro hotline contractuel]

Ils déclenchent leur expert-incident qui prend le relais sur la phase forensique. Ne PAS poursuivre la reconstruction §7 sans leur feu vert — sinon perte de la couverture financière.

6.4 Notification clients (sous 24h, version dégradée)

Objet : SnakySec — Incident de sécurité significatif

Un incident de sécurité significatif a été détecté sur notre infrastructure
le YYYY-MM-DD à HH:MM UTC. Nous activons immédiatement notre plan de
continuité.

Actions en cours :
- Plateforme isolée pour préservation forensique
- Investigation en cours avec [CSIRT-FR / expert assurance]
- Reconstruction sur infrastructure neuve, hors périmètre compromis
- Notification CNIL en cours (RGPD art. 33)

Durée prévisionnelle indisponibilité : 8-12 heures.

Concernant vos données :
- Aucune perte de données significative attendue (RPO 24h max)
- Backups sont stockés sur infrastructure indépendante non impactée
- Investigation en cours pour déterminer si exfiltration a eu lieu
- Vous serez informés sous 72h du résultat de cette analyse

Si vous êtes vous-même soumis à des obligations NIS2/RGPD, cet incident peut
constituer un sous-traitant compromis au sens art. 28 RGPD. Nous nous
tenons à votre disposition pour vous fournir les éléments nécessaires à
votre propre déclaration.

Contact urgent : [e-mail]

7. Étape 4 — RECONSTRUIRE (T+4h → T+8h)

Sur infrastructure NEUVE — jamais l’ancienne.

Suivre 03-rebuild-vps-from-zero.md intégralement.

Différences spécifiques au scénario ransomware :

7.1 Provisioning

• Provisionner dans une autre région OVH que l’ancienne (dépaysement réseau utile)
• Générer une nouvelle clé SSH sur poste Nicolas (l’ancienne peut être compromise)
• Ne pas réutiliser les credentials OVH/Scaleway de l’ancienne instance — régénérer des access keys neufs avant le restore

7.2 Vault

• NE PAS restaurer le snapshot Vault le plus récent (potentiellement contient l’état post-compromission)
• Identifier le dernier snapshot Vault antérieur à l’incident (typiquement J-1 ou J-2 selon le RPO)
• Procéder au restore avec ce snapshot

7.3 Postgres

• PITR target-time = juste avant la première anomalie observée
• En cas de doute, choisir 24h avant pour marge

7.4 Artifacts

• Snapshot restic immédiatement antérieur à l’incident
• Si les buckets OVH/Scaleway ont versioning + retention lock activé (cf. 03-backup-strategy.md §2), restorer la version immutable correspondante

7.5 Rotation des secrets compromis

Avant remise en service :

• Tous les secrets clients dans Vault : régénérer les certs Entra X.509 + notifier chaque client de re-pousser les credentials côté tenant
• Auth secret NextAuth : régénérer (invalide toutes les sessions actives)
• GitLab tokens : régénérer
• OVH/Scaleway S3 keys : déjà régénérés à l’étape §7.1
• Sentry DSN : régénérer (ancien DSN potentiellement leaké)
• Postgres password : régénérer

8. Étape 5 — VALIDER (T+8h → T+12h)

8.1 Smoke check infra

make dr-shell
/dr/restore/smoke-after-restore.sh

Doit reporter valid: true sur la chaîne Ed25519, comptes critiques cohérents.

8.2 Scan IOC sur le VPS reconstruit

# Vérifier qu'aucun fichier suspect n'a été restauré accidentellement
sudo apt install -y clamav clamav-daemon
sudo freshclam
sudo clamscan -r /opt/mssp/data/ /var/lib/docker/volumes/

# Vérifier intégrité packages système
sudo apt install -y debsums
sudo debsums -c

8.3 Test fonctionnel par échantillonnage clients

• Login portail MSSP : OK
• Pour 3 clients aléatoires :
  • Dashboard charge : OK
  • Audit récent visible : OK
  • 1 rapport GRC téléchargeable : OK
  • Trigger nouvel audit (test pipeline GitLab) : OK

8.4 Vérification absence de persistance malveillante

• crontab -l (sur VPS) : aucune entrée non documentée
• systemctl list-unit-files --state=enabled : aucun service ajouté
• find / -newer /etc/hostname -not -path '/proc/*' -not -path '/sys/*' 2>/dev/null : revue manuelle des fichiers récents
• Logs auth récents : last -F | head -20 (qui s’est connecté en SSH)

9. Étape 6 — POST-INCIDENT (T+12h → 30 jours)

9.1 Communication finale aux clients (sous 72h)

Objet : SnakySec — Incident résolu, plateforme à nouveau disponible

L'incident détecté le [date] est résolu. La plateforme est à nouveau
opérationnelle depuis [date] sur infrastructure entièrement reconstruite.

Synthèse :
- Type : [ransomware / compromission / accès non autorisé]
- Détection : YYYY-MM-DD HH:MM UTC
- Reprise : YYYY-MM-DD HH:MM UTC
- Origine probable : [résultat investigation, ou "investigation en cours"]
- Données impactées : [aucune / [liste précise]]
- Exfiltration confirmée : [non / oui — voir section dédiée]

Mesures correctives :
- Reconstruction complète sur infrastructure neuve
- Rotation de tous les secrets et certificats
- [Mesures spécifiques selon type d'incident]

Conformité :
- Notification CSIRT-FR effectuée le [date], référence [REF]
- Notification CNIL effectuée le [date] (si applicable)

Un rapport post-incident détaillé conforme au format ANSSI vous est transmis
ce jour en pièce jointe. Si vous avez des obligations propres NIS2/RGPD à
satisfaire suite à cet incident, ce rapport contient les éléments nécessaires.

Nous sommes à votre disposition pour toute question : [e-mail]

9.2 Rapport post-incident formel (sous 7 jours, sous 30j si CSIRT-FR)

Utiliser le template docs/dr/templates/post-incident-report.md.

Sections obligatoires :

• Timeline détaillée (minute par minute pour les 4 premières heures)
• Cause racine (root cause analysis)
• Vulnérabilités exploitées
• Données compromises (avec scope précis)
• Actions immédiates prises
• Actions correctives à long terme
• Leçons apprises
• Mises à jour de la PSSI / threat model

9.3 RETEX et amélioration continue

Sous 30 jours :

• Mettre à jour docs/SECURITY.md threat model
• Mettre à jour ce runbook si des étapes ont manqué
• Si root cause = bug applicatif : créer issue + PR de correction
• Si root cause = config infra : durcir les paramètres concernés
• Si root cause = humain (phishing, social engineering) : formation + 2FA renforcé

9.4 Activation indemnisation cyber-assurance

• Constitution dossier complet (factures externes, perte d’exploitation, frais juridiques, etc.)
• Soumission à l’assureur dans les délais contractuels (typiquement 30 jours)

10. Erreurs courantes et solutions

Erreur	Conséquence	Solution
Restaurer dans le même environnement compromis	Re-déclenchement immédiat du ransomware	Toujours nouvelle infra (§7)
Restorer le snapshot Vault le plus récent (peut contenir l’état compromis)	Compromission persistée dans la nouvelle infra	Restorer snapshot J-1 ou J-2 antérieur à la première anomalie
Ne pas notifier CSIRT-FR	Sanction NIS2 + perte couverture assurance	Notif sous 24h non négociable
Réutiliser les SSH keys de l’ancienne infra	Persistance de l’attaquant	Régénérer toutes les clés
Communication client trop tardive	Sanction RGPD + perte de confiance	Notif sous 24h, version dégradée acceptable si investigation pas finie
Payer la rançon sans contact assureur	Perte couverture indemnisation	Toujours hotline assurance d’abord, jamais de paiement direct

11. Validation du runbook

Testé annuellement (Q4, exercice incident complet en mode “blanc”) avec simulation de ransomware sur env de test. Procès-verbal dans docs/dr/test-results/.

Version	Date	Auteur
1.0	2026-04-26	Nicolas Schiffgens