10. macOS

15. Preservation, acquisition, analysis

macOS workstations: FileVault and APFS

In short: a powered-on, unlocked Mac is frequently the only opportunity to obtain decrypted data, so preserve the session and acquire logically before anything else.

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 upshot: some acquisitions possible on other platforms are not possible here.

Powered on and unlocked: work the session

1. Document the state (section 3) and preserve the session. Connect mains. Do not close the lid, log out or switch user.
2. Isolate physically (section 4). Macs have no hardware wireless switch: remove an external adaptor, and handle an internal one by shielding rather than through the menu bar.
3. Capture volatile evidence where feasible. Software memory acquisition on current macOS is constrained (see below), so record what the running system tells you with native commands from your own media, each with its output.
4. Take a decrypted logical acquisition of the Data volume, and of any other unlocked volume that matters (see below).
5. Acquire physical storage where technically and legally possible, and state which image you obtained and why the others were not (see below).
6. Hash and verify every acquisition (section 9). A logical acquisition of a live filesystem is a derived artefact: hash its container and each file within it, since a repeat acquisition will not match at the container level.

Record volatile state without weakening the Mac

Kernel extensions are restricted, System Integrity Protection prevents loading unsigned ones, and on Apple silicon there is no established general-purpose memory tool.

Instead, run and record:

• Time: date and systemsetup -gettimezone.
• Users: who and last.
• Processes and open files: ps aux; lsof.
• Network: netstat -an and ifconfig.
• Storage: mount; diskutil list; diskutil apfs list (containers, volumes, capacity, FileVault and lock state for each volume).
• Encryption: fdesetup status.
• Snapshots: tmutil listlocalsnapshots / and diskutil apfs listSnapshots <volume>.

Take the decrypted logical acquisition

• Use a tool that reads through the mounted filesystem and preserves metadata and extended attributes.
• Or use 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. That is a configuration change on the evidence; record it.
• Record what was included, including whether snapshots were captured.

Know what physical acquisition can give you

On T2 and Apple silicon, the realistic alternatives are:

• A block-level image of the internal disk taken from the live system with root. It is an image of the encrypted container: useful for structure, not for content.
• The decrypted logical acquisition above.

State clearly in the record which of these was obtained and why the others were not.

Avoid 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

1. Identify the model (Intel, T2, Apple silicon), because the acquisition options differ as above.
2. Pursue a FileVault recovery source (below).
3. With a key or password, use the Mac itself as the decryption tool. It must be booted, which is a documented decision, and the logical acquisition is taken from the unlocked system as above.

FileVault recovery sources:

• Personal recovery key: shown to the user at enablement, and securely synchronised with other passwords when iCloud Keychain is in use.
• Institutional recovery key: held by the organisation.
• MDM-escrowed recovery key: the common enterprise route.
• The password of any FileVault-enabled user, obtained lawfully.

Booting a physical image of the internal storage of a T2 or Apple silicon Mac elsewhere is not possible.

Examine APFS

• 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. 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.
• 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.

Pull the macOS artefacts

• Unified Logs: the system-wide log, in compressed binary files under the diagnostics and uuidtext directories. Covers process activity, authentication, network changes, USB connections and much else, with sub-second timestamps. 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. No per-event timestamps, but 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. Query live with mdfind and mdls; parse 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 holds 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 carving assumes a deleted file's blocks remain, unchanged and contiguous, in unallocated space. A modern Mac breaks that assumption four ways:

• SSD with TRIM. Freed blocks are typically zeroed by the drive soon after deletion.
• Copy-on-write. A modified file's new content goes to new blocks while old blocks are released, scattering versions.
• Snapshots. They hold references to blocks that would otherwise be free, so "unallocated" depends on which snapshot you consider.
• FileVault. Data at rest is ciphertext, so blocks outside any file record cannot be interpreted at all without the volume key context the live system provides.

So 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.