What is a forensic triage artefact set, and how does it differ from a full disk image?

## The two things being compared A **full disk image** is a bit-for-bit copy of a storage device, sector by sector, including regions the filesystem no longer references: deleted files not yet overwritten, file slack, unallocated space, and in some cases host-protected areas. Nothing is selected, so nothing is missed - which is exactly why it is expensive. Acquisition speed is bounded by the device and the interface; a 512 GB laptop drive is typically hours, and you then own an image of that size for the life of the case, plus the processing time to index it. A **triage artefact set** (also called a triage collection, or forensic triage) is a *selective* copy of named, high-value artefacts taken from a running host. A typical Windows profile pulls the Security, System, Application, PowerShell and Sysmon event logs; the MFT and USN journal (filesystem metadata, which tells you a file existed and when even if its content is gone); prefetch and other execution evidence; registry hives carrying run keys, services and installed software; scheduled task definitions; shell and browser history; and a process, service and network snapshot taken at collection time. On Linux the equivalent is `/var/log`, audit logs, shell histories, cron and systemd unit files, package state and process listings. The set is packaged - usually as a single archive with a manifest - and shipped to your analysis store. ## Why you would ever choose the lossy option Because the first question in a wide incident is almost never *what exactly happened on this one box*. It is *which boxes are in scope at all*. If a third-party application was granted a mail-read scope across your tenant after a consent lure, you do not know how many of your endpoints saw the lure or what else the user ran afterwards. You cannot answer that by imaging; you answer it by pulling the same small profile from every endpoint in parallel and looking for the outliers. The arithmetic is what makes the decision, and it is worth being able to say out loud in an interview: | | Full image | Triage set | |---|---|---| | Time per host | Hours | Minutes | | Size per host | Hundreds of GB | Tens-hundreds of MB | | Hosts you can do at once | One, maybe a few | The whole estate | | Deleted / unallocated data | Yes | No | | Anything not in the profile | Present | Gone | | Host must be taken out of service | Usually | No | ## What you are actually giving up Be precise here, because this is where candidates overclaim in both directions. - **You lose unallocated space and file slack.** Deleted-file *content* is generally not recoverable from a triage set. You often still see that a file *existed*, because filesystem metadata such as the MFT and USN journal is collected and survives the file itself. - **You lose anything the profile did not name.** A profile written before the case cannot anticipate a case-specific artefact - an application log for a niche product, a particular user directory. Good tooling lets you extend the profile per case; that is a decision, not a default. - **You do not lose defensibility.** A triage collection is ordinary digital evidence: it is admissible if you can say what you collected, when, from where, with what tool, and can show the copy is unchanged since. Selectivity is a *completeness* limitation you disclose, not an authenticity defect. The common wrong answer is that triage output is somehow not `real forensics`. - **Collection is not free of footprint.** Anything you run on a live host writes to that host and changes volatile state. That is a known and accepted cost of live collection, and it is the reason your notes must record exactly what you ran. ## How the two fit together in practice The normal shape of a large investigation is a funnel. A wide triage sweep across the estate produces a small set of hosts with something interesting. Those hosts get deeper treatment - a fuller collection, memory, or a genuine image - and that is where the expensive, complete acquisition is justified because the population is now small. Running it the other way round - insisting on images first - fails in two ways at once: it is too slow to scope the incident before the adversary acts again, and it burns your responders on 899 machines that turn out to be irrelevant. The judgment an interviewer is testing is whether you understand that *completeness per host* and *coverage across hosts* are competing goods, and that early in an incident coverage usually wins.