What footprint does running a live collection tool leave on the host you are collecting from?

## Observation changes the observed A live collection is executed *by the machine you are investigating*. There is no way to read a running system's memory without being a process on that system, so the tool becomes part of the evidence. Candidates who have only done offline work are often surprised by this; candidates who have done live response plan for it before they touch the keyboard. ## Where the traces land **Execution artefacts.** Starting a binary produces a process-creation record — Windows Security event ID `4688`, or Sysmon event ID `1` where Sysmon is deployed. On a Windows client with Prefetch enabled, the first run of an executable creates a `.pf` file under the Prefetch directory recording that it ran and when. If your collector installs itself as a service, the System log records event ID `7045`, 'A service was installed in the system' — the same artefact class investigators look for as a persistence indicator. **Device artefacts.** Attaching a USB drive writes device-installation records into the registry and the setup logs. Those entries look exactly like an intruder's exfiltration media unless someone wrote down that they are yours. **Filesystem metadata.** Reading files updates access-related metadata on some configurations; opening directories in a graphical shell touches more than you think. This is a strong argument against 'just having a quick look' before the capture. **Memory.** Your process asks the allocator for pages, and the allocator hands over pages that are currently free. Free is not empty: those pages may still hold the remains of a process that exited, a decrypted buffer, or key material. A large, feature-rich collector can overwrite the very thing you came for. This is why single-purpose tools with a small resident footprint are preferred, and why running six utilities 'to be thorough' is a bad instinct. **Output.** The avoidable half. Writing an image or an artefact archive to the source volume consumes free space and overwrites unallocated clusters that may hold deleted evidence, and grows a file on the volume you are about to acquire. Write to attached external media, or stream over the network to a collection host. ## The defence is documentation, not stealth There is no zero-footprint live collection, and pretending otherwise is a red flag. The standard the work is judged against is whether the change you caused is understood, minimised and recorded. Practically that means a contemporaneous log capturing, for every action: wall-clock time, what was run, its full path and hash, the media it ran from, the account it ran under, and where the output went. Mistakes go in the log too — 'at 02:44 I double-clicked the wrong folder' is far more valuable than a tidy account written from memory two days later. That log is what lets an examiner subtract the responder from the timeline. Without it, a Prefetch entry and a service installation timestamped inside the incident window are indistinguishable from intruder tooling, and any conclusion resting on them can be argued away. ## Choosing the tool before the incident The footprint is a property you should know in advance, not discover at 03:00. A prepared team has an approved collection kit, knows what it writes and where, has it on prepared external media, and has practised running it. The alternative — downloading something onto the compromised host and running it from the local disk — combines the largest possible footprint with the smallest possible confidence in what the tool actually did. ## The trade-off in one line Every live collection destroys some evidence in order to preserve evidence that would otherwise be destroyed anyway. That trade is worth making, and it is only defensible if you can say precisely what you did.