Digital forensics: preserve evidence before changing the system

Illustrative case: a suspicious scheduled task

Suppose a responder finds an unfamiliar scheduled task on a company laptop. Deleting it might stop unwanted activity. It also changes the system before anyone has recorded the task definition, account, execution history or related endpoint alerts. The incident lead needs to coordinate those two concerns. If ongoing activity threatens other systems, containment may come first. Record what was changed and which evidence remains available.

Work from a copy and restrict access to the original collection. Retain tool versions, collection errors and the apparent device-clock offset. Those details can change the explanation. For example, one timestamp may describe when a file was modified, while another records when a monitoring service received the event. Putting them on a timeline does not make them measurements of the same thing.

An evidence record that follows the collection

This hypothetical record follows the material from collection through each transfer. Add a transfer entry when custody changes, so another analyst can determine who handled which copy and for what purpose. The entries are examples; they do not describe a real incident.

Check the evidence, then test the explanation

First, compare hashes to check that the working copy matches the collection. Then examine what its contents establish. Keep the original records alongside any normalized timeline, including enough information to check the transformation. Authentication logs or endpoint telemetry may support the proposed sequence. If they contradict it, retain that too. A contradictory observation is a reason to investigate the explanation further.

Static inspection and metadata may answer the question without running the suspicious binary. If execution is necessary, explain what it is expected to add and use an approved isolated environment with controlled networking and a defined reset procedure. Uploading a confidential sample to a public scanner is a separate disclosure. It requires authorization even when the purpose is investigation.

• An observed event and an inference about its cause should remain distinguishable in the record.
• Missing logs and expired retention periods limit which explanations can be checked.
• Collection commands and tool output let another analyst examine how the material was obtained.
• A consequential timeline conclusion should be reproducible by a second analyst.

What the available records can support

Finding no record of an event leaves at least two possibilities: it did not happen, or the relevant evidence is missing. The search alone cannot resolve that. NIST SP 800-61 Rev. 3 treats collection and analysis as part of coordinated incident response, alongside containment. This ledger helps organize that work; it does not establish a forensic acquisition standard or a legal chain-of-custody determination. Memory capture, damaged media, encrypted devices, employee investigations and possible litigation may require specialist procedures and counsel.