Forensics · Lesson 06
Log Analysis Fundamentals
Learn how to read logs as structured evidence, filter noise, preserve surrounding context, recognize meaningful patterns, and correlate system events with users, files, services, processes, and network activity.
The goal is not to memorize every event ID or message. The goal is to know how to ask a focused question, find the right source, interpret the record, and verify the conclusion.
Lesson Snapshot
Learning objectives
Turn large log sets into useful evidence
Explain what logs are and why they are useful in forensic investigations.
Recognize common log fields such as timestamp, source, user, host, event type, severity, and message.
Filter large log sets without losing important context around an event.
Distinguish normal, suspicious, unknown, and irrelevant records.
Correlate log evidence with files, users, processes, services, and network activity.
Build short evidence-backed timelines from multiple records instead of relying on one isolated event.
Core idea
Logs tell you what a system recorded, not the entire story
A log entry becomes useful when you know which host and component produced it, what the event means, and how it fits with other evidence.
Competition caution
Do not clear logs before answering forensic questions
Logs may contain the only record of a login, service change, scheduled action, package install, error, or privilege event. Preserve the relevant evidence before cleanup or hardening.
Log fundamentals
Understand what logs can and cannot tell you
Logs are records, not conclusions
A log records that a system or application observed an event. The event still needs interpretation and context.
Fields create structure
Timestamp, source, host, user, event ID, severity, and message fields help organize raw activity into searchable evidence.
Noise is normal
Healthy systems generate many repetitive entries. The goal is to find what is relevant to the forensic question.
Sequence matters
Events before and after a target record can reveal cause, effect, or whether the event was expected.
Absence is not proof
Logs can rotate, be disabled, fail to capture an event, or use a different source. Missing records do not prove something never happened.
Corroboration strengthens confidence
A log becomes more useful when it agrees with file metadata, process state, user activity, service configuration, or network evidence.
Common fields
Read the structure before reading the story
Timestamp
When the event was recorded.
Ask
What time zone? Was the clock synchronized? Is this event time or collection time?
Host
The system that generated the record.
Ask
Are you mixing evidence from multiple machines?
Source
The service, application, subsystem, or component that wrote the event.
Ask
Does this source normally report the kind of event you are investigating?
User
An account associated with the event where available.
Ask
Does this mean authenticated user, process owner, service account, or target account?
Event Type
The category of activity, such as login, service change, error, process action, or network event.
Ask
What does this event type actually represent?
Severity
A label such as information, warning, error, or critical.
Ask
Is severity meaningful for the forensic question, or only operational health?
Record ID
A unique or sequential identifier within a log source.
Ask
Can this help order neighboring entries or reference the exact event later?
Message
Human-readable details about the event.
Ask
Which parts are facts, and which are interpretation by the logging application?
Analysis workflow
Move from question to log evidence
Define the question
Decide whether you are looking for a login, service change, process, file action, network event, error, or sequence.
Choose the likely log source
Start with the subsystem most likely to record the event instead of searching every log at once.
Set a time window
Use known timestamps from files, browser records, user sessions, or scenario clues to narrow the search.
Filter carefully
Filter by user, host, event ID, service, keyword, severity, process, or address while keeping enough context to understand the event.
Read neighboring events
Inspect entries before and after the match to understand sequence and reduce false conclusions.
Correlate
Compare the log with independent artifacts such as files, services, processes, account changes, or network records.
Document the evidence
Record the exact source, timestamp, event identifier, relevant fields, and why the event matters.
Event classification
Label records by relevance, not by fear
Relevant
Directly helps answer the forensic question.
Example
A successful login event for the account named in the prompt.
Supporting
Does not answer the question alone but strengthens the timeline or conclusion.
Example
A service start event occurring immediately after a configuration change.
Expected
Normal activity that helps establish baseline behavior.
Example
Routine operating-system update service activity during its normal schedule.
Suspicious
Unexpected or concerning enough to investigate further.
Example
A newly created administrator account outside the expected scenario.
Unknown
Meaning is not yet understood.
Example
An unfamiliar application event with limited context.
Irrelevant
Unrelated to the current forensic question.
Example
A printer warning while investigating an SSH login.
Filtering
Narrow the evidence without losing the story
Start broad enough
A time window of several minutes around a known event is often better than searching one exact second.
Add one filter at a time
Over-filtering can hide the event you need. Narrow gradually and confirm each filter still makes sense.
Keep context
A matching line may be meaningless without records immediately before and after it.
Watch repeated events
Repeated failures followed by success can mean something different from one isolated failure.
Do not search only for suspicious words
Useful evidence may contain ordinary usernames, service names, event IDs, or process paths instead of obvious warning terms.
Record the query
If you filtered by user, event ID, time, or keyword, write down the filter so another teammate can reproduce the result.
Windows logs
Common sources
Security
Authentication, account, privilege, and security-related events depending on audit policy.
System
Operating-system components, services, drivers, startup, shutdown, and system-level events.
Application
Application-generated records, errors, warnings, and operational messages.
PowerShell
Script and command activity where PowerShell logging features are enabled.
Task Scheduler
Task creation, trigger, execution, and completion information in relevant operational channels.
Defender
Antivirus and security-protection events in Defender-related channels where available.
Linux logs
Common sources
journalctl
Central systemd journal access for boots, services, kernel, authentication, and application events where captured.
/var/log/auth.log
Common Ubuntu-family authentication, sudo, SSH, and PAM activity where configured.
/var/log/syslog
General system and service messages on many Ubuntu-family systems.
/var/log/apt
Package installation and update history.
Application logs
Service-specific logs under /var/log or application-defined directories.
Shell history
Can provide useful user-command context but is incomplete and not a substitute for authoritative logs.
Windows commands
Review event data with PowerShell
Search recent system events
Get-WinEvent -LogName System -MaxEvents 50
Reads recent System log entries for review.
Filter by time
Get-WinEvent -FilterHashtable @{
LogName = "System"
StartTime = (Get-Date).AddHours(-1)
}Limits results to a defined recent time window.
Filter by event ID
Get-WinEvent -FilterHashtable @{
LogName = "System"
Id = 7045
}Shows matching records for a specific event ID when that ID is relevant to the investigation.
Format useful fields
Get-WinEvent -LogName System -MaxEvents 20 | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message
Displays common evidence fields in a compact format.
Linux commands
Review journal and text logs
Recent journal events
journalctl -n 50
Shows the most recent journal records.
Filter by time
journalctl --since "2026-10-10 13:00:00" --until "2026-10-10 14:00:00"
Limits the journal to a defined time window.
Filter by service
journalctl -u ssh --since today
Shows journal records associated with a specific service unit where applicable.
Search authentication log
grep -i "sudo" /var/log/auth.log
Finds lines containing a relevant keyword in a common Ubuntu-family authentication log.
Sequence patterns
Look for event relationships, not isolated lines
Failure → failure → success
Repeated authentication attempts followed by a successful login.
Caution
Could be a mistyped password, automation, or other legitimate behavior. Context matters.
Config change → service restart
A service may have been restarted to apply a new configuration.
Caution
Confirm the configuration file, user, command history, or administrative log.
Download → process start
A downloaded file may have been opened or executed.
Caution
Correlate filename, path, hash, process path, user, and timing.
Account creation → group change
A newly created user may have been granted additional privileges.
Caution
Verify whether the account was authorized by the scenario.
Task creation → recurring process
Scheduled execution may explain repeated process activity.
Caution
Preserve task details before removing or disabling it.
Network error → service stop
An application may have lost connectivity because a dependent service stopped.
Caution
Do not assume causation until sequence and dependency are confirmed.
Context window
Read before, target, after, and elsewhere
Before
What event, login, process, file, or configuration change occurred immediately before the target record?
Target
What exactly does the matching event say happened?
After
What happened next, and does it support the same interpretation?
Elsewhere
Does another log or artifact show the same user, time, service, process, file, or host?
Correlation
Combine logs with independent artifacts
Log
Successful login for trainee1 at 09:12.
Other artifact
User profile file modified at 09:16.
Supported conclusion
The account was authenticated before the file change, but this still does not prove who physically made the edit.
Log
Service DemoAgent installed at 10:20.
Other artifact
Executable appears in ProgramData at 10:19.
Supported conclusion
The file and service events likely belong to the same installation sequence.
Log
SSH login for analyst at 11:02.
Other artifact
sudo event appears at 11:04.
Supported conclusion
The analyst account authenticated and then performed a privileged action shortly afterward.
Log
Task Scheduler records a task start at 12:30.
Other artifact
Related process appears under the configured task account.
Supported conclusion
The scheduled task likely launched that process.
Log
Application reports failed DNS lookup at 13:18.
Other artifact
Network configuration shows an incorrect DNS server.
Supported conclusion
The configuration provides a plausible explanation for the application error.
Log
Package manager records installation at 14:05.
Other artifact
New service file appears shortly afterward.
Supported conclusion
The service may have been installed as part of that package operation.
Severity
Operational severity is not forensic importance
Information
Often normal activity, but informational records can contain the exact evidence needed for a forensic question.
Warning
Indicates a condition that may need attention but is not automatically security-related.
Error
Shows that an operation failed or encountered a problem. Errors can explain outages or failed actions.
Critical
Represents severe operational conditions, but severity still does not replace forensic relevance.
Limitations
Know why log evidence can be incomplete
Logging may be disabled
A system can perform an action without the specific log source being enabled.
Logs rotate
Older records may be archived or overwritten when size or retention limits are reached.
Clocks can disagree
Different hosts may not share identical time settings.
Messages vary by version
Operating-system and application versions can change event wording or available fields.
Applications log differently
Some services use the system journal, some write files, and some maintain their own databases.
Logs can be changed
Do not assume every log is complete or untampered. Corroboration improves confidence.
Evidence note
Document a log event so another teammate can verify it
Question
Which account started the service?
Log source
Windows System log
Time window
10:15-10:25 local
Event
Record ID 4312 / relevant provider event
Observed fields
Time, provider, account, service name, message
Context
Related service-install event occurs two minutes earlier
Corroboration
Executable path and file timestamp align
Conclusion
Evidence supports that the service started under the recorded account
Common mistakes
Log-analysis habits that create weak conclusions
Searching without a question
You can waste time reading thousands of unrelated entries.
Using one matching line as the whole story
Neighboring events often change the meaning of the target event.
Ignoring source and host
A log entry is meaningless if you cannot identify which system or component produced it.
Treating severity as security importance
An informational event may be more forensically useful than a critical operational error.
Over-filtering
Too many filters can hide the evidence you need.
Ignoring time zones
Cross-source ordering becomes unreliable when time references differ.
Assuming missing logs mean no event
Retention, configuration, and logging gaps can create false absence.
Clearing logs before documentation
This destroys evidence and makes later questions harder to answer.
Fictional log lab
Build a short timeline from mixed evidence
User: student3
Successful interactive login.
User: student3
Downloaded tools.zip into the Downloads directory.
User: student3
tools.zip present with matching creation context.
User: student3
Task LabUpdater created to run every 30 minutes.
User: student3
updater.exe starts from the user's AppData directory.
User: student3
Process opens a connection to fictional server 203.0.113.20.
Task 01
Which record establishes the user session?
The 15:01:22 authentication record for student3.
Task 02
Which two records best support the download event?
The 15:03:09 browser record and the 15:04:17 filesystem evidence.
Task 03
What event adds persistence-style context?
The 15:06:41 scheduled task creation.
Task 04
What links the task to later activity?
The process start at 15:07:02 occurs shortly after task creation and uses a user-profile path.
Task 05
Can the network record alone prove malicious activity?
No. It shows a connection by a process. Purpose and legitimacy require more context.
Task 06
What should be preserved before disabling the task?
Task name, trigger, command, user, timestamps, related process evidence, file hash, and neighboring log records.
Lesson checklist
Before moving on
I know the exact forensic question before searching logs.
I choose the most likely log source first.
I define a reasonable time window.
I record host, source, timestamp, event identifier, and user where available.
I read neighboring events before drawing conclusions.
I distinguish relevant, supporting, expected, suspicious, unknown, and irrelevant records.
I do not treat severity as the same thing as forensic importance.
I keep track of the filters or commands I used.
I correlate important events with files, services, processes, users, or network evidence.
I account for time zones and clock differences.
I remember that missing records do not prove an event never happened.
I preserve logs before making changes that could alter or rotate them.
Reflection
Check your log-analysis reasoning
Question 1
Why is one matching log line usually weaker than a sequence of related events?
Question 2
What is the difference between an informational event and a forensically important event?
Question 3
Why should you record the log source and host with every important event?
Question 4
How can over-filtering hide useful evidence?
Question 5
Why does a missing event fail to prove that an action never occurred?
Question 6
What additional evidence would you use to strengthen a log-based conclusion?
Carry this forward
Start with a question, choose the right source, filter by time and relevant fields, read neighboring events, correlate with independent artifacts, and document the exact evidence used.