Forensics · Lesson 05
File Metadata & Timestamps
Learn how filenames, paths, extensions, sizes, ownership, permissions, attributes, hashes, and timestamps work together to describe a file without overclaiming what any one field proves.
Timestamp interpretation is one of the easiest places to make a forensic mistake. Copying, extraction, editing, restoration, and filesystem behavior can all change what a time value means.
Lesson Snapshot
Learning objectives
Read metadata without turning clues into conclusions
Explain the difference between file metadata and file content.
Interpret common file timestamps without assuming they always represent user actions.
Understand how copying, extracting, downloading, editing, and restoring files can affect timestamp meaning.
Use size, ownership, permissions, extension, attributes, and path as supporting forensic context.
Compare Windows and Linux timestamp behavior at a practical competition level.
Correlate metadata with logs, browser activity, hashes, and process evidence before drawing conclusions.
Core idea
Metadata describes context around content
Metadata can explain where a file is, who owns it, when certain filesystem events occurred, and how the object is configured. It does not automatically explain who performed an action or why.
Timestamp warning
A timestamp is only meaningful when its type is known
Creation, modification, access, metadata-change, event, and download times can represent completely different actions. Always label the type before using the time in a timeline.
Metadata fields
Know what each field can and cannot tell you
Filename
The visible name assigned to the file.
Caution
Names can be changed and do not prove content, origin, or intent.
Extension
The suffix commonly used to suggest file type, such as .txt, .zip, .exe, or .pdf.
Caution
Extensions can be misleading. A renamed file may not match the type implied by its extension.
Path
The directory location of the artifact.
Caution
Location gives important context but does not by itself prove legitimacy or maliciousness.
Size
The number of bytes stored in the file.
Caution
Two different files can have the same size, so size is not a strong identity field alone.
Owner
The account associated with ownership of the object.
Caution
Ownership does not automatically prove who created, downloaded, or intentionally used the file.
Permissions
Rules controlling who can read, write, execute, modify, or delete the file.
Caution
Changing permissions before documenting them can destroy useful evidence.
Attributes
Flags such as hidden, read-only, archive, or system on Windows, plus filesystem-specific metadata.
Caution
Hidden or read-only status is not automatically suspicious.
Hash
A cryptographic digest representing exact file content.
Caution
Useful for content identity, but not for proving why the file exists.
Timestamp types
Different clocks answer different questions
Creation / Birth
A timestamp associated with when a filesystem entry was created, where the filesystem exposes this field.
Competition note
Copying or extraction can create a new file and therefore a new creation-style timestamp.
Modification
When file content was last changed.
Competition note
Editing a document, changing script content, or rewriting an archive can update modification time.
Access
When the file was last accessed, if the operating system and filesystem track or update this field.
Competition note
Access-time behavior varies widely and may be disabled, delayed, or optimized.
Metadata Change
A timestamp reflecting changes to metadata such as permissions, ownership, or other inode-style fields on many Unix-like filesystems.
Competition note
Linux ctime is not file-creation time.
Windows timestamps
Practical interpretation
CreationTime
Represents when the current filesystem entry was created. Copying a file to a new location can produce a new creation time.
LastWriteTime
Represents when file contents were last written.
LastAccessTime
Represents access-time information, but Windows may delay or limit updates for performance reasons.
Time zones
Tools may display local time even when underlying storage or logs use another representation. Record the display context.
Archive extraction
Extracted files may preserve some internal archive times while receiving new filesystem creation context.
Copy operations
Different copy tools and destinations can affect timestamps differently, so avoid assuming one universal behavior.
Linux timestamps
Practical interpretation
mtime
Modification time: when file contents were last changed.
atime
Access time: when file data was last read, subject to mount options and update policies.
ctime
Metadata-change time: when inode metadata changed. It is not creation time.
Birth time
Some Linux filesystems and tools expose file birth/creation time, but support is filesystem-dependent.
stat output
The stat command is useful because it shows multiple timestamp fields, ownership, permissions, size, and inode information together.
Timezone context
Command output typically follows the system's configured time zone unless a tool specifies otherwise.
Timestamp interpretation
Replace assumptions with evidence-backed language
A file creation time matches a browser download time.
Weak conclusion
The browser definitely created the file.
Better conclusion
The timestamps align and support a possible relationship. Correlate with the browser download record, path, hash, and user profile.
A file modification time is later than its creation time.
Weak conclusion
The user manually edited it.
Better conclusion
The file content changed after the current entry was created. Additional evidence is needed to determine what changed it.
A Linux ctime is recent.
Weak conclusion
The file was created recently.
Better conclusion
Metadata changed recently. Check mtime, birth time where available, logs, and surrounding activity.
A file access time is recent.
Weak conclusion
A person opened the file.
Better conclusion
The filesystem recorded recent access, but the accessing process and reason require more evidence.
An extracted file has an older modification time than the archive download time.
Weak conclusion
The file existed on this computer before the archive was downloaded.
Better conclusion
The archive may have preserved the internal file modification time. Use extraction context and creation-style timestamps.
Two files have identical timestamps.
Weak conclusion
They were created by the same action.
Better conclusion
They share timestamp values. Hashes, paths, logs, and process evidence are needed to connect them.
Windows commands
Inspect metadata without changing it
Basic file metadata
Get-Item "C:\Users\trainee\Downloads\sample.zip" | Format-List Name,FullName,Length,CreationTime,LastWriteTime,LastAccessTime,Attributes
Shows common Windows metadata fields in one place.
Owner
(Get-Acl "C:\Users\trainee\Downloads\sample.zip").Owner
Shows the NTFS owner associated with the object.
Permissions
Get-Acl "C:\Users\trainee\Downloads\sample.zip" | Format-List
Displays owner and access-control information without changing it.
Hash
Get-FileHash "C:\Users\trainee\Downloads\sample.zip" -Algorithm SHA256
Adds strong content-identity evidence to the metadata record.
Linux commands
Inspect metadata and actual type
Detailed metadata
stat /home/trainee/Downloads/sample.zip
Shows size, ownership, permissions, inode information, and multiple timestamp fields.
Directory listing
ls -lah /home/trainee/Downloads
Provides a quick view of names, permissions, ownership, size, and modification times.
File type
file /home/trainee/Downloads/sample.zip
Examines file-content signatures to help compare actual type with the filename extension.
Hash
sha256sum /home/trainee/Downloads/sample.zip
Records a SHA-256 digest for exact content comparison.
Extensions vs actual type
Do not trust the filename suffix alone
notes.txtPlain text, script content, binary data, or another file type renamed with .txt.
Better check
Inspect safely with metadata-aware tools and file-type identification without executing unknown content.
photo.jpgJPEG image, renamed archive, or unrelated content.
Better check
Use file-type inspection and hashes; do not trust the extension alone.
report.pdfPDF document or a renamed file.
Better check
Validate actual file type and inspect only with safe, appropriate tools.
update.exeExecutable content, but legitimacy depends on path, signature, hash, source, and behavior.
Better check
Document path, hash, owner, timestamps, and related process or service evidence before any change.
File transformations
Copying, extraction, editing, and restoration can change metadata meaning
Copy file to another directory
The destination entry may receive a new creation-style timestamp while preserving or changing other times depending on tool and filesystem.
Lesson
Do not assume the destination's creation time equals the original file's historical creation.
Extract file from archive
The extracted file may inherit archive-stored modification time while receiving new local filesystem context.
Lesson
An old modification time does not prove the file existed locally before extraction.
Edit file content
Modification time and hash usually change.
Lesson
Use both metadata and hash to distinguish content change from simple renaming.
Rename file
Content may remain identical while path or metadata changes.
Lesson
A hash can show that renamed content stayed the same.
Change permissions
Linux ctime or Windows metadata/ACL context may change without changing file content.
Lesson
Metadata can change even when the hash remains identical.
Restore from backup
Restoration software may preserve some historical timestamps and recreate others.
Lesson
Backup and restore context matters when interpreting time evidence.
Question-to-evidence map
Pick the field that actually answers the question
Did the file content change?
Strongest evidence
Compare secure hashes and modification context.
Supporting evidence
LastWriteTime or mtime, application logs, process activity.
Did the file move or get copied?
Strongest evidence
Compare paths, hashes, creation-style timestamps, and filesystem context.
Supporting evidence
Logs, shell history, browser activity, application records.
Who owns the file?
Strongest evidence
Filesystem ownership or ACL information.
Supporting evidence
Account and group records.
Was the file downloaded?
Strongest evidence
Browser or application download history.
Supporting evidence
Path in Downloads, creation time, hash, user activity.
Was the file opened?
Strongest evidence
Application history, recent-file records, process evidence, or logs.
Supporting evidence
Access time only as supporting evidence where meaningful.
Is the extension truthful?
Strongest evidence
File-content type inspection and safe structural analysis.
Supporting evidence
Filename, MIME-style identification, application context.
Size & content
Combine size with hashing
Size changed but filename stayed the same
Content likely changed, but verify with hashes.
Size stayed the same but hash changed
Content definitely differs despite identical size.
Different filename and same hash
The content is extremely likely identical despite the rename.
Same filename and different hash
The files contain different bytes.
Unexpectedly tiny executable or archive
Worth checking actual type, source, and integrity, but size alone is not proof.
Large temporary file
Could be legitimate cache, installer, extraction, or application data. Correlate before concluding.
Ownership
Ownership gives account context, not motive
User-owned file in Downloads
Consistent with user-profile storage, but ownership does not prove who initiated the download.
SYSTEM-owned service executable
Potentially normal for installed software. Validate path, signature, service definition, and installation context.
Root-owned script in /usr/local/bin
Could be administrator-installed software. Check package/source context, timestamps, and related service or cron references.
User-owned file in a system directory
Unusual context worth investigating, but confirm permissions, installation history, and logs before drawing conclusions.
Timeline method
Build time evidence carefully
Record original display
Write down the timestamp exactly as the tool shows it, including date, time, and zone where available.
Label the timestamp type
Creation, modification, access, metadata-change, event, download, or another specific category.
Record the source
Note the host, path, log, application, or filesystem that produced the timestamp.
Compare related evidence
Place browser, log, process, and file times side by side instead of relying on one artifact.
Check for transformations
Ask whether copy, extraction, restore, edit, rename, or permission changes could explain the time values.
State uncertainty
If the timestamp meaning is ambiguous, document the limitation and avoid pretending the sequence is exact.
Fictional timeline lab
Separate archive history from local-system history
Authentication log
trainee3 signs in to the fictional workstation.
Browser download record
training.zip is downloaded into the user's Downloads folder.
Filesystem creation time
training.zip appears locally near the browser-record time.
Internal archive modification time
A file inside the archive carries an older stored timestamp.
Filesystem creation context
notes.txt appears after extraction.
Modification time
notes.txt content changes after extraction.
Task 01
Does the 2024 modification time prove notes.txt existed on this computer in 2024?
No. The archive may have preserved an older internal timestamp.
Task 02
What supports the conclusion that training.zip was downloaded around 13:24?
The browser download record and matching local creation context.
Task 03
What does the 13:29 modification time support?
The local notes.txt content changed after extraction.
Task 04
Can the timestamps alone identify who edited notes.txt?
No. User session, process, application, and log evidence would be needed.
Task 05
Which event appears first on the local system?
The 13:20 authentication event.
Task 06
Why should the archived 2024 time not be mixed directly with local event times?
It represents stored file metadata from before extraction, not necessarily local-system activity.
Common mistakes
Metadata mistakes that create false timelines
Treating creation time as universal origin
Creation-style timestamps usually describe the current filesystem entry, not the first time the content ever existed.
Calling Linux ctime creation time
ctime normally represents metadata change time, not creation.
Ignoring time zones
Cross-source ordering can become wrong when logs and tools display different zones.
Trusting file extensions
Extensions can be changed and should not replace actual type inspection.
Using access time as proof of human action
Applications, scanners, indexing, backups, and the OS can access files automatically.
Ignoring copy and extraction behavior
Transformations can preserve some timestamps while generating others.
Changing permissions before recording them
Original ownership and ACLs may be valuable evidence.
Assuming identical size means identical content
Only a strong content comparison such as hashing can establish byte-level identity.
Lesson checklist
Before moving on
I record the full path with the filename.
I understand the difference between metadata and content.
I label each timestamp type correctly.
I do not call Linux ctime creation time.
I consider copy, extraction, restore, and edit behavior.
I record time zone context when available.
I use hashes when exact content identity matters.
I treat file extensions as clues, not proof.
I record ownership and permissions before changing them.
I avoid using access time alone as proof that a person opened a file.
I correlate metadata with logs, browser records, and process evidence.
I document uncertainty when timestamp meaning is ambiguous.
Reflection
Check your timestamp reasoning
Question 1
Why can a file's creation time fail to represent the first time that content ever existed?
Question 2
What is the difference between Linux mtime and ctime?
Question 3
Why is an extension weaker evidence than a content hash or file-type check?
Question 4
How can extraction create a misleading timeline if you do not understand stored archive timestamps?
Question 5
Why can access time fail to prove a person opened a file?
Question 6
What additional evidence would you use to identify who modified a file?
Carry this forward
Treat metadata as context, label timestamp types correctly, account for copy and extraction behavior, and use logs, hashes, browser records, and process evidence to confirm the story.