Documentation Index

Fetch the complete documentation index at: https://snakysec.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

​

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

​

1. AVERTISSEMENT — DO NOT PANIC, READ FIRST

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)

​

2. Quand activer ce runbook

​

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)

​

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

​

4.1 Couper le réseau public du VPS

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 <NICOLAS_HOME_IP> to any port 22
sudo ufw enable

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

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)

​

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

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)

• 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)

• 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)

​

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

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

​

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)

​

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

• 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

​

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 : contact@snakysec.com

​

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

• 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

• 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

​

11. Validation du runbook