macOS Forensic Artifacts: plist, Keychain, Time Machine

Before macOS 10.13 High Sierra (2017), every Mac shipped on HFS+ (Hierarchical File System Plus, also called Mac OS Extended). HFS+ was a 1998-era filesystem with extents, a catalog B-tree, and forensic behaviour that mostly mirrored the FAT/NTFS mental model from Windows. Indian state FSL teams trained on HFS+ are still tested on it because pre-2018 Macs still surface in cold cases and inheritance disputes, but everything seized from 2018 onwards is APFS.

APFS differs from HFS+ in ways that directly affect acquisition and recovery. The design that matters for the examiner:

• Containers and volumes. An APFS container is a single physical region (usually the whole disk). Inside it, multiple volumes share free space dynamically. A 1 TB SSD with four APFS volumes does not have four fixed partitions; the volumes grow into the container's free pool as they need it. Acquisition tools must image the container, not just the boot volume, or the examiner loses the data, recovery and preboot volumes.
• Copy-on-write. Modifying a file does not overwrite the original block. APFS writes the new version to a fresh block and updates pointers. The old block survives until garbage collected, which has obvious recovery implications and equally obvious anti-recovery implications on TRIM-aware SSDs.
• Snapshots. APFS takes point-in-time read-only snapshots cheaply because of copy-on-write. Time Machine uses these. tmutil listlocalsnapshots / shows what's on disk; mount_apfs -s <snap> mounts one read-only. Snapshots can hold deleted files for days even on a TRIM SSD.
• Clones. A clone is a zero-cost file copy: APFS just bumps a refcount and starts diverging on write. Forensically you want to know clones existed; mac_apt flags them.
• Native encryption (FileVault 2). FileVault on APFS encrypts at the volume layer with AES-XTS. Without the user password, recovery key, or institutional key, an APFS-encrypted volume is opaque even after physical acquisition.

macOS has no init, no systemd, no native cron for users. Everything is launchd, which boots PID 1 and supervises every service after it. From an examiner's view, that's a gift: persistence on macOS is concentrated in a small number of paths and a single format.

The persistence locations, ranked by how often they show up in Indian casework:

• /Library/LaunchDaemons/: system-wide, run as root, launched at boot. Targeted by Shlayer-family adware and other root-privilege malware.
• /Library/LaunchAgents/: system-wide, run per user session at login.
• ~/Library/LaunchAgents/: per-user, run at that user's login. The favoured location for unprivileged malware and for legitimate-but-suspicious tools like data-exfil scripts in insider matters.
• /System/Library/LaunchDaemons/ and /System/Library/LaunchAgents/: Apple-owned, on the SSV-protected system volume. Modification here on macOS 11+ is effectively impossible without breaking System Integrity Protection. Items here are baseline and not where you look first.
• Legacy: /etc/cron.d, ~/.crontab, cron.daily. Almost extinct on macOS, occasionally seen in cross-platform infection scripts.
• LoginItems configured in ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm (replacing the older login items plist on macOS 13+). The Background Task Management database is now the canonical source for "what auto-runs at login."

Each LaunchAgent/LaunchDaemon is a plist with the keys you actually care about: Label, ProgramArguments, RunAtLoad, KeepAlive, StartInterval, WatchPaths. A 30-second StartInterval on a binary in ~/Library/Application Support/<random>/ is the classic insider-data-exfil signature.

1. Enumerate
   List every plist under the three LaunchAgents/LaunchDaemons paths and parse with plutil.
2. Resolve binaries
   For each ProgramArguments, hash the target binary and check against VirusTotal, NSRL and your local known-good baseline.
3. Cross-check btm
   Parse backgrounditems.btm to find the Background Task Manager view of login items, including those registered through the new SMAppService API.
4. Walk Unified Log
   Query `log show --predicate 'subsystem == "com.apple.xpc.launchd"'` to see when each item launched and what spawned it.
5. Correlate to FSEvents
   Map plist creation/modification timestamps against fseventsd to find when the persistence was installed and what process did it.

A .plist is a key-value dictionary serialized either as Apple's old XML format or as the much more common binary plist (magic bytes bplist00). They store everything: app preferences, recent files, login window state, Dock icons, Spotlight history, malware configuration.

Two pragmatic rules. First, never grep a binary plist; it'll look like noise. Convert it. Second, never trust a plist on a live system to be in a consistent state; preferences are written in batches by cfprefsd, and reading them while the user is logged in produces stale results. On a dead-box image you read the file directly; on a live triage you flush with defaults after asking the suspect to log out, which usually you can't, so prefer dead-box.

The conversion incantations:

• plutil -convert xml1 com.apple.recentitems.plist -o - prints an XML view to stdout without modifying the file.
• plutil -p file.plist prints a human-readable dump.
• plistutil -i file.plist -o file.xml is the Linux-native equivalent inside SIFT/REMnux containers.
• mac_apt parses plists across an entire mounted image and produces a single CSV per artifact category.

Plists that come up repeatedly in CFSL Pune and Mumbai state cyber cell macOS casework (under BSA Section 63 certificate workflow):

• com.apple.loginwindow.plist (per user under ~/Library/Preferences/): last logged-in user, auto-login flag.
• com.apple.recentitems.plist: recent applications, documents, servers and AirDrop transfers. AirDrop history shows up here even when the user thinks they cleared it.
• com.apple.airport.preferences.plist: every Wi-Fi network ever joined, with BSSID and last-connected timestamp. Useful for placing the device geographically.
• com.apple.Bluetooth.plist: every Bluetooth device ever paired.
• com.apple.preferences.softwareupdate.plist: last update check; helps establish when the user last had the device online.
• com.apple.spotlight.plist and com.apple.spotlight.Shortcuts: Spotlight search history.
• com.apple.dock.plist: Dock pinned apps, recent applications, and recent documents per Dock category.

The Keychain is among the highest-value artifacts on a Mac. Open a login.keychain-db and you find: every saved website password, every saved Wi-Fi PSK, every iMessage and iCloud token, app-specific passwords, S/MIME private keys, code-signing keys for developers, and any secure notes the user dropped in. Its contents often establish credentials and account access before browser history is examined.

The catch: it is properly encrypted. Each item is wrapped under a key derived from the user's login password through PBKDF2 with a per-item salt. Without one of (the login password, a registered Touch ID re-derivation, a Keychain recovery key, a RAM dump containing the in-memory master key), the database is opaque.

The forensic options:

• Known password. Mount the user volume, run security find-generic-password -ga <itemname>, or for batch extraction use chainbreaker against the raw login.keychain-db. This is the standard CFSL path when the suspect cooperates under BNSS Section 94 (production notice) or has handed over the password during seizure.
• Live RAM extraction. If the device was seized while logged in, a RAM image captured before shutdown contains the unwrapped Keychain master key. Tools: AXIOM Volatility for macOS, Recon ITR. This is why the Digital First Responder is told never to power down a running Mac in custody without an attempt at memory capture first; cross-link Digital First Responder: Volatility, Seizure and Imaging.
• iCloud Keychain sync. With the right Apple ID credentials and 2FA, Keychain items are recoverable from iCloud. The legal pathway is an MLAT request through I4C / CBI to Apple Inc., which is slow but works for the cases that justify it.
• Brute force. hashcat -m 23100 for macOS Keychain on the extracted DB. Worth running against a 6-character dictionary for the speculative case; not worth running against a high-entropy password.

FileVault is the volume-level counterpart. The recovery options mirror Keychain: user password, personal recovery key (printed at FileVault setup), institutional recovery key (MDM-managed), or iCloud-stored recovery key. An MDM-managed Mac at an Indian enterprise will usually have institutional recovery keys escrowed to Jamf or Kandji, and a properly-drafted production notice to the enterprise IT team is faster than an MLAT.

After documenting persistence mechanisms and credentials, timeline construction requires four system-level sources. Four sources matter.

Time Machine on macOS 11+ stores hourly snapshots locally for 24 hours and uses APFS replication to a destination drive if one is configured. tmutil listbackups lists destination backups; tmutil listlocalsnapshots / lists local ones. Each is a full read-only image of the volume at that point. Mount with mount_apfs -s com.apple.TimeMachine.2026-05-15-143000.local /Volumes/snap1. You can walk a file's history backwards across deletions, which is how a "wiped" project folder gets reconstructed in a Bengaluru source-code-theft matter.

Unified Logging lives at /var/db/diagnostics/ as .tracev3 files keyed against the UUID-to-format-string database at /var/db/uuidtext/. The query interface is the log command:

log show --start "2026-05-10 09:00:00" --end "2026-05-10 18:00:00" \
  --predicate 'subsystem == "com.apple.xpc.launchd"' --info --debug

A SOCO who only knows /var/log/system.log will see a near-empty file and conclude nothing happened. The reality is that Unified Logging captures process launches, network state changes, USB attach events, authorisation prompts and far more, in compact binary form. mac_apt extracts Unified Log entries into CSVs for offline review.

Spotlight maintains .Spotlight-V100 on every indexed volume. The store is binary and proprietary, but mdfind against a mounted image lets you replicate the user's search experience. More importantly, the MDImporter plugins record every imported file's metadata, which sometimes preserves filenames of files long deleted.

FSEvents at /.fseventsd/ is the filesystem event log: every create, modify, delete, rename, with a 64-bit event ID and a flag set. Tools: FSEventsParser (David Cowen) and mac_apt. FSEvents lasts weeks to months depending on volume size and activity. In a 2024 Hyderabad insider-data-exfil case, an FSEvents parse showed a 4 a.m. burst of file renames in ~/Projects/, immediately followed by a Drop-classified set of writes to /Volumes/SanDisk, which placed the suspect at the workstation with the device.

Once system-level artifacts are handled, the per-user ~/Library/ tree is where the actual case content sits. The structure is consistent across users:

• ~/Library/Application Support/<app>/: the canonical per-app data folder. Chrome stores its profiles here; Signal stores its database here; many enterprise tools store cached corporate data here.
• ~/Library/Containers/<bundle-id>/Data/: sandboxed apps see a virtualised home directory rooted here. App Store apps and most Apple first-party apps live in containers.
• ~/Library/Caches/<bundle-id>/: per-app caches; sometimes contain unencrypted copies of otherwise encrypted content. Slack, Teams and Discord caches frequently hold message excerpts.
• ~/Library/Preferences/: per-app and per-domain plists.
• ~/Library/Application Scripts/<bundle-id>/: sandboxed scripting handlers, occasionally abused for persistence.
• ~/Library/Safari/, ~/Library/Mail/, ~/Library/Messages/: Apple first-party app data, not sandboxed in the container tree.
• ~/Library/Mobile Documents/: iCloud Drive content, mirrored from cloud.
• Hidden dotfiles: .DS_Store (per-folder Finder view; preserves filenames of deleted files), .Trashes/ (deleted-via-Finder content), .zsh_history (shell history on Catalina+; .bash_history on older systems).

The browser map on a Mac:

Messages.app stores the SQLite database at ~/Library/Messages/chat.db with the attachment tree at ~/Library/Messages/Attachments/. iMessage and SMS share the same DB. The schema (message, chat, handle, attachment, joined through chat_message_join) is parsed by mac_apt, Cellebrite Inspector, and a number of open-source iMessage extractors. A 2025 Pune financial-fraud matter turned on a recovered chat.db entry that had been deleted in the UI but survived in the SQLite WAL file.

For iCloud sync, ~/Library/Mobile Documents/ contains everything the user has put on iCloud Drive, mirrored locally for offline access. Apple Notes lives partly here and partly in ~/Library/Group Containers/group.com.apple.notes/NoteStore.sqlite. Photos in ~/Pictures/Photos Library.photoslibrary/ (a bundle, not a directory in Finder's view; right-click "Show Package Contents" or just ls from the terminal).

For the Linux-side counterpart artifact map, see Linux Forensic Artifacts: Filesystem, Logs, Cron and Shell History. For the Windows counterpart, see Windows Forensic Artifacts: Registry, Event Logs and Prefetch. The chain of custody requirements that apply to every macOS image are covered in Chain of Custody.