How macOS Endpoint Investigation Is Structured: Questions, Phases, Two OS Versions

You learned in 0.1 that a Mac keeps a different record than Windows. The layout that follows teaches you to read that record in the order an investigation actually needs it, and it carries two macOS versions at once because the Macs landing on your bench are a mix of both.

Estimated time: 20 minutes.

Built around the question, not the artifact

Most forensics material is organized by artifact. One chapter on the file system, one on logs, one on persistence. You finish knowing what each artifact contains and are left to work out how to combine them when a real Mac is in front of you. The layout here is organized by the question an investigator has to answer, and the artifacts are taught inside the question they serve.

That matters more on macOS than on a platform you already know. When the stores are unfamiliar, an artifact-by-artifact tour leaves you with a pile of names and no sense of which to open when an alert fires. Organizing by question forces the connection from the start: you meet the quarantine database because you are trying to prove where a file came from, not because it is the next item on a list. You learn the artifact and its job together.

The twelve content modules move through four phases, and the order is deliberate. Foundations come first, because you cannot read evidence whose shape you do not understand: the macOS security model and the architecture that decides where artifacts live. Acquisition and Unified Logging follow, because the first thing you do on an engagement is get analysis-ready evidence, and the log is the backbone the rest of the work hangs from.

The investigation questions then run in the order an intrusion tends to unfold: what is on the disk, what persisted, what ran and where it came from, what the user did, what crossed the network, and what a suspect binary is. Integration comes last. The timeline and anti-forensics modules pull the separate answers into one account, and a full capstone runs the whole method end to end against a compromised Mac.

Phrased as questions, the modules ask what the system's own security machinery records, how you acquire a Mac you cannot image, what the file system remembered, what an attacker installed to survive a reboot, what executed and whether Gatekeeper trusted it, what the user was doing, what left the machine, and whether a suspect binary is malicious. Each is a question a real engagement hands you, answered from evidence rather than asserted.

How a section works

Every content section follows the same rhythm, so once you can read one artifact you know how to approach the next. It opens with the threat, or the question the artifact answers, and shows you where the evidence lives and how it is structured.

Then it puts the normal and the malicious side by side, because you cannot spot the anomaly until you know the baseline, and walks the reasoning that tells them apart, including the false positives that trip people up. It shows the method against real output, and closes with the operational procedure where one applies.

One ordering rule holds throughout: evidence before method. You see the raw artifact a Mac produced before the command that parses it at scale, because the point is to learn what the evidence means, not to memorize tool flags. A command whose output you cannot interpret is not a skill. The reading is the skill, and the tool is how you reach it.

Take persistence as a preview. You do not meet the Background Task Management database as an abstract artifact. You meet it because you are asking what an attacker installed to survive a reboot, you have already checked the LaunchAgent plists, and you need the one store that records every background item the modern way. The question puts the artifact in your hands at the moment you would actually reach for it, with the reasoning that separates a malicious entry from the dozens of legitimate ones.

Two versions, on purpose

The material targets two macOS releases at once: Sequoia 15, the prior major version, and macOS 26 Tahoe, the current one. That is not hedging. It is the only honest way to teach a platform that changes its artifacts every year, and it matches the reality that you will examine both for a long time.

Establishing the release is one of the first things you do on any Mac, because it sets what you can expect to find. On a live system it is one command. On a collection you read it from the system version property list instead, and the build string alone tells you the major release.

# On a live Mac, the release is one command
% sw_vers
ProductName:        macOS
ProductVersion:     26.0.1
BuildVersion:       25A362
# On an image, read it from the system version property list
% plutil -p "/Volumes/NE-VANCE-MBP/System/Library/CoreServices/SystemVersion.plist"
{
  "ProductName" => "macOS"
  "ProductVersion" => "26.0.1"
  "ProductBuildVersion" => "25A362"
}

The build prefix is the fast read. A 25-series build like 25A362 is Tahoe; the finance laptop on Sequoia reports a 24-series build such as 24G231. Once you know the release, the version notes through the course tell you which artifacts to expect, which behave differently, and which simply will not be there.

The failure mode is concrete. A tool tuned for Sequoia may parse a database whose schema Tahoe reorganized and return nothing, or worse, return stale fields as if they were current. An examiner who does not know the release reads that empty result as no activity. An examiner who checked the build first knows to validate the parser against Tahoe before trusting it.

When a difference matters, the section says so. When an artifact behaves the same on both releases, no note appears and you can treat it as stable.

Fieldcraft and how to use the material

Two recurring elements are specific to this material. A version note appears wherever Sequoia and Tahoe differ in where an artifact lives, what it contains, or whether it exists at all. A Fieldcraft card gives the operational procedure for artifacts that have one: the tool, the command, the expected output, the decision it supports. Not every section has a card, only those with a concrete procedure you would run on a real Mac.

The Fieldcraft cards are pitched for someone who has done forensic work before and needs the exact macOS syntax, not a beginner walkthrough. A card in the Unified Logging module, for instance, gives the predicate syntax to pull authentication events from a log archive and the output to expect, so you are not assembling it from scattered documentation mid-incident. Collected, the cards become a reference you carry onto engagements.

Two reference modules and a capstone close things out. The reference modules consolidate the commands, artifact locations, and version differences into something you search mid-engagement. The capstone hands you a fully compromised Mac and no scaffolding: you acquire, read, correlate, and produce a findings package with a timeline and stated confidence.

Work the material actively. When a section poses its investigation question, try to answer it from the evidence shown before you read the reasoning, and when a Fieldcraft card gives a procedure, run it against a Mac or an image you control. The procedures you have actually executed are the ones you will trust under pressure.

Next: Section 0.3 covers the toolstack you use throughout, what each tool is for, and why the analysis stack is open-source.