Affiliate disclosure

Book titles on this page link to Amazon. As an Amazon Associate, DataField.Dev earns from qualifying purchases β€” at no additional cost to you.

Chapter 31 β€” Further Reading

Cloud forensics moves faster than any other corner of this book β€” providers rename services and change retention between editions β€” so anchor yourself to the standards bodies and the tool authors' own research, and treat vendor documentation as the live source of truth for operation names and retention windows.

Foundations (πŸ”¬ deeper / standards & format-level)

  • NIST SP 800-201, NIST Cloud Computing Forensic Reference Architecture (2024), and NISTIR 8006, Cloud Computing Forensic Science Challenges. The standards-body framing of exactly the problems this chapter raises β€” the shared-responsibility-as-forensic-map idea, log-centric acquisition, and the limits of provider telemetry. Cite these when you must justify your method's rigor.
  • Brian Maloney β€” OneDriveExplorer and his OneDrive research (bmaloney.com / GitHub). The byte-level reverse engineering behind the OneDrive <cid>.dat sync database and the cloud-only/available status flags. When you must explain why a parser reported a file as cloud-only, this is the source.
  • Yogesh Khatri β€” Swift Forensics blog and odl.py. The work that decoded OneDrive's ODL activity logs and their general.keystore obfuscation. Pair it with Maloney's tools for the complete endpoint-OneDrive picture.

Approachable explanations (everyone)

  • SANS FOR509, Enterprise Cloud Forensics and Incident Response (course + cloud "Hunt Evil"–style posters). The single best structured on-ramp to M365, Google Workspace, AWS, and Azure investigation; the posters compress the audit-log surfaces onto a page you will keep at your desk.
  • Microsoft Learn β€” "Search the audit log," Search-UnifiedAuditLog reference, "Audited activities," and Microsoft Purview eDiscovery docs. The authoritative, current list of UAL operation names and retention by license. Cite it; never trust a forum post for an operation name.
  • Invictus Incident Response β€” the Microsoft-Extractor-Suite (open-source) and their BEC playbooks. Free PowerShell tooling that pulls the UAL, Entra sign-in logs, and inbox rules the way Case Study 1 does β€” the fastest way to do a tenant collection rather than read about one.
  • πŸ›‘οΈ The DFIR Report (thedfirreport.com) and the AWS Security Incident Response Guide. Real, sourced intrusion write-ups β€” increasingly identity- and cloud-centric β€” plus AWS's own IR playbook for CloudTrail-driven reconstruction and the EBS snapshot workflow.
  • πŸ” Magnet Forensics and Cellebrite cloud-artifact blogs (AXIOM Cloud, etc.). Practitioner walk-throughs of sync-client and browser cloud artifacts, and the validated suites cross-examiners expect under Daubert.
  • πŸ“œ DOJ CCIPS, Searching and Seizing Computers and Obtaining Electronic Evidence (the "SCA manual"), plus the texts of the SCA and CLOUD Act and the opinions in Microsoft v. United States and Carpenter v. United States. The legal spine of reservoir 3 β€” preservation letters, the tiered Β§ 2703 standard, and the jurisdiction fight.

Reference (this book)

Do, don't just read

  • Run a real tenant collection. Spin up a free Microsoft 365 Developer tenant (Appendix J), generate file-share and sign-in events, then pull them with Search-UnifiedAuditLog and the Extractor Suite β€” and hash the export the instant it lands. You do not understand the UAL until you have flattened an AuditData JSON blob into a timeline row yourself.
  • Read a cloud-only flag with your own eyes. Parse your own machine's OneDrive <cid>.dat with OneDriveExplorer and find a file that lives only in the cloud β€” then explain, out loud, exactly what that proves and what it does not.
  • Draft the day-one letter. Using the templates in Appendix F, write a Β§ 2703(f) preservation request for a hypothetical third-party account. Feeling the retention clock once teaches the lesson Case Study 2 paid for.

Next: Chapter 32 β€” Malware Forensics: from where the data lives to what the adversary ran β€” static and dynamic triage, persistence artifacts, and reconstructing an intrusion as defensive analysis.