TL;DR Executive

  • Les snapshots de VM sont utiles pour figer rapidement un état technique, mais ils ne sont pas automatiquement équivalents à une image forensique complète et validée. [2][4][10]
  • La cohérence dépend du type de snapshot/checkpoint (mémoire incluse ou non, quiescence applicative, crash-consistent vs application-consistent). [5][7][8][9]
  • Le principal risque de contamination est opérationnel : consolidation tardive, chaîne de snapshots profonde, actions d’admin non journalisées, et traitement direct sur l’original. [4][5][10][12]
  • La reproductibilité augmente fortement quand l’acquisition est scriptée, hashée, documentée (horodatage, hyperviseur, UUID, datastore, versions outils) et répétée sur copies de travail. [1][2][11][13]
  • En cloud, les snapshots sont souvent incrémentaux/logiques; la sémantique fournisseur (AWS/Azure/GCP) influence la portée de preuve et les limites d’interprétation. [7][8][9]
  • Les formats et outillages (VMDK/qcow2/checkpoints) introduisent des dépendances techniques qui doivent être explicitées au tribunal (compatibilité, delta chains, support partiel de features). [6][11][12]
  • Niveau de confiance global: modéré à élevé sur principes; modéré sur uniformité d’implémentation inter-plateformes.

Problématique et objectifs

Question de recherche. Dans quelle mesure les artefacts de virtualisation (VM + snapshots) permettent-ils une acquisition forensique cohérente, non contaminée et reproductible?

Objectifs.

  1. Distinguer ce qu’un snapshot capture réellement selon l’hyperviseur.
  2. Identifier les vecteurs de contamination spécifiques aux chaînes de snapshots.
  3. Définir un protocole minimal de reproductibilité et d’argumentation probatoire.

Méthodologie

  • Stratégie de recherche: requêtes orientées (forensic VM snapshot consistency, checkpoint types, cloud disk snapshot semantics, evidence collection chain of custody), puis lecture critique multi-sources.
  • Critères d’inclusion: documentation officielle (NIST, RFC, Microsoft, AWS, Azure, GCP, VMware/Broadcom, QEMU), source technique forensique reconnue (SANS/TechTarget), projet outillage forensique open-source reconnu.
  • Critères d’exclusion: billets d’opinion non vérifiables, contenus SEO sans méthode, pages sans auteur/date exploitable.
  • Nombre d’URL analysées: 13 (minimum requis ≥10; maximum autorisé 100).
  • Évaluation de crédibilité: grille Autorité/Vérifiabilité/Qualité/Fraîcheur/Biais (checklist skill), avec pondération forte pour documents normatifs et docs éditeurs.
  • Limites méthodologiques: hétérogénéité des hyperviseurs; accès limité à certaines publications académiques payantes; absence d’expérimentation labo dans ce livrable (revue documentaire).

Cadre conceptuel / technique / juridique

Trois propriétés structurent l’évaluation:

  1. Cohérence: état interne des données au moment de capture (filesystem/app/mémoire).
  2. Contamination: altération non maîtrisée de l’état probatoire durant acquisition/transport/analyse.
  3. Reproductibilité: possibilité pour un tiers compétent d’obtenir des résultats substantiellement similaires via procédure documentée.

Cadres de référence: intégration forensics-IR (NIST SP 800-86), procédures de collecte/archivage et chaîne de possession (RFC 3227), sémantiques snapshots éditeurs cloud/hyperviseurs. [1][2][4][5][7][8][9][11]

Analyse critique des résultats

1) Ce qu’un snapshot « prouve » réellement

La documentation Hyper‑V distingue explicitement les checkpoints standard (incluant état mémoire) des checkpoints de production (cohérence applicative via VSS/freeze, sans mémoire), ce qui modifie la valeur interprétative d’un artefact pour une reconstruction d’événement. [5]

QEMU précise qu’un VM snapshot peut inclure CPU, RAM, état device et disques, mais mentionne aussi des limitations (périphériques amovibles, support incomplet de certains drivers). Cette transparence technique est centrale pour l’opposabilité d’expertise. [11]

Côté cloud, AWS et GCP décrivent des snapshots incrémentaux et indépendants du cycle de vie VM, mais pas comme « image bit‑à‑bit physique » au sens strict; Azure parle d’une copie read-only de VHD avec recommandations d’arrêt propre avant certains usages. [7][8][9]

« A snapshot is not a full backup and can cause data consistency issues… » (Hyper‑V standard checkpoints) [5]

2) Risques de contamination spécifiques à la virtualisation

Le risque principal n’est pas seulement technique mais procédural: captures prises en environnement actif sans journal d’actions, consolidation tardive, snapshots chaînés, intervention d’outils tiers (backup locks), et analyses sur originaux. VMware signale d’ailleurs des conditions de consolidation problématiques et des contraintes d’espace/locking pouvant influencer l’état final de disque. [4]

Dans la pratique IR, la méthode SANS/TechTarget recommande de figer via snapshot puis hasher le parent disk avant copie forensique, pour séparer acquisition et exploitation. Cette logique réduit la contamination de la preuve exploitable. [10]

« …forensically sound method of imaging the virtual machine disk… » [10]

3) Reproductibilité: ce qui fonctionne en pratique

Les principes généraux (ordre de volatilité, documentation complète, chaîne de possession, conservation des artefacts originaux) restent valides en VM. [2][13]

La reproductibilité augmente lorsque l’on:

  • exporte les artefacts source (descripteurs VM, fichiers disque, delta/checkpoint metadata);
  • calcule des empreintes cryptographiques sur chaque composant acquis;
  • fige versions d’hyperviseur/outils/parser;
  • rejoue l’analyse sur copies immuables.

Les dépendances de format sont non triviales: libvmdk indique des features VMDK supportées/non supportées (ex. CBT partiel), ce qui peut affecter la capacité d’un expert adverse à reproduire exactement l’extraction. [12]

4) Convergences et divergences inter-plateformes

Convergences: snapshots = point‑in‑time utile, non substitut automatique à un protocole forensique complet; nécessité de hash + chaîne de possession. [1][2][5][10]

Divergences:

  • granularité mémoire/processus incluse ou non selon moteur;
  • comportement post-suppression source (notamment en cloud);
  • sémantique de cohérence (crash/app-consistent) et contraintes opérationnelles.

Ces divergences imposent de qualifier explicitement la nature du snapshot dans le rapport d’expertise au lieu de parler génériquement de « copie forensique ».

Discussion

Pour un litige civil/criminel, la meilleure posture est de présenter le snapshot comme mécanisme de préservation, puis de démontrer la solidité forensique par une chaîne d’opérations vérifiable (hash, logs, copies de travail, script de collecte, conservation originale). [1][2][13]

En environnement cloud, l’expert doit articuler la portée de ce qu’il infère (ex. état logique d’un volume) et ce qu’il ne peut pas inférer (ex. certains artefacts hyperviseur sous-jacents), afin d’éviter la surinterprétation.

Limites et incertitudes

  • La littérature académique récente et ouverte sur validation comparative inter-hyperviseurs reste fragmentée.
  • Certaines capacités fournisseur évoluent vite; conclusions à réévaluer périodiquement.
  • Ce livrable ne contient pas de bench expérimental (temps de consolidation, taux d’échec de replay, variance hash en scénarios multi-delta).

Conclusion

Les snapshots de VM sont indispensables en réponse rapide et en préservation initiale, mais leur force probatoire dépend d’un encadrement méthodique strict. Sans qualification du type de snapshot, sans hashing composant par composant et sans documentation de chaîne de possession, la cohérence, la non‑contamination et la reproductibilité deviennent contestables. À l’inverse, une procédure standardisée et rejouable permet d’élever significativement la robustesse judiciaire de l’analyse VM.

Références

  1. NIST SP 800-86, *Guide to Integrating Forensic Techniques into Incident Response* — NIST, 2006 — https://csrc.nist.gov/pubs/sp/800/86/final
  2. RFC 3227, *Guidelines for Evidence Collection and Archiving* — IETF, 2002 — https://www.rfc-editor.org/rfc/rfc3227
  3. NIST SP 800-101 Rev.1, *Guidelines on Mobile Device Forensics* (principes méthodologiques transposables de validation/préservation) — NIST, 2014 — https://csrc.nist.gov/pubs/sp/800/101/r1/final
  4. *Consolidating/Committing snapshots in VMware ESXi* — Broadcom (VMware KB), maj. 2026 — https://knowledge.broadcom.com/external/article?legacyId=1002310
  5. *Using checkpoints* — Microsoft Learn (Hyper‑V), 2025 — https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/checkpoints
  6. *vSphere Virtual Machine Administration* — Broadcom/VMware Docs, 2024–2025 — https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-virtual-machine-administration.html
  7. *Amazon EBS snapshots* — AWS Documentation, 2025 — https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html
  8. *Create an Azure snapshot of a virtual hard disk* — Microsoft Learn (Azure), 2025 — https://learn.microsoft.com/en-us/azure/virtual-machines/snapshot-copy-managed-disk
  9. *About archive and standard disk snapshots* — Google Cloud Documentation, 2025 — https://cloud.google.com/compute/docs/disks/snapshots
  10. Paul Henry, *How to perform a forensic acquisition of a virtual machine disk* — TechTarget / SANS, 2015 — https://www.techtarget.com/searchsecurity/tip/How-to-perform-a-forensic-acquisition-of-a-virtual-machine-disk
  11. *Disk Images (VM snapshots, qcow2, limitations)* — QEMU Documentation, consulté 2026-02-12 — https://www.qemu.org/docs/master/system/images.html
  12. *libvmdk: Library and tools to access VMware VMDK format* — libyal (GitHub), consulté 2026-02-12 — https://github.com/libyal/libvmdk
  13. *Chapter 1 – First Steps* (virtual machine freezing/copying/backup context) — Oracle VM VirtualBox User Manual, consulté 2026-02-12 — https://www.virtualbox.org/manual/ch01.html

Articles qui pourraient vous intéresser