Cloud Forensics Guide: Investigating Incidents in AWS, Azure and Google Cloud

In the cloud, most of the evidence you need either lives in provider logs with short default retention or sits on resources that automation will delete before anyone thinks to preserve them. Cloud forensics is the discipline of acquiring, preserving and analysing that evidence in a way that stands up to scrutiny, across a control plane you do not own and infrastructure you cannot touch. This guide covers what evidence exists in AWS, Microsoft Azure and Entra ID, and Google Cloud, the default retention traps, how to acquire disk and memory from virtual machines, chain of custody in a shared responsibility model, and how to investigate service principals, roles and other non-human identities. It is written for incident responders, cloud security engineers and forensic analysts. Response coordination, containment and communications are covered in the Cloud Incident Response Guide; this page is about the evidence.

Key takeaways

• Retention decides what you can prove. AWS CloudTrail event history keeps 90 days of management events, Entra ID Free keeps sign-in and audit logs for 7 days, and Google Cloud's _Default bucket keeps 30 days, unless you configured more before the incident.
• Data-plane logging is off by default. CloudTrail data events and most Google Cloud Data Access audit logs must be enabled explicitly, so "did they read the bucket?" is often unanswerable after the fact.
• Snapshot first, then isolate. Protect the resource from termination, snapshot its disks, capture memory if it matters, and only then cut it off or shut it down.
• Identities are the main thread. Most cloud intrusions are a story told through access keys, service principals, roles and tokens, so the investigation pivots on identity, not on hosts.
• Preserve evidence in a separate, locked-down account. A dedicated forensics account or subscription with immutable storage and recorded hashes gives you chain of custody the attacker cannot reach.

Why cloud forensics is different

NIST's Cloud Computing Forensic Science Challenges (NISTIR 8006) aggregates and categorises the problems responders face in cloud environments. In practice they come down to five differences from traditional forensics.

• No physical access: you cannot pull a drive or attach a write blocker. Acquisition goes through provider APIs (snapshots, exports, log queries), so the integrity of the evidence depends on the provider's controls and your logging of every API call you make.
• Ephemerality: auto scaling groups, containers, serverless functions and spot instances can disappear in minutes. Instance store volumes and ephemeral OS disks cannot be snapshotted at all.
• Shared responsibility for evidence: the provider holds hypervisor and physical evidence you will never see. Your evidence is what you configured the platform to log and what you can extract from your own resources.
• Multi-tenancy and jurisdiction: logs and snapshots live in specific regions, and copying them elsewhere can raise data residency questions. Keep forensic copies in the same region unless counsel agrees otherwise.
• Identity-centric attacks: attackers rarely need malware on a host. A stolen access key or an abused service principal leaves its trail almost entirely in control plane logs.

Evidence sources and default retention by provider

Know these defaults before an incident. If your retention is the default, the first hour of any investigation should include exporting what still exists.

To extend retention, route logs to storage you control: a CloudTrail organisation trail or CloudTrail Lake event data store in AWS, Entra and Azure diagnostic settings to a Log Analytics workspace or storage account, and Cloud Logging sinks or longer _Default retention in Google Cloud. Microsoft Graph activity logs exist only if you archive them. See the Cloud Logging and Audit Trail Guide and the Log Management and Retention Guide.

Acquiring evidence from compute

AWS's Security Incident Response guidance sets an order for EC2 instances that preserves the most data. The same sequence translates directly to Azure and Google Cloud virtual machines.

1. Record metadata: instance or VM ID, type, private and public IP, VPC or VNet and subnet, region, image ID, security groups, attached identity (instance profile, managed identity, service account) and launch time.
2. Protect from deletion: on AWS enable termination protection, change shutdown behaviour from terminate to stop, and disable Delete on Termination on attached EBS volumes. Apply a tag such as Status=Quarantine, which can also trigger automated acquisition. On Azure and Google Cloud, apply resource locks or remove the instance from autoscaling and managed instance groups.
3. Snapshot the disks: EBS snapshots, Azure managed disk snapshots of OS and data disks, or Compute Engine persistent disk snapshots (which can be taken while the disk is attached to a running instance). Ephemeral OS disks in Azure and instance store volumes in AWS cannot be snapshotted, so they need live response.
4. Capture memory where it matters: snapshots only hold data written to disk. Running processes, injected code, decrypted keys and network connections exist only in memory. Capture before isolation or shutdown, because both destroy volatile state. See the Memory Forensics Guide.
5. Live response only when needed: collecting triage artefacts from a running system changes it. Use it when disk or memory cannot be acquired another way, and log every command.
6. Decommission and isolate: detach from autoscaling and load balancers, replace the instance profile or managed identity with one that has no permissions, and apply a deny-all security group or network rule.
7. Shut down or keep observing: shutting down after acquisition is the standard choice. If you must observe the attacker, AWS recommends creating an image and relaunching it in an isolated, instrumented forensics account with VPC Flow Logs or Traffic Mirroring.

Chain of custody in the cloud

Microsoft's Azure Architecture Center publishes a reference design for chain of custody of VM evidence that is a useful model on any platform. Its main elements:

• Separate evidence boundary: a SOC subscription (or AWS forensics account, or Google Cloud forensics project) that only the security team can access, with RBAC changes limited to two named custodians.
• Automated acquisition by a workload identity: a runbook (Copy-VmDigitalEvidence) on a dedicated hybrid runbook worker uses a system-assigned managed identity to snapshot OS and data disks. The identity holds only what it needs, including Contributor on the target resource group so it can create snapshots. Treat this identity as a highly privileged NHI.
• Immutable storage: snapshots are copied into blob storage with a legal hold, a write-once, read-many state in which they cannot be deleted. AWS S3 Object Lock and Google Cloud bucket locks serve the same purpose.
• Hashes recorded separately: hash values (the design supports MD5, SHA-256, SKEIN and KECCAK) are calculated on a temporary copy and stored as secrets in a SOC key vault, away from the evidence itself.
• Controlled analyst access: investigators receive read-only SAS URIs that expire after eight hours, from allow-listed IP addresses, and each use can be logged.
• Same region: all components stay in the region of the investigated systems.

Microsoft also notes the design should be validated with your legal department before it is relied on for legal purposes. Whatever platform you use, record who triggered each acquisition, when, which API calls were made and the resulting hashes. The provider's own control plane log of your snapshot calls becomes part of the evidence record.

Investigating identity and NHI activity

In most cloud incidents the question is not "what ran on this host" but "what did this identity do, and where did its credential come from". Start from the identity, then expand to every resource it touched.

• Trace credential origin: a key used from an unfamiliar IP often traces back to a CI system, a developer laptop or a leaked repository. Correlate first use with code commits, pipeline runs and secret scanner alerts. See the Cloud Access Key Leak Playbook.
• Watch instance metadata abuse: credentials taken from a VM's metadata service (ATT&CK T1552.005) appear in logs as the instance's own role or managed identity, used from somewhere other than the instance.
• Map the blast radius from permissions: enumerate everything the compromised identity could reach, not only what logs show it touched, because data-plane gaps hide reads.
• Preserve the identity state: before deleting a malicious app registration or key, export its configuration, credentials list, owners and consent grants. Deletion destroys evidence.

See the Identity Incident Response Playbook and the Azure RBAC and Service Principals Guide.

Building the timeline

1. Export first: pull every log still inside retention to the forensics account before analysis, starting with the shortest-lived sources (Entra Free sign-ins, CloudTrail event history, _Default bucket).
2. Normalise time: all three providers log in UTC; keep it that way and record clock sources for VM artefacts.
3. Anchor on identity: use access key IDs, application IDs, object IDs and service account emails as pivot keys across control plane, data plane and host evidence.
4. Layer host evidence: add file system timelines and memory findings from snapshots, plus flow logs. See the Network Forensics Guide.
5. Mark gaps explicitly: a missing data event is "not logged", not "did not happen". Record this in the report.
6. Scope and validate: estimate affected resources, accounts and data, then test each conclusion against a second source.

Automated cloud forensics: decisions and trade-offs

• Manual vs automated acquisition: manual console steps are fine for a small estate with rare incidents. Above a few accounts or subscriptions, automate: a quarantine tag or alert triggers snapshot, copy to the forensics account, hash and isolation. Automation is faster than autoscaling and removes operator error.
• Native vs third-party tooling: native APIs (snapshots, Run Command, Systems Manager) avoid extra agents but differ per cloud. Commercial and open source cloud forensic platforms unify collection across providers; evaluate how they authenticate, because their collector identities need broad read and snapshot rights. See the Digital Forensics Tools Buyer's Guide.
• Cost of logging vs cost of not knowing: data events and Data Access logs are expensive at volume. Enable them selectively with advanced event selectors or per-service configuration on buckets and tables holding regulated or sensitive data, rather than everywhere or nowhere.
• Small vs large organisations: a small team should prioritise an organisation-wide trail, Entra P1 or log export, and a written snapshot procedure. A large enterprise should add a forensics account per region, pre-approved automation identities, immutable evidence stores and regular drills.

Detection and measurement

Forensic readiness is measurable before any incident happens.

• Log coverage: percentage of accounts, subscriptions and projects sending control plane logs to central storage with retention of at least 12 months.
• Data-plane coverage: percentage of buckets, tables and vaults classified as sensitive with data access logging enabled.
• Time to preserve: minutes from quarantine decision to verified snapshot in the forensics account; measure in drills.
• Logging tamper alerts: alerts on StopLogging, trail deletion, diagnostic setting removal and sink changes, with zero unacknowledged.
• Identity attribution rate: share of workload credentials (keys, service principals, service accounts) with a known owner and purpose, which determines how fast you can tell malicious use from normal.

Framework mapping

Common failure patterns

• Running on default retention: an Entra ID Free tenant discovers a compromise on day 10 and has no sign-in history left. Upgrading the licence afterwards does not bring the data back.
• Assuming reads are logged: teams state "no evidence of data access" when data events or Data Access logs were never enabled. The honest finding is that access could not be determined.
• Isolating before acquiring: applying a deny-all rule or stopping the VM first destroys memory, and autoscaling may replace the instance and delete its disk.
• Deleting the attacker's foothold too early: removing a rogue app registration, key or role without exporting its configuration loses the evidence of when and how it was created.
• Trusting host logs alone: in the Storm-2949 Azure attack the actor cleared event logs and command history on VMs, while its listkeys calls, Key Vault secret reads and Run Command use were visible in the Azure control plane. Central, provider-side logs are what survive.
• Evidence stored where the attacker can reach it: snapshots kept in the compromised account can be deleted or shared out by the same stolen credentials. Copy to a separate forensics account with immutability.

Practitioner checklist

• Document default and configured retention for every log source in each cloud, and extend anything below 12 months for control plane logs.
• Enable an organisation-wide CloudTrail trail, Entra and Azure diagnostic settings, and Cloud Logging sinks to a central, access-restricted store.
• Enable data-plane logging for sensitive buckets, tables, vaults and storage accounts.
• Create a forensics account, subscription or project per region with immutable storage and a small set of named custodians.
• Pre-build and test acquisition automation: protect, snapshot, copy, hash, isolate, in that order.
• Decide in advance which workloads need memory capture and which tool you will use.
• Alert on logging changes: trail stops, diagnostic setting deletion, sink and exclusion changes.
• Keep an inventory of workload identities with owners so malicious use stands out.
• Agree evidence handling, data residency and legal hold rules with counsel before an incident.
• Run a cloud forensic drill at least annually and measure time to preserve.

Standards and references

• NIST: NISTIR 8006 NIST Cloud Computing Forensic Science Challenges
• AWS: Security Incident Response User Guide, Collect relevant artifacts
• AWS: Working with CloudTrail event history
• Microsoft: Computer forensics chain of custody in Azure
• Microsoft: Microsoft Entra data retention
• Google Cloud: Cloud Audit Logs overview
• Google Cloud: Cloud Logging quotas and limits
• MITRE ATT&CK: Disable or Modify Cloud Log

Related NHI Mgmt Group resources: Cloud Incident Response Guide · Digital Forensics (DFIR) Guide · Incident Response Guide · Cloud Workload Identity Guide · Data Exfiltration Guide