macOS Forensic Acquisition: Live vs Dead-Box Triage
How to acquire evidence from a Mac: live vs dead-box, FileVault, Full Disk Access, SIP, order of volatility, and triage with Aftermath, mac_apt and UAC.
Acquisition is the step that decides what every later analysis can and cannot prove. On macOS it answers a deceptively simple question for the investigator: what evidence can I actually get off this Mac, in what state, and with what integrity guarantees? The answer depends on the hardware generation, whether FileVault is on, whether you have the user's credentials, and whether the system is running when you arrive. This article walks through the decisions, the platform protections that get in the way (FileVault, TCC and Full Disk Access, System Integrity Protection), and the open-source tools most responders use for macOS triage.
Live vs dead-box on modern Macs
The classic DFIR playbook says: pull the plug, remove the drive, image it through a write blocker. On a modern Mac that playbook mostly fails.
- Intel Macs without a T2 chip (roughly pre-2018 models) behave like traditional computers. You can boot to Target Disk Mode or an external forensic environment and take a block-level image. If FileVault is enabled you still need a password or recovery key to decrypt the APFS volume, but the ciphertext image is complete.
- Intel Macs with a T2 chip encrypt the internal SSD with keys held by the T2. A block-level image taken off the device is not decryptable elsewhere. Imaging must happen through the Mac itself, with the volume unlocked.
- Apple Silicon Macs go further: storage is always encrypted, Target Disk Mode is replaced by the file-level Share Disk feature, and the boot security policy restricts external boot. See Apple Silicon forensics for the details.
In practice this means that for most corporate Macs today, the running and unlocked system is the most valuable evidence source you will ever have. Shutting it down can put the Data volume back behind FileVault, and if you lack the password or an escrowed recovery key, that may be the end of the investigation.
| Situation | Recommended approach | Main risk |
|---|---|---|
| Running, unlocked, credentials unknown | Live triage and logical collection now; do not reboot | Losing access to encrypted data at shutdown |
| Running, locked, credentials known | Unlock, then live triage and logical collection | Screen lock timeouts, remote wipe via MDM or Find My |
| Powered off, FileVault on, credentials or recovery key available | Boot to recovery, unlock Data volume, file-level copy; or boot normally and collect live | Changes caused by booting |
| Powered off, FileVault on, no credentials | Document, preserve the device, pursue escrowed keys (MDM, institutional key) | Data may be unrecoverable |
| Pre-T2 Intel Mac | Traditional block-level imaging is possible | FileVault still requires keys to read |
Check FileVault status on a live system before deciding anything else:
fdesetup status
diskutil apfs list
diskutil apfs list shows the containers and volumes, their roles (System, Data, Preboot, Recovery, VM) and whether each volume is encrypted and currently locked. Background on the volume layout is in the APFS glossary entry.
Platform protections that shape what you can collect
Full Disk Access and TCC
Running as root is not enough on macOS. Many user data locations are protected by TCC (Transparency, Consent and Control): Safari data, Mail, Messages, some parts of ~/Library, and the TCC databases themselves. Access is granted per application. If you run a collection script from Terminal, it is Terminal (or your terminal emulator) that needs Full Disk Access, not only the script.
Grant it in System Settings > Privacy & Security > Full Disk Access before you start, and note in your case log that you did. That change is itself recorded in the system TCC database and the Unified Logs, so documenting it keeps your own footprint distinguishable from attacker activity. For how TCC records grants, see TCC database forensics.
System Integrity Protection
SIP prevents even root from modifying protected system locations and from reading or writing certain protected data. Check it with:
csrutil status
Do not disable SIP to make collection easier. It requires rebooting into recovery, changes the security state you are trying to examine, and on Apple Silicon also lowers the boot security policy. A SIP status of "disabled" on a suspect machine is itself a finding worth recording.
The Sealed System Volume
Since macOS Big Sur the operating system lives on a cryptographically sealed system volume. You generally do not need to collect it: it is identical to Apple's build for that version. Record the exact version and build instead, and focus collection on the Data volume, where user data, logs, third-party software and persistence live.
What logical collection can and cannot reach
A logical collection from a live system copies files and metadata through the file system. It can reach almost everything on the Data volume that your process is authorized to read. It cannot reach:
- Unallocated space and deleted file content (APFS with TRIM on SSDs makes carving low-yield anyway).
- Data locked behind TCC if Full Disk Access was not granted.
- Keychain secrets. You can copy keychain files, but their contents are encrypted and protected by the user's credentials and, on newer hardware, the Secure Enclave.
- Data in other users' encrypted contexts that is not currently unlocked.
- Physical memory, in most cases. Public memory acquisition options for current macOS, and especially Apple Silicon, are very limited. When you do obtain a memory image, RAM Parser can analyse it in the browser with macOS kernel plugins (process cross-view, kext inventory) without uploading it anywhere.
When copying files, preserve extended attributes and timestamps. The com.apple.quarantine attribute, kMDItemWhereFroms and others carry evidence (see Quarantine events and Gatekeeper). ditto preserves extended attributes and resource forks by default, and ls -l@ lets you verify:
ditto /Users/analyst/Downloads /Volumes/EVIDENCE/case01/Downloads
ls -l@ /Volumes/EVIDENCE/case01/Downloads
Do not rely on copy tools that silently drop xattrs, and be aware that the access and change timestamps of your destination copies reflect your copy, not the original.
Order of volatility on macOS
Collect the most volatile data first. A reasonable macOS order:
- System state and time:
date -u,sw_vers,hostname,uptime,system_profiler SPHardwareDataType(serial number, model). - Processes and network:
ps aux,lsof -i -n -P,netstat -anv,ifconfig,arp -an. - Loaded persistence and services:
launchctl list, and on Ventura and latersfltool dumpbtmfor Background Task Management items (see launchd persistence). - Unified Logs: they rotate by size, so collect them early with
log collect. - Mounted volumes and snapshots:
mount,diskutil list,tmutil listlocalsnapshots /(APFS snapshots can hold older file versions). - File system artifacts: user and system artifacts,
/.fseventsd, databases, plists.
Save output to external media, not the suspect disk:
OUT=/Volumes/EVIDENCE/MBP-IR-01
date -u > "$OUT/collection_time_utc.txt"
ps aux > "$OUT/ps_aux.txt"
lsof -i -n -P > "$OUT/lsof_network.txt"
launchctl list > "$OUT/launchctl_list.txt"
sudo log collect --output "$OUT/system_logs.logarchive" --last 7d
log collect produces a .logarchive bundle that can be analyzed later with log show on another Mac or with cross-platform parsers. The Unified Logs article covers the options in detail.
Triage tools
Aftermath (Jamf)
Aftermath is an open-source Swift incident response framework from Jamf, built specifically for macOS. It runs on the live system and collects a broad set of artifacts (browser data, persistence items, logs, file listings, TCC databases and more) into a single archive. It has a separate analysis mode that processes a previously collected archive into timelines.
sudo aftermath
sudo aftermath --analyze /path/to/Aftermath_archive.zip
It needs root and, to be useful, Full Disk Access for the binary or the terminal launching it. Output options and module flags change between releases, so check aftermath --help for the version you deploy.
UAC (Unix-like Artifacts Collector)
UAC by tclahr is a shell-based collector that runs on Linux, macOS, BSDs and other Unix-like systems with no dependencies beyond what the OS provides. Collection is driven by YAML artifact definitions grouped into profiles such as ir_triage and full.
sudo ./uac -p ir_triage /Volumes/EVIDENCE/MBP-IR-01
The result is a compressed archive named after the host and collection time, plus a log of the commands UAC ran. Because UAC is plain shell, it is easy to audit, which helps when you must explain exactly what touched the system. Profiles and artifact definitions evolve, so list them with the tool's help output rather than assuming names.
mac_apt
mac_apt by ydkhatri is primarily an offline analysis framework. It accepts disk images (E01, DD, DMG, VMDK and others), mounted volumes, and in some modes collected artifact folders, and runs plugins that parse dozens of artifacts into SQLite, with optional spreadsheet or delimited-text output depending on the version. It can decrypt FileVault-protected APFS images when given the password or recovery key.
python3 mac_apt.py -o /cases/case01/out E01 /cases/case01/MBP-IR-01.E01 ALL
For a quick look inside an E01, raw, VMDK or VHD image before a full mac_apt run, Disk Image Parser opens it in the browser and lets you browse its APFS or HFS+ volumes, with the image staying on your workstation.
Treat mac_apt as the parsing stage that follows collection, not as a live collector. Input types, flags and plugin names are documented in the project and should be confirmed against the version you use.
| Tool | Runs on the suspect Mac | Main role | Output |
|---|---|---|---|
| Aftermath | Yes (live) | Collection plus separate analysis mode | Archive with collected artifacts |
| UAC | Yes (live) | Collection driven by profiles | Compressed archive plus logs |
log collect | Yes (live) | Unified Logs collection | .logarchive bundle |
| mac_apt | No (analysis workstation) | Parsing images and artifacts | SQLite, optional spreadsheet/text exports |
Hashing and documentation
Hash everything you produce as soon as it is written, and store the hash list separately:
cd /Volumes/EVIDENCE/MBP-IR-01
find . -type f -exec shasum -a 256 {} \; > ../MBP-IR-01_sha256.txt
A .logarchive is a directory bundle, so hash its contents (as above) or package it in a single archive and hash that. Record for each action: the time in UTC, the command, the operator, and whether it required a privilege or TCC change. Live response inevitably changes the system; the goal is that every change is explainable.
Pitfalls
- Rebooting or shutting down a FileVault-protected Mac without credentials or an escrowed recovery key can make the Data volume unreadable.
- Forgetting Full Disk Access produces collections that look complete but silently miss Safari, Mail, Messages and TCC data. Check tool logs for permission errors.
- Leaving the Mac online allows remote wipe through MDM or Find My, and lets an attacker react. Consider network isolation while the system stays powered.
- Collecting to the suspect disk overwrites free space and pollutes FSEvents and other activity artifacts. Write to external media.
- Trusting time blindly: record the system clock against a reference and note the time zone. Many macOS artifacts use Mac Absolute Time or other epochs.
- Waiting too long for logs: Unified Logs are size-limited and rotate. Collect them early.
Frequently asked questions
Can I still take a full physical image of a modern Mac's internal disk?
Usually not in a useful form. On T2 and Apple Silicon Macs the internal storage is encrypted with keys bound to the security chip, so a raw copy of the flash is unreadable off the device. Plan for a live logical collection from the unlocked system, or a file-level copy after unlocking the Data volume with valid credentials.
Why does my triage collection miss Safari, Mail or the TCC database?
Those locations are protected by TCC. Even root cannot read them unless the process doing the collection (for example Terminal or the collection binary) has been granted Full Disk Access in System Settings. Grant it before collecting and record that you did so.
Which tool should I use for macOS triage?
Use what fits the situation. Aftermath and UAC are designed to run on a live Mac and produce an archive; mac_apt is mainly an offline parser for images, mounted volumes or collected artifacts. Many teams collect live with Aftermath or UAC plus log collect, then parse with mac_apt and other tools.