When approaching a powered-on computer, one of the first decisions may come before choosing an acquisition method: should the current state be maintained, or deliberately changed?
A running system may be unlocked, have encrypted volumes already mounted, contain useful volatile data, maintain authenticated sessions, or depend on network resources that may no longer be available after isolation or shutdown.
But maintaining that state is not neutral either. Processes continue to run, logs change, applications write data, synchronization may continue, and remote access or destructive activity may still be possible.
This makes the usual options difficult to reduce to a fixed sequence.
Network isolation may reduce the risk of remote interference, but it can also break active sessions or dependencies.
Live collection may preserve memory, encryption material and other volatile information, while necessarily introducing its own footprint.
Shutdown may stop ongoing activity, but it can also destroy volatile state or turn an accessible encrypted system into one that is much harder — or impossible — to access afterwards.
This makes me wonder whether first-response guidance should begin less with a predefined procedure and more with the observable state of the system.
For example:
- power and lock state;
- encryption and access state;
- mounted local or remote storage;
- active sessions;
- network dependencies;
- volatile information likely to be lost;
- indications of ongoing remote or destructive activity.
The available options could then be compared in terms of what they preserve, what may be lost, what footprint they introduce, and how reversible the decision really is.
By reversible, I do not simply mean whether an action can technically be undone. I mean whether the evidential state that existed before the action can realistically be recovered.
For those who regularly deal with powered-on systems: which observable states actually make you change your normal first-response approach?
And are there situations where you deliberately maintain the current state rather than immediately isolating, collecting, or shutting the system down?
Interested to hear how others approach this in practice.
Forensic response is not a one-size-fits-all approach, but rather a risk assessment governed by unchanging priorities:
If the risk of the disk self-destructing is imminent: the priority is to immediately cut off power.
If encryption is active and the screen is open: the priority is to extract encryption keys and memory, and logically recover sensitive data.
If evidence is linked to network and cloud sources: the priority is to cautiously restrict the network partially, not completely.
Forensic intervention always leaves a trace; therefore, the investigator's success is measured by their ability to document that trace and demonstrate that their intervention was the only option to save the evidence from certain destruction.
Thanks — this is very close to the tension I was trying to surface.
I agree that the observed state should drive priority, rather than a fixed sequence of actions.
The part I’m particularly interested in is separating risk from reversibility.
For example, cutting power may be justified where destructive activity is genuinely imminent, but in a less certain situation it may also irreversibly remove access to volatile memory, plaintext data, an authenticated session, or encryption material.
Likewise, partial network restriction can sometimes preserve more options than either leaving the system fully connected or fully isolating it.
So I’m trying to think of the decision not only as “what is the highest immediate risk?” but also “which action spends future evidentiary options, and which preserves them?”
I also agree completely that every live intervention leaves a footprint. I would probably stop short of saying the investigator must prove it was the only possible action, though — in many cases several defensible options may exist, provided the trade-offs and rationale are documented.
That distinction between risk, footprint and reversibility is what I’m trying to make explicit.