Chapter 57 Quiz: Cloud Forensics & Investigation¶

B -- The shared responsibility model

The shared responsibility model is fundamental to cloud forensics. In IaaS, the customer controls the OS and above, so they must collect OS logs, application data, and memory dumps. The provider controls the physical hardware and hypervisor layer. In SaaS, the provider controls nearly everything, leaving the customer with only access logs and configuration data. Understanding this boundary is critical for scoping an investigation. Refer to Chapter 57 Section 57.1.

C -- AWS CloudTrail

CloudTrail records every API call made in an AWS account as an event. Each event includes the caller identity (IAM user, role, or service), timestamp, source IP address, request parameters, and response. Management events are logged by default for 90 days; for long-term retention and data event logging (S3 object access, Lambda invocations), a trail must be configured to deliver logs to an S3 bucket. CloudTrail is the first log source investigators examine in any AWS incident. Refer to Chapter 57 Section 57.2.

B -- Create an EBS snapshot

EBS snapshots create an immutable point-in-time copy of a volume. This is the gold standard for disk evidence preservation in AWS because it does not alter the running instance (preserving volatile state), it can be shared across accounts for isolated analysis, and it provides a verifiable chain of custody through API audit trails in CloudTrail. The snapshot can then be attached to a clean forensic workstation instance for analysis. Refer to Chapter 57 Section 57.2.

C -- Volatile evidence

Volatile evidence exists only in the runtime state of a system. In cloud environments, this risk is amplified because auto-scaling can terminate instances, containers can be destroyed and recreated in seconds, and serverless functions exist only during execution. Investigators must prioritize capturing memory dumps, process listings, network connections, and container state before any containment actions that might destroy these artifacts. Refer to Chapter 57 Section 57.1.

C -- Azure AD (Entra ID) audit and sign-in logs

Azure AD sign-in logs record every authentication attempt, including the user, application, location, device, conditional access result, and risk level. Audit logs capture directory changes such as role assignments, group modifications, and application registrations. Together, these are essential for investigating identity-based attacks like credential stuffing, token theft, and privilege escalation through Azure AD. These logs can be streamed to a Log Analytics workspace for KQL-based investigation. Refer to Chapter 57 Section 57.3.

C -- NSG Flow Logs

NSG Flow Logs capture metadata about IP traffic flowing through a Network Security Group, including source and destination IP, source and destination port, protocol, traffic direction, and whether traffic was allowed or denied. Version 2 flow logs also include byte and packet counts and flow state information. These logs are stored in a storage account and can be analyzed with Traffic Analytics or exported to a SIEM for correlation with other evidence. Refer to Chapter 57 Section 57.3.

B -- Security Command Center

Security Command Center (SCC) is GCP's centralized security management platform. It aggregates findings from multiple sources including Event Threat Detection (anomalous IAM grants, cryptocurrency mining), Security Health Analytics (misconfigured resources), Web Security Scanner, and third-party integrations. For forensic investigations, SCC provides a timeline of security findings correlated with Cloud Audit Logs, enabling rapid identification of the attack chain. Refer to Chapter 57 Section 57.4.

C -- Capture pod logs, pod state, container image snapshot, and persistent volume data before containment

In Kubernetes forensics, the priority is evidence preservation before containment. This means running kubectl logs to capture stdout/stderr, kubectl describe pod to record the pod specification and events, exporting the running container as an image (docker commit or crictl checkpoint), and snapshotting any persistent volumes. Only after evidence is preserved should containment actions -- such as network isolation via NetworkPolicy, pod deletion, or node cordoning -- be taken. Refer to Chapter 57 Section 57.5.

B -- LiME (Linux Memory Extractor)

LiME is a loadable kernel module (LKM) that allows acquisition of volatile memory from Linux systems, including those running in cloud environments. It can dump memory in raw, padded, or LiME formats and can output to the local filesystem or over a TCP connection for remote acquisition. For cloud instances, LiME is preferred because it minimizes the forensic footprint on the target system. The resulting memory image can then be analyzed with Volatility or Rekall. Refer to Chapter 57 Section 57.8.

B -- Successful deletion of Azure virtual machines

This KQL query filters the AzureActivity table for successful VM deletion operations. In a forensic context, this is critical for detecting anti-forensic behavior where an attacker destroys evidence by deleting compromised VMs. The query projects the timestamp, the identity of the caller (which could be a compromised service principal or user), the resource group, and the resource ID. This should be correlated with sign-in logs to determine if the deletion was performed by a legitimate administrator or a threat actor. Refer to Chapter 57 Section 57.7.

C -- The ephemeral execution environment eliminates traditional forensic artifacts

Serverless forensics is fundamentally different from traditional or even cloud VM forensics because the execution environment exists only for the duration of the function invocation. Once execution completes, the container may be frozen, reused, or destroyed -- there is no persistent disk or memory to image. Investigators must rely on CloudWatch Logs (Lambda), Application Insights (Azure Functions), Cloud Logging (GCP Cloud Functions), and distributed tracing (X-Ray, OpenTelemetry) that was configured before the incident. This makes proactive logging configuration essential. Refer to Chapter 57 Section 57.6.

B -- Time synchronization and normalization

Multi-cloud investigations require correlating events across providers that use different timestamp formats (ISO 8601, epoch, provider-specific), different log schemas, and potentially different internal clock synchronization mechanisms. Without normalizing all timestamps to a common reference (UTC), the reconstructed timeline will be inaccurate. SIEMs like Sentinel, Splunk, or Chronicle address this through Common Information Model (CIM) or ASIM normalization, but investigators must validate that ingestion pipelines preserve timestamp fidelity. Refer to Chapter 57 Section 57.9.

B -- Document, hash, write-protect, restrict access, and log all collection API calls

Cloud evidence chain of custody requires the same rigor as physical evidence but adapted for cloud-native workflows. Every evidence artifact must be cryptographically hashed at collection time and verified at each transfer. The cloud API audit trail (CloudTrail, Activity Log, Cloud Audit Logs) automatically documents collection actions with timestamps and caller identity. Evidence should be stored in immutable storage (S3 Object Lock, Azure Immutable Blob, GCS retention policies) with access restricted to the investigation team. Refer to Chapter 57 Section 57.8.

B -- Query the Kubernetes API server audit logs for ClusterRoleBinding creation events

Kubernetes API server audit logs record every request to the API, including RBAC modifications. This SPL query filters for create operations on the clusterrolebindings resource matching the suspicious name pattern, showing the timestamp, the authenticated user who made the request, the binding name, and the request URI. This is critical for determining whether the attacker used a compromised service account, a stolen kubeconfig, or exploited a vulnerability to escalate privileges. The etcd datastore also contains historical state if API audit logging was not enabled. Refer to Chapter 57 Section 57.5.

C -- AVML operates from user space without requiring a kernel module

Unlike LiME, which requires loading a kernel module compiled for the exact kernel version of the target system, AVML uses /dev/crash or /proc/kcore to acquire memory from user space. This is a significant advantage in cloud environments where instances may run many different kernel versions and compiling a matching LiME module for each is impractical. AVML produces output in LiME format or Microsoft's own AVML format, both of which can be analyzed with Volatility. This user-space approach also reduces the forensic footprint on the target system. Refer to Chapter 57 Section 57.8.