macOS Forensic Artifacts: plist, Keychain, Time Machine and Browser Traces

Your journey to becoming a forensic professional starts here.

Practice with national-level exam (FACT, FACT Plus, NET, CUET, etc.) mocks, learn from structured notes, and get your doubts solved in one place.

Start Free Mock Test Create Your Account

macOS Forensic Artifacts: plist, Keychain, Time Machine and Browser Traces | ForensicSpot

macOS forensics used to be the niche corner of a Windows-heavy course. That stopped being true around 2022. Indian startups, IT services firms, design studios and senior leadership across BFSI now run on MacBook Pros and Mac minis, which means the laptop seized from a CXO in a Bengaluru insider-trading FIR or a Mumbai data-exfiltration matter is, more often than not, a Mac. The examiner who shrugs and says "I only do Windows" is the examiner the FIR walks away from. The artifact map on macOS is different, the filesystem is different, and the legal request you draft to the user for Keychain credentials has to be worded with care because BSA 2023 Section 63 evidence will rise or fall on that single decryption step.

This topic walks through the macOS forensic stack as it actually exists on macOS 13 Ventura, macOS 14 Sonoma and macOS 15 Sequoia: APFS containers and snapshots, launchd persistence, the binary plist format, the Keychain database, Time Machine recovery, the Unified Log, FSEvents, and the user-level artifact tree under ~/Library. Each Section ties a forensic mechanism to where it lands in Indian casework. By the end, you should be able to triage a Mac image in mac_apt, find the persistence mechanisms, decrypt a Keychain with a known password, walk a Time Machine snapshot back across deletions, and explain to a CrPC magistrate (now BNSS) why the artifacts you produced are reliable.

Key terms

APFS: Apple File System. Default on macOS since 10.13 High Sierra (2017). Container-and-volume design, copy-on-write, native snapshots, native encryption, space sharing across volumes inside a container.
launchd: macOS process supervisor that boots and manages every system and user service. Replaces init/cron/SysV-RC. Configured via .plist files under /Library/LaunchDaemons, /Library/LaunchAgents, and ~/Library/LaunchAgents.
Property list (plist): Apple's key-value config file format. Either XML or binary (bplist00 magic). Parsed with plutil, plistutil, or mac_apt. Holds preferences, recent items, login items, malware persistence.
Keychain: Apple's encrypted credential store. The per-user database at ~/Library/Keychains/login.keychain-db holds passwords, Wi-Fi PSKs, private keys, certificates and secure notes. Decryption needs the user's login password, a recovery key, or a RAM-extracted master key.
Time Machine: Apple's built-in backup system. On HFS+ targets it produced incremental hard-link trees in Backups.backupdb; on APFS targets (macOS 11 Big Sur and later) it uses snapshot-based local backups and APFS replication to the destination. Lets you walk file state back across time.
Unified Logging: macOS 10.12+ replacement for syslog. Binary .tracev3 files in /var/db/diagnostics/ and /var/db/uuidtext/. Queried with `log show --predicate ...`. Holds an order of magnitude more than the legacy /var/log/system.log.

APFS, snapshots and what changed under HFS+

Containers, volumes, copy-on-write and the snapshot you didn't know existed.

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 is a different beast. 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.

launchd and the persistence map

No init, no cron, just launchd, and three folders that hold every persistence trick.

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 the more capable Silver Sparrow loader.
/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.

Property lists, parsed properly

XML or binary, but only one survives reboots without surprises.

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 Indian casework:

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.

Keychain, FileVault and the password problem

Encrypted credentials are useless to you without the user's password. Plan accordingly.

The user's Keychain is the single most valuable single artifact 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. Decrypt it and you frequently solve the case before opening Safari history.

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.

Time Machine, Unified Log, Spotlight, FSEvents

Four system-level event sources, each with weeks or months of history.

Once you've handled persistence and credentials, the macOS examiner's next job is timeline construction. 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.

User Library, browsers, Messages and iCloud

The per-user tree under ~/Library is where the case usually lives.

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:

Browser	Profile root	History store	Other key files
Safari	~/Library/Safari/

Worked example

The Shlayer-flagged MacBook from a Pune insider-trading FIR

A composite, drawn from CFSL Hyderabad's 2024 macOS triage course.

The seized device is a 2021 MacBook Pro running macOS 14.4 Sonoma. The FIR alleges the senior analyst was forwarding pre-publication research to a personal account during a six-week window. The device was seized powered on; the first responder captured a 16 GB RAM image with Recon ITR, then performed a graceful shutdown after tmutil was queried for snapshot inventory. The disk was imaged at the container level (/dev/disk0, 1 TB) producing a .E01 triple-validated against the source SHA-256.

Triage flow on the working copy:

mac_apt run with the ALL_APPLE plugin produced 312 CSVs covering Unified Log slices, plist parses, FSEvents, browser histories and chat.db.
The persistence pass found a LaunchAgent at ~/Library/LaunchAgents/com.adobeflash.helper.plist (no Adobe Flash on macOS since 2020) pointing to a binary in ~/Library/Application Support/.flashcache/. The binary hashed to a known Shlayer adware variant. Unified Log showed it was installed two months before the alleged window, via a curl | bash from a torrented Final Cut Pro installer. Defence later argued the Shlayer payload made the device generally compromised and that exfiltration could not be attributed to the user. The prosecution's counter was specific: Shlayer-family adware does not exfiltrate PDFs.
FSEvents showed a regular pattern: a research PDF created in ~/Downloads/, opened in Preview, renamed and moved to ~/Documents/Research/, then within five minutes a Mail.app draft was created and sent. The Mail folder (~/Library/Mail/V10/<UUID>/) confirmed thirty-one emails to a Gmail address over the window, each with the renamed PDF attached.
Safari History.db and Downloads.plist showed the analyst's research portal access matched the PDF creation timestamps to the second.
The Keychain, decrypted with the password recovered from the RAM dump (the user was logged in at seizure), produced the Gmail password and the second-factor TOTP seed, which corroborated the recipient account. Mail headers from the Gmail account, obtained separately via an MLAT, closed the loop.

The Mac artifact stack alone produced timeline, attribution and recipient. The Shlayer infection was a distraction the defence tried to exploit; the FSEvents-plus-Mail timeline was specific enough that the magistrate accepted the exfiltration attribution despite the malware presence.

Practice

Question 1 of 5· 0 answered

On a macOS 14 Sonoma device, where does a forensic examiner look first to enumerate user-level persistence?

Frequently asked questions

What filesystem does modern macOS use, and how is it different from HFS+?

Macs running macOS 10.13 High Sierra (2017) and later use APFS, Apple File System. APFS introduces a container-and-volume design where multiple volumes share free space dynamically, copy-on-write semantics, native snapshots, native AES-XTS encryption (FileVault 2 on APFS), and zero-cost clones. HFS+ was the previous default, a 1998-era filesystem with extents and a catalog B-tree. APFS changes acquisition (image the container, not just a volume) and changes recovery (snapshots can preserve deleted files for days even on TRIM-enabled SSDs).

How do I read a .plist file on a non-Mac forensic workstation?

Two options. `plistutil -i file.plist -o file.xml` is the standard Linux-native converter and is available in Kali, SIFT and most forensic distros. Python's `plistlib` module reads both XML and binary plists directly: `python3 -c "import plistlib, sys, pprint; pprint.pprint(plistlib.load(open(sys.argv[1], 'rb')))" file.plist`. mac_apt parses plists in bulk across a mounted image and outputs CSVs per artifact category. Never grep a binary plist as raw text; the magic bytes are `bplist00` and the body is offset-encoded.

Can a Keychain be decrypted without the user's password?

Sometimes. A live RAM image captured before shutdown contains the unwrapped Keychain master key and can be used with chainbreaker or AXIOM to decrypt the database. A Keychain recovery key or institutional MDM-escrowed key (Jamf, Kandji) decrypts a Keychain without the user's interactive password. iCloud Keychain sync exposes items via the Apple ID with 2FA, recoverable through MLAT requests to Apple via I4C / CBI. Brute force with hashcat -m 23100 works only against weak passwords. Without one of these paths, the Keychain is opaque.

How long does Time Machine keep local snapshots?

/dev/disk1

disk1

diskutil apfs list

Source	Granularity	Retention	Best for
Time Machine local snapshots	Hourly full-volume	~24 hours local, full history on destination	Reconstructing deleted folders and project state
Time Machine destination	Hourly to daily	Bounded by destination size	Multi-month historical recovery
Unified Log (.tracev3)	Per-event, sub-second	Days to weeks, capped by /var/db/diagnostics size	Process launches, USB attach, network changes, auth events
.Spotlight-V100	Indexed metadata only	As long as volume exists	Locating files by content keyword and surfacing deleted-file metadata
.fseventsd	Per-FS-event with flags	Weeks to months	Create/modify/delete/rename timeline across the volume