Chapter 31 — Key Takeaways

The big idea

In the cloud the evidence is not on a device you can seize, so you stop imaging a medium and start collecting from three reservoirs — and the dividing line between two of them is law, not engineering. Evidence lives (1) on the endpoint, as the cloud's footprint on a disk you can image; (2) at the provider, in a tenant your client controls, collected by API and eDiscovery with admin access; and (3) at the provider, in an account your client does not control, reachable only through legal process served on the provider. Reservoir 2 is an engineering problem; reservoir 3 is a legal one, and confusing them gets evidence suppressed and examiners charged. The method you have used all book survives intact — understand the system, acquire what you may lawfully acquire, analyze and correlate across sources, document every query, hash every export, and report findings and their limits honestly. Only the meaning of "acquire" changed, beyond recognition.

The three reservoirs (memorize this map)

Shared responsibility is a forensic map

• The deeper into SaaS, the less you can image and the more you depend on the provider's telemetry. On-prem: image the whole stack. IaaS: snapshot the VM disk. PaaS: app data + logs. SaaS: logs and exports only — there is no disk to image.
• Cloud forensics is therefore log-centric: logs are frequently the entire case. First reflex: what is logging here, where does it go, and how long does it last?

Endpoint artifacts: where the cloud touches the ground

• OneDrive <cid>.dat (parse with OneDriveExplorer; a cloud-only flag proves a file existed in the user's cloud without ever fully downloading) and de-obfuscated ODL operation logs; .dat.previous gives a second point in time.
• Google Drive metadata_sqlite_db (SQLite; carries a trashed flag — theme #1) and a carvable content_cache (chunks are headerless files: FF D8 FF JPEG, 25 50 44 46 PDF, 50 4B 03 04 ZIP/Office).
• Dropbox info.json is plaintext; the .dbx files are SQLCipher-encrypted behind DPAPI — the Chapter 29 problem inside a cloud artifact.
• Browser: History, downloads, OAuth-bearing cookies (AES-256-GCM key in Local State, DPAPI-protected), and IndexedDB/Service-Worker caches that can hold webmail bodies offline.

Provider-side collection and the retention clock

Two traps: the log must have been enabled (M365 auditing, Slack Enterprise Grid, Salesforce Shield, AWS/GCP data events are off by default), and the control-plane log is usually on while the data-plane log is not — so "did they read the object?" often has no answer. An attacker's StopLogging/DeleteTrail is itself a logged event: the absence of a trace is a trace.

The law decides what you can reach

• SCA tiers (18 U.S.C. § 2703): subpoena → subscriber info; 2703(d) order → non-content records; warrant → content. A § 2703(f) preservation letter freezes an account for 90 days and goes out day one.
• Civil litigants cannot get content from providers — compel the party/custodian instead.
• Jurisdiction: the CLOUD Act reaches a U.S. provider's data wherever stored, but GDPR Art. 48 can forbid disclosure; executive agreements help, MLAT is slow and may outlast retention.

You can now…

• ☐ Place every cloud source in one of the three reservoirs and choose the lawful acquisition method without blurring engineering and law.
• ☐ Extract and parse endpoint cloud-sync artifacts (OneDrive <cid>.dat/ODL, Google metadata_sqlite_db/content cache, Dropbox, browser caches) and read a cloud-only flag correctly.
• ☐ Collect tenant telemetry (M365 UAL, Entra, Google Vault/Reports, CloudTrail) with a defensible chain of custody — query, principal, role, UTC, hash.
• ☐ Acquire an IaaS host forensically — memory first, then snapshot and image in an isolated account — and separate control-plane from data-plane logs.
• ☐ Pick the right legal instrument (preservation letter, subpoena, 2703(d) order, warrant) and reason about CLOUD Act / GDPR / MLAT jurisdiction.

Looking ahead

Chapter 32 — Malware Forensics. From where the data lives to what the adversary ran: static and dynamic triage, persistence and its artifacts, and how memory and cloud-log skills combine to reconstruct an intrusion — strictly defensive, investigative analysis.

One sentence to carry forward: You cannot write-block Amazon — so in the cloud you collect what the provider logged, prove how you collected it, and say exactly where your authority ends and a warrant must begin.