Cloud Logging, VM Snapshots and Cloud Incident Response

The first task on any cloud case is to know which logs exist, which are on by default, and which had to be turned on before the incident. The vocabulary is different across AWS, Azure and GCP, but the mental model is the same: a control-plane log records management API calls, a data-plane log records access to the data, a network log records flow tuples at the VPC layer, and a security service log records derived findings from anomaly detection.

CloudTrail in AWS is on by default for the last 90 days of management events through the Event History view, but the default retention is short and the events are not searchable at scale until a trail is configured to write to an S3 bucket. Data events (S3 GetObject, Lambda Invoke) are off by default; their absence is the single most common gap in compromised-account cases. Azure Activity Log is on by default for 90 days but does not persist beyond that unless exported to a Log Analytics workspace, an Event Hub, or a storage account. GCP's Admin Activity logs are on by default and retained for 400 days; Data Access logs are off by default for cost reasons and must be enabled per service.

The Indian anchor sits across all three providers. The CERT-In Direction of April 2022 (No. 20(3)/2022-CERT-In) makes 180 days of log retention a statutory minimum for service providers, intermediaries, data centres, VPS providers, and cloud service providers serving Indian users. The same direction sets a six-hour reporting window for notifiable incidents. RBI's Master Direction on Information Technology Governance (2023) pushes scheduled commercial banks to longer retention and to dedicated log sinks. A breach response that finds only 30 days of CloudTrail history on an Indian bank tenant is a compliance failure as much as a forensic one.

Default retention windows are short by design because logging at cloud scale costs money. The forensic readiness step is to move every log of interest to an immutable, write-once destination before any incident happens. The control surfaces that matter:

• AWS: CloudTrail organisation trail writing to a dedicated audit account S3 bucket; bucket has S3 Object Lock in compliance mode, KMS encryption with a key in the audit account, and a bucket policy denying s3:DeleteObject, s3:PutObjectLegalHold:false, and s3:DeleteBucketPolicy to everyone including root. A service control policy on every account in the organisation denies cloudtrail:StopLogging, cloudtrail:DeleteTrail, cloudtrail:UpdateTrail, and cloudtrail:PutEventSelectors.
• Azure: Diagnostic settings exporting Activity Log and Resource Logs to a Log Analytics workspace in a separate subscription. Immutability policy on the underlying storage account (time-based retention or legal hold). Azure Policy denies modifications to the diagnostic settings. Sentinel pulls from the workspace for detection.
• GCP: Aggregated log sink at the organisation level routing to a Cloud Storage bucket with bucket lock retention or to a BigQuery dataset with partition expiration. Organisation policy iam.disableServiceAccountKeyCreation and storage.uniformBucketLevelAccess cut off common attacker paths. Audit log configs explicitly enable Data Access for the high-value services.

The point of the immutability story is that an attacker who lands in an account with cloudtrail:StopLogging permission will use it. The 2019 Capital One breach used a server-side request forgery to assume a role and exfiltrate from S3; the 2024 Snowflake-customer compromises ran for weeks because data access logs were off. In both pattern cases the gap was on the customer side, not the provider side. Forensic readiness fixes the gap before the incident, not during.

Centralised collection is the second half of readiness. SIEM ingestion into Splunk Cloud, Microsoft Sentinel, Sumo Logic, or Elastic Security gives the responder one query surface across the providers. The trade-off is cost: VPC Flow Logs at any real scale generate terabytes a day, and ingestion-by-volume pricing on a SIEM can run into lakhs per month. The standard Indian SOC pattern is to send control-plane and security-service logs in full, and to filter VPC Flow Logs at the source (sampling 1 in 100, or sending only rejected traffic) until an incident makes the full feed worth the bill.

The cloud equivalent of a write-blocked drive image is the storage-layer snapshot. AWS EBS, Azure managed disks, and GCP persistent disks all expose a snapshot API that captures the block device state at a point in time. The snapshot is incremental on the back end but presents as a full copy. The forensic value is that a snapshot can be taken without disturbing the running VM and shared across accounts to a clean forensic environment.

1. Snapshot the running volume
   AWS: `aws ec2 create-snapshot --volume-id vol-xxxx --description "forensic case 2026-CSL-417"`. Azure: snapshot the managed disk through the portal or `az snapshot create`. GCP: `gcloud compute disks snapshot`. Crash-consistent by default; application-consistent if the OS filesystem is quiesced (`fsfreeze` on Linux, VSS on Windows) or the VM is paused first.
2. Share the snapshot to the forensic account
   AWS: `aws ec2 modify-snapshot-attribute --create-volume-permission Add=UserId=<forensic-account>`. If the volume is KMS-encrypted, also share the CMK or re-encrypt the snapshot with a forensic-account KMS key. Azure: snapshot can be exported as a SAS URL, or the managed disk can be moved to a forensic resource group with RBAC restricted to the case examiner. GCP: snapshot is granted IAM access for the forensic project service account.
3. Create a volume from the snapshot in the forensic account
   AWS: `aws ec2 create-volume --snapshot-id snap-xxxx --availability-zone <fz>`. The new volume sits in the forensic VPC, behind a security group that allows only the analyst workstation.
4. Attach to a forensic instance
   Attach the volume to a hardened, read-only forensic EC2 (or equivalent) running SIFT Workstation or a custom Ubuntu with dc3dd, ewfacquire, libewf, sleuthkit, Volatility 3, and Plaso. Mount with `mount -o ro,noatime,noexec`.
5. Image and hash
   `dc3dd if=/dev/nvme1n1 of=/case/forensic.E01 hash=sha256 hash=md5 log=/case/forensic.log` or `ewfacquire`. Record the source snapshot ID, the volume ID, the instance ID, the IAM role, the CMK ARN and the dual hash in the BSA Sec 63(4) certificate.

Memory acquisition from cloud VMs presents constraints absent in physical investigations because the hypervisor is outside customer visibility. The realistic approaches in 2026:

• AWS: the AWS Forensics Pipeline (open-source reference from AWS Security) takes an EBS snapshot of the root volume and triggers vmsync or avml (Microsoft's Linux memory tool) on the running instance to dump RAM to an S3 bucket in the forensic account. The dump is then fed to Volatility 3 with the appropriate Linux symbol pack or Windows profile. The catch is that running the agent on the live instance is itself an action that touches the system; it is documented in the runbook.
• Azure: the Azure VM Inspection Pack (Microsoft) pauses the VM at the hypervisor layer and exports a memory dump for the supported sizes. Outside the pack, the standard approach is to run winpmem or avml inside the guest.
• GCP: no first-party memory acquisition product; the in-guest approach is the only viable one.

Across all three platforms, the correct sequence is to take the disk snapshot first and the memory dump second, because the memory acquisition agent modifies the disk state. Snapshot-first preserves the unaltered disk for the chain-of-custody record, and the memory dump is documented as a known footprint.

NIST SP 800-61 Revision 2 is the incident response lifecycle that every Indian SOC builds on. The four phases (Preparation, Detection and analysis, Containment, eradication and recovery, Post-incident activity) apply to cloud the same way they apply to on-prem, but the mechanics shift.

1. Preparation
   Forensic readiness: logging enabled with immutable destinations, runbooks rehearsed, forensic account stood up with cross-account roles pre-provisioned, SCPs in place, IAM Identity Center wired up, emergency break-glass account documented. The CERT-In incident response policy is on file and the six-hour reporting clock is understood.
2. Detection and analysis
   Alerts triage from GuardDuty, Defender for Cloud, Security Command Center, plus SIEM correlations. Scope determination: which accounts, which roles, which resources. The output is an incident timeline with timestamps in UTC and an initial impact statement.
3. Containment, eradication, recovery
   Containment first via security-group narrowing and IAM credential revocation, then eradication by destroying compromised resources, rotating keys, and rebuilding from clean images, then recovery by restoring traffic to the rebuilt resources.
4. Post-incident
   Lessons learned, written incident report, IoC sharing with CERT-In and sectoral CERTs (CERT-Fin for BFSI, NCIIPC for critical infrastructure), update of the runbooks. The post-incident review is where the cost of skipped readiness becomes visible.

Cloud containment differs from on-prem containment in the absence of physical access. The first move on a compromised EC2 instance is to replace the security group with a quarantine security group that allows inbound only from the forensic analyst IP and outbound nowhere. The instance is left running long enough for memory acquisition. IAM credentials attached to the instance profile are revoked with aws iam put-user-policy adding an explicit Deny on everything, or by attaching the AWS managed AWSCompromisedKeyQuarantineV3 policy that denies the dangerous actions while leaving read access for investigation. The snapshot of the EBS volume is taken before the instance is terminated.

On a compromised S3 bucket, containment is a bucket policy that denies all principals except the investigation role, plus enabling versioning and Object Lock if they were not already enabled. On a compromised user account, the access keys are deactivated (not deleted, because deletion destroys the audit trail of which key did what), MFA is forced, the password is rotated, and active sessions are revoked. On a compromised Azure tenant the equivalent is conditional access lockdown and revocation of refresh tokens through Revoke-AzureADUserAllRefreshToken.

The following composite case illustrates the full workflow. An Indian fintech subsidiary running on AWS receives a GuardDuty finding at 02:47 IST: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltrationOutsideAWS. The finding includes the AccessKeyId of an instance profile credential used from an IP in another country. The SOC analyst pulls CloudTrail history filtered on that AccessKeyId.

The investigation walks the following surface, in order:

• CloudTrail by AccessKeyId for the last 30 days, filtered to write events. The result: 47 calls to s3:ListBuckets, 312 calls to s3:GetObject against a single bucket containing customer KYC documents, and four calls to iam:CreateAccessKey against three other IAM users.
• CloudTrail by source IP to find any other credentials used from the same IP. Two more AccessKeyIds appear, both belonging to long-lived IAM users whose keys were probably leaked from a developer laptop.
• VPC Flow Logs filtered to the EC2 instance that held the original instance profile. Outbound flows to the foreign IP for the past 18 days. The instance is identified, the security group is captured.
• S3 server access logs for the KYC bucket, confirming the GetObject pattern and giving exact byte counts that establish the scope of exfiltration.
• Config history for the instance, showing that the instance metadata service (IMDS) is at v1 (the older, exploitable version). The root cause is an SSRF in a containerised web app that lets the attacker hit 169.254.169.254 and pull the instance role credentials.

The containment runs in parallel. The compromised instance profile credential is deactivated. The instance security group is replaced with the quarantine SG. The EBS volume is snapshotted, shared cross-account, and attached read-only to a forensic m6i.large for imaging. The two leaked human-user keys are deactivated. The S3 bucket policy is locked to deny all principals except the investigation role. The CERT-In six-hour clock is met by reporting at 06:30 IST with the impact statement, IoC list, and initial scope.

The post-incident write-up flags the fixes: enforce IMDSv2 across the account, rotate the leaked developer keys, move long-lived keys to IAM Identity Center with short-lived SSO sessions, narrow the S3 bucket to a VPC endpoint with a bucket policy that denies non-VPC access, and add an SCP that denies iam:CreateAccessKey for non-break-glass users. The case is closed with the CERT-In follow-up report and a customer-notification decision under the DPDP Act 2023 obligations.

The legal and regulatory frame for cloud incidents in India applies on top of the technical workflow. Five anchors govern real investigations.

The CoWIN data-leak claims of 2023 are the recurring Indian example, though the government's position was that no breach of the CoWIN platform itself was confirmed and that the leaked data appeared to have originated from a Telegram bot fed by older datasets. Whatever the final attribution, the case is a teaching point on what a cloud-era breach response looks like under the CERT-In Direction: a notifiable incident, a six-hour clock, a coordinated reply by the platform owner and CERT-In, and a parallel inquiry by I4C. The network-side defences that fence cloud workloads are covered at Network security, firewalls, IDS, IPsec, SSL/TLS, VPN, PKI, SIEM. The hypervisor and multi-tenant boundary that sits underneath every cloud forensic case is at Cloud technology, virtualization and cloud security architecture; the deeper acquisition story for managed disks and cloud-backed endpoints is at Virtual machine and cloud-backed endpoint forensics.