Cloud Forensics: Finding And Preserving Evidence In Ephemeral Infrastructure

A cloud container is terminated. A virtual machine is deleted. A Kubernetes pod is replaced automatically. By the time investigators begin examining the incident, the original workload may no longer exist.

Does that mean its digital evidence is gone?

Not necessarily.

Modern cloud infrastructure generates records across multiple layers. Even when the original workload disappears, information may remain in container runtimes, host operating systems, network infrastructure, cloud audit services, image registries, backups and security monitoring platforms.

The challenge for digital forensic investigators is identifying these sources, understanding what each can reveal, and determining whether the available information is reliable enough to support an investigation.

This is where cloud forensics becomes particularly important. Unlike traditional investigations centred on a physical device, cloud investigations often involve evidence distributed across multiple services, accounts and infrastructure providers.

Why cloud evidence disappears

Cloud infrastructure is designed around flexibility and automation. Resources can be created, replaced, scaled or terminated without requiring manual intervention.

Several mechanisms can affect evidence availability:

• Ephemeral containers: Containers can be stopped and removed when workloads are replaced or terminated.
• Autoscaling: Cloud instances may be terminated automatically when demand decreases.
• Log rotation: Older log records may be overwritten or removed when configured storage limits are reached.
• Pod eviction: Kubernetes can remove pods and their associated local container logs when a pod is evicted from a node.
• Temporary storage: Data stored in temporary filesystems or non-persistent volumes may not survive workload termination.
• Retention policies: Cloud logging services may automatically expire records after a configured period.

Kubernetes documentation explains that container logs are normally managed through the kubelet and container runtime. When a container restarts, logs from a previous instance may remain available. However, when a pod is evicted, its containers and associated logs are also evicted. Log rotation further restricts the amount of history available through the standard logging interface.

This distinction matters: a terminated workload, deleted container, unavailable log file and permanently destroyed evidence are not necessarily the same thing.

Investigators must establish what was removed, what remains, and which independent systems may have retained copies.

Understanding the cloud evidence ecosystem

Before searching for evidence, investigators need to understand how the cloud environment is structured.

A cloud-hosted application may involve several interconnected components:

• Virtual machines and operating systems
• Containers and orchestration platforms
• Cloud storage and databases
• Identity and access management services
• DNS and network infrastructure
• Load balancers and firewalls
• Deployment pipelines and image registries
• Centralized logging and security monitoring

Each component can generate a different type of record.

For example, a container runtime may record information about a container's lifecycle, while the cloud control plane may record who requested its creation or deletion. Network monitoring may reveal communication with external destinations, while an identity service may record authentication activity.

These sources are complementary. No single record should automatically be treated as a complete account of an incident.

The National Institute of Standards and Technology (NIST), in Special Publication 800-201, Cloud Computing Forensic Reference Architecture, emphasizes the importance of understanding cloud forensic challenges and preparing systems to support evidence collection.

1. Investigating the container and runtime environment

The first place to examine is often the environment in which the workload operated.

Even if a container has stopped, investigators may find useful information on the underlying host or through the container runtime.

Potential evidence includes:

• Container IDs and image references
• Container creation and termination times
• Runtime configuration and environment variables
• Process information and execution context
• Container logs and filesystem changes
• Network connections and open ports
• Container image and snapshot metadata

For Kubernetes environments, kubectl provides an initial way to examine available workload information.

Useful commands:

# List pods, including their current status
kubectl get pods -A -o wide

# Retrieve logs from a container
kubectl logs <pod-name> -n <namespace>

# Retrieve logs from the previous container instance
kubectl logs <pod-name> -n <namespace> --previous

# Inspect available pod information
kubectl describe pod <pod-name> -n <namespace>

These commands depend on the Kubernetes API retaining the relevant resources and records. They do not guarantee recovery of deleted workloads.

At the node level, investigators may examine container runtime artifacts. In environments using containerd and the Container Runtime Interface (CRI), tools such as crictl can provide additional information.

# List containers known to the runtime
crictl ps -a

# Inspect container metadata
crictl inspect <container-id>

# Retrieve available container logs
crictl logs <container-id>

The underlying host may also contain relevant records. On Linux systems using systemd, investigators can examine service logs through journalctl.

# Examine kubelet service logs
journalctl -u kubelet

# Examine containerd service logs
journalctl -u containerd

# List available journal entries
journalctl --list-boots

The exact services and available records depend on the operating system and runtime configuration.

Important: These commands only retrieve information that remains accessible. If runtime metadata, logs or snapshots have already been removed, they cannot recreate the missing information automatically.

Where a node is still available, investigators should consider preserving its state before rebooting, cleaning up containers or redeploying workloads. Memory, running processes and active network connections may contain volatile evidence that will not survive shutdown.

2. Examining the underlying host operating system

A container does not operate independently of its host. It relies on the underlying operating system, kernel, storage and network interfaces.

This creates another evidence source.

On Linux systems, investigators may examine:

• Authentication records
• System logs and service events
• Process execution records, where auditing was enabled
• Kernel and security events
• Filesystem metadata
• Scheduled tasks and service configurations
• Network interface and connection information

Relevant tools include journalctl, ausearch, aureport, ps, ss and filesystem examination utilities.

For example:

# Review recent authentication-related journal events
journalctl -u ssh --since "24 hours ago"

# Examine Linux audit events, if auditd was configured
ausearch -ts recent

# Generate an audit summary
aureport

# Examine current network connections
ss -tulpn

# List running processes
ps aux

The commands shown are examples for authorized investigation. Service names, audit configuration and available history vary across Linux distributions.

Windows-based cloud instances can provide a separate evidence source through Windows Event Logs.

Investigators may examine:

• Security event records
• System and application logs
• PowerShell operational logs, if enabled
• Windows Defender records
• Service installation and execution events
• Authentication and remote-access activity

PowerShell can be used to inspect available records:

# Retrieve recent system events
Get-WinEvent -LogName System -MaxEvents 100

# Retrieve recent security events
Get-WinEvent -LogName Security -MaxEvents 100

# List available event log channels
Get-WinEvent -ListLog *

The availability of historical events depends on logging policies, permissions, retention and whether records were forwarded elsewhere.

A crucial limitation is that host evidence does not automatically reveal everything that happened inside a container. Investigators must correlate host-level observations with runtime, application and cloud records.

3. Examining container images and deployment pipelines

A container may disappear while the image used to create it remains available in a container registry.

This creates an alternative avenue for investigating the software that was deployed.

Investigators may examine:

• Image digests and manifests
• Image tags and historical versions
• Container image layers
• Build metadata
• Dockerfiles and deployment configuration
• Software dependencies
• Vulnerability scan reports
• CI/CD pipeline execution records

For example, Docker provides commands to inspect an image and examine its filesystem configuration.

# List locally available images
docker images --digests

# Inspect image configuration
docker image inspect <image-name>

# Display image history
docker history <image-name>

# Examine changes to an existing container filesystem
docker diff <container-id>

The final command requires the container to remain available to Docker. It cannot inspect an already removed container simply because its image still exists.

An image digest can help identify the exact image version associated with a deployment. Investigators can retrieve the corresponding image, preserve it and perform offline analysis.

Deployment pipelines provide another useful source. Systems such as Jenkins and GitHub Actions may retain build and deployment records, depending on configuration.

These records may help establish:

• Which source-code revision was used
• Which identity initiated a deployment
• When a build occurred
• Which image was produced
• Whether deployment configuration changed
• Which environment received the image

However, an image describes software that could have been deployed; it does not prove everything that happened during execution. Processes, downloaded files, runtime modifications and in-memory activity may not be represented in the original image.

4. Recovering evidence from storage, snapshots and backups

Storage systems can preserve information even after the workload that used them has disappeared.

Investigators should identify whether the environment used persistent volumes, temporary storage, object storage or attached virtual disks.

Potential evidence sources include:

Virtual machine disk snapshots: A snapshot may preserve the filesystem state of a virtual machine at a particular time.

Persistent volume snapshots: These can contain application data, configuration files and other information stored outside the container's writable layer.

Object storage versioning: Where enabled, previous versions of objects may remain available after an object is overwritten or deleted.

Backup catalogues: Backup systems may retain earlier copies of databases, configuration files and application data.

Database transaction logs: These may help reconstruct database operations, depending on the database engine and retention configuration.

Filesystem metadata and journals: Depending on the filesystem and acquisition conditions, these may provide information about file creation, modification or deletion activity.

A snapshot should not automatically be considered a complete forensic image. Investigators must document its origin, creation time, acquisition process and integrity. They should also establish whether the snapshot represents the relevant period.

For example, a volume snapshot created after a malicious file was deleted may not contain that file. Recoverability depends on the storage system, snapshot implementation and the sequence of events.

Where possible, preserve the original snapshot or backup and conduct analysis on a separate working copy.

5. Network-based evidence discovery

Network forensics is particularly useful when the original workload is unavailable because communication records may exist outside the affected host.

Investigators should examine several sources.

DNS records

DNS records may reveal which domain names a workload attempted to resolve.

Potential evidence includes:

• Queried domain names
• Query timestamps
• Response records
• DNS resolver information
• Repeated or unusual query patterns

These records may help identify communication with suspicious infrastructure. However, DNS queries do not independently establish that a connection was successfully completed or that data was transferred.

Firewall and load-balancer logs

Firewall records may show permitted or blocked connections. Load-balancer logs may contain request information, backend selection, response codes and timing, depending on the service and configuration.

These sources can help investigators identify communication paths and correlate activity with application events.

Network flow logs

Cloud platforms provide flow-logging services that record network communication metadata.

For example, Google Cloud VPC Flow Logs can provide information about sampled network packets, aggregated into records associated with IP connections.

These records may help identify:

• Source and destination addresses
• Communication protocols
• Ports
• Traffic volume
• Connection timing
• Associated cloud resource metadata, when available

However, flow logs are not full packet captures. Google documents that VPC Flow Logs use packet sampling and aggregation, with additional filtering and sampling options. Consequently, missing flow records do not prove that communication never occurred.

Packet captures and network sensors

Packet captures may provide more detailed information than flow logs, depending on where and how they were collected.

Investigators may search for existing captures or records from:

• Network intrusion detection systems
• Network detection and response platforms
• Security appliances
• Virtual network packet mirroring
• Host-based packet capture tools
• Gateway and perimeter monitoring systems

A packet capture may contain protocol details, DNS messages, connection handshakes and, where encryption does not prevent inspection, application-level information.

Encrypted traffic may still expose metadata, but investigators should not assume that a packet capture contains readable application content.

The central lesson is that network evidence may survive independently of the workload. Its value depends on collection coverage, retention, sampling and the location of the monitoring system.

6. Searching external security and monitoring platforms

Evidence does not always remain within the cloud account where the incident occurred.

Organizations may forward records to independent security platforms, creating additional sources for investigators.

Examples include:

• Security Information and Event Management (SIEM) platforms
• Endpoint Detection and Response (EDR) systems
• Extended Detection and Response (XDR) platforms
• Centralized log-management systems
• Cloud security posture monitoring tools
• DNS security providers
• Managed Security Service Providers (MSSPs)

These platforms may retain alerts, process events, authentication records, network indicators and other telemetry.

For example, an EDR platform may have recorded a suspicious process before the associated virtual machine was terminated. A SIEM platform may retain a copy of authentication or firewall records that are no longer available in the original cloud account.

Investigators should also consider records held by cloud providers and other authorized service operators.

However, access to third-party records may require organizational authorization, contractual arrangements or appropriate legal processes. Investigators should document the source, collection method and limitations of every acquired record.

7. Where should investigators look first?

Searching every possible evidence source without a plan can waste valuable time. A structured discovery process helps prioritize collection.

The following workflow provides a practical starting point.

Step 1 — Identify the resource

Record the cloud account, region, resource ID, container ID, pod UID, node identifier and relevant time period, where available.

Step 2 — Map the dependencies

Identify associated storage volumes, databases, image registries, identity services, DNS resolvers, network interfaces, load balancers and deployment pipelines.

Step 3 — Preserve surviving volatile evidence

If relevant systems are still running, consider collecting memory, process information, active connections and runtime state before they disappear. Document any actions that could alter the system.

Step 4 — Search independent records

Examine cloud audit services, application logs, DNS records, network telemetry, firewall events, SIEM and EDR data.

Step 5 — Examine historical artifacts

Search image registries, storage snapshots, object versions, backup catalogues and deployment history.

Step 6 — Obtain external records

Where necessary and legally authorized, coordinate with the cloud provider, managed security provider or other relevant service operators.

Step 7 — Correlate and validate

Normalize timestamps, compare resource identifiers, verify record integrity and document missing information.

The result should be an evidence inventory showing which sources were examined, which records were obtained, what remains unavailable and what conclusions each source can support.

8. Preserving and validating digital evidence

Finding a record is only one part of a forensic investigation. Investigators must also demonstrate how the evidence was acquired and whether it has remained reliable.

Several principles are essential.

Evidence provenance: Record the original source, resource identifier, collection date, time, person responsible and acquisition method.

Integrity verification: Calculate cryptographic hashes, such as SHA-256, for acquired files and evidence packages where appropriate.

For example:

sha256sum evidence.log

On Windows (Powershell):

Get-FileHash .\evidence.log -Algorithm SHA256

A hash can help identify subsequent changes to the same file. It does not prove that the original record was complete, accurate or generated by the claimed system.

Time synchronization: Record time zones and clock differences. Do not assume that timestamps from different cloud services use the same time basis or precision.

Chain of custody: Document every transfer, access, examination and storage change involving the evidence.

Preservation of originals: Retain original acquired material securely and perform analysis on verified working copies whenever practical.

Access control: Protect evidence storage against unauthorized access, alteration and deletion.

Cloud services may provide additional integrity mechanisms. AWS CloudTrail, for example, supports log-file integrity validation using hashes and digital signatures. Investigators should establish whether the relevant feature was enabled and follow the provider's documented validation procedure.

These measures help support evidential reliability, but they do not compensate for missing records or inadequate collection coverage.

What investigators must not assume

Cloud investigations involve uncertainty, and several common assumptions can lead to incorrect conclusions.

• A missing log does not automatically mean someone deleted it deliberately.
• A surviving container image does not prove what happened during runtime.
• A network flow record does not reveal the complete application payload.
• An audit event does not necessarily identify the human behind an account.
• A storage snapshot does not guarantee recovery of deleted files.
• A matching hash does not prove that the original evidence was complete.
• The absence of an alert does not prove that malicious activity did not occur.

Investigators must distinguish between directly observed evidence, reasonable interpretation and unverified assumptions.

The goal is not to reconstruct a perfect story from incomplete records. It is to establish what the available evidence supports and clearly document what remains unknown.

Forensic readiness must come first

Cloud infrastructure can be temporary, distributed and highly automated. This changes how investigators approach digital evidence.

The most effective investigations are supported by systems that were prepared for evidence collection before an incident occurred.

Independent log storage, suitable retention policies, cloud audit records, network monitoring, protected backups, controlled access and tested acquisition procedures all contribute to forensic readiness.

For cloud engineers, this is an architectural responsibility. For digital forensic investigators, it is a challenge of evidence discovery, preservation and correlation.

When infrastructure is temporary, evidence preservation must be designed to outlast it.