Cloud Forensics: Multi-Tenant, API and Jurisdictional Challenges

NIST IR 8006 catalogues 65 challenges across nine categories. For the digital forensics examiner, seven of them carry the practical weight.

Volatility is the first. Cloud resources can be deprovisioned in seconds, by the customer or by an attacker who has the customer's credentials. An EC2 instance terminated by an attacker disappears from the console immediately; the EBS volume backing it is deleted by default unless DeleteOnTermination was false; the memory state is gone instantly. Auto-scaling groups spin instances up and down on demand. Spot instances die when the spot market reclaims them. The CFSL Hyderabad cyber wing's documented practice is to issue a preservation order through the IO that names every active resource in the suspect account within the first hour of incident notification, then convert active snapshots and freeze auto-scaling.

Multi-tenancy is the second. Shared physical hardware is the cloud's economic model. Tenants are isolated by the hypervisor, by network segmentation and by storage allocation, but they share CPUs, NICs, storage controllers and physical RAM. Chain-of-custody concerns arise when an acquisition would, in principle, capture state belonging to another tenant. Providers handle this by acquiring at the customer-visible boundary: snapshots of customer-owned volumes, exports of customer-owned databases, never anything that traverses tenant boundaries.

Cross-jurisdiction is the third. The data may live in a region different from where the incident is being investigated. Microsoft 365 audit logs for an Indian customer can be stored in EU or US regions depending on the tenant's data residency configuration. A Salesforce instance for an Indian enterprise might have its event monitoring logs in the US. When Indian authorities require those logs, the conflict between the US CLOUD Act (which compels US providers to produce data regardless of where it is stored) and Indian sovereignty under the DPDP Act 2023 surfaces directly.

API dependency is the fourth. Every legal access pathway runs through a provider API. AWS gives subpoena response through a structured process documented at d1.awsstatic.com/legal documents. Microsoft has a Law Enforcement Request Report mechanism. Google's Transparency Report names the volume of Indian government requests served. Without provider cooperation, the data is not accessible. Without an API to query, the cooperation is meaningless.

Lack of physical access is the fifth. The examiner never touches the storage media, never sees the host, never controls the hypervisor. This breaks the traditional forensic principle of working from a write-blocked physical image. The substitute is a chain-of-custody documented in API calls and provider attestations.

Trust in provider logs is the sixth. The examiner accepts CloudTrail, Activity Log and Cloud Audit Logs as authoritative because there is no alternative. The provider's certifications (SOC 2, ISO 27001, the MeitY empanelment audit) are the only assurance that the logs are accurate and tamper-evident. CERT-In Direction April 2022 demands 180-day retention precisely because of this dependency.

Vendor cooperation, the seventh, varies by provider and request type. Subpoenaed metadata is usually handed over quickly; content takes a court order and an MLAT for cross-border. Customer-managed encryption keys mean the provider hands over ciphertext only.

The cloud version of the standard digital forensics workflow retains the four phases but changes the mechanics of every step.

Identify means working out what cloud services the suspect or victim was using. The starting points are the AWS account ID or the Azure tenant ID, the admin console history, the monthly bill, and the corporate IAM directory. The bill is often the most useful identification artifact in an unknown-environment investigation: every service that was active in the billing period is itemised. A subpoena to the provider yields the account inventory if the customer cannot or will not cooperate.

Preserve means stopping the resources from being modified or destroyed. The legal mechanism is a litigation hold (US-style term) or a preservation order (Indian-style term), served on the provider through their law-enforcement channel. The technical mechanism is provider-specific: enable S3 Object Lock on buckets, take EBS snapshots of active volumes, enable RDS snapshot retention, freeze the auto-scaling group at current capacity, revoke API keys to prevent attacker tampering. CERT-In Direction 2022's 180-day retention obligation is the regulatory floor; for an active investigation, the preservation order extends it.

Acquire means pulling the evidence out of the provider and into the forensic workspace. API-based acquisition uses the provider SDK: boto3 for AWS, azure-cli and the Azure SDK for Python for Azure, gcloud and the GCP Python SDK for GCP. Provider-console export is the manual fallback. Third-party tools sit on top of the APIs: Magnet AXIOM Cloud handles AWS, Azure and major SaaS; FaceIt Cloud (now branded as Cellebrite Cloud Analyzer in newer versions) covers similar ground; Oxygen Forensic Cloud Extractor focuses on cloud backup acquisition (iCloud, Google, Microsoft); Belkasoft Forensic Studio includes a cloud module. Each tool produces its own report format; each must be named in the BSA 2023 Section 63 certificate.

Analyse means running the same analytic toolchain the examiner uses on-prem against the acquired data, once it is on disk in the forensic workspace. The cloud-specific cognitive shift is that the analyst now thinks in terms of timelines built from API call logs alongside file-level evidence, with the principal-to-action mapping carrying as much weight as the file MAC times.

1. Identify the cloud footprint
   Pull the account inventory from billing, admin console, and IAM directory. For an unknown environment, subpoena the provider for the account list tied to the suspect identity. Document the AWS account ID, the Azure tenant ID and any Google Workspace domain in the case file.
2. Preserve before acquiring
   Issue the preservation letter through the provider's law-enforcement channel. Technically enable S3 Object Lock, take EBS snapshots with the forensic AWS account as the snapshot owner, freeze auto-scaling and revoke compromised credentials. CERT-In retention obligations run from the date of notification.
3. Acquire through API and tools
   Use boto3, az cli or gcloud to enumerate and export. Use Magnet AXIOM Cloud, Oxygen Cloud Extractor or Belkasoft to acquire SaaS-side artifacts (Microsoft 365 mailbox, Google Workspace audit, iCloud backup). Hash every artifact with SHA-256 at the moment of acquisition.
4. Transfer to forensic workspace
   Bring snapshots into a dedicated forensic AWS or Azure account that is isolated from the production environment. Mount snapshots read-only against forensic EC2 instances. Maintain the chain-of-custody log with every API call timestamp and principal.
5. Analyse with on-prem tools
   Once data is on disk in the forensic workspace, run the standard tools: Plaso for super-timelines, Volatility for memory captures, Autopsy and X-Ways for disk images, jq and Splunk for log analysis. The BSA 2023 Section 63 certificate names every tool with version.

Every cloud incident reconstruction starts with the API call history. The architectural distinction a forensic analyst must hold is control-plane versus data-plane.

Control-plane logs record API calls that change the configuration or state of the cloud resources themselves. Creating an EC2 instance, attaching an IAM policy, opening a security group, deleting an S3 bucket: these are control-plane operations. The reference log surface is AWS CloudTrail, which records every API call to every supported AWS service. The equivalent on Azure is Activity Log (resource manager actions); on GCP it is Cloud Audit Logs (Admin Activity and System Event streams). Every entry names the principal (the IAM user, role or service account), the source IP, the user agent, the action, the target resource, the request and response details, and the timestamp in UTC. CloudTrail has been on by default since 2017 for management events; the customer must enable data-event logging and CloudTrail Lake or S3 delivery for retention beyond 90 days. CERT-In Direction 2022's 180-day retention is the operative Indian floor.

Data-plane logs record what was actually accessed inside the resources. S3 server access logs and Amazon S3 access logs record every GET, PUT and DELETE against bucket objects. GCS access logs record the equivalent for Google Cloud Storage. Azure Storage Analytics logs cover Blob, Queue and Table. The distinction matters because a control-plane API call (s3:PutObject via CloudTrail) records that an object was uploaded; the data-plane access log records who downloaded it later through which client. For a data exfiltration investigation, both layers are needed.

Delta analysis between user-reported actions and API timestamps is a recurring pattern. A suspect claims they downloaded a file at 14:00 IST on 12 March. The CloudTrail s3:GetObject data event shows the same principal accessing the same object at 02:30 UTC on 14 March, which is 08:00 IST on 14 March. The 42-hour gap between the suspect's story and the API record is the evidence. The same pattern applies to claimed account compromise. If the suspect says they were hacked at 10:00 on 5 April but the IAM CreateAccessKey operation that issued the attacker's credentials happened at 09:45 with the suspect's own user principal, the compromise story has a timing problem.

API-based timestamps are nanosecond-accurate in the underlying records and second-accurate in the log surfaces. They are synchronised across regions because cloud providers run distributed time services. CERT-In Direction 2022 also requires that customer system clocks be synchronised to NPL (National Physical Laboratory) or NIC time sources, which means the Indian customer's own workload logs should also be coherent with the provider's API logs to within a few seconds.

VM snapshot acquisition is the cloud counterpart to imaging a hard drive. The steps below are AWS-specific but the pattern is identical on Azure and GCP.

The forensic AWS account is a dedicated account, separate from the production account, that the forensic team controls. Snapshots taken in the production account are shared with the forensic account through aws ec2 modify-snapshot-attribute. The snapshots are then copied (not just shared) into the forensic account, which gives the forensic team a fully owned copy that survives even if the production account is later compromised or deleted. The copied snapshot is then turned into a volume in the forensic account and attached to a dedicated forensic EC2 instance for analysis.

1. Snapshot the source volume
   In the production account, take an EBS snapshot of the volume of interest. The snapshot is incremental but is logically a full copy. Record the snapshot ID and the SHA-256 of the snapshot manifest.
2. Share with the forensic account
   aws ec2 modify-snapshot-attribute --snapshot-id snap-xxx --attribute createVolumePermission --operation-type add --user-ids ForensicAcctId. Document the cross-account share in the case log.
3. Copy into the forensic account
   aws ec2 copy-snapshot --source-region ap-south-1 --source-snapshot-id snap-xxx. The copy is a new, fully owned snapshot in the forensic account, independent of the production account.
4. Create a volume and attach read-only
   Create an EBS volume from the copied snapshot. Attach to a forensic EC2 instance with the device read-only at the OS layer (mount -o ro). Calculate dd-based hashes against the device to confirm integrity.
5. Analyse with on-prem tools
   Run Plaso log2timeline, Volatility against any memory capture, Autopsy or X-Ways against the disk. Every analytic action is logged in the case journal. The BSA 2023 Section 63 certificate names the source snapshot, the copy chain, and the tools.

Cloud storage forensics covers S3, Azure Blob, GCS and equivalents. The artifacts to acquire are the bucket inventory (every object with size, ETag and last-modified), the bucket policy and ACL state (who can access what), the bucket versioning state (objects may have prior versions that survive a delete), the encryption configuration (SSE-S3, SSE-KMS with which key, or customer-provided keys), the access logs covering the relevant period, and any lifecycle policy that may have transitioned or expired evidence. S3 Object Lock in Compliance mode is the strongest preservation primitive: once enabled, no principal including the account root can delete the object before the retention period expires.

Cloud database forensics covers managed databases: RDS, Aurora, DynamoDB, Cosmos DB, Cloud SQL. The standard acquisition path is the automated snapshot (RDS exports a snapshot as a Parquet dataset to S3, Cosmos DB exports a backup to a blob container). Transaction logs and change data capture streams (DynamoDB Streams, Cosmos DB change feed) record row-level changes when enabled. The acquisition has to be paired with the schema and the application code; row-level evidence without context rarely persuades a court.

Cloud incident response inverts the on-premises priority. On a workstation, the responder captures memory before doing anything else. In the cloud, the responder isolates first: the attacker still holds valid credentials and can delete evidence faster than an acquisition can proceed.

Isolation steps are credential-first. Revoke the suspected compromised IAM user's access keys with aws iam delete-access-key. Disable the user with a deny-all policy attachment. For a role, revoke active sessions with aws iam put-role-policy setting aws:TokenIssueTime deny conditions. Quarantine the affected EC2 instance by replacing its security group with a deny-all SG (do not stop or terminate; that loses memory). Quarantine the affected S3 bucket by attaching a bucket policy that denies the principal pending investigation. For an account-wide compromise, the SCP (Service Control Policy) at the AWS Organizations layer applies a denial across the suspect account.

Preservation runs concurrently with isolation. Take an EBS snapshot of every volume on every quarantined instance. Capture memory through SSM Run Command driving Magnet RAM Capture or LiME on Linux instances. Pull the last 24 hours of CloudTrail through Athena or CloudTrail Lake into a forensic S3 bucket in the forensic account. Enable S3 Object Lock on all buckets named in the incident scope. Enable RDS automated snapshot retention if not already at the maximum.

Analysis runs after isolation and preservation. The sequence is not arbitrary: reversing it risks losing volatile evidence before it can be secured. The Indian banking sector cloud incident response playbook published by the IDRBT (Institute for Development and Research in Banking Technology) in 2022 codifies this exact ordering, with a mandatory 6-hour notification to CERT-In aligned with the April 2022 Direction.

The Indian legal framework around cloud forensics is layered. Each layer constrains a different part of the workflow.

The DPDP Act 2023 (notified 11 August 2023, rules released for consultation in early 2025, full operationalisation phased) is the general personal-data law. Section 8 imposes obligations on data fiduciaries to process personal data with reasonable security safeguards. Section 16 empowers the central government to restrict cross-border transfer to specified countries. For the examiner, DPDP affects acquisition: personal data of Indian residents acquired during a forensic engagement is itself processing, and the data fiduciary's preservation purposes must be documented. The Data Protection Board of India (DPBI), constituted under Section 18, is the regulator.

The CERT-In Direction of 28 April 2022, issued under Section 70B(6) of the IT Act 2000, is more operational. Six-hour reporting for specified cyber incidents is the headline. 180-day log retention within India is the second pillar. The third is KYC obligations on data centres, VPS providers, cloud providers and VPN providers: they must retain accurate customer information for five years. The fourth is clock synchronisation to NPL (National Physical Laboratory, Delhi) or NIC time servers. For the forensic examiner, CERT-In Direction sets the retention floor against which the preservation order must extend, and defines the incident category list (twenty types) that trigger the 6-hour reporting clock.

The IT (Intermediary Guidelines and Digital Media Ethics Code) Rules 2021 (with the 2022 and 2023 amendments) bind intermediaries: social media platforms, messaging services, OTT platforms and digital news media. The Significant Social Media Intermediary (SSMI) threshold of 50 lakh (5 million) registered Indian users triggers additional obligations including a Chief Compliance Officer, Nodal Contact Officer, Resident Grievance Officer, monthly compliance report, and traceability of the first originator of information (Rule 4(2)). The Grievance Appellate Committee (GAC) under the 2022 amendment provides a tiered appeal mechanism: user complains to platform grievance officer, then to GAC if unsatisfied. For the examiner, SSMI status determines what evidence the platform is obliged to retain and how quickly it must respond to a lawful Indian authority's preservation request.

MLAT is the cross-border evidence pathway. India has Mutual Legal Assistance Treaties with over 40 countries. The Ministry of Home Affairs (MHA) is the central authority. The US India MLAT is invoked for evidence from US-based providers. The MLAT process is documented and lawful but slow: reported averages of 8 to 12 months for the US route. Time-sensitive matters use the informal channel through the Indian offices of SSMIs (Meta India, Google India, Microsoft India, Twitter/X India), which provide preservation and limited content responses under expedited procedures for emergency requests involving threat to life. The Sushant Singh Rajput case in 2020 illustrated the workflow: the Mumbai Police issued summons and preservation notices to Twitter and Instagram through their Indian offices; certain content subpoenas required MLAT routing through the MHA to US providers.

The CLOUD Act tension is unresolved. The US Clarifying Lawful Overseas Use of Data Act 2018 compels US service providers to produce data subject to a US warrant regardless of where the data is physically stored. India is not a designated qualifying foreign government under the CLOUD Act's executive agreement mechanism as of the current date, which means data of Indian residents stored by US providers in India could in principle be compelled to the US under a US warrant. The DPDP Act 2023's cross-border provisions are India's regulatory response. Most Indian customers manage this through contractual clauses requiring the provider to notify them of any CLOUD Act request before producing data, and through architectural choices such as customer-managed encryption keys.