Forensics · Lesson 02
Evidence Preservation & Documentation
Learn how to preserve the original state of useful artifacts, document where evidence came from, separate observations from conclusions, and track defensive changes without losing the information needed for later forensic questions.
Strong forensic work is reproducible. Another teammate should be able to read your notes and understand what you observed, where you observed it, what changed afterward, and how confident the conclusion should be.
Lesson Snapshot
Learning objectives
Preserve enough evidence to explain what happened later
Explain why preserving original evidence matters before configuration changes or cleanup.
Separate original artifacts, working copies, notes, and conclusions so the investigation remains understandable.
Record enough context that a teammate can reproduce where an observation came from.
Use hashes, timestamps, paths, account names, event identifiers, and source-system details consistently.
Document uncertainty, conflicting evidence, and unanswered questions instead of hiding them.
Build concise evidence notes that support later forensic answers and final review.
Core idea
Evidence loses value when its context disappears
A copied value without its path, host, timestamp type, user, log source, or neighboring records may be impossible to interpret correctly later. Preservation means keeping both the artifact and the information that gives it meaning.
Competition caution
Hardening can destroy useful forensic state
Removing an account, disabling a task, deleting a file, restarting a service, or clearing a log may erase details needed for another question. Record the original state first whenever it is safe and practical.
Preservation principles
Treat the original state as evidence
Preserve before changing
A file, account, log, process, service, scheduled task, startup item, or network state may become evidence for a later question. Record it before you alter it.
Originals are references
Treat the original artifact as the reference point. If a lab permits copies, analyze the copy while keeping the original state documented.
Context is part of the evidence
A filename alone is weak. Path, owner, timestamp, host, event source, and surrounding records often determine what the artifact means.
Notes must distinguish fact from interpretation
Write what you observed separately from what you think it means. This prevents an early assumption from becoming an undocumented conclusion.
Every change creates new evidence
Stopping a service, resetting a password, editing a file, or rebooting can create logs and timestamps that did not exist before.
Documentation is part of verification
If you cannot explain where a fact came from, another teammate cannot reliably verify it.
Evidence states
Know which version of the system you are describing
Original state
What existed before you intentionally changed anything.
Examples
Current file path, service state, task configuration, log records, running process, user membership.
Observed state
The facts you directly recorded from the original environment.
Examples
Timestamp, hash, event ID, username, process ID, port, service startup type.
Working copy
A duplicate or exported artifact used for safe inspection when the lab allows it.
Examples
Copied text log, exported event record, copied document, screenshot, hash list.
Changed state
What exists after a deliberate defensive action.
Examples
Disabled account, stopped service, removed startup entry, updated permission, blocked port.
Verified state
Evidence that confirms the intended change occurred and required functionality still works.
Examples
New service status, new group membership, clean listener list, successful required login.
Evidence note
Record enough information to reproduce the observation
Case or question
The exact forensic prompt or issue being investigated.
Example
Which account created the scheduled task BackupCheck?
Source system
The hostname or lab system where the artifact was observed.
Example
CP-WIN-04
Artifact source
The log, path, application, configuration area, or command output used.
Example
Task Scheduler / task details
Location
Exact path, log channel, registry location, unit file, or other precise location.
Example
\Microsoft\Windows\BackupCheck
Observed value
The fact you directly saw.
Example
Task runs as user labadmin at 07:30 daily.
Timestamp
The relevant time plus its type and zone when known.
Example
2026-10-10 07:28 EDT, task modification time
Identity
User, process, service, host, or application associated with the evidence.
Example
labadmin
Identifier
Hash, event ID, process ID, task name, service name, or record ID.
Example
SHA-256: fictional-example-hash
Interpretation
What the evidence may mean, clearly labeled as interpretation.
Example
The task may have been created by or for labadmin, but creator identity needs corroboration.
Corroboration
A second artifact that supports or challenges the conclusion.
Example
Security log shows an administrative session near the modification time.
Chain-of-custody mindset
Track what the artifact is, where it came from, and what happened to it
CyberPatriot practice is not a courtroom investigation, but the same disciplined habits make competition evidence more reliable and easier to verify.
Identify
Label the artifact clearly enough that there is no confusion about what was collected.
Record source
Document the system, user profile, path, log, or application where the artifact originated.
Record time
Note when you observed or collected it and distinguish that time from the artifact's own timestamps.
Protect the original
Avoid editing, renaming, deleting, opening in a way that writes changes, or otherwise altering the source evidence unnecessarily.
Hash where useful
For copied files in authorized labs, calculate and record a cryptographic hash so later comparisons can verify file identity.
Track analysis
Record which copy or export you examined and what tools or commands produced your observations.
Before you change it
Capture the evidence that a defensive action could erase
Suspicious file
Record first
Record path, filename, owner, size, timestamps, and hash if appropriate.
Avoid
Deleting, renaming, moving, or executing it before the forensic question is answered.
Unexpected user account
Record first
Record username, group memberships, status, profile path, and relevant authentication evidence.
Avoid
Deleting the account immediately and losing easy access to its context.
Unknown service
Record first
Record service name, display name, startup type, state, executable path, account, and related logs.
Avoid
Stopping or disabling it before documenting what it was doing.
Scheduled task or cron entry
Record first
Record name, command, trigger, user, path, timestamps, and whether it is enabled.
Avoid
Removing the task before preserving its configuration.
Listening network service
Record first
Record protocol, local address, port, process ID, process path, owner, and expected purpose.
Avoid
Killing the process before tying the listener to a specific program.
Relevant logs
Record first
Record channel, source, event ID, timestamps, user, host, neighboring entries, and export if permitted.
Avoid
Clearing logs or restarting components that may rotate or overwrite them.
Hashing for preservation
Use hashes to identify exact file content
Lesson 03 will go deeper into hashing. Here, focus on how hashes support preservation and documentation.
What a hash tells you
If the same cryptographic algorithm produces the same digest for two files, the content is extremely likely to be identical.
What a hash does not tell you
A hash does not explain who created a file, why it exists, whether a user intended to use it, or whether it is safe.
Record the algorithm
A digest is incomplete documentation without the algorithm name, such as SHA-256.
Hash before and after copies
In authorized practice, comparing hashes can help confirm that a copied artifact matches the source content.
Do not rely on filenames
Two files with the same name can have different content, and the same content can appear under different names.
Do not expose secrets
Do not publish hashes of passwords, tokens, private keys, or other secret material from real systems.
Example documentation
Artifact: report-pack.zip Source system: CP-WIN-04 Path: C:\Users\analyst\Downloads\report-pack.zip Algorithm: SHA-256 Digest: <fictional training digest> Observation time: 2026-10-10 13:31 EDT Purpose: Verify file identity before later defensive cleanup
Screenshots
Capture context, not just pixels
Strong evidence capture
A screenshot includes the artifact, relevant path or source, visible timestamp or identifier, and enough interface context to understand where the evidence came from.
Weak evidence capture
A tightly cropped screenshot shows only one value with no source or context.
Strong evidence capture
The note references the screenshot by a clear label such as F02-S03 and explains what it proves.
Weak evidence capture
A folder contains many unnamed screenshots such as Screenshot1.png, Screenshot2.png, and Screenshot3.png.
Strong evidence capture
Sensitive or unrelated personal data is excluded from the capture.
Weak evidence capture
The capture includes real credentials, private messages, or unrelated personal information.
Strong evidence capture
The screenshot supports the written evidence note rather than replacing it.
Weak evidence capture
The team relies on memory of what the screenshot supposedly showed.
Timestamp discipline
Document what each time actually means
Observation time
When you looked at or collected the artifact. This is not necessarily the time the event occurred.
Artifact time
The time stored in a file, log, application, task, or other source.
Timestamp type
Creation, modification, access, event, start, stop, login, download, or another specific kind of time.
Time zone
Record the zone or offset when known so evidence from different sources can be compared correctly.
Clock reliability
Different systems can have drift or incorrect settings, so timestamps may require corroboration.
Sequence over precision
When exact time is uncertain, several agreeing artifacts may still establish a reliable order of events.
Change tracking
Keep defensive changes separate from original observations
| Time | System | Change | Reason | Evidence saved | Verification | Performed by |
|---|---|---|---|---|---|---|
| 15:42 local | CP-WIN-04 | Disabled fictional unused service DemoUpdater | Service not required by scenario and confirmed unrelated to required applications | Service name, executable path, startup type, account, related event IDs | Service stopped; required web application still reachable | Team member initials |
The change log answers a different question from the evidence note. The evidence note records what existed. The change log records what your team intentionally did afterward.
Observation vs interpretation
Do not let assumptions become facts in your notes
Observation
File notes.zip exists at C:\Users\trainee\Downloads.
Reasonable interpretation
The file may have been downloaded by the trainee profile.
Unsupported claim
The trainee intentionally downloaded a malicious archive.
Observation
Security log records a successful logon for labadmin at 09:17.
Reasonable interpretation
The account was authenticated at that time.
Unsupported claim
The account owner was physically sitting at the machine.
Observation
TCP port 8080 is listening under process ID 4312.
Reasonable interpretation
Process 4312 owns the listener at the time of observation.
Unsupported claim
The service is malicious because port 8080 is unusual.
Observation
A scheduled task launches script.ps1 every hour.
Reasonable interpretation
The task provides recurring execution of that script.
Unsupported claim
The task is definitely persistence created by an attacker.
Observation
A browser record and file creation time are both near 14:08.
Reasonable interpretation
The two artifacts may describe the same download event.
Unsupported claim
The browser record proves every later action involving the file.
Observation
The file hash changed after editing the document.
Reasonable interpretation
The file content changed.
Unsupported claim
The editor changed only the sentence visible on screen and nothing else.
Evidence labels
Use a simple naming system so teammates can reference artifacts quickly
File or filesystem evidence
Example: F-01 archive.zip metadata
Log or event evidence
Example: L-03 authentication event
Account or identity evidence
Example: A-02 Administrators membership
Process or service evidence
Example: P-04 service executable path
Network evidence
Example: N-01 TCP listener mapping
Browser or user-activity evidence
Example: B-02 download history record
This is only a training convention. The important part is consistency: every teammate should know exactly which artifact a note such as F-01 or L-03 refers to.
Common mistakes
Documentation failures that weaken later answers
Changing first, documenting later
The original state may be impossible to reconstruct after the change.
Screenshots with no labels
A teammate cannot tell which question the image supports or where it came from.
Notes that contain only conclusions
A statement such as 'malicious task found' is weaker than recording the task name, trigger, command, user, and source.
Mixing evidence from multiple hosts
The same username, process name, or path can exist on different machines.
Ignoring timestamp type
A modification time is not the same as a creation time or event time.
Overwriting the original evidence file
Editing a log or document used as evidence destroys the reference state.
Publishing sensitive data
Evidence notes should not expose real credentials, keys, tokens, or unrelated private information.
Treating hashes as verdicts
A hash identifies content; it does not by itself explain intent, safety, or origin.
Fictional documentation lab
Preserve the case before cleanup begins
The evidence below comes from a fictional training workstation. Your goal is to organize it so a teammate can answer forensic questions even after later defensive changes.
C:\Users\analyst\Downloads\report-pack.zip exists and is 8.2 MB.
SHA-256 was recorded for report-pack.zip before any cleanup.
A download entry references report-pack.zip at 13:22.
User analyst logged in at 13:10.
An archive utility started under analyst at 13:24.
A new folder named report-pack appears at 13:25.
Task 01
Write the strongest supported answer to: Which account was active before the download?
Evidence-based answer
analyst, supported by L-01.
Task 02
What evidence should be preserved before deleting report-pack.zip?
Evidence-based answer
Path, size, timestamps, ownership, hash, browser record, related process evidence, and extracted-folder context.
Task 03
Can B-01 alone prove who physically initiated the download?
Evidence-based answer
No. It supports activity in that browser profile but does not prove physical identity.
Task 04
Which two artifacts best support that the archive was opened or extracted?
Evidence-based answer
P-01 and F-03.
Task 05
Why is F-02 valuable?
Evidence-based answer
It records exact file content identity so later copies or changes can be compared.
Task 06
What should the team document before disabling a related suspicious task discovered later?
Evidence-based answer
Name, command, trigger, user, path, state, timestamps, and relevant supporting logs.
Final checklist
Before you consider an artifact documented
I know the exact question or issue this evidence supports.
I recorded the source system.
I recorded the artifact location.
I recorded the relevant value and surrounding context.
I labeled timestamp type and time zone when known.
I preserved the original before changing anything.
I used a working copy or export where appropriate and permitted.
I recorded the hash algorithm when a hash was used.
I separated observation from interpretation.
I documented uncertainty or conflicting evidence.
I tracked defensive changes separately from original observations.
I can explain the evidence to another teammate without relying on memory.
Reflection
Check your preservation habits
Question 1
Why can a defensive change make later forensic questions harder to answer?
Question 2
What information should accompany a screenshot so it remains useful evidence?
Question 3
Why should observation and interpretation be written separately?
Question 4
What does a matching SHA-256 hash help establish?
Question 5
Why is the time you collected an artifact different from the artifact's own timestamp?
Question 6
When is it better to write 'insufficient evidence' than to choose the most likely explanation?
Carry this forward
Preserve original state, record source and context, hash files when useful, separate observation from interpretation, and log every defensive change that could affect later evidence.