Practice with national-level exam (FACT, FACT Plus, NET, CUET, etc.) mocks, learn from structured notes, and get your doubts solved in one place.
Cloud forensic logging across AWS, Azure and GCP, EBS and managed-disk snapshot acquisition, NIST 800-61 incident response in cloud accounts, and the CERT-In April 2022 180-day retention rule that anchors Indian cloud cases.
Cloud forensics starts with logs the investigator never owned. The disks belong to the provider, the hypervisor is invisible, the storage volume is sliced across an availability zone, and the only durable record of who did what is whatever the customer remembered to enable before the breach. CloudTrail off by default in a region, Activity Log not exported to a workspace, audit logs retained for 30 days when the attacker dwelled for 60: these are the patterns that decide whether a cloud case is solvable. The acquisition step is no longer "pull the disk and image it." It is "snapshot the managed volume, share it cross-account, attach it to a forensic instance, hash it, and write the BSA Sec 63 certificate."
This topic walks the digital forensics cloud incident response workflow as practised in Indian SOCs and CERT-In coordinated cases. The control-plane vs data-plane log split is treated in detail across AWS, Azure and GCP. The forensic snapshot procedure is given as a five-step runbook with the IAM and KMS gotchas that turn a clean acquisition into a contaminated one. NIST SP 800-61 incident response is mapped onto cloud-specific containment. The Indian anchor is the CERT-In Direction of April 2022 that mandates 180-day log retention for service providers and intermediaries, the financial-sector RBI overlays, and the cross-link to network-side defence at Network security, firewalls, IDS, IPsec, SSL/TLS, VPN, PKI, SIEM.
Three vocabularies, one mental model.
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.
| Layer | AWS | Azure | GCP |
|---|---|---|---|
| Control plane | CloudTrail (management events) | Activity Log | Cloud Audit Logs · Admin Activity |
| Data plane | CloudTrail data events (S3, Lambda, DynamoDB) | Resource Logs (storage, key vault, SQL) | Cloud Audit Logs · Data Access |
| Network flow | VPC Flow Logs | NSG Flow Logs | VPC Flow Logs |
| Object access | S3 server access logs, S3 Object Lambda logs | Storage analytics logs | Cloud Storage usage logs |
If logging was not on before the breach, the case is half lost.
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:
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.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 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.
The forensic image is no longer a disk you can hold.
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 it can be taken without disturbing the running VM and shared across accounts to a clean forensic environment.
The lifecycle works in the cloud only if the controls work in the cloud.
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.
From CloudTrail anomaly to scoped containment in one pass.
A composite case shows the flow. 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:
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.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 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.
CERT-In, RBI, NCIIPC and the DPDP Act 2023.
The legal and regulatory frame for cloud incidents in India sits on top of the technical workflow. Five anchors matter for real cases and for real cases.
| Anchor | Source | What it requires | Forensic implication |
|---|---|---|---|
| CERT-In Direction (April 2022) | Dir. 20(3)/2022-CERT-In under IT Act Sec 70B(6) | 180-day log retention; 6-hour incident reporting; NPL/NIC time sync; KYC retention for VPN/VPS providers | Defines the minimum log inventory and the reporting clock |
| RBI Cyber Security Framework | RBI Master Direction on IT Governance 2023 | Tiered controls for banks/NBFCs; SOC; cyber drills; cloud-specific controls under Banking Cloud Framework 2023 | Longer retention and dedicated log sinks for BFSI tenants |
| NCIIPC guidelines | National Critical Information Infrastructure Protection Centre | Reporting and incident response for designated CII entities | Parallel reporting to NCIIPC and CERT-In for power, banking, telecom, transport |
| DPDP Act 2023 | Digital Personal Data Protection Act |
Which CERT-In direction sets the 180-day log retention and the six-hour incident reporting clock for Indian cloud service providers and intermediaries?
| Load balancer | ELB / ALB access logs | App Gateway, Front Door diagnostics | HTTP(S) LB logging |
| Anomaly findings | GuardDuty, Security Hub | Microsoft Defender for Cloud, Sentinel | Security Command Center |
| Config drift | AWS Config history | Azure Policy compliance, Resource Graph | Asset Inventory + Recommender |
| Custom / system | CloudWatch Logs | Log Analytics workspace | Cloud Logging |
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 before it is a forensic one.
cloudtrail:StopLoggingCentralised 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.
Memory acquisition from cloud VMs is harder than memory acquisition from a physical machine because the hypervisor is invisible to the customer. The realistic approaches in 2026:
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.winpmem or avml inside the guest.The cleanest pattern across all three is to take the disk snapshot first and the memory dump second, because the memory acquisition agent will modify 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.
Cloud-specific containment is its own discipline. 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.
iam:CreateAccessKey| Breach notification to the Data Protection Board and to affected data principals |
| Personal data breach reporting overlay on top of CERT-In |
| BSA 2023 Section 63 | Bharatiya Sakshya Adhiniyam 2023 | Electronic record admissibility with Sec 63(4) certificate | The cloud image and the log extract both need a Sec 63 certificate signed by the person responsible for the system |
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.