Case Study 1 — The Snapshot That Outlived the Cleanup

A departing data scientist wiped their Downloads folder, emptied the Trash, cleared their browser history, and stripped the download tags off the files they took — all before handing back a company MacBook. None of it mattered. An hourly APFS snapshot from earlier the same day, a surviving Quarantine database row, and a Linux journal entry rebuilt the exfiltration intact. This is anchor case #2's lesson — anti-forensics rarely beats a thorough examiner — proved on a Mac and a Linux box.

Background

A clinical-AI startup builds diagnostic models on proprietary, hard-won training data. A senior data scientist resigns to join a direct competitor and, per policy, returns a company-issued MacBook Pro and loses access to the Ubuntu GPU training server (train-01, ext4) where the models are built. Two weeks later the competitor demonstrates a strikingly similar model. The startup's general counsel opens an internal investigation under a signed engagement letter that scopes the examination to the aurora project — its training data, model weights, and any exfiltration in the departing employee's final week — and nothing else. You receive both machines.

The MacBook is FileVault-encrypted, but the startup uses mobile-device management (MDM) that escrows the institutional FileVault recovery key, so you have lawful access to decrypt. You image both systems and verify hashes following Chapter 14 — Forensic Acquisition, then analyze the images on your workstation. The question is narrow: did this person take the aurora data, and can you prove it to a standard that survives cross-examination?

The investigation

The live MacBook volume looked clean. The Downloads folder was empty, the Trash was empty, Safari's download history showed nothing for the relevant week, and the aurora working directory under ~/Projects/ was gone. A junior examiner might have written "no evidence found." You started, instead, with the file system itself — because on APFS, "deleted" is rarely the end of the story.

mac_apt reported the APFS container held six local snapshots. Time Machine had been quietly creating them roughly hourly all along. The most useful was com.apple.TimeMachine.2025-03-20-160118.local, captured at 16:01 — well before the 17:40 end-of-day cleanup. Mounted read-only with APFS-Fuse, that snapshot contained both ~/Downloads/cloudsync-pro.dmg and the entire ~/Projects/aurora/ directory — both absent from the live volume. You did not carve anything. You walked into a preserved 16:01 version of the file system and read it like the present, recording the snapshot name and its transaction id for the report.

Now the activity story. The user had cleared Safari's download history and even run xattr -d com.apple.quarantine on the downloaded installer to strip its download tag. But the QuarantineEventsV2 database in the profile still held the row — and a forensic SQLite parser recovered a second, freeblock-resident row the user had "cleared," straight out of the page's unallocated area:

LSQuarantineEvent  (one live row + one recovered from a freeblock; Mac absolute time +978307200)
 dl_time (UTC)        agent   data_url                                   origin_url
 2025-03-20 19:32:08  Safari  https://cloudsync.example/dl/cloudsync.dmg https://cloudsync.example/
 [freeblock] 2025-03-20 19:55:—  Safari  https://paste.example/raw/aurora-keys  (cleared by user)

The knowledgeC.db /app/inFocus stream — converted from Mac absolute time with the chapter's +978307200 — turned the abstract download into human behavior:

knowledgeC /app/inFocus  (America/New_York; train-01 logs are UTC)
 15:18  com.apple.dt.Xcode          (working in the aurora project)
 15:32  com.apple.Safari            (downloaded cloudsync-pro.dmg)
 15:41  com.example.CloudSyncPro    (ran the third-party sync/upload tool, 11 min)
 15:54  com.apple.finder

FSEvents filled the file-system gaps. Its records carry no wall clock — the event IDs are a monotonic counter — so you ordered them by ID and anchored the times against knowledgeC and the gzip files' mtimes: a cloudsync-pro.dmg Created in Downloads, an aurora archive Created, and then, late in the sequence, Users/.../Projects/aurora Removed;IsDir. The Unified Log (collected with both /var/db/diagnostics/ and /var/db/uuidtext/, so every line rendered) showed no USB mass-storage attach at all — consistent with the recovered freeblock Quarantine row pointing at a paste/upload site rather than a thumb drive. This exfiltration went out over the network, not onto a stick.

That pivoted the case to train-01. The MacBook's address (from its network configuration plist and the Unified Log) tied to the source IP in the server's logs. Three independent Linux sources agreed:

train-01 (Ubuntu, ext4) — UTC
 auth.log + wtmp + journal   19:12  SSH publickey login: user 'dsci' from 10.2.7.40
 .zsh_history (extended fmt) 19:14  tar -czf /tmp/aurora-data.tgz /data/aurora/   (: 1742500440:…)
 auth.log (sudo)            19:15  dsci: COMMAND=/usr/bin/rsync /tmp/aurora-data.tgz to remote
 ext4 inode dtime           19:58  /tmp/aurora-data.tgz deleted
 [recovery] ext4magic via jbd2 journal → restored the tarball, 2.4 GB, SHA-256 = H1

The .zsh_history was in zsh's extended format (: <epoch>:<elapsed>;<command>), so unlike a default bash history it carried timestamps. The tarball, rm'd at 19:58, was recovered through the jbd2 journal because the deletion was recent enough that the journal still held the pre-deletion inode with its extents intact. Its SHA-256 matched a residual copy cloudsync-pro had staged on the Mac (recovered from the 16:01 snapshot) — cryptographic proof that the data rsync'd off the server is the same data the upload tool handled on the laptop.

CASE 2025-061 — RECONSTRUCTED EXFILTRATION (all UTC)
 19:12  SSH login dsci@train-01 from MacBook (10.2.7.40)   [auth.log + wtmp + journal]
 19:14  tar of /data/aurora → /tmp/aurora-data.tgz (2.4 GB) [.zsh_history]
 19:15  rsync tarball off the server                        [auth.log sudo]
 19:32  cloudsync-pro.dmg downloaded via Safari             [Quarantine + Spotlight]
 19:41  CloudSyncPro run for 11 minutes                     [knowledgeC]
 19:55  paste/upload of "aurora-keys" (cleared, recovered)  [Quarantine freeblock]
 19:58  server tarball rm'd                                 [ext4 dtime; recovered via journal]
 ~16:01 snapshot still holds Downloads + Projects/aurora    [APFS snapshot — proves prior existence]

Before writing, you validated each load-bearing finding by hand — opening QuarantineEventsV2 yourself in a read-only client to confirm mac_apt's parse, re-decoding wtmp with last -f. And you held to scope: knowledgeC, Spotlight, and the Photos library exposed an intimate portrait of the person's life, almost none of it about aurora, and you queried only the project, the tool, and the relevant window — the Chapter 28 discipline that keeps a finding clean.

The analysis

  1. Check snapshots before you carve. The single biggest macOS rookie error is reconstructing from fragments what a snapshot holds intact. An hourly Time Machine local snapshot captured the volume before the cleanup; enumerating snapshots first turned a "no evidence" laptop into the spine of the case.
  2. Deleted is not destroyed — in databases too. The user cleared the browser and stripped the quarantine xattr, but the QuarantineEventsV2 row survived, and a cleared row came back out of a SQLite freeblock. Erasing the trace left a trace, and the recovered upload URL was decisive.
  3. No single artifact carried the case; their agreement did. Snapshot, Quarantine, knowledgeC, FSEvents, auth.log, wtmp, journal, and a journal-recovered tarball interlocked. Six-plus independent sources telling one story is what survives cross-examination.
  4. The hash match is the kill shot. A 2.4 GB tarball recovered from the server's ext4 journal hashing identically to the data staged on the Mac proves same content regardless of filename — a cryptographic fact, not an inference.
  5. Scope discipline is part of competence, not a constraint on it. Lawful access via the escrowed FileVault key let the work proceed; querying only the in-scope artifacts kept the irrelevant intimate data out of the report and the finding defensible.

Discussion questions

  1. The live volume looked clean and a hasty examiner might have closed the case. List the first three things you would check on any seized Mac before concluding "no evidence found," and say what each could recover.
  2. The user stripped the com.apple.quarantine xattr but the database row survived, and a "cleared" row came back from a freeblock. Explain to a non-technical attorney, in plain language, why deleting these traces is so hard — and why the attempt itself became evidence.
  3. The exfiltration left no USB attach in the Unified Log, unlike the chapter's worked example. Walk through how the artifact mix shifts when data leaves over the network (upload/paste) rather than onto a thumb drive — which artifacts gain importance, which lose it?
  4. ⭐ The decisive correlation was a SHA-256 match between a tarball recovered from the server's ext4 journal and data staged on the Mac. Construct the strongest defense challenge to that match (consider the circular-journal limitation, the institutional key, and chain of custody), then state how clean documentation answers each objection.
  5. The MacBook's knowledgeC and Photos library exposed deeply private, out-of-scope information. State the ethical rule that governed what you queried, name the authority document that defined your scope, and explain the concrete risk — legal and professional — of "just looking" because the tool put it in front of you.