Aller au contenu

Scénario ransomware : isoler, vérifier, restaurer

Day 2 · ExploiterNiveau 3 · MaîtriserLabRédigé · à valider en lab

Ce lab vous entraîne au réflexe face à un ransomware : isoler d'abord, geler les sauvegardes, identifier le dernier point sain, restaurer dans une bulle isolée, et comprendre pourquoi la copie MSP sous droits séparés survit quand le PBS local a été vidé par l'attaquant.

Cluster de test uniquement

Ce lab chiffre volontairement des fichiers et supprime des sauvegardes. Ne l'exécutez jamais sur la production ni sur un PBS qui contient des sauvegardes réelles. Utilisez un cluster de lab (même un PVE mono-nœud imbriqué) et deux PBS de lab.

Prérequis

Élément Lab
PVE pve01 de lab, bridge isolé vmbr9 sans uplink
PBS « local » pbs-lab-local, datastore pbs01, stockage PVE pbs-local
PBS « MSP » pbs-lab-msp, datastore client-a, sync pull depuis pbs-lab-local toutes les heures, remove-vanished désactivé, prune keep-hourly 24, keep-daily 7
Compte de sync Sur pbs-lab-local : msp-pull@pbs avec rôle DatastoreReader seulement
VM victime VM 9201 Debian, dossier /srv/data avec une centaine de fichiers texte, agent invité actif
Job de sauvegarde VM 9201 vers pbs-local, toutes les heures

Objectifs

  1. Appliquer l'ordre isoler → geler → vérifier → restaurer.
  2. Repérer dans les logs de sauvegarde le moment de l'infection.
  3. Distinguer intégrité technique (verify) et intégrité métier (fichiers lisibles).
  4. Constater l'intérêt d'une copie dont le client ne détient pas les droits de suppression.

Scénario pas à pas

Phase 1 : situation saine

  1. Laisser tourner au moins 3 sauvegardes horaires de la VM 9201 et 3 syncs vers pbs-lab-msp.
  2. Noter, dans le log de chaque sauvegarde, la ligne dirty-bitmap status et le pourcentage reused.

Phase 2 : attaque simulée

  1. Dans la VM 9201, chiffrer les fichiers (script de lab, sans danger hors de ce dossier) :

    for f in /srv/data/*.txt; do
  openssl enc -aes-256-cbc -pbkdf2 -pass pass:lab -in "$f" -out "$f.locked" && rm "$f"
done
echo "Vos fichiers sont chiffrés" > /srv/data/LISEZMOI.txt

  2. Laisser passer une sauvegarde horaire (le point infecté entre dans le PBS local) et une sync.

  3. Simuler l'attaquant qui a volé le compte root@pam du PBS local : supprimer les snapshots de la VM 9201 sur pbs-lab-local (Datastore → Content → groupe vm/9201 → Remove).
  4. Tenter la même suppression sur pbs-lab-msp avec le compte msp-pull@pbs : constater l'échec.

Phase 3 : réponse à incident

  1. Isoler la VM : qm set 9201 --net0 virtio,bridge=vmbr9,link_down=1 (ou Hardware → Network Device → Disconnect). Ne pas l'éteindre avant d'avoir décidé si une analyse mémoire est nécessaire.
  2. Geler les sauvegardes : désactiver le job de sauvegarde PVE, les prune jobs et la GC des deux PBS. Côté MSP : suspendre la sync pull. Marquer Protected les snapshots candidats sur pbs-lab-msp.
  3. Identifier le dernier point sain sur pbs-lab-msp :
    • lire les logs : la sauvegarde post-infection montre un volume modifié anormal et un reused en chute ;
    • déclarer pbs-lab-msp dans PVE comme stockage pbs-msp, avec un compte du PBS MSP limité au rôle DatastoreReader (en réel, fourni temporairement par le MSP) ;
    • ouvrir chaque snapshot avec File Restore et vérifier que /srv/data/*.txt est lisible.
  4. Vérifier le snapshot choisi : Datastore → Content → snapshot → Verify, statut ok.

  5. Restaurer sous un nouvel ID, sur vmbr9, sans démarrage automatique (RB-12) :

    qmrestore pbs-msp:backup/vm/9201/<horodatage-sain> 9202 --storage local-zfs --unique 1
qm set 9202 --net0 virtio,bridge=vmbr9 && qm start 9202

  6. Contrôler dans la VM 9202 que les fichiers sont lisibles, rechercher la persistance (tâches planifiées, clés SSH, comptes ajoutés), changer les mots de passe, puis seulement reconnecter au réseau.

  7. Réactiver les jobs, rapatrier la chaîne de sauvegarde sur le PBS local reconstruit (sync pull inverse dans un namespace dédié), et rédiger le retour d'expérience.

Questions

  1. Pourquoi isoler la VM avant de restaurer, plutôt que restaurer immédiatement par-dessus ?
  2. Pourquoi désactiver le prune et la GC dès la détection ?
  3. Le verify du snapshot infecté est ok. Est-il sain ?
  4. Pourquoi l'attaquant n'a-t-il pas pu supprimer la copie MSP ? Qu'est-ce qui aurait annulé cette protection ?
  5. Les sauvegardes sont chiffrées côté client et la clé n'était que sur pve01, lui aussi chiffré par l'attaquant. Que se passe-t-il ?
Corrigé
  1. L'attaquant est peut-être encore présent : une VM restaurée sur le même réseau peut être réinfectée aussitôt. Restaurer par-dessus détruit aussi les preuves et le point de comparaison.
  2. Le prune supprime les points les plus anciens, souvent les seuls sains si l'infection date de plusieurs jours, et la GC rend la suppression définitive après le délai de grâce. Geler la rétention préserve tous les candidats.
  3. Non. Le verify contrôle l'intégrité des chunks par rapport à leur empreinte : un fichier chiffré par le ransomware est un contenu valide du point de vue de PBS. Seul le contrôle des données (File Restore, démarrage, applicatif) dit si le point est sain.
  4. La copie est tirée en pull par le PBS du MSP : le PBS local ne détient aucun identifiant du PBS MSP, et le compte msp-pull@pbs n'a que DatastoreReader sur le PBS local. remove-vanished est désactivé, donc les suppressions locales ne se propagent pas, et la rétention MSP est pilotée par le MSP seul. La protection serait annulée par : remove-vanished actif, un push avec un jeton disposant de Datastore.Prune ou Datastore.Modify côté MSP, ou des comptes d'administration partagés (même annuaire AD) entre client et MSP.
  5. Les sauvegardes, locales comme MSP, sont indéchiffrables. Seule une paperkey ou une master key séquestrée hors du cluster permet la restauration. C'est un point du test mensuel (PV de test).

En situation réelle

Ransomware avéré ou suspecté : ticket iTop P1 immédiat, avant toute restauration. Le MSP gèle la rétention de la copie distante et vous accompagne dans le choix du point sain (RB-15, sévérité).

Ouvrir un ticket iTop

Pour aller plus loin