Forensics · Lesson 13
Browser & Download Artifacts
Learn how browser history, download records, profiles, cache, local files, hashes, and later process activity work together to explain web and download activity.
A browser can prove browsing and download activity, but it does not automatically prove that a user trusted, opened, or executed the downloaded content.
Lesson Snapshot
Learning objectives
Connect web activity to local file and process evidence
Explain what browser and download artifacts can reveal without assuming they prove user intent.
Recognize common evidence such as browser history, downloads, cache, cookies, profiles, and downloaded files.
Connect a download record to a local file using filename, path, timestamps, size, and hash.
Distinguish browsing evidence from proof that a person intentionally opened, trusted, or executed a file.
Correlate browser artifacts with file metadata, process evidence, authentication records, and network activity.
Preserve browser and download evidence before deleting files, clearing history, or changing profiles.
Core idea
Browsing, downloading, opening, and executing are different claims
Each claim requires different evidence. Avoid turning a browser record into a stronger conclusion than the artifacts support.
Competition caution
Preserve browser evidence before cleanup
Clearing history or deleting downloads can remove useful evidence. Record the browser profile, URLs, download path, timestamps, file metadata, and hashes first.
Browser principles
Use web artifacts without overclaiming
History is activity evidence, not intent
A browser record can show that a page was visited or requested, but it does not automatically explain why.
Downloads create multiple artifacts
A download can leave browser history, a download record, a local file, filesystem timestamps, and later process or application evidence.
Filename is not identity
A downloaded file can be renamed, moved, copied, or replaced. Use hashes and metadata when exact content identity matters.
Profiles matter
Browser evidence usually belongs to a specific browser profile, which can help connect activity to a local account context.
Automatic activity exists
Browsers load background resources, prefetch content, update extensions, and create cache entries without direct user action.
Preserve before cleanup
Clearing history, deleting downloads, or resetting a profile can remove the evidence needed to answer later questions.
Artifact types
Know what each browser artifact can tell you
Browsing history
Visited URLs, page titles, and timestamps depending on the browser.
Caution
A record shows browser activity, not necessarily deliberate reading or approval.
Download history
Downloaded filename, source URL, destination path, timestamp, status, and size where available.
Caution
A browser record may remain even if the file was later moved or deleted.
Cache
Locally stored web resources used to speed future browsing.
Caution
Cached content can be created automatically and does not prove the user intentionally saved it.
Cookies
Site state, session identifiers, preferences, and tracking data.
Caution
Cookies can show site interaction but should not be treated as credentials or exposed unnecessarily.
Browser profile
History, settings, extensions, bookmarks, saved state, and application-specific databases.
Caution
A browser profile can persist after account or browser changes.
Local downloaded file
File path, size, timestamps, type, ownership, permissions, and hash.
Caution
File presence alone does not prove it was opened or executed.
Evidence chain
Move from browser record to later activity
Find the browser record
Identify source URL, timestamp, filename, destination, browser profile, and download status where available.
Find the local file
Check the expected download path, full filename, size, timestamps, ownership, and actual file type.
Hash the file
Record SHA-256 when exact content identity matters.
Look for later activity
Check whether an application, process, service, task, or script used the file after download.
Correlate the user session
Use authentication and profile context to establish which account session existed at the time.
Answer only what the evidence supports
Separate downloaded, opened, executed, modified, and trusted because each requires different evidence.
Windows paths
Common user-profile evidence locations
C:\Users\<user>\DownloadsDefault location for many user downloads.
C:\Users\<user>\AppData\LocalCommon location for Chromium-based browser profile data and caches.
C:\Users\<user>\AppData\RoamingSome browser and application profile data may appear here.
Browser profile directoriesProfile-specific history, downloads, cache, extensions, and state.
Linux paths
Common user-profile evidence locations
/home/<user>/DownloadsCommon default download directory for desktop Linux users.
~/.configCommon location for browser configuration and profile data.
~/.cacheCommon location for browser cache data.
~/.mozilla / browser-specific profile pathsApplication-specific user profile information depending on browser.
Windows file review
Inspect downloaded artifacts
Inspect a downloaded file
Get-Item "C:\Users\trainee\Downloads\sample.zip" | Format-List Name,FullName,Length,CreationTime,LastWriteTime,LastAccessTime,Attributes
Shows common file metadata.
Hash a downloaded file
Get-FileHash "C:\Users\trainee\Downloads\sample.zip" -Algorithm SHA256
Provides exact content identity for later comparison.
Search profile for a filename
Get-ChildItem "C:\Users\trainee" -Filter "sample.zip" -Recurse -Force -ErrorAction SilentlyContinue
Finds matching filenames under a scoped user profile.
Review process evidence
Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId,Name,ExecutablePath,CommandLine
Helps determine whether a downloaded file or related application was later executed.
Linux file review
Inspect downloaded artifacts
Inspect a downloaded file
stat /home/trainee/Downloads/sample.zip
Shows size, ownership, permissions, and timestamps.
Hash a downloaded file
sha256sum /home/trainee/Downloads/sample.zip
Provides exact content identity.
Identify actual file type
file /home/trainee/Downloads/sample.zip
Checks content type instead of trusting the filename extension.
Find matching files
find /home/trainee -name "sample.zip" 2>/dev/null
Searches the selected user profile for copies or moved versions.
Question-to-evidence map
Use the right artifact for each browser question
Was the site visited?
Strongest evidence
Browser history or application-specific browsing database.
Supporting
Cache, cookies, DNS/application logs, and user session context.
Was a file downloaded?
Strongest evidence
Browser download record plus matching local file.
Supporting
File creation context, source URL, size, timestamp, and hash.
Was the file opened?
Strongest evidence
Application history, recent-file records, process evidence, or application logs.
Supporting
Access-time information only where meaningful.
Was the file executed?
Strongest evidence
Process execution evidence, service/task launch evidence, or execution logs.
Supporting
Browser download history and file presence do not prove execution.
Was the file modified?
Strongest evidence
Hash comparison and file modification evidence.
Supporting
Application logs, process timeline, and LastWriteTime/mtime.
Which user profile was involved?
Strongest evidence
Browser profile path plus OS account/profile context.
Supporting
Authentication records and file ownership.
Reasoning
Separate downloaded from opened or executed
Browser shows file.zip downloaded at 10:04
Supported
The browser recorded a download event for file.zip at that time.
Not supported
The user trusted, opened, or executed the file.
Matching file exists in Downloads at 10:04
Supported
The local file aligns with the browser download record.
Not supported
The file remained unchanged after download.
Browser record and local file have matching size
Supported
The artifacts are consistent with one another.
Not supported
The files are byte-for-byte identical without a hash comparison.
Downloaded file later appears in AppData with same SHA-256
Supported
The content is identical despite the changed path.
Not supported
The user intentionally copied it without additional evidence.
Process starts from the downloaded path
Supported
The file at that path was executed as a process.
Not supported
The execution was malicious or intentional without more context.
Cache contains content from a site
Supported
The browser stored content associated with that site.
Not supported
The user intentionally saved or viewed every cached object.
Browser profiles
Connect browser data to user context
Which browser profile?
Record the profile directory or browser account context if available.
Which OS account?
Map the profile directory back to the Windows or Linux user account.
Was the session active?
Use authentication and session evidence around the browser timestamp.
Was more than one profile present?
Multiple browser profiles can exist under the same operating-system account.
Was sync enabled?
Synced history or bookmarks can complicate assumptions about which device originated an artifact.
Cache cautions
Why cache does not equal deliberate action
Automatic fetches
Browsers can retrieve images, scripts, advertisements, icons, and background resources automatically.
Prefetching
Some browsers may retrieve resources before a user explicitly opens the destination.
Service workers
Web applications can store resources for offline or background behavior.
Extensions
Browser extensions can make web requests that are not direct user navigation.
Cache eviction
Older cache entries can disappear automatically as space is reused.
Cookies & sessions
Handle site-state evidence carefully
Cookies show site state
They can indicate that the browser interacted with a site or maintained a session.
Do not expose secrets
Session cookies and tokens can be sensitive. Training notes should describe evidence without publishing live secrets.
Cookie presence is not account ownership
A cookie can exist because someone authenticated, a session was restored, or an application created site state.
Correlate with account context
Use browser profile, OS user session, and site/application evidence together.
Filename & path
Track content even when location or name changes
Same filename in Downloads and Temp, different hashes
The files are different content despite matching names.
Different names, same SHA-256
The file content is the same despite rename or copy.
Download record points to Downloads, file now in AppData
The file may have been moved or copied after download.
Download history exists but file is missing
The browser recorded the download, but the local file may have been moved, deleted, quarantined, or cleaned.
File exists but no browser download record
It may have arrived through another browser, application, archive extraction, network share, USB, or another method.
Correlation
Combine browser, file, session, and process evidence
Browser download at 09:15 + local file creation at 09:15 + matching filename and size
Supported conclusion
The local file is consistent with the recorded browser download.
Download at 10:02 + task creation at 10:05 + task launches downloaded script at 10:10
Supported conclusion
The browser, scheduler, and process evidence form a coherent execution chain.
Browser history visit at 11:00 + no download record + no local file
Supported conclusion
The page was visited, but there is no direct evidence here that a file was downloaded.
Download record + local file hash + Defender detection referencing same path/hash
Supported conclusion
The browser, file, and security-product records refer to the same content.
Download at 12:20 + RDP session active + process starts at 12:25
Supported conclusion
The download and execution occurred during the remote interactive session.
Downloaded archive + extracted script with older mtime + extraction event later
Supported conclusion
The older script timestamp may have been preserved from the archive rather than representing earlier local existence.
Evidence note
Preserve the browser-to-file chain
Browser name and profile
OS user account
History URL and title
Download source URL
Download filename
Destination path
Download timestamp and zone
Download status and size
Local file metadata
Actual file type
SHA-256 hash
Related process/application evidence
Related authentication/session evidence
Common mistakes
Browser-analysis mistakes that create false conclusions
Equating visit with intent
A page visit does not explain why the browser loaded it.
Equating download with execution
A browser download record does not prove the file was opened or run.
Trusting filenames
Files can be renamed or replaced. Use hashes when exact identity matters.
Ignoring browser profile
Multiple profiles can exist under one operating-system account.
Treating cache as deliberate saving
Cache entries are often created automatically.
Ignoring archive extraction
Extracted files can preserve older internal timestamps and create misleading timelines.
Clearing browser data first
This can destroy history, download, and profile evidence.
Recording sensitive session tokens
Preserve evidence conceptually without exposing live credentials or cookies.
Fictional browser lab
Reconstruct browsing, download, extraction, and execution
trainee7 begins a fictional Windows interactive session.
The browser visits https://training.example/resources.
utilities.zip is downloaded to C:\Users\trainee7\Downloads\utilities.zip.
utilities.zip appears locally with size 84 KB and SHA-256 HASH-U1.
helper.ps1 is extracted into C:\Users\trainee7\AppData\Local\Temp\UtilityLab\.
PowerShell runs helper.ps1 from the extracted temporary directory.
Task 01
What proves the browser visited the training page?
The browser-history record at 15:08.
Task 02
What best proves utilities.zip was downloaded?
The browser download record plus the matching local file at the recorded destination.
Task 03
What does HASH-U1 add?
It provides exact content identity for utilities.zip.
Task 04
Does the browser record prove helper.ps1 was executed?
No. The later PowerShell process evidence establishes execution.
Task 05
Why is the Temp extraction path useful?
It connects the extracted script to a specific local location and later process command line.
Task 06
What should be preserved before deleting the archive or script?
Browser history/download record, file paths, timestamps, sizes, hashes, extraction context, PowerShell process evidence, and session context.
Lesson checklist
Before moving on
I distinguish browsing, downloading, opening, and executing.
I record browser name and profile context.
I record the source URL and download destination.
I compare download record time with local file metadata.
I record file size and actual type.
I use SHA-256 when exact file identity matters.
I correlate later process or application activity.
I account for archive extraction and timestamp preservation.
I treat cache and cookies cautiously.
I use authentication evidence to place browser activity in a user session.
I preserve browser records before cleanup.
I avoid exposing sensitive cookies, tokens, or credentials.
Reflection
Check your browser-artifact reasoning
Question 1
Why does a browser download record fail to prove execution?
Question 2
What evidence would you use to prove a downloaded file later ran?
Question 3
Why can browser cache be misleading if interpreted as deliberate user action?
Question 4
How can hashes connect a renamed or moved file to the original download?
Question 5
Why can archive extraction create confusing timestamps?
Question 6
What evidence would you preserve before clearing a browser profile?
Carry this forward
Separate browsing from downloading and execution, connect the browser record to the local file, use hashes for identity, and preserve profile evidence before cleanup.