0.1 What Remote Live Collection Is

You already know the shape of the problem. Something fires, the host is three floors away or three time zones away, and the distance between wanting evidence and holding it is measured in travel, shipping, or waiting for somebody to answer a phone.

Two problems, and which one you have

Almost every investigative tool answers questions about evidence you already possess.

A forensic parser reads an image somebody acquired. A search platform reads logs that were shipped to it before you asked. Both are excellent at what they do, and both share a limitation: the moment you need something nobody thought to collect in advance, you are back to physically reaching the machine.

Remote live collection changes which of those two problems you have. An agent sits on the endpoint holding a connection to a server you operate. When you want something you send a question, and the agent answers it from the live system: read this registry key, parse this artifact, list the processes with these characteristics, retrieve this file. Nothing had to be shipped in advance, because the endpoint itself is the store and it is reachable on demand.

That is a genuinely different proposition from centralized logging, and the difference is worth being precise about. Centralized logging decides in advance what might matter and pays to keep all of it forever. Remote live collection stores nothing in advance and pays a small cost per question, at the moment you ask. Most mature environments run both, because each covers the other's weakness: the log pipeline answers questions about a machine that has since been rebuilt, and the agent answers questions nobody anticipated.

Which you reach for is decided by the question rather than by preference. Anything about a period that has passed on a machine that may no longer exist belongs to the pipeline. Anything about what a specific machine looks like right now, in detail nobody thought to ship, belongs to the agent. Investigations routinely need both within an hour of each other, and knowing which one a question belongs to is most of what makes an analyst quick.

What actually changes

The obvious change is speed, and it is not the important one.

The important change is which questions are worth asking. When reaching a machine costs a day, you ask few questions and you make each one count, which means you ask the questions you already believe you know the answer to. When it costs ten seconds, you ask the cheap question first and let the answer tell you what to ask next.

That difference compounds across an investigation. An analyst who can ask ten cheap questions in the time it used to take to ask one will follow leads that would otherwise have been dismissed as not worth the effort, and the lead nobody follows is where intrusions survive.

It also changes who can ask. When each question costs a day of somebody's time, questions get rationed by seniority and the junior analyst with a hunch does not get to test it. When a question costs ten seconds, testing a hunch is cheaper than discussing whether it is worth testing, which is a quiet but substantial change in how a team works.

The second change is scale. Asking one machine and asking eight hundred are almost the same action, which turns a question into a survey. That capability has its own discipline, because a question that is cheap on one host is not automatically cheap on the estate, and this course spends two modules on exactly that.

-- The whole proposition: a question, answered from the machine's own
-- live state. Nothing was shipped and nothing was imaged.
SELECT Pid, Ppid, Name, Username, CommandLine, Exe, CreateTime
FROM pslist()
WHERE Name =~ "(?i)powershell"

Nine seconds, on a machine three floors away or three time zones. Everything else in this course is about what that answer does and does not establish.

The condition everything rests on

There is one requirement and it is absolute: the agent has to have been there before the incident started.

This is not a footnote. It is the single dependency the entire proposition sits on, and it is the reason deployment is treated in this course as an engineering exercise rather than as an install step.

A team that evaluates the tool, agrees it is impressive, and files it as something to stand up when a real incident arrives has bought nothing. The incident arrives, somebody spends the first three hours building a server and pushing agents through the software deployment system, and the agents land on hosts that a helpdesk technician has already rebooted or reimaged. The capability that justified the tool, which is reaching a machine you did not plan to care about, only exists if the deployment predates the surprise.

There is a partial answer for machines with no agent, which is a standalone collector you build in advance and hand to somebody. It is genuinely useful and it is single-shot: it runs, it writes, it stops. Module 4 builds one, and it is a different tool for a different problem rather than a substitute for enrollment.

The practical consequence for a team evaluating this tool is that the work is front-loaded and unglamorous. Deployment, enrollment, coverage against an inventory, and knowing which machines the agent will never reach: none of that is investigation and all of it decides whether the investigation is possible. Module 1 treats it accordingly.

Where it stops

Four limits matter enough to know before you start, because each produces an absence of evidence that looks like evidence of absence.

It reads the present, not the past. A live query sees the system as it is now. If a file was deleted on Tuesday and the machine has been busy since, querying on Friday finds nothing, and the finding is about your timing rather than about the file. That limit is why the course spends a full section on collection order: some evidence is disappearing while you decide what to do, and the decision itself has a cost.

It reads what the system retains. Every artifact has its own horizon: a log rotates, a cache evicts, a database prunes. A busy machine ages evidence out faster than a quiet one, which means two hosts can give different answers to the same question for reasons that have nothing to do with the intrusion.

It sees the endpoint's view. What crossed the network, what a cloud service recorded, what another organization's systems logged: none of that is on the endpoint, and no amount of collecting from hosts will produce it. Recognizing that boundary quickly is worth more than persistence, because the useful move is to name where the answer would have to come from and hand the question to whoever holds it.

It is not a disk image. Live collection from a running machine is defensible and routine, and it is still second best where the standard being applied is a verified bit-for-bit copy of a seized drive. Where a single laptop is the whole case, image it. The same applies where the question is about deleted content, since the parts of a disk that hold a removed file are not what a live agent reads.

Knowing when to reach past this tool is what stops a capable instrument from becoming a habit, and the course returns to that judgment repeatedly rather than treating the tool as the answer to everything.

Why the reasoning matters more than the interface

Most material on this platform teaches the buttons. That produces analysts who can run a collection and cannot say what its result covers, which is a worse position than not having the tool, because a confident wrong answer travels further than no answer.

Here is the shape of the problem this course is built around. A collection returns rows and does not tell you it was canceled at a limit, so the last row looks like the last event. A hunt reaches 731 machines and the console never shows you that the estate has 812, so absence gets reported as clean. A connection list is a snapshot, so a process beaconing every five minutes is invisible between beacons and a single collection proves nothing about it. An artifact named for the data it reads gets used for what somebody hoped it proved.

None of those are bugs. Each is a reasonable design decision with a consequence, and each produces a specific, confident, wrong finding in the hands of somebody who learned the interface without the reasoning.

The pattern behind all four is worth naming once here, because it recurs in every module. This platform is deliberately tolerant: it does not stop you asking an expensive question, it does not warn you that a filter matched nothing, and it does not distinguish an empty result from an impossible one. That tolerance is what makes it flexible enough to answer questions nobody anticipated, and the price is that judgment which another tool would enforce is left to you.

So every section of this course does the same two things. It shows you a capability and how to use it well, and then it shows you the particular way that capability misleads. That is the difference between knowing a tool and being able to rely on what it tells you.