Forensics · Lesson 04

File Systems & Important Paths

Learn where Windows and Linux commonly store user data, system files, application state, logs, temporary artifacts, startup entries, and configuration so you can search for evidence efficiently and interpret location correctly.

The same filename can tell a completely different story depending on whether it appears in Program Files, Downloads, AppData, /usr, /home, /tmp, or an automatic-start location.

Lesson Snapshot

PlatformsWindows + Linux

Main clueFull path

Key contextUser vs system

GoalSearch efficiently

Learning objectives

Know where evidence is likely to live

Explain why filesystem location is a major part of forensic context.

Recognize important Windows and Linux directories that commonly contain user, system, application, log, startup, and temporary evidence.

Distinguish system-wide locations from per-user locations.

Understand why the same filename can have very different meaning depending on its path.

Use directory structure, ownership, permissions, and application conventions to guide evidence collection.

Avoid deleting or moving artifacts before their original locations are documented.

Core idea

The directory is part of the evidence

A file's path often tells you whether it belongs to the operating system, an installed application, a user profile, temporary storage, or an automatic-start mechanism.

Competition caution

Location is context, not a verdict

A file in Temp, AppData, /tmp, or a hidden directory is not automatically malicious. Use ownership, timestamps, hashes, logs, process activity, and scenario requirements to corroborate.

Path principles

Use filesystem structure as investigative context

Path changes meaning

A file named updater.exe in a trusted application directory means something different from the same name in Downloads, Temp, or a user startup folder.

User and system scope differ

Per-user folders describe one profile's activity, while system-wide directories may affect every account on the machine.

Applications leave traces

Browsers, office tools, messaging apps, security products, and services often maintain logs, caches, profiles, history, or configuration files in predictable locations.

Temporary does not mean irrelevant

Temporary directories can contain installers, extracted files, scripts, caches, or short-lived artifacts useful for reconstruction.

Hidden does not mean malicious

Operating systems and applications legitimately hide many files and directories. Concealment is only one clue.

Document before cleanup

Record the original path, name, owner, timestamps, permissions, and hash where useful before moving or deleting anything.

Windows system paths

Know the major operating-system and application locations

C:\Windows

Core operating system files, logs, services, drivers, updates, and system components.

Forensic value

Useful for system configuration, event artifacts, service binaries, temporary update data, and operating-system context.

C:\Windows\System32

Important Windows executables, libraries, administrative tools, drivers, and configuration resources.

Forensic value

Path context matters because many legitimate Windows processes run from here. A similarly named binary elsewhere may deserve closer review.

C:\Windows\Temp

System-level temporary storage.

Forensic value

May contain installer remnants, temporary scripts, extracted files, or short-lived application artifacts.

C:\Program Files

Primary location for installed 64-bit applications.

Forensic value

Useful for validating expected application paths, installed software, service executables, and application configuration.

C:\Program Files (x86)

Common location for 32-bit applications on 64-bit Windows.

Forensic value

Helpful when comparing installed software, process paths, and application versions.

C:\ProgramData

Shared application data for all users.

Forensic value

Can contain service configuration, application logs, caches, databases, updater data, and shared state.

Windows user profile

Per-user paths can reconstruct user activity

C:\Users\<user>

Root of a Windows user profile.

Ownership, profile-specific activity, personal files, browser data, and application settings.

Desktop

Files intentionally placed on the user's desktop.

Documents, shortcuts, tools, scripts, or training artifacts associated with the profile.

Downloads

Default location for many browser and application downloads.

Useful for correlating downloaded files with browser history, timestamps, hashes, and later execution evidence.

Documents

Common storage for user-created documents and project files.

Document metadata, recent activity, archives, scripts, or saved output.

AppData\Roaming

Per-user application data designed to roam with a domain profile.

Application settings, profiles, startup shortcuts, caches, and user-specific configuration.

AppData\Local

Per-user local application data.

Browser profiles, caches, temp-like application data, logs, databases, and local state.

AppData\LocalLow

Per-user low-integrity application data.

Some applications store sandboxed or restricted-profile data here.

AppData\Local\Temp

Per-user temporary storage.

Temporary installers, extracted content, working files, caches, and transient artifacts.

Windows startup

Automatic-start locations

User Startup Folder

C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Programs or shortcuts here can launch when that user signs in.

All Users Startup Folder

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

Items here can affect multiple users.

Task Scheduler

Administrative interface and stored task definitions

Scheduled execution can launch programs or scripts at logon, startup, time intervals, or events.

Services

Service Control Manager configuration and service executable paths

Services can start automatically and run under specific accounts.

Windows logs

Common evidence sources

Windows Event Logs

Viewed through Event Viewer; underlying .evtx files are typically stored under C:\Windows\System32\winevt\Logs

Security, System, Application, and specialized event channels.

Windows Defender

Event Viewer channels and Defender-related operational logs

Detection, scan, remediation, and protection activity where logging is available.

Application logs

Varies by software; commonly under ProgramData, AppData, or the application's install directory

Application-specific events, errors, update history, user activity, and service state.

PowerShell logs

Event Viewer channels when the relevant logging features are enabled

Can provide command and script activity depending on configuration.

Linux system paths

Know the major configuration, log, software, and temporary locations

/etc

System-wide configuration.

Forensic value

Accounts, authentication, services, network settings, scheduled jobs, application configuration, and policy.

/var

Variable system data.

Forensic value

Logs, caches, spool data, application state, package metadata, and service data.

/var/log

Traditional Linux log directory.

Forensic value

Authentication, system, service, package, kernel, and application logs depending on distribution and configuration.

/home

Regular user home directories.

Forensic value

Documents, downloads, shell history, hidden application directories, SSH data, browser profiles, and user scripts.

/root

Home directory for the root account.

Forensic value

Administrative shell history, scripts, configuration, and root-owned user artifacts.

/tmp

Temporary storage generally available to users and applications.

Forensic value

Transient files, extracted content, scripts, sockets, temporary application data, and installers.

/usr

Installed user-space programs, libraries, documentation, and shared data.

Forensic value

Useful for validating expected executable paths and installed software structure.

/opt

Optional or third-party software.

Forensic value

May contain manually installed or vendor applications outside the normal package layout.

Linux user paths

Home directories contain high-value user evidence

/home/<user>

User profile root.

Personal files, downloads, hidden application settings, shell history, SSH data, scripts, and configuration.

~/Downloads

Common user download directory.

Downloaded archives, installers, documents, and browser-linked evidence.

~/.config

Per-user application configuration under common desktop conventions.

Application settings, autostart entries, profiles, and user configuration.

~/.local

Per-user local data and installed content.

User-local applications, state, binaries, shares, caches, and application data.

~/.cache

Per-user application cache.

Temporary but potentially useful records of application activity.

~/.ssh

Per-user SSH configuration and keys.

Authorized keys, known hosts, client configuration, and key material. Handle secrets carefully.

~/.bash_history

Common Bash command history file.

May show prior interactive commands, but coverage is incomplete and depends on shell behavior and configuration.

Linux startup

Automatic and scheduled execution locations

systemd system services

/etc/systemd/system and distribution-managed unit locations

Services and timers may start at boot or on triggers.

User systemd services

~/.config/systemd/user

Per-user service and timer definitions.

Cron

/etc/crontab, /etc/cron.*, and user crontabs

Scheduled commands and recurring jobs.

Desktop autostart

~/.config/autostart and system-wide autostart locations

Graphical-session programs may launch automatically after login.

Shell startup files

~/.profile, ~/.bashrc, ~/.bash_profile, and related shell files

Commands can execute during login or shell startup depending on the shell and file.

Linux logs

Common system and authentication evidence

systemd journal

Queried with journalctl

Boot, service, kernel, authentication, and application events depending on configuration.

Authentication logs

/var/log/auth.log on many Debian/Ubuntu-family systems

Syslog

/var/log/syslog on many Ubuntu-family systems

General system and service messages where rsyslog-style logging is enabled.

Package logs

/var/log/apt and related package-management logs

Install, upgrade, and package-management activity.

Path comparison

Same-looking names can have very different context

update.exe in C:\Program Files\VendorApp\

Could be a legitimate vendor component. Validate signature, hash, installation context, service mapping, and logs.

update.exe in C:\Users\student\Downloads\

User-space download context. Correlate browser history, timestamps, ownership, and execution evidence.

update.exe in C:\Users\student\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\

The path adds automatic-start context and deserves review before any cleanup.

update.sh in /usr/local/bin

Could be an administrator-installed utility. Check ownership, package/source context, permissions, and related services.

update.sh in /tmp

Temporary location. Record timestamps, owner, content hash, process evidence, and related logs.

update.sh in ~/.config/autostart

User login persistence context. Preserve the file and desktop entry details before changing it.

Windows commands

Inspect paths without changing them

List directory including hidden items

Get-ChildItem "C:\Users\trainee\Downloads" -Force

Shows normal and hidden items in a target directory.

Show detailed file properties

Get-Item "C:\Users\trainee\Downloads\sample.zip" | Format-List *

Provides path, size, timestamps, attributes, and other available metadata.

Search recursively by filename

Get-ChildItem "C:\Users\trainee" -Filter "sample.zip" -Recurse -Force -ErrorAction SilentlyContinue

Finds matching files under an authorized profile while suppressing inaccessible-path noise.

Show environment paths

$env:USERPROFILE
$env:APPDATA
$env:LOCALAPPDATA
$env:TEMP

Quickly identifies current-user profile, roaming data, local data, and temp locations.

Linux commands

Inspect directories and metadata safely

List including hidden entries

ls -la /home/trainee/Downloads

Shows ownership, permissions, size, timestamp, and hidden items.

Inspect detailed metadata

stat /home/trainee/Downloads/sample.zip

Displays size, ownership, permissions, inode, and timestamp fields.

Find a filename

find /home/trainee -name "sample.zip" 2>/dev/null

Searches the authorized home directory while hiding permission errors.

Show home and temp locations

echo "$HOME"
echo "${TMPDIR:-/tmp}"

Identifies common current-user storage locations.

Ownership & permissions

Path evidence becomes stronger when access context is included

Owner

Windows

NTFS ownership and ACLs help identify who controls the object.

Linux

User and group ownership are shown by tools such as ls -l and stat.

Permissions

Windows

NTFS ACLs can grant or deny access to users and groups.

Linux

Read, write, and execute bits plus ACLs determine access.

Executable path

Windows

Processes and services should be tied to the actual binary path, not only a display name.

Linux

Resolve the executable path and package or installation source where practical.

System vs user location

Windows

Program Files and Windows directories have different trust and privilege context from user profile folders.

Linux

/usr and /etc differ in purpose from /home and /tmp.

Hidden items

Hidden is a display choice, not a verdict

Windows

Hidden and system attributes, AppData, protected operating-system files, application caches.

Many legitimate Windows files are hidden by design.

Linux

Dotfiles and dot-directories such as .config, .ssh, .cache, and .local.

A leading dot is a normal Unix convention, not evidence of malicious intent.

Temporary artifacts

Short-lived files can still explain the timeline

Installer remnants

Can help explain when software was installed or updated.

Extracted archives

May reveal the relationship between a downloaded archive and later files.

Application caches

Can preserve traces of documents, webpages, or application activity.

Temporary scripts

May show automation or setup activity, but require context before conclusions.

Crash or error files

Can contain timestamps, application names, or diagnostic details.

Temporary copies

Applications sometimes create working copies whose metadata differs from the original.

Common mistakes

Filesystem mistakes that weaken forensic reasoning

Searching the whole disk first

Start with the question and likely evidence location. Broad searches can waste competition time.

Ignoring the full path

A filename without its directory loses essential context.

Deleting temp files automatically

Temporary directories can contain valuable evidence and should be documented before cleanup.

Treating hidden files as suspicious by default

Hidden files and dotfiles are normal parts of both Windows and Linux environments.

Confusing user data with system data

Profile-specific evidence and system-wide configuration answer different questions.

Assuming Program Files or /usr means trusted

Location is only one factor. Validate ownership, package context, hashes, signatures where applicable, and logs.

Ignoring application-specific folders

Important evidence may live under AppData, ProgramData, ~/.config, ~/.local, or application-specific directories.

Changing permissions before documenting them

Ownership and ACLs may themselves answer forensic questions.

Fictional path lab

Use directory location to reconstruct activity without overclaiming

F-01Windows

C:\Users\student1\Downloads\inventory.zip

Archive created at 11:03 in the user Downloads folder.

F-02Windows

C:\Users\student1\AppData\Local\Temp\inventory\run.ps1

Script appears two minutes later under the user's temporary directory.

P-01Windows

C:\Users\student1\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\inventory.lnk

Startup shortcut references a script under the user's profile.

L-01Linux

/home/analyst/Downloads/package.tar.gz

Archive appears in the analyst account's Downloads directory.

L-02Linux

/tmp/package/install.sh

Temporary extraction contains a shell script.

L-03Linux

/home/analyst/.config/autostart/package.desktop

Desktop autostart entry references a user-local script.

Task 01

Which paths provide download context?

F-01 and L-01 because both artifacts are in user Downloads directories.

Task 02

Which paths add temporary-extraction context?

F-02 and L-02 because both sit in temporary storage associated with extracted or transient content.

Task 03

Which paths add automatic-start context?

P-01 and L-03 because they are located in Windows Startup and Linux desktop autostart locations.

Task 04

Do these paths alone prove malicious intent?

No. They establish location and execution context. Logs, hashes, user activity, process evidence, and scenario requirements are still needed.

Task 05

What should be recorded before removing the startup entries?

Exact path, target command, user, timestamps, file hash where useful, related logs, and the evidence connecting the entry to the question.

Task 06

Why does the same filename mean little without its path?

The directory indicates whether the file is part of an installed application, a user download, temporary data, or an automatic-start location.

Lesson checklist

Before moving on

I record the full original path of every relevant artifact.

I distinguish system-wide paths from user-specific paths.

I know the important Windows profile locations.

I know the important Linux home-directory locations.

I recognize common Windows and Linux startup locations.

I recognize common Windows and Linux log locations.

I treat temporary directories as possible evidence sources.

I understand that hidden does not automatically mean malicious.

I record ownership and permissions before changing them.

I use hashes when exact file-content identity matters.

I correlate path evidence with logs, browser records, processes, or services.

I preserve important artifacts before cleanup.

Reflection

Check your path reasoning

Question 1

Why does a path often matter as much as a filename?

Question 2

What is the difference between a user-specific directory and a system-wide directory?

Question 3

Why can temporary folders contain strong forensic evidence?

Question 4

Why is a file in a startup location more interesting than the same file in Documents?

Question 5

Why should hidden files not automatically be considered malicious?

Question 6

What evidence should you record before moving or deleting a suspicious file?

Carry this forward

Record the full path, understand what that directory normally contains, distinguish user from system scope, and combine location with ownership, timestamps, hashes, logs, and process evidence.

Back to Forensics CyberPatriot Hub

← Previous Lesson Next Lesson →