Common Mistakes · Guide 06 · Forensics
Forensics Mistakes
Forensics mistakes usually happen when the team acts before it records the evidence or becomes too confident too early. Preserve first, correlate multiple artifacts, and separate what you observed from what you think happened.
Strong forensic work protects the original state, builds a defensible timeline, and makes uncertainty explicit instead of hiding it.
Quick Use
Forensics rule
Preserve the evidence before you improve the system
Security remediation changes the state you are trying to investigate. Capture the details that matter first, then contain or remediate only after the evidence needed for the question is safe.
10 forensic mistakes
What goes wrong and the safer replacement
Remediating before preserving evidence
What goes wrong
A suspicious account, service, file, process, task, or network connection is changed immediately after discovery.
Why it hurts
The original state can disappear, making it harder to answer forensic questions or reconstruct what happened.
Stronger replacement
Capture the relevant logs, paths, hashes, timestamps, process details, service state, network context, and configuration before remediation.
Jumping from one artifact to a conclusion
What goes wrong
A single log entry, filename, timestamp, or process is treated as enough proof for a complete story.
Why it hurts
The team may misclassify normal activity as suspicious or miss the real sequence of events.
Stronger replacement
Correlate multiple artifacts and look for agreement across time, identity, process, file, service, and network evidence.
Mixing observation with interpretation
What goes wrong
Notes may say an attacker created a file or a user was compromised when the evidence only proves that a file existed or an account logged on.
Why it hurts
The investigation becomes biased and later evidence may be interpreted to fit an unsupported theory.
Stronger replacement
Write what was observed first, then separately record the interpretation and confidence level.
Ignoring time zone and clock context
What goes wrong
Timestamps from different systems or logs are compared without checking time zone, clock skew, or format.
Why it hurts
Events can appear in the wrong order and the timeline may become misleading.
Stronger replacement
Record system time, time zone, and any known clock differences before building the event sequence.
Failing to hash important files
What goes wrong
A suspicious file may be inspected or moved without recording an integrity value.
Why it hurts
The team cannot prove whether the file changed later or reliably identify the exact artifact in notes.
Stronger replacement
Record a SHA-256 hash when practical before making changes to important files.
Deleting suspicious files too early
What goes wrong
A file is removed as soon as it looks malicious or unnecessary.
Why it hurts
Metadata, hashes, file type, directory context, and related artifacts may be lost.
Stronger replacement
Record the full path, hash, size, timestamps, file type, owner, and related process or service context before removal.
Ignoring parent-child process relationships
What goes wrong
A suspicious process is reviewed in isolation.
Why it hurts
The team may miss the launcher, persistence mechanism, script, service, or user action that explains how the process started.
Stronger replacement
Trace parent PID, command line, executable path, user, service relationship, and related network activity.
Treating successful logon as proof of normal behavior
What goes wrong
A successful authentication event is assumed to be legitimate because the credentials worked.
Why it hurts
Unauthorized use of a valid account can be overlooked.
Stronger replacement
Compare the account, logon type, source, time, privilege level, and nearby activity with the mission and expected behavior.
Building a timeline from one log source
What goes wrong
The investigation relies only on one event log, journal source, or application record.
Why it hurts
Important gaps remain and the sequence can be misunderstood.
Stronger replacement
Correlate authentication, process, service, persistence, file, browser, and network artifacts when available.
Overstating confidence
What goes wrong
The team presents a possible explanation as certain even though the evidence is incomplete.
Why it hurts
Wrong conclusions can drive unnecessary remediation and weaken the final answer.
Stronger replacement
Label findings as confirmed, strongly supported, possible, or unresolved based on the evidence actually available.
Preserve first
Capture context that remediation can destroy
Exact hostname and system time
Time zone or clock context
Full file path
SHA-256 hash
File size and timestamps
PID and parent PID
Executable path and command line
Service or scheduled-task relationship
Username and privilege context
Listening port or remote endpoint
Relevant event IDs or log lines
Screenshots or exports when useful
Correlation
Build conclusions from multiple evidence dimensions
Identity
Process
Persistence
File
Network
Time
Confidence model
Match the conclusion to the strength of the evidence
Confirmed
Multiple artifacts directly support the finding and there is little reasonable ambiguity.
Strongly supported
The evidence aligns well, but one or more details are still inferred rather than directly observed.
Possible
Some evidence fits the theory, but other explanations remain plausible.
Unresolved
The available artifacts are not sufficient to support a reliable conclusion.
Timeline reconstruction
Build the sequence only after time context is understood
Record system time and time zone.
Identify the earliest reliable event.
Add authentication activity.
Add process and service activity.
Add persistence changes.
Add file and browser artifacts.
Add network connections or listeners.
Compare the sequence with mission context and mark gaps.
Weak habit vs better habit
Replace assumptions with evidence language
Weak statement
The attacker created this file.
Better statement
The file appeared at this path at this time. The creating process is not yet confirmed.
Weak statement
This login proves the user was compromised.
Better statement
The account logged on successfully from this source. Legitimacy still needs to be compared with expected use.
Weak statement
Delete the suspicious file now.
Better statement
Record path, hash, metadata, owner, file type, and related process or service evidence first.
Weak statement
The timestamp proves event A happened before event B.
Better statement
Confirm system clocks and time zones before ordering cross-system events.
Weak statement
The process is malicious because the name looks strange.
Better statement
Check path, parent, command line, user, service relationship, file hash, and network activity.
Weak statement
We know exactly what happened.
Better statement
State what is confirmed, what is strongly supported, and what remains unresolved.
Forensics final checklist
Preserve, correlate, document, and state uncertainty clearly
Important evidence was preserved before remediation.
System time and time-zone context were recorded.
Important files were documented with full paths and hashes where practical.
Process evidence included parent, command line, path, and user context.
Service, task, cron, and timer evidence was preserved before deletion.
Successful logons were reviewed in context rather than assumed legitimate.
Multiple evidence sources were correlated where possible.
Observation and interpretation were written separately.
Timeline conclusions accounted for clock and time-zone differences.
Confidence levels matched the strength of the evidence.
Unresolved findings were labeled clearly instead of guessed.
Forensic notes were complete enough for another teammate to continue the investigation.