What macOS Endpoint Investigation Is: The Evidence a Mac Keeps

Introduction

Published best practice states that an administrator's password is now required to acquire a modern Mac, and names the single remaining exception: an Intel machine without the T2 chip and without FileVault enabled.

That one sentence is this course in miniature. The moves a Windows examiner reaches for first are, on current hardware, foreclosed before the machine is touched, and two of them fail quietly enough to cost a day before anybody notices.

So this section is about which doors are actually open. Not the artifacts yet, and not the tooling, but the question you settle before either of those matters: given this machine, what can be collected at all?

Start with the move that a decade of Windows work makes automatic, because it fails for a reason that governs everything after it. Published description is direct about the hardware: the storage in modern machines is soldered to the board, so traditional imaging methods are often not possible, and removing the storage is not enough on its own because the keys live elsewhere.

WHERE THE PARTS OF THE ANSWER ACTUALLY LIVE

  the ciphertext      on the internal storage, soldered down
  the encryption key  derived inside the Secure Enclave, on the chip
  the passphrase      with a person, who may not be cooperating

  taking the storage  gets you one of the three

Read the block as three separate components rather than as one asset to be seized. The ciphertext sits on the storage, the key is derived inside the chip, and the passphrase is with a person who may not be cooperating, so the classic seizure collects exactly one of the three.

Published description states the data on built-in storage is encrypted by an engine using a key tied to a unique identifier inside the Apple Silicon or T2 module. The storage and the key are separated by design rather than by accident, and that separation is not a security feature that happens to inconvenience examiners. It is the reason this exists as a discipline of its own rather than as a chapter in a Windows course.

It also changes what seizure is for. On a platform where the drive can be read elsewhere, taking the machine is a way of taking the data; here it is a way of taking the machine, and the data comes with it only if the credential does. That reframing is worth carrying into the first conversation with whoever is handing the device over, because the question that matters is not where the laptop is but who can unlock it.

It is worth asking that question while the people who know the answer are still in the room. Custodians go on leave, administrators change, and the window in which somebody can simply tell you the escrow position is usually the first hour rather than the second week. Nothing about the hardware gets easier with time, and the human side of it reliably gets harder.

Which raises the question of what enabling FileVault actually adds, because people speak as though it is the only encryption in play. Published description separates the two states clearly: modern machines encrypt all data at rest whether or not FileVault is enabled, with the keys tightly bound to the hardware and managed by the Secure Enclave, a separate coprocessor built into the chip.

So a machine with FileVault switched off is still an encrypted machine. Enabling it encrypts the user data volume and requires valid authentication to decrypt it, which means the distinction is not between encrypted and unencrypted machines at all. It is between a machine whose encryption nobody chose and one that additionally requires a credential somebody holds.

Read the three values in the examiner and say which acquisition paths remain available before scrolling on. The value of the FileVault line is the credential it implies rather than the encryption it announces, which is the reading most people get backwards on first encounter.

The distinction has a practical edge in the first minutes of a response. A machine reported as not encrypted is still a machine whose contents are bound to its chip, so the instinct to relax about imaging it is wrong, and a machine reported as encrypted is not thereby unreachable if the credential is escrowed or the user is cooperative. Both readings are common and both send a responder down the wrong path before anybody has looked at the hardware.

The correct order is the dull one: read the chip, read the encryption state, then ask about the credential, and form a view after all three rather than after the first. Each of those is a single command or a single question, and taken together they cost less time than the argument that follows from guessing.

The move a responder makes when the disk cannot come out is to boot the machine from a prepared external volume and image it from there, and published best practice forecloses that in one line for current hardware: machines with Apple Silicon will not boot from external media unless that media is signed by Apple.

THE EXTERNAL-BOOT PATH, BY HARDWARE

  Apple Silicon    will not boot external media unless Apple-signed
  Intel with T2    generally will not, unless secure boot is lowered
                     in the recovery Startup Security Utility, and
                     System Integrity Protection may also need turning off
  Intel, no T2     the case published practice names as the exception

  lowering security is a change you made to the evidence machine

Read the block as three hardware cases and the path each one leaves open. An Intel machine with T2 generally will not boot external media unless the examiner lowers the secure boot level in the recovery Startup Security Utility, and System Integrity Protection may also need turning off first.

That Intel row is worth reading twice. The path exists, and taking it means altering the security configuration of the machine you are about to call evidence, which is a decision to record rather than a step to perform quietly. Published description of the system volume adds the other half: a signed system volume verifies cryptographic signatures at boot and is mounted read-only, which prevents processes, forensic tools included, from reaching protected areas without proper credentials.

There is a planning consequence worth drawing out. If prepared external media is only useful on a subset of hardware you may not encounter, the decision about what to carry to a scene should follow from the fleet rather than from habit. An estate of Apple Silicon laptops makes that media dead weight, and the equipment worth carrying instead is whatever supports collecting from a machine that is already running. That is a different kit and a different set of skills, and deciding which one the estate needs is a conversation to have before an incident rather than in the car on the way to one.

The same reasoning applies to the Intel exception rather than dismissing it. Older hardware persists in most estates for years, so the path is worth knowing even where it is rare, and the thing to record when you take it is what you changed and why. A lowered secure boot level on an evidence machine is defensible when it was the only route and it was written down, and indefensible when somebody finds it later with no explanation attached.

All of which assumes the failures announce themselves, and the third one does not. Published commentary states the position plainly: a drive image can be technically complete and still unreadable without valid keys or credentials. The acquisition reports success, the hash verifies, and the artifact is ciphertext.

Three true statements, and the claim none of them makes.

Read the pairs across rather than down, because the left column is what a report will quote and the right is what the evidence actually supports.

Read the rows across rather than down, because both columns describe the same operation. A verified hash proves the copy is faithful, which is a different claim from the contents being readable, and the gap between those two columns is where a day disappears.

So the credential question is not a step inside the acquisition at all. Published description is explicit that data is acquirable while remaining encrypted, and published practice states that without the password or recovery key acquisition is limited or completely impossible. It comes before the acquisition, because its answer decides whether the acquisition is worth performing: establish whether the password or a recovery key can be obtained, and from whom.

Asking early also costs nothing and occasionally changes everything. Where a machine is managed, the credential may be escrowed and obtainable by an administrative request rather than from the user at all, which is a different conversation with a different timeline. Where it is not, the answer may be that nobody has it, and knowing that on the first day means the effort goes into the paths that remain instead of into an image nobody will be able to open.

Those remaining paths are real rather than consolation. Account-side records held by a provider, management-server records held by whoever enrolled the device, and backups taken elsewhere all survive a machine nobody can decrypt, and each of them is a request with a lead time. Starting those requests on the day the credential question is answered no is what keeps the investigation moving.

One further matter concerns what you point the tool at, and it is the kind of detail that costs a re-collection. Published tool documentation states that acquisition aimed at an individual volume will fail because of the container architecture, and that full container imaging is what a sound collection requires.

The volumes share metadata, which is why one of them alone is not collectible.

With the shape settled, the next question is where to point the tool. The volumes share the container metadata, so one of them alone is not a coherent thing to take, and a tool aimed at a single volume fails on the architecture rather than on the data.

# List the containers and the volumes inside each one
% diskutil apfs list

# Confirm which physical disk holds the system and data volumes
% diskutil list

Published guidance adds a check worth building into the collection. Machines frequently carry several containers, including separate ones for recovery and preboot, so confirming afterwards that you captured the intended one is part of the collection rather than an optional extra.

The check is cheap and the failure it catches is expensive. A collection that captured a recovery container instead of the system one looks complete by every measure a tool reports: it has a size, it has a hash, and it finished without error. Discovering that at analysis rather than at collection means going back to a machine that may no longer be available, which is the same class of problem as the unreadable image and arrives by a different route. Both are collections that report success and deliver nothing, and both are prevented by a check that takes a minute at the point of collection.

The pattern is worth naming because it recurs throughout this course. Several of the ways a macOS collection fails produce output that looks exactly like success, so the habit that protects you is verifying the thing you actually wanted rather than the thing the tool reports. Opening the image and confirming the volumes are present is the version of that habit which belongs here.

There is one more constraint and it applies after every question above is settled. Published description states that forensic tools require Full Disk Access to do their work, and that without it some artifacts remain inaccessible, so the operating system restricts reaching sensitive locations regardless of the account running the tool.

# The two states that decide the acquisition path, before anything is collected
% csrutil status
% fdesetup status

Run both of them before deciding anything at all about the collection. System Integrity Protection restricts changes to system files even for the root account, so an examination running as an administrator is still a restricted examination, and the two constraints apply separately rather than as one.

The practical consequence is that a tool reporting a clean run may simply never have seen the locations it could not reach. Absence of a finding and absence of access are different things, and only one of them is visible in the output, which makes the access position something to establish and record rather than assume.

That also decides how you read an empty result later. A search that returns nothing from a protected location is ambiguous between the location being empty and the tool never having reached it, and the only thing that separates the two is knowing what access the tool held when it ran. Recording that at the time is trivial; reconstructing it afterwards is usually impossible, because nobody remembers which grants were in place on which afternoon. A line in the notes at the time settles a question that would otherwise be argued about later with no evidence on either side.

Granting the access is also a change to your own machine, which is worth noticing even though it is entirely routine. It is not a change to the evidence, so it carries none of the weight of altering a subject machine, but it does belong in the record of how the examination was conducted rather than being assumed as a default state of the workstation.

By this point the division is clear enough to write down, and writing it down before touching a machine is the habit this section exists for. The question is not which acquisition is best but which are available on this hardware, in this state, with the credentials you actually hold.

Each condition closes or opens a route, and the third can close all of them.

Read the rows as four separate questions rather than a checklist, because each is answered from a different place and only one of them needs a person to hand you something.

Read the rows as four separate questions asked in one fixed order, because each one narrows the next. Establishing the chip first is what stops somebody preparing external media for a machine that will never boot it, and reading them by preference rather than in order wastes that narrowing.

The live path deserves its own note. Published practice records that an examiner meeting a live, unlocked machine may still obtain a limited live acquisition, and the word doing the work in that sentence is limited. A machine found unlocked offers a path that a powered-down one does not, which is why the state of the machine on arrival belongs in the first four lines rather than in a note added later.

It is also the line most likely to change between the incident and your arrival. A machine that was unlocked when somebody found it will not be by the time it reaches you unless somebody kept it awake deliberately, and whether that instruction was given is part of the record. The difference between a limited live acquisition and no acquisition at all frequently comes down to a decision somebody made in the first ten minutes without knowing it mattered.

That is an argument for telling people in advance rather than instructing them during. A first responder who knows not to close the lid, not to shut down and not to let the machine sleep has preserved a path that no amount of later expertise recovers, and the instruction is short enough to fit in a single line of a runbook.

One matter remains, and it is what all of this looks like in a report somebody else reads. State the hardware, the encryption state and the credential position at the point you establish them, not in a limitations paragraph at the end.

THE OPENING PARAGRAPH OF A MAC EXAMINATION

  hardware      the chip, because it decides the boot paths
  encryption    on by default here, and whether FileVault applies
  credential    held, requested, or refused, and by whom
  path taken    and the ones the hardware foreclosed

  everything after this is read against those four lines

Read the block as the four lines a Mac examination opens with. The hardware line names the chip because it decides which boot paths exist, the encryption line says that it applies here by default and whether FileVault applies on top, and the credential line says held, requested or refused, and by whom.

A constraint recorded up front is a scope statement and the same constraint recorded at the end reads as an apology. Naming what was foreclosed is not a hedge: a reader who knows the platform will ask what the hardware ruled out, and a report that answered before being asked is the one that survives the question.

The same four lines are also what let somebody else pick the work up. An examination handed over mid-case with the hardware, the encryption state, the credential position and the path taken written down is one the next person can continue; the same examination without them starts with a day of rediscovery, and some of what they rediscover will be a machine whose state has moved since. The four lines are cheap to write while the answers are in front of you and expensive to reconstruct once they are not, which is the same argument as everything else in this section.

Written early, they also shape the rest of the report by giving every later finding something to be read against. A conclusion about what a machine held means one thing when the reader knows a full container image was taken with the credential in hand, and something quite different when they know the collection was a limited live acquisition from an unlocked machine. The same sentence carries different weight, and the four lines are what tell the reader which weight to give it.

The four lines above take about a minute to establish on a machine you own, and doing it once is what makes doing it under pressure automatic.

Published best practice states that an administrator's password is increasingly required to acquire a modern Mac, naming an Intel machine without T2 and without FileVault as the likely exception, and that without the password or recovery key acquisition is limited or impossible. Modern machines encrypt data at rest whether or not FileVault is enabled, with the key tied to an identifier inside the chip, so removing the soldered storage collects the ciphertext and leaves the key behind. Machines with Apple Silicon will not boot external media unless it is Apple-signed. An image can be technically complete and still unreadable. Published tool documentation states that volume-level acquisition fails on the container architecture, and that forensic tools need Full Disk Access or some artifacts stay out of reach.