> ## Documentation Index > Fetch the complete documentation index at: https://docs.snakysec.com/llms.txt > Use this file to discover all available pages before exploring further. # 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 ```bash theme={null} ssh mssp@vps.snakysec.com # 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 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 ```bash theme={null} cd /opt/mssp/app/platform make prod-down ``` Si docker daemon compromis (containers re-spawn malgré stop) : ```bash theme={null} 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) ```bash theme={null} # 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 : ```bash theme={null} 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 mssp@vps.snakysec.com:/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](../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](../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 : contact@snakysec.com ``` ## 7. Étape 4 — RECONSTRUIRE (T+4h → T+8h) **Sur infrastructure NEUVE — jamais l'ancienne.** Suivre [03-rebuild-vps-from-zero.md](./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](../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 ```bash theme={null} 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 ```bash theme={null} # 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 : contact@snakysec.com ``` ### 9.2 Rapport post-incident formel (sous 7 jours, sous 30j si CSIRT-FR) Utiliser le template [docs/dr/templates/post-incident-report.md](../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 |