CyberPatriot Resources · Resource 09
Forensics & Evidence References
Use forensic references to preserve evidence, examine system artifacts, correlate multiple data sources, reconstruct timelines, and document conclusions that another teammate can verify.
In CyberPatriot practice, the goal is not to perform a full legal forensic investigation. The goal is to use disciplined evidence handling so security decisions are supported by observable facts.
Evidence rule
Preserve before you change
Restarting a service, deleting a file, disabling an account, or changing configuration can alter useful evidence. Record what matters before remediation whenever practical.
Official reference library
NIST SP 800-86
NIST guidance for integrating computer and network forensic techniques into incident response and troubleshooting.
Open reference →
NIST SP 800-61 Rev. 3
Current NIST incident-response recommendations aligned with the Cybersecurity Framework 2.0.
Open reference →
Microsoft Windows Event Log
Microsoft reference for the Windows Event Log infrastructure used to record and examine operating-system and application events.
Open reference →
Autopsy User Documentation
Official documentation for the Autopsy digital-forensics platform and its analysis features.
Open reference →
Evidence principles
Preserve
Record useful state before making changes so the original evidence is not silently lost.
Verify Integrity
Hashes can help confirm that a copied file or evidence set has not changed unexpectedly.
Keep Context
A filename, event, timestamp, or process is much more useful when tied to its system, user, path, and surrounding activity.
Build a Timeline
Correlate timestamps from multiple sources to understand sequence rather than examining isolated artifacts.
Separate Fact from Interpretation
Document what the evidence directly shows separately from what you think it may mean.
Report Reproducibly
Record enough detail that another teammate can locate and verify the same evidence.
Common evidence sources
Files
Operating System
Logs
Network
Applications
Persistence
Evidence workflow
01
Define the question
State what you are trying to determine before collecting large amounts of unrelated evidence.
02
Identify relevant sources
Choose files, logs, processes, network activity, accounts, or application artifacts that can answer the question.
03
Preserve useful state
Capture important evidence before making a change that could overwrite, delete, restart, or alter it.
04
Examine
Extract relevant details such as timestamps, users, paths, event IDs, hashes, processes, and network endpoints.
05
Correlate
Compare independent data sources and build a sequence of related activity.
06
Analyze
Determine what the combined evidence supports without overstating certainty.
07
Document
Record the finding, evidence location, interpretation, action taken, and verification result.
File integrity references
Windows PowerShell
Get-FileHash .\evidence.bin -Algorithm SHA256Calculate a SHA-256 hash for a file using PowerShell.
Linux
sha256sum evidence.binCalculate a SHA-256 hash for a file using a common Linux utility.
A matching hash can help establish that two files contain the same data. A hash by itself does not determine whether the file is safe, approved, or malicious.
Timeline questions
Which timestamp occurred first?
Are the systems using the same timezone?
Could one system clock be inaccurate?
What happened immediately before the event?
What happened immediately after the event?
Which user was active at that time?
Which process or service was running?
Was a network connection created near the same time?
Did a file appear or change near the same time?
Do two independent evidence sources support the same sequence?
Windows evidence sources
Security
Authentication, account, group, privilege, and audit events.
System
Operating-system, driver, service, and system-component events.
Application
Events written by applications and software components.
Task Scheduler
Scheduled-task execution and operational activity.
PowerShell
PowerShell operational and scripting-related events when logging is available.
Defender
Microsoft Defender operational and detection-related evidence when present.
Linux evidence sources
/var/log/
Traditional operating-system and service logs.
journalctl
Systemd journal containing system and service events.
auth.log
Authentication and sudo-related evidence on many Ubuntu systems.
last / lastlog
Login-history information where available.
systemctl
Service state and unit information.
cron locations
Scheduled commands and recurring jobs.
Evidence record template
System
Which computer, VM, or device produced the evidence?
Time
When was the event observed? Include timezone when relevant.
Source
Which file, log, utility, or artifact contains the evidence?
Location
What exact path, event log, record, or object should another analyst open?
Observation
What does the evidence directly show?
Correlation
Which other evidence supports or contradicts the observation?
Interpretation
What conclusion is reasonably supported?
Action
What change, if any, was made because of the finding?
Verification
How was the result checked afterward?
Competition evidence situations
A suspicious account appears
Confirm whether the scenario authorizes the account.
Record account state, groups, privilege, and recent relevant activity.
Review authentication and account-change evidence.
Determine whether another service depends on the identity.
Make only the justified change.
Verify required access still works.
An unfamiliar file appears
Record its path, owner, size, type, and timestamps.
Calculate a hash if useful.
Determine which process or user may have created it.
Check nearby log and network activity.
Do not delete the file until useful evidence has been preserved.
Document the reasoning behind any action.
A service may have been added
Record service name, executable path, account, and startup configuration.
Check service-install and system logs.
Inspect the executable and related files.
Check listening sockets and network connections.
Determine whether the service is required by the mission.
Verify system function after any authorized change.
A timeline does not make sense
Check timezone assumptions.
Compare timestamps from multiple sources.
Check whether one clock may be offset.
Distinguish creation, modification, access, and log timestamps.
Use sequence and correlation instead of relying on one time field.
Weak interpretation vs better interpretation
Weak interpretation
Delete a suspicious file as soon as you find it.
Better interpretation
Record its metadata, location, hash, related processes, and surrounding evidence before making a justified change.
Weak interpretation
One log entry proves exactly what happened.
Better interpretation
Correlate logs with files, users, processes, services, and network evidence.
Weak interpretation
Every timestamp represents the same kind of event.
Better interpretation
Identify what each timestamp means and account for timezone and clock differences.
Weak interpretation
A hash tells you whether a file is malicious.
Better interpretation
A hash primarily identifies file content and helps verify integrity; interpretation still requires context.
Weak interpretation
Absence of a log entry proves an event did not occur.
Better interpretation
Consider logging configuration, retention, deletion, collection scope, and alternate evidence sources.
Weak interpretation
Document only the final conclusion.
Better interpretation
Document the source evidence, reasoning, changes, and verification so another teammate can reproduce the finding.
Forensics resource checklist
Define the forensic question before collecting unrelated data.
Preserve useful state before making changes.
Record exact evidence locations.
Use hashes when file-integrity verification is useful.
Keep timestamps tied to timezone and system context.
Correlate files, logs, processes, services, users, and network activity.
Separate direct observations from interpretation.
Use Windows Event Logs and Linux logs as evidence sources, not automatic conclusions.
Review persistence mechanisms carefully.
Document changes made during investigation.
Verify system functionality after remediation.
State only what the available evidence actually supports.