Where macOS Endpoint Investigation Is Used: IR, Insider Cases, Malware, eDiscovery

Introduction

Most endpoint evidence records what happened. A Mac running the current release records something narrower and considerably more useful: what the person chose.

That difference decides whether this platform is worth learning for the cases that turn on a person rather than on malware. A deletion is an action, and any number of things on a running machine delete files. Selecting Move to Trash and then Empty Trash is a decision taken twice, by somebody sitting at the keyboard, and only one kind of record captures the second thing.

This section is about that distinction, the two stores that arrived with it, and the discipline that stops a record of a choice becoming an assertion about a state of mind.

A filesystem record establishes that something happened, and that is genuinely less than it sounds. Applications write and delete constantly, sync clients reconcile folders without anybody watching, and installers create and remove working directories as a matter of course. So the record of a folder appearing and disappearing inside forty minutes is consistent with a person acting deliberately and equally consistent with software doing its job, and nothing in the record itself separates the two. The scenario's report cited a deletion and concluded a decision, which is a step the evidence did not license. It is worth being precise about the size of that step: the report was not wrong about the deletion, which plainly happened, but about who the deletion was attributable to, and that is the harder half of almost every finding in this course. Occurrence is usually settled by one record; attribution is usually settled by several, read together, with the innocent explanations closed off one at a time.

TWO RECORDS OF THE SAME DELETION

  the filesystem      the folder existed, then it did not
                        true of a user, an installer, a sync client

  the interaction     a person selected Move to Trash
                        then, separately, selected Empty Trash

  one is an event, the other is a decision taken twice

Read the block as two records of one deletion rather than as two separate events, because that is what they are. Published description of the newer interaction store draws the line explicitly: where filesystem logs record that a file was deleted, the interaction record shows the deliberate sequence of actions and supplies the human context behind the technical event.

The phrase worth carrying out of this section is the human context. Intent is a claim about a person, and a claim about a person needs a record of a person choosing rather than a record of a change occurring. Everything that follows is about where such records exist on a Mac, how to reach them, and how far they can honestly be pushed. The order matters: a store you cannot reach is not evidence, a store no tool reads is not evidence either, and a store you read too generously is worse than none of it.

Published research describes a stream introduced in macOS Tahoe 26 that logs the specific menu items a user selects across the operating system, capturing the exact text of each selection alongside the timestamp of the activity. It is not scoped to one application; it records the choice wherever the choice was made, which is what turns a list of commands into a sequence you can lay against other evidence. A single selection in isolation is close to worthless; the same selection in a run of five, with the gaps between them visible, is what lets you argue about deliberation. Eight seconds between a copy and a paste reads differently from eight minutes, and neither figure means anything without the other selections around it.

The examiner above holds eighty-one seconds of those records, taken from the window the scenario asks about. Read the sequence and commit to what it supports before scrolling on, because deciding first is what the exercise trains rather than something incidental to it.

Two things about that run are worth noticing before you work it. The commands appear in the plain language a user would have seen on a menu, not as internal identifiers, so the record is legible without a lookup table. And a short run is far easier to reason about than a full day of activity, which is a practical argument for pulling a narrow window rather than everything and filtering afterwards.

The stream belongs to a wider framework worth knowing by name, because it explains why the format is unfamiliar. These activity streams began on the mobile platform several releases ago and expanded steadily until they largely replaced the older behavioral database, and a modern device carries well over a hundred defined streams, each tracking one kind of activity in its own directory. The menu-selection stream is one recent addition to a long-established arrangement rather than a new mechanism, which is why the tooling to read it already existed when the stream appeared.

Reaching the stream is where this stops being a click in a commercial suite. It sits in the user's own activity directory under a restricted streams path, inside the home directory rather than anywhere system-owned, and it is stored in the segment-based format that wraps protocol-buffer records with metadata and integrity structures. Neither half of that is hostile, but both mean the store will not open in anything that expects a database or a property list. The name of the format comes from the four bytes at the head of every such file, which spell it out literally, and the format has never been publicly documented by the vendor, so the community named it after those bytes and the name stuck.

# The stream on a mounted image, under the user's activity directory
% cd "/Volumes/NE-VANCE-MBP/Users/j.vance/Library/Biome/streams/restricted"
% ls -l App.MenuItem/local

# Extract the records with the open-source parser, then review as text
% python ccl_segb_cli.py App.MenuItem.local > menuitems.txt

Locating the stream is the step people skip, and it costs nothing once you know the path. Published description names the same open-source parser as the extraction route and describes converting its output into a form you can filter, which is what makes a long run usable rather than merely available. Neither command alters the store it reads.

There is a detail inside the directory layout that bears directly on attribution, and it is easy to walk past. Each stream separates what it holds into local and remote, where the local side carries records from the machine in front of you and the remote side carries records synced from other devices signed in to the same account. Reading a record without noticing which side it came from is how an examiner attributes another device's activity to the machine on the desk, and the distinction costs one glance at the path.

One thing about the stream's origins is worth holding onto, because somebody will eventually ask. Published research puts its likely purpose as adaptive interface behavior, suggestion or behavioral learning rather than auditing. The forensic value is a side effect of a feature built for something else entirely, which is a useful thing to be able to say plainly when the question of whether the user consented to being recorded this way comes up.

All of which assumes an ordinary examination would surface the store, and published testing says otherwise in plain terms. In that testing the artifact is not parsed by the most common commercially available forensic tools, so a standard processing run across a current-release image will complete cleanly and never list a single one of these records. Nothing in that run reports a gap, because from the tool's point of view there is no gap to report. The plugin list will show every plugin it ran, all of them successful, and the store that mattered simply never appears in the inventory of things considered.

Absent from a report and absent from the machine are three decisions apart.

Read the dashed arrow as the step that does not follow, because everything else in the diagram is sound and that one inference is where reports go wrong.

Read the rows across rather than down, because both columns describe the same run. The first row is the practical one, and it is the same failure this course keeps returning to: a tool that cannot read a store produces silence rather than a warning, so an unread store and an empty one look identical in the output.

There is a second-order reason to care, beyond your own thoroughness. A store that answers the intent question is one the opposing examiner has every reason to open, and published guidance urges examiners working current-release images to verify whether the artifact is present and fold that check into standard workflow. Being the party that did not look is a poor position to discover late.

The format itself has a wrinkle that decides whether an older parser succeeds. The container has gone through more than one revision, and the later one added a trailer section that has to be parsed for the file to be read correctly, so a tool written against the earlier revision may fail or, worse, return a partial read. A parser that handles both without being told which it is looking at is the one to prefer, and confirming that a run reached the end of the file is a cheap guard against a truncated result presented as a complete one.

A second change arrived in the same release and altered something long assumed settled. Published description records clipboard history appearing in macOS 26 as a persistent list of recently copied items, searchable through the system search interface, and Apple's own release notes confirm a clipboard view sitting alongside applications, files and actions.

The same question gets a different answer on either side of one release.

Setting the two releases side by side shows how completely the answer moved.

THE CLIPBOARD QUESTION, BY RELEASE

  before macOS 26   most recent item only, in memory
                      the honest answer was nothing to recover

  macOS 26 onward   a persistent list, on disk, searchable
                      text, document snippets, command output

the same question, two answers, one release apart

Published description is specific about what changed. Previously clipboard content was limited to the most recent item and generally stored only in memory; now the data can be recovered from disk and may include copied text, snippets from documents, or command-line output. A question that honestly answered nothing to recover a release ago now answers differently. That is a rare direction of travel on this platform, and it is worth enjoying while noting that the same release moved other things the other way.

An examiner carrying the older assumption would not think to look, and that is the shape of most failures on this platform. Not a wrong technique, but a correct technique aimed at a release that no longer exists. The assumption was true when it was learned, which is exactly what makes it expensive.

The practical consequence for a live examination is worth stating separately. Because the clipboard list is reachable through the same search interface the user uses, a responder working on an unlocked machine can see it without any specialist tooling at all, which makes it one of the few stores in this course that rewards looking during the first ten minutes rather than after the image is taken. What is visible there is also what the user could have seen, so nothing about reading it requires explaining an exotic technique to a reader later.

An orientation that reported only the gains would be selling something, and the same release cuts the other way as well. Published analysis notes that rather than introducing broad new data sources, the platform selectively expands what is available while redefining how data is stored or accessed, with some communication data restructured and in some cases not retained at all.

THE RELEASE CUTS BOTH WAYS

  gained    a record of menu selections, with timestamps
  gained    clipboard contents recoverable from disk

  lost      some communication data restructured
  lost      some of it not retained at all

an orientation that reported only the first half would be selling something

Two of those four lines run against you. Reading a release as a net gain is how an examiner ends up searching for a store that was quietly removed, which wastes a day and produces an absence that means nothing. An absence you cannot interpret is the most expensive kind of result, because it consumes the time of a finding without supporting one.

The same analysis states the direction plainly: many of the most powerful new features are designed to avoid creating traditional artifacts, and that trend is expected to continue. Features that leave no artifact are not an oversight on the vendor's part; they are the stated design direction, and an examiner who expects each release to hand them something new has misread which way the platform is moving. So the two changes in this section are not evidence that the platform is becoming easier to examine. They are evidence that it is becoming different to examine on an annual cycle, and that what was true last year is a thing to verify rather than a thing to carry.

That argues for a specific habit rather than general vigilance. Each time a major release lands, take one machine running it and check the stores this course names: whether each is still where it was, whether it still holds what it held, and whether the parser you rely on still reads it end to end. An afternoon spent that way once a year is the difference between discovering a change in your own time and discovering it in the middle of a case with a deadline attached.

The cases this actually decides are the ones that turn on a person. A departing employee and unreleased files is the standing example, a policy investigation asks the same question in a different frame, and an account takeover asks whether the account holder or somebody else was at the keyboard. In each of them the contested point is authorship rather than occurrence. Nobody disputes that the file moved; the argument is about whose hand moved it, and that is precisely the question a record of a menu selection speaks to.

WHAT EACH RECORD LETS YOU SAY

  filesystem event      a change occurred, at a time
  application focus     an application was frontmost, for an interval
  menu selection        a person chose a named command, at a time
  clipboard entry       material was copied, and what it was

  the last two are the ones that speak to a person's choices

Read the block as four different widths of claim rather than as four artifacts. Building a finding means picking the narrowest width the evidence actually supports, and in a case about a person the standing temptation is to reach one row further than the record allows. Application focus establishes an interval, not a choice; a menu selection establishes a named command chosen at a time.

Malware cases use the same reading in reverse. Where the question is whether a person did something or a process did, a record of a deliberate selection at the moment in question is what separates the two, and its absence during an otherwise busy window is itself informative. The evidence does not change; the direction you read it in does.

One caution applies to every case in that list. A record of a selection places a choice at the interface, which is not the same as placing a named individual at the keyboard; it establishes that somebody with access to that session made that choice. Bridging from the session to the person is separate work, resting on who held the credential, who had physical access, and what the machine's own state says about being locked or unlocked at that moment. Reports that skip the bridge tend to be the ones that do not survive.

A claim about intent is the most challenged kind there is, so the way it is written matters as much as the records behind it. Say what was selected, when, and in what sequence, and let the sequence carry the argument rather than asserting a state of mind. Two deliberate selections a few seconds apart make a stronger statement than any adjective you could attach to them.

AN INTENT FINDING, IN FOUR PARTS

  the records       what was selected, and at what times
  the sequence      the order, and the gaps between them
  the corroboration the filesystem or log record of the same event
  the alternative   what else could produce this, and why it is ruled out

  the fourth is what a challenge goes after first

Read the block as the four parts of an intent finding. The corroboration line ties a selection to an independent record of the same event, and the fourth is the one most reports omit and every challenge reaches for first. Writing it takes two sentences and its absence is the single most common reason an otherwise sound intent finding comes apart under scrutiny.

Name the alternatives explicitly. An automated action driving the interface, a change synced from another device on the same account, and a second person at a machine left unlocked are all ordinary rather than exotic, and at two in the morning on a corporate laptop the last of those deserves an answer rather than a silence. A finding that names them and says what rules each in or out is substantially harder to challenge than one that leaves the other side to raise them on your behalf.

The second alternative has a concrete check behind it rather than only a caveat, which is why it is worth naming first. Because these streams separate local records from records synced in from other devices on the account, the path a record was read from speaks directly to whether the activity happened on this machine. An examiner who can say the sequence was read from the local side has closed the synced-from-elsewhere explanation with evidence rather than with assertion, and that is a materially stronger position than a report that simply does not mention it.

The stream is present on any machine running the current release, and reading back your own selections from this morning is the fastest way to understand both what it proves and what it does not.

Published research describes a stream introduced in macOS Tahoe 26 that logs the specific menu items a user selects across the operating system with timestamps, stored in the segment-based format under a restricted streams path in the user's activity directory and extracted with an open-source parser, its forensic value a side effect of a feature likely built for adaptive interface behavior. Published testing states the artifact is not parsed by the most common commercially available forensic tools, so its absence from a processing run is evidence about the process rather than about the machine. Clipboard history arrived in the same release as a persistent list recoverable from disk, where previously the clipboard held only the most recent item in memory. Published analysis also records the countervailing trend: many of the most powerful new features are designed to avoid creating traditional artifacts.