Chapter 31: Cloud Forensics — Investigating Data That Lives on Someone Else's Servers

Where you are: Part V, Chapter 31 of 40. Chapter 29 taught you to break (or fail to break) into encrypted volumes you physically hold; Chapter 30 taught you to detect the traces left by someone trying to erase their tracks. This chapter dissolves the comforting assumption underneath both: that the evidence is on a device in your hands at all. More and more of the data that matters never touches a disk you can seize. It lives in a data center you will never enter, on hardware you do not own, under the control of a company that is not a party to your case. This is the home chapter for the cloud extension of anchor case #2 — the departing engineer — who, in this telling, does not reach for a thumb drive. They reach for a browser tab.

Learning paths: This chapter splits four ways. 🛡️ Incident Response lives in the IaaS/PaaS sections — CloudTrail, Azure Sign-in logs, snapshotting a compromised EC2 instance, business-email-compromise hunting. 📜 Legal/eDiscovery practitioners get the legal-process and jurisdiction sections — preservation letters, the Stored Communications Act, the CLOUD Act, Microsoft 365 eDiscovery, Google Vault — which are the difference between wanting cloud evidence and lawfully obtaining it. 🔍 Forensic Examiners own the endpoint-sync and browser-artifact sections, where the cloud touches the ground and leaves something you can image. 💾 Data Recovery technicians get the least here, but learn a genuinely useful trick: the local sync cache is sometimes the only surviving copy of a file the cloud has already purged.

The evidence you cannot seize

Return to the engineer from Chapter 16. In that telling, they copied proprietary CAD files to a SanDisk thumb drive, and the Windows registry, ShellBags, LNK files, and a self-incriminating CCleaner prefetch convicted them. That case is a decade out of date. The modern engineer does not own a thumb drive. They open a browser, drag four .sldprt files into the personal OneDrive tab they keep signed in next to the corporate one, create a "anyone with the link" share, paste the link into a personal Gmail draft, and close the laptop. No removable device was ever connected. No file was ever written to a location the corporate USB-blocking policy could see. By every artifact you learned to read in Part III, nothing happened.

Something did happen. It happened in three places at once, and your job in this chapter is to learn all three. A residue landed on the endpoint — OneDrive's own logs recorded the upload, the browser cached the session, the operating system noted the process. A record was created at the provider — Microsoft's audit log captured a FileUploaded and an AnonymousLinkCreated event with a timestamp and an IP address. And the data itself came to rest in a data center in a region you would have to subpoena Microsoft to even identify. Three sources, three completely different acquisition methods, three different bodies of law. That is cloud forensics: not one technique but a coordinated assault on a problem whose defining feature is that you do not have the disk.

Everything you have learned so far assumed possession. The first theme of this book — deleted is not destroyed; the pointer is removed, the data persists until overwritten — assumed you controlled the medium where that data persisted. The second theme — the original is sacred; image it, hash it, work the copy — assumed there was an original you could attach a write-blocker to. In the cloud, both assumptions fail. You cannot write-block Amazon. You cannot hash "the original" Salesforce. The data persists or is purged according to a retention policy you did not set and cannot inspect, on storage that is replicated across continents for the provider's convenience, not yours. The fourth theme is the one that survives intact and becomes your lifeline: technology changes, principles don't. You still understand the system, acquire the evidence, analyze it systematically, document everything, and report accurately. Only the meaning of "acquire" has changed beyond recognition.

Why This Matters. A large and growing share of the evidence in modern investigations has no on-premises copy at all. Corporate email is Microsoft 365 or Google Workspace. Files are OneDrive, Drive, Dropbox, Box. Chat is Slack and Teams. Customer records are Salesforce. The company's servers are EC2 instances and Azure VMs. When counsel says "preserve everything," more than half of "everything" is sitting on someone else's hardware, governed by someone else's terms of service, expiring on someone else's schedule. An examiner who can only work a seized laptop is, in 2026, an examiner who can recover a fraction of the case.

Three places the cloud leaves evidence

Hold this map in your head for the whole chapter. Every cloud investigation draws from some combination of these three reservoirs, and the skill is knowing which one can answer your specific question — and which one you are allowed to reach.

WHERE CLOUD EVIDENCE LIVES  (and how you get it)
┌──────────────────────────────────────────────────────────────────────────┐
│ 1. ON THE ENDPOINT          The cloud's footprint on a device you CAN image │
│    • sync-client databases  (OneDrive .dat/.odl, Drive metadata_sqlite_db, │
│      Dropbox .dbx, cached file content)                                     │
│    • browser artifacts      (history, cookies/OAuth tokens, cache, IndexedDB│
│      and Service Worker caches of web apps like Gmail/Outlook web)         │
│    ► ACQUIRE: ordinary forensic imaging (Part III) — it's a local disk.     │
├──────────────────────────────────────────────────────────────────────────┤
│ 2. AT THE PROVIDER, VIA YOUR TENANT   Logs/exports YOU are entitled to       │
│    • M365 Unified Audit Log, eDiscovery; Google Vault + Reports API;        │
│      AWS CloudTrail; Azure/Entra logs; Slack/Salesforce audit + export APIs │
│    ► ACQUIRE: admin credentials + API/portal. NO third party needed —       │
│      you (or your client) already control this tenant.                      │
├──────────────────────────────────────────────────────────────────────────┤
│ 3. AT THE PROVIDER, NOT YOURS   Data in an account you do NOT control        │
│    • a suspect's personal Gmail; a third party's Dropbox; content the       │
│      provider holds that your tenant cannot see                            │
│    ► ACQUIRE: LEGAL PROCESS ONLY — preservation letter, subpoena, court     │
│      order, or warrant served on the provider. This is where law leads.    │
└──────────────────────────────────────────────────────────────────────────┘

The dividing line between reservoir 2 and reservoir 3 is the single most important distinction in this chapter, and new examiners blur it constantly. If your client owns the tenant — it is their Microsoft 365 organization, their AWS account, their Slack Enterprise Grid — then the audit logs and the content are theirs to collect, and you collect them with administrative access, no subpoena required. If the data lives in an account your client does not own — a suspect's personal cloud, a customer's separate tenant — then you cannot touch it without legal process served on the provider, and trying to do so may be a crime in itself. Reservoir 2 is an engineering problem. Reservoir 3 is a legal one. Confusing them gets evidence suppressed and examiners sued.

The shared-responsibility model: who holds the evidence

Before you can collect cloud evidence you must know who controls the layer it lives in. Cloud providers publish a shared-responsibility model that divides operational responsibility between the provider and the customer. It was written to clarify who patches what, but it doubles as a forensic map: the layers the customer controls are the layers the customer can collect from; the layers the provider controls are the layers you must request from the provider. The model shifts dramatically depending on the service type.

SHARED RESPONSIBILITY  →  WHAT YOU CAN ACQUIRE
                  On-prem      IaaS          PaaS          SaaS
                  (you own)    (EC2, VM)     (App Service) (M365, SFDC)
  ┌────────────┬────────────┬────────────┬────────────┬────────────┐
  │ Data       │  CUSTOMER  │  CUSTOMER  │  CUSTOMER  │  CUSTOMER  │ ← always yours
  │ App        │  CUSTOMER  │  CUSTOMER  │  CUSTOMER  │  provider  │
  │ Runtime    │  CUSTOMER  │  CUSTOMER  │  provider  │  provider  │
  │ OS         │  CUSTOMER  │  CUSTOMER  │  provider  │  provider  │
  │ Hypervisor │  CUSTOMER  │  provider  │  provider  │  provider  │
  │ Hardware   │  CUSTOMER  │  provider  │  provider  │  provider  │
  │ Network/DC │  CUSTOMER  │  provider  │  provider  │  provider  │
  └────────────┴────────────┴────────────┴────────────┴────────────┘
   IMAGEABLE:   whole stack   the VM disk   app data +   logs &
                              (snapshot)    logs only    exports ONLY

Read the table left to right and watch your forensic reach shrink. On-premises, you own the whole stack and Part III applies unchanged: pull the drive, write-block it, image it. IaaS (Infrastructure as a Service — a raw virtual machine like an AWS EC2 instance or an Azure VM) hands you the operating system and up, which means you can snapshot the virtual disk and acquire a genuine forensic image of everything from the boot sector to user files — but the hypervisor, the physical host, and the data-center network belong to the provider, and you will never image those. PaaS (Platform as a Service — a managed runtime like Azure App Service or AWS Lambda) takes the OS away too; you get the application and its data and whatever the platform chooses to log, and nothing beneath. SaaS (Software as a Service — Microsoft 365, Salesforce, Slack) takes everything but the data and the configuration. You cannot image Salesforce. There is no disk to image; there is no operating system you are permitted to touch. There are only the logs the provider exposes and the data you can export through sanctioned channels.

Limitation. The shared-responsibility model is also a limitation model, and you should internalize it as one now, before the dedicated Limitations section. The deeper a service sits in SaaS, the less you can image and the more you depend on the provider having logged what you need, retained it long enough, and exposed it through an API. If Microsoft did not log it, or logged it and rotated it out of retention, that evidence is gone, and no amount of skill recovers it. In SaaS forensics your investigation is bounded not by your technique but by the provider's telemetry.

This is what practitioners mean when they call cloud forensics log-centric. On a seized laptop, the disk is the evidence and logs are a supplement. In the cloud — especially in SaaS and PaaS, where there is no disk you can reach — logs are frequently the entire case. Acquisition shifts from "image the medium" to "collect, parse, and correlate logs from multiple providers, each in its own format, each with its own retention clock ticking." The examiner's reflex becomes: what is logging here, where does it go, and how long does it last? — asked the moment you are engaged, because the answer changes by the hour.

Where the cloud touches the ground: endpoint sync artifacts

Begin where you are strongest. Almost every cloud-storage service offers a desktop sync client — OneDrive, Google Drive for Desktop, Dropbox, Box Drive — and the moment a user installs one, the cloud acquires a footprint on a disk you can image with everything you learned in Part III. The sync client must, by its nature, keep a local record of what it is syncing: a database of file names, sizes, cloud identifiers, timestamps, sync state, and frequently the cached file content itself. That local record is ordinary forensic gold. It survives in your .E01 image. It is subject to no provider's retention policy. And it often describes files that exist only in the cloud and have never been fully downloaded — proving they were there even when you cannot reach them.

OneDrive: the sync database and the ODL logs

OneDrive is the richest endpoint cloud artifact on Windows because it is built into the operating system and logs aggressively. Two reservoirs matter: the sync databases and the ODL activity logs, both under the user's local profile.

ONEDRIVE ARTIFACTS  (per user)
C:\Users\<user>\AppData\Local\Microsoft\OneDrive\
  ├── settings\
  │     ├── Personal\        ┐
  │     └── Business1\       ┘ one folder per linked account
  │           ├── global.ini            ← maps account → "cid" (account ID)
  │           ├── <cid>.dat             ← the SYNC DATABASE (proprietary binary)
  │           ├── <cid>.dat.previous    ← prior generation — a second snapshot!
  │           ├── ClientPolicy*.ini     ← tenant name, quota, library URLs
  │           └── <cid>.ini
  └── logs\
        └── Business1\
              ├── *.odl  *.odlgz  *.odlsent   ← per-operation ACTIVITY LOGS
              ├── *.aold
              └── general.keystore             ← key to de-obfuscate the logs

Registry (per user):
  HKCU\Software\Microsoft\OneDrive\Accounts\Business1\
      UserEmail, UserName, cid, SPOResourceId
      Tenants\<TenantName>\   → synced library URLs + local mount points
      ScopeIdToMountPointPathCache

The <cid>.dat file is OneDrive's sync database — a proprietary binary format, not SQLite, that records every item the client is tracking: file and folder names, the cloud resource IDs, sizes, hashes, the local path, and crucially a sync/availability state flag that tells you whether the file is downloaded locally, "cloud-only" (a placeholder you can see but not open offline), or in some intermediate state. You do not parse it by hand; you use OneDriveExplorer (Brian Maloney's open-source tool), which reconstructs the entire synced folder tree from the .dat and renders it as a browsable hierarchy and a CSV. The .dat.previous file is a gift the documentation never advertises: it is the prior generation of the same database, so between .dat and .dat.previous you frequently get two points in time and can see what changed — files that appeared, files that vanished from sync.

OneDriveExplorer.py -f "Business1\<cid>.dat" --csv .\out

Type    Name                              Size       Status        Path
folder  ProjectArchive                    -          -            /
folder  TurbineHousing                    -          -            /ProjectArchive
file    TurbineHousing_v7.sldprt          1,990,656  cloud-only   /ProjectArchive/TurbineHousing
file    BearingAssembly_rev3.sldprt         842,128  available    /ProjectArchive/TurbineHousing
file    NOTES_takehome.txt                    4,210  available    /ProjectArchive

Read that output the way it will read in a report. The client was syncing a ProjectArchive/TurbineHousing tree; TurbineHousing_v7.sldprt shows status cloud-only, meaning the metadata is on this machine but the bytes live in the cloud — proof the file existed in this account's OneDrive even though it was never fully downloaded to this disk. That single status flag answers a question seizure alone cannot: a file you cannot find in the file system was nonetheless present in the user's cloud storage.

The ODL files (.odl, .odlgz, .odlsent) are OneDrive's own verbose activity logs, and they are extraordinary because they record individual operations — file uploaded, file downloaded, file renamed, file deleted, link created — with timestamps and the function names of the code that ran. Recent OneDrive versions obfuscate the strings in these logs using a general.keystore, which is why you parse them with odl.py (Yogesh Khatri's research tool) that knows how to de-obfuscate against the keystore. The .odlgz variants are simply gzip-compressed older logs — a .odlgz file begins with the standard gzip magic, which you will recognize instantly:

Offset    00 01 02 03 04 05 06 07     meaning
00000000  1F 8B 08 00 00 00 00 00     1F 8B = gzip; 08 = DEFLATE; (mtime, flags)
          └gzip┘

Recovery vs. Forensics. The OneDrive sync database serves both disciplines from the same bytes. For the 🔍 forensic examiner, a cloud-only entry proves a file existed in the user's cloud account — an element of an exfiltration or possession claim — even though the file was never on the local disk. For the 💾 data recovery technician, the very same database, read against a content cache, is a map to surviving copies: when a client's cloud subscription lapsed and the provider purged the files, but the laptop still holds the locally-cached versions of the "available" items, the sync database tells you exactly which files you can still pull out of the local cache and which are gone for good. One reads it to prove what was there; the other to restore what remains.

Google Drive for Desktop: metadata_sqlite_db and the content cache

Google's desktop client (Drive for Desktop, formerly Backup and Sync / Drive File Stream) keeps its state in a SQLite database and a chunked content cache, both under the local profile:

C:\Users\<user>\AppData\Local\Google\DriveFS\
  └── <numeric_account_id>\
        ├── metadata_sqlite_db   ← SQLite: the file/folder metadata catalog
        ├── content_cache\       ← cached file CONTENT (chunked: chunk_*, etc.)
        └── mirror_sqlite_db     ← (if mirroring folders) mirror state

The metadata_sqlite_db is a standard SQLite database, so it begins with the unmistakable 16-byte SQLite signature — a magic number you will meet over and over in cloud forensics, because nearly every sync client, browser, and chat app stores its state in SQLite:

Offset    00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F   ASCII
00000000  53 51 4C 69 74 65 20 66  6F 72 6D 61 74 20 33 00   SQLite format 3.
          └──────────── "SQLite format 3\0"  (16-byte magic) ───────────┘
00000010  10 00 01 01 00 40 20 20  ...                        ..... 
          └ page size = 0x1000 = 4096 bytes (big-endian, offset 16) ┘

Because it is SQLite, you query it directly with the sqlite3 CLI (or any parser) — against a working copy extracted from your image, never the original:

# Work on an EXTRACTED copy; hash it into your chain of custody first.
sha256sum metadata_sqlite_db >> coc.txt

# DriveFS schema varies by version; the items + properties pattern is stable.
sqlite3 metadata_sqlite_db \
  "SELECT i.stable_id, i.trashed, p.value
     FROM items i JOIN item_properties p ON i.stable_id = p.item_stable_id
    WHERE p.key IN ('local_title','content-md5','modified_date');"

The database holds, per item, the Google cloud ID, the file's title, its size, an MD5 checksum of the content, modified/viewed timestamps, and a trashed flag — meaning Drive records deleted files in the same catalog (theme #1: deleted is not destroyed; here the "pointer" is just a flag). The content_cache\ directory holds cached chunks of file content. Those chunks have no helpful names and no file extensions, but they are the literal bytes of files the user opened — which means they are carvable (Chapter 7): run them through a signature carver and a chunk that begins FF D8 FF is a JPEG, one that begins 25 50 44 46 (%PDF) is a PDF, one that begins 50 4B 03 04 is an Office/ZIP container. The cache is, in effect, a pile of headerless files waiting for the carving skills you already have.

Dropbox: SQLite that grew teeth

Dropbox stores its state under both local and roaming app-data folders, and its history is a useful lesson in how cloud clients harden over time:

C:\Users\<user>\AppData\Local\Dropbox\    and    ...\AppData\Roaming\Dropbox\
  ├── info.json          ← PLAINTEXT: account type + local Dropbox path  (reliable)
  ├── host.db / host.dbx ← base64-encoded host id + path
  └── instance1\ , instance_db\
        ├── config.dbx     ┐  SQLite databases — but in modern Dropbox these are
        ├── filecache.dbx  ┘  ENCRYPTED (SQLCipher), key protected by Windows DPAPI
        └── deleted.dbx

Two facts matter. First, info.json is plaintext and reliable: it names the account type (personal/business) and the local Dropbox path, which is the fastest way to confirm a Dropbox account was configured and where it synced. Second, the .dbx databases — config.dbx, filecache.dbx, deleted.dbx — were once plain SQLite you could open and read directly; modern Dropbox encrypts them with SQLCipher, using a key derived through the Windows DPAPI (Data Protection API) and tied to the user's logon credentials. That means on a dead-box image you generally cannot read them without the user's DPAPI master key (recoverable if you have their password or a live, logged-in context). This is the encrypted-device problem of Chapter 29 reappearing inside a cloud artifact — and it is exactly the kind of thing you note honestly in a report rather than pretend you can decrypt. The filecache.dbx, when you can read it, catalogs the synced files; deleted.dbx is precisely what its name says.

Tool Tip. Do not hand-parse these formats when validated tools exist and will be expected under Daubert. OneDriveExplorer and odl.py for OneDrive; the SQLite CLI or DriveFS parsers for Google; established suites (Magnet AXIOM Cloud, Cellebrite, X-Ways) wrap many of them. But always confirm what the tool actually parsed, and corroborate a load-bearing finding (e.g., "this file was cloud-only in the user's OneDrive") with a second source — the ODL logs, the provider audit log, the browser history — exactly as Chapter 16 taught. One artifact is a lead; three that agree is a finding. The full tool landscape is surveyed in Chapter 36 — The Forensic Toolkit, and the artifact paths in this section are collected in Appendix D — Forensic Artifact Locations.

Browser artifacts: the webmail and web-app trail

Many cloud services have no sync client at all. The user reaches them entirely through a browser — webmail (Gmail, Outlook web), web file storage, SaaS consoles, the personal-cloud tab next to the corporate one. When that is the access path, the evidence lands in the browser's profile, which is Chapter 18's domain in depth. Here we look at it specifically through the cloud lens, because a handful of browser artifacts are decisive for cloud cases.

The Chrome/Edge profile (Edge is Chromium, so the layout is identical under Microsoft\Edge\User Data\) holds these cloud-relevant stores:

C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Default\
  ├── History               ← SQLite: urls, visits, downloads
  ├── Network\Cookies        ← SQLite: cookies (VALUES encrypted, see below)
  ├── Cache\Cache_Data\      ← cached responses (data_#, f_######) — carvable
  ├── Local Storage\leveldb\ ← LevelDB: web-app local state (*.ldb, *.log)
  ├── IndexedDB\<origin>\    ← LevelDB + .blob: offline app data (e.g., webmail)
  └── Service Worker\CacheStorage\  ← offline-app cached pages/assets

The History database (SQLite) records every visit to drive.google.com, outlook.office.com, dropbox.com, mail.google.com, with timestamps and visit counts — the bare fact that the user reached a cloud service, and when. The download records show files pulled from the cloud to this machine. But the two richest and most sensitive cloud artifacts in the browser are the cookies and the web-app caches.

The cookie store contains the user's authenticated session and OAuth tokens for cloud services — the bearer tokens and refresh tokens that prove the browser was logged in to a specific account. Chromium encrypts cookie values with AES-256-GCM using a key stored in the Local State file (the os_crypt.encrypted_key field), which is itself DPAPI-protected — the same Chapter 29 pattern. Decrypted, these tokens identify which accounts the user was signed into, including the personal accounts logged in alongside corporate ones. This is potent evidence and a potent hazard, which is why it earns the ethics note below.

The IndexedDB, Local Storage, and Service Worker CacheStorage folders are where web apps stash data for offline use — and "offline use" can mean cached email bodies, cached document contents, cached chat history. Gmail's and Outlook-web's offline modes, for example, persist message content into IndexedDB. These stores use Google's LevelDB format (files named *.ldb and *.log, with a CURRENT and MANIFEST-*), which you parse with a LevelDB reader rather than SQLite. The forensic payoff is large: even when you have no lawful access to the live mailbox in the cloud, the browser's local cache of it may sit, fully readable, inside your image.

Ethics Note. Browser cloud artifacts hand you the keys to a person's entire digital life — live session tokens that could, technically, let you walk straight into their personal email or cloud storage. Do not. Your authority is defined by the warrant or engagement that put the image in front of you (the deep treatment is Chapter 25 — The Legal Framework), and a personal account that is out of scope stays out of scope no matter how easy the token makes it. Reading an extracted OAuth token to document "this browser was authenticated to account X at time Y" is analysis. Replaying that token to log into account X is unauthorized access — likely a violation of the Computer Fraud and Abuse Act and a fast route off the witness stand. The sixth theme — the human cost is real — is never closer than when a single cached token exposes someone's whole private existence. Scope discipline is not bureaucracy; it is the line between an examiner and an intruder.

Recovery vs. Forensics. The browser cache cuts both ways here too. For 🔍 the examiner, an IndexedDB cache of webmail is evidence content obtainable without touching the live mailbox. For 💾 recovery, that same cache is sometimes the only surviving copy of a message or document a user lost when their cloud account was closed, compromised, or wiped — you carve the cached body out of LevelDB and hand back what the cloud no longer holds.

API-based collection: pulling evidence from the provider

When the evidence lives in a cloud tenant your client controls (reservoir 2), you do not seize it — you collect it through the provider's administrative and eDiscovery interfaces. This is a fundamentally different motion from imaging a disk, and it has its own chain-of-custody discipline: you are pulling records across a network from a system you do not control, so you must document what query you ran, against which tenant, with which credentials, at what time, and what the provider returned — and you hash the exported result the instant it lands.

Microsoft 365: the Unified Audit Log, eDiscovery, and Entra logs

Microsoft 365 (Exchange Online, SharePoint, OneDrive for Business, Teams) is the most common corporate SaaS, and its forensic backbone is the Unified Audit Log (UAL) — a tenant-wide record of operations across all the workloads, searchable in the Microsoft Purview compliance portal or, far more usefully for an examiner, through Exchange Online PowerShell:

# Connect with an account that has the View-Only Audit Logs / eDiscovery role.
Connect-ExchangeOnline -UserPrincipalName investigator@contoso.com

# Pull file and sharing operations for one custodian over a date range.
Search-UnifiedAuditLog -StartDate "06/01/2026" -EndDate "06/28/2026" `
    -UserIds "j.rivera@contoso.com" `
    -Operations FileDownloaded,FileUploaded,FileSyncDownloadedFull,`
                AnonymousLinkCreated,SharingInvitationCreated,FileDeleted `
    -ResultSize 5000 |
  Select-Object CreationDate, UserIds, Operations, AuditData |
  Export-Csv .\ual_rivera.csv -NoTypeInformation

# Each row's AuditData is a JSON blob with the full event detail:
#   { "CreationTime":"2026-06-15T18:51:07", "Operation":"AnonymousLinkCreated",
#     "UserId":"j.rivera@contoso.com", "ClientIP":"203.0.113.47",
#     "ObjectId":"https://contoso-my.sharepoint.com/.../TurbineHousing_v7.sldprt",
#     "SourceFileName":"TurbineHousing_v7.sldprt" }

The operations you most often hunt for: FileDownloaded and FileSyncDownloadedFull (bulk pulls), FileUploaded, AnonymousLinkCreated and SharingInvitationCreated (the "share it out" smoking gun in IP-theft cases), FileDeleted, MailItemsAccessed (was a mailbox read — central to business-email-compromise cases), New-InboxRule (an attacker auto-forwarding mail), Add-MailboxPermission, and UserLoggedIn/UserLoginFailed. Each AuditData JSON carries the timestamp, the actor, the client IP address, and the object acted upon.

PowerShell is the right tool to export the UAL, but the embedded AuditData JSON is awkward to analyze in a spreadsheet — so examiners typically flatten it in Python (the book's primary scripting language) to extract the fields that build a timeline. This is illustrative reference code; run it against your hashed export, never a live system:

# Flatten an exported Unified Audit Log CSV into timeline rows.
# Each 'AuditData' cell is a JSON string; pull the fields that matter.
import csv, json

KEEP = {"FileUploaded", "FileDownloaded", "AnonymousLinkCreated",
        "SharingInvitationCreated", "FileDeleted"}

with open("ual_rivera.csv", newline="", encoding="utf-8-sig") as fh:
    for row in csv.DictReader(fh):
        ad = json.loads(row["AuditData"])          # the nested JSON blob
        if ad.get("Operation") not in KEEP:
            continue
        print("{time}  {op:<24}  {ip:<15}  {obj}".format(
            time=ad.get("CreationTime"),           # UTC ISO-8601
            op=ad.get("Operation"),
            ip=ad.get("ClientIP", "-"),
            obj=ad.get("SourceFileName") or ad.get("ObjectId", "")))
# 2026-06-15T18:51:07  AnonymousLinkCreated      203.0.113.47     TurbineHousing_v7.sldprt

Two hard caveats define what the UAL can do. First, retention: the UAL is searchable for roughly 180 days on standard (E3) licensing and one year on E5, extendable to ten years only with an add-on. Beyond the window, the events are simply gone. Second, it must have been enabled — auditing has shipped on-by-default for new tenants for several years, but older or reconfigured tenants may have had it off, in which case there is no retroactive log to search. Both facts make the very first action in any M365 case a race against the retention clock, addressed under "Common mistakes."

For content — the actual emails, documents, Teams messages, not just the metadata of operations — Microsoft 365 provides eDiscovery (Content Search and eDiscovery Premium). You place custodians on legal hold (which freezes their content against deletion and retention expiry), search across mailboxes, SharePoint, OneDrive, and Teams, and export the results as PST/EML plus metadata. Hold is the cloud analogue of the second theme — the original is sacred — implemented as policy rather than a write-blocker: you cannot physically prevent Microsoft from rotating data, so you invoke the legal mechanism that obliges them not to.

Identity is its own log surface. Entra ID (formerly Azure AD) sign-in and audit logs record authentications, MFA results, the source IP and geolocation, the device, and risk signals — the heart of any account-compromise investigation. The default retention is short (about 30 days), so mature organizations stream these to Log Analytics or a SIEM for longer. Programmatically you reach them through the Microsoft Graph API:

# Entra sign-in logs via Microsoft Graph (illustrative; bearer token required).
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/auditLogs/signIns?\$filter=userPrincipalName eq 'j.rivera@contoso.com'&\$top=50"
# Returns JSON: createdDateTime, ipAddress, location, clientAppUsed,
#               deviceDetail, status (success/failure + failure reason).

Google Workspace: Vault and the Reports API

Google Workspace mirrors the pattern with different names. Google Vault is the eDiscovery service — holds, searches, and exports for Gmail, Drive, Chat, Meet recordings, and Groups, producing PST/mbox plus an XML metadata sidecar. For activity logs, the Admin console audit logs (and the underlying Admin SDK Reports API) record events across applications: the Drive audit log (view, download, edit, create, trash, and the all-important change_user_access and change_document_visibility events that capture sharing changes), the Login audit log, the Token audit log (third-party OAuth grants — how data leaves via connected apps), and the Admin audit log.

# Admin SDK Reports API — Drive downloads for a user (conceptual REST shape).
GET https://admin.googleapis.com/admin/reports/v1/activity/users/\
j.rivera@example.com/applications/drive?eventName=download&\
startTime=2026-06-01T00:00:00Z
# Each item: id.time, actor.email, ipAddress, events[].name,
#            events[].parameters (doc_id, doc_title, visibility, target_user).

The Drive audit log in the admin console is typically retained for six months; for longer history, organizations export it to BigQuery. As with the UAL, the retention window is the binding constraint, and the change_document_visibility event — the moment a private file became "anyone with the link" — is the event that wins exfiltration cases.

Chain of Custody. API collection needs the same rigor as imaging, expressed differently. Record the exact query (cmdlet or API call with parameters), the tenant/organization identifier, the authenticated principal and its role, the collection timestamp in UTC, and the tool and version. The instant the export lands, hash it (sha256sum export.pst) and log the hash. A defensible note reads: "Ran Search-UnifiedAuditLog (ExchangeOnlineManagement v3.x) against tenant contoso.onmicrosoft.com as investigator@contoso.com (eDiscovery Manager role), 2026-06-28 14:02 UTC, date range 2026-06-01..2026-06-28; exported 1,284 records to ual_rivera.csv, SHA-256 4f2a…." Now the cloud-collected evidence is as traceable as a disk image. The chain-of-custody fundamentals are in Chapter 5 — The Forensic Process; templates are in Appendix F.

SaaS forensics: Slack, Teams, and Salesforce

Beyond storage and email, organizations run on SaaS applications whose entire state lives in the vendor's cloud — and each exposes its own audit and export surface. The shared-responsibility model says it plainly: you will never image these. You collect logs and sanctioned exports, or you get nothing.

Slack keeps two relevant surfaces, gated by license tier. The Audit Logs API (available on Enterprise Grid) records administrative and security events — user_login, file_downloaded, message_deleted (recorded as a tombstone), channel_created, public_channel_exported, permission changes — as JSON, queryable at api.slack.com/audit/v1/logs with the auditlogs:read scope. For message content, Slack offers exports (standard workspaces can export public-channel history as per-channel, per-day JSON) and, on Enterprise Grid, the Discovery API for eDiscovery-grade content collection including private channels and DMs — which is governed and typically requires legal or executive authorization. A vital theme-#1 nuance: a Slack message a user "deleted" frequently persists in the compliance/Discovery export, because retention is set at the workspace level, not by the user — deletion removed their view, not the record.

Microsoft Teams has no separate evidence store at all; it is a front-end over the rest of Microsoft 365. Teams chat messages are written into hidden folders of the participants' Exchange Online mailboxes (a TeamsMessagesData substructure); files shared in a channel live in the team's SharePoint site; files shared in a 1:1 chat live in the sender's OneDrive. Therefore you investigate Teams through the UAL (operations like MessageSent, MessagesListed, ChatRetrieved) and through M365 eDiscovery, which has a dedicated Teams collection path. There is no "Teams image"; there is the M365 telemetry you already know.

Salesforce holds the customer's most sensitive business records and exposes several audit layers. The Setup Audit Trail logs configuration and administrative changes (who changed a permission, exported a report setting, altered a sharing rule) and retains roughly 180 days, exportable to CSV. Real user-activity monitoring requires the Shield Event Monitoring add-on, which surfaces Login, ReportExport, URI (page views), API, and content-download events as EventLogFile records pulled through the REST or Bulk API as CSV. Field Audit Trail and field history track changes to record data over time. The recurring exfiltration question in a Salesforce case — did a departing salesperson export the customer list? — is answered by the ReportExport and Bulk-API events in Event Monitoring, if the organization licensed Shield before the fact. Without Shield, that telemetry was never generated, and the honest answer is that it cannot be reconstructed.

Limitation. Notice the pattern across all three: the evidence you can collect was determined before your investigation began, by which licenses the organization bought and which logging it enabled. Slack audit logs require Enterprise Grid; Salesforce user activity requires Shield; the M365 UAL requires auditing to have been on. You arrive after the fact and inherit whatever telemetry already existed. A core professional skill in SaaS forensics is therefore assessing logging posture early and telling the client, plainly, what their configuration will and will not let you prove. This is theme #5 — know your limitations — built into the architecture of the cloud itself.

IaaS and PaaS forensics: control-plane logs and volume snapshots

When the cloud asset is infrastructure — a virtual machine, a managed database, a serverless function — the investigation gains a dimension that on-premises work lacks: a clean separation between the control plane and the data plane. The control plane is the cloud's management layer: the API calls that create, modify, and destroy resources (launch this VM, snapshot that disk, open this firewall, delete that log). The data plane is what happens inside the resources: the processes on the VM, the rows in the database, the bytes in the object store. They are logged by entirely different systems, and a competent IaaS investigation reads both.

CONTROL PLANE  vs  DATA PLANE   (IaaS)
┌───────────────────────────────────────────────────────────────────────┐
│ CONTROL PLANE  — "what was done to the cloud account"                   │
│   AWS: CloudTrail        (RunInstances, CreateSnapshot, DeleteTrail…)   │
│   Azure: Activity Log + Entra Sign-in/Audit                            │
│   GCP: Cloud Audit Logs  (Admin Activity, Data Access, System Event)    │
│   ► answers: who created/deleted/changed resources, from where, when    │
├───────────────────────────────────────────────────────────────────────┤
│ DATA PLANE     — "what happened inside the resource"                    │
│   the VM's own disk + memory (acquire by SNAPSHOT + image, see below)   │
│   app/OS logs, VPC Flow Logs, S3 access logs, DB query logs            │
│   ► answers: what ran on the host, what data was touched                │
└───────────────────────────────────────────────────────────────────────┘

The cloud audit logs

AWS CloudTrail records management-plane API calls account-wide as JSON. A single record is dense with investigative value:

{
  "eventTime": "2026-06-15T03:42:11Z",
  "eventSource": "ec2.amazonaws.com",
  "eventName": "CreateSnapshot",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "203.0.113.47",
  "userAgent": "aws-cli/2.15.0 Python/3.11",
  "userIdentity": {
    "type": "IAMUser",
    "userName": "svc-backup",
    "accessKeyId": "AKIAEXAMPLE12345"
  },
  "requestParameters": { "volumeId": "vol-0a1b2c3d4e5f6a7b8" },
  "responseElements": { "snapshotId": "snap-0f1e2d3c4b5a69788" }
}

CloudTrail "Event history" is searchable for the last 90 days for free; to keep events longer (and to capture more than the management plane) you configure a Trail that delivers records to an S3 bucket indefinitely. Data events — object-level S3 access (GetObject, PutObject), Lambda invocations — are not logged by default and must be explicitly enabled, which is why "did the attacker read the bucket?" so often has no answer. Crucially, the actions an attacker takes to blind you are themselves CloudTrail events: StopLogging, DeleteTrail, and PutEventSelectors (narrowing what gets logged) all appear in the log right up until the moment logging stops — the third theme in cloud form: every action leaves a trace, and the absence of a trace (the log that suddenly stops) is itself a trace.

The equivalents: Azure splits this into the Activity Log (subscription-level control-plane operations) plus Entra sign-in/audit logs for identity, with Microsoft Defender for Cloud and Microsoft Sentinel for analytics and longer retention. Google Cloud provides Cloud Audit Logs in three streams — Admin Activity (always on, control-plane changes), Data Access (off by default, like AWS data events), and System Event — exported to Cloud Logging and onward to BigQuery for retention. The names differ; the model — a control-plane log that is on by default, a data-plane log that is not, and a retention clock you must beat — is identical across all three. Technology changes, principles don't.

Acquiring a cloud volume: the snapshot workflow

When you must examine the inside of an IaaS host — a compromised EC2 instance, a VM that staged stolen data — you cannot pull a drive. You take a snapshot of the virtual disk and image that. The principle is unchanged from Part III: capture a point-in-time copy, work from the copy, hash everything. The mechanics are cloud-native, and the order of volatility from Chapter 15 — Live Response and Triage still rules: memory first, because it dies at power-off; disk second, because the snapshot is durable.

# --- AWS EBS forensic acquisition (illustrative) ---

# 0. ISOLATE first: move the instance to a restrictive security group so it
#    cannot phone home or be tampered with, but DON'T stop it yet.
aws ec2 modify-instance-attribute --instance-id i-0abc... \
    --groups sg-forensic-isolation

# 1. VOLATILE: capture RAM from the live instance BEFORE stopping it.
#    (Linux example, on the instance, writing OFF-host to mounted evidence vol.)
sudo avml /evidence/i-0abc_mem.lime

# 2. Snapshot the EBS volume (point-in-time, crash-consistent).
aws ec2 create-snapshot --volume-id vol-0a1b2c3d \
    --description "IR-2026-014 forensic snapshot of i-0abc" \
    --tag-specifications 'ResourceType=snapshot,Tags=[{Key=case,Value=IR-2026-014}]'

# 3. In an ISOLATED forensic account/VPC, create a volume from the snapshot,
#    attach it to a hardened forensic instance, and image the raw device.
aws ec2 create-volume --snapshot-id snap-0f1e2d3c --availability-zone us-east-1a
#    ... attach as /dev/xvdf to the forensic instance, then:
sudo dc3dd if=/dev/xvdf hof=/evidence/i-0abc_disk.raw \
    hash=sha256 log=/evidence/i-0abc_disk.log
sha256sum /evidence/i-0abc_disk.raw >> /evidence/coc.txt

The Azure path is the same shape — az snapshot create from the managed disk, then az snapshot grant-access to obtain a time-limited SAS URL you use to download the VHD; GCP uses gcloud compute disks snapshot. In every case you analyze in an isolated account or subscription so a compromised resource cannot contaminate your environment, and you treat the downloaded image exactly as you would a dd of a physical disk: it is now an ordinary forensic image, and every technique in Parts II and III applies to it.

War Story. A small SaaS company was hit with ransomware that, unusually, also reached into their AWS account using a stolen access key and ran DeleteSnapshot against every backup snapshot before encrypting the production volumes — a deliberate move to foreclose the recovery path that anchor case #3 (the ransomware recovery, Chapter 12) is built around. The responders' first instinct was despair: the backups were gone. Their second, correct instinct was to open CloudTrail, where every one of those DeleteSnapshot calls sat logged with a timestamp, the accessKeyId used, and the sourceIPAddress — and, two events earlier, the CreateSnapshot the attacker had made of one volume to exfiltrate it. The control-plane log did not save the snapshots, but it reconstructed the entire attack and, because one cross-region snapshot copy lived in an account the attacker's key could not reach, it identified the single surviving recovery point. The attacker erased the data; they could not erase the record of erasing it.

The legal process: getting data the provider holds

Everything above assumed reservoir 1 (you have the endpoint) or reservoir 2 (your client owns the tenant). When the data sits in an account your client does not control — a suspect's personal cloud, a third party's mailbox, content the provider holds beyond your tenant's reach — engineering stops and law begins. You cannot log into someone else's account, and you cannot ask the provider nicely. You compel disclosure through legal process, and in the United States the governing statute is the Stored Communications Act (SCA), Title II of the Electronic Communications Privacy Act, 18 U.S.C. §§ 2701–2712. The deep treatment belongs to Chapter 25 — The Legal Framework and Appendix E — Legal Frameworks Reference; here is the operational shape every cloud examiner must know.

The SCA sets a tiered standard — the more sensitive the data, the higher the legal bar:

SCA TIERS  (18 U.S.C. § 2703)  — what process compels what data
┌──────────────────────────┬──────────────────────────────────────────────┐
│ SUBPOENA                  │ Basic subscriber info — name, address, billing,│
│ (§ 2703(c)(2))            │ session/login records, IP logs, length of      │
│                           │ service. The "who is this account" tier.       │
├──────────────────────────┼──────────────────────────────────────────────┤
│ 2703(d) COURT ORDER       │ Non-content transactional records — metadata,  │
│ (specific & articulable   │ logs, to/from headers, connection records.     │
│  facts)                   │ More than a subpoena, less than a warrant.     │
├──────────────────────────┼──────────────────────────────────────────────┤
│ SEARCH WARRANT            │ CONTENT — the emails, files, photos, messages  │
│ (probable cause)          │ themselves. Post-Carpenter & DOJ policy:       │
│                           │ stored content generally requires a warrant.   │
└──────────────────────────┴──────────────────────────────────────────────┘

Before any of that, the single most important action — and the most time-sensitive — is the preservation request under 18 U.S.C. § 2703(f). A § 2703(f) letter compels the provider to preserve the existing contents of an account for 90 days (renewable for another 90) while you obtain the warrant or order to actually get it. It does not give you the data; it stops the clock. Because cloud logs rotate and users delete, preservation is the cloud equivalent of putting a guard on a crime scene, and it goes out the first day — before the subpoena, before the warrant — or the evidence may simply age out while the paperwork is drafted.

Two practical nuances trip up newcomers. First, providers run law-enforcement portals (Google's LERS, Microsoft, Meta, Apple) with published guidelines specifying exactly how to serve process and what each tier returns; transparency reports tell you what the provider holds and for how long. Use the guidelines — malformed process is rejected and wastes the preservation window. Second, and critically for the many readers doing civil work (eDiscovery, internal investigations): the SCA generally bars providers from disclosing the content of communications to civil litigants at all, even under a Rule 45 subpoena. In civil matters you do not get a suspect's Gmail content from Google; you get it from the party — through discovery obligations, a litigation hold, and the custodian's own production. This is why corporate eDiscovery leans so hard on reservoir 2 (the company's own tenant) and on compelling individuals to produce their accounts, rather than serving providers. Knowing which door is even legally open is half of cloud-evidence work.

Legal Note. The cloud also runs straight into mandatory reporting. Under 18 U.S.C. § 2258A, electronic service providers that detect apparent child sexual abuse material — typically via automated hash-matching such as PhotoDNA — must report it to the NCMEC CyberTipline, and must preserve the associated content (90 days, extended to one year by the REPORT Act of 2024) pending legal process. Many cloud-origin cases under anchor #4 begin exactly this way: a provider's report, then a warrant for the account, then a forensic examination of what is returned. Your handling of such material stays clinical and non-graphic — procedure, law, and ethics only — and your own mandatory-reporting duties, scope discipline, and well-being are treated fully in Chapter 28 — Ethics. The point here is narrow: in the cloud, the provider is often the first reporter, and legal process is the only lawful path to the content.

The jurisdictional challenge: where IS the data?

A physical drive has a location. You can point at it. Cloud data has, at best, a policy about location, and frequently no single location at all — it is sharded, replicated, and cached across multiple data centers in multiple countries for durability and speed. "Where is the file?" can be a genuinely unanswerable question, and the law has spent a decade struggling with the consequences.

The landmark fight was Microsoft v. United States — the "Microsoft Ireland" case. U.S. law enforcement served an SCA warrant for emails Microsoft stored in a Dublin data center; Microsoft refused, arguing a U.S. warrant could not reach data on foreign soil. The case reached the Supreme Court in 2018 and was rendered moot mid-stream by Congress passing the CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018), which amended the SCA to say plainly that a U.S. provider must produce data within its "possession, custody, or control" regardless of where the data is physically stored. The location of the bytes stopped being the question; the nationality and control of the provider became the question.

That resolved one tension and created another. A U.S. warrant can now reach a U.S. provider's data wherever it sits — but that data may be subject to foreign law that forbids the disclosure. The European Union's GDPR, for instance, restricts transfers of personal data in response to foreign court orders (Article 48), so a U.S. provider can find itself ordered by a U.S. court to produce what EU law forbids it to hand over. The CLOUD Act's answer is a framework for executive agreements between countries (the U.S.-U.K. Data Access Agreement was the first) that let each side's lawful orders reach the other's providers directly. Where no such agreement exists, cross-border requests fall back to the slow, traditional channel: a Mutual Legal Assistance Treaty (MLAT) request, which routes through diplomatic and judicial bureaucracy and can take many months — sometimes longer than the data's retention period, which is its own quiet tragedy.

WHOSE LAW REACHES THE DATA?
   Data physically in:        Provider is:        Likely reachable by:
   ─────────────────────────────────────────────────────────────────────
   USA                        US company          US warrant (SCA)
   Ireland (EU)               US company          US warrant via CLOUD Act
                                                   — but GDPR Art. 48 tension
   Germany (EU)               EU company          EU process; US needs MLAT
                                                   or an executive agreement
   Anywhere                   foreign company,    MLAT / diplomatic — slow,
                              no US presence       may outlast retention

For the working examiner, jurisdiction is not abstract. It dictates whether you can get the data at all, how long it will take, and whether the way you got it will survive a challenge. Data-residency commitments (a provider's promise to keep a customer's data in, say, the EU) determine which legal regime applies. The practical discipline is to establish, early, three facts for every cloud source: who the provider is and where it is incorporated, where the data is contractually resident, and what legal instrument can lawfully reach it. Get those wrong and you may spend months on an MLAT for data a CLOUD Act request would have produced in weeks — or, worse, obtain data by a route a court later rules unlawful, losing the evidence and possibly more. The full legal machinery lives in Chapter 25; your job in the field is to recognize the jurisdictional question the moment a case crosses a border, and to bring counsel in before, not after, you act.

Worked example: the engineer who reached for a browser tab

Assemble the cloud version of anchor case #2. The same firm, the same departing engineer (j.rivera@contoso.com), the same proprietary turbine-housing CAD files — but this time the corporate USB policy blocked removable storage, so there is no thumb drive to find. Counsel's question is unchanged: did this employee exfiltrate trade secrets before resigning? The firm owns the Microsoft 365 tenant (reservoir 2) and you have a forensic image of the workstation (reservoir 1). You work all three sources you can lawfully reach, building one timeline.

1 — The endpoint: was personal cloud storage in use? (OneDrive artifacts, browser). On the workstation image, the registry shows two OneDrive accounts under HKCU\Software\Microsoft\OneDrive\Accounts\ — Business1 (corporate) and Personal (a consumer Microsoft account, j.rivera.personal@outlook.com). OneDriveExplorer against the Personal <cid>.dat reconstructs a synced tree containing ProjectArchive\TurbineHousing\ with the four .sldprt files marked cloud-only — present in the personal account, never fully downloaded back to this disk. Browser history confirms repeated visits to onedrive.live.com and a personal Gmail.

2 — The endpoint: when did the upload happen? (OneDrive ODL logs). odl.py against the Personal ODL logs (de-obfuscated with the general.keystore) shows upload operations for the four files clustered Friday 18:44–18:51, naming each file and recording the local source path C:\Work\TurbineHousing\. The kernel-set $FILE_NAME MFT timestamps on those local source files (the truthful clock from Chapter 30 — Anti-Forensics and Chapter 16) corroborate creation that same afternoon.

3 — The tenant: did the corporate side see anything? (M365 UAL). Search-UnifiedAuditLog over the corporate tenant returns, for j.rivera@contoso.com, a burst of FileDownloaded events from the corporate SharePoint TurbineHousing library Friday 18:39–18:43 — pulled down from corporate storage minutes before the personal-OneDrive upload at 18:44. The AuditData JSON gives client IP 203.0.113.47 for each.

4 — The tenant: was anything shared out? (UAL sharing operations). The same UAL search surfaces an AnonymousLinkCreated event for TurbineHousing_v7.sldprt at 18:51 — but note carefully: this is on the corporate file, indicating the engineer also created an anyone-with-the-link share on the corporate copy, a second exfiltration path. The personal-account uploads themselves are not in the corporate UAL (different tenant) and would require legal process to obtain from Microsoft for the personal account — a reservoir-3 problem you flag for counsel rather than reach for yourself.

5 — Correlate the IP and the identity (Entra sign-in logs). Entra sign-in logs via Graph place j.rivera@contoso.com authenticating from 203.0.113.47 (geolocated to the engineer's home city) across the relevant window — binding the corporate downloads and the share-link creation to the engineer's authenticated session, not merely to "someone."

Assembled, sourced line by line:

CLOUD-EXFIL TIMELINE (UTC) — j.rivera, anchor case #2 (browser-tab variant)
Fri 18:35  Sign-in to corporate M365 from 203.0.113.47 (home city)   [Entra sign-in log]
Fri 18:39  FileDownloaded ×4 from SharePoint TurbineHousing library   [M365 UAL]
Fri 18:44  Upload of 4 .sldprt to PERSONAL OneDrive begins            [endpoint ODL log]
Fri 18:51  Personal-OneDrive sync completes (files now "cloud-only")  [endpoint <cid>.dat]
Fri 18:51  AnonymousLinkCreated on corporate TurbineHousing_v7        [M365 UAL]
(personal-account content itself: requires SCA process to Microsoft)  [reservoir 3 — flag]

Every line is sourced to a cloud artifact, every tenant-side artifact is hashed at export, every endpoint artifact comes from the verified image — and the reservoir-3 gap (the personal account's contents) is named as a gap, with the lawful path to close it identified rather than crossed. That is a cloud examination: corroborated across endpoint, tenant logs, and identity, honest about the boundary where your authority ends and a warrant must begin.

Ethics Note. You found that the engineer's personal OneDrive holds the files. The temptation — the personal account's session cookie may even be cached in the browser — is to "just confirm" by logging in. That is the line from the earlier ethics note made concrete: confirming via an out-of-scope personal account is unauthorized access, full stop. You report what the in-scope evidence shows ("four files were uploaded from this workstation to a personal OneDrive account at 18:44–18:51, and the same files were shared anonymously from corporate storage at 18:51"), and you hand counsel the legal mechanism (SCA process to Microsoft) to reach the rest. Findings and the methods to extend them stay rigorously separate, exactly as Chapter 26 — The Forensic Report requires.

Common mistakes

• Not sending the preservation letter on day one. Cloud logs rotate and users delete. A § 2703(f) preservation request (for third-party data) or a legal hold (for your own tenant) freezes the evidence while process is obtained. Wait a week and the M365 sign-in logs (≈30 days), the Drive audit log (≈180 days), or the CloudTrail event history (90 days) may already be eroding. Preservation is the first action, not a later step.
• Confusing "our tenant" with "their account." Collecting your client's own M365 or AWS with admin access is an engineering task; reaching a suspect's personal cloud is a legal one requiring process served on the provider. Treating reservoir 3 like reservoir 2 — logging into someone else's account because a cached token made it easy — is unauthorized access and can be a crime.
• Assuming the log exists. The UAL must have been enabled; Salesforce user activity needs Shield; Slack audit logs need Enterprise Grid; AWS/GCP data-plane logging is off by default. Absence of a log is not evidence of absence of activity — it may mean the telemetry was never generated. Verify logging posture before you promise an answer.
• Reading provider timestamps without their timezone and meaning. UAL CreationTime, CloudTrail eventTime, and Google id.time are UTC; SharePoint and some exports localize. And MailItemsAccessed means a mailbox sync occurred, not that a human read a specific message. State what each event actually proves, as you would for any artifact.
• Snapshotting a cloud VM and forgetting volatility. A disk snapshot is durable, so examiners reach for it first — but RAM still dies at power-off. Capture instance memory before you stop the instance; order of volatility (Chapter 15) did not stop applying just because the host is virtual.
• Trusting the local cache as the whole story. A sync client's database and content cache reflect what that endpoint synced, which may be a subset of the cloud account (cloud-only placeholders, selective sync). "It's not in the cache" does not mean "it's not in the cloud."
• Treating "deleted" cloud data as gone. Version history, trash/recycle with retention, soft-delete windows, and compliance exports routinely retain what a user "deleted." A deleted Slack message persists in the Discovery export; a trashed Drive file persists with a trashed flag. Theme #1 holds in the cloud — check the retained copies before concluding the data is unrecoverable.
• Ignoring jurisdiction until it bites. Discovering mid-investigation that the data is EU-resident and your only route is a multi-month MLAT — after the retention window — is an avoidable failure. Establish provider, residency, and lawful instrument the moment a case touches the cloud, and bring counsel in early.

Limitations: knowing when to stop

Cloud forensics is bounded more tightly than any discipline in this book, and the boundaries are not set by your skill — they are set by the provider, the license, the retention clock, and the law. A professional report states them as plainly as its findings.

The first and hardest limit is you cannot image SaaS. There is no disk, no memory, no file system you are permitted to touch — only the logs and exports the provider chooses to expose. If Microsoft, Google, Salesforce, or Slack did not log an event, it did not happen as far as your evidence is concerned, and no technique reconstructs it. Your reach is exactly the provider's telemetry, no further.

The second limit is retention. Every cloud log has a clock: Entra sign-ins around 30 days, the M365 UAL 180 days to a year, Google's Drive audit log about 180 days, CloudTrail event history 90 days, Salesforce Setup Audit Trail 180 days. Past the window, the records are deleted by policy and are unrecoverable — which is why preservation is the first action and why a case that comes to you six months late may have already lost its decisive evidence to ordinary log rotation.

The third limit is default-off logging. AWS and GCP data-plane events, M365 auditing on older tenants, Salesforce Event Monitoring without Shield — these generate nothing unless someone turned them on before the activity occurred. You inherit the past's configuration choices and cannot retroactively create telemetry.

The fourth limit is encryption and key control. Dropbox's SQLCipher .dbx files, DPAPI-protected browser cookies, provider-side encryption where the customer never held the keys — each can leave you with data you can see but not read, the Chapter 29 problem transplanted into the cloud. When the keys are genuinely beyond reach, the honest finding is that the content is inaccessible.

The fifth limit is jurisdiction. Data you could technically read may be legally unreachable, or reachable only through an MLAT that outlasts the data's retention. "The data is EU-resident and no lawful U.S. process can compel it within its retention period" is a real, defensible conclusion.

Across all five, the fifth theme governs: know your limitations. "The available cloud telemetry is insufficient to determine whether X occurred, because auditing was not enabled / the retention window had elapsed / the account is outside the scope of lawful process" is not a failure. It is a complete, professional finding, and it is infinitely better than forcing a conclusion the logs cannot support — which, in the cloud as on a disk, is how examiners are unmade on cross-examination.

Progressive project: add the cloud-evidence layer to your case file

Continue building your Forensic Case File (introduced in Chapter 5 — The Forensic Process). Your case now extends into the cloud, and this chapter adds the third reservoir to the endpoint evidence you collected in Part III.

1. Map the three reservoirs for your case. List every cloud source implicated: which endpoints carry sync clients or webmail (reservoir 1), which tenants your subject organization controls (reservoir 2), and which accounts belong to third parties (reservoir 3). For each, write down the lawful collection method. This map is itself a case-file document.
2. Collect the endpoint cloud artifacts from your verified image: the OneDrive <cid>.dat/.dat.previous and ODL logs, any Google metadata_sqlite_db and content cache, Dropbox info.json/.dbx, and the browser history/cookies/IndexedDB for cloud services. Parse with OneDriveExplorer, odl.py, the SQLite CLI, and a LevelDB reader. Hash every extracted file into your chain-of-custody worksheet (Appendix F).
3. Collect the tenant telemetry you are authorized to reach: run a Search-UnifiedAuditLog (or the Google Reports API, or a CloudTrail query) for your custodian and date range, export it, and hash the export immediately. Record the exact query, principal, role, and UTC timestamp.
4. Draft the preservation/legal step for reservoir 3. For any third-party account, write the § 2703(f) preservation request (or, in a civil matter, the litigation-hold/production approach) you would send — and note the provider's law-enforcement-portal requirements and the retention window you are racing.
5. Add a cloud timeline to the case file, every entry sourced to a specific cloud artifact (endpoint, tenant log, or identity log), and explicitly mark every reservoir-3 gap with the lawful instrument needed to close it. You will merge this into the master timeline in Chapter 21 — Timeline Analysis and fold it into the final report in Chapter 26; the capstone in Chapter 38 assembles everything.

Save your parsed outputs, exports, hashes, and the cloud timeline into the case-file folder. The discipline that matters most here is the one this chapter exists to teach: keep the reservoirs — and the legal authority that governs each — rigorously separate.

Summary

This chapter dissolved the assumption beneath everything before it: that the evidence is on a device in your hands. In the cloud it usually is not, and you learned to find it in three reservoirs instead. The first is the cloud's footprint on the endpoint — a disk you can image — where sync clients leave rich, retention-proof artifacts: OneDrive's <cid>.dat sync database (parsed with OneDriveExplorer, with cloud-only flags that prove a file lived in the cloud without ever fully downloading) and its de-obfuscated ODL operation logs; Google Drive's metadata_sqlite_db and carvable content_cache; Dropbox's plaintext info.json and its SQLCipher-encrypted .dbx; and the browser's history, OAuth-bearing cookies, and IndexedDB/Service-Worker caches of web apps. The second reservoir is the provider, via a tenant your client controls, collected not by imaging but through APIs and eDiscovery: the Microsoft 365 Unified Audit Log and eDiscovery, Entra sign-in logs via Graph, Google Vault and the Reports API, AWS CloudTrail, Azure Activity and GCP Cloud Audit Logs, and the SaaS audit/export surfaces of Slack, Teams (which lives inside M365), and Salesforce — every one of them log-centric and governed by a retention clock you must beat. The third reservoir is the provider, in an account you do not control, reachable only through legal process: preservation letters under § 2703(f), then subpoena, 2703(d) order, or warrant under the Stored Communications Act, mediated by provider law-enforcement portals — and constrained by jurisdiction, where the CLOUD Act, GDPR Article 48, executive agreements, and the slow MLAT decide whether you can lawfully reach data whose physical location may be genuinely unknowable. Underlying all three you learned the shared-responsibility model as a forensic map (the deeper into SaaS, the less you can image and the more you depend on the provider's telemetry) and the control-plane/data-plane split that lets CloudTrail reconstruct an attack even when the attacker deletes the backups — because every action leaves a trace, and a log that suddenly stops is itself a trace. The medium changed beyond recognition; the method did not. Understand the system, acquire what you are lawfully able to acquire, analyze and correlate across sources, document every query and hash every export, and report findings — and the boundaries of those findings — with rigorous honesty.

You can now: - Locate, extract, and parse endpoint cloud-sync artifacts — OneDrive <cid>.dat/ODL logs, Google metadata_sqlite_db and content cache, Dropbox info.json/.dbx — and read browser history, cookies, and web-app caches for cloud activity. - Collect tenant-side cloud evidence through provider APIs and eDiscovery — the M365 Unified Audit Log, Entra sign-in logs, Google Vault/Reports API, AWS CloudTrail, Azure/GCP audit logs, and Slack/Salesforce audit surfaces — with proper chain of custody for exports. - Acquire an IaaS host forensically: capture instance memory first, snapshot the volume, image it in an isolated account, and distinguish control-plane from data-plane logs. - Choose the correct legal instrument for provider-held data — preservation letter, subpoena, 2703(d) order, or warrant under the SCA — and recognize the civil-vs-criminal disclosure distinction. - Reason about jurisdiction — the CLOUD Act, data residency, GDPR Article 48, and MLAT — and identify when data is legally or practically unreachable. - Apply the shared-responsibility model as a forensic map, run a log-centric cloud investigation, and state cloud-specific limitations (retention, default-off logging, no-image SaaS, jurisdiction) honestly in a report.

What's next. Chapter 32 — Malware Forensics — turns from where the data lives to what the adversary ran: you will analyze malicious code post-incident — static and dynamic triage, persistence and the artifacts it leaves, and how the memory and cloud-log skills from the last two chapters combine to reconstruct an intrusion — strictly as defensive, investigative analysis, never weaponization.

Practice in exercises.md, test yourself with the quiz, apply it in the case studies, review the key takeaways, and go deeper with further reading.