Competition Strategy 09
Read forensic questions early, protect evidence, investigate with a clear target, and build answers that are supported by facts rather than guesses.
Forensics is not separate from system hardening. Every cleanup, account change, service change, log action, or file modification can affect the evidence you may need later.
Lesson Snapshot
Learning objectives
Explain why forensic questions should be reviewed early in the competition rather than saved for the end.
Separate evidence collection from assumptions so answers remain supported by facts.
Identify common evidence sources such as logs, files, accounts, processes, timestamps, and configuration artifacts.
Protect evidence from accidental deletion, overwriting, or configuration changes during system hardening.
Use a structured investigation workflow that keeps forensic work from stalling the rest of the team.
Build concise, evidence-supported answers and document the reasoning behind them.
Core concept
The first forensic skill is recognizing which artifacts may matter. Once you know what the question asks, you can protect the relevant evidence and search with purpose.
Investigation rule
Suspicious files, logs, accounts, services, and processes may look like immediate cleanup targets, but they may also contain the evidence needed to answer a question.
Investigation workflow
Identify exactly what the prompt is asking: a user, event, file, timestamp, process, configuration, cause, or other fact.
Decide what kind of artifact is most likely to answer the question before searching randomly.
Avoid deleting, moving, modifying, clearing, or reconfiguring evidence-rich areas until the needed information is captured.
Record the specific log entry, file path, account detail, timestamp, process, or configuration item that supports the conclusion.
Use a second source when possible so the answer does not rely on one ambiguous clue.
Respond to the actual question using the evidence you found instead of adding unsupported assumptions.
Record the answer, evidence source, and any remaining uncertainty so the team can review it later.
Evidence sources
System, security, application, authentication, service, and event logs can reveal actions, failures, account activity, or timing.
File names, locations, contents, permissions, ownership, metadata, and timestamps can support investigation questions.
Users, administrative privileges, group membership, login history, and account properties can reveal authorization or access issues.
Running processes, enabled services, startup items, and background tasks can show what is active on the system.
Persistent tasks and startup mechanisms can explain why software or scripts run automatically.
Connections, listening services, firewall rules, routes, interface settings, and related logs can support network-focused questions.
Policies, service configuration files, registry settings, package configuration, and server settings can reveal the intended system state.
Creation, modification, access, execution, or log times can help build a sequence of events when interpreted carefully.
Fact discipline
Directly supported by a log, file, account state, timestamp, configuration, or other observable artifact.
A reasonable conclusion drawn from multiple facts. Useful, but it should still be described as an interpretation.
Information that the current evidence does not answer yet.
A conclusion that feels plausible but is not yet supported. It should not be treated as evidence.
Evidence preservation
A suspicious file may be the exact artifact needed to answer a forensic question.
Logs can contain event sequences, timestamps, authentication records, and service errors that disappear once cleared.
Installed applications, services, or configuration files may provide evidence about system behavior.
Deleting or heavily modifying accounts can remove useful information about permissions, ownership, or activity.
Moving or editing files can alter metadata that may matter for an investigation.
Some temporary state, running processes, connections, or volatile evidence may change after a restart.
Team coordination
Reads questions early, maps each question to likely evidence sources, documents findings, and warns teammates before evidence-changing actions.
Helps interpret operating-system-specific evidence and pauses high-impact changes when the forensic lead identifies a dependency.
Keeps forensic tasks visible, prevents them from consuming the entire round, and schedules revisits if an investigation becomes a time trap.
Search discipline
What exact fact is the question asking for?
Which artifact type is most likely to contain that fact?
What evidence must be preserved before hardening continues?
Is there a second source that can confirm the same conclusion?
Am I observing a fact or interpreting one?
Could a teammate's planned change alter this evidence?
What should be recorded before I move on?
Is this investigation taking too much time compared with its value?
Time management
Reading forensic questions early protects evidence and gives the team time to revisit difficult investigations later.
Searching is faster when you know whether you need a username, timestamp, file path, process, or configuration value.
If the investigation becomes a time trap, document what you know and move it to Revisit rather than consuming the entire round.
A Windows, Linux, Server, or networking specialist may recognize an artifact faster than the forensic lead alone.
Worked forensic cases
The forensic question asks which account was involved in a suspicious login event.
Weak approach
Guess based on which username looks unusual.
Better approach
Review relevant authentication or security logs, identify the event and account, cross-check the time or source if possible, and record the evidence supporting the answer.
The question asks for information about a recently modified file related to suspicious activity.
Weak approach
Delete the suspicious-looking file immediately.
Better approach
Preserve the file and metadata first, record its path and timestamps, inspect related evidence, answer the question, then decide what cleanup is justified.
A startup item may explain why an unwanted process appears after login.
Weak approach
Disable every unfamiliar startup entry before investigating.
Better approach
Record the startup location, command, associated file, user context, and process behavior before making a change.
A question asks when a service-related problem began.
Weak approach
Use the first timestamp you notice.
Better approach
Correlate relevant service logs, system events, configuration changes, and timestamps before choosing the best-supported time.
Common mistakes
By then, evidence may already have been modified by normal hardening work.
A plausible story is not the same as an evidence-supported answer.
Capture the relevant state before deleting, disabling, editing, or cleaning up.
When possible, confirm important findings with another artifact or source.
A forensic task can become a time trap if the team keeps searching without a clear target or stopping point.
The team should be able to explain why the answer is correct during review.
Reflection
Question 1
Why should forensic questions be read before broad hardening begins?
Question 2
What is the difference between a fact and an inference?
Question 3
Why can deleting a suspicious file too early be a mistake?
Question 4
What makes cross-checking evidence useful?
Question 5
How should the team respond when a forensic investigation becomes a time trap?
Question 6
Why should the forensic lead communicate with operating-system specialists?
Forensics checklist
Read every forensic question early.
Identify the exact fact each question asks for.
Map the question to likely evidence sources.
Protect evidence-rich areas before major changes.
Record file paths, logs, timestamps, users, processes, or configuration details that support the answer.
Separate facts, inferences, unknowns, and assumptions.
Cross-check important conclusions when possible.
Communicate evidence risks to teammates.
Document the answer and supporting evidence.
Move time-consuming investigations to Revisit when necessary.
Return to unresolved forensic tasks during review.
Verify that the final answer directly addresses the question asked.
Next strategy lesson
Next, learn how to recognize time traps, reset your approach, gather better evidence, ask for help, and return to difficult problems without losing the rest of the round.