Listen to this Post
Introduction:
APFS snapshots are point-in-time filesystem records that preserve deleted files, prior versions, and user activity invisible in live macOS systems. When forensic examiners fail to identify and properly handle these snapshots during acquisition, they lose critical evidence that could make or break a case—ranging from deleted incriminating documents to timestamps proving system tampering.
Learning Objectives:
- Identify, list, and mount APFS snapshots using native macOS forensic commands and third-party tools.
- Recover deleted files and prior file versions from snapshots without altering the original evidence.
- Implement a forensic workflow that preserves snapshot data during imaging and acquisition.
You Should Know:
- Locating and Listing APFS Snapshots on a Live or Acquired Mac System
APFS snapshots are stored as hidden filesystem objects. Before any acquisition, you must enumerate them to avoid data loss.
Step‑by‑step guide:
- Boot the target Mac from a forensic boot drive (e.g., Paladin, Recon ITR) or mount the acquired image in read‑only mode.
2. Open Terminal and list all volumes:
`diskutil list`
Identify the APFS container and volume (e.g., `/dev/disk3s1`).
3. List snapshots on a specific volume:
`tmutil listlocalsnapshots /Volumes/MacintoshHD`
Note: `tmutil` works on live systems but may not show all snapshots. For deeper analysis use:
`diskutil apfs listSnapshot /dev/disk3s1`
- For forensic images (E01, DD), use `apfs-fuse` or `sleuthkit` with
fsstat:
`fsstat -f apfs /path/to/image.dd`
Look for snapshot metadata under “Snapshot List”.
Linux/Windows alternative:
On Windows, use `APFS Explorer` (commercial) or `apfs-tools` (Linux). Example Linux enumeration:
`sudo apfs-snapshot list /dev/sda2`
- Mounting APFS Snapshots Safely for Read‑Only Evidence Extraction
Mounting snapshots interactively changes the live system; always mount as read‑only to preserve integrity.
Step‑by‑step guide:
- Identify snapshot UUID from the listing (e.g.,
com.apple.TimeMachine.2025-12-01-143506).
2. Create a mount point:
`sudo mkdir /mnt/snapshot_forensics`
3. Mount snapshot (macOS):
`sudo mount_apfs -o ro -s /dev/disk3s1 /mnt/snapshot_forensics`
If `mount_apfs` is unavailable: Use `apfs-fuse` on Linux:
`apfs-fuse -o ro -s /dev/sda2 /mnt/snapshot`
- Verify mount with `df -h` or
mount | grep snapshot. - Navigate and extract files using `rsync` with preserved metadata:
`rsync -av –dry-run /mnt/snapshot_forensics/ /output/extracted/`
Remove `–dry-run` to execute.
Forensic note: Calculate cryptographic hash of every extracted file and log all mount commands in your case notes.
- Recovering Deleted Files and Prior Versions from Snapshots
Snapshots retain inodes of deleted files. This is where most examiners miss evidence.
Step‑by‑step guide:
- After mounting a snapshot, use `find` to locate inodes that no longer exist in the live filesystem:
`find /mnt/snapshot_forensics -type f -links 0`
These are files deleted in the live FS but still present in the snapshot.
2. For a more systematic recovery, use `sleuthkit` on the snapshot mount point or raw image:
`fls -f apfs -r /dev/disk3s1 | grep -i deleted`
Then extract with `icat`:
`icat -f apfs /dev/disk3s1 > recovered_file`
- To compare snapshot vs. live directory structure and spot user activity:
`diff -rq /Volumes/MacintoshHD/Users/john /mnt/snapshot_forensics/Users/john`
Look for files present only in snapshot (deleted after snapshot was taken).
Windows tool command (using APFS for Windows by Paragon):
`C:\> apfs-snapshot.exe -mount -uuid -letter S:`
Then use `cmd` or `PowerShell` to recover as above.
- Preserving Snapshots During Forensic Imaging (E01, DD, AFF4)
Traditional `dd` or `dcfldd` ignores snapshot metadata unless you image the entire physical disk. However, snapshots exist within the APFS container’s internal copy‑on‑write structures.
Step‑by‑step guide:
- Always image the whole disk (
/dev/rdiskX), not just the volume, to capture the APFS container’s snapshot metadata.
`sudo dcfldd if=/dev/rdisk2 of=/cases/evidence/image.dd hash=sha256 hashlog=/cases/hash.log`
- For live Linux acquisition of a Mac disk, use `dcfldd` or
guymager. Ensure `apfs` kernel module is loaded:
`sudo modprobe apfs`
3. Verify that snapshots appear after imaging:
`fsstat -f apfs /cases/evidence/image.dd | grep -i “Number of snapshots”`
4. If using commercial tools (X-Ways, Axiom, EnCase), enable “acquire APFS snapshots” in the imaging options—many tools default to ignoring them.
Critical mistake to avoid: Never run `tmutil deletelocalsnapshots` or allow macOS to automatically purge snapshots during live acquisition. Boot from write‑blocked media.
5. Automating Snapshot Analysis with Forensic Scripts
Scale your examination by scripting the extraction of all snapshots.
Linux/macOS bash script example:
!/bin/bash
VOLUME="/dev/disk3s1"
OUTPUT="/cases/snapshots"
mkdir -p "$OUTPUT"
diskutil apfs listSnapshot "$VOLUME" | grep -E "^[[:space:]][[:xdigit:]]{8}" | while read UUID; do
echo "Processing snapshot $UUID"
mkdir "$OUTPUT/$UUID"
sudo mount_apfs -o ro -s "$UUID" "$VOLUME" "$OUTPUT/$UUID" && {
find "$OUTPUT/$UUID" -type f -links 0 -exec cp {} "$OUTPUT/$UUID/deleted/" \;
sudo umount "$OUTPUT/$UUID"
}
done
Windows PowerShell (using APFS tools):
$snapshots = & apfs-snapshot.exe -list -volume C:
foreach ($uuid in $snapshots) {
& apfs-snapshot.exe -mount -uuid $uuid -letter X:
& robocopy X:\ C:\snapshot_$uuid\ /MIR /COPY:DAT
& apfs-snapshot.exe -unmount X:
}
6. Mitigating Anti‑Forensic Techniques Targeting Snapshots
Attackers may delete snapshots or corrupt their metadata. Understand how to detect and recover from such tampering.
Step‑by‑step guide:
1. Check for snapshot deletion in system logs:
`log show –predicate ‘process == “apfsd” OR eventMessage contains “snapshot”‘ –last 7d`
Look for `Deleted snapshot` or `apfs_snapshot_delete`.
- If snapshots are missing, search for unallocated APFS container blocks using `apfs-locate` (Linux):
`apfs-locate -s /dev/disk2 -p “SnapshotSuperblock”`
Then carve potential snapshot descriptors with `photorec`.
- On a compromised Mac, check if `tmutil snapshot` was disabled:
`tmutil listbackups` – an empty output after known snapshots existed indicates tampering.
4. Reconstruct deleted snapshot metadata from journal:
`sudo fsstat -f apfs -J /dev/disk3s1`
The APFS journal records snapshot creation/deletion events.
What Undercode Say:
- Key Takeaway 1: APFS snapshots are not optional extras—they are primary sources of deleted file evidence that can refute or confirm user alibis.
- Key Takeaway 2: Traditional imaging workflows that target only the live volume destroy snapshot metadata; always acquire the whole disk and validate snapshot presence with
fsstat.
Analysis: Most Mac forensic failures come not from tool limitations but from procedural ignorance about copy‑on‑write filesystems. When an examiner mounts a live Mac to run dd, they may trigger Time Machine snapshot deletions or filesystem changes that alter the evidence. The shift toward container‑aware acquisition (using tools like `apfs-fuse` or `asr` with snapshot flags) is inevitable. Additionally, as anti‑forensic actors learn to purge snapshots, examiners must layer journal carving and memory analysis to recover erased snapshot references. The days of treating a Mac like a standard x86 computer are over—APFS demands a native approach.
Prediction:
Within three years, forensic tools that fail to enumerate and extract APFS snapshots automatically will be considered legally inadequate. Expect court challenges questioning why snapshots were not preserved, and a rise in certification training specifically focused on APFS internals. Linux‑based forensic distributions will fully integrate `apfs-fuse` and `libapfs` as standard modules, while cloud‑acquired macOS images (from T2/M1/M2 Macs) will require snapshot‑aware workflows due to encrypted volume groups. The future of Mac forensics is snapshot‑first, not snapshot‑last.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Steve Whalen – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
