Cloud, Virtualization and Container Forensics

Introduction and Context

Digital evidence increasingly resides outside a traditional investigator’s direct physical control. Public-cloud storage, virtual machines, container platforms, serverless functions and software-as-a-service (SaaS) applications may distribute relevant evidence across providers, regions, accounts and transient execution environments. A conventional forensic model—seize a device, create a bit-stream image and analyse it independently—must therefore be adapted.

Cloud forensics is the application of forensic principles to data, systems and services delivered through cloud-computing models. It combines technical investigation with provider cooperation, identity management, legal process, service-level agreements, auditability and careful interpretation of shared infrastructure. The central problem is not merely how to acquire data, but how to establish that the acquired data is authentic, complete enough for the investigative purpose, lawfully obtained and correctly interpreted.

Cloud environments are commonly classified as:

• Public cloud: Infrastructure is operated by a provider and shared among customers through logical isolation.
• Private cloud: Cloud capabilities are dedicated to one organisation, although infrastructure may still be virtualised.
• Hybrid cloud: Workloads and evidence span private and public environments.
• Multicloud: An organisation uses multiple cloud providers, often creating complex identity and logging paths.

The forensic investigator must understand both the customer-controlled layer and the provider-controlled layer. A customer may control operating-system logs, application data and identity policies, while the provider controls hypervisors, physical hosts, underlying storage and some management-plane records.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the forensic implications of public, private, hybrid and multicloud architectures.

2. Distinguish evidence from virtual machines, containers, serverless platforms and SaaS applications.

3. Use provider logs, snapshots, APIs and preservation mechanisms in a defensible investigation.

4. Evaluate multitenancy, shared responsibility, jurisdiction and chain-of-custody risks.

5. Design an investigation that accounts for volatile and ephemeral evidence.

6. Critically assess limitations, governance requirements and emerging automation, including AI-assisted analysis.

A Forensic Model for Cloud Environments

A useful model separates cloud evidence into three planes.

The management plane

The management plane records administrative actions such as account creation, policy changes, creation of virtual machines, modifications to security groups, key management operations and API calls. Examples include identity-provider logs, cloud audit trails and infrastructure-as-code repositories. These records are often essential for attributing an action to an identity, but an identity is not necessarily a human: it may be a role, service account, automation pipeline or compromised credential.

The control plane

The control plane provisions and configures resources. It may contain metadata about instances, volumes, network interfaces, snapshots, container clusters, functions and storage buckets. Control-plane evidence can reveal when a resource existed and how it was configured, even when the workload itself has disappeared.

The data plane

The data plane carries workload activity: files, database records, network traffic, process execution and application transactions. Data-plane evidence may be held in virtual disks, object storage, packet captures, endpoint agents, application logs or SaaS audit records.

Investigators should correlate all three planes. For example, an audit record showing that a storage object was downloaded is stronger when correlated with an authenticated session, a source address, an endpoint record and the object’s access log. No single timestamp or log entry should automatically be treated as a complete account of an event.

Shared Responsibility and Evidence Ownership

In cloud computing, security responsibilities are divided between provider and customer. The provider commonly manages physical facilities, hardware, foundational networking and the virtualisation layer. The customer commonly manages identities, data, configurations and, depending on the service model, guest operating systems and applications.

This division changes with the service model:

• In Infrastructure as a Service (IaaS), the customer generally manages guest operating systems, applications, virtual networks and data.
• In Platform as a Service (PaaS), the provider manages more of the runtime and operating platform; the customer focuses on applications, configurations and data.
• In Software as a Service (SaaS), the provider operates the application and infrastructure, while the customer manages users, permissions, content and organisational policies.
• In serverless computing, the provider manages servers and much of the runtime. Investigators usually rely heavily on invocation logs, application telemetry and provider APIs rather than host images.

Responsibility for security does not automatically equal availability of forensic evidence. A provider may be responsible for a layer but retain logs only for a limited period, expose them only through a paid feature, or disclose them only under legal process. Evidence planning must therefore begin before an incident through logging, retention and preservation policies.

Virtual Machine Forensics

A virtual machine (VM) is an emulated or virtualised computer with virtual CPUs, memory, storage and network interfaces. A VM may be examined through several evidence sources:

• Virtual disk images and snapshots
• Guest operating-system logs and artefacts
• Hypervisor and orchestration logs
• Virtual network-flow records
• Instance metadata and configuration history
• Memory captures, where technically and legally available
• Backups and machine images

Snapshots and images

A snapshot records the state of a virtual disk at a point in time. It is not necessarily a complete physical image of the VM. Snapshot mechanisms may be incremental, crash-consistent rather than application-consistent, encrypted, dependent on parent snapshots or subject to provider-specific semantics. Investigators must document the snapshot type, creation time, dependencies, encryption status and export process.

A crash-consistent snapshot resembles the result of sudden power loss. Open transactions may be incomplete, and volatile memory is not preserved. An application-consistent copy coordinates with the application or operating system and may provide stronger reconstruction of transactional state, but it still does not capture all runtime evidence.

A sound acquisition workflow is to preserve the original resource, restrict changes, create a provider-side snapshot where possible, export a forensic copy through an approved method, calculate cryptographic hashes of exported files and record all API calls and personnel actions. Hashing supports integrity verification of the acquired copy; it does not prove that the provider’s original data was itself complete or untampered with.

Virtual memory and deleted data

Virtual disks may contain page files, unallocated blocks, journal records, deleted files and remnants of earlier content. However, cloud storage may use thin provisioning, deduplication, encryption and internal garbage collection. A customer-exported disk does not necessarily include provider-level remnants or sectors belonging to other tenants. Investigators must not assume that conventional physical-disk recovery techniques apply to provider-managed storage.

Virtual network evidence

Network security-group logs, flow logs, load-balancer records, DNS logs and host-based telemetry can establish communications. Flow records usually provide metadata—such as source, destination, port, bytes and time—not packet content. Clock synchronisation, time zones, delayed ingestion and aggregation must be examined before constructing a timeline.

Container Forensics

Containers package an application and its dependencies while sharing the host operating-system kernel. They are typically more lightweight and short-lived than VMs. A container image consists of layered filesystems and metadata; a running container adds a writable layer, process state, environment variables, mounted volumes and network identity.

Important evidence sources include:

• Container image digests, manifests and registries
• Orchestrator audit logs
• Pod, task or workload definitions
• Container stdout and stderr logs
• Runtime and host logs
• Persistent volumes and object storage
• Kubernetes events, admission records and control-plane logs
• Secrets-management and identity-provider logs
• Network policies, service-mesh telemetry and ingress records

An image tag such as `latest` is mutable and is not a sufficient identifier. A cryptographic image digest provides a more stable reference to image content, although the investigator should preserve the manifest, layer digests, registry metadata and retrieval time.

Container evidence is highly ephemeral. A terminated container may lose its writable layer, process list and local logs. Orchestrator logs may reveal that a workload existed, but not necessarily every command executed inside it. Persistent volumes may outlive containers and become the principal source of application evidence.

Container investigations should distinguish between:

1. Image evidence: What software and configuration could have been deployed?

2. Workload evidence: Which image, command, environment and identity were actually used?

3. Runtime evidence: What processes, files, connections and system calls occurred?

4. Orchestration evidence: Who created, modified or deleted the workload?

A container escape investigation requires host-level and runtime evidence, because the container view alone may omit kernel activity and neighbouring workloads. Multitenancy also means that investigators must avoid acquiring unrelated tenants’ data.

Serverless and Function Forensics

Serverless functions execute in provider-managed environments, often in response to events from queues, storage systems, APIs or schedules. Instances may be created and destroyed rapidly, and investigators normally cannot acquire a host disk or memory image.

Relevant sources include function configuration, deployment packages, version identifiers, invocation logs, request identifiers, trigger records, identity logs, environment-variable history, source repositories, dependency manifests, API-gateway logs and downstream database or storage records. Correlation identifiers are particularly valuable because one user action may traverse an API gateway, function, queue and database.

A function log can show that code was invoked, but it may not prove what code was present unless the deployed version or immutable package digest is also preserved. Similarly, an error message may be generated by a downstream service rather than by the function itself. Investigators should capture configuration and dependency information alongside execution logs.

SaaS Application Forensics

SaaS applications present a different challenge: the customer often has access to content and administrative audit logs but not the underlying operating system. Evidence may include:

• Login, session and multifactor-authentication records
• Administrative audit trails
• File creation, sharing, download and deletion events
• Email headers and message trace data
• Collaboration and chat records
• Application exports and legal holds
• API responses and pagination metadata
• Retention, versioning and recycle-bin records

SaaS exports should be treated as structured evidence rather than ordinary reports. Preserve the export format, schema, field descriptions, timezone, query parameters, account scope, pagination details and provider-generated identifiers. A screenshot is useful for presentation but is usually weaker than a native audit export because it omits metadata and may not demonstrate completeness.

Acquisition, Preservation and Chain of Custody

Cloud acquisition is usually selective and API-driven rather than a single physical imaging event. A defensible process includes:

1. Scoping: Identify accounts, subscriptions, projects, regions, services, identities and time ranges.

2. Legal and organisational authority: Determine consent, warrant, subpoena, contractual authority, internal policy and cross-border requirements.

3. Preservation: Apply legal holds, extend log retention, preserve snapshots and prevent deletion or rotation where possible.

4. Volatility assessment: Prioritise short-lived logs, containers, function versions, tokens, queues and ephemeral disks.

5. Acquisition: Use documented provider APIs, exports, snapshots and approved collection tools.

6. Integrity protection: Hash acquired files, preserve response headers and record acquisition commands and API request identifiers.

7. Validation: Compare records across independent sources and test whether expected records are missing.

8. Analysis and reporting: Separate observed facts, provider assertions, investigative inferences and unresolved uncertainty.

A cloud chain of custody must include the identity and authority of the collector, provider and tenant context, resource identifiers, region, acquisition time, time standard, API endpoint, query parameters, tool version, export format, hash values, encryption and transfer method. Because provider systems may change records after collection, investigators should preserve raw responses before normalising them into analysis formats.

Jurisdiction, Privacy and Multitenancy

Cloud evidence may be replicated across countries or processed by subcontractors. The location selected in a customer console may not identify every location where metadata, backups or support records exist. Investigators must assess data-protection law, cross-border transfer restrictions, sector regulations, contractual terms and mutual legal assistance requirements.

Multitenancy creates both technical and ethical constraints. Logical isolation is intended to prevent one customer accessing another’s data, but it also means that investigators cannot generally demand physical disks containing only the target. Provider-mediated acquisition is often necessary. Collection should follow data minimisation and proportionality principles: acquire only relevant accounts, fields, objects and time periods, and protect unrelated personal information.

Encryption creates additional issues. Customer-managed keys may prevent provider access, while provider-managed keys may be unavailable to investigators. Key-rotation records, key versions, access policies and decrypt operations can be as important as ciphertext. Possession of encrypted data without the relevant key may establish existence but not content.

Applied Case: Illustrative Hybrid-Cloud Intrusion

Background

A financial-services organisation operates a private Kubernetes cluster and uses a public-cloud environment for analytics and object storage. Its security team detects that a service account uploaded an unfamiliar archive to public object storage and then accessed a production database.

Problem

The relevant container was deleted within minutes. The organisation must determine whether customer records were accessed, identify the responsible identity and preserve evidence without collecting unrelated tenant information.

Analysis

Investigators first preserve identity-provider logs, cloud audit logs, Kubernetes audit records, registry manifests, object-storage access logs, database audit logs and network-flow records. They identify the service account, its token-issuance events and the pod using that identity. The image tag is mutable, so the registry digest and manifest are preserved. The pod definition shows a mounted persistent volume, while the container’s writable layer is unavailable.

Timeline correlation reveals that an administrator changed a workload definition, causing a new pod to run with excessive permissions. The pod read selected database tables and uploaded an archive. Object-storage logs confirm the upload and subsequent download from an unfamiliar network address. Database audit records establish which tables were queried, but an absence of records for a short interval is documented as a logging limitation rather than interpreted as proof of no access.

Approach and solution

The organisation revokes the service-account credentials, preserves the relevant volume, exports immutable copies of logs, applies a legal hold and asks the cloud provider to preserve provider-side records. Investigators compare the archive’s hash with endpoint and registry evidence, examine database query results and notify legal and privacy officers. They do not attempt to inspect physical hosts or unrelated containers.

Outcome

The evidence supports a conclusion that a compromised administrative credential modified the deployment, the container accessed a defined set of records and the archive was downloaded externally. The investigation cannot establish whether data was opened after download because the external system is outside the organisation’s control. That limitation is explicitly reported.

Learning points

The case demonstrates that container forensics requires orchestration, identity, storage and application evidence together. It also shows why immutable identifiers, preconfigured audit logging, rapid preservation and careful statements about uncertainty are more valuable than a late attempt to recover a deleted container.

Professional Practice and Governance

Organisations should design for forensic readiness. Effective measures include centralised, tamper-resistant logging; synchronised time sources; long-enough retention; immutable or write-once storage; well-defined roles; tested provider contacts; automated snapshot and preservation procedures; detailed asset inventories; and documented exit and export capabilities.

Access to forensic data should use least privilege, separation of duties and strong authentication. Investigators should maintain reproducible scripts, record API versions and avoid destructive commands. Production snapshots can contain credentials or regulated personal data, so they require encryption, access monitoring and controlled disposal.

Incident response plans should identify which evidence is customer-accessible and which requires provider assistance. Contracts should address audit-log availability, retention, breach notification, data location, legal requests, subcontractors, evidence preservation and termination-time exports. Service-level commitments for availability do not necessarily guarantee forensic retention.

Contemporary Developments and AI

Cloud-native detection increasingly uses distributed telemetry, eBPF-based observation, service meshes, identity analytics and software-supply-chain attestations. These tools improve visibility but introduce new evidential questions concerning sensor configuration, sampling, clock accuracy and algorithmic transformations.

AI can assist with log clustering, timeline extraction, anomaly detection, malware triage and summarisation. It should not independently determine guilt, completeness or evidential significance. Investigators must preserve original records, document model versions and prompts where relevant, validate outputs against primary evidence and assess false positives, training bias and explainability. An AI-generated narrative is an analytical aid, not a substitute for authenticated source records.

Challenges and Limitations

Cloud investigations commonly face:

• Short retention periods and rapid deletion
• Provider-specific APIs and changing schemas
• Incomplete or sampled telemetry
• Clock drift and uncertain timestamp semantics
• Encryption and inaccessible keys
• Shared infrastructure and privacy constraints
• Cross-border legal barriers
• Automation identities that obscure human attribution
• Mutable container tags and unreproducible deployments
• Lack of host memory or disk access in serverless services
• Cost and rate limits during large-scale acquisition

These limitations should be reported explicitly. A technically sophisticated investigation can still be weak if it overstates what the evidence proves.

Best-Practice Investigation Checklist

Before an incident, enable appropriate management, identity, network, storage, database and workload logging. Use immutable resource identifiers, versioned deployments and centralised retention. Define who can approve snapshots and legal holds.

During an incident, preserve volatile evidence first, record scope and authority, avoid altering production resources unnecessarily, capture raw provider responses, document all time conversions and correlate independent evidence sources.

After acquisition, verify hashes, maintain original and working copies, restrict access, test analytical reproducibility and distinguish facts from assumptions. In the final report, explain the architecture, acquisition method, evidence gaps, provider dependencies, jurisdictional issues and confidence limits.

Chapter Summary

Cloud, virtualisation and container forensics require an architectural approach rather than a simple disk-imaging procedure. Evidence is distributed among management, control and data planes and may be divided between customer and provider responsibilities. VM investigations use snapshots, virtual disks, guest and hypervisor records, while container investigations depend on immutable image identifiers, orchestrator logs, volumes and runtime telemetry. Serverless and SaaS investigations rely heavily on invocation, audit, identity, configuration and application records because host acquisition is usually unavailable.

A defensible investigation preserves volatile evidence, uses documented APIs and snapshots, protects chain of custody, validates data across independent sources and reports uncertainty. Multitenancy, encryption, jurisdiction, privacy and provider retention policies place important limits on acquisition. Forensic readiness, contractual planning and centralised immutable logging are therefore strategic controls. AI may accelerate analysis, but authenticated primary evidence and human accountability remain essential.

Key Terms

Cloud forensics: Forensic investigation of cloud-hosted systems, services and data.

Multitenancy: Use of shared infrastructure by multiple logically isolated customers.

Shared responsibility: Division of security and operational duties between provider and customer.

Management plane: Layer recording administrative and identity-driven operations.

Control plane: Layer that provisions and configures cloud resources.

Data plane: Layer carrying workload data and runtime activity.

Virtual machine: Software-defined computer with virtualised hardware resources.

Snapshot: Point-in-time representation of a virtual disk or resource state.

Crash-consistent snapshot: Copy reflecting a state similar to abrupt power loss.

Container: Isolated application environment sharing the host kernel.

Container image: Layered package containing application code, dependencies and metadata.

Image digest: Cryptographic identifier associated with image content.

Orchestrator: System that schedules, configures and manages workloads.

Serverless function: Provider-managed code execution triggered by events or requests.

SaaS: Provider-operated software delivered as a service.

Ephemeral evidence: Evidence that may disappear rapidly through normal system operation.

Cloud audit log: Provider record of administrative or service actions.

Chain of custody: Documented history of evidence handling and control.

Forensic readiness: Preparation that enables efficient, lawful and reliable evidence collection.

Review Questions

Short Answer Questions

1. What are the management, control and data planes in a cloud environment?

2. Why is a mutable container image tag inadequate for forensic identification?

3. Distinguish a crash-consistent snapshot from an application-consistent snapshot.

4. Name four important evidence sources in a SaaS investigation.

5. Why must investigators document evidence gaps and uncertainty?

Long Answer Questions

1. Explain how shared responsibility affects the acquisition of evidence in IaaS, PaaS, SaaS and serverless environments.

2. Develop a defensible forensic workflow for a deleted container in a public-cloud Kubernetes cluster.

3. Discuss the legal, privacy and technical implications of multitenancy and cross-border cloud evidence.

4. Compare VM, container and serverless forensics in terms of persistence, volatility and available acquisition methods.

5. Explain how an organisation can achieve cloud forensic readiness through architecture, logging, contracts and governance.

Analytical / Application Questions

1. A cloud audit log records an API call by a service account, but no human user is identified. What additional evidence would you collect before attributing the action to an individual?

2. A function invocation log shows that a function ran, but the deployment package was overwritten later. How would you establish which code version executed?

3. During an investigation, a provider can supply object-access logs but not host-disk data. Evaluate what conclusions can and cannot responsibly be drawn.

Multiple Choice Questions with Answers

Question 1

Which plane primarily records administrative actions such as policy changes and resource creation?

A. Data plane

B. Management plane

C. Physical plane

D. Presentation plane

Correct Answer: B. Management plane

Question 2

What is the strongest identifier for preserving a specific container image version?

A. The mutable image tag

B. The container name

C. The image digest

D. The host IP address

Correct Answer: C. The image digest

Question 3

Which evidence source is generally most important for determining who changed a Kubernetes workload definition?

A. Container stdout alone

B. Kubernetes or provider audit logs

C. A screenshot of the running application

D. The image colour scheme

Correct Answer: B. Kubernetes or provider audit logs

Question 4

A crash-consistent snapshot most closely represents which condition?

A. A fully coordinated application backup

B. The state after abrupt power loss

C. A physical image of the provider’s disk

D. A copy of volatile memory

Correct Answer: B. The state after abrupt power loss

Question 5

Why are serverless investigations heavily dependent on invocation and application logs?

A. Serverless functions always run on customer-owned disks

B. Providers normally expose complete host memory images

C. Execution environments may be short-lived and host access is restricted

D. Serverless functions cannot generate logs

Correct Answer: C. Execution environments may be short-lived and host access is restricted

Question 6

Which statement about a cryptographic hash of an acquired cloud export is correct?

A. It proves the export is complete

B. It helps verify that the acquired copy has not changed

C. It identifies the human who created the original data

D. It removes jurisdictional requirements

Correct Answer: B. It helps verify that the acquired copy has not changed

Question 7

What is a major risk of relying only on a screenshot of a SaaS audit event?

A. It always contains too much raw metadata

B. It may omit schema, scope and completeness information

C. It cannot be viewed by investigators

D. It automatically modifies the provider database

Correct Answer: B. It may omit schema, scope and completeness information

Question 8

Which practice best supports cloud forensic readiness?

A. Disabling audit logs to reduce cost

B. Using only mutable resource names

C. Centralising and retaining tamper-resistant logs

D. Allowing all administrators to delete snapshots

Correct Answer: C. Centralising and retaining tamper-resistant logs

Question 9

Why should investigators preserve raw provider API responses?

A. To ensure later analysis can reproduce the original record and metadata

B. To guarantee that missing events never occurred

C. To avoid documenting acquisition details

D. To replace all legal authorisation

Correct Answer: A. To ensure later analysis can reproduce the original record and metadata

Question 10

Which conclusion is most defensible when object-storage logs show a download but provide no evidence about what happened afterward?

A. The recipient definitely opened every file

B. No data was accessed

C. The download occurred, but subsequent use may remain unknown

D. The provider must be responsible for the breach

Correct Answer: C. The download occurred, but subsequent use may remain unknown