Forensics · Lesson 15
Archives, Hidden Files & Alternate Storage Awareness
Learn how archives, hidden items, application data folders, temporary locations, removable media, and network shares can preserve or obscure important forensic evidence.
The key is to preserve the original container and path context, then separate archive history from local extraction and actual execution evidence.
Lesson Snapshot
Learning objectives
Find evidence that ordinary views can miss
Explain how archives, hidden files, alternate paths, and non-obvious storage locations can complicate forensic review.
Recognize common Windows and Linux methods for hiding or obscuring files without assuming hidden automatically means malicious.
Preserve original archives before extraction and compare contained files using paths, timestamps, sizes, and hashes.
Inspect hidden and alternate-storage evidence safely without executing unknown content.
Correlate archive contents and hidden files with downloads, user profiles, scheduled tasks, services, and process evidence.
Document path, visibility state, ownership, timestamps, hash, and source before deleting, moving, or unhiding anything.
Core idea
Visibility and location change context, not truth
Hidden files and unusual paths deserve review, but the evidence still needs source, ownership, timestamps, hash, execution, and scenario context.
Competition caution
Preserve the archive before extraction
The original archive has its own hash and timestamps. Extraction creates new local state and can preserve older internal metadata.
Principles
Use hidden and archive evidence without overclaiming
Hidden does not mean malicious
Operating systems and applications routinely hide configuration, cache, and support files. Visibility is context, not a verdict.
Archives preserve internal history
Files inside ZIP, tar, and similar containers can carry timestamps and names that predate the local extraction event.
Path changes meaning
The same filename in Downloads, Temp, AppData, ProgramData, /tmp, ~/.config, or /opt can imply very different context.
Original container matters
The archive itself is evidence separate from the files extracted from it.
Alternate storage can hide in plain sight
Application folders, user-local directories, startup paths, removable media, network shares, and alternate data mechanisms can all hold relevant evidence.
Preserve before changing visibility
Renaming, moving, extracting, unhiding, or changing attributes can modify timestamps and metadata.
Archive evidence
Preserve both container and extracted content
Archive path
Shows where the container was stored on the local system.
Archive hash
Provides exact identity for the original container.
Archive timestamps
Places local appearance and later modification into the timeline.
Contained filename
Shows the name recorded inside the archive.
Internal path
Preserves directory structure stored in the container.
Internal timestamp
May reflect older source history rather than local extraction time.
Extracted path
Shows where the file appeared after extraction.
Extracted hash
Allows comparison to the archived content.
Extraction evidence
Connects the container to the newly created local files.
Archive reasoning
Separate container history from local history
ZIP created locally at 10:02, internal file mtime is 2024-04-01
Supported
The archive appeared locally at 10:02 while the file stored inside carries an older modification timestamp.
Not supported
The internal file necessarily existed on this computer in 2024.
Extracted file and archived copy have matching SHA-256
Supported
The extracted content is identical to the archived content.
Not supported
The extracted path is the original source location.
Archive filename changed but hash is identical
Supported
The archive content is unchanged despite the rename.
Not supported
The archive was never copied or moved.
Archive contains hidden-dotfile configuration
Supported
The container includes a hidden-style filename.
Not supported
The file is malicious because its name begins with a dot.
Extraction produces startup shortcut or autostart file
Supported
The extracted content can affect future startup if placed in an active startup location.
Not supported
The startup behavior actually occurred without separate execution evidence.
Windows hidden storage
Common visibility and storage mechanisms
Hidden attribute
Windows files and folders can carry the Hidden attribute and may not appear in default File Explorer views.
System attribute
System files can be hidden by default and should not be treated as suspicious solely because of that attribute.
AppData
Per-user application data is commonly stored under hidden profile locations.
ProgramData
Shared application data can contain service files, update data, logs, and configuration.
Alternate Data Streams
NTFS can store additional named data streams associated with a file. Awareness is useful, but their presence alone does not prove misuse.
Linux hidden storage
Common dotfile and user-storage locations
Dotfiles
Names beginning with a dot are hidden from ordinary directory listings unless hidden files are requested.
~/.config
Common per-user application configuration location.
~/.local
Common per-user application data and binaries location.
~/.cache
Application cache location that may contain temporary or automatically created data.
/tmp and /var/tmp
Temporary-storage areas that may contain legitimate or unexpected files.
Windows commands
Inspect hidden entries safely
Show hidden items
Get-ChildItem "C:\Users\trainee" -Force
Includes hidden and system-marked entries in PowerShell output.
Inspect attributes
Get-Item "C:\Users\trainee\AppData\Local\example.bin" | Format-List Name,FullName,Attributes,Length,CreationTime,LastWriteTime
Shows path, attributes, size, and timestamps.
Find hidden files
Get-ChildItem "C:\Users\trainee" -Recurse -Force -ErrorAction SilentlyContinue |
Where-Object { $_.Attributes -match "Hidden" }Finds hidden entries within a scoped user profile.
List NTFS streams
Get-Item "C:\Users\trainee\Documents\sample.txt" -Stream *
Lists alternate data streams associated with a selected NTFS file where supported.
Hash a file
Get-FileHash "C:\Users\trainee\AppData\Local\example.bin" -Algorithm SHA256
Provides exact content identity.
Linux commands
Inspect hidden entries safely
Show hidden entries
ls -la /home/trainee
Includes dotfiles and hidden directories.
Inspect one file
stat /home/trainee/.config/example/settings.conf
Shows ownership, permissions, size, and timestamps.
Find hidden files
find /home/trainee -name ".*" 2>/dev/null
Finds hidden-style names inside the selected user profile.
Identify file type
file /home/trainee/.local/bin/example
Checks actual file type without executing it.
Hash a file
sha256sum /home/trainee/.local/bin/example
Provides exact content identity.
Windows archives
List and hash before extraction
List ZIP contents
tar -tf "C:\Users\trainee\Downloads\evidence.zip"
Lists archive contents without extracting them on modern Windows systems where tar is available.
Hash the archive
Get-FileHash "C:\Users\trainee\Downloads\evidence.zip" -Algorithm SHA256
Preserves the original container identity.
Inspect archive metadata
Get-Item "C:\Users\trainee\Downloads\evidence.zip" | Format-List Name,FullName,Length,CreationTime,LastWriteTime
Records the archive's local metadata.
Linux archives
List and hash before extraction
List ZIP contents
unzip -l /home/trainee/Downloads/evidence.zip
Lists ZIP contents without extracting them.
List tar contents
tar -tf /home/trainee/Downloads/evidence.tar.gz
Lists archive contents without extraction.
Hash the archive
sha256sum /home/trainee/Downloads/evidence.zip
Preserves container identity.
Inspect archive metadata
stat /home/trainee/Downloads/evidence.zip
Shows local archive timestamps and ownership.
Alternate storage
Look beyond ordinary Downloads and Documents folders
C:\Users\<user>\AppData\LocalWindowsPer-user application data, caches, local settings, and sometimes executables.
C:\Users\<user>\AppData\RoamingWindowsUser profile data intended to follow the user in some environments.
C:\ProgramDataWindowsShared application data, service files, logs, and vendor directories.
C:\Windows\TempWindowsSystem temporary storage.
~/.configLinuxPer-user application configuration.
~/.localLinuxPer-user application data and binaries.
/tmp and /var/tmpLinuxTemporary storage with different retention behavior.
/optLinuxOptional or third-party software location.
Removable mediaBothUSB or external storage can introduce or remove files without browser or email evidence.
Network sharesBothFiles can arrive through shared storage without local download history.
Reasoning
Unusual storage is a clue, not a conclusion
File exists only in AppData
Supported
The file is stored in a per-user application-data location.
Not supported
The file is malicious because the directory is normally hidden.
Executable exists under ~/.local/bin
Supported
The executable is stored in a per-user binary location.
Not supported
The executable is unauthorized without package, user, and scenario context.
File arrived from USB
Supported
Removable media is a possible source path.
Not supported
The user intentionally executed the file.
File copied from network share
Supported
The network share can explain local arrival.
Not supported
The file originated on the local computer.
NTFS stream exists on sample.txt
Supported
The file has additional named stream data.
Not supported
The stream is malicious solely because it exists.
Question-to-evidence map
Use the right evidence for hidden and alternate-storage questions
Why did I not see the file in a normal directory view?
Hidden/system attribute, dotfile naming, permissions, or application-specific path.
Where did the hidden file come from?
Browser, email, archive extraction, package install, process, removable media, or share evidence.
Was it used?
Process execution, service/task references, application logs, or access evidence.
Is it the same content as another file?
SHA-256 comparison.
Did extraction change the timeline?
Archive internal timestamp versus local extraction timestamp.
Is the location expected?
Application/package context, scenario requirement, ownership, and startup/service references.
Correlation
Connect archives and hidden files to source and execution
Browser download at 09:02 + archive in Downloads + extraction into AppData at 09:05
Supported conclusion
The archive likely explains the later files under AppData.
Archive internal file mtime from 2024 + local extraction at 10:10
Supported conclusion
The older timestamp may reflect archive metadata rather than earlier local presence.
Hidden script in user profile + scheduled task points to same path + process runs later
Supported conclusion
The scheduler and process evidence connect the hidden file to actual execution.
Executable under ~/.local/bin + systemd user unit references it
Supported conclusion
The user-level service configuration explains recurring execution of that file.
File on USB + same SHA-256 appears later in Downloads
Supported conclusion
The local file content matches the removable-media copy.
Network share access + matching hash appears in ProgramData
Supported conclusion
The share can explain the local file's arrival path.
Preserve before action
Capture original archive, path, and visibility state
Record the original archive or container path.
Hash the original archive before extraction when practical.
List archive contents before extraction.
Record internal paths and timestamps.
Record hidden/system attributes or dotfile naming.
Record full path, owner, permissions, and timestamps.
Record actual file type.
Hash important extracted or hidden files.
Record startup, service, task, or cron references.
Record removable-media or network-share context if relevant.
Separate archive timestamps from local extraction timestamps.
Only then move, delete, unhide, or disable if appropriate.
Common mistakes
Archive and hidden-file mistakes that distort the timeline
Treating hidden as malicious
Many legitimate operating-system and application files are intentionally hidden.
Extracting before documenting
Extraction changes local filesystem state and can complicate the timeline.
Trusting archive timestamps as local history
Internal timestamps can predate local arrival by years.
Ignoring the original archive
The container is separate evidence with its own hash and timestamps.
Ignoring alternate paths
AppData, ProgramData, ~/.config, ~/.local, /tmp, and /opt can contain relevant artifacts.
Ignoring removable media or shares
Files can arrive without browser or email history.
Unhiding or moving evidence first
Changing attributes or paths can alter metadata and destroy original-state context.
Equating storage location with intent
An unusual path can justify review, but not a conclusion by itself.
Fictional archive & hidden-file lab
Reconstruct download, extraction, hidden storage, and execution
trainee9 downloads tools.zip to the Downloads directory.
tools.zip SHA-256 is HASH-A1 and contains scripts/check.ps1 with an internal mtime from 2024-03-01.
check.ps1 is extracted into C:\Users\trainee9\AppData\Local\ToolsLab\.
A related folder under ToolsLab is marked Hidden.
A fictional task references the extracted check.ps1 path.
PowerShell runs check.ps1 from the AppData path.
Task 01
What proves the archive existed before extraction?
The browser/download record and archive metadata at 10:01-10:02.
Task 02
Does the 2024 internal timestamp prove the script existed locally in 2024?
No. The older timestamp may have been preserved inside the archive.
Task 03
Does the Hidden attribute prove the folder is malicious?
No. It only changes visibility. Context, source, and usage still matter.
Task 04
What connects the extracted script to actual execution?
The scheduled-task reference plus the PowerShell process evidence at 10:10.
Task 05
Why preserve HASH-A1?
It identifies the original archive content and allows later comparison.
Task 06
What should be preserved before deleting the hidden folder?
Archive identity, contained paths/timestamps, extracted file metadata and hashes, hidden attribute state, scheduled-task configuration, and process evidence.
Lesson checklist
Before moving on
I preserve the original archive before extraction.
I record archive hash and local timestamps.
I list archive contents before extracting when practical.
I distinguish internal archive timestamps from local extraction times.
I record hidden/system attributes or dotfile naming.
I inspect AppData, ProgramData, ~/.config, ~/.local, and temp paths when relevant.
I record actual file type and SHA-256.
I correlate hidden files with tasks, services, cron, or processes.
I consider removable media and network shares as source paths.
I do not assume hidden means malicious.
I preserve original path and metadata before moving or deleting.
I record my own cleanup changes separately.
Reflection
Check your archive and hidden-file reasoning
Question 1
Why can an archive contain timestamps older than the local download?
Question 2
What evidence would you use to prove an extracted file actually executed?
Question 3
Why is a hidden attribute or dotfile name not enough to label a file suspicious?
Question 4
How can a hash connect a file on removable media to a local copy?
Question 5
Why should the original archive be preserved even after extraction?
Question 6
What storage locations would you review if a file did not come through a browser or email client?
Carry this forward
Preserve the container, separate internal timestamps from local history, treat hidden state as context, and connect alternate storage to source and execution evidence before cleanup.