Forensics · Lesson 14
Email, Documents & Suspicious File Triage
Learn how to preserve and analyze email messages, attachments, documents, archives, and suspicious files without executing unknown content.
Safe triage begins with metadata, path, type, timestamps, hash, sender context, and surrounding evidence. Opening or running the file is not the first step.
Lesson Snapshot
Learning objectives
Preserve evidence before interacting with suspicious content
Explain how email, document, archive, and attachment artifacts can be reviewed safely without opening or executing unknown content.
Recognize useful evidence such as sender fields, recipients, subject, timestamps, attachment names, file type, metadata, and hashes.
Distinguish email display names from actual addresses and visible filenames from actual file types.
Use metadata, hashes, paths, and application evidence to triage suspicious files without relying on filenames alone.
Correlate email and document evidence with browser downloads, user sessions, file metadata, processes, and security-product logs.
Preserve suspicious attachments and document evidence before deleting, renaming, quarantining, or changing the original artifacts.
Core idea
Observe first, interact later
Filename, path, file type, size, timestamps, hash, sender fields, and application evidence usually provide enough context to begin triage without opening the file.
Competition caution
Do not enable macros or unknown active content
Macro-capable or executable content should be handled as evidence. Use metadata, process logs, and security-product records rather than intentionally running unknown content.
Triage principles
Use safe evidence before active interaction
Do not execute unknown content
Triage should begin with observation, metadata, file type, path, size, hash, and surrounding evidence. Opening or executing unknown content can change the system and create risk.
Display name is not identity
An email can show a friendly display name that differs from the underlying address. Record both.
Extension is not file type
A filename such as report.pdf or invoice.docx is only a label. Use system tools to identify the actual content type.
Attachment presence is not execution
An attachment can exist in a mailbox, Downloads folder, or cache without ever being opened.
Metadata is context, not motive
Author, title, timestamps, and application fields can help build a timeline but rarely prove intent by themselves.
Preserve before cleanup
Deleting a suspicious message or file can destroy the exact evidence needed to answer a later question.
Email fields
Read message identity and routing fields carefully
From
The sender address presented in the message.
Caution
The visible sender can be misleading. Header context may show a different route or envelope sender.
To / Cc
Recorded recipients.
Caution
Do not assume every recipient opened or read the message.
Subject
Human-readable subject line.
Caution
Subjects are user-controlled and can be misleading.
Date
Message timestamp as recorded in the email.
Caution
Timezone and mail-client display settings matter.
Message-ID
A message identifier commonly generated by sending infrastructure.
Caution
Useful for correlation, but not proof of trustworthiness.
Reply-To
Address where replies may be directed.
Caution
A mismatch with From can be relevant, but legitimate services also use different reply addresses.
Received
Mail-server routing records added during transit.
Caution
Read them as a chain and avoid treating one field as complete sender attribution.
Attachment name
Filename presented for an attached object.
Caution
The filename and extension can be misleading.
Header reasoning
Separate observation from sender assumptions
Display name says IT Support, address is helpdesk@example.org
Supported
The message displays IT Support while using the recorded address.
Not supported
The sender is legitimate solely because the display name looks official.
Reply-To differs from From
Supported
Replies would be directed to a different address.
Not supported
The message is malicious automatically; some legitimate systems use separate reply addresses.
Received headers show multiple mail servers
Supported
The message passed through those recorded systems in that order as represented by the headers.
Not supported
The topmost visible sender field alone identifies the original human sender.
Attachment named invoice.pdf.exe
Supported
The filename contains multiple extensions and ends in .exe.
Not supported
The file is malicious without content and context review.
Message timestamp is 09:15 -0400
Supported
The message records that local offset in its timestamp.
Not supported
Every system involved used the same timezone.
Message-ID repeats across copied evidence
Supported
The artifacts may refer to the same message.
Not supported
The message content is trustworthy.
Attachment evidence
Preserve the fields that establish file identity
Filename
Useful label, but can be changed easily.
Full path
Shows where the file actually exists on the system.
Size
Helps compare copies and identify changes.
Actual file type
Checks whether content matches the filename extension.
SHA-256
Provides strong content identity.
Creation / birth context
Helps place local appearance in the timeline.
Modification time
Can show later content change.
Owner
Provides account context, not authorship proof.
Source
Email, browser, archive, share, removable media, or another path of arrival.
File categories
Different files require different evidence questions
Metadata, path, hash, actual file type, reader history, and whether embedded content or links are relevant to the question.
Caution
Do not assume a PDF is safe because it appears to be a document.
Office documents
DOCX, XLSX, PPTX and related files can contain metadata, links, embedded objects, and macro-enabled variants.
Caution
Do not enable macros or active content in unknown files.
Plain text / scripts
Content can often be reviewed as text without execution when authorized and safe.
Caution
Reading is different from running. Do not execute unknown scripts.
Archives
ZIP, 7z, tar, and similar containers can hold multiple files with their own timestamps and paths.
Caution
Extracting changes local filesystem state. Preserve the original archive first.
Executables
Filename, path, size, hash, signature information, process evidence, and source context.
Caution
Do not run unknown executables to see what they do.
Images
File type, metadata, dimensions, timestamps, path, and source.
Caution
Metadata can be absent or altered and should not be treated as proof of authorship.
Macro awareness
Recognize active-content risk without executing it
Macro-enabled formats
Some Office file types support embedded macros or active content. Their presence can be relevant to triage.
Do not enable content
Unknown documents should not be opened with active content enabled merely to inspect behavior.
Metadata first
Begin with filename, path, file type, size, hash, source, and timestamps.
Correlate with process evidence
If the question is whether a document led to execution, use application/process logs and command lines rather than assuming from the document alone.
Security-product records
Defender or another endpoint tool may provide detection context that can be correlated with the file hash and path.
Windows
Inspect suspicious files without running them
Inspect file metadata
Get-Item "C:\Users\trainee\Downloads\report.docx" | Format-List Name,FullName,Length,CreationTime,LastWriteTime,LastAccessTime,Attributes
Shows common metadata without executing the file.
Hash the file
Get-FileHash "C:\Users\trainee\Downloads\report.docx" -Algorithm SHA256
Provides exact content identity.
File owner
(Get-Acl "C:\Users\trainee\Downloads\report.docx").Owner
Shows the current owner for account context.
Search matching filename
Get-ChildItem "C:\Users\trainee" -Filter "report.docx" -Recurse -Force -ErrorAction SilentlyContinue
Finds matching filenames in a scoped user profile.
Related process evidence
Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId,Name,ExecutablePath,CommandLine
Helps determine whether a document, script, or executable was later opened or launched.
Linux
Inspect suspicious files without running them
Inspect file metadata
stat /home/trainee/Downloads/report.docx
Shows size, ownership, permissions, and timestamps.
Identify actual type
file /home/trainee/Downloads/report.docx
Checks content type rather than trusting the extension.
Hash the file
sha256sum /home/trainee/Downloads/report.docx
Provides exact content identity.
Search for copies
find /home/trainee -name "report.docx" 2>/dev/null
Finds copies or moved versions inside the selected profile.
Review process command lines
ps -eo pid,ppid,user,lstart,cmd
Helps identify applications or scripts associated with a file.
Question-to-evidence map
Use the right artifact for each suspicious-file question
Where did the file come from?
Email attachment record, browser download history, archive contents, share path, removable-media context, or application logs.
What is the file really?
Actual file-type identification plus extension and content structure.
Is this the same file as another copy?
SHA-256 comparison.
Was it opened?
Application history, recent-file records, process evidence, or application logs.
Was it executed?
Process creation, command line, service/task evidence, or execution logs.
Was it modified?
Hash change, modification timestamp, application evidence, or version comparison.
Filename triage
Never trust the extension by itself
quarterly-report.pdf.exeThe file ends in .exe despite containing .pdf earlier in the name.
invoice.docmThe format can support macros; treat active content cautiously.
notes.txt renamed to notes.pdfExtension alone may no longer match the actual file type.
archive.zip contains update.ps1The archive and extracted script are separate artifacts with separate hashes and timeline context.
same report.docx in two folders, different SHA-256The files are different content despite matching names.
Document metadata
Useful context with important limits
Author
Application-provided metadata about document authorship.
Caution
Can be absent, automatically populated, copied from a template, or edited.
Title / Subject
Descriptive document metadata.
Caution
User-editable and not proof of content origin.
Created
Document-internal creation metadata where available.
Caution
Can differ from filesystem creation time and can survive copying.
Modified
Document-internal modification metadata where available.
Caution
May not match filesystem LastWriteTime in every transformation.
Application
Software recorded as creating or modifying the document.
Caution
Can reflect a template or later edit rather than original creation.
Revision count
Some document formats store a revision or save count.
Caution
Useful context, not a complete editing history.
Evidence chain
Move from message to attachment to execution evidence
Message
Sender fields, recipients, subject, message timestamp, Message-ID, attachment name.
Attachment
Filename, MIME/content type where available, size, and attachment relationship.
Local file
Destination path, filesystem timestamps, owner, size, actual type, and SHA-256.
Opening
Application history, recent-file records, process evidence, or logs.
Execution
Process creation, script host, command line, service/task evidence, or other execution records.
Follow-on activity
Network connections, file creation, scheduled activity, service changes, or security-product records.
Correlation
Combine message, file, application, and security evidence
Email attachment at 09:05 + local file creation at 09:06 + matching size/hash
Supported conclusion
The local file is consistent with the email attachment.
Attachment saved at 10:12 + document viewer process at 10:15 + recent-file record
Supported conclusion
The document was likely opened by the viewer application.
DOCM attachment + macro-capable format + no process or execution evidence
Supported conclusion
The file can support macros, but there is no evidence here that macros ran.
Archive attached + script extracted + scheduled task created later
Supported conclusion
The archive, extracted script, and scheduled task form a related evidence chain.
Same hash in email attachment and Temp directory under different names
Supported conclusion
The content is identical despite the filename and path change.
Defender detection references same hash as downloaded attachment
Supported conclusion
The security-product record and attachment refer to the same file content.
Evidence note
Preserve the message-to-file chain
Message source or mailbox context
From address and display name
To / Cc
Subject
Message timestamp and zone
Message-ID
Reply-To if relevant
Attachment name
Attachment size
Local path
Actual file type
SHA-256 hash
Filesystem timestamps
Related process/application evidence
Common mistakes
File-triage mistakes that destroy evidence or create risk
Opening unknown files first
Opening or executing a file can change system state and introduce risk before evidence is preserved.
Trusting display names
Friendly sender names can differ from the underlying address.
Trusting extensions
A filename extension can be misleading. Verify the actual file type.
Equating attachment with execution
An attachment can exist without ever being opened or run.
Treating macro-capable as macro-executed
Format capability and actual execution are separate facts.
Ignoring archive transformations
Extracted files have their own paths, hashes, and local timeline context.
Deleting before hashing
You can lose the easiest way to prove file identity later.
Recording secrets from email sessions
Do not expose live tokens, passwords, cookies, or private keys in training notes.
Fictional email & document lab
Reconstruct attachment receipt, saving, opening, and later evidence
Fictional message from Training Office <office@training.example> arrives with attachment schedule.docm.
schedule.docm is saved to C:\Users\trainee8\Downloads\schedule.docm.
schedule.docm appears locally with SHA-256 HASH-S1.
A document viewer opens schedule.docm.
No script-host or child-process evidence is observed in the fictional timeline.
A fictional endpoint tool records a scan of HASH-S1 with no detection.
Task 01
What proves the message carried schedule.docm?
The email attachment record associated with the fictional message.
Task 02
What connects the saved file to the attachment?
The matching filename, timing, size context, and SHA-256 HASH-S1.
Task 03
Does the .docm extension prove a macro executed?
No. It only identifies a macro-capable format. Execution requires separate evidence.
Task 04
What evidence supports that the file was opened?
The application evidence showing a document viewer opened schedule.docm at 08:48.
Task 05
What does the lack of child-process evidence mean?
This evidence set does not show a script-host or child process during the observed window. It does not prove no other action occurred.
Task 06
What should be preserved before deleting the attachment?
Email metadata, attachment details, local path, timestamps, actual type, SHA-256, application evidence, and security-product record.
Lesson checklist
Before moving on
I preserve the message and attachment before cleanup.
I record sender display name and actual address separately.
I record message timestamp and timezone.
I record Message-ID and Reply-To when relevant.
I verify the attachment's actual file type.
I record local path, size, timestamps, owner, and SHA-256.
I distinguish attachment presence from opening and execution.
I do not enable macros or active content in unknown files.
I correlate document activity with process evidence.
I compare attachment and local-file hashes when identity matters.
I preserve archive originals before extraction or deletion.
I avoid exposing credentials, session tokens, or other secrets.
Reflection
Check your triage reasoning
Question 1
Why does a sender display name fail to prove sender identity?
Question 2
What evidence would you use to prove an attachment was actually executed?
Question 3
Why is .docm a reason for caution but not proof that a macro ran?
Question 4
How can hashes connect an email attachment to a renamed local copy?
Question 5
Why should the original archive or attachment be preserved before extraction?
Question 6
What evidence would you record before deleting a suspicious document?
Carry this forward
Preserve the original message and file, verify type and hash, separate attachment presence from opening and execution, and use process evidence before making stronger claims.