macOS Evidence Handling: Integrity, Corroboration, and Stating Honest Limits

A finding is only as good as the evidence behind it and the honesty with which you state it. This section is the discipline that keeps a macOS investigation defensible. On a platform that decides for itself what to record, the honesty part carries more weight than it does on Windows, and you make it concrete with the same native commands you used to read the evidence.

Estimated time: 20 minutes.

Integrity and chain of custody

Every piece of evidence needs an integrity record from the moment you collect it. You hash the collection archive, the disk image, or the individual artifact files at acquisition, and you keep those hashes with the evidence so anyone can later confirm nothing changed. The native command is one line, and its output is the number you record.

# Hash the collection the moment you have it, and keep the hash with the evidence
% shasum -a 256 NE-VANCE-MBP_triage.tar.gz
9f2a1c7e4b834d2a9e517c3d8a1f2b60c4d5e6f70819a2b3c4d5e6f708192a3b4  NE-VANCE-MBP_triage.tar.gz

You record who collected it, when, from which machine, and how, and you re-hash before you hand it on so the value still matches. That chain is what lets a finding survive a challenge, whether the challenge comes from opposing counsel or your own incident commander.

macOS adds one wrinkle worth stating plainly. The realistic collection on a modern Mac is a logical one taken from a live, running system, and the act of collecting touches the machine. You cannot pretend otherwise, so you document it: what tool you ran, what it accessed, and the fact that a live collection is not a pristine dead image. A documented, repeatable live collection is defensible. An undocumented one is a problem you created for yourself.

Keep contemporaneous notes, not reconstructed ones. The value of a custody record is that it was written as you worked, timestamped and specific, rather than assembled from memory afterward. On a live macOS collection that means recording the exact commands you ran and the order you ran them, because the next examiner, or you in six months, needs to know precisely how the evidence came to exist.

Acquire while you can

Order of volatility decides what you collect first, and on a Mac the order is unusual. Memory is effectively out of reach under System Integrity Protection on Apple Silicon, so the most volatile thing you can realistically capture is the live system state: running processes, network connections, mounted volumes, and logged-in sessions. Below that sits the unlocked disk, then the snapshots and backups that hold earlier states.

The reflex from physical-disk forensics, pull the power and image later, is exactly wrong here. The moment a FileVault Mac locks or powers down, the decrypted volume can become unreachable, so you confirm the encryption state while you still have access and treat that window as perishable.

# Confirm encryption state before you rely on the volume being readable
% fdesetup status
FileVault is On.
% diskutil apfs list
    APFS Volume Macintosh HD - Data (disk3s1)
    FileVault:    Yes (Unlocked)

That "Unlocked" is the whole game. While it reads Unlocked you can image or collect from the volume. Once the machine locks it reads "Yes (Locked)", and diskutil apfs unlockVolume /dev/disk3s1 then demands the user password or the recovery key. Without one of those, the data is gone, and no later imaging recovers it. This is why you collect from the running, unlocked machine first.

The least volatile layer is still worth capturing, because it holds earlier states the live disk has overwritten. APFS keeps local snapshots, and Time Machine keeps more, each a point-in-time view you can mount and compare.

# Earlier states you can fall back on: APFS local snapshots
% tmutil listlocalsnapshots /
com.apple.TimeMachine.2026-03-13-235901.local
com.apple.TimeMachine.2026-03-14-010000.local

macOS also guards parts of its own evidence. The privacy layer known as TCC restricts access to protected stores such as mail and messages, so a collection tool may need Full Disk Access before it can read them. Whether you granted that access, and what the tool could and could not reach, belongs in the record. An incomplete collection because a tool lacked permission is a gap you want to find while you are still at the machine, not halfway through analysis.

Validate the tool against the version

You already know from 0.2 that artifacts shift between releases. The handling consequence is that you validate a parser against the specific macOS version in front of you before you trust its output. A tool tuned for Sequoia can silently misread a store that Tahoe reorganized, returning nothing or returning stale fields, and a finding built on that output inherits the error.

Validation is not elaborate. You confirm the tool's output against the native command or the raw store on a known-good sample of the same release, and only then trust it on the case. When the automated parser and the native tool agree, you proceed. When they disagree, the native output is usually the arbiter, and the disagreement itself is something you note.

A concrete case is a database whose table layout changed in Tahoe. Run a Sequoia-era parser against it and you can get an empty result that reads like nothing is there, when the data sits in columns the parser does not know to read. One check of the raw store with plutil or a SQLite browser catches that before it becomes a false negative in your report.

Corroborate across stores

The corroboration habit from 0.1 is an evidence-handling rule, not just an analytical preference. A finding resting on one macOS artifact is a lead. A finding corroborated by independent stores that record through different mechanisms is evidence. Because so few macOS artifacts stand alone, you build findings as multi-source from the start rather than bolting on corroboration at the end.

This shapes how you collect, too. If you know a finding will need the quarantine record, the log, and the persistence database to stand up, you make sure your collection captured all three. Evidence handling and analysis are not separate phases. What you choose to collect determines what you can later prove.

Say what the platform did not record

Here is the discipline that separates macOS work from a Windows checklist. When an artifact is missing, you owe the reader four distinct possibilities, not one conclusion: the activity did not happen, the OS version does not record it, retention rolled it off, or someone removed it. Collapsing those into "no evidence of activity" is how investigations overstate and later collapse under challenge.

Retention is the one you can measure, so measure it. Unified Logging keeps only a rolling window on disk, days to a few weeks depending on how busy the machine is, and you can read the real floor straight off the host.

# How far back does this Mac's on-disk unified log actually reach?
% log show --style compact --start "2026-02-01 00:00:00" | head -1
2026-03-07 08:12:44.110  loginwindow  Display asserted for user j.vance

You asked the log for everything since February 1. The earliest record it can return is March 7, so on this host the log reaches back about a week and is silent on anything older. That is the sentence the report needs: not "the log was clean," but "the log retains roughly this window, the activity predates it, so the log cannot speak to it." Naming what the platform did not capture is what makes the rest of the report trustworthy.

Confidence and defensibility

Attach a confidence level to every finding, and mean it. A definitive finding has multiple independent sources and no contradiction. A probable finding has one strong source and no contradiction, with the single-source limitation named. An inconclusive finding has ambiguous or conflicting evidence, and you say so rather than forcing a conclusion the data will not carry.

The language carries the confidence. "The binary executed at 02:14" states a fact you can defend. "The attacker exfiltrated the design files" asserts intent and an outcome you may not have proven. Write what the artifacts support, "a binary read the design directory and a network connection followed", and let the stated confidence carry the rest. Precise language is not hedging. It is the finding stated at the resolution the evidence actually has.

Putting it together for NE-VANCE-MBP, the limits statement is as much a part of the report as the finding. It says what the evidence carries, and it says plainly where the platform went dark.

Defensibility is the sum of all of this: intact evidence with a chain, tools validated against the version, conclusions built on corroboration, limits stated plainly, and confidence that matches the data. A brilliant analysis that cannot survive a challenge is not yet a finding.

Next: Section 0.6 walks setting up your analysis environment, the host, the case structure, and the toolstack, so you are ready to work real macOS evidence.