Preserve before change
If a file, task, account, service, or log may help answer a forensic question, record the evidence before disabling, deleting, or reconfiguring it.
Windows 11 · Lesson 15
Windows Forensics & Evidence Preservation
Preserve the original Windows state before remediation, connect multiple evidence sources, and build defensible timelines from facts instead of assumptions.
Good forensic work is careful, reproducible, and evidence-aware. You should be able to explain what you observed, where it came from, when it happened, what it may mean, and what remains uncertain.
Lesson Snapshot
Evidence principles6
Evidence sources8
Main skillCorrelation
GoalDefensible findings
Learning objectives
What this lesson should help you do
01
Explain why forensic evidence should be preserved before remediation whenever a question may depend on the original state.
02
Distinguish observations, artifacts, timestamps, and conclusions so evidence does not get mixed with assumptions.
03
Identify high-value Windows evidence sources such as Event Viewer, Defender history, scheduled tasks, user accounts, services, startup entries, installed software, and file metadata.
04
Build a simple evidence timeline that connects multiple Windows artifacts.
05
Document evidence in a repeatable way that another teammate could review later.
06
Make defensive changes only after relevant evidence has been preserved and then verify the system state afterward.
Core concept
Preserve first, remediate second
If the original state matters to a forensic question, document it before disabling, deleting, uninstalling, or changing anything.
Evidence warning
Your own actions become part of the timeline
Hardening, reboots, scans, updates, logons, and administrative changes can all create new evidence.
Keep a change log so team activity is not confused with the original state.
Evidence principles
Six habits that protect forensic value
Facts before conclusions
Write down what the evidence actually shows before deciding what it means.
Use multiple sources
One artifact may create a lead. Multiple independent sources make a stronger conclusion.
Keep time context
Timestamps become far more useful when they are compared across logs, tasks, files, Defender, accounts, and team actions.
Separate team activity
Your own hardening work can create events and modify timestamps, so maintain a clear change log.
Preserve required functionality
Evidence collection should not unnecessarily disrupt the system or required services.
Windows evidence map
Eight places to look for useful evidence
Event Viewer
Security, System, Application, and operational logs can reveal account activity, service changes, scheduled-task activity, application failures, and system events.
Microsoft Defender
Protection History and Defender detections can provide file paths, timestamps, threat names, remediation actions, and investigation leads.
Scheduled Tasks
Task names, triggers, actions, accounts, privilege level, and last-run information can reveal automatic execution.
Users and Groups
Local account state, group membership, and administrator access help explain privilege changes and authorized versus unauthorized identities.
Services
Service name, startup mode, account, executable path, and state can connect background activity to installed software or persistence.
Startup Entries
Automatic logon-time execution can reveal legitimate helpers or potentially suspicious persistence.
Installed Software
Application name, publisher, version, install date, path, and related services or tasks can support a forensic timeline.
Files and Folders
File path, size, timestamps, ownership, permissions, and related application context can help explain activity.
Evidence record
Eight fields that make findings reproducible
Artifact
The file, account, task, event, service, application, or configuration item being examined.
Source
Where the evidence came from, such as Security log, Defender history, Task Scheduler, or a filesystem path.
Timestamp
The relevant date and time associated with creation, execution, detection, modification, logon, or another event.
Identity
The user, service account, computer, or security principal connected to the artifact.
Location
The file path, task path, service path, log name, or other location that helps another reviewer find the same evidence.
Observed fact
A plain statement of what the system shows without interpretation.
Interpretation
What the team thinks the evidence may mean, clearly separated from the raw fact.
Verification
Another source or test that supports, contradicts, or refines the interpretation.
Observation vs conclusion
Say only what the evidence supports
Example 01
Observation: Task Scheduler shows a task named UserSync triggered at logon and last run at 10:42 PM.
Unsupported conclusion: UserSync is malware.
Better conclusion: UserSync is an unknown logon-triggered task that ran at 10:42 PM and requires correlation with its action, account, file path, and logs.
Example 02
Observation: Defender quarantined an executable from a Downloads folder.
Unsupported conclusion: The user intentionally downloaded malware.
Better conclusion: Defender detected and quarantined an executable in Downloads; user intent is not established by this evidence alone.
Example 03
Observation: An unfamiliar account is in Administrators.
Unsupported conclusion: The account is unauthorized.
Better conclusion: The account has administrative privilege and must be compared with scenario authorization and account-change evidence.
Timeline construction
Connect activity across evidence types
Account timeline
Account creation, enable/disable state, group membership changes, successful or failed sign-ins.
Execution timeline
Scheduled-task run time, service start, startup entry execution, application launch evidence.
File timeline
Created, modified, accessed, downloaded, quarantined, moved, or removed artifacts where timestamps are available.
Security timeline
Defender detection, firewall change, policy change, account lockout, authentication activity.
System timeline
Startup, shutdown, update, service failure, driver issue, application crash.
Windows collection tools
Inspect before you remediate
Event Viewer
eventvwr.mscReview and filter relevant logs before remediation.
Task Scheduler
taskschd.mscCapture task trigger, action, user context, and history.
Services
services.mscReview service state, startup mode, account, and dependencies.
Windows Security
Windows Security → Virus & threat protection → Protection historyReview Defender detections and actions before clearing or altering related evidence.
PowerShell collection
Capture evidence with read-only queries
Recent Security events
Get-WinEvent -LogName Security -MaxEvents 100 | Select-Object TimeCreated, Id, ProviderName, MessageCreates a read-only recent Security log snapshot when permissions allow.
Scheduled task inventory
Get-ScheduledTask | Select-Object TaskPath, TaskName, StateProvides a broad view of automatic task-based execution.
Service inventory
Get-CimInstance Win32_Service | Select-Object Name, State, StartMode, StartName, PathNameCaptures service state, startup mode, account, and executable path.
Administrator membership
Get-LocalGroupMember -Group "Administrators"Captures current local administrative membership for comparison with scenario authorization.
Defender detections
Get-MpThreatDetectionReviews Defender detection records when available in the authorized environment.
File metadata
Get-Item "C:\Practice\Evidence\sample.exe" | Select-Object FullName, Length, CreationTime, LastWriteTime, LastAccessTimeShows basic filesystem metadata for a known practice artifact.
Evidence documentation template
A simple structure the whole team can use
Question
When did the unknown administrator appear, and what activity occurred around that time?
Known anchor
Unknown scheduled task last ran at 10:42 PM.
Evidence source
Task Scheduler, Security log, local Administrators group, Defender history.
Observed fact
UserSync ran at 10:42 PM under account TempAdmin.
Interpretation
The task may be related to the administrator account, but more evidence is needed.
Corroboration
Security log shows TempAdmin authenticated shortly before the task run.
Action taken
Evidence preserved; task disabled after review.
Verification
Task remains disabled, required services still work, and no authorized account lost access.
Before remediation
Ten preservation questions
01
Could this artifact answer a forensic question?
02
Could changing it alter timestamps or logs?
03
Can I record the state before remediation?
04
Do I know the exact source and location of the evidence?
05
Can another teammate reproduce what I saw?
06
Is there another evidence source that supports the same conclusion?
07
Will this change affect a required service or application?
08
Have I separated my own team actions from pre-existing activity?
09
Do I need to export, screenshot, or write down the evidence before continuing?
10
What verification will confirm the system remains functional afterward?
Decision cases
Evidence-aware decisions in context
Unknown admin account
The local Administrators group contains an unfamiliar account that the scenario does not list.
The account is a high-priority finding, but removing it immediately may destroy the chance to understand when or how it appeared.
Response
Record membership, inspect account properties, correlate account-change and logon evidence, then remove privilege or disable the account after preservation if it is confirmed unauthorized.
Defender quarantined a suspicious executable
Protection History shows a quarantined executable and a timestamp matching the forensic window.
Deleting history or related artifacts too early could erase useful context.
Response
Record detection details, file path, timestamp, action, and related user or process evidence before cleanup.
Unknown scheduled task
A task runs at every logon from an unusual user-profile path.
The task may represent persistence, but the strongest conclusion requires action-path, account, timing, and log correlation.
Response
Document task properties and history, correlate with file and event evidence, then disable after preservation if justified.
Suspicious service
An automatic service runs from an unexpected path using a privileged account.
The path and privilege are suspicious signals, but the service may still belong to installed software.
Response
Capture service metadata, application ownership, executable path, and relevant events before changing the service.
Evidence quality
What makes a conclusion stronger
Direct observation
You personally viewed the artifact in Windows or through a read-only command.
Reproducible
Another teammate can follow the same steps and see the same evidence.
Corroborated
A second independent source supports the same interpretation.
Time-linked
The timestamps align with the suspected or known activity window.
Context-aware
The evidence is interpreted against scenario requirements and known team actions.
Preserved before change
The original state was documented before remediation modified it.
Fictional defensive lab
Correlate an unknown account, task, and Defender detection
Step 01
Read the fictional scenario
Morgan is the only authorized administrator. RDP is required. The system contains an unknown administrator, an unknown logon task, and one Defender detection from the same evening.
Step 02
Define the forensic question
Determine whether the unknown account, task, and Defender detection are connected in time and context.
Step 03
Collect evidence
Record administrator membership, task properties and last-run time, Defender detection details, and relevant Security/System events.
Step 04
Build a timeline
Place only supported facts in chronological order and label any interpretation separately from observations.
Step 05
Corroborate
Compare the account, task, detection, file path, and event evidence. Note which points are confirmed and which remain uncertain.
Step 06
Remediate and verify
After evidence is preserved, remove the confirmed unnecessary privilege or disable the suspicious task, then verify RDP, Defender, firewall, and required services still function.
Common mistakes
Forensic habits that weaken conclusions
Remediating before collecting evidence
The original state may disappear once a task, account, file, or service is changed.
Writing conclusions as facts
A suspicious artifact is not proof of intent, ownership, or compromise.
Using only one source
One artifact may be misleading or incomplete. Correlation improves confidence.
Ignoring your own team actions
Hardening changes create events and timestamps that can contaminate a timeline.
Clearing logs
Log cleanup can destroy evidence needed for later troubleshooting or forensic questions.
Breaking required functionality during collection
Evidence preservation should not unnecessarily disrupt required services or access.
Reflection
Test your forensic reasoning
Question 1
Why should evidence be preserved before remediation?
Question 2
What is the difference between an observed fact and an interpretation?
Question 3
Why is correlation stronger than relying on one artifact?
Question 4
How can your team's own changes affect a forensic timeline?
Question 5
What evidence sources would you compare for an unknown scheduled task?
Question 6
What should be verified after remediation is complete?
Verification checklist
Confirm the evidence and the final system state
01
Confirm all relevant evidence was recorded before remediation.
02
Confirm observations and interpretations are written separately.
03
Confirm timestamps are documented consistently.
04
Confirm at least two evidence sources support important conclusions where possible.
05
Confirm team-generated changes are identified separately.
06
Confirm the evidence source and location are documented.
07
Confirm required services still work after remediation.
08
Confirm authorized users still have required access.
09
Confirm Defender and firewall remain healthy.
10
Confirm suspicious or unauthorized items are in the intended final state.
11
Document unresolved questions instead of inventing an answer.
Competition checklist
Before leaving Windows Forensics
01
Define the exact forensic question.
02
Identify likely evidence sources.
03
Record evidence before changing the system.
04
Capture timestamps, paths, users, providers, and task/service names.
05
Separate observations from conclusions.
06
Correlate multiple sources.
07
Maintain a team change log.
08
Do not clear logs during active investigation.
09
Preserve suspicious task, service, account, and Defender details.
10
Remediate only after evidence collection.
11
Verify required functionality after remediation.
12
Document what remains unknown.
Final Windows lesson
Windows 11 Final Review Checklist
Next, combine identity, protection, system, access, evidence, and verification into one final competition-ready Windows review.