Phone:

Hidden from the page source until you click: friction against scrapers, not a guarantee.

Email:

[email protected]

Digital Forensics Guide

10. macOS

On a modern Mac the unlocked session may be the only chance to obtain decrypted data. This chapter covers the live procedure, what cannot be done on T2 and Apple silicon hardware, APFS structures and the artefacts that matter.

In this chapter

  1. macOS workstations: FileVault and APFS

15. Preservation, acquisition, analysis

macOS workstations: FileVault and APFS

Modern Macs combine FileVault encryption, APFS, a Secure Enclave and, on Apple silicon, a boot process that cannot be bypassed with external media without changing the machine's security policy. The practical consequence is that a powered-on, unlocked Mac is frequently the only opportunity to obtain decrypted data, and that some acquisitions possible on other platforms are not possible here.

Powered on and unlocked

  1. Document the state (section 3) and preserve the session: connect mains, do not close the lid, do not log out or switch user. Isolate physically (section 4); Macs have no hardware wireless switch, so an external adaptor is removed and an internal one is handled by shielding rather than by the menu bar.
  2. Capture volatile evidence where feasible. Software memory acquisition on current macOS is constrained: kernel extensions are restricted, System Integrity Protection prevents loading unsigned ones, and on Apple silicon there is no established general-purpose tool. Do not disable those protections; that is exactly the kind of security change warned against below. Record instead what the running system will tell you with native commands from your own media: date and systemsetup -gettimezone; who and last; ps aux; lsof; netstat -an and ifconfig; mount; diskutil list; diskutil apfs list (containers, volumes, capacity, FileVault and lock state for each volume); fdesetup status; tmutil listlocalsnapshots / and diskutil apfs listSnapshots <volume>. Each is recorded with its output. A sysdiagnose archive captures a great deal of state in one step but has a large footprint and writes to the system volume; use it only by documented decision.
  3. Take a decrypted logical acquisition of the Data volume, and of any other unlocked volume that matters, with an acquisition tool that reads through the mounted filesystem and preserves metadata and extended attributes, or with native tools that do the same (an archive with extended attributes preserved, or a block copy of a disk image created from the volume). Full Disk Access must be granted to the tool, which is a recorded configuration change on the evidence. Record what was included, including whether snapshots were captured.
  4. Acquire physical storage where technically and legally possible. On an Intel Mac, the drive may be removable or reachable through Target Disk Mode, which requires a reboot and, with FileVault, the password; on a T2 or Apple silicon Mac the internal storage is not removable and is encrypted by hardware keys that never leave the machine, so an external physical image is ciphertext that cannot be decrypted elsewhere. The realistic alternatives are a block-level image of the internal disk taken from the live system with root (an image of the encrypted container, useful for structure but not for content), or the decrypted logical acquisition above. State clearly in the record which of these was obtained and why the others were not.
  5. Hash and verify every acquisition (section 9). A logical acquisition of a live filesystem is a derived artefact: hash its container and hash each file within it, since a repeat acquisition will not match at the container level.

Actions that can remove access

  • Rebooting or shutting down locks FileVault; on Apple silicon the Data volume is inaccessible until a user with a secure token authenticates. If the password is not available, everything not acquired from the live session is lost.
  • Changing startup settings (Startup Security Utility, startup disk, boot policy) and altering Secure Boot require entering Recovery, which is a reboot, and may require an administrator password and, on managed devices, MDM approval. Reducing the security policy also changes the evidence and leaves a record.
  • Changing recovery settings, resetting the user's password, adding accounts or changing FileVault users: a password reset can strip the user's secure token and lose the ability to unlock FileVault; an institutional recovery key added after the fact changes the volume metadata.
  • Otherwise disturbing authentication state: signing out of iCloud, turning off Find My, removing the device from MDM, or clearing the Keychain. Each alters evidence and may trigger Activation Lock or remote actions.

Powered off

Leave it off. Identify the model (Intel, T2, Apple silicon), because the acquisition options differ as above. Recovery sources for FileVault are the personal recovery key (shown to the user at enablement, possibly stored in iCloud if they chose escrow), the institutional recovery key held by the organisation, the FileVault recovery key escrowed by MDM (which is the common enterprise route), and the password of any FileVault-enabled user obtained lawfully. With a key or password, the Mac itself is the decryption tool: it must be booted, which is a documented decision, and the logical acquisition is taken from the unlocked system as above. Booting a physical image of a T2 or Apple silicon Mac elsewhere is not possible.

APFS examination

  • Containers and volumes. A container holds several volumes sharing free space: on a modern install a sealed System volume, the Data volume where user content lives, Preboot, Recovery and VM. Examine the Data volume first; the others carry boot and update artefacts.
  • Snapshots. APFS snapshots are read-only images of a volume at a point in time, sharing unchanged blocks with the live volume. Time Machine creates local snapshots on the Data volume (listed with tmutil), updates create snapshots of the System volume, and third-party tools create their own. A file deleted after a snapshot was taken is intact in the snapshot with its metadata; a snapshot is therefore the first place to look for deleted content, and each snapshot is examined as a filesystem in its own right, with its creation time recorded.
  • Clone metadata. Duplicating a file in the Finder or with the copy command's clone option creates a new inode sharing the original's blocks until one is modified. Two files with shared extents are clones; the clone flag and extent references show which was created from which, and a clone's data may survive the deletion of the original.
  • Extended attributes. Listed with xattr -l. The quarantine attribute records the download time and originating application; the "where from" attribute records the download URL; resource forks and Finder information are attributes too; and any attribute can carry arbitrary data (section 17).
  • Filesystem metadata. APFS keeps its structures in checkpoints; earlier checkpoints in the checkpoint area can retain superseded versions of the object map and file records for a short time. Inode records carry creation, modification, change and access times in nanoseconds, plus the "added" time of the directory entry. Toolkit support for APFS varies; use a tool that documents its APFS handling and cross-check with a second.

macOS artefacts

  • Unified Logs: the system-wide log in compressed binary files under the diagnostics and uuidtext directories, covering process activity, authentication, network changes, USB connections and much else, with sub-second timestamps. On the live system log collect gathers them into a logarchive that log show --archive reads later, at the cost of a recorded write to your own media; from an image, copy the diagnostics and uuidtext directories and parse them with a dedicated Unified Log parser. Log retention is limited and rolls quickly on a busy machine.
  • FSEvents: per-volume records of filesystem changes (creations, modifications, renames, deletions by path) in compressed files in the volume's FSEvents directory. They do not carry per-event timestamps but are ordered, and they record activity on files that no longer exist, including on removable volumes.
  • Spotlight metadata: the index on each volume records file names, content-derived metadata and, for many types, timestamps and provenance, and can retain entries for deleted files. Queried on a live system with mdfind and mdls; parsed from the store on an image.
  • Keychain artefacts: the login and system keychains hold passwords, keys and certificates, encrypted with the user's password (login) or a system key (system). With the user's password, lawfully obtained, the login keychain can be opened from a copy; it commonly contains passwords for Wi-Fi networks, websites, encrypted disk images and other volumes.
  • iCloud-related artefacts: the account configuration, the iCloud Drive local cache under the user's Mobile Documents directory, and the CloudDocs database recording sync state and files that exist only in the cloud. Content synchronised elsewhere may have been deleted locally.
  • Application containers: sandboxed applications keep their data under the user's Containers and Group Containers directories rather than in Application Support; messaging, mail and note-taking applications are usually found there.
  • User preference data: property lists under the user's Preferences directory, usually binary, holding recent items, mounted volume history, connected devices and per-application state; read with plutil -p or a plist parser.

Why carving is weaker on APFS and SSDs

Traditional deleted-file carving assumes that a deleted file's blocks remain, unchanged and contiguous, in unallocated space. On a modern Mac several things break that assumption. The storage is an SSD with TRIM enabled, so freed blocks are typically zeroed by the drive soon after deletion. APFS is copy-on-write, so a modified file's new content goes to new blocks while old blocks are released, scattering versions. Snapshots hold references to blocks that would otherwise be free, so "unallocated" depends on which snapshot is considered. And on a FileVault volume the data at rest is ciphertext, so blocks outside any file record cannot be interpreted at all without the volume key context that the live system provides. The practical consequence is that recovery of deleted content on a Mac comes overwhelmingly from snapshots, clones, caches, Spotlight and FSEvents records, cloud copies and Time Machine backups, not from carving. Attempt carving on a decrypted image where the allocation evidence justifies it, and report its limits.

Example. A MacBook with Apple silicon is found unlocked. The examiner records the APFS layout and FileVault state, notes three local Time Machine snapshots from the previous two days, and takes a logical acquisition of the Data volume including the snapshots, hashing every file. The user's password is not available and no MDM escrow exists. After power-off the internal storage cannot be decrypted, and the report says so: the logical acquisition is the evidence, its scope is stated, and the two files of interest are recovered from the oldest snapshot, with the snapshot's creation time as the upper bound on when they existed.