macOS Forensics Guide: Unified Logs, FSEvents and TCC

Macs now sit on the desks of the people attackers most want to reach, executives and developers, yet many incident response teams still investigate them with Windows habits and tools that cannot read what macOS actually records. Apple silicon encrypts internal storage with keys held in the Secure Enclave, the system volume is sealed and read-only, and the richest evidence lives in binary unified logs, SQLite databases and gzip streams rather than in an event log. This guide explains how to acquire evidence from a modern Mac and how to analyse the artefacts that answer incident questions: the unified log, FSEvents, TCC, KnowledgeC and Biome, quarantine records, persistence locations and shell history. It is written for DFIR analysts, SOC leads and endpoint engineers who already know general forensics. Detection engineering for macOS is covered in the macOS Detection and Response Guide; this page goes deeper on evidence.

Key takeaways

Acquisition is logical, not physical. On Apple silicon and T2 Macs internal volumes are always hardware encrypted, so a chip-off or raw image is ciphertext; plan for live or credentialed logical collection.
The unified log is the event log, and it ages out. Collect a .logarchive early, because high-volume entries can be purged within days.
FSEvents shows what changed, not when. Records carry a path, flags and an event identifier but no timestamp, so they need anchoring to other sources.
TCC is the privacy perimeter and an attacker target. The TCC databases show which processes gained Full Disk Access, screen recording or accessibility rights.
Usage databases moved. KnowledgeC remains valuable on older systems, but from macOS 13 most usage statistics are stored in Biome, so tools must parse both.

How macOS changes the forensic model

NIST SP 800-86 frames forensics as collection, examination, analysis and reporting. On a Mac each step is shaped by Apple's platform security design.

Platform feature	What Apple documents	Forensic consequence
Always-on storage encryption (Apple silicon and T2)	Internal APFS volumes are encrypted by the Secure Enclave and AES Engine whether or not FileVault is on	A disk removed from the Mac, or a raw image without keys, cannot be read; collect from the running system or with the user's credentials or recovery key
FileVault	Adds a key encryption key protected by the user password and hardware UID; a 24-character recovery key is generated	Obtain the recovery key from MDM escrow before the device is powered off
Remote or MDM erase	Erasing the media key makes the volume cryptographically inaccessible	Suspend any automated wipe workflow for a device under investigation
Signed system volume (macOS 11 and later)	System content sits on a sealed, read-only volume verified at every boot	Malware and persistence live on the Data volume and in user Libraries; system binary tampering is rare and should be treated as a major finding
Separate System and Data volumes (macOS 10.15 and later)	A dedicated, isolated volume holds system content	Tools must parse both volumes of the APFS container and their firmlinks
Privacy controls (TCC)	Protected locations need user consent or Full Disk Access	Your collector itself needs root and Full Disk Access, otherwise collection silently misses Mail, Messages, Safari and TCC data

Acquisition options and decision guidance

Choose the acquisition method by what the case needs and what the device allows. In most corporate investigations a scripted live collection through MDM is the default, with full logical images reserved for cases that may go to court or that need deleted-file recovery.

Method	What you get	When to choose it	Trade-offs
Targeted live triage collection (for example Jamf Aftermath, Velociraptor or UAC collections)	Unified log, databases, persistence, browser and shell artefacts, process and network state	Fast scoping across many Macs, remote users, malware and stealer cases	Requires root and Full Disk Access; changes the system slightly; no unallocated space
Full logical image of the Data volume (sparse image or DMG while running, or decrypted with credentials)	All allocated files, including databases and caches	Insider, HR or legal cases; deep timeline work	Slow on large disks; needs user credentials or recovery key on FileVault Macs
Unified log collection only (`log collect` to a `.logarchive`)	Persisted log store plus format strings needed to render messages	Immediate preservation when time is short	Large output; must be taken with root to capture the full store
Memory acquisition	Running processes, injected code, decrypted secrets	Fileless or in-memory malware suspected	Limited tooling on Apple silicon; SIP and kernel restrictions apply
Endpoint telemetry export (EDR, Endpoint Security events)	Process, file and authentication events already shipped off the device	Device lost, wiped or unavailable	Only as good as what was collected before the incident

Do not power off first. On a FileVault Mac a shutdown locks the volume key behind the user password. Keep the device awake, on power and off the network (disable Wi-Fi, keep the EDR connection only if you need live response).
Retrieve the FileVault recovery key from MDM escrow and record the retrieval.
Collect volatile and fast-ageing data first: process list and tree, network connections, logged-in users, then the unified log archive.
Run the triage collector as root with Full Disk Access, writing to external or network storage rather than the suspect disk where possible. Jamf's open-source Aftermath, for example, writes to /tmp by default unless you set an output location.
Take a logical image if the case warrants it, then hash every output file and record the chain of custody.
Test the whole sequence on a lab Mac with your MDM and EDR, and time it, before you need it.

The unified log

Unified logging replaced syslog-style text files from macOS 10.12 (2016). Entries are stored in binary .tracev3 files under /private/var/db/diagnostics/ in the Persist, Special, Signpost and HighVolume subdirectories, with timesync files for time correlation. The format strings that turn an entry into readable text are kept separately under /private/var/db/uuidtext/, which is why copying only the diagnostics folder produces unreadable messages. A .logarchive bundle packages both.

Collection: log collect --output <path>.logarchive as root on the live system, optionally limited with --last or --start; then analyse with log show --archive on an examiner Mac, or parse on any platform with Mandiant's open-source Rust library and its unifiedlog_iterator tool, which outputs JSONL or CSV.
Fields that matter: timestamp, process and process UUID, PID, effective UID, subsystem, category, activity ID, boot UUID and message. Filter by subsystem and process rather than free text where you can.
Privacy redaction: dynamic strings are often logged as <private>, so expect gaps in usernames, paths and URLs.
Retention: the log store is size-managed, not time-managed. Busy systems may keep only days of some categories. Collect early and ship key predicates to your SIEM in advance.

Question	Where to look in the unified log
Who logged in, and how	`loginwindow` session events, `sshd` and screen sharing entries
Was sudo used or attempted	`sudo` process entries, including failed attempts
Were privacy permissions granted or prompted	`tccd` process entries
Did Apple's built-in malware tools act	XProtect and XProtect Remediator entries
Was a configuration profile installed manually	Profile installation entries from the management subsystems
Did Gatekeeper assess or block an app	Gatekeeper and `syspolicyd` entries

Aftermath ships default predicates along these lines (failed sudo, login, manual configuration profile install, screen sharing, SSH, TCC, XProtect Remediator), which is a practical starting set to adapt.

FSEvents: file system change history

The fseventsd daemon records file system changes per volume in a hidden .fseventsd directory at the volume root. Each file is a multi-member gzip stream; the record format changed from version 1 (DLS1, up to macOS 10.12) to version 2 (DLS2, from macOS 10.13). A version 2 record holds a path, an event identifier, event flags and a node identifier.

Strength: FSEvents can show that a file existed and was created, renamed, modified or deleted even after the file is gone, including on external drives that were attached to the Mac.
Limitation: there is no timestamp in each record. Event identifiers increase monotonically, so you date a range by anchoring known events (a file with a known creation time, a log entry) and bracketing the unknown ones between them.
Use it for: malware staging in /tmp or user Libraries, archive creation before exfiltration (stealers commonly zip collected data), files copied to USB media, and deletion of tools after use (T1070.004 File Deletion).
Tooling: mac_apt's FSEVENTS plugin parses .fseventsd from images and collections into CSV, XLSX or SQLite.

TCC, quarantine and persistence artefacts

Artefact	Location	What it answers	ATT&CK
TCC databases	`/Library/Application Support/com.apple.TCC/TCC.db` (system) and `~/Library/Application Support/com.apple.TCC/TCC.db` (per user)	Which apps and binaries hold Full Disk Access, screen recording, accessibility, camera and other grants, and when they were last modified	T1056.002 GUI Input Capture (accessibility abuse)
LaunchServices quarantine events	`~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2`	Downloaded files, source URL and downloading app, even after deletion	T1553.001 Gatekeeper Bypass (files missing the attribute)
Quarantine extended attribute	`com.apple.quarantine` on individual files	Whether a file came from the internet and which app fetched it	T1553.001
Launch agents and daemons	`~/Library/LaunchAgents`, `/Library/LaunchAgents`, `/Library/LaunchDaemons`	Persistent programs and their arguments	T1543.001 Launch Agent, T1543.004 Launch Daemon
Background Task Management database	Read with `sfltool dumpbtm`	Registered login items and background items, including ones removed from disk	T1547.015 Login Items
Shell history and Terminal saved state	`~/.zsh_history`, `~/.bash_history`, Terminal saved application state	Commands run, including pasted one-liners from fake installer or "fix" pages	T1059.004 Unix Shell, T1070.003 Clear Command History
Keychains	`~/Library/Keychains/`	Whether keychain files were copied (stealer behaviour); stored credentials needing rotation	T1555.001 Keychain
XProtect Behavior Service database	Collected by Aftermath and parsed by mac_apt XPROTECT	Apple's own behavioural detections on the device

TCC grants are a frequent pivot: a stealer that tricks the user into granting Full Disk Access or Terminal automation can read browser stores and the keychain. See the macOS TCC and Privacy Permissions Management Guide for how grants should look on a managed fleet, which is your baseline for spotting anomalies.

KnowledgeC, Biome and user activity

To answer "what was the user doing at the time", macOS keeps usage databases built for features such as Screen Time and Siri suggestions.

KnowledgeC: knowledgeC.db is a SQLite database at /private/var/db/CoreDuet/Knowledge/ (system) and ~/Library/Application Support/Knowledge/ (user). The ZOBJECT table holds entries with a ZSTREAMNAME such as /app/inFocus, /app/usage, /safari/history and /device/isLocked, with start and end times.
Biome: from macOS 13 most of these statistics are stored in Biome streams instead of KnowledgeC, so a tool that only parses KnowledgeC will return little on current Macs. mac_apt has a BIOME plugin and a SCREENTIME plugin.
Timestamps: Apple stores many times as Mac absolute time, seconds since 1 January 2001 UTC. Convert by adding 978,307,200 to get Unix time, and record the conversion in your notes.
Corroboration: these databases depend on the device clock. Cross-check app focus times against unified log entries and FSEvents ordering before relying on them.

Where identity fits

Developer and administrator Macs hold the credentials that turn one infected laptop into a cloud or supply chain incident: SSH keys, cloud CLI profiles, Git and package registry tokens, browser session cookies and password manager data. Every macOS investigation should end with a credential inventory of the device and a rotation decision for each item. Stealers that target macOS (see the Atomic macOS Stealer Guide) collect exactly this material, and session cookies can bypass MFA. Run the Leaked Credential Response Playbook for anything found, and use the Infostealer Threat Guide for the wider response.

Building the timeline and measuring readiness

Normalise all times to UTC and record each source's time format (Mac absolute time, Unix epoch, HFS+ dates, unified log timesync).
Start from a known anchor, usually the quarantine event for the first malicious download or the first suspicious unified log entry.
Add persistence creation (launch item file creation, BTM registration), TCC changes, shell commands and FSEvents ranges.
Close with network evidence (EDR, proxy) for exfiltration and with credential use in identity provider and cloud logs.

Metrics that show the capability works:

Percentage of managed Macs where the triage collector can run with root and Full Disk Access through MDM (target: all).
FileVault recovery key escrow coverage (target: all FileVault-enabled Macs).
Median time from incident declaration to unified log archive collected.
Unified log look-back available on a sample of Macs, measured in days.
Percentage of macOS investigations that completed a credential inventory and rotation decision.

Framework mapping

Framework	Reference	How this guide applies
NIST SP 800-86	Collection, examination, analysis, reporting	Acquisition order and evidence handling above
NIST CSF 2.0	RS.AN-03, RS.AN-06, RS.AN-07	Root cause analysis; recording investigative actions; preserving integrity and provenance of incident data
NIST SP 800-53 Rev. 5	IR-4, AU-6, AU-9, AU-11	Incident handling; audit review; protecting and retaining log evidence
CIS Controls v8.1	Control 8 Audit Log Management; Control 17 Incident Response Management	Shipping unified log predicates off-device; IR readiness for Macs
ISO/IEC 27001:2022 Annex A	A.5.28 Collection of evidence; A.8.15 Logging	Evidence procedures and log retention
MITRE ATT&CK	T1543.001, T1543.004, T1547.015, T1555.001, T1553.001, T1056.002, T1059.004, T1070.003, T1070.004, T1005	Artefacts mapped in the tables above

Common failure patterns

Shutting the Mac down to "preserve" it: on FileVault and Apple silicon this locks the evidence behind credentials and can lose the unified log tail.
Running collectors without Full Disk Access: collection completes without errors but TCC, Mail, Safari and other protected data are missing.
Copying diagnostics without uuidtext: the log entries cannot be rendered into readable messages.
Treating FSEvents order as time: conclusions about "when" without anchors are often wrong.
Parsing only KnowledgeC on macOS 13 and later: user activity appears absent because it is in Biome.
Reimaging before credential rotation: the device is clean but the stolen SSH keys, tokens and cookies still work.
Letting an MDM erase or a stolen-device workflow run while the device is under investigation.

Practitioner checklist

Escrow FileVault recovery keys in MDM for every Mac and test retrieval.
Pre-deploy or pre-package a triage collector with root and Full Disk Access granted by MDM profile.
Write a Mac acquisition runbook: keep awake, isolate network, recovery key, volatile data, log collect, triage, logical image, hashes.
Ship key unified log predicates (login, sudo, SSH, TCC, XProtect, Gatekeeper) to the SIEM so evidence survives log rotation.
Keep an examiner workflow that parses unified logs, FSEvents, TCC, quarantine, BTM, KnowledgeC and Biome, and validate it on each new macOS release.
Record a TCC baseline per device type to spot unexpected Full Disk Access and accessibility grants.
End every case with a credential inventory of the Mac and a rotation decision per credential.
Pause automated wipe workflows for devices on legal hold or under investigation.

macOS Forensics Guide: Acquiring and Analysing Unified Logs, FSEvents, TCC and KnowledgeC